八宝书库 > 文学其他电子书 > 软件工程实践者的思想(PDF格式) >

第5部分

软件工程实践者的思想(PDF格式)-第5部分

小说: 软件工程实践者的思想(PDF格式) 字数: 每页4000字

按键盘上方向键 ← 或 → 可快速上下翻页,按键盘上的 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……………………………………………………………

                                   『大道至简』  



                  更上层管理  



     品质部门     文档和培训     客服部门     市场部门 



    开发团队  

                      开发经理  



          项目经理  

                      开发人员  



                                           

     



   在保障这样一个组织机构模式的过程中,有几点是需 



要注意的:  



    )  如果项目针对直接客户,而且没有产品化的可能 


返回目录 上一页 下一页 回到顶部 0 0

你可能喜欢的