走出项目管理的泥沼”之“研发规范”话题

规范不仅仅是文档模板——“走出项目管理的泥沼”之“研发规范”话题

 规范不仅仅是文档模板

——“走出项目管理的泥沼”之“研发规范”话题

作者：茹海燕

最近读《IT经理世界》，刊登了这样一篇文章：《下班后你的公司还值多少钱？》，文章开头讲了这么一个小故事：一位软件公司的老总感慨地说：“做软件公司，最痛苦的事情是下班之后，你发现自己的公司除了几台电脑外，几乎什么也没有了。因为公司最值钱的资产都在每个程序员的脑子里，这些人一旦离开，公司的资产就等于零”。

    这不是偶尔的现象，目前还有不少公司，时刻担心某些员工的流失，直接导致工作的延续和完善出现断层，影响公司收益。难道脑力劳动就只存在于头脑中吗？如果真是这样，人员流动率相当高的IT行业，怎么可能做长寿公司？只能是昙花一现而已。不，不应该是这样的。

    以上述的软件公司为例，装在程序员脑子里的公司重要资产有哪些？软件包括源代码，发布版本，和相关资料，这些资产通过一定的操作，都可以转化成为固化资产。如果研发人员的文档与代码是一致的，那么交接工作会顺畅得多；如果前期的设计文档足够详细和清晰地表达了上层设计的思路，那么下一级设计或者实现不会因为人员变更而受到较大影响；如果随机资料与发布版本一一对应，并且完备地描述其细节，那么设计人员的离开并不能增加太多维护工作的难度。然而，这些都是如果。在一家国内知名公司的办公区内，墙上贴着这样的条幅：“人人都痛恨别人不写文档，人人自己都不愿意写文档！”这就是原因，导致脑力劳动成果总是保留于无形。

    怎么解决这个问题？“没有规矩，无以成方圆”，制定研发规范，将无形的脑力劳力劳动显式化。研发规范，主要是为了细化研发过程，便于流程度量、改进和控制。除了上述的留住公司的无形资产之外，另有一个重要的目的：规范化不同人员的表达方式，减少不必要的信息沟通，提高交流的效率。

    如何制定研发规范？各个公司根据各自的经验，和参考国内国际相关标准，都会有自己的一整套系统规范。如软件项目，从项目立项阶段提交项目立项报告，可行性报告；到系统设计方案，详细设计报告，测试规程，以及各种评审报告等等。其模板也多种多样，很多介绍项目管理的书籍或者文章上，还专门有介绍如何编写某某报告的指导，不可谓不详细。

    规定了这样的一套研发规范，是不是研发过程真的就规范起来，总裁不必再担心下班后的公司不值钱呢？很多公司不是这样。这是因为研发规范不仅仅包括这些各种各样的“文档模板”，更重要的是操作规范。例如，不同研发阶段应该完成什么样的操作、出具什么样的文档才算结束？这些操作又有什么样的要求？这就是流程规范。所以完善的研发规范应该由一系列的流程组成，每个流程包括一些相关操作，和输入输出。

   

    如图1所示，我们以软件中的编码阶段为例，详细介绍其研发规范。

    1． 流程输入
    软件的编码阶段，比学校里的学生想象的复杂得多。首先需要输入详细设计文档，这是上一个流程，“详细设计阶段”的输出产物。而编码规范，则按照不同的语言组织，规范某种语言的使用和交流方式，最常见的要求是规定其注释的百分比。这两种规范一般是公司规范。

    2． 复查
    编码完成之后，需要作者进行复查工作，如果发现故障，需要立即修复故障；否则可以进入下一步操作。
    在编码之后加入的复查阶段，让很多人不理解，因为大家没有在编译之前再读一遍自己代码的习惯，总是希望编译器来代替自己查错。不错，已经有许多改进的编译器可以查出全部的语法故障，和一部分语义故障；但是最好的编译器也只能查出85%的故障，所以为了尽量早地发现故障，作者自己的复查是有价值的。妄图借助后续的同行评审来弥补没有自己复查的人，忘记了自己才是作品的构思者，才最清楚自己想要表达什么，这是任何别人代替不了的。
    不过，如果研发规范在操作这一步骤中面临很大的推进困难，也可以调整此操作到编译之后，但是取消是不提倡的。
    复查也同样需要规范的指导，即代码复查表。这张表的制定需要更多的实时性，它一般是根据软件团队对某一种语言的运用程度而定制的，甚至个人也可以根据个人掌握情况来调整。检查表的有效程度，可以用此阶段的发现故障数量，与整个研发过程的故障数量之比度量，因此它依赖于后期的质量检测，如果在前期制定时有经验丰富的工程师参与，将会降低延迟修复故障而造成的成本。
    从图中可以看出，代码复查可以进行多次，理论上依赖于作者对完成代码的质量信心，不过一般更依赖于作者的勤勉和负责程度，需要团队领导和质量经理经常督促。

    3． 编译
    这是个没有争议的操作，基本上所有的代码版本库的入库要求中，都包括了“代码编译通过”。这个阶段同时需要提交《程序配置清单》，为了同行评审的方便，有时还需要在每个代码文件的属性中标明，是新建的文件还是修改的文件。

    4．代码的同行评审
    这是CMM的要求，按照PR（同行评审）的流程规范进行，并且修改故障和提交评审报告，以及故障记录。同行评审一般不需要循环进行，除非代码质量很差，一次评审不能按照要求通过。
    代码经过同行评审，即可进入调试阶段。

    5．流程输出
    编码阶段的输出，除了代码直接用于调试之外，还有很多的评审报告、记录报告，主要用于项目回顾。

    文档是珠，操作为线，连贯成流程，制定完善的流程规范是让研发规范化的第一步，认真地按照其进行操作，才是研发规范真正起到作用的关键。老板们如果担心自己的公司下班后不那么值钱，与其一门心思担心员工频繁跳槽，不如一边分析员工不稳定的原因，一边花些精力好好研究一下如何规范化研发操作，才能双管齐下，稳操胜券。