读《人人都是产品经理》-笔记-一个需求的的奋斗史_《人人都是产品经理》一书里有一个单向需求模版-CSDN博客

本文链接：https://blog.csdn.net/qq_41518597/article/details/116536216

需求的整个生命周期如下：
在这里插入图片描述

引用自《人人都是产品经理》一书

需求采集的过程，都会有如下几步：

需求采集的过程
明确目标
选择采集方法
制定采集计划
执行采集
资料整理
进入下一步的需求分析阶段

将上述过程简化为图可以有以下参考：
在这里插入图片描述

引用自《人人都是产品经理》一书

定性的说：用户访谈中我们需要规避一些常见问题
比如：

用户访谈需要规避的问题	对策
“说”和“做”不一致的问题	尽量在用户可以和产品发生交互的场合下进行，让用户在“说”的同时也“做”
样本少，以偏概全的问题。	该尽量识别出各种可能引起偏差的因素，并在访谈的报告里标明，让读者了解。为了用尽可能少的样本得到尽可能正确的结论，以增量的方式做访谈
用户过于强势，把我们往沟里带。	时刻牢记访谈的目的。如果发现话题不对，就赶紧往正道上扳，若发现多次都扳不过来，就可以考虑尽快结束
我们过于强势，把用户往沟里带。	是牢记访谈的目的，并且管好自己的嘴

定量的说：问卷调查中我们需要规避一些常见问题
比如：

问卷调查需要规避的问题	对策
样本的偏差，即样本与想了解的目标用户群体出现偏差。	把潜在的筛选条件标明，让报告的读者知道数据获得的方法与来源，同时如果自己是报告的读者，也要一直带着问号去阅读里面的数据
样本过少的问题。	避免采用百分比来分析
问卷内容的细节问题。	先进行小范围的试答，根据反馈修改后，再大面积投放，

定性的做：可用性测试中我们需要规避一些常见问题
比如：

可用性测试需要规避的问题	对策
如果可用性测试做得太晚（往往在产品将要上线的时候），这时发现问题也于事无补了。	可用性测试在产品的各个阶段做。在尚无任何成型的产品时，拿竞争对手的产品给用户做；只有纸面原型的时候，拿手绘的产品，加上纸笔给用户做；只有页面 Demo 的时候，拿 Demo 给用户做
总觉得可用性测试很专业，所以干脆不做。	可选择的进行可用性测试
明确是测试产品，而不是测试用户。	明确地告诉用户，这个测试的目的是发现软件产品中的问题。不要让用户听到“可用性测试”的术语，而是说“来试用一下我们的新产品，提点意见”。清楚地说明这一点将有助于减轻用户的压力，使得他们能像在真实环境一样来使用软件。
测试过程中，组织者该做的和不该做的。	做测试的过程中千万不要有任何的引导与暗示，而只是观察和记录

定量的做：数据分析中我们需要规避一些常见问题
比如：

数据分析需要规避的问题	对策
过于学术，沉迷于“科学研究”。	实际生产环境更注重综合的性价比，需要的是一种对数据的敏感，对商业的敏感。
虽然数据不会骗人，但我们经常无意或有意地误读数据	对数据保持中立的态度，尽量不要“为了迎合一个观点而去找数据”，减少利益牵扯
平时不烧香，临时抱佛脚。	在产品设计的时候就把数据分析的需求加进去，比如记录每个按钮的点击次数、统计每个用户的登录频率等

我们经常接到的就是口头上的几句话，或者一封邮件的几行说明，这中间理解的偏差只能靠我们主动的、反复的沟通来弥补，那么有没有什么办法解决呢？可以用需求采集工具
——单项需求卡片。

产品的需求工作不只是需求分析人员的事，而是涉及产品的每个干系人的义务，至少得参与“采集”的过程，理想的状态是产品的所有干系人都参加过“需求采集”的培训，然后在日常工作中养成主动提交需求给产品人员的习惯，但实际很难做到，所以作为专业的需求分析人员，就应该尽量降低同事们，比如销售、服务、技术人员提交需求的成本，也是节省我们自己的时间。
引用自《人人都是产品经理》一书

一张单项需求卡片描述了一个用户需求到底包含哪些内容，重点是描述用户场景，
谁在什么时间、地点产生了何种需求，模板如下：

引用自《r人人都是产品经理》一书

BRD、MRD、PRD的解释

名称	解释
BRD(Business Requirement Document) 商业需求文档	基于商业目标或价值所描述的产品需求内容文档，用于产品在投入研发之前，由企业高层作为决策评估的依据。
MRD(Market Requirements Document)市场需求文档	描述什么样的功能和特点的产品可以在市场上取得成功。一般新功能的实现，上线新的产品提供MRD
PRD(Product Requirement Document)产品需求文档	产品项目由“概念化”阶段进入到“图纸化”阶段的最主要的一个文档，产品的功能改善、产品的细节说明提供PRD