互联网和产品 · 2019年12月17号 0

如何控制B端产品的需求边界?

最近,隔壁项目组开发花了一个月,但是验收却花了两个多月的项目迟迟没有上线。

和他们开发一聊才知道,每次他们拿着测试版产品去到客户那边验收,客户总会提出一大堆问题或者新的需求,他们只能回来继续改——继续去客户那验收——继续回来改,如此循环。而且,当产品和测试从客户那带回新需求时,开发越来越“绝望”,代码出现的Bug也越来越多。

于是,我意识到一个重要概念,那就是需求边界。

需求边界的概念是指在一个明确的项目或产品版本中,需求的数量和范围可控;不在外力的驱使下随意改动或增加需求,知道该做什么,不该做什么。

我们做的B端产品,在工作中一般会分为两种:一种是平台化Saas产品,即标准化产品;一种是外包型产品,也叫外包项目,定制化产品。

一般来说,公司外部的需求较难控制,不可预测的情况容易发生。因此,外包项目更需要做需求边界的控制。

需求边界的重要性

可以想想,如果B端产品经理没有需要边界的概念,会发生什么情况?

  • 首先,在任何阶段对客户的需求来者不拒,肆意扩大边界范围,那么将导致项目迟迟无法交付上线;
  • 其次,在开发阶段,需求依然充满变数,团队将产生疲惫抗拒心理,对团队士气是”致命“的;
  • 最后,对公司来说,阶段性验收形同虚设,无法交付就没有项目尾款,最终造成项目亏损。

而需求边界的好处就是明确阶段性工作的方向和重点,对排期和进度更好把控,这样就能避免出现上述“灾难性”的问题。

那么如果可以控制需求边界呢?

通过总结,我认为可以通过三个层面控制。

需求层面

我们需要有个认知,在业务方面,我们的客户是专家,他们一定是有需要没有得到满足,所以希望我们提供解决方案。我们无法根据业务技能去识别产品需求,只有使用对象才能决定需求边界的范围和深度。

当对需求还没有认知时,最好的办法就是深入业务场景,通过调研、仿真、模拟,建立对需求理解的一致性,这样使我们能想象最终的产品形态是什么样的。

再从结果倒推出需求边界,清晰界定自己的边界,以及需要遵守的边界。毕竟客户只是需要解决问题,而如何解决,功能如何呈现,还是靠产品经理决定。

项目层面

1. 规范流程控制边界

“需求从来不是靠过程中的控制来实现,一旦想控制‘进行中的边界’,都会让你处于一种极为不利的境地”。

这句话我非常认同,当出现边界不可控,需求无线蔓延的状况,最主要的原因就是没有在项目开始之前梳理一个基本的规范。如果不在项目开始时就建立起规范的机制和流程,盲目依靠自己在过程中的包容性,只会越深入越困难。

一件事开始要做的时候,也就是项目开始的时候,一切都是“一派祥和”,无论是客户还是团队都是最好说话的时候。那么就,要抓住这最好的时机,建立整个项目过程中必须遵守的规则和流程。

做外包项目时,我们都需要进行阶段性的验收。其中一个重要的里程碑就是需求边界确定,我们向客户交付的原型和UI设计稿就划定了我们本次开发的需求边界。客户口头说Ok后,我们还需要通过一封正式的确认邮件,白纸黑字就是我们以后拒绝扩大需求边界的武器。

2. 确定需求冻结时间

当产品/项目有了明确的上线或交付时间,就需要在确认需求邮件后开需求评审会,开发会评估需求的问题点以及实现难度。

评估结果出来之后,我们再去调整版本规划表的需求划分。例如,有些需求这个版本不能实现的,就下移到下一个版本;有些需求压根不能实现的,就直接删除;有些需求实现难度太大的,就可以直接放到待定版本需求里面去。

当排期敲定之后,我们的需求就冻结了,我们向外界传达出一个讯息就是,这一版本我们就做这些工作,不会增加新的需求,也是对开发负责任的态度。

如何控制B端产品的需求边界?

商务层面

1. 落实合同和验收标准

不管是Saas还是外包,如何和客户签订了合同,合同中明确了项目范畴和交付时间,也是需求边界的一道墙;明确了项目解决方案,任何超出边界的需求都可以拒绝。

比如,我们给线下亲子门店设计线上预约和购买会员解决方案,那么如果客户在之后想增加电商功能,我们是可以以合同约定的内容给予拒绝。

如果是合同范围内的修改需求要求,说实话,有时候我们做不了主是否修改需求,毕竟面对金主爸爸。因此我们可以重新评估需求的变动成本,提供更简单的解决方案或合理的拒绝理由给到客户或领导,让他们做出决策。

2. 转移决策压力程控制边界

学会拒绝是个好方法,但是有的需求无法拒绝,我们就需要给出充足的理由。比如,提出需求池的概念,告诉客户,这一版本我们的目标是完成什么主要功能,刚提出来的新需求我们会维护在需求池中,在下一版本中进行规划。

如果客户依然觉得新增需求是合理的,那么我们就将决策的压力转移到客户身上。给客户说明利害关系,是要尽快上线,慢慢优化,还是不停加需求无限期开发下去。

势必要增加新需求,那么费用和时间成本也需要重新评估。为了保证能顺利交付上线,遵守需求边界的约定,新需求规划到下一版本当是上上策。

如若还拒绝不了时,要学会向领导借力,将需求边界被打破,无法控制的情况说明清楚,最终决策权在领导手中。

总结

需求边界对产品规划的重要性不用多说,而如何控制边界,需从需求、项目到商务层面层层把握,通常还需要经历多次教训,慢慢领悟。当

需求蔓延的后果铭记于心时,自然更有魄力控制需求边界,坚持不让产品需求处于不可控的地步。