如何应对频繁的软件需求变更？

项目建设方最痛苦的事情之一，就是软件需求的经常变更。本文以项目过程生命周期为主线，通俗而简要地阐述了项目各阶段应如何做好需求变更管理

转载请联系作者

作为项目建设实施掌舵人的项目经理及架构师们，最痛苦的事情之一就是：软件需求经常变更，导致工期不断拉长、成本投入持续增长、项目风险也越来越大，有一种想把这些善变的客户，哦不对、是需求，给砍了的冲动

这时，请先反省一下：自己是否还有哪些地方做的不够？或者，还有哪些地方应该做得更好？

我们不妨从项目过程生命周期的各个阶段来看看我们可以做到哪些

售前及商务阶段

• 在售前阶段应提前明确界定项目范围，并于商务阶段落实到项目合同中；
• 需要明确项目范围中是否包含、及包含多少免费需求变更工作量，并落实于项目合同中（一般对应到售后服务中）；
• 明确需要额外计价的需求变更工作量范围及上限，及计价方式，并落实于项目合同中；
• 明确需求变更管理机制，特别是变更各环节的确认及审核责任，并落实于项目合同中；
• 对影响/决定项目核心设计方案的技术/业务关键点，可以适度进行POC确认；

项目计划阶段

• 项目经理应在制定项目初期计划之前就对客户有充分地了解和调查，并以此作为风险分析的依据：是否是对技术方案熟悉的成熟用户？是否有对项目需求明确的接口人？是否有可以拍板需求的决策人？响应度如何？等等。。。
• 依据对上述风险的分析结果，对应采用不同的实施模型。如：需求明确的情况下，可以瀑布；反之，如果情况不太乐观，尽量螺旋迭代；
• 计划中安排足够的反复需求确认的时间，并做好不乐观情况的充分准备；

需求调研及分析阶段

• 尽量让需求人员以小步快跑的方式迭代地进行多轮的界面原型确认，除了降低项目风险外，这同样也是提高用户满意度的方式；
• 频繁而有引导性地需求确认，既要充分把握用户需求，又要时刻注意不要被（业务和技术上）不专业的用户带到沟里，这两点重要度是一样的！

设计阶段

• 作出更加具有“远见”、和更有扩展性的架构设计，要敢于想在用户之前，这要求架构师不光是技术专家，同样也应是一名业务专家；满足于满足当前需求是不够的，你的架构和设计是否禁得起3~5年后业务变化的考验？
• 关心扩展性、高可用、高并发、高内聚、低耦合等非功能性需求大于关心功能性需求；时刻记住：功能性需求是时刻变化的，非功能需求则要相对稳定得多；

开发测试阶段

• 尽量以小步快跑的方式迭代地进行多轮的可运行原型确认，要记住：用户再满意的界面原型和实际可运行原型之间还是有一定区别的；
• 可以的话让用户参与测试，测试过程中也许你会发现和以前理解有偏差的地方，并在还为时过晚之前给你一个修复它的机会；等到试运行之后再由用户提出来会多出更多的成本；

运营、试运行、正式上线

• 可以的话这里的每个阶段都要拿到用户正式（邮件/纸质）的评审通过确认单，这是很好的用户“封口胶”——你确认没问题、满足需求、并可以上线了？那好，再提出变更的时候你就要三思了哈_{（灭哈哈哈}~~）

贯穿所有阶段的工作

• 所有的需求变更都要留痕，并以邮件/纸质文件形式进行用户确认；
• 记住：不要试图回避或掩盖可能发生的需求变更，它就像被你用沙子埋起的炸弹，总有一天会爆炸的，再丑的媳妇也是要见公婆的。
• 每个大的阶段评审都要有用户正式（邮件/纸质）的评审通过确认单，当然要注意该用户是否是具有该阶段评审结果确认权力的有效用户；

技术和管理外的功夫

• 项目经理和销售是否在项目工作之外，和项目的客户方主要干系人都建立了足够的私人信任？该吃饭吃饭、该喝点小酒就去喝点，俗话说：吃人嘴短。。。这种私人信任有时候能帮你少走很多弯路

最后的话

• 对于初创期小企业或其他在商务谈判中处于弱势的建设方，也应尽量坚守上述的原则和方法；如果为了企业长远利益着想而在当下项目中实在无法做到，那就做好为奴为婢的思想准备吧~并尽早跳离这个坑，尽快找到除了低价之外自己的核心竞争力，以争取商务谈判主动权；
• 当然，项目的实际情况也许远比上文所述复杂，还是要靠实战中个人项目经验的不断积累和总结，《周礼》有曰：坐而论道,不如起而行之！