需求改来改去,高手和菜鸟究竟有什么不同?

1 评论 8934 浏览 26 收藏 11 分钟
🔗 技术知识、行业知识、业务知识等,都是B端产品经理需要了解和掌握的领域相关的知识,有助于进行产品方案设计和评估

在产品和开发日常的工作中,需求改来改去是常有的事,但总有一些人能够化解这种恼人的事,这就是高手。那么相比产品的菜鸟,高手究竟在哪些方面表现得更为突出呢?

最近开发吐槽说,很多的时候,能不能一开始想好了,需求不要改来改去的。

感觉每隔一段的时间,都需要配合改改改,这个真的非常浪费效率。

我当时立刻想起:

某次跟老板在屋子里面对需求文档。

“哎呀,你这个写得太复杂了,一开始不需要这么复杂的呀,这些这些,还有这些都砍掉。”

某次在会议室里面跟开发拆业务需求。

告诉开发同学们,这个地方,先务必使用这个结构,将来方便改,为后续的迭代留好可能性

而我们当前的业务结构不需要这么复杂。那个开发同学立刻说

“那你就跟我讲这个版本要做什么就好了,为什么要跟我说那么多,我本来就事情非常多。”

有的时候被其他人催需求。

“一个案子为什么那么难写,大方向不是会议上都订好了么?你都想了这么久了,快点结束,然后把需求提过去,方便开发干活。”

工作中真的这种事情大量发生。

真想有的时候想怼回去,可是那样还会引起什么别的东西;很多的时候真的是不想解释,因为真的很累;有那个解释的时间,还不如自己闷头做点有价值的事情。

吐槽当然很爽了,但是本文的目的绝对不是吐槽,当然得说说“如何看出一个人的专业度”。

需求文档的水平,就决定了一个人在理解业务时候的专业度。

本文中心思想:

一开始就想明白,然后设计出框架感,以方便未来迭代。

相比:

想到一点是一点,然后根据需求去添加迭代。

在专业上,根本就是两个境界。

一、从两个案例说起

举两个例子吧(不喜欢例子的可以跳过):

1. 游戏行业的礼包码案例

我职业生涯里面写得第一个需求是“礼包码”的需求文档。非常简单,人人都见过。

用户拿到一个几位数的字符串,比如:da3f4ggu6u232f,然后进入到游戏里面,找到一个兑换界面,输入后点击确认,验证通过后,即可拿到事先配置好的游戏道具礼包。

除去兑换成功外,还要考虑多少兑换失败的反馈呢(反正很多的人只考虑正常情况,从来不考虑多少异常情况)?

礼包码就只有一种用法么?

来看看,还有多少种业务场景:

  1. 发布会的场景,希望现场的5000个用户使用一个礼包,用到5000就作废,如何处理?
  2. 当我们使用用户召回行为的时候,是否可以限制注册时间仅允许老用户参与?
  3. 当我们想给新用户发福利的时候,是否可以限制注册时间仅允许新用户参与?
  4. 当我们跟渠道通过游戏礼包换资源,是否可以做到仅仅A渠道参与,B渠道无法参与?

这仅仅是点击兑换回复这一个小的点,这个业务的复杂性,在运营层面也许更多:

  1. 用户需要输入的礼包码要不要区分大小写?
  2. 要不要去掉数字1和0,字母L和O(为什么要去掉呢,用过的都懂吧)
  3. 用户用手输入的礼包码的位数支持多少种排列组合?
  4. 如果礼包码的位数过多,能不能想到一种方式不用手动填写?
  5. 用户拿到礼包码之后,能不能准确找到对应的兑换入口?
  6. 礼包批次激活查询,和客服的单个礼包的查询后台如何构建业务查询字段以及逻辑?
  7. 如果有人的礼包码被盗异常丢失,被人挂在淘宝上卖,能不能把某个批次的礼包作废掉?

……

后面的问题我还可以提出20多个。

2. 互联网行业的优惠券案例

这个业务更好理解了。

比如说我们在使用美团的时候,经常会收到各种各样的优惠券;在支付的时候,优惠券会自动抵扣一些金额。

仅仅说创建阶段,有多少可以设计的呢?

上面的图片,仅仅是配置优惠券的一个功能设计——怎么投放,怎么使用,怎么查询,怎么管理,每个模块都有不同的细节。

这两个例子,做得好,被认为是理所当然;做的不好,业务能力需要拓展,就只能发起需求,改来改去咯。

想到一点点自然是非常简单,但是每个业务上,实际的颗粒度,是需要考虑得非常细节的。

所以:

“一开始就想明白,然后设计出框架感,以方便未来迭代。”

相比

“想到一点是一点,然后根据需求去添加迭代。”

在专业上,根本就是两个境界。

二、但是,世界上识货的人有多少呢?

如果识货,需要我跟你费力巴拉解释么?

你要是懂,有些问题和话术就不会表达。

你一张嘴,我就知道你的业务段位。

此时此刻来看看本文开始的三段文字。

  • “哎呀,你这个写得太复杂了,一开始不需要这么复杂的呀,这些这些,还有这些都砍掉。”
  • “那你就跟我讲这个版本要做什么就好了,为什么要跟我说那么多,我本来就事情非常多。”
  • “一个案子为什么那么难写,大方向不是会议上都订好了么?你都想了这么久了,快点结束,然后把需求提过去,方便开发干活。”

很多时候,产品们受迫于时间的压力,被强行出那种粗糙的需求文档给开发。

这种产品,可以拿互联网的金句“快速迭代,小步快跑”来安慰自己,可以拿“MVP(最小化可实施方案)”来安慰自己——其实就是自己想得非常粗糙。

好了,祭出我的又一个发明的业务清单:

这张清单,方便各位团队管理者能够看出自己是一个什么水平,能够看出自己的团队是一个什么水平

上面的这张表格,花费的时间,真的非常多非常多,不过在开发的眼里,甚至在很多不识货的老板眼里,或者在很多不明真相的吃瓜群众眼里,甚至本质上,整个开发团队的行为也还是:

第一周,某某功能,产品写文档,开发写写写

第二周,还是某某功能,产品写文档,开发改改改

第三周,依旧还是某某功能,产品写文档,开发改改改

……

可能一个月过去了,也还是改来改去的。

上面的描述,真的仅仅是表象;但是在实际的业务中,产品的境界天差地别。

要知道:高手的改来改去和菜鸟的改来改去终究是不一样的。

一个是事先声明,全盘控制(有些拿不准的,事先声明自己拿不准),但是上线后,可以通过数据论证,收集到足够多的条件,最后做出修订决策。

而另外一个人是在某些领导的压力下,先交付一个版本再说,发现业务表现不行,然后慌不择路,发出亡羊补牢式的需求迭代。

真正的了解到业务细节,才能够判断出谁是高手,谁是菜鸟。

 

作者:饭大官人,微信公众号:fanfan19860403,《游戏运营:高手进阶之路》一书作者。熟悉AI-NLP-创业公司产品负责人

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

题图来自 Unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 最后那个产品水平的表格,值得深思 🙂

    来自北京 回复
专题
12144人已学习12篇文章
数字化平台搭建,适用于企业已经有稳定的业务和资源,希望通过数字化平台做资源变现实现盈利,通过数字化平台将客户、交易、需求、场景全部数据化。本专题的文章分享了如何搭建数字化平台。
专题
14979人已学习13篇文章
在产品的运营过程中,无论是产品、运营还是市场团队,都希望能清晰地了解用户的行为路径,通过用户行为分析,优化用户体验,实现更精准的运营和营销。
专题
18607人已学习15篇文章
库存管理是管理商品和数量之间的关系。本专题的文章提供了库存管理设计指南。
专题
18345人已学习17篇文章
随着互联网的不断发展,不少产品开始了适老化改造,帮助老年人更好地融入智能生活。本专题的文章分享了适老化的设计思路。
专题
16536人已学习12篇文章
本专题的文章分享了产品经理需要知晓的API接口知识。
专题
61109人已学习12篇文章
业务流程图是最常见的图表之一,能看懂读懂是必修课,能绘制便是非常重要的选修课。