需求
需求采集过程：
明确目标、选择采集方法、制定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段 。
用户访谈的常见问题与对策：
- “说”和“做”不一致的问题。用户经常会骗我们，他们被问了自己也没仔细想过的问题，又不想回答不知道，就现场编一个看似有理的理由，或者他们有讨好访谈者的心理，会回答他们觉得你希望听到的答案。所以，尽量在用户可以和产品发生交互的场合下进行，让用户在“说”的同时也“做”。
- 样本少，以偏概全的问题。选择样本时尽量做到随机，以增量的方式做访谈。举个例子，先访谈5个用户，得出基本结论，然后再访谈5个，观察结论是否有变化，如果有变化，就继续加大样本量，或思考问题是否合适？样本集是否合适？如果没有改变，就停止继续访谈，节省成本。
- 用户过于强势，把我们往沟里带。牢记访谈目的，发现话题不对就赶紧往正道上扳，若多次都扳不过来就考虑尽快结束。
- 我们过于强势，把用户往沟里带。牢记访谈目的，并管好自己的嘴。
用户访谈注意点：
- 避免一组固定的问题：固定的问题会让被访问者产生被审问的感觉。
- 首先关注目标，其次任务：比用户行为更重要的是行为背后的原因，多问问用户为什么这么做。
- 避免让用户成为设计师：听用户说，但不要照做，用户的解决方案通常短浅、片面。
- 避免讨论技术：不要纠缠产品的实现方式。
- 鼓励讲故事：故事是最好帮助设计师理解用户的方法。
- 避免诱导性的问题：典型的诱导问题是“如果有xx功能，你会使用么？”一般用户用户会给出毫无意义的肯定答复。
调查问卷注意点：
无论是线上还是线下，作答时间尽可能短。开篇一般放一些简单的不需要思考的问题；很想知道的内容，需要思考的，较敏感的问题一般放中间；有关被访者个人信息的题目一般放最后。
- 样本偏差，即样本与想了解的目标用户群体出现偏差。尽可能覆盖目标用户群体中各类型的用户，保证各种类型用户的样本比例接近全体的比例，比如目标用户男女比例为7:3，那么样本也应该保持这个比例。
- 样本过少。样本量过少就不要采用百分比来分析。
- 问卷内容的细节问题。表述应无引导性。比如，不要问“你喜欢某个产品吗？”，这时用户可能会考虑到提问者的情感而回答“是”，正确的问法是“你是否喜欢某个产品？”。
可用性测试（UGC理念的一种实践）：
- 招募测试用户。招募测试用户主要原则是，这些用户要尽可能地代表将来真实的用户。比如，如果产品的主要用户是新手，那么就应当选择一些对产品不熟悉的用户。
- 准备测试任务。测试组织者在测试前需要准备好一系列要求用户完成的任务，这些任务应当是一些实际使用中的典型任务。
- 测试过程。用户通过使用产品来完成所要求的任务，同时组织者在一旁观察用户操作的全过程，并把发现的问题纪录下来。
- 测试结束。组织者可以询问用户对于产品整体的主观看法或感受。
- 研究和分析。分析纪录并产生一份产品的可用性问题列表，并对问题的严重程度进行分级，根据项目进度选择哪些优先处理。
数据分析：
整体思路：在对产品足够熟悉的基础上，先作出方向性的假设，再提取相应的数据并分析，得到一些现象，最好是之前没发现的现象，然后尝试解释，接下来做用户调研修正解释，最终指导产品发展方向。
二手需求 —— 单项需求卡片：
单项需求卡片的理念是：产品的需求工作不只是需求分析人员的事，而是涉及产品的每个干系人的义务，至少得参与“采集”的过程。
用户需求 VS 产品需求：
- 用户需求：用户自以为的需求，并且经常表达为用户的解决方案。
- 产品需求：经过分析，找到的真实需求，并且表达为产品的解决方案。
- 需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。
满足需求的三种方式：
- 改变现状。是我们最常用的，去开发某种产品，但也是最笨的办法。
- 降低理想。什么“打预防针”、“丑话说在前头”这类句子想必大家都经常听到。
- 转移需求。引导用户去关注其他事物，他就会觉得这个差距没那么可憎了。
需求分析：
需求属性：
需求筛选：
- 需求打包，最好打包类似的功能点。需求依赖，功能互相之间有依赖关系。
- 产品会议。
- 商业需求文档（Business Requirement Document）。项目背景、商业价值、功能需求描述（业务逻辑图，若能给出一些简单的Demo更好）、非功能需求描述、资源评估、风险和对策。
项目坎坷的一生
做产品 VS 做项目：
产品是一个解决问题的东西，而项目是一个过程。
一切从 Kick Off 开始：
KO通常只需要15分钟左右的时间，在这15分钟内，需要传达的信息有如下几点：
项目背景
我们在哪里？说过去，做项目之前的“悲惨境地”，明确为什么要做这个项目，以让听众为终极目标痛下决心。
项目意义、目的与目标
我们去哪里？说将来，做项目之后的美好前景，解决什么问题就算成功了，以让听众为终极目标“面带桃花”。
需求、功能点概述
我们怎么去？说现在，具体使用什么方法促使“过去”到“将来”的转变，以让听众为终极目标跃跃欲试。
项目组织架构
目的是让项目成员互相认识，明确有什么事应该找谁。
项目计划
让所有人了解两个关键点：
第一，项目的时间点与里程碑。
第二，各个时段需要的资源，即每个人要在各阶段做什么事情。
沟通计划
和项目全体成员明确这点非常重要，因为太多事情的不顺利都是沟通的问题，所以有个规矩来逼着做一些沟通工作。
项目管理：
做项目的本质就是在保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡。
关键的青春期，又见需求：
写文档：市场需求文档（MRD）、产品需求文档（PRD）、功能详细说明（FSD）。
需求评审：PRD评审、UC评审、Demo评审的统称。于需求的相应部分完成以后进行，评审会上PD把PRD和UC说给开发、测试听，Demo评审则由UE的同学主讲。PRD评审会重点关注偏商业的内容，强烈建议叫上老板。而UC评审更偏技术实现。
设计评审：在概要设计与详细设计完成后进行，由开发工程师把对需求的理解以文档的形式说给PD、测试听。
测试评审：测试开始之前进行，由测试工程师把对需求的理解说给PD、开发听。
项目小结：
流程的本质：
设计流程的目标，在于保证“无论谁来做这个产品的设计，都能达到80分”。 一件事情总是有他的两面，流程帮助了产品，但对于后来者的个人成长也许不利，比如只能接触到产品工作的某一个层面，缺乏对大局的了解和把握。
那么多评审，可以省么？
- 必有：产品会议、Kick Off会议、需求评审（PRD、UC、Demo评审，可合并）、测试评审、功能评审。
- 可省略：设计评审、发布评审。
敏捷方法：
- 有计划，更要“拥抱变化”。
- 迭代周期内尽量不加任务。
- 集中工作，小步快跑。
- 持续细化需求，强调测试。
- 不断发布，尽早交付。