做软件项目，肯定与遇到各种各样的风险和问题，而风险越早识别出来，纠偏或预防投入的成本越低，这个道理，大家都懂，但是为什么还是有不少项目失败，明明早期一切顺利，一切可控，但是越做到后面越不可控，如同深陷泥沼，不可自拔。总结以下，注意有以下几方面的原因：
1，识别风险的人能力不足
能力强的PM之所以难得，就是要靠时间的沉淀，只有自己亲身经历过，才知道前面会有什么坑，面对这个坑是跳过去，绕过去，还是跳进去。在项目初期，接触过各种各样的PM，那种前期说了一堆了风险，找各种领导申请资源的PM，基本不需太操心。而那种项目成立初期，PM各种拍胸脯保证完成任务，说没有问题，然后带着团队冲劲方案梳理中的，反而是要多关注的，早期悲观，后期平安，早期乐观，后期悲惨。
2，识别到了但是没跟踪闭环
一些有经验的人，在项目初期参与评审的时候依据自己的经验，提出风险项，但是过了一段时间后，再回来看，发现明明已经提过的风险还是发生了，比如有一次在项目初期给PM预警了一个开发新人的质量风险，要在过程中让有经验的老人多把控该人的细节，结果过了一个月去看，临近交付点了，还有一堆BUG等着修复，再看明细，全是那个新人了，也是挺无语。事后我问那个PM，这个风险咱早期都识别出来了，咋还搞这么惨，PM说，一头扎进项目，就把这个细节给忘了，那个老人忙自己的工作，自己也没关注到。
3，低估了风险影响
风险逐渐暴露为问题，相关的人主观认为自己可以搞定，捂着藏着不升级，直到问题严重到无可挽回的地步，不仅仅是他搞不定了，连他的上级也搞不定，坑了一堆人。比如之前遇到一个PM，需求开发的过程中，客户提出了需求变更，那个PM为了让客户满意，满口答应，没问题没问题，结果做的时候发现，有技术风险，困难远超自己预估，已经答应了客户，这个PM咬牙，带着团队加班加点，最后还是没赶上交付点，延期了一个月，交出去的软件包各种问题，最后引发客户投诉。事后这个PM告诉我，这个事他不应该这么扛着的，承诺的话不能说太满，而且第一时间发现技术难度的时候，应该拉上客户一起制定应对措施，这样变更交付时间还有得谈，闷头自己干，没有出路。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
