软件项目的人员风险

场景一:
　　办公室里，老板peter气急败坏的走来走去，刚培养起来的得力干将david今天说下周合同期满他要辞职了，一想起自己不得不为了再培养一个和David一样得力的员工，先花掉大笔的银子找猎头、面试，然后找一个熟手带他(天哪!这是双倍的浪费)，Peter的头都要炸开了，要命的是，这些和David一样不打算长期在公司呆下去的家伙，平常会为公司的长远利益着想吗?尤其当这个长远利益与他们自己的利益发生冲突的时候?那么公司的问题出在哪里呢?

　　场景二:

　　项目例会，经理Susan向老板汇报:“要在年底之前完成A公司的项目存在太多的不确定性，您看我们从前没有做过这类项目，我们也没有对项目功能点的准确评估，我们更没有关于工作效率的统计数据……”，老板打断她的话说:“在我们公司，没有什么是不可能的，只要我们全力以赴，没有什么是做不到的，各位同仁……”,老板没有注意，台下大家面面相觑。

　　场景三:

　　Susan领导的团队排除千难万阻终于在第2年完成了A公司的项目，在这个过程中，团队成员一起攻克难关，一起加班，越来越默契，合作起来顺畅，大家建立了哥们似的友谊。可是老板说，要充分发挥精英团队的力量，所以打算将Susan的团队分为5个部分，插到5个其它团队中，以“影响其它团队都成为精英团队!”，老板手一挥说得豪情壮志。他没有注意Susan一脸木纳，面无表情，Tom在那里嘀咕“我讨厌H团队的那个bill，怎么偏偏要和他合作?我恨和他一起工作，真是倒霉，哼，我一定不让他好过!”

　　计算机技术日新月异，CASE工具、可视化程序设计方法、快速设计原型、面向对象技术、各种软件开发过程模型层出不穷，可是为什么我们还是不能开发出一个好的软件呢?想想吧，任何一个好的软件出自于什么?任何一个失败的软件呢?对了，是“人”，都是“人”!既然软件是人创造的，也是由人来使用的，那么只有更好地了解人是如何工作、如何解决工作中的问题、如何协调工作中的关系，才可能设计、开发出更好的软件。随着软件工程的发展，“人件”一词出现啦!人件甚至被认为是即硬件危机和软件危机后的第三次计算机革命的起源，人员问题多么重要啊!细细想想，前面的场景是否都与人员有关呢?

　　人员因为其在软件项目中的重要地位和其在配置方式、意识、行为上的缺陷成为软件产品开发过程中的最大风险源和缩小项目风险的最重要途径之一。人员间的交流质量、信任水平、尊重、冲突、工作技能、团队精神、对工作的满意度、个人自豪感和职业成长机会，都影响着企业区分、处理风险因素的整体能力，而且还都有助于建立标准化的团队，而在面向使命的软件开发过程中，高性能的团队将使项目远离并最小化风险因素。

　　另外，很多软件项目中存在的风险本身就和人员密切相关，比如对于著名的软件工程专家Tom DeMarco和Timothy Lister在其合著的由清华大学出版社2004年出版的《与熊共舞——软件项目风险管理》一书中列出的5项软件项目核心风险，人员流失本身就是人员问题，其它4项，进度安排的先天错误由项目主管的行为决定，需求膨胀和规约崩溃因为与客户的不充分、正确交流，低生产率因为人员的工作效率和士气低落，都与人员有关。

　　那么软件项目中都存在哪些和人员有关的风险呢?笔者查“万卷”书，从人员的配置、意识、行为、士气四个方面，总结如下:

　　建立个团队先——配置篇

　　(一) 选择谁?

　　一个成功的项目组首先需要一个知道如何选择合适人员的合适的项目经理。此处合适的人员指具有其岗位需要的技术及其它相应潜质的员工，是否在重要的位置安排了合适的人是至关重要的，将很大程度决定这个项目的成功。很难指望提高领导技巧挖掘每个下属潜在的品质，因为人的个性在一个公司呆的一段时间不足够改变。最好的经理的标志之一是能将那些可以把前瞻性和成熟性技术很好结合、遵守标准又不拘泥于标准的人挑出来。

　　(二) 多少人合适呢?

　　人员数量绝不是越多越好，因为越多的人需要越多交流，所谓镀金现象出现的可能越大。据相关专家估计当团队成员为4人的时候，会有三分之一的工作量浪费在交流上。要靠增加人员数量提高整个项目团队的生产力，很可能是南辕北辙。微软公司项目团队的典型配置是1名经理、3名开发人员和5名测试人员。当然，人员数量也不能过少，缺少人员势必增加人员压力、影响生产效率和项目进度。

　　(三)如何组织?

　　目前业界流行的有三种人员配置方式:

　　1)项目人员数量恒定，几个特定人员自始至终共同负责某个划分好的系统模块;

　　2)随着项目进展人员数目逐步增多，然后随着项目收尾人员再逐渐减少;

　　3)项目从开始到详细设计时，人员数量恒定，编码和测试阶段增加大量人员。

　　前两种方式应用逐渐减少，后一种方式被认为是最合理的人员配置方式，因为在完成设计(尤其是概要设计)前，参加的人员越多，人员之间和各小组之间的接口就越复杂，这样整个项目组的耦合度必然提高，人员交流的工作必然增加，重复和无效工作的出现几率越大，甚至为了让多余的人工作起来而不得不为项目增加额外的工作，这些工作反而拖了项目的后腿。当然不同公司、不同项目情况会有所不同，项目经理需要考虑适合自己项目的人员配置方式。

　　(四) 他们是“跳瘙”吗?

　　人员的频繁变动对项目的影响很大，人员决不像机器零件那样是可以随便替换的。新成员的加入不但需要其对项目的熟悉，融入团队也需要一个过程。人员流动需要很高的成本，这个成本包括雇佣新员工的成本，新成员融入团队的成本(其在真正对项目工作有帮助前的薪水和耗费别的同事帮助其熟悉工作的相应时间的薪水)和更可怕的隐性成本(在人员流通率很高的公司，不打算长期在公司呆的人会持短期对自己有利而不是对公司长期有利的观点)。人员的频繁流动还将抑制企业引进新技术、制定培训计划和发展策略，使企业难得有长远的进步。

　　公司是这么想的——意识篇

　　(一) 企业文化

　　1 企业如何面对风险呢?

　　企业风险文化对一个软件项目的风险管理至关重要。企业面对风险的文化可能分下面三个层次:

　　l 知道会有风险这回事吗?还是机构的经理们认为“we can do everything”，不会出现风险的，盲目自信?但是，风险往往与机遇并存;

　　l 知道可能会有风险，但是敢承认风险吗?强迫自己和团队成员别去想它，不容许这种想法在脑子里闪?心里偷偷盼望好运气?但是，这种相信基于任何分析吗?无论是企业，还是项目经理，应该只相信有权相信的事;

　　l 伪承认风险，只承认可以管理的风险，如果前10个风险不能管理或者实施起来困难重重(这样的风险可能是致命的那10个)，那么就不管它，只管理下面的(其实是芝麻大的)，该领域专家Tom DeMarco把这种现象叫做选择性近视;

　　l 正视风险，不过老实说，极少数公司能做到这点。

　　2 企业又是如何管理的?

　　由管理层决定的企业运行模式对一个软件项目的成败乃至整个企业在市场中所处的风险状况有决定性影响。著名软件与系统思想家Weinberg在关注底层开发人员和管理层的同时，确定了6种企业管理模式，即:不知不觉模式、反复无常模式、例行公事模式、驾驭自如模式、未雨绸缪模式、整体一致模式。Weinberg认为这6种模式都有可能取得成功，关键是与企业现状适合。

　　(二) 进行团队风险管理了吗?

　　团队风险管理是要求客户和供应商一起参加风险管理的方法。这种管理方法可以在保证各方负责自己方面风险缓解的同时，建立三方亲切友好的关系。没有这样的风险管理，三方可能在项目出现问题时互相推诿责任。为了在整个项目开发过程中，以上三方可以共同进行风险管理，1994年SEI在撰写的专题报告:“团队风险管理介绍”中定义了团队风险管理的组织结构、操作方法和使用工具。

　　(三)持续风险管理呢?

　　持续风险管理是随着项目的进行，在项目的不同阶段进行持续的风险识别、分析、缓解、控制的过程。风险管理决不是项目开始时一时的事，随着项目的进展，风险、风险的重要性必然发生变化，一些风险因素消除了，另外一些从前没有的风险出现了。只有持续的进行风险管理，才能保证整个项目的成功。

　　(四)喜欢将项目组拼来拼去吗?

　　一个稳定的、成形的项目组将对项目成功非常有帮助。这一点不同于人员稳定性，人员稳定性是针对一个具体的项目人员稳定;固定的项目组是指对于一个机构，一个项目组一旦成形就不轻易拆开。因为随着这些项目组成员一起工作时间的加长、彼此之间的了解，他们的合作会更加流畅，交流损失会逐渐减少。每结束一个项目就拆散一个项目组不是明智的做法。

　　我们是这样做的——行为篇

　　(一)又着火啦?

　　如果经常为了一些所谓更紧急的事放弃计划好的风险缓解措施，或者其它计划中的工作，那么这样的开发模式就是救火模式了。为什么总有一些更紧急的事需要处理呢?其实还是前面提到的持续风险管理没有做好，如果充分进行了持续的风险分析，那么绝大多数的火都不会着。现在为了救火暂时放下计划中的工作很可能为下次着火留下了隐患，以致形成恶性循环，这样的项目开发过程是高风险的，项目失败的可能性很大。

　　(二) 大家是如何交流的?

　　人员间的交流问题对项目成败影响巨大。在项目组内部，小组成员间有效的交流方式可以提高生产率。另外，还应该鼓励项目组成员与项目经理之间的交流，甚至可以提供匿名交流方式，使坏消息可以尽快反应到项目高层，不至于到无法挽救时，项目高层才知道。与客户的交流更是对项目成败有举足轻重的影响。软件风险管理专家将规约崩溃作为软件项目失败的五大风险之一。这主要是与客户没有进行充分的交流，进而系统要完成的功能(可以以输入输出的形式描述)没有取得一致的意见引起。与供应商也需要充分的交流，尤其外包方，否则可能导致采购品或外协件的质量问题。人员交流将影响工作效率，同时人员交流的效率本身也将直接影响项目进度。

　　(三)我们是个“jell”团队

　　作为一个凝聚紧密的“jell”团队，团队成员有精英意识、责任明确、整体大于部分和，有共同的、愿意为之努力的目标，成员之间的交往容易、相互信任、热情、对他们建立的产品有着共同的情感。只有团队才能起到使每个团队成员都朝着同一个方向努力的作用，团队成员也因此更有效率。而且真正的团队可以因为其团队文化的存在，在所有原班人马离开的情况下生存下来，仍然保持它的力量和特性。

　　一个真正团队的形成有赖于项目经理对其成员的信任、成员的物理集中、不官僚的执行无关紧要、不是必须执行的工作。让员工同时参加多于一个的项目对团队的形成及工作效率都非常不利，因为他需要太多的时间和其它成员交流和从一个工作到另一工作的换档。另外，一次成功会带来另一次成功，高效的和谐会带来更多的和谐，项目团队一起的一次成功的经历对他们非常重要。安排意外的度假、集体开发、甚至一顿特别的午餐都有利于项目团队的形成。

　　(四)标准化!!!必须标准化?

　　标准化应该是将与项目相关的文档工作标准化，而不是将产品本身标准化，应该允许在标准化中试验一种新技术或新方法。真正的标准应该是被公司重复使用的、经过证明的方法。人们在尝试新东西时表现会更好。对于任何标准都应该做好有例外的思想准备。软件行业有经验证明那些尝试任何改进方法的项目，生产力往往高于平均净生产力。安排头脑风暴会议，鼓励会议中提出主意的数量而不是质量，因为愚蠢的主意经常会引领其他人思考聪明的主意。

　　(五)我们分分秒秒在有效的工作呢!

　　可以用功能点比所用时间来衡量工作效率。如果对自己公司的生产力毫无概念是危险的，因为可能你的竞争对手有高于你10倍的生产效率，而你毫不知情，那在竞争中自然处于劣势。拥有高效率的员工(也就是前面所说的选择了对岗位合适的人)对项目成败影响至关重要。据调查，成绩中等以上的开发人员的工作效率是另一半人员的2倍，而使用的语言(汇编除外，会降低工作效率)、工作经验、产品缺陷数量、甚至薪资水平对生产效率影响都不大。另外，企业文化、办公环境、工作场所、噪音对工作效率也有很大影响。实验证明程序员生产力比差为10:1时，其所在公司的生产力比差也接近10:1。

　　(六)冲突!又有冲突?

　　员工间的利益和分工都可能冲突，这种冲突产生的风险是责任不明确和出现问题时的扯皮及员工本身责任不明确引起文档的表述不清楚。人员冲突的解决情况必然影响生产效率和团队的形成。人员产生冲突时，请一个无权、中立的人来调解是一个不错的解决办法。

　　(七)今天去培训!

　　人力资本投资是明智的花费，可以提高员工士气、增强员工的归属感、降低人员流动。而且这种花费并没有消耗掉，而是转化成另外一种形式的资本，长远来说公司非但没有损失反而会有更大的收益。比如将一个员工送去培训一周，这笔付该员工工资和培训费的钱其实并没有消耗掉，而是转化成另外一种资本:知识。这些知识会在该员工头脑中持续很久，为公司创造更大的效益。

　　(八)头儿是这样做的…

　　主管的行为在下面6个方面影响项目的成功:

　　1不合理的工作量和预算估计、进度安排:项目工作量估计不准确是项目开发过程中的原则性错误。有时项目经理只估计必须完成的工作，不估计可能必须完成的工作，这样人员、时间、资源的分配将不合理，计划之外的工作一旦出现，项目交付日期必然延迟，资金也可能周转不灵，所以应该充分估计项目工作量，在分配资源时也应该保留一定的冗余。

　　2 项目开发策略是全力进攻不防守的策略:风险管理其实就是防守，进行了风险管理可以把资源安排在应该安排的地方，只有当对实际情况进行了充分估计时才可以放心做决定。

　　3 领导无效时的恐慌反应:一旦管理层陷入恐慌，项目将注定失败，这时候他们采取的行动经常是起反作用的。

　　4为了在短期的竞争中脱颖而出而放弃长远利益追求近期绩效。

　　5 将多的工作全部压到最优秀的人员手上，造成至关重要的人员的流失。

　　6 对项目组成员像犯人似的监督，项目经理应该允许最终可能成功的不服从，给员工选择参加的项目和一起工作的人的自由。

　 我爱编程，但别逼我!——士气篇
　　(一) 雄赳赳、气昂昂!

　　低落的士气对项目成功有很多负面影响，会使员工的工作成为应付，消极的工作方式会降低工作效率，延缓项目进度，工作中不积极、负责的参与使产品质量下降。而且进度延缓和质量下降引起的挫败感会使士气更加低落，形成恶性循环。

　　很多原因可能引起士气低落:对老板和客户失望;要他们为了工作牺牲他们认为更重要的价值(比如爱情、家庭、青春);甚至将劣质产品交付用户，都将使技术人员产生严重的挫败感，他们会认为辜负了客户的信任，使他们对以后的开发工作丧失信心;凡事都规定好了，不给员工承担他们其实愿意通过承担来认识自己价值的责任，或者一定遵守所谓的标准化。要想提高员工的士气需要给人员一定的动力，奖励、鼓励他们(甚至是鼓励他们犯错误)。另外，主管的行为对士气的影响很大。

　　(二)压力!哦!压力!

　　适当的压力会增强士气，提高生产效率，但过大的压力(如加班、高工作强度、被责备等)肯定会降低士气和生产效率，如果这时候继续施加压力，将引起不可逆转的崩溃——迫使优秀员工辞职(心理学家对各种需要技巧才能完成的工作中的调查显示)，或者更可怕的脑死亡状态，他们即使在编写代码，也会出现极大量的错误，绩效为0。而且如果团队成员对压力的承受能力不同，还会导致团队分裂。人们在压力下只能选择顺从，这种顺从会给项目经理错误的信号，以致作出错误的估计，使项目经理对项目控制不足，项目失控，此时转而又对项目组成员施加更大的压力，陷入恶性循环的怪圈。有时候施加的压力越大，收到的效果可能越小，通过一个不能实现的最后期限给员工施加压力对项目不能起到任何激励作用(不过一个紧迫但又不是不可能实现的最后期限可以构成一个愉快的挑战)。不过如果人员本身感到局面可以控制，那么他们感知的压力可能比实际被施加的压力小。

　　结束语

　　软件行业是一个特殊的行业，软件产品都是通过人的智慧得到，“人”在这个行业的地位非常重要，本文对影响软件项目成功的人员风险因素进行了总结，希望对软件企业有一定的借鉴意义。为了量化的计算一个软件项目可能存在的人员风险，我们可以采用逻辑回归等模型，具体方法限于篇幅不再详述。