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