在获取需求和定义产品阶段，需要防止 的不是进度太慢而是过快、过草率。特别是对于创业公司的产品经理来说，很可能因为看到开发人员无事可做而感到压力，所以尽快完成产品定义，而没有充分了解 市场和竞争对手信息，没有与合作伙伴充分沟通，没有做深入的思考。

　　这些因仓促而隐藏的问题，发现得早则导致开发阶段大量返工，发现得晚则导致产品上线后不 受欢迎。常听一些人说现在互联网开发，讲究快速迭代和敏捷，边做边想，返工也正常。这是一个误解。快速迭代指的是将不同版本之间的周期缩短，小步快跑，而 不是在一个版本的周期内来回折腾。

　　在开发和测试阶段，项目管理重在跟踪进度和保持沟通—用集成和演示跟踪进度，基于Bug沟通问题。

　　要做到各个模块外部接口相对清晰稳定，并尽早完成各个模块间的集成，最晚不超过开发周期的1/4时间。第一次集成之后，就应该开始每日集成和每周演示。每日 集成使得测试团队每天能同步测试最新的代码，帮助开发团队尽早发现问题并及时了解技术细节上的进度;每周演示使产品经理、项目经理和管理层能从用户的角度 感受产品，使他们对产品有信心。集成和演示是项目管理的心跳，合理利用它们，有助于及时把握项目的健康程度。

　　无论开发流程多敏捷，工程师能 力多强，记录和跟踪Bug都是必不可少的。开发团队和测试团队的沟通都应该基于Bug，才能言之有物。开发工程师每次提交代码都应该记录是针对哪个Bug 的，每日工作简报都应该写今天关/开了哪些Bug。要在每日晨会(站着开，一般15分钟内)时说好，今天打算解决哪些Bug，其中有哪些点不清楚，需要和 谁沟通。

　　在后期部署和维护阶段，要快速响应。考验的是团队成员的责任心和抗压能力。系统运维工程师要深夜工作，因为部署可能要在流量低的时 候进行;项目经理要保持能随时沟通，做出快速而准确的决定，鼓励团队并做出表率;一旦出现高危害Bug，开发团队要在24小时内准备好补丁。Amazon 的做法比较有趣：在产品刚上线一段时间内，开发工程师要保持24小时开机。如果自己负责的模块中出现高危害Bug，那么很可能会在深夜被系统运维工程师叫醒。这样不仅能保证快速响应，还能让工程师意识到：前期代码不好好写，后期就别指望能好好睡觉了。