如何学做程序经理？

指派一名优秀的程序经理，是团队产出优秀软件的重要前提之一。你的团队里可能没有这样的人，其实绝大多数团队都没有。

Charles Simonyi，这位曾与Martha Stewart（译者注：美国女富豪，作家）拍拖15年、WYSIWYG字处理技术发明人之一、从微软股票赚得10亿美元（译者注：Charles Simonyi曾是微软Office产品团队的负责人）、到过太空的天才程序员，是试图解决大型软件团队遇到的“人月神话”问题之第一人。他的方法是创立一个新的岗位，由超级天才程序员担任，负责系统中最重要功能的实现，而其他次要部分则交给一个由低级程序员组成的杂牌团队。他把这个岗位命名为程序经理（program manager）。Simonyi本人是天才级的，但他的这个想法可不怎么出彩，我想没人愿意做一个被人轻视的低级程序员吧。

若需详细了解这段历史，可以阅读William Poundstone的《How Would You Move Mount Fuji?》（http://www.amazon.com/gp/product/0316778494?ie=UTF8&tag=joelonsoftware&linkCode=as2&camp=1789&creative=9325&creativeASIN=0316778494）。

Jabe Blumenthal，是上世纪80年代后期在Mac Excel团队工作过的一名程序员。他捡起了这个头衔，但赋予了不同的含义。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个月的新版本开发周期中，哪些需求是合理的、可以实现的。我和Visual Basic团队沟通，确定他们是否可提供编译器、代码编辑器、对话框编辑器，否则用户就不能在Excel中使用宏语言。我必须跑去与Apple沟通，他们当时正在自己搞一门叫做AppleScript的通用宏语言。此外，我还要和微软内部的其他应用团队，主要包括Word、Access、Project和Mail等打交道，因为他们也在做和Excel团队差不多的事情。这个过程的绝大部分工作，都是沟通讨论——会议、邮件、电话……几乎无休无止。我被那段生活搞怕了，直到现在，在办公室的时候还怕听到电话铃响。

第二步是写愿景规划。这是一个内容相当宽泛的文档，比如Visual Basic如何在Excel中工作，用户可能编写的宏是什么样子，需要技术团队构建哪些模块，以及它们如何解决用户的问题。然后在此基础上讨论修改，直到没有太多分歧。至此，我可以开始编写详细规格书，要描述清楚每个不可再分的细节呈现在用户面前时的样子。

这是一份功能而不是技术规格书。也就是说，它的全部内容都用于描述用户所见所为，而不是程序如何实现。若需进一步了解功能规格，请阅读http://www.joelonsoftware.com/articles/fog0000000036.html。程序经理不关心开发团队的内部实现细节。当我将这份功能规格发给开发团队的头头Ben Waldman后，他和他的团队再坐下来详细讨论实现工作。最后，他们很聪明地弄出一份精悍的表格，将我定义的面向对象的接口一一映射到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由此诞生了，借助“鸭式类型识别”（duck typing。“如果一只鸟，走起来像鸭子，叫起来像鸭子，那我们就可以管它叫鸭子。”），Basic摇身一变，成了动态语言。这个事情说明，我的工作不是自己去解决问题，而是找到用户需要解决的问题，并保证程序员找出解决这些问题的办法。

一旦功能规格完成、技术团队开始工作后，我的职责就有了变化：（1）解决设计方面出现的问题；（2）负责与所有其他团队的沟通，以便节省开发人员的时间。例如，我要向测试人员说明全部功能是如何运转的，帮助他们设计测试计划；确保文档团队明白如何为Excel Basic编写一份高质量的教程和参考手册；和本地化专家确定本地化策略；向市场人员解释VBA在市场上的优势；和可用性专家设计可用性测试方案等。

程序经理需参加大量的会议，但其产出基本不超出规格文档这个范围，因此我一个刚毕业的无用之人也能胜任这份工作。完全没必要让一个有14年经验的资深程序员担当程序经理。实际上，有14年的开发经验，你反而可能因为知道太多，而无法扮演好用户代言人这个角色。

冲突

如果没有程序经理，聪明的程序员们在一起，可能设计出让用户难以理解的界面，也许只有Vulcan人（《Star Trek / 星际迷航》中逻辑思维能力超强的外星种族）才会表示“正合吾意”。最好的程序员会聪明到不能理解用户为何不能记住16个单字母的命令行参数。这些程序员往往难以割舍他们的最初想法，尤其是已经将自己的想法变成了代码之后。

程序经理给软件设计流程带来的最大益处，是可以引入程序员之外的第二种观点。而这种观点恰恰更接近用户的想法——这些用户往往既不想阅读使用手册，更不想写什么emacs-lisp函数，至于在他们大脑里将十进制数字转化为八进制，那就更不可能了。

一个好的程序经理对于UI的工作方式有他自己的想法，和开发人员的相比，可能更好，也可能更坏，因此需要双方讨论。通常，程序经理是站在用户角度，希望凡事尽可能简单易懂，诸如有心灵感应力的用户界面、大到30″而又能放进口袋的屏幕之类；而开发人员想的是处处尽可能减少要编写的代码，支持命令行界面（他们会说“这怎么就不好用了呢？”）和Python绑定。

我记得Excel 5项目中最为经典的争论发生在一个开发人员和程序经理之间。开发人员希望数据透视表（pivot table）悬浮在电子表格的绘画层上，而程序经理坚持认为数据透视表应位于单元格的右侧。这个争论持续了很长很长时间，最后程序经理胜出。但最终的设计比当初任何一方的单独设计都好出很多。

为确保这种争论完全以事实为基础、在参与方间平等地展开，程序经理和开发人员地位对等是绝对必要的。如果开发人员负责向程序经理汇报，那么在争论过程的任何时刻，程序经理只要略感厌倦，就可以说“好了，讨论得够了，现在就按我说的办”。如果他们是对等的，这种事情就不会发生。就好比在法庭，我们不能允许任何一方的律师同时是法官。只有建立在这个理论之上，真理才最可能通过对等双方间的争论而被发现。只有任何参与方都不具有不公平优势时，争论本身才可能是公平的。

这点很关键，如果你刚才还在梦里探究11年级的Sally现在哪儿，赶紧醒醒吧。她在Scottsdale做生物医学家，还入了共和党。我们必须明白，程序员不能是程序经理的下属，换句话说，开发团队的头头、CTO或CEO，都不应是负责撰写规格书的人。

大多数公司犯的头号错误，就是让程序员的上级编写规格书、设计产品。这样出来的设计，不能得到真正平等的审查，不能引出冲突与争议，自然就不会好到哪里去。

我真正弄懂这个道理，并不容易。在Fog Creek软件公司，我自己曾承担了该程序经理做的大量工作，为此我费劲口水，时刻提醒在我说错的时候，程序员要指出、争辩。我们不是大公司，但也已经到了需要真正的程序经理的时候了——Dan和Jason，程序员喜欢和他们吵。

当然，程序员和程序经理地位对等的时候，程序员会略占优势。这样的事曾发生过几次：程序员让我介入他和程序经理间发生的争议。
“谁写代码？”我问。
“是我……”
“那好，谁负责将程序签入版本控制库呢？”
“我想还是我……”
“既然这样，那你还有什么问题呢？”我问，“你对最终产品的每个比特都有绝对控制权，你还需要什么呢，一顶皇冠？”

可见，这种体制将担子压在了程序经理肩上，要求程序经理能说服程序员，因为在某些时候，程序经理会面临程序员不理会争议而直接按自己想法行事的风险。因此，要成为一名优秀、有影响力的程序经理，要求你：（1）正确；（2）赢得程序员的尊重，唯此他们才可能承认你的正确。

如何赢得这种尊重？

若已是编程高手，当然对你担任程序经理很有帮助。但这个要求并不公平。我也不建议程序经理去写代码。不过，程序员通常首先尊重的是同是程序员的人，而不是非程序员，无论他们多聪明。不会写程序而要成为一个受人尊重的程序经理是可能的，但往往要付出更多努力才行。

赢得开发人员尊重的另一个方法，是能在出现争议的时候充分展示你的才华、开明和正直。如果程序经理净说傻话办蠢事，程序员就会在心里给他们打上笨蛋标记。程序经理武断、情绪化地固执己见，不可理喻，也会大丢信誉分。所以双方，特别是程序经理，一定要避免在争论中带入个人情绪，事实已证明自己犯错时，要乐于、勇于改变老观点，考虑新问题。最后要说的一点是，如果程序经理被发现玩弄权术、向老板打小报告，或试图依靠分而治之的阴谋手段而不是事实在分歧中胜出，都会在程序员那里大失信任。

一个失去了程序开发团队信任的程序经理，将寸步难行。程序员会无视程序经理的存在，直接按照自己意愿行事。其结果是出现大量错误、浪费大量时间，你不但要付给低效率的程序经理薪水，他们还要召集会议、占用其他很多人的时间，而程序质量又没有因此得到提高。

规格化是否是不敏捷的代名词？

在很多开发团队中，规格文档变成了无思想、无灵气、满篇官僚词句的一堆废纸，因此要求革除规格文档的呼声很高。其实这些人被误导了。功能规格书的编写，恰恰是敏捷开发中的灵魂，因为它可以让你在写代码前将大量可能的设计方案快速过一遍。和代码的变更相比，规格文档编写所耗费的工作量实在微不足道。编写规格书会强迫你对大脑中已有的设计方案深思熟虑，帮你快速找到其中的缺陷，充分考虑各种替代方案。有效利用了功能规格书的团队，产品质量更好，因为他们有机会快速探究大量可能的解决方案。而且，他们写代码也更快，因为他们对整个流程的理解更为清晰。功能规格如此重要，以至于在我们Fog Creek公司，不多的硬性规定之一就是“无规格，则无代码”。

当然，功能规格书的具体格式，可依情况而定。但其必须遵守一条原则：它是用来说明程序在用户面前如何运行的。它无需解释程序内部代码如何工作。具体来说，你应首先从顶层开始：愿景描述（vision statement），用不超过一页纸的篇幅，说明新特性、新功能的要点。这步工作完成，就可以开发情景图（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?ie=UTF8&tag=joelonsoftware&linkCode=as2&camp=1789&creative=390957&creativeASIN=0596517718），这是唯一一本非常准确说明了程序经理必须做哪些事情的书，就从它开始吧。Scott曾长期在Internet Explorer团队担任程序经理。

Another big part of the program manager’s job is user interface design. Read Steve Krug’s Don’t Make Me Think, then my own book User Interface Design for Programmers.

程序经理的另一大块工作是用户界面设计。这方面可阅读Steve Krug的《Don’t Make Me Think》（http://www.amazon.com/gp/product/0321344758?ie=UTF8&tag=joelonsoftware&linkCode=as2&camp=1789&creative=390957&creativeASIN=0321344758）和我自己的《User Interface Design for Programmers》（http://www.amazon.com/gp/product/1893115941?ie=UTF8&tag=joelonsoftware&linkCode=as2&camp=1789&creative=390957&creativeASIN=1893115941）。

最后，我知道听起来可能有点老套，但Dale Carnegie在1937年出版的《How to Win Friends & Influence People》（http://www.amazon.com/gp/product/0671027034?ie=UTF8&tag=joelonsoftware&linkCode=as2&camp=1789&creative=390957&creativeASIN=0671027034）确实是一本讲人际交往技巧的好书。它是我要求Fog Creek所有初级管理人员阅读的第一本书。我每次告诉他们阅读这本书时，他们都会窃笑；等到读完，他们都会爱上这本书。

作者简介：

Joel Spolsky：Fog Creek 软件公司（http://www.fogcreek.com/）创始人，曾在微软Excel团队工作。Fog Creek位于纽约，这是一家以实践证明可以很好对待程序员，而又能获得不错利润的公司。程序员有私人办公室、免费午餐，每周工作40个小时。用户满意后才需为软件支付费用。公司主要产品包括：FogBugz，帮助大型团队开发高水平软件的项目管理系统；Fog Creek Copilot，让远程桌面变得轻而易举。

程序员与程序经理
指派一名优秀的程序经理，是团队产出优秀软件的重要前提之一。你的团队里可能没有这样的人，其实绝大多数团队都没有。
工作在第一线的软件开发人员是程序员和程序经理，他们决定着软件的命运。良好的程序员队伍和出色的管理是软件项目成功的必要条件。管理不是管制，不是去卡住人家的脖子，因为程序员不是一群野鸭子。管理的目的是让大家一起把工作做好，并且让各人获得各自的快乐和满足。当一个组织被出色地领导时，雇员甚至不知道他们已被领导。在项目完成时，他们会自豪地说：“看看我们通过努力取得的成绩吧”。所以管理者不能老惦记着自己是一个官，而应时刻意识到自己是责任的主要承担者。
我们经常会听到有经理头衔的人在高谈阔论：“编程我不会，做个项目还不easy？派个人去搞系统分析，回头再叫几个程序员把需求译成程序，不就OK了吗？”
不懂英语的人准以为easy和OK是贬义词。要让软件项目失败很容易，只要符合下列条件之一即可：
（1）项目经理对软件一无所知；
（2）技术负责人对编程不感兴趣；
（3）真真编写代码的程序员是临时雇用的。
如果上述三个条件同时具备，就请放心失败好了。
让我们少幻想自己是比尔·盖茨，先当好程序员和程序经理再说。

2.1 了 解 程 序 员

早期的程序员干活能从软件直通硬件，个个生猛无比。又因他们的作息时间、言行举止与常人不太一样，久而久之就给人们留下了“神秘”、“孤僻”的印象。如今软件行业被炒得热火朝天，有能耐的程序员即便躲在大山岙的军工厂里也能被挖出来。而更多原本不是程序员的人操起几本“速成”、“二十一天通”等书籍也加入了这个行业。现在国内号称有上百万程序员，这支大军鱼龙混杂，已搞不清那些是正规军，那些是民兵游击队了。
真正的程序员都有如下秉性：
一、诚实
程序员在学习与工作期间几乎天天与机器打交道，压根就没有受欺骗或欺骗人的机会。勤奋的程序员在调试无穷多的程序Bug时，已经深深地接受了“诚实”的教育。不诚实的人，他肯定不想做、也做不好程序员。
有一名市场营销员和一名程序员都在新闻发布会上发言，将一项新技术的消息公布于众。
市场营销员说：“这项技术比电话、晶体管和原子弹三项发明加起来对世界文明的影响都要大。”
程序员说：“这项技术在有限的领域内，在有限的程度上，解决了一些技术性的问题。”
看来为了让我们的民族更加诚实，学电脑真的要从娃娃抓起。
二、简单——实用主义
有人问一个数学家，一个物理学家和一名程序员：“一个盒子有几个面？”
数学家回答说：“有六个面，因为盒子是长方体。”
物理学家回答说：“有12个面，分为6个外表面和6个内表面。”
程序员回答说：“只有两个面，里面放电路板和硬盘，外面放显示器和键盘。”
目前即使最先进的计算机也不具备智能，程序员的基本工作就是把复杂的问题转化为计算机能处理的简单的程序。如果一个问题复杂到连程序员自己都不能理解，他就无法编出程序让更笨的计算机来处理。所以程序员信奉“简单——实用”主义。
也有不少做计算机“学问”的人颠倒行事。本来几句话、几行程序就能说明白的事，非得要抬高到理论创新的程度，写成玄乎的文章去评教授或者弄个博士学位。所幸在第一线工作的程序员大多是实干的。
三、爱憎分明
程序员大都喜欢技术挑战，不喜欢搞测试与维护。高水平的程序员喜欢与高水平的程序员一起工作，因为他们怕“与臭棋佬下棋，棋越下越臭”。程序员大都厌恶拉帮结派、耍政治手腕。不信，数一数你认识的程序员，有几个是党派人士？
四、工作单调但不乏味
有人问编程大师：“程序设计的真正含义是什么 ？”
大师回答说：“饿了的时候就吃，困的时候就睡，只要时机恰当就进行程序设计。”
其实程序员的生活和工作已融为一体，尽管单调却不乏味，还能独享孤独。有诗为证：
我编程三日
两耳不闻人声
只有硬盘在歌唱

结论：优秀的程序员没有理由不让人喜欢，他们远比怪僻来得可爱。
2.2 了 解 程 序 经 理

这里程序经理是指一支程序员队伍的领导者，不管他的职务是开发组长，项目经理，还是部门经理。程序经理是技术性的基层或中层干部，是软件企业得以发展的生力军。程序经理的选拔是不容草率的事。不象有些事业单位，只要政治口号喊得勤快、能左右逢缘不犯错误就可混个领导当当。也不象一些官僚机构，只有两个人的办公室也要设正主任和副主任。如果碰巧正主任姓傅，副主任姓郑，还会斗个没完没了。
在一个管理混乱的软件公司里，如果某个程序员能大喊大叫并且干劲十足，那他就能成为一名程序经理。微软公司在选择经理人员时，总是把他们的技术知识和运用技术去赚钱的能力放在首位。程序经理一般就是程序员队伍中最聪明的那个家伙。比尔·盖茨曾这样描述聪明人[Cusumano1996]：
聪明人一定反应敏捷，善于接受新事物。他能迅速进入一个新领域，给你一个头头是道的解释。他提出的问题往往一针见血、击中要害。他能及时掌握所学知识，并且博闻强记，他能把本来认为互不相干的领域联系在一起使问题得到解决。他富有创新精神与合作精神……
好的程序经理应该具备以下几个条件：
一、技术水平是程序员队伍中的最高级别
每个程序员骨子里头都有一股傲气，如果你不能技压群雄，他们就不会听你指挥。一个技术水平较差的人被任命为程序经理真是个悲剧，就象一个略有权势的太监，表面上有人对他点头哈腰，背后却被人鄙视。
二、能做最多且最难的工作
程序经理编程要快且好。别人要干一天的活，他半天就能做完，这样才会有精力去搞管理。程序经理应负责系统分析、系统设计这类最难的开发工作，并指导不同水平的程序员把各自的工作做好。如果人手不够，程序经理要能同时干几个人的活。
三、有人格魅力
软件开发是智力创作过程，你不能指望仅通过执行规章制度来产生好的作品。很多软件公司的程序经理都不是管理专业出身的，他们也不可能为了搞好管理而成天玩弄心机。技术出色的程序经理一般少有心术不正的，所以管理的重点应是“以身作则”、“公正待人”。如果程序经理在上班时趴在桌上睡觉，其他程序员也会这样干。如果程序经理发现有两个程序员趴在机器旁睡觉，不能只对其中一个大声吼叫：“你一编程就想睡觉，看看人家，在睡觉时都想着编程。”
如果管理者没有人格魅力，就没有人信服你，团队就不会有凝聚力，乌合之众不可能开发出优秀的软件。
结论：一个有活力的软件公司的各级经理都不会这样感叹，“因为我啥也不会干，所以只好当领导。”
2.3 程序员升为经理后是否还要编程

让我们先看看Microsoft公司的系统软件部门与应用软件部门的领导是怎样看待这个问题的[Cusumano1996]。Windows NT 3.0项目的软件经理娄·帕雷罗里让他手下的经理们像他一样每天花一半的时间编写代码：
我在组内制定了许多规则，其中最重要的一条是每个人都得编程，谁也别想坐在那儿发号施令……我发现管理者很容易失去目标，他们总是无法认识到问题的本质并且反应迟缓。如果你始终不放弃编写代码，你就能对项目的进展情况了如指掌，及时发现并解决问题……我大概每天花一半的时间编写代码并寻找项目的缺陷。
作为应用软件领域的经理，克里斯·彼得斯也持同样的看法。在他任Word项目总经理时就认为：
在一些大公司内部，各部门经理把具体操作的层次向下移。你一旦当上开发部门经理，很快就会以自己身居高位、日理万机为由放弃编程；同样地，开发小组的组长会以自己重任在肩而不愿编程；至于程序员也会觉得自己十分繁忙、分身无术而不再多编写程序。虽然我是270名员工的领导，似乎不再需要做什么具体的工作了，但我还是为Word新版本编写了一个特性。
程序员升为经理后一定要编程，这个道理已经说得很清楚了。最怕的是“虚心接受，坚决不做”；或者仅是做个样子，每天花一分钟时间编程，编译器还没运行完就关掉了。
2.4 经理与技术队伍的建设

如果是经营一个加工厂或一个饭店，经理们可以不必懂技术。因为他们的常识，以及通过耳闻目睹或者咨询都能解决实践中的问题。在软件领域，技术的力量是无穷的，一天之内就可使整个产业发生巨变。也许你在商业上很精明，但无法保证自己在技术浪潮中安然无恙。软件公司的各级经理最好既精通技术又懂管理。
一个出色的领导，加上一支技术过硬的队伍，才有可能创造业绩。不能光指望请来孙子或诸葛亮当教练，就能让弱不禁风的男足去捧世界杯。不少人总喜欢自吹中国人很聪明，最适合搞软件开发。可至今也没有做出几个很光彩的软件来，这与十三亿人口不呼应啊。新中国历来喜欢与可怜的印度相比较来展现丰富多彩的优越性，可是软件产业没法与人家比。工作在第一线的程序员与程序经理应该意识到：好兵好将都不是天生的，是后天练出来的；既要学会冷静地分析问题，又要充满激情地去工作。
软件公司总希望能物色到既精通技术又善长商业的优秀人才做经理。但已经出名了的优秀人才难以请到，也难以留住。所以把公司中的普通员工培养成为优秀人才是重要的举措。公司的老板不要对程序员抱有偏见，以为他们只配与机器打交道。一个高水平的程序员既然能学好数字逻辑，能理得清楚软件中很多象“嵌套”这类“鸡生蛋并且蛋又生了鸡”的错综复杂的关系，从理论上讲当个县长也不成问题。
现在很多女士不会烧菜，却能把菜的营养讲得头头是道。虽然这是个值得哀叹的社会问题，但我们应该有信心期待：如果她们非得天天烧菜不可，那么不久就能把菜烧得又好吃又有营养。许多程序员不懂商业，不是智力上的原因，主要是个人兴趣和环境所致。软件公司的老板应该这样鼓励有灵气的员工：“你能把技术做得那么棒，还怕搞不好管理？放心干吧！”的确，很多技术人员是在工作中领悟如何管理的，他们经过挫折与磨练，逐渐升为组长、项目经理，乃至成为公司重要的决策者。
优秀的程序员喜欢与优秀的程序员一起工作，这是一种理想的愿望。一个普通的软件公司不可能有非常多的优秀程序员，即便有，他们也不可能天天聚在一起干同一件事并且和睦得无法形容。中国自封建社会起就有喜好内斗的风俗习惯，几千年下来早已渗透到社会各个角落，那怕黄河水流断了，估计这民风也会延袭下去。要使程序员队伍稳健，必须有合理的等级制度来维护。等级制度并不限制自由和民主，它能让自以为聪明绝顶、谁也不服的人们懂得如何合作与奋斗。就象有了一架梯子，每个人才有机会爬上墙头摘下那向往已久的野花。当梯子散成一堆木棍时，只可能造就几个卖炭翁。
下面我们尝试着建立一个程序员队伍的等级制度。
把技术水平分为四级，第一级最低，第四级最高。第一级技术水平的程序员主要考核编程基本功，要求质量合格（他们主要来自刚毕业的大学生）。第二级技术水平的程序员编程质量要高，做过几个软件项目，有数年的工作经验，并能指导新手的工作。第三级技术水平的程序员主要考核系统分析与系统设计的能力，要求其技术有足够的深度和广度。第四级技术水平的程序员是成功的软件产品的设计师，他不仅技术超群，并且能使技术转化为有价值的商品。
把管理（这里仅指软件业务的管理，不考虑行政事务）水平也分成四级。第零级最低，第三级最高。第零级管理水平的人没有管理职务，就是普通员工。第一级管理水平的人是开发小组的组长，可带领几名程序员工作。第二级管理水平的人是项目经理。第三级管理水平的人决定某些产品是否要开发，以及如何去占领市场。
每个程序员都有明确的技术级别和管理级别。技术级别与管理级别有一定的联系。一般地，第一级技术水平的人只能做普通员工；第二级技术水平的人可以当一名组长；第三级技术水平的人可以当一名项目经理；第四级技术水平的人可成为公司产品的决策者。如图2.1所示。本书作者目前的技术水平当属第二级，管理水平符合组长的要求。作者在读中学和大学时就曾美滋滋地当过课代表，也就是组长级别。

2.5 向错误与失败学习

不管是生活或工作，人们都应该向错误与失败学习，目的是让我们在短暂的健康年华中少犯错误、少失败，多做几件正确的对社会有贡献的事。
导致软件项目失败的因素很多，如果不去找借口的话，就会发现错误的根源在自己身上：知识贫乏、才能低下、经验不足、骄傲自负……。我们必须正视自身的不足与缺点，才会学到经验教训。可人们常有太多的虚荣，为了克服心理障碍，白白浪费了很多本该用于创造的精力。
假设犯错误的人是诚实的并且是勤奋的。他愿意不带虚荣地改进自己。当这个人突然面对失败时，可能觉得自己一无是处，也许会不知所措，也许会病急乱投医。程序员都有一种共同的体会：在调试程序时，时常碰到只有十几行的程序竟会产生上百个编译错误；最后发现这么多的错误其实是由某一行程序错误引发的。当我们在工作中碰到挫折时，先要冷静地分析问题（事出有因哪），找出问题的内因与外因。内因是最主要的，应该予以最先解决。
前几年，中国出现了一个叫“FLG”的邪教，教徒达数百万之多，人民群众深受其害。不久前，全国的主要媒体对“FLG”进行连续数月的声讨与揭露。目睹了很多受害人的哭诉后，相信人们能够明白“FLG”是邪恶的、的。但在愤怒与心痛之余，我们不禁要反思：为什么那么多人轻信邪教？人们是否接受了教训？
在电视上看到很多人的确作了深刻的检讨：“我真是后悔啊，跟错了（FLG的头头）这个坏蛋，我对不起社会……。以后我一定要听党组织的话，党叫我干什么我就干什么，决不上坏人的当。”
我觉得这些受害人一点都没有醒悟：他只知道FLG是个邪教，并不知道自己为什么信了邪教。有些事情只要用脑袋去想一想就能分辨是非，可人们就是不去思考，却渴望能跟对“福星”，甘愿把自己的脑袋拴在别人的裤带上。难道这就是人民的纯朴与可爱吗？回顾一下历史，在“文革”时期，亿万人民跟着合法的党组织大干伤天害理的事，一干就是十多年哪！可见世界上哪个人哪个组织都不能确保绝对的英明。
所以说“迷信”是傻子碰到骗子的结果。傻是内因，被骗是外因。傻子碰到好人未必能做出好事，傻子碰到另一个骗子就会做出另一件傻事。为了不让自己“傻”，善良的人们应该用脑子去多学一些知识，努力让自己来把握命运，不要急着把一生托给某个人或某个组织。
软件人员在遭受项目失败并开始反省时，不要只是就事论事地仅把眼光锁在特定的项目上，吃一堑应该长好几个智才对。本书作者刚刚失败过，乐意乘热讲讲感受。
我在读本科和硕士研究生时，一直信奉“创造性的事业要靠激情来推动”。我把这个口号贴在办公室里，并扔掉物理学专业天天编程。在读硕士研究生的第一年，我卖出了第一份软件。到我读博士研究生的第一年，我心想事成地获得了全国大学生电脑大赛软件展示第一名。那时候我自以为翅膀已经硬了，再回顾前些年的艰苦，不禁有“媳妇熬成婆”的悲壮感觉。于是我在杭州这个小地方略作宣传，在1997年10月份开了一家软件公司。
我开始把“振兴民族软件产业”列入日程，并且提前担忧将来钱挣得太多用不完该怎么办。半年之后，我开始为软件产品作宣传，可并没有出现订单如潮、接应不暇的形势（事实上压根就没有反应）。我已经意识到市场没找对，但仍觉得软件中的技术很有价值，准备再开创“东方不亮西方亮”的新局面。于是我向只有一面之缘尚在北大方正工作的一位朋友求助。他是真真的软件高手，当我小心翼翼地展示约10万行C++代码的软件时，他竞在十几分钟内就指出多处重大的设计错误，使我目瞪口呆地意识到整个软件系统的价值为零。那种心痛啊，就象眼睁睁看着孩子被狼吃掉一样。
1998年10月，这位朋友再一次从北京飞到杭州，三下五除二替我把只活了一年的公司给关闭掉。他放心不下，觉得我“恶病需用猛药补”，于是意尤未尽地把我捉到北大方正插在他管辖的部门，让我学习怎样做事情。北京寒冷的冬天可以营造一种凄凉的气氛，冲去一切可以自我原谅的借口。我并不是太爱虚荣的人，知道这次失败是我的毛病积累到一定水准忍不住喷发出来的结果。我绝不能以年纪尚轻不太懂市场与管理为理由轻率地敷衍过去。我把自己察觉到的数十个毛病列出来，日后一个一个克服掉。……