项目经理访谈录5：我们究竟靠什么来保证交付的产品质量

人员背景：项目经理老吴，8年IT项目管理经验访谈主题：我们究竟靠什么来保证交付的产品质量访谈记录整理如下：

质量的改进终归要依靠一个个产品，一行行代码的改进。作为一名基层的IT产品负责人，根据我自身遇到的一些问题，进行了一些总结和反思，与大家分享一下。

1.识别重点，明确质量控制措施

明确的工作事项往往比较容易落实，项目管理的三个关键要素是质量、进度及成本。IT项目的进度保障基本不是大问题，因为进度、成本的承诺和压力对项目经理而言是很明确的压力和挑战，相关控制措施也明确、好衡量，但质量控制措施的效果往往不太明确，这就容易被忽略或裁减。因此把质量保障措施明确化、固化就非常重要。当进度、成本二者存在刚性约束时，则应该识别重点，保证重点交付的质量控制措施不缩水。

比如在某安全软件上线过程中出现内核驱动的兼容性问题，全公司陆续有外来为用户反馈开机启动联网或者连接某些无线热点时，机器卡死。事后分析，虽然此问题的直接原因是编码缺陷导致，但是根本原因却是项目管理的问题。

此功能原本由一名经验丰富的老员工负责，项目中途此员工离职，接手的员工上手速度还比较快，表面上功能开发进度正常，项目进度也就未进行调整，但实际上驱动模块对编码能力及经验要求很高，有些问题在少量测试机器上很难暴露，换人接手后，在技能辅导，代码审视以及测试验证等环节，都会增加相应具体的质量控制措施，未预留人力投入，导致未及时发现隐患，最终上线后出现问题。

2.质量源于设计，设计方面的欠缺易导致后续的问题

软件中需要依靠潜规则、违反认识直觉才能使用的功能，往往会导致问题产生。如果此类问题又没有明确而醒目的警示，则更加糟糕。比如一次网络通信必定包含两个方向的数据包，某安全软件在WIN平台需要对一次通信的进出两个方向的数据包分开进行策略配置。此功能上线后，策略配置人员并未充分了解此项潜规则，忽视了进、出规则的联系。全公司因策略配置错误，陆续导致了200多个额外的用户热线事件。

另一安全系统中，针对某些人下发某个个性化策略时，要把其他所有策略全部拷贝一遍，这样导致其他无关策略有多份拷贝。

策略配置人员在后续策略调整时数次出现遗漏修改策略拷贝，导致用户事件设计的优劣，隐患往往更加抽象，不易衡量，但实际很多问题的根因都具有较大的共性。

回顾成功失败的案例，提炼设计原则，制作成检查单，根据检查单比对检查设计方案则能达到较好的效果。另外设计时容易忽略可测试性，可度量性方面的要求，导致后期难以实现自动化测试。而手工测试重复的工作很多，效率较低，不能充分的挖掘问题，功能上线后异常隐患，性能、效能等数据也往往依靠人工收集、统计，导致产品团队不能主动发现隐患，系统优化周期长，

3.质量扎根于开发

在从事客户端安全软件开发的几年中，我观察到这样的现象，在新员工大量入职的第二年，往往出现较多的线上问题，此后版本质量会逐渐提高，直到下一批新员工入职。

新员工入职第二年，开始独立从事主要功能的开发，但面对复杂的线上环境，对各种异常情况考虑不足，代码中存在各种隐藏的地雷，比如多线程并发逻辑的缺陷，对代码执行时间敏感操作，内存访问越界，资源未释放等。这些地雷通过集成测试的经常不能发现，这些问题中有相当多的问题，实际是老问题的重复。