 |
相關閱讀 |
大道至简——软件工程实践者的思想 第3章 团队缺乏的不只是管理
|
>>> 讀書—連接古今充實信仰 >>> | 簡體 傳統 |
第3章 团队缺乏的不只是管理
“言人三为众，虽难尽继，取其功尤高者一人继之，於名为众矣。”
——《汉书高惠高后文功臣表序》颜师古注
1. 三个人的团队
《汉书》中说“言人三为众①”，是指三个人就算得上是“众”了。这里的“众”应该理解成一个群体，亦或者说是一个团队。
团队是至少以三个人为规模的。这有其合理性。为什么呢？首先一个人算不得团队，那是个体。两个人则互相支撑，古文中“从”字是二人互立，就是这个意思。然而二人互立并不算团队，因为没有监督。三个人便可以构成团队，这样便有了团队的一些基本特性：主从、监督和责任。
一个人的开发行为可以成功，这取决于个人努力。大家熟知的 KV100、KV200 反病毒软件，最早就是王江民先生一个人做出来的。二人小组如果能相互支撑，那也是可以获得成功的，同样作为反病毒软件的 AV95 在 95 到97 年成功占据反病毒软件市场之一隅，就是周辉和刘杰先生两个人的作品。
① 片面地理解成“三人为众”是不对的。“三”在这里是虚词，指的是很多人的意思。然而，古人以“三”来泛指很多人或者群体，则是很值得玩味的事。
然而到了三个人的时候呢，就得选个领导了。颜师古为《汉书高惠高后文功臣表序》作注时，引用了孟康的话，说“取其功尤高者一人继之，於名为众”，简意就是功高者代替群体受功。古人的受功当然包括封侯晋爵，因此这便仿然成了惯例而推广开来，功劳大的、能力强的便成了团队中的领导角色。
殊不知彼时彼事，目的并非要选领导，而是要表彰功
绩。项目结束会议上，总经理说：“M 项目完成得很好，
小 S 的进步尤其之大，他独立完成了全部核心代码的编
写，因此月奖加三倍”。奖不可谓不丰，然而这并不代表
在下一个项目该让小 S 来做项目经理。
同样，三板斧定了瓦岗寨的程咬金，功不可谓不高，
技不可谓不强。但程咬金不是将帅之才。
做管理起码需要能承担责任，这是最基本的素质。
《史记循吏列传》记载了李离伏剑的故事。春秋时
晋国最高司法长官李离，因为“过听杀人”，断狱失误，
把一个不该处死的人错判了死刑。随后“自拘于廷，请死
于君”，晋文公欲以其下属有过为由免他的罪，而李离说：
“臣居官为长，不与吏让位；受禄为多，不与下分利。
今过听杀人，傅其罪下吏，非所闻也。”
随后拔剑自杀了。
同样的道理，你的项目经理职位又没有让给别人做，
你拿的经理级工资又没有分给别人，那项目失败了，你为
什么要把责任推到别人头上呢？
三人团队中的那个领导，不是要程咬金一样的牛人，
而是要李离一样的死士。项目完成不了，切脑袋的事倒不
必做，递交辞呈的那点勇气总是要有的。
2. 做项目 = 死亡游戏 ?
如果项目做不成就要掉脑袋，那就象好比是枕着铡刀
在做程序；如果项目失败就要交辞呈，那可能就从来不会
有项目经理。
为什么这么说呢？
从管理角度来看，项目失败与否与项目经理的经验直
接相关。我曾经听过一个来自澳大利亚的讲师说软件工
程。她说到项目的成功是两个方面的评估：
项目完成质量
项目完成时间
由于项目的时间是在项目前期对项目工期的设定，因
此我问这个讲师：什么方法能保证预期的工期是正确的，
或者说是可以完成的。
讲师的回答很有意思：经验丰富的工程师能尽可能接
-28-
『大道至简』
近地预估工期，但没有办法保障(预估的)工期是绝对合理
的①。
那么进一步的推论是，由于没有绝对合理的工期，所
以项目的完成时间可能总是被进度变更所修正，所以项目
也就总是不能“成功”。
——看来外来的和尚(包括尼姑)也未必能比本地的
更会念经。在这一点上，来自澳大利亚的讲师，与来自北
极的爱斯基摩人(如果他们也念经的话)如出一辙。
项目工期的问题不能解决，就不能保证项目成功。只
有经验更加丰富，才能更尽可能地逼近“合理的工期”。
因此在此之前，项目经理面临的就是失败。这个失败可能
不是项目经理本身能力所决定，或者也不是团队成员的工
作所决定，而是在一开始，那份给客户的项目协议就签错
了。
项目经理是需要时间来成熟的。他需要有机会来承受
错误，而不是一开始就享受成功。
3. 做 ISO 质量体系的教训
Y 公司终于在 2001 年发现管理跟不上了，于是开始
① 软件工程中有专门的学科来研究项目的工期问题。学者们试图
寻找公式来计算项目的复杂度，从而计算出所需的工时和人月。
然而在实践中，这被认为是不可行的。
引进 ISO 质量认证体系，希望通过这个体系来规范管理行
为，提高产品质量和对外的竞争力。
他们做得非常认真，把全公司的人员都调动起来了，
质量手册的论证做到了每一个员工；他们按照标准的软件
工程模型进行了开发流程的重组；每一份流程相关的材料
都约定了格式，并进行了归档说明；每一个环节都设定了
质量监督员来考核和回顾；……
接下来，他们开始实施。
三个月后，他们发现了一个问题：所有环节的质量监
督员是同一个人，他没有工程经验，于是他提出的问题总
是得不到工程负责人的确认。——很显然，没有工程负责
人愿意说自己这里存在问题：有问题就要改，就有可能中
断或者重新来过。再则这质量监督员也没有管理权限，于
是他即使确认了问题，也没有权利要求立即整改，工程负
责人随时可以以进度为由搁置这份监督报告。
再两三个月后，他们发现一切如旧，好象工作并没有
因为《质量手册》的存在而发生什么变化，在手册上被改
造的流程因为人力资源不充分而没有办法运作起来；绝大
多数应该书写的材料因为时间不够而被“候补”。
改变最大的是综合部，这里多了一个虚设的机构用于
分管 ISO 质量，综合部的经理也变成了分管质量的副总，
但又没有因此而多拿一分钱。改变最少的是开发部，其表
现为每个人的显示器顶上放了一本质量手册，用来挡住窗
口射进来的阳光，以及落向显示器的灰尘。
两年之后，我们一群人来回顾这一次失败时，很多人
都说是“体制的问题”，说是原有的公司转型到新的公司，
不适合新的公司的管理体制以及对管理的要求。
其实这并不十分正确。体制的内涵是分两个方面的，
其一是“体”，即“体系”；其二是“制”，即“制度”。“ISO
质量体系”所产生的那份手册只是“制度”，在它的背后，
所要求的是对旧有“体系”的改变。——旧的公司转型到
新的公司，不是搬来一本“管理制度”给每个员工读一遍
就要可以的了。
在这一个转型期，第一要务是解决“体”的问题，也
就是“组织机构建设”的问题。如果把这个问题缩小到开
发部门的工程环节，
那么就是“如何组织
开发团队”的问题。
有 了 确 定 的 团 队 模
式，才能寻求相应的
管理制度，并且才能
把这样的制度实施在
团队之上。
汉 朝 的 刘 向 在
《新序·杂事二》中
记录了一个故事，说
是魏文侯出游，见路
人把羊皮统子毛向内
皮朝外地反穿着，还背着一篓喂牲口的草。文侯奇怪地问
他为什么。这个人答道：我爱惜这件皮衣，怕毛被磨掉了。
文侯叹道：你难道不知道，如果皮被磨尽了，毛不也就掉
光了吗？
皮之不存，毛将焉附。没有确定的组织机构，又如何
能指望做出来的管理制度“合用”呢？
Y 公司在 1999 年至 2001 年一直保持着从 K 公司移
植过来的组织机构模式和管理模式，两年的组织机构建设
的时候被白白浪费了。本来，做 ISO 体系是最后一次弥补
组织机构建设的机会，然而在管理者还没有意识到“皮之
不存”的时候，Y 公司就连“毛”也都掉光了。
4. 谁动摇了你的制度？
组织模式确定的同时，相应的制度也有随之建立。很
少是有几年之后才来补制度的。
然而制度究竟决定了什么呢？我们先来看看，如果员
工在工作中出了纰漏：
没有制度，你没有办法和依据来惩戒员工，因此
是管理者的过失；
有了制度而没有惩戒他，是执行者和监督者的过
失；
一而再、再而三地犯错，又一而再、再而三地被
惩戒，那就是教而不改，就真正是员工的品性和
素质的问题了。
因此，先做制度总是好的。至少在你选择做伏剑自刎
的李离之前，你还有机会把黑锅扔到出问题的员工的头
上。
对于一个已经规范管理、体制健全的公司，不容许员
工犯错是对的。即使是一次犯错，立即开除也说得过去。
但还是有前提的，这至少包括：
员工已经接受过相关的培训，这至少包括员工规
范和技术技能的学习
在该员工之前，相同的或者相关的错误没有被枉
纵
第一条是人性化的体现。中国人常说不知者不为过：
员工不知道，管理者也没有给他知道的条件，那怎么能说
是他的过错呢？如果因为不知道而出了问题，那管理者首
先应该自省才是。
第二条则是公平性的体现。不管是针对谁，制度都是
一样的，没有情面可讲的，常说的“特殊情况特殊处理”
在制度面前行不通。规矩一旦被破坏就形同虚设，反而被
员工作为笑柄，用来类比其它的制度。如此一来，整个的
制度也就离崩溃不远了。反过来，在已经被破坏了制度面
前，若再做杀鸡儆猴状，那猴子是被吓着了，不平声、怨
愤声也就跟着出来了。
因此最好的方法是赶紧修订制度，而不是修理人。
所以，经常的情况下，动摇了制度的人不是犯错的员
工，而是管理者自己。如果在制度面前，既做得到“人性
化”，又做得到“公平性”，那么当管理者的便可以多做几
次黑脸的包龙图，而脖子上的脑袋便可以比李离顶得长久
一些。
5. “那我们就开始开发吧”
现在，公司的组织机构和制度建设已经完成①了，在
这个组织机构里，我们已经有了一个或者多个团队。接下
来，我们要真正的开始团队建设了。
这是任务。因为正在读书的你，和我一样，是要拉齐
七八杆枪，开始做工程的了。而在这一切开始之前，再之
前的时间里，我还想知道一件事：你知道如何做工程吗？
我们先来回顾一下。
前一章说的是编程，EN，那实在简单，愚公式的工
作。我们先不管愚公们的水平如何，以及够不够勤快，反
正，他们会编程就是了。
上一章呢，说的是一部分懒人“创造”或“寻找”到
一些编程的方法。这些懒人们可能来源于做得太老的、或
者太累的愚公，或者是……一些看着愚公们着急，又被闲
出毛病了人。反正他们找了一些方法出来，而我们的愚公
们也已经学会了这些方法。
现在，有了会(比较快速地)编程的愚公，而且有了公
司，我们完成了组织机构建设，我们还找到了一名(或好
① 这里的“完成”是指告一段落，或者说是阶段性的结束了。完
成，并不等于完善。而完美，则更是无可企及。
多名)项目经理，他们一不怕死，二不怕苦……对了，更
为可喜的是我们还有了开发部：对内，我们订了一套规章
制度；对外，我们还拿到了项目单子。
“那我们就开始开发吧”——你就这样给我说。
很久以前，很久很久以前，人们都是这样做的。拿到
项目单子，然后“那我们就开始开发吧”。这样的事出现
得很自然，因为积极的愚公们总是有挖山不止的欲望。所
以他们一看到项目单子，第一个反应就是：那我们就开始
开发吧。
做了这么多年项目，我现在一听到这句话，就哆嗦。
6. 组织的学问：角色
现在先考察一下你的公司，在整个系统里面，有没有
这样的人：他既不归任何人管理，也不管理任何的他人。
如果有，那么就早早地把他开掉好了。
这样的人在组织机构中是一个盲点，或者空洞。按照
我的观点来看，他在组织中不担任任何的角色，既然“不
是角色”，那么当然要开掉。
在任何错误被归咎于员工之前，管理者应该先想想是
不是自己的问题。
是的。你可能很快发现问题出在了管理者。因为管理
者没有确定组织机构模式，或者没有为组织中的成员进行
-35-
第 3 章 团队缺乏的不只是管理
角色定位和分工。如果这样，出现“既不能令，又不受命”
的人就是必然的事了。
同样的道理，在工程开始“做”之前就得先把“角色”
确定好。——可能部分角色是组织机构相关的，例如“部
门经理”和“开发人员”；而有些就需要临时授命。
对于一个项目来说，第一个授命的人的当然是“项目
经理”。接下来的事件就复杂得多了。按照微软的惯例，
授命项目经理的同时，会有“产品经理”、“开发经理”、
“市场经理”以及“文档化和培训负责人”。这当然不表
明至少需要 5 个人才能构成团队，在大量角色从项目团队
中抽取与剥离后，我们可以得到一个精减的团队模型①（在
后面我会把它叫“R模型②”）：
① 我非常不情愿给出一个模型来让读者跟随，但如果没有这样的
一个模型，我想接下来的讲述可能会令很多人如坠雾里。明确的
组织机构，既是团队的关键，也是我们思考问题的基础。
② 我试图找一个单词来表现这个模型的简单和粗糙。我得到的一
个建议是Rough(粗糙的)。然而我更愿意溯源到这个单词在古英语
中的形态(Ruh)，希望我这样一再强调，能让你真正地注意到：“R
模型”是一个原始而且粗糙的东西。
更上层管理
品质部门 文档和培训 客服部门 市场部门
开发团队
开发经理
项目经理
开发人员
在保障这样一个组织机构模式的过程中，有几点是需
要注意的：
如果项目针对直接客户，而且没有产品化的可能
性(或必要性)，那么可以将与市场(以及市场部门)
相关的问题和角色先暂时放在一边。
已经存在于开发团队中的成员，不适合在品质部
门中兼任角色。
项目经理应致力于减少团队中开发角色与其它
部门的沟通，必要时开发经理应该站在开发人员
之前进行部门间的交互。
品质部门、文档和培训部门和客服部门应该主要
由有专门培训的人员构成，尽管开发人员可以
(或者经常会)参与文档、培训和客服工作，但这
也通常是他们最不能胜任的角色。
这是中小型规模的公司和团队的参考组织机构模型，
对大型团队并不适用。
在这个模型中，我们仍然看到了一个至少由三个人构
成团队。其中，在开发经理和开发人员之间，既存在主从
关系，也存在协作关系。而项目经理，则在团队中处于领
导者、组织者和团队保障者的地位。
如果非得要精简到两个角色的团队模式，那么这种情
况下，通常是开发经理兼任项目经理，因此这位开发经理
一定要能清楚地区分这种双层角色的身份：在任何时候，
明确自己是在进行“团队内协作”、还是“团队管理(和组
织)”、还是在与“团队外交流”。
如果这个开发经理总是混淆自己的角色，那么，我建
议，换人吧。
7. 跟随蚂蚁。但不要栽进蚂蚁洞里。
团队真的需要管理吗？
这经常是“经营”开发团队的管理者最容易给错答案
的问题。这些管理者兢兢业业，试图细化每一个管理环节，
将自己的意愿贯彻到……EN，CPU 里去。
实际上，开发团队并不需管理。或者说，在你还没有
弄清楚状况之前，不要去管它。
温伯格(Gerald M. Weinberg)在“给软件开发经理的建
议”中提到了这样一个问题：开发经理如何面对一个并非
由他亲自雇佣成员的团队。温伯格的回答是：
与成员面谈，让他们签约受雇于你；
或者，解聘他们；
再或者，放弃这个职位。
温伯格的意思是“没办法管就不管”。温伯格当然可
以有更多的选择，他总可以找到适合自己管的公司。然而
目前，你可能是唯一的人选。或者你原本就期待这个角色
很久了，当然不能象温伯格一样放弃。
你得找办法来解决团队问题。
“签约”这样的事，在大多数环境下是行不通的。要
知道，既然他们与公司的签约保证不了他们工作的质量，
同样与你的这份签约也不会。协议并不能建立管理者与被
管理者的信任，而只是确保了这种关系。
但是你应该相信我，在你接手这个团队之前，上一任
经理也确保了这种关系。然而团队失败了，否则不会换作
是你。
所以告诉团队成员“现在轮到我管理你们了”，根本
就是一句废话。或者在你来之前，他们就已经知道你要来
了。
小的时候，我就喜欢观察蚂蚁。我喜欢看它们成群结
队地搬着东西穿过小路，或者水沟。我尝试用木棍导引它
们改变行动的路线，然而不久之后，它们就会翻过那根木
棍，按照既定的路线行进。
禀性难移，要改变一个人都难，何况是改变一个团队
的既定习惯。
如果有一群开发人员象蚂蚁一样辛勒地工作着，那
么，先不要打扰他们。你应该跟随他们，看看他们是如何
做的。发现规律，分析这个规律的价值，最后再尝试改变
它们(的一些负面价值的规律)。
所以你要紧紧地跟随他们。——除了一个地方。那地
方是你去不得的，那就是蚂蚁洞。
显然，你不是开发者，你是管理人员。所以尽管你是
团队中的角色，但千万记得离蚂蚁洞远点。你在洞外张望，
可以发现问题；你在洞内，就只有做“循规蹈矩”的蚂蚁。
管理者是那个可以在洞外放木棍的人。
8. “什么是增值税发票？”
现在你已经足够地观察了你的团队，你知道这个团队
存在问题，你也知道你需要改变。当然，你也知道这种改
变并不是放一根木棍那么简单。
你已经确定了组织结构，确定了组织中的角色，还有
了一个团队(5 个？或者 10 个？)的人。所以作为项目经理，
你需要先分工。
在分工之前，那个团队只能算是一个没有组织与合作
的群体(所以英文中群是 Group，而开发团队是 Team)。
被优先考虑的是弹性分工。每一个人都被要求做一颗
革命的螺丝钉，哪里需要哪里拧。所以弹性分工总是被放
在企业节省人力资本的第一要务上。然而我们真的会做弹
性分工吗？
蚂蚁的分工模式之一就是弹性分工。一只蚂蚁搬食物
往回走时，碰到下一只蚂蚁，会把食物交给它，自己再回
头；碰到上游的蚂蚁时，将食物接过来，再交给下一只蚂
蚁。蚂蚁要在哪个位置换手不一定，唯一固定的是起始点
和目的地。
确定被“弹性分工”的员工需要可以快速地转换到新
的角色，但首要考察的并不是他是否“有能力”胜任这个
角色。能力可以通过学习来增强，而角色的转换，则首先
是思想的转换。
1997 年，P&J 的公司打算全面拓展市场，我随他一
起到了成都。当时我是开发部的三个主力开发人员之一，
因此在原定计划里，我是到成都组建西南区开发部(或技
术中心)。然而在两周之后，P&J 发现总公司的运作存在
问题，因此他必须回郑州。P&J 决定将成都市场的问题全
权交给我，换而言之，我必须出任成都办事处经理。
我对市场一窍不通，也不懂得公司的经营与管理。但
很明显，做办事处经理不是做技术，这与我(当时的)个人
意愿是相背的。于是我拒而不受。理由也很充分：我不会
做市场。
P&J 用了两天的时间来说服我，直到在临回郑州的前
一晚我仍未能接受这个任命。这时他告诉我：即使是做开
发，也是需要了解市场的，你必须知道用户想要什么，你
必须理解你的客户。因此你如果想要做一个好的开发人
-41-
第 3 章 团队缺乏的不只是管理
员，你应该正视这次机会。
我沉默了许久。我想明白了两件事：从公司的角度上，
我必须接受这个职务；从个人的角度上，我需要接受这个
职务。于是，我问了我的第一个问题：“什么是增值税发
票？”
P&J 笑了。接下来我们开始讨论经营问题。第二天
P&J 飞回郑州。五个月后我升任西南区总经理，一年后，
西南区做到六个分区市场中业绩第二。此后我辞职回到郑
州，再一次从开发人员做起。
“什么是增值税发票？”意味着从技术到经营的角色转变。这个问题本身带来的并不是能力的提升，但如果我提不出这个问题，我将没有可能理解经营与市场。
尽管弹性分工非常有效，然而真正做弹性分工却并非易事。蚂蚁的角色转换是本能的，而 P&J 却不得不花两天时间来说服我。因而更应当留意团队成员“自激”式的角色转换，知道他是不是真的想(而不是需要)转变一下角色，这样起码可以省去你两天的功夫。
然而能提问“什么是增值税发票”的愚公毕竟不是太多，大多数时候他们在“箕畚运于渤海之尾”，如果实在闲得厉害，他们可能会去发明翅膀，而不是思考“什么是增值税发票？”
更好的选择是明确分工，而不是弹性分工。你应该明白，重要角色的更替通常是极具风险的，例如项目经理或者开发经理；频繁的开发人员的调度也会直接影响到工程的质量和进度。
如果所有人都在思考“什么是增值税发票”，那么你的组织机构将立即溃散。
因此，明确分工是你的管理职责。做管理≠做伯乐。
周爱民(Aimingoo) 2013-08-24 22:16:32
評論集
暫無評論。
稱謂：
内容：
驗證：
返回列表