请选择 进入手机版 | 继续访问电脑版

ITIL,DevOps,ITSS,ITSM,IT运维管理-ITIL先锋论坛

 找回密码
 立即注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

查看: 33|回复: 0

产品决策:如何决定需求做与不做

[复制链接]
发表于 2022-1-10 14:54:30 | 显示全部楼层 |阅读模式
本帖最后由 FYIRH 于 2022-1-10 14:55 编辑 4 h9 U+ S; ^* W( b% Q5 _4 X
$ i- r! m. ?  S+ h; m* N. {
在产品开发的过程中,产品的内部、外部利益干系人会提出很多自己的期望;每个产品版本发布后,团队会收到用户的反馈意见。作为产品负责人,你会发现随着产品继续向前推进,收到的需求会越来越多,总有堆积如山的需求等待着团队去做。因此,判断某个需求做与不做,成为产品负责人需要做出的至关重要的决策。

0 F3 I! Z, m' x7 F) B' ~+ M
产品决策要以“用户或客户场景驱动”为核心,即面对一个需求,首先,判断这是否是用户或客户真实的需求,以及这个需求是在什么场景下产生的。其次,如果是真实的需求,再进行竞品分析,分析同行竞品是否有这个功能。如果有,它们是如何设计来满足用户需求的?如果没有,它们可能会有什么考虑?如果我们要做这个功能,设计方案是什么,如何确保竞争力?最后,看内部资源是否具备条件,可以使这个功能在合适的市场窗口期推出。
7 A# F! h# A# {0 ^* e- O0 y  U8 t
整个过程如图8-18所示。
粘贴上传202201101452414070..png
图8-18产品需求决策过程示意图

$ @- Y) S0 s) I& @1 O
在很多企业里,产品的大量功能不是来自客户或用户的真实需求,而是来自于以下几个方面。

( ]- y' S4 k6 K3 j

& \) ^5 D. e, `5 E3 C
(1) 产品负责人自己的假设。产品负责人依据自己的经验和知识来判断某个需求是否应该做。然而,需要注意的是,判断某个需求该做的依据是什么?是有相关的用户场景经历,还是自己单方面的假设?很多时候,产品负责人自己都难以区分那是个需要验证的假设,还是已经被验证的结论。
- _' Z! j. n! ]3 c0 W0 Q
(2) 对市场上竞品的模仿。很多负责人看到竞品有什么功能,自己就急忙做什么功能,这是最大的忌讳。产品要体现的是自己的核心价值主张,而不是别人的核心价值主张。大量地模仿竞品只能说明自己不自信,不知道做什么功能更好;或者说明人家的某个功能设计得太好了,我们无法超越和创新,只能跟风、抄袭。
0 L6 N- N7 v- R' Z
(3) 年度战略规划。很多企业都会做年度战略规划,由于规划要汇报给高层领导,因此要做得高大上才行。然而很多贴近用户的功能没法拿得出手,因为那些不吸引高层的眼球,进而无法争取到这个产品所需的资源。于是,战略规划里的产品成了“航空母舰”,而实际上也许用户只需要一艘“小快艇”,一些用户不需要的设备也被装到了这艘“小快艇”上。

: ]$ n$ J( d2 y; h2 i4 ?* I5 B! ^
(4) 行业竞争。有些企业喜欢用“行业领袖”“业界第一”这样的目标牵引所有产品的发展方向,这使得产品负责人将注意力放到了虚荣的先进性上,而不是扎扎实实地以用户为中心。需要注意的是,先进性与满足甚至超越用户的期望不是一回事。比如,一个社交产品有先进的人工智能技术,可以智能化地向你推荐你有兴趣交往的人。但是如果连像聊天这样的核心基础功能都做得令用户体验感很差,那么即使人工智能技术再好也是白费。

: p' g9 P  v! m- b4 i$ W
(5) 领导指示。很多企业的产品,尤其是在ToB产品的Backlog里,经常有“某总”的一句话需求。诸如在某次汇报上,“某总”提出,应该做……,于是这句话就被录进了产品的Backlog里。而且有这样不成文的惯例:领导的职位越高,他提的需求的优先级就越高。
9 L) I) u' i8 N, ?9 ^* t
当然,上述渠道的需求并不是一律不该做。不管从什么渠道获得的需求,都要将其带到用户或客户的场景中去分析。即使需求成立,还要考虑档期,以及与其他需求相比,其优先级是否足够高,从客户价值角度分析,是否值得做等。所以,决定不做某项需求比决定做某项需求更困难,也更重要。

2 M) o4 _6 J! z6 K8 j9 _& a% U
即便是用户或客户的原始需求,我们也需要小心甄别。以用户为中心,听取用户的反馈,并不意味着用户提出的所有的需求都要去做。根据经验,用户提出的需求里有70%都是不需要做的,但是我们要聆听用户全部的反馈,否则就无法筛选出来那些该做的30%的需求。
- C. q. ~7 R) J. f* ?/ v# @
不管是什么类型的产品,我们都要仔细分析需求,比如,用户或客户要解决什么问题?这个需求在什么场景下发生,是不是刚需?具体来说,当面对一个需求时,我们可以做好以下工作。
' s- z0 ?) C+ K: n3 p. ~
1.还原需求

- P2 c# ]5 D- m" B+ a( ~
很多情况下,用户以为自己提的是个需求,其实这是他/她脑子里设计的解决方案。所以我们要分析用户需求的本质,思考用户提出的是需求还是解决方案。
/ e- k# m% i: F1 u/ X5 K5 s* C4 G
我在做电子看板工具产品的时候,一个用户向我提出:“我希望产品有邮件通知功能,每天早上8点钟提醒我有哪些事情需要办理。”

- R. ?9 @$ U* A! X* w1 N
这个陈述是个典型的需求解决方案。用户的真实需求是:“我希望有个方法能提醒我有哪些要做的事情,以便于我安排好当天的工作。”至于是采取邮件通知的方式,还是其他方式,提醒时间安排在几点合适,这些都属于解决方案的范畴,需要深度挖掘用户的场景才能设计出合适的解决方案。如果我们直接做个邮件通知,每天早上8点钟定时发送邮件,那么这些邮件最终很可能成为垃圾邮件。因此,千万不要把用户提出的所谓“需求”直接收录到Backlog里,我们一定要做需求还原的工作。

* L, A0 C  D' V) K( L# ?5 W+ q
2. 用场景化甄别出伪需求
( w9 g* U4 A5 ^7 A( B
用户提的需求会在什么场景下产生?对以下问题进行分析,就可以甄别出其是否为伪需求。

2 q% w$ m! A9 F& O1 Y9 |
  • Who:哪些角色参与。
  • When:什么时候、在什么条件下发生。
  • Why:要解决什么问题。
  • HowOften:以什么频次发生。
  • How:怎么发生。. O1 I, Y1 U0 k: x; S; f0 R) C$ A
# W3 Q- p$ r8 f$ o" Y$ d8 b9 c% P
还是拿我做的电子看板工具为例。曾经有用户向我的团队提出这样的需求:“我希望将团队看板的几个不同视图做切换,每天动态轮播。”团队觉得这个主意很好,就放到了Backlog里并向我提议。我了解后,与用户做了如下访谈。
0 Q: k1 i; ?- Y8 z. ]0 X
我:听说您想要实现看板不同视图的动态轮播功能,请问您想要解决的具体问题是什么?

; ^( k3 n" o& P% D0 D) p
用户:现在的看板需要手工切换不同的视图,不能自动播放。我们希望自动播放,不用我手工操作。
: L) Y7 z3 ]3 z) @" E) k
我:那么您是希望在什么情况下看自动轮播呢?用户:每当我走过去的时候会看一眼。

- k: t0 `5 V* f
我:您每天大概什么时候会去看?

/ a9 G. w: L5 ~+ o4 W. U
用户:主要是开站会的时候,平时偶尔也会走过去看看。我:你们开站会的时候,主要看哪些东西?
8 Y: |3 n: p3 Z& _9 _8 O
用户:主要看用户故事的状态,然后看每个人名下的任务状态,最后看看Backlog里还有哪些重要的需求没有启动。一共三个视图。我:现在手动切换这三个视图有什么不方便的吗?用户:其实也没有,一键就切换了。

2 a  Y1 w3 W; @2 t) h1 J2 w- x
我:那么自动轮播能在哪些方面帮助到你们呢?
' S: g& Y" K% [" O3 v# z
用户:如果有轮播,平时我路过的时候看一眼感觉会很不错。
, J" W' {' M- s2 D" u& [- @4 M( i
通过以上访谈我们可以看出,用户提出的这个需求并不是他真正需要的。这是个典型的伪需求,用户对此并没有察觉。

" Z/ J4 c- n' s- m
3.判断是否是刚需、高频或大客户的需求

0 f7 z5 K6 r. r  t2 _5 @
排除伪需求后,我们再来分析这个需求是不是刚需,即卡诺模型里的“必备属性”需求。如果是刚需,我们再判断用户对需求的使用频次。如果这个需求是刚需、高频,则应该做;如果这个需求是刚需、低频,则需要判断是否会带来其他方面的价值,比如对于ToB产品的大客户来说,虽然可能某个需求的使用频次低,但对于客户的商业价值很高,同时也会带来较高的收益,因此我们可能还是会选择接纳。
) \" o% o& u6 N* L
产品里的那些刚需、高频的特性是需要重点打磨的地方。例如微信的发送消息、发朋友圈等特性是典型的刚需、高频特性。因此,我们一定要重点打磨这类特性,给客户最佳的体验感。
* Q# T# |# A1 p$ E
4.判断是否解决了“更”的问题

" W& V, j$ k  a8 u
与用户现有的解决方案相比,我们完成的这个需求有什么优势?是否带来了副作用?
" k. w8 q5 j# n1 ]& S7 ^8 G" [# ?
一个大多数人都看不到的事实是,在绝大多数情况下,用户远没有其自己说的那么“痛”,因为他已经在用一些工具或者方法解决他遇到的问题。在这样的情况下,需求意味着更快、更便宜、更方便等。比如,微信比短信的即时通信方式更便捷。
0 V  Q* f% C6 O: ^6 D/ R# T9 Q. U
如果你将需求做进了产品之中,却对用户现有的解决方案没有更大的超越,那么这个需求就白做了。

+ c2 Q$ I0 Z# ~$ E7 o0 _4 N2 H
还是拿我做过的电子看板工具为例。我曾经深入客户中调研,发现一些客户雇用专门统计度量数据的QA人员,他们负责从各种工具里导出数据到Excel中,生成了大量的度量数据。对此,我迸发出一个想法:如果把一些核心通用的度量数据做到产品里,这些QA人员就可以解放了。客户听了我的提议非常高兴,于是我赶紧让团队去做。

6 x  ^7 d% M- n* [7 x8 c7 u
这个功能上线后,我兴奋地向这几个客户通知了上线消息,客户点赞,还要求我们给他们的团队做培训,讲解怎么使用。但是过了一段时间,我查看了产品的运营数据,发现客户从没有访问过度量页面。于是,我回访了客户,客户说:“大家已经习惯了采用QA人员发布的度量数据报告,那个报告很全面,而且QA人员将报告发到邮箱里,我们只需要看邮件就可以,不用登录你们的工具看数据。”

6 [% k& |- W9 q  E. ]
结果是,这个需求没有达到原来设想的目的。究其原因,这个解决方案并没有更大地超越QA人员的报告。
3 m4 j3 s) `1 v+ e
5.判断是否是全流程的需求

. e: ^. g. z7 H4 X9 F5 v9 C% j
如果需求只是全流程场景中的一部分,我们就要思考是否可以将其延展到全流程场景,如果不能延展,那么这个需求与用户现有的解决方案衔接起来是否流畅。
% m- Q2 M: z/ {
在上述案例中,如果我们将需求延展到全流程场景,那么产品不仅能生成度量数据,还可以定制化地生成报告的内容。这样的话,用户从管理需求、跟踪度量数据到接收数据报告的全流程所需就都实现了。可是如果我们只做了前两个部分,而没有解决第三个部分“接收数据报告”的问题,那么用户自然还是喜欢既有的解决方案。

$ Y5 S$ X9 F  L2 K" ^

, M0 ]' t- \2 Z3 Q' ~5 J! O6 s" E+ @' `) `% d7 K! m0 Y




上一篇:如何决定敏捷需求的优先级顺
下一篇:将用户体验设计纳入敏捷流程
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

参加 ITIL 4 基础和中级专家认证、v3专家升级、DevOps专家认证、ITSS服务经理认证报名
本站关键字: ITIL| ITSM| ISO20000| ITIL培训| ITIL认证| ITIL考试| ITSS| ITSS培训| ITSS认证| IT运维管理| DevOps| DevOps培训| DevOps认证| itop| itil4| sre| 开源ITSM软件

QQ|ITIL先锋论坛 ( 粤ICP备11099876号 )|appname

Baidu

GMT+8, 2022-1-20 19:49 , Processed in 0.107984 second(s), 31 queries .

Powered by Discuz! X3.4 Licensed

Copyright © 2001-2020, Tencent Cloud.

快速回复 返回顶部 返回列表