新项目的estimation

 

刚刚接手一个multi-touch的项目，平台是win7.

感觉很混乱，刚开始program manager一直催design，development和QA做schedule, 因为design的schedule没有出来，所以development的schedule很难做，QA更无法做schedule。我觉得在当前很多东西都不明确的情况下，很难做estimation和schedule，即便是管理层施压必须要做，也只能是个很粗略的一个计划而已，随着项目的进展，schedule和estimation也要更新。

之后得到design和development的schedule，看了之后，感觉这份schedule是在个理想的情况下，设想项目顺顺利利进行的情况下做的schedule，没有添加任何risk的buffer。(这里要先说明个前提，因为这个development team空闲了很长时间，很想要得到这个项目，PM给出一个deadline，如果不在这个deadline之前把东西做出来，这个项目就不做。这件事情我是私下和development team沟通才得知)。还好development manager重新做了一份schedule,为了补救他们的工作吧，他发了两份schedule，一份是乐观情况下的schedule(即前一份schedule)，一份相对比较保守的schedule，列出一些可能会出现的问题，加了buffer。接手这一个新项目，新技术，依赖第三方的方面很多，比如win7何时发布，比如touch设备，比如multi-touch的drive，如果中间的一个环节hold住，都将影响整个项目的进展情况。经过老大的指点，在我发QA schedule的同时，又向所有项目组的成员说明，QA如果能按照schedule完成任务，有几个前提必须要在某个时间点前准备就绪：Touch的device在哪个时间前必须到货，在哪个时间，development必须deliver一个testable的build。说明这些之后，才稍微觉得安心。

因为是采用scrum流程，在第一个sprint，development只能deliver 一个build，所以这个阶段，QA尽量多做一些准备工作，备份系统，根据workflow准备case，遇到问题及时找development沟通，储备相关的业务知识等。每周的项目例会，更新QA工作，如果发现潜在的risk，及时沟通。有些问题是躲避不了的，所以有问题要早提出来。现在深有感触Team Coordination and Consensus Management 是多么的重要，做好项目的工作，也要把项目的发展情况及时准确的反映给项目组成员和管理层，如果遇到困难，及时寻求帮助，如果遇到争议的问题，也要努力找到一个解决的办法。

 

对development lead之前只因为PM的一句话，不根据自己的实际情况而且迎合管理层，觉得很是不妥。困难和风险不提出来并不代表没有，早提出来，可以让管理层去判断，去和客户协商，最终找到一个可以成功完成项目的解决办法。