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

17 评论 8181 浏览 82 收藏 9 分钟

碰到一味加需求的甲方爸爸,产品人需要学会拒绝,控制需求边界,才能控制产品的上线时间,把握产品效能。

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

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

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

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

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

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

需求边界的重要性

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

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

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

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

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

需求层面

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

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

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

项目层面

1. 规范流程控制边界

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

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

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

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

2. 确定需求冻结时间

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

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

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

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

商务层面

1. 落实合同和验收标准

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

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

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

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

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

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

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

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

总结

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

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

 

作者:晴天;微信公众号:impm6666

本文由 @晴天 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 面向B端用户使用的产品,技术团队中如果没有一个非常熟悉传统业务的产品经理,技术再好,也会改到你哭的。

    回复
  2. 确定项目边界比确定产品边界更重要(你提到的是甲方)

    回复
  3. 做起来难!业务方自己对需求没有清晰认知,产品出来落地难,试行困难,只能修改。

    回复
  4. 自己开公司,你就不这么想了。在利润面前,只能跪下

    回复
    1. 需求无边界,哪里来利润?

      回复
    2. 外包也可能是人力外包,只管做项目,按投入人力算钱,这样不必太纠结需求变动

      回复
  5. 越发觉得产品经理岗位是块狗皮膏药,哪里需要贴哪里。

    回复
    1. 哈哈哈 这个是!

      回复
  6. 还是有一点理想化。主要看甲乙双方的谈判地位如何。如果甲方是大客户,你得罪不起,人家的临时需求,乃至超边界需求你还是会去满足。现实就是这样。

    回复
  7. 能做到这样还得自身公司的产品流程是规范的,对输出的原型、UI设计图是有自信的,目前来说能达到这种实力的公司团队太少了

    回复
  8. 需求若是真到领导那里了,十有八九是给他做

    回复
    1. 还真是

      回复
  9. 有必要对公司商务、销售等岗位加强业务边界的培训,从一开始的招标书就划定边界,就怕什么都敢往里面写,后面产品经理和项目经理就很被动了。

    回复
    1. 点赞👍🏻

      回复
  10. 感觉是瀑布式研发流程

    回复
  11. 道理都懂,做起难啊。其实往往产品、项目经理能抗住,上面的领导,市场部的提前投降。

    回复
    1. 他们要赚钱,只要能接单就行。毕竟他们只负责签单

      回复