2015第32周周记：“根本原因”、“真实想法”

又是8月初，又过了一周，特别的快。几乎想让时间慢点走——因为项目的进度实在太慢，想分身无奈技能有限。

本来这周是交付的，但测试人员又曝了几个bug，无法遗留，只有继续解决。由于本人较遵守制度，既然还有问题无法交付，只好向大领导申请延期。恰逢大领导休假。周一8:30之前我来上班，发现大领导回复公务，叫我找出“根本原因”、“真实原因”。无奈，当天只好把bug列举出来并给出客观事实。

我不由得想起当初我自己岗位的问题，领导也是要求我说出“真实想法”，我感觉这些术语，是今年公司流行语——还要加上“关键路径”。
这周反馈的bug几乎和设备端的无关了，都是上位机的事。有一个是IE兼容问题，之前我接到的是支持64位IE，但需求管理工程师在描述时，在该功能文字后面用括号注明支持IE6到IE10。当时我没留意看，就埋下了地雷。当年也有个类似的事，视频要求1080P，顺带说720P，但我们在沟通过程中只强调1080P，等到产品准备卖了，反正说明书上有720P而却没有，于是从大领导开始一直向下查。这类事，相信还有很多。我在电子邮件中批评了项目经理、开发人员、测试人员不认真领会需求精神，最后顺便批评需求管理工程师不应该如此含糊。结果该工程师回复说，特别加入该功能，你们开发人员要重视，在概要设计或开发时有疑问，应第一时间反馈到我这里，消除误解。其实我当时就想顶他了。但人家的项目管理部，权力大于PM。而且说得很有道理，我无法找到有力证据。当然，该同志没认真看我的公务，我首先批判的就是项目经理，即我本人。

从这个事得到一个教训，作为PM，什么事都要细心，特别是需求、验收标准、以及流程文档，都要仔细确认，自己不懂的，要问人，要记录下来。

关于文档，因为后期基本没什么新加功能，所以可以同步着手进行。有的人比较主动，有的人要经常催，而且催了不一定有效。文档的事不能马虎，一旦到了验收审查时，威力就显示出来了。作为PM，不可不知。

李迟 周一