如何控制B端产品的需求边界?
碰到一味加需求的甲方爸爸,产品人需要学会拒绝,控制需求边界,才能控制产品的上线时间,把握产品效能。
最近,隔壁项目组开发花了一个月,但是验收却花了两个多月的项目迟迟没有上线。
和他们开发一聊才知道,每次他们拿着测试版产品去到客户那边验收,客户总会提出一大堆问题或者新的需求,他们只能回来继续改——继续去客户那验收——继续回来改,如此循环。而且,当产品和测试从客户那带回新需求时,开发越来越“绝望”,代码出现的Bug也越来越多。
于是,我意识到一个重要概念,那就是需求边界。
需求边界的概念是指在一个明确的项目或产品版本中,需求的数量和范围可控;不在外力的驱使下随意改动或增加需求,知道该做什么,不该做什么。
我们做的B端产品,在工作中一般会分为两种:一种是平台化Saas产品,即标准化产品;一种是外包型产品,也叫外包项目,定制化产品。
一般来说,公司外部的需求较难控制,不可预测的情况容易发生。因此,外包项目更需要做需求边界的控制。
需求边界的重要性
可以想想,如果B端产品经理没有需要边界的概念,会发生什么情况?
- 首先,在任何阶段对客户的需求来者不拒,肆意扩大边界范围,那么将导致项目迟迟无法交付上线;
- 其次,在开发阶段,需求依然充满变数,团队将产生疲惫抗拒心理,对团队士气是”致命“的;
- 最后,对公司来说,阶段性验收形同虚设,无法交付就没有项目尾款,最终造成项目亏损。
而需求边界的好处就是明确阶段性工作的方向和重点,对排期和进度更好把控,这样就能避免出现上述“灾难性”的问题。
那么如果可以控制需求边界呢?
通过总结,我认为可以通过三个层面控制。
需求层面
我们需要有个认知,在业务方面,我们的客户是专家,他们一定是有需要没有得到满足,所以希望我们提供解决方案。我们无法根据业务技能去识别产品需求,只有使用对象才能决定需求边界的范围和深度。
当对需求还没有认知时,最好的办法就是深入业务场景,通过调研、仿真、模拟,建立对需求理解的一致性,这样使我们能想象最终的产品形态是什么样的。
再从结果倒推出需求边界,清晰界定自己的边界,以及需要遵守的边界。毕竟客户只是需要解决问题,而如何解决,功能如何呈现,还是靠产品经理决定。
项目层面
1. 规范流程控制边界
“需求从来不是靠过程中的控制来实现,一旦想控制‘进行中的边界’,都会让你处于一种极为不利的境地”。
这句话我非常认同,当出现边界不可控,需求无线蔓延的状况,最主要的原因就是没有在项目开始之前梳理一个基本的规范。如果不在项目开始时就建立起规范的机制和流程,盲目依靠自己在过程中的包容性,只会越深入越困难。
一件事开始要做的时候,也就是项目开始的时候,一切都是“一派祥和”,无论是客户还是团队都是最好说话的时候。那么就,要抓住这最好的时机,建立整个项目过程中必须遵守的规则和流程。
做外包项目时,我们都需要进行阶段性的验收。其中一个重要的里程碑就是需求边界确定,我们向客户交付的原型和UI设计稿就划定了我们本次开发的需求边界。客户口头说Ok后,我们还需要通过一封正式的确认邮件,白纸黑字就是我们以后拒绝扩大需求边界的武器。
2. 确定需求冻结时间
当产品/项目有了明确的上线或交付时间,就需要在确认需求邮件后开需求评审会,开发会评估需求的问题点以及实现难度。
评估结果出来之后,我们再去调整版本规划表的需求划分。例如,有些需求这个版本不能实现的,就下移到下一个版本;有些需求压根不能实现的,就直接删除;有些需求实现难度太大的,就可以直接放到待定版本需求里面去。
当排期敲定之后,我们的需求就冻结了,我们向外界传达出一个讯息就是,这一版本我们就做这些工作,不会增加新的需求,也是对开发负责任的态度。
商务层面
1. 落实合同和验收标准
不管是Saas还是外包,如何和客户签订了合同,合同中明确了项目范畴和交付时间,也是需求边界的一道墙;明确了项目解决方案,任何超出边界的需求都可以拒绝。
比如,我们给线下亲子门店设计线上预约和购买会员解决方案,那么如果客户在之后想增加电商功能,我们是可以以合同约定的内容给予拒绝。
如果是合同范围内的修改需求要求,说实话,有时候我们做不了主是否修改需求,毕竟面对金主爸爸。因此我们可以重新评估需求的变动成本,提供更简单的解决方案或合理的拒绝理由给到客户或领导,让他们做出决策。
2. 转移决策压力程控制边界
学会拒绝是个好方法,但是有的需求无法拒绝,我们就需要给出充足的理由。比如,提出需求池的概念,告诉客户,这一版本我们的目标是完成什么主要功能,刚提出来的新需求我们会维护在需求池中,在下一版本中进行规划。
如果客户依然觉得新增需求是合理的,那么我们就将决策的压力转移到客户身上。给客户说明利害关系,是要尽快上线,慢慢优化,还是不停加需求无限期开发下去。
势必要增加新需求,那么费用和时间成本也需要重新评估。为了保证能顺利交付上线,遵守需求边界的约定,新需求规划到下一版本当是上上策。
如若还拒绝不了时,要学会向领导借力,将需求边界被打破,无法控制的情况说明清楚,最终决策权在领导手中。
总结
需求边界对产品规划的重要性不用多说,而如何控制边界,需从需求、项目到商务层面层层把握,通常还需要经历多次教训,慢慢领悟。当
需求蔓延的后果铭记于心时,自然更有魄力控制需求边界,坚持不让产品需求处于不可控的地步。
作者:晴天;微信公众号:impm6666
本文由 @晴天 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
面向B端用户使用的产品,技术团队中如果没有一个非常熟悉传统业务的产品经理,技术再好,也会改到你哭的。
确定项目边界比确定产品边界更重要(你提到的是甲方)
做起来难!业务方自己对需求没有清晰认知,产品出来落地难,试行困难,只能修改。
自己开公司,你就不这么想了。在利润面前,只能跪下
需求无边界,哪里来利润?
外包也可能是人力外包,只管做项目,按投入人力算钱,这样不必太纠结需求变动
越发觉得产品经理岗位是块狗皮膏药,哪里需要贴哪里。
哈哈哈 这个是!
还是有一点理想化。主要看甲乙双方的谈判地位如何。如果甲方是大客户,你得罪不起,人家的临时需求,乃至超边界需求你还是会去满足。现实就是这样。
能做到这样还得自身公司的产品流程是规范的,对输出的原型、UI设计图是有自信的,目前来说能达到这种实力的公司团队太少了
需求若是真到领导那里了,十有八九是给他做
还真是
有必要对公司商务、销售等岗位加强业务边界的培训,从一开始的招标书就划定边界,就怕什么都敢往里面写,后面产品经理和项目经理就很被动了。
点赞👍🏻
感觉是瀑布式研发流程
道理都懂,做起难啊。其实往往产品、项目经理能抗住,上面的领导,市场部的提前投降。
他们要赚钱,只要能接单就行。毕竟他们只负责签单