原标题：如何控制需求蔓延和变更——受自助餐行业的启发

交付项目，又称为toB商业化项目、toB解决方案项目、甲方外包项目。交付项目如何控制需求蔓延和变更，一直是行业难题。受自助餐行业启发，咱来聊聊这个话题。

软件交付和自助餐，看似2个毫不相干的行业，却面对同一个难题：如何控制需求蔓延和变更。

• 软件交付：甲方付1份合同的钱200w，在合同范围内无限提需求，需求实现都是成本。
• 自助餐厅：顾客付1份门票的钱200块，进店无限吃，餐品制作都是成本；

咱从企业盈利的角度，来看看自助餐厅是怎么做的，再聊聊软件交付该怎么做：

一.控制项目周期

• 自动餐厅：一张门票，看似200块无限吃，实则控制了用餐时间，比如4小时。顾客即使不停的吃，但是受限于时间，消耗量是有限的。
• 软件交付：一个项目，要控制周期，能半年结束的，就别拖一年。需求是在时间长河中不断涌现的，控制时间就是控制需求。

• 自助餐厅：一张门票，看似200块无限吃，但只针对一个人。一个人的胃是有限的，用餐量总有上线。
• 软件交付：一个项目，要控制甲方的需求扎口人，人数越少越好，不能人人提需求。提需求的人越少，需求就越少。

• 自助餐厅：顾客选餐之后，原则上不能浪费。所以顾客选每样餐品时，量都不多；
• 软件交付：要避免甲方随意提需求的情况出现。需求变更、方案选择，都要有留痕。需求变更要提收费。

• 自助餐厅：对于一些高成本菜，比如现烤类，就那么一两个窗口。人人都有需求是吧，得等；
• 软件交付：对于需求蔓延、需求变更，如果没有额外收入，就别响应太快，也别投太多人。

• 自助餐厅：虽然有用餐时间、反浪费、响应速度等众多制约，但是有的服务员会主动给顾客送上特色餐品，确保顾客的整体满意度；
• 软件交付：从项目目标出发，团队应主动从“最佳性价比”的角度，主动给出推荐方案。

• 自助餐厅：营销时给顾客高大上遐想的同时，用餐规则文案却不随意；
• 软件交付：售前吹牛皮可以天花乱最，合同内容要谨慎。

本文由 @点水点点 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自Unsplash，基于CC0协议

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务