软件开发过程中的审查 (Review)
希望别人做些什么->定义出流程
希望别人做出正确的结果->定义出审查制度
软件开发项目中包括很多的审查动作,贯穿于整个开发过程。个人认为审查主要有以下目的：
1.尽早排查出潜在的问题(Potential Risk/Issue)
经过其他人的参与，以不同的视角提出不同的看法，会有类似头脑风暴的效果，集思广议来查找工程师未能注意的问题。
2.保持良好且有效的双向沟通
很多时候沟通并不充分，总有许多以为明白，实际并不明白的情况。组织管理人员需要及时通过审查的方式，与开发人员进行有效的沟通。 同时，审查会使开发有更多的表达和相互沟通的机会，提高参与度，所以审查也可以提高开发人员的认同感和归属感。如果大家都能从审查中得到有效的指导和帮助，也会有助于提高审查效率。
3.通过以上两点，来达成最终正确的结果。
管理者需要对最终的结果负责，不能坐等问题发生，一定要先行加以预防，所以需要不断的进行审查。而组员通常对于所谓的审查会有一定的戒心，害怕批评或出丑，或者觉得没有必要，于是管理要确保在审查时做到对事不对人，并能针对问题提供有价值的指导。审查的对象是当前状态及产出，审查的目的在于确保最终的正确产出，审查的方式就是质询，而质询的基础就是审查制度。
审查制度可以很灵活，比如在项目开始定义出项目的角色及职责(ARCI矩阵), 然后针对不同的Milestones或任务设置检查点(Check point),重要的环节加以定义，使得审查有据可循。如针对Design Spec,我们需要宣布以下规则:
1. Design Spec需要遵循公司统一规范。
2. Design Spec中需要描述清楚Block diagram, Interface defintions等等。
3. Design Spec什么时候提交给哪些人做审查。
4. 什么时候举行Design Spec的审查会议，哪些人会参加，等等。
这是针对工程师而言的。Design Spec中的内容相应会有一个审查表(Check List)来进行审查，这就是规则。同样针对管理者也可以设定一个审查表,如:
1. 必须向所有组员说明一次公司相关的文档规范。
2. 必须定义清楚撰写及审查的时间安排，并向所有组员宣布，确保大家可以执行。
3. 必须提供相应的审查记录。
对于需求分析、Functional Spec、代码管理、版本控制、发布控制、BUG管理及成本控制，都可以细化相应的动作，加以审查。审查对象包括项目中的各个角色。
总结一下，项目中审查制度的建立有以下步骤:
1. 项目中角色及职责定义(R&R, Who)
2. 定义审查点 (Check Point, When)
3. 定义审查内容、范围及目标(Check List, What)
4. 定义出审查人员 (Who)
*SMART原则是目标管理的重要参考法则，对于这个的审查制度有很强的指导性。
上面的审查制度是常态性的，另外还有一些突发状况需要由管理者适时判断审查的必要性。
如果突然遇到之前未能预估到的技术难题时，管理者必须特别为这个问题设定应急计划和一个更为紧凑的审查机制。比如在应急计划如下：
1.召开会议，寻求资深工程师的帮助。[负责人及时间]
2.安排其他人员支援。[负责人及时间]
3.寻求第三方公司的支持。[负责人及时间]
4.网络寻求解答。[负责人及时间]
5.向相关人员报告细节问题，对于项目管理人员要考虑有无替代方案。[负责人及时间]
相应的审查一方面要针对每项进行，另外也要有一个统一个状态报告会议，以此来加强组织的有效性。当然这样的问题应及早被识别成风险或问题来加以预防，越少发生越好。
还有一种主动的自我审查方式。
无论对于管理者还是工程师，一定要清楚，你的主管、客户和老板，都需要知道你在做什么！及时的汇报是非常必要的，这也是一种主动的审查，它的效率更高。所以我们可以要求承担重点开发任务的人员周期性提交状态报告，将做过的事情、遇到的问题、后续的计划表列出来。其他人可以另作要求。管理者则应主动为其提供相应支持，这样就可以保持一个较为良性的互动。
审查之所以重要，是因为我们处在越来越讲求效率与生产力的环境，走越少的弯路，我们的企业才会更多的利润，员工才有更大的空间。这是管理者与工程师需要共同承担的责任。
*有点乱，先写到这，以后再完善!