人人都是产品经理-一个需求的奋斗史

  1. 首先确定目标用户-对用户进行研究
  2. 需求采集
  3. 需求分析
  4. 需求筛选
  5. 2-4部可以统称为需求管理
  6. 最后是需求开发

对于产品经理来说更重要的是发现一个问题,然后设法将其转化为一个任务来解决。

2.2 需求采集的大生产运动

  1. 需求采集的过程:明确目标-选择采集方法-制定采集计划-执行采集-资料整理-需求分析
  2. 定性得说:用户访谈
    一对一聊天的形式,一批次一般是几个到几十个,每个人勇士几十分钟到几个小时,围绕特定话题。我们问用户答,用户说,我们听。这是定性研究。
    目的是了解用户的目标和观点,并分析现象的原因。
  3. 用户访谈的常见问题以及对策

    1. 说和做不一致的问题:原因:问了一个自己也没仔细想过的问题,不想回答不知道,就现场编造有理有据的理由。或者他们有讨好访谈者的心里,会回答他们觉得你希望听到的答案,那不是真正的想法。解决方法是在用户可以和产品交互的场合下进行,让用户说的同时也做。另外,区分用户的事实与观点,一般来说诸如我做了什么,步骤如何,碰到什么问题的可信度高,我觉得,我认为这类观点要存疑,
    2. 样本少,以偏概全:尽量识别引起偏差的因素,并在访谈报告里表明。利用增量访谈:先问五个得出基本结论,再访谈五个看结论是否有改变,如果有改变就思考是否合适,并加大样本量。
    3. 用户过于强势,把访谈者往沟里带:时刻牢记访谈的目的,发现话题不对就往正道上掰,掰不过来可以考虑尽快结束。
    4. 我们过于强势,把用户往沟里带:牢记访谈目的,管好自己的嘴。
    5. 用户访谈注意点:
      image_1c65bjn6r1hk4ao11c41gfa1edkp.png-102.9kB
  4. 定量的说,调查问卷:不适合安排问答题,不适合超过十分钟,开篇放不需要思考的问题,需要思考的敏感问题放中间,个人信息题放最后。
    1. 表明是哪些特定城市的用户,那些特定时间场景的用户,标注在问卷报告上。活着吧目标群体的特征也定义成一系列问题,放入问卷中,再根据这些问题评估做答者是否是目标群体。
    2. 样本过少时会有问题
    3. 问卷表述应该没有引导性:比如不要问你喜欢这个产品吗,而应该问你是否喜欢某个产品。被调查者趋向于选择第一个或最后一个答案,对于一组数字,如价格和打分,趋向于取中间值,为了减少顺序偏差,可以准备几种形式的问卷,每种形式选项排序都不同。
    4. 设计问卷:明确目的,确定对象,调查渠道,时间计划,最后是问卷本身。
  5. 定性的做:可用性测试
    1. 仍实际用户使用产品或者原型,以发现页面设计中的可用性问题。UGC的一种实践(User generate Content,即让终端产品参与到产品设计的各个环节中)
    2. 招募测试用户(用户尽可能代表未来真实的用户)-准备测试任务(一些实际场景中的典型任务)-测试过程(观察用户,记录问题)-测试结束后询问用户看法-研究和分析(产品可用性问题列表,并对严重程度进行分级)
    3. 常见问题和对策:
      • 如果可用性测试做得太晚(在产品即将上线的时候,这时发现问题也于事无补了):任何阶段都可做,竞争对手产品,手绘产品,demo,真实产品都可以做。
      • 总觉得可用性测试很专业而不做:一般做5个左右用户可以发现共性问题,只做一个简化步骤也比不做要好。
      • 明确是测试产品而不是测试用户:和用户说来试用一下我们的新产品,提点意见
      • 测试过程中组织者该做和不该做的:告知答题时间,要做哪些任务,鼓励用户使用发声思维,不能有任何的引导与暗示。一切错都是产品和我们的错。
      • 结束时送个小礼品并表示感谢,简历用户参与产品设计的氛围。
      • 产品改版的时候做可用性测试是一种很合适的方法,来保证产品改版的安全性。
    4. 改版的时候要把暴力革命变成温柔和谐的和平演变
  6. 定量的做:数据分析
    1. 数据来源:用户使用产品的日志,客户管理系统的信息,网站访问情况的统计信息,数据分析的方法最简单可以用Excel,复杂的可以用统计软件,数据库软件或者写程序解决。完成分析后访谈用户,听用户解释
    2. 注意避免过于学术,沉迷于科学研究
    3. 虽然数据不会主动骗人,但是我们经常有意无意的误读数据
    4. 阅读《黑天鹅》和《统计数字会撒谎》这类图书,努力提高自己的水平
    5. 不要为了迎合一个观点去找数据
    6. 不要平时不烧香,临时抱佛脚,产品设计的时候就应该把数据分析的需求加进去,比如记录每个按钮的点击次数,统计每个用户的登陆频率,这是一种典型的非功能需求,对产品的可持续发展非常必要
    7. 对产品足够熟悉的基础上,先做出方向性的假设,再提取相应的数据并分析,得到一些现象,然后尝试解释,接下来用户调研修正解释,病指导产品发展方向。
  7. 需求采集人人有责
    1. 生孩子与养孩子:生孩子时从用户那里得到的一手需求,而养孩子是从老板,销售,运营处得到的二手需求。
    2. 二手需求采集工具:单项需求卡片-产品的需求工作不仅是需求分析人员的事情,而是涉及到产品的吗每个干系人的义务,至少得参与采集的过程
      image_1c66lqbdg70p9ch1kg81g1i1gdim.png-250.1kB
    3. 尽可能多的采集需求,不怕发现荒谬的需求,而是怕遗漏合理的需求。
    4. AB测试:基于大用户量比较合适,比如有一个按钮不知道是放页面的左边好,还是右边好,而我们有10 万用户,那就先随机挑选少量的用户发布这个按钮,1000人放左边,另外1000人放右边,然后过一段时间分析结果,再决定剩下的98%用户该怎么办。很明显,这也是让用户直接参与了设计,这样低成本的方法让很多传统行业的同学羡慕不已。
    5. 日志研究,卡片分类法,自己提需求
    6. 坚持需求驱动学习

      1: http://static.zybuluo.com/shenda77/o7kglaeu2wuam1rsrmz7nw3n/image_1c65bjn6r1hk4ao11c41gfa1edkp.png

  8. 听用户的但不要照着做

    1. 用户跟福特要一匹更快的马,福特却给了用户一辆车:要注意把用户需求转化为产品需求
    2. 用户需求:用户自以为的需求,并且经常表达为为用户的解决方案,产品需求是经过我们的分析,找到的真实需求,并且表达为产品的解决方案。需求分析就是从用户提出的需求出发,找到用户内心真正的渴望,在转化为产品需求的过程。
    3. 需求分析是一个树叶-树枝-树干-树干-树枝-树叶的分析过程,他是一个分总分的过程,必须先找到树干。
    4. 满足需求的三种方式:从问题的本质出发,寻找新路
      • 改变现状:最笨的方法,直接开发产品
      • 降低理想:
      • 转移需求:满足用户需求,不应该要做新产品或者新功能
  9. 给需求做一次DNA检测
    1. 需求转化-确定基本属性-分析商业价值-初评实现难度-计算性价比
    2. 把用户需求转化为产品需求
      • 产品需求列表
        image_1c66n7lom1sft13s8pbh190b16l113.png-113.7kB
      • 表格每一行是一个产品需求,每一列是一个产品需求的属性
        image_1c66nblcavlj12k5j3flue8sb1g.png-91.3kB
      • 需求的种类
        image_1c66ngjid1oorrqj1hh4o46l0m1t.png-32.6kB
      • 分析需求的商业价值
        image_1c66nl8avpb9js0h75155j1qet2a.png-48.8kB
      • 学习KANO模型加深理解
      • 开发量是非评估不可的,我把它叫做“初评”,允许误差,并且会要经验丰富的人来评估,通常是技术经理,或者系统分析师、架构师
        image_1c66o03491uludea17e812lsc1g34.png-18.5kB
      • 需求性价比 = 商业价值除以实现难度
        image_1c66nvkeh1tfpfmdje111l310be2n.png-19.9kB
  10. 需求筛选
    image_1c66o1thb1raucjn1g6t18a619933h.png-24.3kB
    1. 早期的时候,公司按照产品线划分部门。完全可以在产品经理的层面上决定产品走向。而现在变成了按照职能线划分团队,有了统一的产品中心、研发中心、质控中心,这样每个产品还是由原来的产品人员做,但是开发与测试资源上有了流动性。
    2. 做项目的终极目标就是多快好省:范围大,时间短,品质高,资源省
    3. 需求打包最好打包类似的功能点,且功能相互之间有依赖关系,只能先做的功能应该标注,需求粒度细到五人天
    4. 商业需求文档(Business Requirement Document),即BRD,市场需求文档为MRD(Market Requirement Document),而产品需求文档为PRD(Product Requirement Document)
  11. 商业需求文档BRD怎么写:
    • 项目背景:我们在哪里?为什么要做这个项目,解决什么问题,可以列出一些数据说明项目的必要性。
    • 商业价值:我们去哪里?最关键的重点!大老板们最感兴趣的,做了这个项目以后有什么价值,一定要说在点子上。一般我们还会预测一下相关数字的变化,提出这个项目的商业目标。
    • 功能需求描述:我们怎么去?通过做哪些事情来达到目标,把打好包的需求描述一下,可以用功能列表的形式表达,但最好能画出业务逻辑关系。当然我们也经常会搞点技巧性的东西,比如故意加入一些让老板砍的需求,希望老板砍完之后心有愧疚不好意思再砍我们真正想做的东西,这有点类似谈判技巧里的玩意,大家可以试试,但不要在这上面太花心思了。
    • 非功能描述需求:提一下重要的非功能需求,如果有的话。
    • 资源评估:第二个重点!大老板们要看成本,他们在了解达成项目的目标需要多大的花费以后,才能做出决策。
    • 风险和对策:有的项目会有一些潜在风险,这个时候不妨抛给老板们看一下,并且给出自己的对策,说不定你觉得是很大的麻烦,在老板那里一句话就可以搞定。而且由于信息的不对称,我们无法了解某些功能是否会与公司将来的战略冲突,这时候提出来也是让老板们把一下关。
    • 用100%的质量去实现75%的数量,少做就是多做
  12. 四两拨千斤的效果
    在动手之前找找有没有成本低,收效大的解决方案,需求选择的时候尽可能多的采集,最后尽可能多的放弃
    image_1c69abm0s1era1afg1m5e8vi1mco4e.png-146.2kB