余姚什么网站做装修比较好,蚌埠市网站建设公司,亚马逊市场营销案例分析,江门网站制作网站文/Joel Spolsky 译/罗小平
指派一名优秀的程序经理#xff0c;是团队产出优秀软件的重要前提之一。你的团队里可能没有这样的人#xff0c;其实绝大多数团队都没有。
Charles Simonyi#xff0c;这位曾与MarthaStewart#xff08;译者注#xff1a;美国女富豪#…文/Joel Spolsky 译/罗小平
指派一名优秀的程序经理是团队产出优秀软件的重要前提之一。你的团队里可能没有这样的人其实绝大多数团队都没有。
Charles Simonyi这位曾与MarthaStewart译者注美国女富豪作家拍拖15年、WYSIWYG字处理技术发明人之一、从微软股票赚得10亿美元译者注CharlesSimonyi曾是微软Office产品团队的负责人、到过太空的天才程序员是试图解决大型软件团队遇到的“人月神话”问题之第一人。他的方法是创立一个新的岗位由超级天才程序员担任负责系统中最重要功能的实现而其他次要部分则交给一个由低级程序员组成的杂牌团队。他把这个岗位命名为程序经理program manager。Simonyi本人是天才级的但他的这个想法可不怎么出彩我想没人愿意做一个被人轻视的低级程序员吧。 若需详细了解这段历史可以阅读William Poundstone的《How Would You Move Mount Fuji?》http://www.amazon.com/gp/product/0316778494?ieUTF8tagjoelonsoftwarelinkCodeas2camp1789creative9325creativeASIN0316778494。
Jabe Blumenthal是上世纪80年代后期在MacExcel团队工作过的一名程序员。他捡起了这个头衔但赋予了不同的含义。Blumenthal发现软件开发已经变得日益复杂以至没有哪个程序员有时间去关心如何真正保证软件的可用性和实用性。而市场人员又在一旁大谈客户需求抱怨没人听他们的话没人将他们MBA式的天才想法转化为软件中可用的功能。产品设计方面不少的工作都需要花费大量时间比如用户沟通、可用性测试、竞争对手产品的分析评估、将复杂问题化繁为简等等。但绝大多数程序员恰恰没有时间做这些事情实际上也往往也不是他们的强项。于是Blumenthal重拾“程序经理”不过完全重新定义了这个职位。
程序经理需要做什么工作
自此以后一名程序经理的工作包括
UI设计编写功能规格团队协调充当用户代言人还有穿Banana Republic牌子的休闲Chino裤
在小项目中你有一个程序经理就够了但对于大型项目很可能需配置多名每个人负责全部功能特性的一个子集。从很多项目总结出来了一个经验法则每四名程序员配置一个程序经理。那么如何划分功能集呢如果你遇到困难我向你推荐我从Mike Conte那学到的方法根据用户活动划分产品功能http://www.joelonsoftware.com/uibook/chapters/fog0000000065.html。比如twitter.com可划分为四类用户活动 1. 注册与登录 2. 发表帖子、阅读回复 3. 配置个人账户 4. 搜索新闻
我的第一份程序经理工作是在微软的Excel团队负责一个叫做“用户化”的用户活动比如编写脚本、宏。我首先要做的事情是搞清楚用户的需求。于是我与很多用户交流直到我长满茧子的耳朵总是只能听到相同的需求、让人厌烦为止。接下来我要需花很多时间与开发团队沟通弄清在18个月的新版本开发周期中哪些需求是合理的、可以实现的。我和VisualBasic团队沟通确定他们是否可提供编译器、代码编辑器、对话框编辑器否则用户就不能在Excel中使用宏语言。我必须跑去与Apple沟通他们当时正在自己搞一门叫做AppleScript的通用宏语言。此外我还要和微软内部的其他应用团队主要包括Word、Access、Project和Mail等打交道因为他们也在做和Excel团队差不多的事情。这个过程的绝大部分工作都是沟通讨论——会议、邮件、电话……几乎无休无止。我被那段生活搞怕了直到现在在办公室的时候还怕听到电话铃响。
第二步是写愿景规划。这是一个内容相当宽泛的文档比如VisualBasic如何在Excel中工作用户可能编写的宏是什么样子需要技术团队构建哪些模块以及它们如何解决用户的问题。然后在此基础上讨论修改直到没有太多分歧。至此我可以开始编写详细规格书要描述清楚每个不可再分的细节呈现在用户面前时的样子。
这是一份功能而不是技术规格书。也就是说它的全部内容都用于描述用户所见所为而不是程序如何实现。若需进一步了解功能规格请阅读http://www.joelonsoftware.com/articles/fog0000000036.html。程序经理不关心开发团队的内部实现细节。当我将这份功能规格发给开发团队的头头BenWaldman后他和他的团队再坐下来详细讨论实现工作。最后他们很聪明地弄出一份精悍的表格将我定义的面向对象的接口一一映射到Excel内部功能。当然这的确不是我的事情我对Excel内部知之甚少也真的不知道那些需求应该怎么实现。
老实说我那时候对什么都是一窍不通。刚从学校出来对代码开发、程序测试、文档撰写、产品推广以及可用性测试等等我完全没有经验。幸运的是微软在每个岗位都有经验丰富的导师他们教给了我迄今知道的全部知识也是他们真正承担了这么大的产品的全部实际工作。举个我知道的例子说吧用户可能需要在宏程序里将电子表格中单元格的值复制给一个变量 x [A1] 问题是单元格的值可能是数字也可能是字符串而Basic语言是早期绑定的你必须首先用DIM将x定义为Integer、Float或String等确定类型然后才能使用。
要解决这个问题Basic必须支持某种动态类型但我没那么聪明想不出什么解决办法。不要紧Visual Basic团队的程序员Tom Corbett想出来了http://www.patentstorm.us/patents/5689709/description.html。Variants和IDispatch由此诞生了借助“鸭式类型识别”ducktyping。“如果一只鸟走起来像鸭子叫起来像鸭子那我们就可以管它叫鸭子。”Basic摇身一变成了动态语言。这个事情说明我的工作不是自己去解决问题而是找到用户需要解决的问题并保证程序员找出解决这些问题的办法。
一旦功能规格完成、技术团队开始工作后我的职责就有了变化1解决设计方面出现的问题2负责与所有其他团队的沟通以便节省开发人员的时间。例如我要向测试人员说明全部功能是如何运转的帮助他们设计测试计划确保文档团队明白如何为ExcelBasic编写一份高质量的教程和参考手册和本地化专家确定本地化策略向市场人员解释VBA在市场上的优势和可用性专家设计可用性测试方案等。
程序经理需参加大量的会议但其产出基本不超出规格文档这个范围因此我一个刚毕业的无用之人也能胜任这份工作。完全没必要让一个有14年经验的资深程序员担当程序经理。实际上有14年的开发经验你反而可能因为知道太多而无法扮演好用户代言人这个角色。
冲突 如果没有程序经理聪明的程序员们在一起可能设计出让用户难以理解的界面也许只有Vulcan人《Star Trek /星际迷航》中逻辑思维能力超强的外星种族才会表示“正合吾意”。最好的程序员会聪明到不能理解用户为何不能记住16个单字母的命令行参数。这些程序员往往难以割舍他们的最初想法尤其是已经将自己的想法变成了代码之后。
程序经理给软件设计流程带来的最大益处是可以引入程序员之外的第二种观点。而这种观点恰恰更接近用户的想法——这些用户往往既不想阅读使用手册更不想写什么emacs-lisp函数至于在他们大脑里将十进制数字转化为八进制那就更不可能了。
一个好的程序经理对于UI的工作方式有他自己的想法和开发人员的相比可能更好也可能更坏因此需要双方讨论。通常程序经理是站在用户角度希望凡事尽可能简单易懂诸如有心灵感应力的用户界面、大到30″而又能放进口袋的屏幕之类而开发人员想的是处处尽可能减少要编写的代码支持命令行界面他们会说“这怎么就不好用了呢”和Python绑定。
我记得Excel 5项目中最为经典的争论发生在一个开发人员和程序经理之间。开发人员希望数据透视表pivottable悬浮在电子表格的绘画层上而程序经理坚持认为数据透视表应位于单元格的右侧。这个争论持续了很长很长时间最后程序经理胜出。但最终的设计比当初任何一方的单独设计都好出很多。
为确保这种争论完全以事实为基础、在参与方间平等地展开程序经理和开发人员地位对等是绝对必要的。如果开发人员负责向程序经理汇报那么在争论过程的任何时刻程序经理只要略感厌倦就可以说“好了讨论得够了现在就按我说的办”。如果他们是对等的这种事情就不会发生。就好比在法庭我们不能允许任何一方的律师同时是法官。只有建立在这个理论之上真理才最可能通过对等双方间的争论而被发现。只有任何参与方都不具有不公平优势时争论本身才可能是公平的。
这点很关键如果你刚才还在梦里探究11年级的Sally现在哪儿赶紧醒醒吧。她在Scottsdale做生物医学家还入了共和党。我们必须明白程序员不能是程序经理的下属换句话说开发团队的头头、CTO或CEO都不应是负责撰写规格书的人。
大多数公司犯的头号错误就是让程序员的上级编写规格书、设计产品。这样出来的设计不能得到真正平等的审查不能引出冲突与争议自然就不会好到哪里去。
我真正弄懂这个道理并不容易。在Fog Creek软件公司我自己曾承担了该程序经理做的大量工作为此我费劲口水时刻提醒在我说错的时候程序员要指出、争辩。我们不是大公司但也已经到了需要真正的程序经理的时候了——Dan和Jason程序员喜欢和他们吵。
当然程序员和程序经理地位对等的时候程序员会略占优势。这样的事曾发生过几次程序员让我介入他和程序经理间发生的争议。 “谁写代码”我问。 “是我……” “那好谁负责将程序签入版本控制库呢” “我想还是我……” “既然这样那你还有什么问题呢”我问“你对最终产品的每个比特都有绝对控制权你还需要什么呢一顶皇冠”
可见这种体制将担子压在了程序经理肩上要求程序经理能说服程序员因为在某些时候程序经理会面临程序员不理会争议而直接按自己想法行事的风险。因此要成为一名优秀、有影响力的程序经理要求你1正确2赢得程序员的尊重唯此他们才可能承认你的正确。
如何赢得这种尊重
若已是编程高手当然对你担任程序经理很有帮助。但这个要求并不公平。我也不建议程序经理去写代码。不过程序员通常首先尊重的是同是程序员的人而不是非程序员无论他们多聪明。不会写程序而要成为一个受人尊重的程序经理是可能的但往往要付出更多努力才行。
赢得开发人员尊重的另一个方法是能在出现争议的时候充分展示你的才华、开明和正直。如果程序经理净说傻话办蠢事程序员就会在心里给他们打上笨蛋标记。程序经理武断、情绪化地固执己见不可理喻也会大丢信誉分。所以双方特别是程序经理一定要避免在争论中带入个人情绪事实已证明自己犯错时要乐于、勇于改变老观点考虑新问题。最后要说的一点是如果程序经理被发现玩弄权术、向老板打小报告或试图依靠分而治之的阴谋手段而不是事实在分歧中胜出都会在程序员那里大失信任。
一个失去了程序开发团队信任的程序经理将寸步难行。程序员会无视程序经理的存在直接按照自己意愿行事。其结果是出现大量错误、浪费大量时间你不但要付给低效率的程序经理薪水他们还要召集会议、占用其他很多人的时间而程序质量又没有因此得到提高。
规格化是否是不敏捷的代名词 在很多开发团队中规格文档变成了无思想、无灵气、满篇官僚词句的一堆废纸因此要求革除规格文档的呼声很高。其实这些人被误导了。功能规格书的编写恰恰是敏捷开发中的灵魂因为它可以让你在写代码前将大量可能的设计方案快速过一遍。和代码的变更相比规格文档编写所耗费的工作量实在微不足道。编写规格书会强迫你对大脑中已有的设计方案深思熟虑帮你快速找到其中的缺陷充分考虑各种替代方案。有效利用了功能规格书的团队产品质量更好因为他们有机会快速探究大量可能的解决方案。而且他们写代码也更快因为他们对整个流程的理解更为清晰。功能规格如此重要以至于在我们FogCreek公司不多的硬性规定之一就是“无规格则无代码”。
当然功能规格书的具体格式可依情况而定。但其必须遵守一条原则它是用来说明程序在用户面前如何运行的。它无需解释程序内部代码如何工作。具体来说你应首先从顶层开始愿景描述visionstatement用不超过一页纸的篇幅说明新特性、新功能的要点。这步工作完成就可以开发情景图storyboard——用户在应用程序中行进的各种场景图并详细说明每个场景中程序如何工作。对于很多类型的功能而言尤其是UI级的功能一旦你完成了这些情境图也就可以描述清楚了。这就是你的功能规格。Jason Fried现在该你发言了http://gettingreal.37signals.com/ch11_Theres_Nothing_Functional_about_a_Functional_Spec.php。
若要学习如何编写高质量功能规格书可阅读我的文章《功能规格四部曲》http://www.joelonsoftware.com/articles/fog0000000036.html。若需要我编写规格书范本可从http://www.joelonsoftware.com/articles/AardvarkSpec.html下载。
在一些复杂的功能中可能还包含着不在UI展示的隐藏行为这时候你也应该写清楚这些细节。无论如何编写规格书本身就有助于在写下第一行代码前发现问题、冲突和设计漏洞这样在你真正写代码的时候可能导致设计混乱、质量低下、甚至重新设计这类不可预知问题的出现概率要低很多。
如何学做程序经理
要成为一名合格的程序经理主要就是学习学习技术、学习做人、学习如何在组织中产生影响力。一个好的程序经理要同时具备工程师的技术设计方法、政治家构建共识、团结民众的能力。这方面可读的书不多若你从事这项工作我还是尽我所知推荐几本
Scott Berkun的《Making Things Happen》http://www.amazon.com/gp/product/0596517718?ieUTF8tagjoelonsoftwarelinkCodeas2camp1789creative390957creativeASIN0596517718这是唯一一本非常准确说明了程序经理必须做哪些事情的书就从它开始吧。Scott曾长期在Internet Explorer团队担任程序经理。
Another big part of the program manager’s job is user interfacedesign. Read Steve Krug’s Don’t Make Me Think, then my own book UserInterface Design for Programmers.
程序经理的另一大块工作是用户界面设计。这方面可阅读Steve Krug的《Don’t Make Me Think》http://www.amazon.com/gp/product/0321344758?ieUTF8tagjoelonsoftwarelinkCodeas2camp1789creative390957creativeASIN0321344758和我自己的《User Interface Design for Programmers》http://www.amazon.com/gp/product/1893115941?ieUTF8tagjoelonsoftwarelinkCodeas2camp1789creative390957creativeASIN1893115941。
最后我知道听起来可能有点老套但Dale Carnegie在1937年出版的《How to Win Friends Influence People》http://www.amazon.com/gp/product/0671027034?ieUTF8tagjoelonsoftwarelinkCodeas2camp1789creative390957creativeASIN0671027034确实是一本讲人际交往技巧的好书。它是我要求Fog Creek所有初级管理人员阅读的第一本书。我每次告诉他们阅读这本书时他们都会窃笑等到读完他们都会爱上这本书。
作者简介
Joel SpolskyFog Creek 软件公司http://www.fogcreek.com/创始人曾在微软Excel团队工作。FogCreek位于纽约这是一家以实践证明可以很好对待程序员而又能获得不错利润的公司。程序员有私人办公室、免费午餐每周工作40个小时。用户满意后才需为软件支付费用。公司主要产品包括FogBugz帮助大型团队开发高水平软件的项目管理系统Fog CreekCopilot让远程桌面变得轻而易举。
