如何控制需求边界
来源：网络
阅读量：次
最近项目组开发花了一个月，但是验收却花了两个多月的项目迟迟没有上线。和他们开发一聊才知道，每次他们拿着测试版产品去到客户那边验收，客户总会提出一大堆问题或者新的需求，他们只能回来继续改——继续去客户那验收——继续回来改，如此循环。而且，当产品和测试从客户那带回新需求时，开发越来越“绝望”，代码出现的Bug也越来越多。
这里一个重要概念，那就是需求边界。需求边界的概念是指在一个明确的项目或产品版本中，需求的数量和范围可控；不在外力的驱使下随意改动或增加需求，知道该做什么，不该做什么。
一般来说，公司外部的需求较难控制，不可预测的情况容易发生。因此，外包项目更需要做需求边界的控制。
需求边界的重要性
首先，在任何阶段对客户的需求来者不拒，肆意扩大边界范围，那么将导致项目迟迟无法交付上线；
其次，在开发阶段，需求依然充满变数，团队将产生疲惫抗拒心理，对团队士气是”致命“的；
最后，对公司来说，阶段性验收形同虚设，无法交付就没有项目尾款，最终造成项目亏损。
而需求边界的好处就是明确阶段性工作的方向和重点，对排期和进度更好把控，这样就能避免出现上述“灾难性”的问题。
控制需求边界
1）需求层面
我们需要有个认知，在业务方面，我们的客户是专家，他们一定是有需要没有得到满足，所以希望我们提供解决方案。我们无法根据业务技能去识别产品需求，只有使用对象才能决定需求边界的范围和深度。
当对需求还没有认知时，最好的办法就是深入业务场景，通过调研、仿真、模拟，建立对需求理解的一致性，这样使我们能想象最终的产品形态是什么样的。
再从结果倒推出需求边界，清晰界定自己的边界，以及需要遵守的边界。毕竟客户只是需要解决问题，而如何解决，功能如何呈现，还是靠产品经理决定。
2）规范流程控制边界
“需求从来不是靠过程中的控制来实现，一旦想控制‘进行中的边界’，都会让你处于一种极为不利的境地”。
这句话我非常认同，当出现边界不可控，需求无线蔓延的状况，最主要的原因就是没有在项目开始之前梳理一个基本的规范。如果不在项目开始时就建立起规范的机制和流程，盲目依靠自己在过程中的包容性，只会越深入越困难。
一件事开始要做的时候，也就是项目开始的时候，一切都是“一派祥和”，无论是客户还是团队都是最好说话的时候。那么就，要抓住这最好的时机，建立整个项目过程中必须遵守的规则和流程。
做外包项目时，我们都需要进行阶段性的验收。其中一个重要的里程碑就是需求边界确定，我们向客户交付的原型和UI设计稿就划定了我们本次开发的需求边界。客户口头说Ok后，我们还需要通过一封正式的确认邮件，白纸黑字就是我们以后拒绝扩大需求边界的武器。
3）确定需求冻结时间
当产品/项目有了明确的上线或交付时间，就需要在确认需求邮件后开需求评审会，开发会评估需求的问题点以及实现难度。
评估结果出来之后，我们再去调整版本规划表的需求划分。例如，有些需求这个版本不能实现的，就下移到下一个版本；有些需求压根不能实现的，就直接删除；有些需求实现难度太大的，就可以直接放到待定版本需求里面去。
当排期敲定之后，我们的需求就冻结了，我们向外界传达出一个讯息就是，这一版本我们就做这些工作，不会增加新的需求，也是对开发负责任的态度。
4）落实合同和验收标准
如果和客户签订了合同，合同中明确了项目范畴和交付时间，也是需求边界的一道墙；明确了项目解决方案，任何超出边界的需求都可以拒绝。
比如，我们给线下亲子门店设计线上预约和购买会员解决方案，那么如果客户在之后想增加电商功能，我们是可以以合同约定的内容给予拒绝。
如果是合同范围内的修改需求要求，说实话，有时候我们做不了主是否修改需求，毕竟面对金主爸爸。因此我们可以重新评估需求的变动成本，提供更简单的解决方案或合理的拒绝理由给到客户或领导，让他们做出决策。
5）转移决策压力程控制边界
学会拒绝是个好方法，但是有的需求无法拒绝，我们就需要给出充足的理由。比如，提出需求池的概念，告诉客户，这一版本我们的目标是完成什么主要功能，刚提出来的新需求我们会维护在需求池中，在下一版本中进行规划。
如果客户依然觉得新增需求是合理的，那么我们就将决策的压力转移到客户身上。给客户说明利害关系，是要尽快上线，慢慢优化，还是不停加需求无限期开发下去。
势必要增加新需求，那么费用和时间成本也需要重新评估。为了保证能顺利交付上线，遵守需求边界的约定，新需求规划到下一版本当是上上策。
如若还拒绝不了时，要学会向领导借力，将需求边界被打破，无法控制的情况说明清楚，最终决策权在领导手中。
这里一个重要概念，那就是需求边界。需求边界的概念是指在一个明确的项目或产品版本中，需求的数量和范围可控；不在外力的驱使下随意改动或增加需求，知道该做什么，不该做什么。
一般来说，公司外部的需求较难控制，不可预测的情况容易发生。因此，外包项目更需要做需求边界的控制。
需求边界的重要性
首先，在任何阶段对客户的需求来者不拒，肆意扩大边界范围，那么将导致项目迟迟无法交付上线；
其次，在开发阶段，需求依然充满变数，团队将产生疲惫抗拒心理，对团队士气是”致命“的；
最后，对公司来说，阶段性验收形同虚设，无法交付就没有项目尾款，最终造成项目亏损。
而需求边界的好处就是明确阶段性工作的方向和重点，对排期和进度更好把控，这样就能避免出现上述“灾难性”的问题。
控制需求边界
1）需求层面
我们需要有个认知，在业务方面，我们的客户是专家，他们一定是有需要没有得到满足，所以希望我们提供解决方案。我们无法根据业务技能去识别产品需求，只有使用对象才能决定需求边界的范围和深度。
当对需求还没有认知时，最好的办法就是深入业务场景，通过调研、仿真、模拟，建立对需求理解的一致性，这样使我们能想象最终的产品形态是什么样的。
再从结果倒推出需求边界，清晰界定自己的边界，以及需要遵守的边界。毕竟客户只是需要解决问题，而如何解决，功能如何呈现，还是靠产品经理决定。
2）规范流程控制边界
“需求从来不是靠过程中的控制来实现，一旦想控制‘进行中的边界’，都会让你处于一种极为不利的境地”。
这句话我非常认同，当出现边界不可控，需求无线蔓延的状况，最主要的原因就是没有在项目开始之前梳理一个基本的规范。如果不在项目开始时就建立起规范的机制和流程，盲目依靠自己在过程中的包容性，只会越深入越困难。
一件事开始要做的时候，也就是项目开始的时候，一切都是“一派祥和”，无论是客户还是团队都是最好说话的时候。那么就，要抓住这最好的时机，建立整个项目过程中必须遵守的规则和流程。
做外包项目时，我们都需要进行阶段性的验收。其中一个重要的里程碑就是需求边界确定，我们向客户交付的原型和UI设计稿就划定了我们本次开发的需求边界。客户口头说Ok后，我们还需要通过一封正式的确认邮件，白纸黑字就是我们以后拒绝扩大需求边界的武器。
3）确定需求冻结时间
当产品/项目有了明确的上线或交付时间，就需要在确认需求邮件后开需求评审会，开发会评估需求的问题点以及实现难度。
评估结果出来之后，我们再去调整版本规划表的需求划分。例如，有些需求这个版本不能实现的，就下移到下一个版本；有些需求压根不能实现的，就直接删除；有些需求实现难度太大的，就可以直接放到待定版本需求里面去。
当排期敲定之后，我们的需求就冻结了，我们向外界传达出一个讯息就是，这一版本我们就做这些工作，不会增加新的需求，也是对开发负责任的态度。
4）落实合同和验收标准
如果和客户签订了合同，合同中明确了项目范畴和交付时间，也是需求边界的一道墙；明确了项目解决方案，任何超出边界的需求都可以拒绝。
比如，我们给线下亲子门店设计线上预约和购买会员解决方案，那么如果客户在之后想增加电商功能，我们是可以以合同约定的内容给予拒绝。
如果是合同范围内的修改需求要求，说实话，有时候我们做不了主是否修改需求，毕竟面对金主爸爸。因此我们可以重新评估需求的变动成本，提供更简单的解决方案或合理的拒绝理由给到客户或领导，让他们做出决策。
5）转移决策压力程控制边界
学会拒绝是个好方法，但是有的需求无法拒绝，我们就需要给出充足的理由。比如，提出需求池的概念，告诉客户，这一版本我们的目标是完成什么主要功能，刚提出来的新需求我们会维护在需求池中，在下一版本中进行规划。
如果客户依然觉得新增需求是合理的，那么我们就将决策的压力转移到客户身上。给客户说明利害关系，是要尽快上线，慢慢优化，还是不停加需求无限期开发下去。
势必要增加新需求，那么费用和时间成本也需要重新评估。为了保证能顺利交付上线，遵守需求边界的约定，新需求规划到下一版本当是上上策。
如若还拒绝不了时，要学会向领导借力，将需求边界被打破，无法控制的情况说明清楚，最终决策权在领导手中。
需求边界
内容版权声明：除非注明，否则皆为本站原创文章。
