正文

[编程思想]大道至简--团队缺乏的不只是管理(强烈推荐) 2006-08-11 14:16:00

【评论】 【打印】 【字体: 】 本文链接:http://blog.pfan.cn/fengfei/17484.html

分享到:

                       第3章  团队缺乏的不只是管理 


            “言人三为众,虽难尽继,取其功尤高者一人继之,於名为众矣。”
                           ——《汉书·高惠高后文功臣表序》颜师古注


1.  三个人的团队 


           《汉书》中说“言人三为众 ”,是指三个人就算得上是“众”了。这里的“众”应该理解成一个群体,亦或者说是一个团队。 


             团队是至少以三个人为规模的。这有其合理性。为什么呢?首先一个人算不得团队,那是个体。两个人则互相支撑,古文中“从”字是二人互立,就是这个意思。然而二人互立并不算团队,因为没有监督。三个人便可以构成团队,这样便有了团队的一些基本特性:主从、监督和责任。

           一个人的开发行为可以成功,这取决于个人努力。大家熟知的 KV100、KV200 反病毒软件,最早就是王江民先生一个人做出来的。二人小组如果能相互支撑,那也是可以获得成功的,同样作为反病毒软件的 AV95 在 95 到97 年成功占据反病毒软件市场之隅,就是周辉和刘杰先生两个人的作品。
 
            然而到了三个人的时候呢,就得选个领导了。颜师古为《汉书·高惠高后文功臣表序》作注时,引用了孟康的话,说“取其功尤高者一人继之,於名为众”,简意就是功者代替群体受功。古人的受功当然包括封侯晋爵,因此这便仿然成了惯例而推广开来,功劳大的、能力强的便成了团队中的领导角色。


            殊不知彼时彼事,目的并非要选领导,而是要表彰功绩。项目结束会议上,总经理说:“M 项目完成得很好,小 S 的进步尤其之大,他独立完成了全部核心代码的编写,因此月奖加三倍”。奖不可谓不丰,然而这并不代表在下一个项目该让小 S 来做项目经理。


           同样,三板斧定了瓦岗寨的程咬金,功不可谓不高,技不可谓不强。但程咬金不是将帅之才。

           做管理起码需要能承担责任,这是最基本的素质。 《史记·循吏列传》记载了李离伏剑的故事。春秋时晋国最高司法长官李离,因为“过听杀人”,断狱失误,把一个不该处死的人错判了死刑。随后“自拘于廷,请死于君”,晋文公欲以其下属有过为由免他的罪,而李离说: 


          “臣居官为长,不与吏让位;受禄为多,不与下分利。今过听杀人,傅其罪下吏,非所闻也。”


           随后拔剑自杀了。

           同样的道理,你的项目经理职位又没有让给别人做,你拿的经理级工资又没有分给别人,那项目失败了,你为什么要把责任推到别人头上呢?
 
            三人团队中的那个领导,不是要程咬金一样的牛人,而是要李离一样的死士。项目完成不了,切脑袋的事倒不必做,递交辞呈的那点勇气总是要有的。


2.  做项目 =  死亡游戏 ?


            如果项目做不成就要掉脑袋,那就象好比是枕着铡刀在做程序;如果项目失败就要交辞呈,那可能就从来不会有项目经理。


           为什么这么说呢?

           从管理角度来看,项目失败与否与项目经理的经验直接相关。我曾经听过一个来自澳大利亚的讲师说软件工程。她说到项目的成功是两个方面的评估:   项目完成质量   项目完成时间 由于项目的时间是在项目前期对项目工期的设定,因此我问这个讲师:什么方法能保证预期的工期是正确的,或者说是可以完成的。


           讲师的回答很有意思:经验丰富的工程师能尽可能接近地预估工期,但没有办法保障(预估的)工期是绝对合理的 。

            那么进一步的推论是,由于没有绝对合理的工期,所以项目的完成时间可能总是被进度变更所修正,所以项目也就总是不能“成功”。


            ——看来外来的和尚(包括尼姑)也未必能比本地的更会念经。在这一点上,来自澳大利亚的讲师,与来自北极的爱斯基摩人(如果他们也念经的话)如出一辙。
 
             项目工期的问题不能解决,就不能保证项目成功。只有经验更加丰富,才能更尽可能地逼近“合理的工期”。因此在此之前,项目经理面临的就是失败。这个失败可能不是项目经理本身能力所决定,或者也不是团队成员的工作所决定,而是在一开始,那份给客户的项目协议就签错了。
 
            项目经理是需要时间来成熟的。他需要有机会来承受错误,而不是一开始就享受成功。

3.  做 ISO 质量体系的教训


            Y 公司终于在 2001 年发现管理跟不上了,于是开始引进 ISO 质量认证体系,希望通过这个体系来规范管理行为,提高产品质量和对外的竞争力。


            他们做得非常认真,把全公司的人员都调动起来了,质量手册的论证做到了每一个员工;他们按照标准的软件工程模型进行了开发流程的重组;每一份流程相关的材料都约定了格式,并进行了归档说明;每一个环节都设定了质量监督员来考核和回顾;


           接下来,他们开始实施。


           三个月后,他们发现了一个问题:所有环节的质量监督员是同一个人,他没有工程经验,于是他提出的问题总是得不到工程负责人的确认。——很显然,没有工程负责人愿意说自己这里存在问题:有问题就要改,就有可能中断或者重新来过。再则这质量监督也没有管理权限,于是他即使确认了问题,也没有权利要求立即整改,工程负责人随时可以以进度为由搁置这份监督报告。

            再两三个月后,他们发现一切如旧,好象工作并没有因为《质量手册》的存在而发生什么变化,在手册上被改造的流程因为人力资源不充分而没有办法运作起来;绝大多数应该书写的材料因为时间不够而被“候补”。 


            改变最大的是综合部,这里多了一个虚设的机构用于分管 ISO 质量,综合部的经理也变成了分管质量的副总,但又没有因此而多拿一分钱。改变最少的是开发部,其表现为每个人的显示器顶上放了一本质量手册,用来挡住窗口射进来的阳光,以及落向显示器的灰尘。

             两年之后,我们一群人来回顾这一次失败时,很多人都说是“体制的问题”,说是原有的公司转型到新的公司,不适合新的公司的管理体制以及对管理的要求。 其实这并不十分正确。体制的内涵是分两个方面的,其一是“体”,即“体系”;其二“制”,即“制度”。“ISO质量体系”所产生的那份手册只是“制度”,在它的背后,所要求的是对旧有“体系”的改变。——旧的公司转型到新的公司,不是搬来一本“管理制度”给每个员工读一遍就要可以的了。

 
            在这一个转型期,第一要务是解决“体”的问题,也就是“组织机构建设”的问题。如果把这个问题缩小到开发部门的工程环节,那么就是“如何组织开发团队”的问题。有了确定的团队模式,才能寻求相应的管理制度,并且才能把这样的制度实施在团队之上。

            汉朝的刘向在《新序·杂事二》中记录了一个故事,说是魏文侯出游,见路人把羊皮统子毛向内皮朝外地反穿着,还背着一篓喂牲口的草。文侯奇怪地问他为什么。这个人答道:我爱惜这件皮衣,怕毛被磨掉了。文侯叹道:你难道不知道,如果皮被磨尽了,毛不也就掉光了吗?

             皮之不存,毛将焉附。没有确定的组织机构,又如何能指望做出来的管理制度“合用”呢?


             Y 公司在 1999 年至 2001 年一直保持着从 K 公司移植过来的组织机构模式和理模式,两年的组织机构建设的时候被白白浪费了。本来,做 ISO 体系是最后一次弥补组织机构建设的机会,然而在管理者还没有意识到“皮之不存”的时候,Y 公司就连“毛”也都掉光了。


4.  谁动摇了你的制度?


            组织模式确定的同时,相应的制度也有随之建立。很少是有几年之后才来补制度的。


            然而制度究竟决定了什么呢?我们先来看看,如果员工在工作中出了纰漏:

              A:没有制度,你没有办法和依据来惩戒员工,因此是管理者的过失;  

              B:有了制度而没有惩戒他,是执行者和监督者的过失;  

              C:一而再、再而三地犯错,又一而再、再而三地被惩戒,那就是教而不改,就真正是员工的品性和素质的问题了。

            因此,先做制度总是好的。至少在你选择做伏剑自刎的李离之前,你还有机会把黑锅扔到出问题的员工的头上。
 
            对于一个已经规范管理、体制健全的公司,不容许员工犯错是对的。即使是一次犯错,立即开除也说得过去。但还是有前提的,这至少包括:  

             A:员工已经接受过相关的培训,这至少包括员工规范和技术技能的学习  

             B:在该员工之前,相同的或者相关的错误没有被枉纵 


            第一条是人性化的体现。中国人常说不知者不为过:员工不知道,管理者也没有给他知道的条件,那怎么能说是他的过错呢?如果因为不知道而出了问题,那管理者首先应该自省才是。

            第二条则是公平性的体现。不管是针对谁,制度都是一样的,没有情面可讲的,常说的“特殊情况特殊处理”在制度面前行不通。规矩一旦被破坏就形同虚设,反而被员工作为笑柄,用来类比其它的制度。如此一来,整个的制度也就离崩溃不远了。反过来,在已经被破坏了制度面前,若再做杀鸡儆猴状,那猴子是被吓着了,不平声、怨愤声也就跟着出来了。 


            因此最好的方法是赶紧修订制度,而不是修理人。

            所以,经常的情况下,动摇了制度的人不是犯错的员工,而是管理者自己。如果在制度面前,既做得到“人性化”,又做得到“公平性”,那么当管理者的便可以多做几次黑脸的包龙图,而脖子上的脑袋便可以比李离顶得长久一些。

5.  “那我们就开始开发吧” 


            现在,公司的组织机构和制度建设已经完成 了,在这个组织机构里,我们已经有了一个或者多个团队。接下来,我们要真正的开始团队建设了。


            这是任务。因为正在读书的你,和我一样,是要拉齐七八杆枪,开始做工程的了。而在这一切开始之前,再之前的时间里,我还想知道一件事:你知道如何做工程吗? 我们先来回顾一下。


            前一章说的是编程,EN,那实在简单,愚公式的工作。我们先不管愚公们的水平如何,以及够不够勤快,反正,他们会编程就是了。


            上一章呢,说的是一部分懒人“创造”或“寻找”到一些编程的方法。这些懒人们可能来源于做得太老的、或者太累的愚公,或者是??一些看着愚公们着急,又被闲出毛病了人。反正他们找了一些方法出来,而我们的愚公们也已经学会了这些方法。

            现在,有了会(比较快速地)编程的愚公,而且有了公司,我们完成了组织机构建设,我们还找到了一名(或好多名)项目经理,他们一不怕死,二不怕苦  对了,更为可喜的是我们还有了开发部:对内,我们订了一套规章制度;对外,我们还拿到了项目单子。
           “那我们就开始开发吧”——你就这样给我说。
 
            很久以前,很久很久以前,人们都是这样做的。拿到项目单子,然后“那我们就开始开发吧”。这样的事出现得很自然,因为积极的愚公们总是有挖山不止的欲望。所以他们一看到项目单子,第一个反应就是:那我们就开始开发吧。


            做了这么多年项目,我现在一听到这句话,就哆嗦。

6.  组织的学问:角色


           现在先考察一下你的公司,在整个系统里面,有没有这样的人:他既不归任何人管理,也不管理任何的他人。如果有,那么就早早地把他开掉好了。


            这样的人在组织机构中是一个盲点,或者空洞。按照我的观点来看,他在组织中不担任任何的角色,既然“不是角色”,那么当然要开掉。


            在任何错误被归咎于员工之前,管理者应该先想想是不是自己的问题。

           是的。你可能很快发现问题出在了管理者。因为管理者没有确定组织机构模式,或者没有为组织中的成员进行角色定位和分工。如果这样,出现“既不能令,又不受命”
的人就是必然的事了。


            同样的道理,在工程开始“做”之前就得先把“角色”确定好。——可能部分角色是组织机构相关的,例如“部门经理”和“开发人员”;而有些就需要临时授命。

             对于一个项目来说,第一个授命的人的当然是“项目经理”。接下来的事件就复杂得多了。按照微软的惯例,授命项目经理的同时,会有“产品经理”、“开发经理”、“市场经理”以及“文档化和培训负责人”。这当然不表明至少需要 5 个人才能构成团队,在大量角色从项目团队中抽取与剥离后,我们可以得到一个精减的团队模型(在后面我会把它叫“R模型 ”):

                     更上层管理                           
品质部门 文档和培训 客服部门 市场部门 
                {                         开发经理
开发团队{      项目经理 
                {                        开发人员
 
 
在保障这样一个组织机构模式的过程中,有几点是需要注意的:  

           A:如果项目针对直接客户,而且没有产品化的可能性(或必要性),那么可以将与市场(以及市场部门)相关的问题和角色先暂时放在一边。  

            B:已经存在于开发团队中的成员,不适合在品质部门中兼任角色。  

            C:项目经理应致力于减少团队中开发角色与其它部门的沟通,必要时开发经理应该站在开发人员之前进行部门间的交互

            D:品质部门、文档和培训部门和客服部门应该主要由有专门培训的人员构成,尽管开发人员可以(或者经常会)参与文档、培训和客服工作,但这也通常是他们最不能胜任的角色。


            这是中小型规模的公司和团队的参考组织机构模型,对大型团队并不适用。

           在这个模型中,我们仍然看到了一个至少由三个人构成团队。其中,在开发经理和开发人员之间,既存在主从关系,也存在协作关系。而项目经理,则在团队中处于领导者、组织者和团队保障者的地位。

 
            如果非得要精简到两个角色的团队模式,那么这种情况下,通常是开发经理兼任项目经理,因此这位开发经理一定要能清楚地区分这种双层角色的身份:在任何时候,明确自己是在进行“团队内协作”、还是“团队管理(和组织)”、还是在与“团队外交流”。
             如果这个开发经理总是混淆自己的角色,那么,我建议,换人吧。


7.  跟随蚂蚁。但不要栽进蚂蚁洞里。


             团队真的需要管理吗?

             这经常是“经营”开发团队的管理者最容易给错答案的问题。这些管理者兢兢业业,试图细化每一个管理环节,将自己的意愿贯彻到??EN,CPU 里去。 


             实际上,开发团队并不需管理。或者说,在你还没有弄清楚状况之前,不要去管它。


             温伯格(Gerald M. Weinberg)在“给软件开发经理的建议”中提到了这样一个问题:开发经理如何面对一个并非由他亲自雇佣成员的团队。温伯格的回答是:  

             A:与成员面谈,让他们签约受雇于你;  

             B:或者,解聘他们;

             C:再或者,放弃这个职位。


             温伯格的意思是“没办法管就不管”。温伯格当然可以有更多的选择,他总可以找到适合自己管的公司。然而目前,你可能是唯一的人选。或者你原本就期待这个角色很久了,当然不能象温伯格一样放弃。


            你得找办法来解决团队问题。


           “签约”这样的事,在大多数环境下是行不通的。要知道,既然他们与公司的签约保证不了他们工作的质量,同样与你的这份签约也不会。协议并不能建立管理者与被管理者的信任,而只是确保了这种关系。 


            但是你应该相信我,在你接手这个团队之前,上一任经理也确保了这种关系。然而团队失败了,否则不会换作是你。
 
            所以告诉团队成员“现在轮到我管理你们了”,根本就是一句废话。或者在你来之前,他们就已经知道你要来了。

           小的时候,我就喜欢观察蚂蚁。我喜欢看它们成群结队地搬着东西穿过小路,或者水沟。我尝试用木棍导引它们改变行动的路线,然而不久之后,它们就会翻过那根木棍,按照既定的路线行进。


            禀性难移,要改变一个人都难,何况是改变一个团队的既定习惯。


            如果有一群开发人员象蚂蚁一样辛勒地工作着,那么,先不要打扰他们。你应该随他们,看看他们是如何做的。发现规律,分析这个规律的价值,最后再尝试改变它们(的一些负面价值的规律)。 
 
             所以你要紧紧地跟随他们。——除了一个地方。那地方是你去不得的,那就是蚂蚁洞。


            显然,你不是开发者,你是管理人员。所以尽管你是团队中的角色,但千万记得离蚂蚁洞远点。你在洞外张望,可以发现问题;你在洞内,就只有做“循规蹈矩”的蚂蚁。 管理者是那个可以在洞外放木棍的人。


8.  “什么是增值税发票?” 


            现在你已经足够地观察了你的团队,你知道这个团队存在问题,你也知道你需要改变。当然,你也知道这种改变并不是放一根木棍那么简单。

            你已经确定了组织结构,确定了组织中的角色,还有了一个团队(5个?或者 10个?)的人。所以作为项目经理,你需要先分工。 


            在分工之前,那个团队只能算是一个没有组织与合作的群体(所以英文中群是 Group,而开发团队是 Team)。
 
           被优先考虑的是弹性分工。每一个人都被要求做一颗革命的螺丝钉,哪里需要哪里拧。所以弹性分工总是被放在企业节省人力资本的第一要务上。然而我们真的会做弹性分工吗?


            蚂蚁的分工模式之一就是弹性分工。一只蚂蚁搬食物往回走时,碰到下一只蚂蚁,会把食物交给它,自己再回头;碰到上游的蚂蚁时,将食物接过来,再交给下一只蚂蚁。蚂蚁要在哪个位置换手不一定,唯一固定的是起始点和目的地。 


            确定被“弹性分工”的员工需要可以快速地转换到新的角色,但首要考察的并不是他是否“有能力”胜任这个角色。能力可以通过学习来增强,而角色的转换,则首先是思想的转换。
 
            1997 年,P&J 的公司打算全面拓展市场,我随他一起到了成都。当时我是开发部的三个主力开发人员之一,因此在原定计划里,我是到成都组建西南区开发部(或技术中心)。然而在两周之后,P&J 发现总公司的运作存在问题,因此他必须回郑州。P&J 决定将成都市场的问题全权交给我,换而言之,我必须出任成都办事处经理。

            我对市场一窍不通,也不懂得公司的经营与管理。但很明显,做办事处经理不是做技术,这与我(当时的)个人意愿是相背的。于是我拒而不受。理由也很充分:我不会做市场。 


            P&J 用了两天的时间来说服我,直到在临回郑州的前一晚我仍未能接受这个任命。这时他告诉我:即使是做开发,也是需要了解市场的,你必须知道用户想要什么,你必须理解你的客户。因此你如果想要做一个好的开发人员,你应该正视这次机会。

            我沉默了许久。我想明白了两件事:从公司的角度上,我必须接受这个职务;从个人的角度上,我需要接受这个职务。于是,我问了我的第一个问题:“什么是增值税发票?” 


             P&J 笑了。接下来我们开始讨论经营问题。第二天P&J 飞回郑州。五个月后我升任西南区总经理,一年后,西南区做到六个分区市场中业绩第二。此后我辞职回到郑州,再一次从开发人员做起。 
 
           “什么是增值税发票?”意味着从技术到经营的角色转变。这个问题本身带来的并不是能力的提升,但如果我提不出这个问题,我将没有可能理解经营与市场。
 
            尽管弹性分工非常有效,然而真正做弹性分工却并非易事。蚂蚁的角色转换是本能的,而 P&J 却不得不花两天时间来说服我。因而更应当留意团队成员“自激”式的角色转换,知道他是不是真的想(而不是需要)转变一下角色,这样起码可以省去你两天的功夫。

           然而能提问“什么是增值税发票”的愚公毕竟不是太多,大多数时候他们在“箕畚运于渤海之尾”,如果实在闲得厉害,他们可能会去发明翅膀,而不是思考“什么是增值税发票?”
 
           更好的选择是明确分工,而不是弹性分工。你应该明白,重要角色的更替通常是极具风险的,例如项目经理或者开发经理;频繁的开发人员的调度也会直接影响到工程的质量和进度。

            如果所有人都在思考“什么是增值税发票”,那么你的组织机构将立即溃散。 
 
            因此,明确分工是你的管理职责。做管理≠做伯乐。

 

PS:这章看的不是很解,可能是自己还没有参加工作把,等参加工作后在来看,肯定又是另一翻体味。。。

阅读(3366) | 评论(0)


版权声明:编程爱好者网站为此博客服务提供商,如本文牵涉到版权问题,编程爱好者网站不承担相关责任,如有版权问题请直接与本文作者联系解决。谢谢!

评论

暂无评论
您需要登录后才能评论,请 登录 或者 注册