公司的一个“新记录”：项目初验不成功

场景：

自公司成立以来，以往由业主方召开的项目初验会议，都未发生过项目初验上出现问题。我一直认为，中国人的从众心理一般都挺严重的，加上我们对项目质量的认识以及对项目管理的重视，就没有碰过一回结论为：初验不通过的初验会。

这次，这样的事情都给我赶上了，刚听到部门经理Z讲的时候，我都觉得有点不可思议！你能理解吗？因为会议之前，同事Z告诉我他得参加项目S初验会，我还非常坚定地告诉他没有什么必要，既然现在有项目经理P在管理项目，就让P去全权负责初验会议，我当时还对Z说，我和你打赌，你去不去初验结果都一样是通过。

分析：

事实的结果给我们来个当头棒喝，至少看来我前面的判断太过自负了，而且还犯了经验主义的错误！我和部门经理Z了解情况，他告诉我原因：

1. 我方初验会议的准备工作不足，前面存在数据质量的问题，也由于我们的Bug，导致初验会议上，C部门提出问题严重；而这个Bug的修订，由于我方在之前进行修复时对Bug进行Impact Analyze时，发生遗漏，导致修复了一个地方，遗漏修复另一个地方；
2. 与接口方项目经理W的沟通、准备不足，本来以往有Bug，做为初验的整改项进行后续的修复则可，没有想到接口方询问C部门意见时，问能否验收，C部门说那不行，如果W问能否做为整改项，可能就验收了！

我了解后，我将我的观点告诉Z，

1. 我们不要埋怨接口方项目经理W，他这样询问确实是正确的，也是符合规定的。我经历的项目验收会，组织方是要分两次询问，第一次是询问是否可以验收，第二次才是询问还有什么遗漏问题，这才是惯例；
2. 从我们自身去找原因，才能将坏事情变成好事情；这是教育我们部门、项目组，包括我的好机会，请项目经理P和成员好好自我分析，将分析情况、经验给大家通报，不是批评，而是让整个部门从中学习；
3. 我们同事容易在工作中只看到业主方的IT接口人，而忽视了整个系统的所有相关干系部门。这种情况应该是事实，试想一下，在从众心理严重的中国社会，这么多部门的代表一起开会讨论，要站出来反对，本来就是一个需要勇气的，要不我们前面确实太忽略了该部门的利益，要不就是我们就是在前面的服务过程中得罪了该部门，这个需要P和项目组他们好好细致分析一下；
4. 从前段时间系统投产以来，项目经理P发出的每日系统监控报告看，确实我们没有收到这样的预警，在说明问题的时候，很多时候是报告其他系统的数据质量导致问题，并没有提及我们Bug导致的影响，从这个角度上讲，也是一个报喜不报忧的假象，混淆了管理者的判断的同时，也可能给相关部门的代表人带来误解：明明系统的问题你们都不说；
5. 我在前面的培训过是有讲过，一个IT系统要有生命力，一定是要照顾到IT系统的所有使用群落，一个系统如果只考虑到管理者的利益，而忽略操作者的利益，这样的系统即使领导说好，也很难长久！这是一个活生生的案例教程；

要将这种意识在部门和项目组中加强再教育，项目管理岗位的同事，本来就需要具备平衡多个合作方、各个岗位、各个角色的能力；需求和顾问岗位的同事，更是需要直面这样的挑战下，进行用户引导；技术岗位的同事，对这样的问题认识也是比较有限的，对一线操作人员的便利性考虑少，特别是这种BI的项目，总觉得让一线再多添点领导需要的数据并不算是什么问题，都需要好好反思。

各位同事，我们做过挺多IT系统，虽然没有一个是失败的，但是我们必须肯定，有不少IT系统曾经昙花一现。公司想成为一个百年老店，我们想做为一个成功的咨询方、设计者、建设者，想多年后还能自豪地告诉你的同事、客户、下属：“这个系统我多年前参与，到现在还在投产使用”，那么这个一个案例不就值得我们细致分析和分享吗！