按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
任。
一个人的开发行为可以成功，这取决于个人努力。大
家熟知的 KV100 、KV200 反病毒软件，最早就是王江民
先生一个人做出来的。二人小组如果能相互支撑，那也是
① 片面地理解成“三人为众”是不对的。“三”在这里是虚词，指
的是很多人的意思。然而，古人以“三”来泛指很多人或者群体，
则是很值得玩味的事。
…25
…………………………………………………………Page 30……………………………………………………………
第 3 章 团队缺乏的不只是管理
可以获得成功的，同样作为反病毒软件的 AV95 在 95 到
97 年成功占据反病毒软件市场之一隅，就是周辉和刘杰
先生两个人的作品。
然而到了三个人的时候呢，就得选个领导了。颜师古
为《汉书 ·高惠高后文功臣表序》作注时，引用了孟康的
话，说“取其功尤高者一人继之，於名为众”，简意就是
功高者代替群体受功。古人的受功当然包括封侯晋爵，因
此这便仿然成了惯例而推广开来，功劳大的、能力强的便
成了团队中的领导角色。
殊不知彼时彼事，目的并非要选领导，而是要表彰功
绩。项目结束会议上，总经理说：“M 项目完成得很好，
小 S 的进步尤其之大，他独立完成了全部核心代码的编
写，因此月奖加三倍”。奖不可谓不丰，然而这并不代表
在下一个项目该让小 S 来做项目经理。
同样，三板斧定了瓦岗寨的程咬金，功不可谓不高，
技不可谓不强。但程咬金不是将帅之才。
做管理起码需要能承担责任，这是最基本的素质。
《史记·循吏列传》记载了李离伏剑的故事。春秋时
晋国最高司法长官李离，因为“过听杀人”，断狱失误，
把一个不该处死的人错判了死刑。随后“自拘于廷，请死
于君”，晋文公欲以其下属有过为由免他的罪，而李离说：
“臣居官为长，不与吏让位；受禄为多，不与下分利。
今过听杀人，傅其罪下吏，非所闻也。”
随后拔剑自杀了。
…26
…………………………………………………………Page 31……………………………………………………………
『大道至简』
同样的道理，你的项目经理职位又没有让给别人做，
你拿的经理级工资又没有分给别人，那项目失败了，你为
什么要把责任推到别人头上呢？
三人团队中的那个领导，不是要程咬金一样的牛人，
而是要李离一样的死士。项目完成不了，切脑袋的事倒不
必做，递交辞呈的那点勇气总是要有的。
2。 做项目 = 死亡游戏 ？
如果项目做不成就要掉脑袋，那就象好比是枕着铡刀
在做程序；如果项目失败就要交辞呈，那可能就从来不会
有项目经理。
为什么这么说呢？
…27
…………………………………………………………Page 32……………………………………………………………
第 3 章 团队缺乏的不只是管理
从管理角度来看，项目失败与否与项目经理的经验直
接相关。我曾经听过一个来自澳大利亚的讲师说软件工
程。她说到项目的成功是两个方面的评估：
） 项目完成质量
） 项目完成时间
由于项目的时间是在项目前期对项目工期的设定，因
此我问这个讲师：什么方法能保证预期的工期是正确的，
或者说是可以完成的。
讲师的回答很有意思：经验丰富的工程师能尽可能接
…28
…………………………………………………………Page 33……………………………………………………………
『大道至简』
近地预估工期，但没有办法保障（预估的）工期是绝对合理
①
的 。
那么进一步的推论是，由于没有绝对合理的工期，所
以项目的完成时间可能总是被进度变更所修正，所以项目
也就总是不能“成功”。
——看来外来的和尚（ 包括尼姑） 也未必能比本地的
更会念经。在这一点上，来自澳大利亚的讲师，与来自北
极的爱斯基摩人（如果他们也念经的话） 如出一辙。
项目工期的问题不能解决，就不能保证项目成功。只
有经验更加丰富，才能更尽可能地逼近“合理的工期”。
因此在此之前，项目经理面临的就是失败。这个失败可能
不是项目经理本身能力所决定，或者也不是团队成员的工
作所决定，而是在一开始，那份给客户的项目协议就签错
了。
项目经理是需要时间来成熟的。他需要有机会来承受
错误，而不是一开始就享受成功。
3。 做 ISO 质量体系的教训
Y 公司终于在 2001 年发现管理跟不上了，于是开始
① 软件工程中有专门的学科来研究项目的工期问题。学者们试图
寻找公式来计算项目的复杂度，从而计算出所需的工时和人月。
然而在实践中，这被认为是不可行的。
…29
…………………………………………………………Page 34……………………………………………………………
第 3 章 团队缺乏的不只是管理
引进 ISO 质量认证体系，希望通过这个体系来规范管理行
为，提高产品质量和对外的竞争力。
他们做得非常认真，把全公司的人员都调动起来了，
质量手册的论证做到了每一个员工；他们按照标准的软件
工程模型进行了开发流程的重组；每一份流程相关的材料
都约定了格式，并进行了归档说明；每一个环节都设定了
质量监督员来考核和回顾；……
接下来，他们开始实施。
三个月后，他们发现了一个问题：所有环节的质量监
督员是同一个人，他没有工程经验，于是他提出的问题总
是得不到工程负责人的确认。——很显然，没有工程负责
人愿意说自己这里存在问题：有问题就要改，就有可能中
断或者重新来过。再则这质量监督员也没有管理权限，于
是他即使确认了问题，也没有权利要求立即整改，工程负
责人随时可以以进度为由搁置这份监督报告。
再两三个月后，他们发现一切如旧，好象工作并没有
因为《质量手册》的存在而发生什么变化，在手册上被改
造的流程因为人力资源不充分而没有办法运作起来；绝大
多数应该书写的材料因为时间不够而被“候补”。
改变最大的是综合部，这里多了一个虚设的机构用于
分管 ISO 质量，综合部的经理也变成了分管质量的副总，
但又没有因此而多拿一分钱。改变最少的是开发部，其表
现为每个人的显示器顶上放了一本质量手册，用来挡住窗
口射进来的阳光，以及落向显示器的灰尘。
…30
…………………………………………………………Page 35……………………………………………………………