如果你是一个项目管理人员，你可能会觉得自己拿到的是一份处方，十个清楚明确的步骤，包含时间、成本、预警、团队建设、评审、风险管理、目标定义等方面的内容。似乎感冒病人照方拿药，按时服药就会病好一般。
只有你自己也处在一个灾难项目当中的时候，你就知道，这些没什么价值。是的，没有价值。
项目管理的很多步骤都只是尽早发现问题，不能解决问题。对于灾难项目，问题多来自于需求分析和设计，来自于架构和框架，部分来自开发方法学。而这背后，是开发经验的积累和复用的问题。
软件项目没有银弹，但有最佳实践。选择架构和框架解决关注点的分离和集成，根据用例分析需求及需求背后的问题，然后划分模块和定义模块的功能接口和合作契约。细心整理领域模型、复用组织机构、权限、工作流、统计报表等模块。整体概要设计然后逐步细化，自动测试、持续集成、发布，不断获得反馈，项目就会在康庄大道上。
这个过程的质量和风险控制可以借鉴《灾难拯救：让软件项目重回轨道》，But just so so。