适应日益加剧的竞争环境、把握瞬息万变的市场信息是企业得以生存和发展的基础，某大型IT公司估计其产品推迟上市一个月将导致收入减少530万（人民币）、利润减少265万、还要付出另外的研发费用37.5万。这就对产品研发项目提出了更高的要求：如何在有限的资源投入下以更快的速度满足或者超越用户的需求。本文汉捷咨询带大家浅析影响研发项目开发效率的因素。

在提高研发效率方面，业界已经进行了大量有益的探索和实践，下面是几种较有代表性的见解：

l 过程/流程决定一切（强调过程的重要性）；

l 人是生产力的决定因素（强调人的重要性）；

l 采用XXX编程工具，可以使您的开发效率提高一个数量级（强调工具的重要性）；

l 良好的计划是项目成功的一半（强调项目管理的重要性）；

……

尽管每种见解都有大量的拥趸（无论处于业务还是商务角度），但是仍然会遭到大量的挑战而不能自圆其说，从研发项目的实践来看也同样反映了“瞎子摸象”的现象：好像每种见解都是对的，但是又不完全对。

根据美国项目管理协会的定义：“项目管理是在项目活动中运用知识，技能，工具和技术，以便达到项目要求”；项目管理的目标是在给定的资源、预算和时间内安全地完成符合质量要求的项目。以上定义意味着项目的资源、预算、时间和项目范围有着内在的约束关系，在这四个因素已经被“极其乐观”的限定的情况下，项目最终无法完成——项目经理常常会遇到非常紧张的、不可能完成的Deadline，如何应对？项目范围的约束关系告诉我们手中的王牌包括增加人手（有时候人多反帮倒忙，可以参考《人月神话》）、投入更多资源（部分模块外包、使用COTS、购买最好的开发/管理工具）、削减项目范围/需求（承诺在后续版本中提供某些功能，但是用户未必会认同）、降低质量（软件项目交付质量的降低往往意味着客户需求没有完全实现，用户也未必会认同）。

更深一个层次，多个因素影响了研发项目的开发效率，片面强调某一个因素而忽略其他的因素，都无法揭示项目实践中遇到的问题。这里引用一个老笑话：

有个警察看到个喝醉的人在路灯下找东西，他就问：你找什么？那个醉鬼说，车钥匙下车时掉了，我在找。警察问：你不在掉的车子附近找，怎么到路灯下找呢。醉鬼说：那里黑啊，这里亮啊，好找！

其实很多项目经理或者咨询机构都在犯类似这个醉鬼的错误，不管是有意或是无意的——试图在自己最熟悉、最容易控制的因素上寻求突破，而对自己陌生的、难以控制的因素却置若罔闻，尽管它可以为项目带来更大的回报。汉捷推测很大程度上是由于“人类本能的需要心理安全感”。

那么，到底哪些因素影响了开发的效率、他们又能够在多大程度上造成影响？下面的资料是Capers Jones在《Software Assessments, Benchmarks, and Best Practices》中使用的数据，这是目前为止最新资料（虽然量化管理是管理追求的较高层次，但是现在度量方面的专著却几乎绝迹，可能是商业利益使然）。

影响软件项目生产率的积极因素（以影响程度排序）：

项目因素	影响程度(%)	项目因素	影响程度(%)
高质量可交付产品复用	350	正式审查的使用	15
高水平的管理人员经验	65	好的办公室人体工程学	15
高水平的技术人员经验	55	低的项目复杂度	13
有效的方法与过程	35	适度的进度压力	11
有效的管理工具	30	生产率测量	10
有效的CASE工具	27	低的需求蔓延	9
高级程序设计语言	24	10天以上的年度培训	8
质量评估工具	19	开发团队分布集中	8
细的岗位分工	18	高昂的团队士气	7
有效的客户参与	18	分层管理机构	5
正式的成本与进度估计	17

 

影响软件项目生产率的消极因素（以影响程度排序）：

项目因素	影响程度(%)	项目因素	影响程度(%)
低质量可交付产品复用	－300	拥挤的办公空间	－27
管理人员缺乏经验	－90	低级语言	－25
技术人员缺乏经验	－87	工作场所分散	－24
高的需求蔓延	－77	非正式的成本与进度估计	－22
不适当的CASE工具	－75	岗位分工不细	－15
没有使用审查	－48	没有客户参与	－13
不适当的管理工具	－45	没有年度培训	－12
无效的方法与过程	－41	平面式的管理结构	－8
无质量评估	－40	没有生产率测量	－7
项目很复杂	－35	低的团队士气	－6
过大的进度压力	－30

 

从上面的数据中可以有很多新的发现，当然是仁者见仁，智者见智：

l 同一要素的不同影响：相同的项目因素，例如“管理人员经验”，对项目生产率的正面影响为65％，也就是说管理人员具备高质量的管理经验，最高可以使生产率提升65％；而蹩脚的管理人员却对生产率造成最高90％的下降。65％对比－90％，并不相同，这一点在“需求蔓延”上面表现的最为突出，是9％对比－77％。这说明了相同的事情如果做的不好，带来的负面影响远远大于将其做好而带来的积极影响；

l 产品/模块复用：复用可以包括平台化开发、模块重用等，高质量产品复用所带来的收益是惊人的，但是如果有问题的模块被复用，就会对相关产品均造成负面影响，这种影响被批量放大，解决起来也更加困难；

l 人的问题：我们会发现管理人员、技术人员的能力经验对项目造成很大的影响，在这方面的努力会得到很好的回报：不少公司愿意在营销运作、过程改进、设备引进等方面投入巨资，在引入和培训人才方面缺乏力度，初衷是认为“人”在短期内不可改变，即便是这样，对“人”视而不见，长期看来只能是在低水平踏步；另一个问题，项目经理往往会认为项目团队的成员是短板，事实却常常相反，项目失利源于经理的经验不足，对项目丧失控制，“能力越大，责任越大（”With Great Power, Comes Great Responsibility”, Uncle Ben to Peter Parker in Spider-Man）”，不断提升应该是管理者的必修课；

l 需求：产品需求可以看作射击的目标，如果目标没有找准或是错误的，项目必定走向失败。需求对于项目的重大意义无论怎么强调都是不为过的，几乎每个项目经理都会被“需求蔓延/变更”折磨过，但是真正能够从中吸取教训的比例却相当少；

l 管理工具/编程语言：运用恰当的管理工具/编程语言会极大的提高工作效率，例如项目管理工具、配置管理工具、团队交流工具、集成开发环境等，但是却不能指望工具可以改变项目的命运或者产生数量级的飞跃，因为整个项目的工作不仅仅是编写代码，需求分析、系统设计、测试设计、评审等活动不能由工具完全代劳；此外，过分迷信工具的效果反而会削弱对其他因素的关注程度；

l 流程：CMM/CMMI的影响已经将过程的重要性渲染得无以复加，但是令人失望的是它只有30％－40％的影响，其实在其他因素不变的情况下，哪怕只有10％的改善已经非常可观了；过程改进方面过犹不及，不顾公司的商业收益而片面强调规范化、一味向某个所谓“业界最佳”实践看齐，更像是一场无收效的做秀而不是真正的过程改进；

l 进度估计与控制：现在已经有很多成熟的估算方法和工具，那些复杂的方法并不见得比相对简易的方法拥有更好的准确度，关键是方法运用和熟悉的程度；适当的进度压力可能刺激开发人员的工作积极性，但是过大的进度压力却可能导致追求进度而放弃产品质量，结果就是产品不稳定，开发周期拖长，直到大家都已经不耐烦了才勉强发布；

l 团队士气：尽管这个因素的影响程度并不大，但是相比耗资巨大、周期漫长的过程改进活动，其投资回报是非常高的。开发团队具备高昂士气并且由衷的愿意为项目做贡献，就会主动的高质量完成工作，这是任何流程规范无法比拟的。电影《勇敢的心》、《特洛依战争》、《魔戒》中，在英雄们率领他的部队展开诗史般的冲锋之前，都会发表一番激情洋溢的演说，用意就是激励起部队斗志，显然这样会比士气低落时的胜算要大很多。但是一味的强调“精神胜利”是不够的，古人曾总结出“一鼓作气，再而衰，三而竭”，试图激励士气并不是一件很容易的事情，不过挫伤士气倒是轻而易举的；

汉捷认为，项目管理是一门寻求平衡的艺术，即凭借有限的资源最大程度的满足项目干系人的期望；上述的表格只是众多因素的一个子集，不同的项目在不同的阶段可能会出现不同的短板，这就是我们改进的机会所在。