|
对于我现在从事的软件开发工作，公司为保证质量，定义了一套规划严谨，资源有序的项目阶段，需要包括立项，需求规划，系统设计，详细设计，编码，集成测试，系统测试，样机测试，成果鉴定，市场商用等等里程碑点或者基线阶段。
在每个里程碑或者基线阶段，都会根据这个阶段的过程任务，制定本阶段的交付产物，质量目标，输入输出。只有进行了阶段评审，交付物，质量达到了该阶段的要求标准后，才能允许进入下一个阶段的项目进程，否则除了不允许进一步进行后续阶段的研发工作外，还要就阶段延期进行原因复盘和责任追究。同时也不允许提前完成某个阶段的工作，因为项目管理工作组认为，如果一个项目的预期计划被提前完成，那么这个任务要么是根本没有完全完成，要么就是走入歧途出了其他问题。
这样一套项目过程监控管理的规则，在理论上的确对于提高一个软件开发项目的交付质量和最终交付出和客户需求一致的产品上，是非常有保障和可控的。但在实际的实施过程中却感觉并不是每次项目过程都能有效可遵循和套用。
我所在的公司在市场上属于后进入的乙方，为了抢占市场份额，竞争的优势是成本低，响应快。尤其后者，响应快的意思说白了就是客户需求的交付时间周期短。公司市场人员为了在激烈的市场竞争中拿到单子，基本是能应承的答full support，不能应承的答we will release after 1-2 months。结果这样的方式苦了支撑的研发团队，需求规划基本无法冻结，也谈不上需求里程碑的评审是算通过了呢还是要继续延期？延期的原因是客户需求一直爆发，并且要求的交付周期非常短。研发经常是在赶工，项目开发模型从瀑布修改为迭代，又调整再修改成小瀑布……但不管如何修改，整个开发过程的工作量估算基本形同虚设，市场的交付时间点已经不能突破，而资源和进度的冲突却无法解决，最终基本靠两点搞定：
1．加班，拼命加班。发挥项目成员的雷锋精神。
2．功能先交付，项目质量目标能打折扣就打折扣，先让市场去忽悠客户，谁让你客户贪便宜（成本低），便宜没好货。
3．只能耍赖皮。让市场人员走潜规则线路，让客户缓缓……
这样的现象在我在公司的这些年是非常常见，也在项目管理层面上思考和摸索过一些方法和手段，但感觉质量，资源和时间就是一个成正比关系，哪个都不能有短板，在功能交付点同等工作量下，资源时间越多，质量就越高。没有什么可以投机取巧的方法。心里也很困惑，各位项目经理在项目管理流程上在规则和实际情况发生冲突的时候，怎么保障突破规则，又能提供好质量的软件产品。
来源：http://www.pmsalon.net/viewthread.php?tid=6556 | 
