软件工程实践者的思想(PDF格式)-第5部分
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
了。
项目经理是需要时间来成熟的。他需要有机会来承受
错误，而不是一开始就享受成功。
3。 做 ISO 质量体系的教训
Y 公司终于在 2001 年发现管理跟不上了，于是开始
① 软件工程中有专门的学科来研究项目的工期问题。学者们试图
寻找公式来计算项目的复杂度，从而计算出所需的工时和人月。
然而在实践中，这被认为是不可行的。
…29
…………………………………………………………Page 34……………………………………………………………
第 3 章 团队缺乏的不只是管理
引进 ISO 质量认证体系，希望通过这个体系来规范管理行
为，提高产品质量和对外的竞争力。
他们做得非常认真，把全公司的人员都调动起来了，
质量手册的论证做到了每一个员工；他们按照标准的软件
工程模型进行了开发流程的重组；每一份流程相关的材料
都约定了格式，并进行了归档说明；每一个环节都设定了
质量监督员来考核和回顾；……
接下来，他们开始实施。
三个月后，他们发现了一个问题：所有环节的质量监
督员是同一个人，他没有工程经验，于是他提出的问题总
是得不到工程负责人的确认。——很显然，没有工程负责
人愿意说自己这里存在问题：有问题就要改，就有可能中
断或者重新来过。再则这质量监督员也没有管理权限，于
是他即使确认了问题，也没有权利要求立即整改，工程负
责人随时可以以进度为由搁置这份监督报告。
再两三个月后，他们发现一切如旧，好象工作并没有
因为《质量手册》的存在而发生什么变化，在手册上被改
造的流程因为人力资源不充分而没有办法运作起来；绝大
多数应该书写的材料因为时间不够而被“候补”。
改变最大的是综合部，这里多了一个虚设的机构用于
分管 ISO 质量，综合部的经理也变成了分管质量的副总，
但又没有因此而多拿一分钱。改变最少的是开发部，其表
现为每个人的显示器顶上放了一本质量手册，用来挡住窗
口射进来的阳光，以及落向显示器的灰尘。
…30
…………………………………………………………Page 35……………………………………………………………
『大道至简』
两年之后，我们一群人来回顾这一次失败时，很多人
都说是“体制的问题”，说是原有的公司转型到新的公司，
不适合新的公司的管理体制以及对管理的要求。
其实这并不十分正确。体制的内涵是分两个方面的，
其一是“体”，即“体系”；其二是“制”，即“制度”。“ISO
质量体系”所产生的那份手册只是“制度”，在它的背后，
所要求的是对旧有“体系”的改变。——旧的公司转型到
新的公司，不是搬来一本“管理制度”给每个员工读一遍
就要可以的了。
在这一个转型期，第一要务是解决“体”的问题，也
就是“组织机构建设”的问题。如果把这个问题缩小到开
发部门的工程环节，
那么就是“如何组织
开发团队”的问题。
有 了 确 定 的 团 队 模
式，才能寻求相应的
管理制度，并且才能
把这样的制度实施在
团队之上。
汉 朝 的 刘 向 在
《新序·杂事二》中
记录了一个故事，说
是魏文侯出游，见路
人把羊皮统子毛向内
…31
…………………………………………………………Page 36……………………………………………………………
第 3 章 团队缺乏的不只是管理
皮朝外地反穿着，还背着一篓喂牲口的草。文侯奇怪地问
他为什么。这个人答道：我爱惜这件皮衣，怕毛被磨掉了。
文侯叹道：你难道不知道，如果皮被磨尽了，毛不也就掉
光了吗？
皮之不存，毛将焉附。没有确定的组织机构，又如何
能指望做出来的管理制度“合用”呢？
Y 公司在 1999 年至 2001 年一直保持着从 K 公司移
植过来的组织机构模式和管理模式，两年的组织机构建设
的时候被白白浪费了。本来，做 ISO 体系是最后一次弥补
组织机构建设的机会，然而在管理者还没有意识到“皮之
不存”的时候，Y 公司就连“毛”也都掉光了。
4。 谁动摇了你的制度？
组织模式确定的同时，相应的制度也有随之建立。很
少是有几年之后才来补制度的。
然而制度究竟决定了什么呢？我们先来看看，如果员
工在工作中出了纰漏：
） 没有制度，你没有办法和依据来惩戒员工，因此
是管理者的过失；
） 有了制度而没有惩戒他，是执行者和监督者的过
失；
） 一而再、再而三地犯错，又一而再、再而三地被
惩戒，那就是教而不改，就真正是员工的品性和
素质的问题了。
…32
…………………………………………………………Page 37……………………………………………………………
『大道至简』
因此，先做制度总是好的。至少在你选择做伏剑自刎
的李离之前，你还有机会把黑锅扔到出问题的员工的头
上。
对于一个已经规范管理、体制健全的公司，不容许员
工犯错是对的。即使是一次犯错，立即开除也说得过去。
但还是有前提的，这至少包括：
） 员工已经接受过相关的培训，这至少包括员工规
范和技术技能的学习
） 在该员工之前，相同的或者相关的错误没有被枉
纵
第一条是人性化的体现。中国人常说不知者不为过：
员工不知道，管理者也没有给他知道的条件，那怎么能说
是他的过错呢？如果因为不知道而出了问题，那管理者首
先应该自省才是。
第二条则是公平性的体现。不管是针对谁，制度都是
一样的，没有情面可讲的，常说的“特殊情况特殊处理”
在制度面前行不通。规矩一旦被破坏就形同虚设，反而被
员工作为笑柄，用来类比其它的制度。如此一来，整个的
制度也就离崩溃不远了。反过来，在已经被破坏了制度面
前，若再做杀鸡儆猴状，那猴子是被吓着了，不平声、怨
愤声也就跟着出来了。
因此最好的方法是赶紧修订制度，而不是修理人。
所以，经常的情况下，动摇了制度的人不是犯错的员
工，而是管理者自己。如果在制度面前，既做得到“人性
…33
…………………………………………………………Page 38……………………………………………………………
第 3 章 团队缺乏的不只是管理
化”，又做得到“公平性”，那么当管理者的便可以多做几
次黑脸的包龙图，而脖子上的脑袋便可以比李离顶得长久
一些。
5。 “那我们就开始开发吧”
现在，公司的组织机构和制度建设已经完成① 了，在
这个组织机构里，我们已经有了一个或者多个团队。接下
来，我们要真正的开始团队建设了。
这是任务。因为正在读书的你，和我一样，是要拉齐
七八杆枪，开始做工程的了。而在这一切开始之前，再之
前的时间里，我还想知道一件事：你知道如何做工程吗？
我们先来回顾一下。
前一章说的是编程，EN ，那实在简单，愚公式的工
作。我们先不管愚公们的水平如何，以及够不够勤快，反
正，他们会编程就是了。
上一章呢，说的是一部分懒人“创造”或“寻找”到
一些编程的方法。这些懒人们可能来源于做得太老的、或
者太累的愚公，或者是……一些看着愚公们着急，又被闲
出毛病了人。反正他们找了一些方法出来，而我们的愚公
们也已经学会了这些方法。
现在，有了会（ 比较快速地）编程的愚公，而且有了公
司，我们完成了组织机构建设，我们还找到了一名（或好
① 这里的“完成”是指告一段落，或者说是阶段性的结束了。完
成，并不等于完善。而完美，则更是无可企及。
…34
…………………………………………………………Page 39……………………………………………………………
『大道至简』
多名） 项目经理，他们一不怕死，二不怕苦……对了，更
为可喜的是我们还有了开发部：对内，我们订了一套规章
制度；对外，我们还拿到了项目单子。
“那我们就开始开发吧”——你就这样给我说。
很久以前，很久很久以前，人们都是这样做的。拿到
项目单子，然后“那我们就开始开发吧”。这样的事出现
得很自然，因为积极的愚公们总是有挖山不止的欲望。所
以他们一看到项目单子，第一个反应就是：那我们就开始
开发吧。
做了这么多年项目，我现在一听到这句话，就哆嗦。
6。 组织的学问：角色
现在先考察一下你的公司，在整个系统里面，有没有
这样的人：他既不归任何人管理，也不管理任何的他人。
如果有，那么就早早地把他开掉好了。
这样的人在组织机构中是一个盲点，或者空洞。按照
我的观点来看，他在组织中不担任任何的角色，既然“不
是角色”，那么当然要开掉。
在任何错误被归咎于员工之前，管理者应该先想想是
不是自己的问题。
是的。你可能很快发现问题出在了管理者。因为管理
者没有确定组织机构模式，或者没有为组织中的成员进行
…35
…………………………………………………………Page 40……………………………………………………………
第 3 章 团队缺乏的不只是管理
角色定位和分工。如果这样，出现“既不能令，又不受命”
的人就是必然的事了。
同样的道理，在工程开始“做”之前就得先把“角色”
确定好。——可能部分角色是组织机构相关的，例如“部
门经理”和“开发人员”；而有些就需要临时授命。
对于一个项目来说，第一个授命的人的当然是“项目
经理”。接下来的事件就复杂得多了。按照微软的惯例，
授命项目经理的同时，会有“产品经理”、“开发经理”、
“市场经理”以及“文档化和培训负责人”。这当然不表
明至少需要 5 个人才能构成团队，在大量角色从项目团队
中抽取与剥离后，我们可以得到一个精减的团队模型① （在
后面我会把它叫“R模型② ”）：
① 我非常不情愿给出一个模型来让读者跟随，但如果没有这样的
一个模型，我想接下来的讲述可能会令很多人如坠雾里。明确的
组织机构，既是团队的关键，也是我们思考问题的基础。
② 我试图找一个单词来表现这个模型的简单和粗糙。我得到的一
个建议是Rough（粗糙的） 。然而我更愿意溯源到这个单词在古英语
中的形态（Ruh） ，希望我这样一再强调，能让你真正地注意到：“R
模型”是一个原始而且粗糙的东西。
…36
…………………………………………………………Page 41……………………………………………………………
『大道至简』
更上层管理
品质部门 文档和培训 客服部门 市场部门
开发团队
开发经理
项目经理
开发人员
在保障这样一个组织机构模式的过程中，有几点是需
要注意的：
） 如果项目针对直接客户，而且没有产品化的可能
