|
为什么我们的项目老在reschedule?
类别: 生活工作- hawk @ 10:20 am
昨天开了一个PM(Project Manager)会议，讨论项目为什么会老是reschedule的问题。大家都很踊跃，也说出了不少问题，大概归纳了一下，有一下几点：
CBD(code base delivery, 一种不记在项目任务内的递交，一般由于US PM做出要求或者修改Bug引起)递交比较多
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，你说这么多，那你做能做到这些吗？
我想过去做好这些，至于能否做到，跟个人能力也有关系。
| 
《匠人手记》推荐网上购书渠道： 
匠人学习：
