Skip to content

如何砍需求

发表于:2020-09-03 00:22:58阅读量:

砍需求的核心是:开发如何理解产品的需求,并根据自己的理解给出产品建议。

快糙猛

对于中小型项目来说,做事更讲究快糙猛,原因:

  1. 适合小团队
  2. BUG 影响到小范围的用户
  3. 相对来说投入产品比很高

对于大型项目则不行:

  1. 产品做的事情有时候是基于对数据的判断,但大多数时候是基于直觉
  2. 用户量多的时候会影响到较大范围的用户
  3. 规模效应,BUG 会导致大量负面评价

一切都是收益和损失的权衡

Case 生命周期

cumd

创造需求 - 补充/修改需求 - 砍需求

create 创造需求

  • 最离谱的错误,没有需求创造需求
  • 要钉子还是要洞还是要锤子(用最简单的方案解决问题)
  • 提需求还是提解决方案(用户需求和解决方案要分清楚,用户需求是高于解决方案的,如果你一开始就把两者混为一团,你就很难再提出更好的解决方案)
  • 我什么都要(猜测用户意图)
  • 在错误的地方做过度设计(在一个用户量很少的场景去做提高转化量的工作毫无意义,因为数据太少所以导致数据波动大,这时候还不如想办法提高用户量)

update/modify 补充/修改需求

  • 容易忽视数据逻辑
  • 猜测用户意图

猜测意图其实是一种常规方式,不是说这个完全不对,而是要学会根据数据反馈来证实自己的猜测,如果数据反馈证实你的猜测是错误的,你会因为 case 需要优化,这个就没完没了了

改需求跟炒股一样,要有止损线。

delete 砍需求

向所有做减法的产品经理致敬

发生以上问题的时候我们如何发现

反复问一个问题,问自己、问产品、问运营、问市场、问客服

用户要的不是功能,是要解决他们的问题,一定要先跳出产品功能

反复问这四个问题:

  • 是谁的问题(是用户的问题吗?还是市场的问题,运营的问题,客服的问题,他们的问题跟用户的问题是一个问题吗?)
  • 这个问题是不是真实存在的问题(有没有数据/用户调研,是不是预设立场)
  • 是不是只解决这一个问题(coding 有个原则,一个方法只做一件事,产品 case 同理)
  • 解决这个问题有没有更快更好的方案(要准确区分出需求和解决方案)

Case 发布后

  • 产品和技术都应该对需求研发和执行过程中的问题做 review
  • 研发关注优化 代码逻辑/效率优化 底层数据结构优化
  • 产品关注数据 (实际上研发比产品更了解这个需求上线后会发生什么,研发也应该关注数据)

总结一下,尝试新需求的时候,最小化的去做事情,而不是又大又全