“走出项目管理泥沼”之“研发规范”.docVIP

“走出项目管理的泥沼”之“研发规范” 　　最近读《IT经理世界》，刊登了这样一篇文章：《下班后你的公司还值多少钱？》，文章开头讲了这么一个小故事：一位软件公司的老总感慨地说：“做软件公司，最痛苦的事情是下班之后，你发现自己的公司除了几台电脑外，几乎什么也没有了。因为公司最值钱的资产都在每个程序员的脑子里，这些人一旦离开，公司的资产就等于零”。 　　这不是偶尔的现象，目前还有不少公司，时刻担心某些员工的流失，直接导致工作的延续和完善出现断层，影响公司收益。难道脑力劳动就只存在于头脑中吗？如果真是这样，人员流动率相当高的IT行业，怎么可能做长寿公司？只能是昙花一现而已。不，不应该是这样的。 　　以上述的软件公司为例，装在程序员脑子里的公司重要资产有哪些？软件包括源代码，发布版本，和相关资料，这些资产通过一定的操作，都可以转化成为固化资产。如果研发人员的文档与代码是一致的，那么交接工作会顺畅得多；如果前期的设计文档足够详细和清晰地表达了上层设计的思路，那么下一级设计或者实现不会因为人员变更而受到较大影响；如果随机资料与发布版本一一对应，并且完备地描述其细节，那么设计人员的离开并不能增加太多维护工作的难度。然而，这些都是如果。在一家国内知名公司的办公区内，墙上贴着这样的条幅：“人人都痛恨别人不写文档，人人自己都不愿意写文档！”这就是原因，导致脑力劳动成果总是保留于无形。 　　怎么解决这个问题？“没有规矩，无以成方圆”，制定研发规范，将无形的脑力劳力劳动显式化。研发规范，主要是为了细化研发过程，便于流程度量、改进和控制。除了上述的留住公司的无形资产之外，另有一个重要的目的：规范化不同人员的表达方式，减少不必要的信息沟通，提高交流的效率。 　　如何制定研发规范？各个公司根据各自的经验，和参考国内国际相关标准，都会有自己的一整套系统规范。如软件项目，从项目立项阶段提交项目立项报告，可行性报告；到系统设计方案，详细设计报告，测试规程，以及各种评审报告等等。其模板也多种多样，很多介绍项目管理的书籍或者文章上，还专门有介绍如何编写某某报告的指导，不可谓不详细。 　　规定了这样的一套研发规范，是不是研发过程真的就规范起来，总裁不必再担心下班后的公司不值钱呢？很多公司不是这样。这是因为研发规范不仅仅包括这些各种各样的“文档模板”，更重要的是操作规范。例如，不同研发阶段应该完成什么样的操作、出具什么样的文档才算结束？这些操作又有什么样的要求？这就是流程规范。所以完善的研发规范应该由一系列的流程组成，每个流程包括一些相关操作，和输入输出。 　　如图1所示，我们以软件中的编码阶段为例，详细介绍其研发规范。 　　1．?流程输入 　　软件的编码阶段，比学校里的学生想象的复杂得多。首先需要输入详细设计文档，这是上一个流程，“详细设计阶段”的输出产物。而编码规范，则按照不同的语言组织，规范某种语言的使用和交流方式，最常见的要求是规定其注释的百分比。这两种规范一般是公司规范。 　　2．?复查 　　编码完成之后，需要作者进行复查工作，如果发现故障，需要立即修复故障；否则可以进入下一步操作。 　　在编码之后加入的复查阶段，让很多人不理解，因为大家没有在编译之前再读一遍自己代码的习惯，总是希望编译器来代替自己查错。不错，已经有许多改进的编译器可以查出全部的语法故障，和一部分语义故障；但是最好的编译器也只能查出85%的故障，所以为了尽量早地发现故障，作者自己的复查是有价值的。妄图借助后续的同行评审来弥补没有自己复查的人，忘记了自己才是作品的构思者，才最清楚自己想要表达什么，这是任何别人代替不了的。 　　不过，如果研发规范在操作这一步骤中面临很大的推进困难，也可以调整此操作到编译之后，但是取消是不提倡的。 　　复查也同样需要规范的指导，即代码复查表。这张表的制定需要更多的实时性，它一般是根据软件团队对某一种语言的运用程度而定制的，甚至个人也可以根据个人掌握情况来调整。检查表的有效程度，可以用此阶段的发现故障数量，与整个研发过程的故障数量之比度量，因此它依赖于后期的质量检测，如果在前期制定时有经验丰富的工程师参与，将会降低延迟修复故障而造成的成本。 　　从图中可以看出，代码复查可以进行多次，理论上依赖于作者对完成代码的质量信心，不过一般更依赖于作者的勤勉和负责程度，需要团队领导和质量经理经常督促。 　　3．?编译 　　这是个没有争议的操作，基本上所有的代码版本库的入库要求中，都包括了“代码编译通过”。这个阶段同时需要提交《程序配置清单》，为了同行评审的方便，有时还需要在每个代码文件的属性中标明，是新建的文件还是修改的文件。 　　4．代码的同行评审 　　这是CMM的要求，按照PR（同行评审）的流程规范进