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

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

2.2 需求采集的大生产运动

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

3. 用户访谈的常见问题以及对策

   1. 说和做不一致的问题：原因：问了一个自己也没仔细想过的问题，不想回答不知道，就现场编造有理有据的理由。或者他们有讨好访谈者的心里，会回答他们觉得你希望听到的答案，那不是真正的想法。解决方法是在用户可以和产品交互的场合下进行，让用户说的同时也做。另外，区分用户的事实与观点，一般来说诸如我做了什么，步骤如何，碰到什么问题的可信度高，我觉得，我认为这类观点要存疑，
   2. 样本少，以偏概全：尽量识别引起偏差的因素，并在访谈报告里表明。利用增量访谈：先问五个得出基本结论，再访谈五个看结论是否有改变，如果有改变就思考是否合适，并加大样本量。
   3. 用户过于强势，把访谈者往沟里带：时刻牢记访谈的目的，发现话题不对就往正道上掰，掰不过来可以考虑尽快结束。
   4. 我们过于强势，把用户往沟里带：牢记访谈目的，管好自己的嘴。
   5. 用户访谈注意点：
      
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. 二手需求采集工具：单项需求卡片-产品的需求工作不仅是需求分析人员的事情，而是涉及到产品的吗每个干系人的义务，至少得参与采集的过程
      
   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. 把用户需求转化为产品需求
      • 产品需求列表
        
      • 表格每一行是一个产品需求，每一列是一个产品需求的属性
        
      • 需求的种类
        
      • 分析需求的商业价值
        
      • 学习KANO模型加深理解
      • 开发量是非评估不可的，我把它叫做“初评”，允许误差，并且会要经验丰富的人来评估，通常是技术经理，或者系统分析师、架构师
        
      • 需求性价比 = 商业价值除以实现难度
        
10. 需求筛选
    
    1. 早期的时候，公司按照产品线划分部门。完全可以在产品经理的层面上决定产品走向。而现在变成了按照职能线划分团队，有了统一的产品中心、研发中心、质控中心，这样每个产品还是由原来的产品人员做，但是开发与测试资源上有了流动性。
    2. 做项目的终极目标就是多快好省：范围大，时间短，品质高，资源省
    3. 需求打包最好打包类似的功能点，且功能相互之间有依赖关系，只能先做的功能应该标注，需求粒度细到五人天
    4. 商业需求文档（Business Requirement Document），即BRD，市场需求文档为MRD（Market Requirement Document），而产品需求文档为PRD（Product Requirement Document）
11. 商业需求文档BRD怎么写：
    • 项目背景：我们在哪里？为什么要做这个项目，解决什么问题，可以列出一些数据说明项目的必要性。
    • 商业价值：我们去哪里？最关键的重点！大老板们最感兴趣的，做了这个项目以后有什么价值，一定要说在点子上。一般我们还会预测一下相关数字的变化，提出这个项目的商业目标。
    • 功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打好包的需求描述一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系。当然我们也经常会搞点技巧性的东西，比如故意加入一些让老板砍的需求，希望老板砍完之后心有愧疚不好意思再砍我们真正想做的东西，这有点类似谈判技巧里的玩意，大家可以试试，但不要在这上面太花心思了。
    • 非功能描述需求：提一下重要的非功能需求，如果有的话。
    • 资源评估：第二个重点！大老板们要看成本，他们在了解达成项目的目标需要多大的花费以后，才能做出决策。
    • 风险和对策：有的项目会有一些潜在风险，这个时候不妨抛给老板们看一下，并且给出自己的对策，说不定你觉得是很大的麻烦，在老板那里一句话就可以搞定。而且由于信息的不对称，我们无法了解某些功能是否会与公司将来的战略冲突，这时候提出来也是让老板们把一下关。
    • 用100%的质量去实现75%的数量，少做就是多做

12. 四两拨千斤的效果
    在动手之前找找有没有成本低，收效大的解决方案，需求选择的时候尽可能多的采集，最后尽可能多的放弃