为什么我们的项目老在reschedule?

Rush and small requirements 比较多

用到别的项目组的库不够稳定

还有与客户同步开发修改用户提出的bug很费时间

QA测试不够充分

从上面的这些归纳，感觉所有项目delay或者reschedule都是因为其他人造成了。不得不承认上面列出的这些问题也是影响项目schedule的因素，甚至还有很多其他的外部因素也在影响项目的进展（比如设备问题等等）。但这些外因是影响项目进展的主要因素吗？

回答这个问题之前，我们来看看现在schedule的制定：为了尽可能减小一些外部因素或者意外情况对项目的影响，我们在feature评估的时候会留一些“buffer”来解决这些问题，buffer一般在20%左右。如果我们将导致项目delay的主要原因归咎于外部因素，那是不是意味着我们的项目有超过20%的时间被其他因素影响，我相信会存在这种项目，但如果大部分项目都是这样的话，我们大部分计划制定出来之日也决定了它必须被schedule，那我们是不是在整体上来考虑我们的项目计划是否合理了？

我个人更偏向内因是影响项目进展的主要原因。“Schedule是PM对大家的承诺”，这是Van去年跟我说过的一句话，给我的印象比较深刻，那么从某种意义上来说，schedule也可以认为是人的诚信问题。记得我曾经说过一句话“如果项目失败，PM有着不可推卸的责任”，这句话其实是一句废话，负责项目的保质保量完成是项目经理的职责。如果感到委屈，不防回答一下下面几个问题：

1、 你接手项目的时候知道这个项目要到达的目标吗（比如达到怎样的性能，内存使用情况怎么样）？

2、 你详细了解并掌握了spec的定义吗？如果不清楚，你是否在计划阶段与US PM讨论过，并确保项目开始前有比较明确的spec？

3、 工作量评估的时候，你跟相关开发人员讨论过每个任务，并让他们自己评估工作量，还是根据自己的“直觉”填写MD？

4、 并了解每个模块怎么实现吗？

5、 你能把握项目的整体框架吗？你怎么控制保证开发人员的编码不偏离你的设计？你一直在跟踪着开发工作吗？还是有些模块你根本不知道怎么回事情？

6、 你每天分发了开发人员比较明确的任务，并在每天结束后来验证过这些任务吗？

7、 对于US PM的要求说过“不”吗？还是来者不拒？

8、 当你发现某一个设计有严重错误的时候，你是否能预知到其可能存在的风险，并及时与总监沟通调整计划吗；还是心存侥幸，希望加紧其他的开发进度以后再来弥补这个设计的缺陷。

9、 在每次递交当天的早上，你与所有开发人员开过会议，明确每个人的递交任务了吗？

10、 你是否忙得连管递交的时间都没有？

11、 你在为提高工作效率和避免让开发人员加班而努力吗？还是对此抱无所谓态度。

12、 你在乎项目的进展吗？项目的reschedule会给你压力感吗？

作为PM，你说这么多，那你做能做到这些吗？