第2章 一个需求的奋斗史

对于产品经理来说更重要的是“发现一个问题,然后设法将其转化为一个任务来解决”
需求采集的过程,都会有如下几步:明确目标、选择采集方法、制定采集计划、执行采集、资料整理,然后进入下一步的需求分析阶段
2.1.1 用户是需求之源
研究需求可以增强对用户的理解,而理解用户,是产品经理最重要的素质之一。
不同的用户有重要程度之分,我们必须、也只能有所偏重。
以用户为中心的思想
UCDChina.com上有不少相关话题,能给做产品的同学很多思路上的启发。
帮助老板明确问题和需求的价值,为其决定方向提出参考建议,或协助其实现目标(当然,前提是老板要做的事情不违背你的价值观)。
不要试图满足所有用户试图满足所有用户的需求是一个灾难,那会让产品变成一个臃肿不堪,谁都不满意的四不像。
优先满足哪些用户需要和产品的商业目标要结合起来考虑
体会真正的用户-想了解用户,光靠空想是不行的,他们是真实的,是五花八门的,必须得真刀真枪地去研究他们。
试着描述用户《赢在用户:Web人物角色创建和应用实践指南》。
图2-3 用户研究的方法
2.2 需求采集的大生产运动
图2-4 常用的需求采集方法
2.2.1 定性地说:用户访谈
用户访谈的常见问题与对策
第一,“说”和“做”不一致的问题。样,尽量在用户可以和产品发生交互的场合下进行,让用户在“说”的同时也“做”。
第二,样本少,以偏概全的问题。
第三,用户过于强势,把我们往沟里带。要解决这个问题,需要时刻牢记访谈的目的。
第四,我们过于强势,把用户往沟里带。牢记访谈的目的,并且管好自己的嘴。
《软件观念革命:交互设计精髓》
2.2.2 定量地说:调查问卷
设计一份实际的问卷
2.2.3 定性地做:可用性测试
可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题,通常只能做少数几个用户的测试,看他们怎么做,属于典型的定性研究。
首先要招募测试用户,然后是准备测试任务,接下来的重头戏是测试过程,最后是研究和分析。
对于改版,对于升级,我们要把“暴力革命”变成温柔和谐的“和平演变”。
2.2.4 定量地做:数据分析
数据分析的常见问题与对策
第一,过于学术,沉迷于“科学研究”。
第二,虽然数据不会主动骗人,但我们经常无意或有意地误读数据。
第三,平时不烧香,临时抱佛脚 应该在产品设计的时候就把数据分析的需求加进去
数据分析是如何转化为商业价值的?
整体的思路是:在对产品足够熟悉的基础上,先做出方向性的假设,再提取相应的数据并分析,得到一些现象,最好是之前没发现的现象,然后尝试解释,接下来做用户调研修正解释,最终指导产品发展方向。
2.2.5 需求采集人人有责
二手需求采集工具——单项需求卡片
单项需求卡片的理念就是:产品的需求工作不只是需求分析人员的事,而是涉及
产品的每个干系人的义务,至少得参与“采集”的过程。
一张单项需求卡片描述了一个用户需求到底包含哪些内容,重点是描述用户场景,
谁在什么时间、地点产生了何种需求。
表2-3 单项需求卡片模板
单向需求卡片所描述的用户需求,最终要转化为产品需求才有真正的价值。
最后再简单分享几个有特点的需求采集方法,
现场调查
AB测试。
日记研究
卡片分类法。
自己提需求。
2.3 听用户的但不要照着做
深挖用户内心根本的需求
要听用户的意见,但不要照着做。我们是产品经理,最终怎么做应该由我们决定。
2.3.1 明确我们存在的价值
用户跟福特要一匹更快的马,福特却给了用户一辆车。
用户需求VS.产品需求
用户需求:用户自以为的需求,并且经常表达为用户的解决方案。
产品需求:经过我们的分析,找到的真实需求,并且表达为产品的解决方案。
需求分析:从用户提出的需求出发,找到用户内心真正的渴望,再转化为产品需求的过程。
伟大的需求分析师,可以无视用户想要的东西,去探究他内心真正的渴望,再给
出更好的解决方案,或者说是用户真正需要的东西,这就是本节标题的意思——我们
存在的价值。
需求来源于理想与现实的差距,那么减小这个差距就有三种方式:
提高现实,改变现状
降低理想
转移需求。
产品设计的最高境界——创造需求。
2.3.2 给需求做一次DNA检测
图2-10 需求的DNA检测过程
(1)把用户需求转化为产品需求
头脑风暴
Excel来记录需求,Feature List(功能列表)
用户需求与产品需求是多对多的关系
需求转化过程中,我们也会做一轮筛选,把明显不靠谱的用户需
求直接过滤掉,不计入上述列表
(2)确定需求的基本属性
需求种类知多少
层次:把需求分成“基础、扩展(期望需求)、增值(兴奋需求)”三层,理论
依据参见KANO模型
(3)分析需求的商业价值
(4)初评需求的实现难度
绝对不能因为某个需求的实现难度很小就马上去做,也不能因为另一个需求的实现难度大就不做。
开发量是非评估不可的,我把它叫做“初评”,允许误差,并且会要经验丰富的
人来评估,通常是技术经理,或者系统分析师、架构师
(5)性价比
性价比=商业价值÷实现难度(简化为开发量)
“性价比”一列从大到小排序,先做排在上面的就可以了
2.4 活下来的永远是少数
图2-16 需求筛选
准备出发:把需求打个包
做项目,终极目标就是:多快好省,即范围大、时间短、品质高、资源省。
战场:产品会议
武器:商业需求文档
BRD 怎么写
项目背景,商业价值,功能需求描述:非功能需求,描述资源评估,风险和对策
少做就是多做。情愿一半功能做到完美,也不要所有功能做成半吊子。
做的少不如做的巧。空肥皂盒的故事。
尽可能多地放弃
文章为从个人wps文档粘贴,无法复制图片,图片可看原书。
网友评论