邱岳的产品手记
邱岳
无码科技产品经理,公众号二爷鉴书作者
立即订阅
9950 人已学习
课程目录
已完结 48 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 | 产品经理的世界没有对错
免费
01 | 验证码是个好设计吗?
02 | 产品经理工具指南
03 | 产品案例分析·Trigraphy的设计哲学
04 | 如何当好AI时代的产品经理?(学习篇)
05 | 如何当好AI时代的产品经理?(实践篇)
06 | 产品案例分析 · The Guardian的文本之美
07 | 关于需求变更(上):需求背后的需求
08 | 关于需求变更(下) : 化变更于无形
09 | 产品案例分析:Hopper的“人工智能”
10 | 产品被抄袭了,怎么办?
11 | 如何借鉴灵感?
12 | 产品案例分析:LabRdr的设计实验
13 | 无用却必要:产品规划(上)
14 | 留白与节奏:产品规划(下)
15 | 产品案例分析:Mimo与Learn Python的导学之趣
16 | 在内部产品中找到产品经理的价值
17 | 产品经理如何获得非权力性的影响力?
18 | 产品案例分析:WWF Together的情怀设计
19 | 产品经理如何与开发打交道(上):打破思维的边界
20 | 产品经理如何与开发打交道(下):合作与共赢
21 | 产品案例分析:Fabulous的精致养成
22 | 产品经理的图文基本功(上):产品文档
23 | 产品经理的图文基本功(下):产品图例
24 | 产品案例分析:PathSource的混乱与直观
25 | 产品世界的暗黑模式:操纵的诱惑
26 | 写好产品文档的诀窍
27 | 产品案例分析:Quartz&Hooked的对话式交互
28 | 产品分析的套路(上):谁是利益相关者?
29 | 产品分析的套路(中):解决什么问题?
30 | 产品案例分析:Primer的扑克牌交互
31 | 产品分析的套路(下):如何出解决方案?
32 | 从受众规模、需求频率和强度出发:排定需求优先级的方法(上)
33 | 产品案例分析:Arts & Culture 的架构之美
34 | 价值曲线分析:排定需求优先级的方法(下)
35 | 答疑时间:关于产品经理的12个问题
36 | 产品案例分析:解读知识星球
37 | 如何做好需求评审(上):需求评审不只是一次会议
38 | 如何做好需求评审(下):在评审中控住全场
39 | 产品案例分析:SeatGeek的订票设计
40 | 新年给产品经理的几碗鸡汤
41 | 产品经理的项目管理心得
42 | 产品案例分析:Unread的阅读体验
43 | “玩”的力量:从游戏设计中学习产品设计(上)
44 | “玩”的启示:从游戏设计中学习产品设计(下)
45 | 产品案例分析:Chartistic的“复杂”图表
尾声:你的快乐是哪一种
【第二季回归】二爷归来,再次扬帆起航
邱岳的产品手记
登录|注册

37 | 如何做好需求评审(上):需求评审不只是一次会议

邱岳 2018-02-13
“问渠哪得清如许, 为有源头活水来。”
——朱熹
几天前收到了一位专栏读者的留言:说自己在现实工作中发现,大家并没有把需求评审这件事情放在心上,有些同事对业务并不熟悉,或者没有建设性心态,觉得潦草交差即可,所以在评审阶段不重视需求方案,认为反正都是产品经理的责任。
他在留言中问我有没有什么办法能让大家转变心态,可以关注产品,而不是简单地交付项目。
这个问题我也遇到过,而且一直持续地遇到,即有我主持需求评审别人心不在焉的时候,也有别人的需求评审我走神儿的情况。
年轻的时候我想了不少歪门邪道让别人在评审阶段关注需求和方案,对需求评审用心,承担责任。
比如提前发出文档然后针对文档问问题,比如要求必须提出两个以上的反馈,或者让工程师来主持需求评审,甚至还干过把评审结论打印出来让业务部门代表在纸上签字的事情。
所有的这些方法和手段在刚提出来的时候都会有一定的效果,但随着大家逐渐习惯,它们就会形式化,然后我们又去寻找新的流程化手段,周而复始,流程越来越重,效率也越来越低。
那应该怎样优化需求评审呢?今天我就来谈谈自己的一点经验和思考,希望可以给你带来启发。

1. 当我们谈论需求评审的时候,我们在谈论什么

当我们谈论需求评审时,第一反应会觉得它只是一个环节,可能包括一次会议,几封邮件。但我们不能局限在一个流程切片的角度去理解和讨论它,需求评审串起了前期的需求收集和分析,不同利益相关方的博弈,以及后续项目落地实施的计划管理等各个方面,评审会议本身只是露出水面的一角,想让评审更有效,事前和事后都要做不少工作。
正因为如此,需求评审也成了对产品经理综合能力的一次考验,我曾经有个同事把需求评审会称作是产品经理的 Show Time(表演时间),如果完成得出色,不但项目会顺利很多,也会为自己在团队中的影响力加分。但是,对于那些能力欠缺、准备不充分的产品经理来说,也可能会是一场噩梦。

2. 需求评审的受众、目的

作为产品经理的下意识反应,任何事情都应该先去追问:“解决谁的什么问题”。对需求评审来说,就是要先弄明白需求评审的受众和目的。我们通常意义的需求评审,是产品经理完成需求收集和分析,确定解决方案之后,面向两个角色,做四件事情。
第一件事情是向需求方以及其他利益相关方详述自己对需求的理解和分析,明确我们的需求分析与他们的原始期望是一致的。通俗一点讲,就是需求方(包括用户)说了自己需要什么东西,你思考和挖掘他们背后的动机之后,用自己的理解复述给他们听,确定自己的理解是不是正确。比如用户说要一匹更快的马,你分析需求和场景之后,认为他的动机是希望更快地到达目的地,把你的分析过程讲给他听,并同他们达成一致。
第二件事情是向设计、研发和测试团队,也就是需要去实现产品的这一票人,讲清楚需求的背景和来龙去脉。这个在我们之前怎样与工程师相处的分享中也提到过,不能只交代做什么,还要交代为什么做。这个事情本质上跟刚才提到的,向需求方详述对需求的理解和分析很像,只不过受众不同,可能需要多交代一些背景。
第三件事情,是向需求方交代具体的产品解决方案,也就是他们将要得到一个什么东西,是一个按钮,还是一个表单,还是一段没有界面的逻辑。这个东西会如何出现在他们的工作场景中,以及会如何跟他们发生关系,让他们的工作发生什么变化。
第四件事情,则是向开发团队交代产品解决方案,设计师、工程师需要弄清楚自己将要制造一个什么东西,长成什么样子,怎样运转,有哪些特性。这也是我们提到需求评审之后可能想到的第一件事情。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《邱岳的产品手记》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(8)

  • 刘祯
    感谢二爷的良苦用心。

    之前遇到这些困惑,的确是自己对于产品工作或是需求评审这件事的重视程度不够,在自己尚未准备充分或是考虑清楚的情况下寄希望别人来共同参与,这是不负责任的表现。作为产品经理,首先要认真做好自己的本职工作,从二爷提到的很多细节上,我还有很长的路要走。

    能够清晰、完整地将自己的业务流程和逻辑具象化表达,并且让大家统一思想,提前沟通,这本身就是对产品经理的综合考验。

    我真心认同二爷说的「需求评审应当是凯旋的钟声,而不是冲锋的号角」。两者的差异可见一斑。

    年前经历的那次需求评审并不完美,时间紧迫,只好提前用正式机会和大家沟通,这就造成很多不确定性,这是我体会最深的。希望年后回来能够认真做好每一件小事。

    感谢二爷的辛苦付出,提前祝大家新年快乐,万事如意~

    作者回复: 谢谢刘祯,每次读你的留言也很有收获,祝你新年快乐

    2018-02-13
    6
  • CC
    今天的分享中关注到两个关键词:

    “冰山一角”,不能局限在一个流程切片的角度去理解需求评审。这让我想到足球比赛中的“临门一脚”。这一脚固然精彩,但更重要的是之前的传接配合。首先要在会议之外下功夫,会议才有达到预期的可能。记起在之前的分享中学到的,非正式沟通是会议之外很好的补充。

    “意外”,生活中意外有可能是惊喜,而项目中的意外往往相反。面向两个角色,做四件事情,目标就是统一期望值,让产品在需求方和开发团队的脑海中的形态统一。第一步尤其重要,可以通过之前关于需求变更的分享中提到的“五问法”,挖掘背后真实的需求。

    我作为前端程序员,其实也可以从自己的角度出发去促成与产品经理的沟通。比如,可以主动一对一跟进,了解需求背后的缘由,以及需求文档上自己需要重点关注的地方。

    谢谢二爷分享,春节快到了,提前祝二爷和一起讨论的极友们新年快乐。
    2018-02-13
    5
  • 周阿冰
    很想交流一下。
    我不是产品经理。最早是测试工程师,现在是项目经理。
    深深认同二爷的这两个观点:评审的四个目标和手段是为目标服务。评审会能不能开好,就看是否达成这四个目标。
    然而,现实情况是需求评审会很不容易开好,一旦有某一方掉链子,会议效率低下还是轻的,重则研发过程中天坑滚滚。
    在遇到各种问题之后,我们制定了评审会的几个重要原则:1.重在评审,不能开成培训会;2.产品经理必须在会前和需求方充分沟通,确保可以实现业务目标;3.大需求必须在产品框架方案构思阶段和技术负责人沟通,确认可行,并且实现成本尽可能小;4.大需求必须和业务负责人就方案达成共识。
    此外,我们还围绕会议效率和质量定了一些细则要求。
    最近几个月,我们遇到了一些糟糕的情况,因为需求方调整了策略或者当初没规划清楚功能的使用,花费大量资源开发出来的一些功能基本不使用,甚至搁置未用。
    这对团队造成了极大的伤害。我们因此做了一些调整,在需求评估阶段,产品经理要合理评估需求的价值,需求方要阐述清楚未来使用该功能的规划。如果产品经理或者产品团队不具备可以评估需求价值的能力,依然有可能会存在这种问题。
    2018-04-13
    4
  • Dylan
    文档发出之后一对一进行指导和跟进,这是一个站在对方角度去高效处理问题的好方法,学习了。其实需求评审应该是个很高效的达成共识的会议,总结过往展望未来,很有必要。
    2018-07-23
    1
  • 雪甫
    会而不议 可能是需求评审的最高境界了吧,所有问题都在事先沟通解决了,会上只是大家一起确认一遍,而不是讨论需求,更不是读需求
    2018-02-26
    1
  • yaxin
    学到的最重要的一点是,完成需求搜集和分析后,产品经理要事先与相关人员沟通。再有,要提前发出需求评审的材料,让大家提前熟悉评审内容。但不能只是笼统发出去,要指出不同人需要关注的地方。
    2019-02-20
  • 罗帅
    讲的很细,虽然我只是一个程序员,但是听过之后对产品经理工作更加理解了
    2018-05-06
  • 林彦
    二爷,一个to B的小硬件公司(30人以下,也有软件和云服务),只有需求方和开发团队,需求方是商务总监和销售,开发团队很少第一线与潜在和已有客户沟通(唯一直接接受客户反馈和投诉的工程师快自己蜕变和被定位成支持工程师了)。最近请了一个做过硬件行业品质和项目的资深经理担当项目经理的角色,他对软件开发了解得比较少。这种情况下除了空降外,什么样的人,或现有的团队和角色里,谁比较适合当或发掘成产品经理,原因是什么。如果外部空降是更好的解决办法,看重候选人的哪些特质,技能,过往经验,现有公司从哪些方面支持他更有助于他融入和为团队贡献价值。

    这个话题有些大,二爷能回答一两点我也很感激😀

    作者回复: 林彦你好,由于不了解行业和人,我的所有回答都仅供参考。

    可以考虑从资深工程师中选一个有商业意识的人来承担产品经理的职责,商务上的东西可以通过旁观和讲授来大致理解对话,而技术则通常需要一些时间和背景知识才容易对接。

    空降的话,最重要的还是人品吧我感觉。听你说感觉是toB的团队,那希望他尽快能理解toB的逻辑吧

    2018-02-13
收起评论
8
返回
顶部