很多企业由于不具备自建软件研发团队的能力，或者预见当前项目无需长期持续运维，于是采用外包的方式完成特定需求的软件定制开发。
软件项目的需求通常是会持续发生变化的。原因包括甲乙双方对需求理解存在的分歧需要时间才能暴露、需求方对需求的表达从碎片化到完整需要时间、外部业务环境发生变化或甲乙双方对客观环境的认知发生变化，等等。
软件需求的变化会引发项目工作内容变化，成本、预算和工期也往往随即改变。在商务上，甲乙双方要共同认可这些改变需要花时间协商和谈判，然后技术团队才能执行需求变更的实施。技术团队在遇到影响工作量、工期的需求变更情况的时候往往只能先暂停实施，等待项目经理甚至商务主管介入并协商成功之后才能继续推进项目。
实践中，需求变化引起工作量变化并不是导致外包项目工期延长的唯一原因；更多时候，成本和预算变化涉及商务条款变更所需要的协商和谈判才是外包项目按时验收的主要障碍。
有什么方法能在外包项目中快速响应需求变化，尽量不耽误工期？
1、把需求分析和开发测试拆成两个外包项目
很多企业在招投标的时候都会提供一份详细的软件需求说明书，方便投标方评估和报价。这些软件需求说明书有的长达数十页甚至数百页，非常具体和清晰。这样的项目执行起来通常偏差会比较小，相对容易掌控进度。
事实上，招标使用的软件需求说明书是需要时间和成本梳理和编写的。大企业通常会聘请专业的咨询顾问公司负责编制软件需求，这就是独立于执行具体程序开发工作的另外一个项目了。
在软件需求编制项目中，整理出来的需求包括流程图、业务过程说明、系统原型、数据接口规范等多个方面，需要客户反复确认、修订并最终签字，其过程已经处理了大量的“需求变更”。由于需求编制阶段并未开展软件设计和编码，大部分都是文档性工作，需求反复细化和调整并不存在障碍，因此可以快速迭代。
2、项目开发分期报价分期实施
把大项目拆分为几个小项目分期签约实施，这样可以降低系统的复杂度，把一些并不紧急的需求变更放到下一期项目再实施，从而不构成对当期项目的影响。
从响应需求的角度来说，对需求变更的理解能快速达成一致，并且放入了下一期的计划。虽然这些计划变更的需求尚未实现，但纳入计划本身就完成了对需求的“响应”了，实现了对需求和预期的管理。
3、用劳务外包的方式而不是项目外包
某些甲方只是受制于其他因素(如人员编制预算)不能扩大研发队伍，但其实具备软件项目实施管理能力。这种情况下，采用劳务外包的方式可以很好解决问题。因为乙方只是出租合格的工程师，工程师的具体工作安排由甲方自理，乙方并不对项目进度和质量负责。这种情况下，甲方的需求变更可以直接在自己的管理范围内完成全部沟通处理和计划调整。甲乙双方只需要按照工程师的实际租赁时长结算外包费用即可，项目需求变更不与甲乙双方商务合作关系构成冲突，自然可以被快速响应。
只不过，并不是所有软件外包企业都能同时支持劳务外包和项目外包这两种业务模式。甲方选择供应商的时候需要识别和区分。
4、按工作量结算而不是一口价外承包
对预算不大、需求不甚清晰但又急于上马的项目，对预算充足的创新型项目，对需求不连续、已经处于持续运营阶段的项目，可以考虑按实际发生的研发工作量结算外包费用，而不是一口价项目外包合同。
一个软件项目外包合同如果需要报一个总价，客观上来说必须先分析需求接着设计方案并取得客户确认，然后评估工作量和报价，最后商务沟通谈判形成合同。如果需求持续变化，上述过程很漫长并且没有办法快起来。
在双方足够信任的情况下，先协商确定技术服务人天单价，然后根据实际发生的工作量结算外包费用，则甲方可以像指挥自有技术团队一样随时变更软件需求以便快速响应市场变化，如臂使指。能充分快速响应需求的变化，是按工作量计价模式的最大优点。
这个方式的缺点是无法在一开始确定项目预算，很多时候这构成了项目投资决策的最大障碍。对预算敏感的客户建议考虑前述模式1和模式2。有充足预算或有计划将会自建研发团队的客户，则可以考虑按工作量结算的模式。
实际上，即使在自建团队的情况下，项目本身的研发预算也是不确定的：只要需求不确定，CTO就无法保证项目一定能在计划时间内完成且不存在重大缺陷；即使需求确定，CTO也保证不了，因为团队可能出现人员变动，等等。
除了甲方的预算问题，乙方的管理能力也是很重要的因素，无法监管工作量和工作质量的团队没有可能实施按工作量结算的计价模式。一是要算清楚工程师花了多少时间，二是要审核这些时间花得合不合理，都是巨大的挑战。
结语：对软件需求而言，唯一不变的就是变化。甲乙双方都最好留有需求变更的备用金预算；能拆分的项目就不要一口吃完，小步才能快跑；先投入做好需求而不是急于开发，磨刀不误砍柴工；如果一定着急干，劳务外包或着按工作量结算，做好为冲动的需求买单的打算。
