再论项目经理和项目SQA的监控职责

       在前几篇文章中，我撰写了“项目经理和SQA的职责和培养”。最近在项目过程中，经常遇到项目经理和项目SQA经常为了监控的结果争吵：项目经理认为，SQA的检查结果太僵化，不适合项目，SQA认为是按照现有流程，现有检查单做出的，有理有据，不可辨驳。

       那么这个过程中，到底是谁对谁错，项目经理和SQA如何配合，才能减少类似的分歧和争吵，进而达到一起为项目的成功而合作的双赢或者多赢的局面呢。

       其实，这个看似不大的问题，个人感觉涉及到几个层面：第一，项目经理对项目监控过程的理解和参与企业过程改进的深度；第二，项目SQA的监控方式，范围和方法；第三，企业对于监控数据的使用范围和态度；第四，项目规模等项目本身的属性。

        目前，很多企业都设有EPG等流程改进的组织结构，专门负责企业内部研发流程的优化和改进。而由于国内企业小散弱等特点，EPG中的成员大多数是兼职的，甚至连EPG leader都是兼职。这样就会造成在过程改进中，EPG组织的功效名存实亡，大部分流于形式。而企业由于各类原因选择项目经理时，更偏重于技术强弱，而对项目管理技术等软技能相对关注较少，这样就造成了，EPG改进时，项目经理不关心，甚至认为流程不能解决问题而不愿意投入精力参与流程改进等工作，岂不知，流程过程的建立和完善，其实是一种规则的建立过程，而项目管理，所管辖的范围正好就是规则范围内的事项。由于流程无用论的理念作祟，后期的流程类培训更是找各种借口不参与。后果就是，在项目执行过程中，由于抵触情绪，对流程进行抵制。甚至有意和流程对着干。第二，SQA对流程的监控范围，方式和方法。SQA的职责是保证流程的执行和实施，向高层提供一种可视化的项目状态。从表述看好像只是监控流程执行情况，和项目无关。其实，往深了想，监控流程的目的是什么，无非就是保证项目的成功。从这个维度考虑项目经理和SQA的目标其实是一致的。既然一致，为什么项目经理和SQA还存在冲突呢？除了上面提到的第一条原因之外，下面从SQA本身的问题去讨论一下。做为项目来说，其实每一个项目都都有一个很大的范围，涉及到方方面面，除了需求，设计，编码，测试，发布等工程环节之外，其实还涉及很多其他至关重要的环节，如项目难度，人员规模等项目本身的属性，还有团队沟通，企业文化，领导风格，团队气质等环境属性。这就要求我们的SQA既要满足组织层面的流程监控力度，同时也要根据项目属性和环境等其他属性来个性化定制项目跟进和监控的属性。 在这个过程中，切忌监控的过于繁琐，不要纠缠于项目的一些细节。如，评审过程的监控，目的是评审出问题，而不一定什么类型的文档都必须评审出多少问题，如果评审不出这么多问题，就如何如何。毕竟，项目规模，项目难度不同，人员熟练程度不同，问题评审出的数量也是不能一概而论的。项目的SQA应该有充分的权限和自由来进行自由的判断。以利于项目进行为准，而不是以找出不符合项为目的。毕竟我们做项目以项目成功是目标，不是为了找不符合项，向领导邀功。很多企业的SQA以找到不符合项向领导邀功做为目标，显然是不利于项目的进行的。第三，企业对监控数据的使用范围和态度，有的企业在对度量数据使用时很不慎重，甚至做为评价员工的依据，这不利于真实数据的收集。有的企业说对度量数据进行考评的依据，但却对度量数据的总结是，经常针对个人进行问揭，让这个团队压力重重。显然也不利于项目数据的真实表现。第四，和项目规模等本身的属性有关，这方面已经在第二条论述中有所体现，在此我就再强调一条，项目属性本身绝对了项目采用什么样的流程和监控形式，只有采用合适项目特性的监控方式，才能既保证效率，也保证质量。