产品实操系列 | 如何做一场酣畅淋漓的需求讨论会
“Simplicity is the key to brilliance.
至简，才是通往成功的钥匙。”
——李小龙Bruce Lee
少有人知道，李小龙热爱哲学，他在香港大学研修了哲学之后，终身都致力于把哲学融入武术中。
在我的帮助创业团队做产品这个合集下，前几期的内容，都偏向于“道”。
包括评估产研的进入时机，以及业务闭环、增长飞轮。
现在，我将启动一个新的系列，将偏向于“术”。
就是直接上手，拿一些实操的事情来帮助创业团队，做一些具体的工作。
0、需求从何而来？然后再摆到桌面上
↑我将以此图为大纲，帮助创业团队完善产品能力
今天这一篇，开始针对看板图的最左上角的.
需求分析能力 -> 需求涌现
需求从何而来，当然是从用户中来。
如果这一点都不承认的话，那么简直就是动摇了整个产品这座大厦的地基。
但需求终究要被提炼出来，并且摆放到整个团队的桌面上来供讨论。
那这些，就一定由经验和灵感相结合，才能涌现出来。
一、做好准备工作，功夫都在开会之前
目标是什么？
我们来假设一个在产品工作中经常可能会出现的问题，比如：用户在整个浏览过程中预定转化率太低。
这个问题具备有如下两个特点：
- 这是一个相对具体的战术问题，而不是一个务虚的战略问题——并不是把大家关在一起讨论，公司十年后是什么样子。
- 但缺少很确定的解决办法——工作中大多数问题的解决办法其实就摆在那里，干就完了。
这样的情况就非常适合来开展一次需求讨论会。
否则还是少开会，能少开就少开，任何的官僚主义都会杀死创业团队。
实在万不得已了，管理者没招了，只能寄望于群策群力了，再来开这个会。
由谁来参与？
我们其实应该先要想想，谁不应该来参与？
用户不应该参与
不知道为什么，在很多创业团队中有一个不好的风气，就是在制定内部需求的时候，会邀请用户来参与。
但是用户视角本身跟公司视角是两码事的，尤其是在谈论功能需求的时候，要么会把整个团队过分带入到用户视角中；要么会使用户不能维持住自己的视角。
这样长期上来看，最终让这个可贵的、可长期考察的用户样本就会被浪费掉了。
用户的需求是需要分析的，而不是和用户讨论的，只会讨好和迎合用户，也会杀死创业团队。
Boss不应该参与
或者说，如果老板还持有老板心态的话，就不能参与。
在一个需求分析会上，大家必须平等的，这样的话才能够迸发出奇思妙想，如果老板还是在会议上端着架子，侃侃而谈，只是另外一场PUA会罢了。
这样的话，其实产品负责人就应该拒绝老板参加（强硬点儿，不能只是说说而已）。
技术、推广、客服、销售等部门不应该参与
或者说，如果这些兄弟部门的同事们，缺乏产品需求理念的话，就不能参加。
否则，他们参与了之后，就变成需求收集会而不是需求分析会，他们很有可能会偏离会议主题，提出来很多很多的问题，这些问题不是说不解决，但是会打乱会议主题的聚焦。
好了，那么确定需要参加的人员有：
- 产品专家；
- 运营专家；
- 扔掉Boss包袱的Boss；
- 聚焦问题而不是趁机提意见的兄弟部门成员。
其他不符合，但却真心想参加的人，那就旁听吧。
在哪里开？
当然是在会议室开了，还能在哪里开？
如果能有更好的选择的话，当然不建议在会议室。
因为会议室是一个日常办公的场所，也会相对严肃一些，尤其如果公司内部整体氛围就比较严肃的话。
去公司周边找个茶室，甚至在团队聚餐后就更好了（有些可遇不可求）。
这样的话，大家的精神会更放松一些，灵感会更多一些。
如果一定要在会议室开，可以带一些饮料或者是零食，各种想办法把氛围搞的相对轻松一些。
必须有准备工作
最大的准备工作就是为这场需求讨论会事先准备好：
- 足够多的数据；
- 足够多的前置思考。
在会议需求下达之前就开始准备，不要空着手就来。
否则来了就真的是纯拼想象力了，浪费讨论机会。
必要的时候，产品负责人可以安排硬性任务。
二、怎么召开？三步走
第一步：头脑风暴
很多团队都会使用头脑风暴开会法，但却遗忘头脑风暴最基本的原则：
无论怎样，在这个环节中不允许反驳。
这是头脑风暴的唯一的核心原则。
在这个环节中，任何想法都是被允许的，大家各抒己见，所有人（包括Boss）都不允许说NO！
大家不停的说想法，竭尽全力的去想。
直到把在场的每个人，都压榨的一滴也没有了。
会议主导者要有充分的情绪调动能力，如果参会者变的激情澎湃、大吼大叫、甚至都拍起了桌子，那才是最好的状态。
哪怕是i人的领导，也必须学会调动起大家。
但要注意，整个过程中一定要把每个人的想法都记录下来，这至关重要。
最好能有个黑板，这样人人可见，如果条件不具备，比如在茶社或饭桌上，那么就应该及时把内容发到内部讨论群，也是不错的办法。
↑头脑风暴产出（仅做举例）
第二步：处理内容
头脑风暴完成之后，那可真是一地狼藉，下面就是打扫战场，获取战利品的时候了。
如果说上一个步骤是不允许做评判，那么这个步骤就必须做充分评判：
- 有些说的是一件事，把它们合并到一起；
- 有些说的是一类事，把它们放到一起；
↑ 内容处理产出（仅做举例）
比如在这个例子中，有几个要点要注意：
- 同一件事的内容可以完全合并——比如两个按钮的问题；
- 不是同一件事，但属于同一类内容，而且可以由一个部门负责的问题，放到一组——比如商品展现问题的三个问题；
- 处理内容的时候就是总结的过程，项目宜多不宜少——比如流量属性问题是投流工作负责的，品牌影响问题是品牌工作负责的，虽然谈的都是流量，但不能做合并，否则不利于工作的分配。
第三步：设定优先级
最后设定优先级，把最有可能出现问题的内容来进行排序。
当然在优先级设定的过程中，大家可能会有争议很大，那么此时就需要让大家来进行投票。
投票也是有方法的，比如并非是需要每个人都有同样的票权，比如说Boss是3票（算是照顾面子啊~），产品或运营专家2票，而其他人可能是1票，旁听的人0票。
这便是照顾了不同的人，也尊重了每个人的Power。
↑ 设定优先级产出（仅做举例）
注意，这里关于优先级的设定，可能会需要用到重要和紧急四象限的方法，我将会在后面来进行内容产出。
三、后续处理，一定要做到有跟踪有结果
每一次需求讨论会，对于创业团队来说都是一次高成本的工作付出。
讨论完了就结束，大家光爽了，这样一点儿意义都没有。
一定要在现场拍板，安排工作，负责到人，这样才是有意义的：
列入需求分析计划
部分内容可能会充满了争议，这是非常正常的现象。
比如上个例子中的“价格感觉太贵”、“商品图片看不懂”，可能现场一定会吵翻天。
那么就需要列入到后面的需求分析计划中，这个后面就会讲。
列入需求池
部分内容没有争议，但会是比较明确的话，就列入到需求池之中。
比如上个例子中的“可以考虑接入信用体系，让到货之后再扣款”
这个事情就需要BD、产品、研发三方工作的努力。
当然在需求池中也会有需求优先级排序，这个就由其内部去进行就好了。
列入版本计划
部分比较明确，而且需要立即实施的就会排入到版本计划中，尽快保证上线。
比如上个例子中的“部分情况下页面载入错误，会出现大白页”
明显就是个恶性bug，一定要尽快解决。
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！