需求若错，产品何用？需求是一个复杂工程，不能正确解锁，那么使用产品的姿势也会有问题，希望用这篇文章创建需求方法论，供我之用，供你所取。
产品如同一个紧锁着的无人城池，需求如同一个钥匙，让产品能够一步步地完整呈现在你的眼前，同样，这个钥匙有着精艺的工序，根据工序一步一步就可以制作出通向产品城池的钥匙。
前一段时间，笔者在学习项目管理，对信息系统的需求管理有了较为系统的了解，尽管是传统的软件工程领域，但在目前的互联网领域还是可以借用其理论与方法，借我之理解，写我之文字。
在软件工程中，软件需求工程包括了需求开发与需求管理两个部分，需求开发的目的是通过调查与分析，获取用户需求并定义软件需求，需求管理的目的是在客户与项目组之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。
需求开发的过程主要有四个活动：需求获取、需求分析、需求定义、需求验证。
需求管理的过程主要有六个活动：制定需求管理计划、求得对需求的理解、求得对需求的承诺、管理需求变更、维护对需求的双向跟踪性、识别项目工作与需求之间的不一致性。
相对于复杂庞大的信息系统工程软件，互联网软件显得比较轻快，同样的，应对信息系统工程软件的多道工序可以简化，使其更贴近互联网的特点，适应互联网的发展。
需求开发的过程不管对工程软件还是互联网软件都是适用的，都会经历一个需求获取、需求分析、需求定义与需求验证的过程，但在需求管理的过程中，在图中可以看到需求管理与需求开发是一个相互作用的过程，并非有一个先后的顺序，所以针对互联网的特点，在需求管理这一个过程里可以简化为需求确认、需求变更与需求跟踪。在下面的介绍里主要是互联网需求工程的七个部分：
一.需求获取
需求的获取可以从三个方面来说明：
WHAT（获取信息）
在需求获取这一过程里最重要的是获取的什么信息，毕竟不管白猫黑猫，能抓到老鼠就是好猫，只要能得到需要的信息，选择何种方式是看你的喜好的，只是说不同的方式有不同的好处。
信息主要是两个方面：业务与用户，业务如业务流程、业务模式等，用户如用户信息、社会属性、消费行为、使用场景、遇到的问题等。
WHERE（需求来源与渠道）
需求的来源与渠道很多，如：
公司战略层面
用户层面
业务部门（如销售、运营、客服等）
领导老板
竞争对手产品
应用市场反馈或产品反馈渠道
产品经理本人
HOW（获取方式）
用户访谈（结构化与非结构化：结构化是指事先准备好一系列问题，有针对地进行；非结构化是指列出一个粗略的想法，根据访谈的具体情况进行发挥。在访谈的过程中建议综合两种方法）
用户调查（由于缺乏面对面的交流，所获取的信息量比较有限，在实际工作中，建议是采用用户调查获取一定量的信息，然后有针对地去开展用户访谈）
现场观摩（典型的定性分析，在现场观察用户怎么说怎么做）
运营数据分析（针对已上线的产品，通过产品的运营监控获取运营数据，分析数据提炼需求为产品迭代升级提供一定依据）
用户模拟（代入用户角色，化身小白用户，亲身使用产品，思考在该场景下用产品做什么，怎么做）
需求讨论会（联合各关键用户、分析人员、开发人员等，通过有组织的会议来讨论需求。在会前说明此次会议主题，发放需求记录单，让与会人员将使用产品过程中的想法、发现的问题和不足都记录下来，形成清单进行讨论，从中提炼需求）
原型法（将主要功能开发出可操作的原型，纸面原型、Axure原型也可以，邀请用户进行使用，及时征求用户意见，确定用户需求）
二.需求分析
需求分析是一次用户需求转化为产品需求的过程。
用户需求表述的是用户的期望与目的，或用户希望产品完成的任务。通常情况下，用户所提出的需求都是从自身角度出发，从用户角度来说是绝对正确的，但在其不了解产品整体的情况下，这并不一定能达到用户的要求，一方面用户表达的并不一定是内心最真实的期望，另一方面这也不一定是产品的最佳解决方式。
产品需求是通过分析挖掘出用户内心最真实的需求，并提出符合产品定位的解决方案。
需求分析的过程可以依照以下几个步骤：
判断用户需求
用户需求的判断可从以下方面进行：
该用户是否是目标用户（非目标用户所提出的需求其参考价值意义不大，当然并非绝对）
用户群大小（收集用户基本信息，输出用户画像，调查用户群体数量。对于上一条非目标用户，可进行用户群数量调查，挖掘出新用户群的新需求）
该需求是否符合产品定位（该需求的满足有可能影响到产品的核心服务，对产品调性产生负面影响，也有可能影响到用户体验等）
该需求能否被解决
需求价值（是否迫切强烈、是否必须解决、是否高频、持续时间是否长、是否符合产品版本规划）
描述用户需求
描述用户需求的过程主要两个方面：构建用户画像与描述使用场景。
构建用户画像
一切工作的开展都应该围绕着用户需求来展开，而不是产品团队里某个人的喜好，为了让整个团队在产品设计的过程中抛弃个人喜好，将焦点关注在目标用户的目的与动机上，就需要构建用户画像进行聚焦。
用户画像的PERSONA七要素：
P代表基本性（Primary）：指该用户是否基于对真实用户的情景访谈
E代表同理性（Empathy）：指用户角色中包含姓名、照片和产品相关的描述，该用户角色是否引同理心
R代表真实性（Realistic）：指对那些每天与顾客打交道的人来说，用户角色是否看起来像真实人物
S代表独特性（Singular）：每个用户都是独特的，彼此很少有相似性
O代表目标性（Objectives）：该用户角色是否包含于产品相关的高层次目标，是否包含关键词来描述该目标
N代表数量性（Number）：用户角色的数量是否足够少，以便设计团队能记住每个用户角色的姓名，以及其中的一个主要用户角色
A代表应用性（Applicable）：设计团队是否能使用用户角色作为一种实用工具进行设计决策
关于构建用户画像的方法很多，像Alen Cooper的“七步人物角色法”、Lene Nielsen的“十步人物角色法”等，借鉴于这些方法，可以将构建用户画像分为以下几个步骤：
确定用户分类维度（大部分用户体验研究是将用户的心理特点与人口统计学特征来作为分类维度对用户进行分类的，而用户画像是针对特定产品或其功能，其分类是根据用户的目标（用户需求）与行为模式（具体行为或行为倾向）
收集数据（数据的收集需要考虑到数据基本信息与数据类型两个因素，数据基本信息包括用户类型，用户样本数量与收集方式，数据类型包括定性数据、定量数据以及经定量数据转化而来的定性数据；根据分类维度，不同的数据类型使用不同的数据收集方式，用户的目标可以采用定性的研究方式（用户访谈，定性式问卷调查、焦点小组等），行为模式可以采用定性的研究方式（现场观摩、卡片分类法、可用性测试等）或定量的研究方式（数据分析等）
分类用户（根据大量数据中特征的相关性与相似程度，对用户进行分类，得到每一类用户包含的典型特征，对用户进行分类可以参考亲和图、聚类分析、德尔菲法等）
评定优先级（ 评定优先级就是根据产品目标与产品功能对不同用户评定重要级别。具体评定的标准根据产品来，可以以市场大小、收益潜力、使用频率来分，也可以就用户类型特征与功能特征的相似程度来分等，将用户划分为重要用户、次要用户、不重要用户）
丰富画像（为了丰富用户画像，使其看起来像一个独立的真实的个体，可以加入姓名、性别、年龄、喜好情况等）
描述用户场景
用户场景（或者叫使用场景）由用户与场景两部分组成，用户为上一步所划分出来的典型用户画像，场景一般由背景、时间、空间、需求组成。
描述产品需求
从用户需求到产品需求的转化在于探究用户内心，用户需求是用户说出来的，并不代表用户内心最真实的需求，所以想要知道用户内心最真实的需求就需要向用户问“Why”，从产品功能的角度找到一个解决方案来解决用户的问题，这就形成了产品需求。
三.需求定义
需求定义在软件工程中分为标识需求、定义需求优先级与编写《需求规格说明书》，在互联网软件行业定义需求优先级可以在需求验证这一步中。下面主要简述标识需求与编写《需求规格说明书》
标识需求
在传统的系统软件中，由于需求数目众多，可能达到上万，为了高效管理这么大数量的需求，就需要对需求进行标识。尽管产品在上线阶段需求不可能很多，但在产品的生命周期过程中因产品迭代，需求是不断增加的，这时为了更高效地管理需求也可以对需求进行标识。
下面介绍两种标识方法：
序列号（简单地说就是赋予每一个需求一个数字编号，因为只是简单的数字编号，所以不能表示任何更多的信息，不能提供任何层次和逻辑上的区别）
层次编码（层次编码采用标点符隔开，以表示需求文档中某一段某一个需求，如1.1.1.1，代表1.1.1中的第一个需求，标识中的数字越多代表划分的需求越细，这样的需求标识方法便于区分该需求是哪一个模块或某一个功能。
需要注意的是，对需求进行标识是为了更好地管理与更高效地查询需求，这对管理需求与需求的跟踪提供巨大的帮助，所以这两种方法没有绝对的优点，同样也没有一种需求标识的方法是绝对完美的。因项目而异，找到最适合项目的标识需求方法，才能最大程度上提高查询的效率。
编写需求文档
《需求规格说明书》对应到互联网软件就是产品需求文档，而一份产品需求文档的编写大致可以参考我的这一篇文章《产品需求文档丨云之家V1.0版需求文档》。
四.需求验证
在系统软件工程中，需求验证专指在需求规格说明书完成后，对需求规格说明书进行的验证活动。应用到互联网软件，就是对产品需求文档进行验证。
需求验证的方法在互联网软件中用的最多的还是需求评审，需求评审的目的是为了让与会人员能清晰地了解需求是什么，需求从哪里来，需求对用户的意义，需求对产品的影响，需求的责任人，评审需求是否正确与评定需求的优先级等。
需求评审会议有两种形式，非正式与正式：
非正式的是吼一嗓子，把各相关人叫过来，直接对着电脑上的需求开始讲，并就需求进行讨论。
正式的需求评审会议一般是为产品初始版本或大版本迭代而开，这里要介绍的就是正式的需求评审会议。
按时间进程可以分为会议前、会议中、会议后三个阶段：
1.会议前
会议前预定好会议室
发一封会议邮件，言明会议时间、会议室、会议主题，发送给项目干系人，时间提前3-5天
小范围先将需求沟通，将产品方案进行改善，不然等到正式评审的时候就会被各种怼
将产品方案附加在邮件中，可以让与会人员先对方案有个概览，加快会议的进程，同时也可以让因事未参与到会议中的相关人员查看到产品方案
做一些会前准备，如检查投影设备
2.会议中
点明会议背景与目的
介绍需求
评定优先级、指定需求联系人与相关开发、设计、测试等人员
遇到争议时，让会议中出席的领导一锤定音
3.会议后
整理会议记录群发邮件
与相关人员沟通会议中的问题，解决问题，补充整理好产品文档发送给所有人员
需求确认、需求变更、需求跟踪属于需求管理，顾名思义是对需求开发的过程进行管理。
关于需求管理的作用，我看到这么一段文字。
需求管理能够确证：
我们确知客户的需求是什么（质量）
满足客户需求的最佳解决方法（统一性）
而著名学者Crosby对于质量的定义就是“同需求保持统一”。我们每个人都应该始终明白我们所做的具体任务其意义何在，然而在一个产品的生命周期里，其需求性是能动的，是处于变化之中的，所以为保证产品的质量，我们必须时刻保持与需求的统一性，随变而变。
五.需求确认
需求确认的意思就是设法理解需求提供者提出的这些需求的含义，那么作为第一手接触用户需求的产品人，需要设法理解用户所提出的需求，同时要将我们理解的需求表达给我们开发、设计与测试等，设法让他们也理解用户的需求，确保大家对需求的理解一致，实际上需求开发的四个过程就是需求确认的动作，需求的获取与分析过程是在理解用户所提出的需求，而需求验证的过程则是向项目组人员传达用户的需求，设法让他们理解。
在系统软件工程中，需求确认的另一个作用是防止项目范围的蔓延，项目组理解了客户的需求，向用户反馈所理解的需求，得到用户的认可后，签署需求确认书，一旦签订需求确认书，就意味着整个项目的范围已经确定，在项目实施的过程中不允许客户随意更改项目范围，增加或者变更需求。但在互联网软件工程中，我们是不可能与用户签订一个需求确认书，来防止用户变更需求，只能在获取需求与分析需求的过程中准确理解用户需求，并设法挖掘到用户内心最真实的需求。
六.需求变更
首先需要明确一点的是需求变更是不可避免的，我们是不可能控制需求永远不会变更，所以对比我们需要有一个正规的流程来对变更的需求进行管理。
一般来说，小的需求变更只是产品经理口头通知相关的开发、设计与测试等人员，但复杂的需求变更必须规范化，使需求有源可寻、有据可跟。
如前文所说，满足用户需求最佳的解决方式就是统一性，所以最终需要解决的就是保证产品与用户需求的一致性。
需求变更的来源一般是两个方面，一个是用户，一个是项目组，但大部分都来自于产品经理本人。需求变更一般来说形式就三种：删除、新增、修改。
下面就两种情况进行说明：
1.用户提出需求变更流程
流程说明：
需求来源：用户提出需求变更
产品经理初步审核：通过产品经理自己对需求的判断，判断是否有必要做、是否能做等
项目组审核：评估实现需求的难度、人力成本、时间成本；对该版本迭代是否有影响，该版本是否能够实现等
需求确认：通过项目审核后，可以与用户确认需求，确保项目对需求的理解与用户一致，要开发的功能能故解决用户的问题
邮件通知：确认需求后，发送邮件通知所有项目干系人，说明需求变更的内容
2.项目组提出需求变更流程
流程说明：
需求来源：项目组人员发现逻辑、流程上有问题或产品需求与提出的需求不一致等
项目组审核：经过项目组相关人员的审核才能确认是否执行变更
邮件通知：将确定在本版本进行变更的内容以邮件的方式来通知相关人员
对于变更的内容，项目组相关人员需要进行记录，方便对需求进行跟踪。
七.需求跟踪
需求跟踪主要的内容是需求的整个生命周期，即从需求源头到实现的生存周期。
上图是需求跟踪过程，从用户需求正向追溯到产品功能，从产品功能反向回溯到用户需求，在这个过程中，可以区分用户需求是否因为需求变更而变化、是否转化为产品功能、产品功能是否有对应的用户需求等，使需求做到有源可溯。
需求状态
在需求开发的过程中，跟踪需求的状态时需求管理的一个重要方面。记录每条需求的状态，对于项目的进度以及对项目的整体把握有很大帮助，下面是几种建议的状态值：
需求跟踪矩阵
在需求管理中，要收集需求的变更和变更的理由并维持对用户需求、产品需求和产品功能的双向跟踪。
不论采用正向跟踪还是逆向跟踪，都要建立与维护需求跟踪矩阵。需求跟踪矩阵保证了需求与后续工作成果的对应关系，当后续工作成果发生变更时，要及时更新需求跟踪矩阵，需求跟踪矩阵对管理需求变更也能提供帮助。下面是简单的需求跟踪矩阵：
总体来说，在需求跟踪的过程中除了上述工具和方法，更常应用的是沟通，维持状态的改变、及时更新需求跟踪矩阵以及需求变更都需要通过沟通来进行，所以维持好与项目组人员的沟通，可以更好地开展需求跟踪工作。
题外话
我只是一个项目人，并不是一个产品人，所以从我的角度并不能完整且完全地描述正确产品角度的需求工程，我希望能通过这篇文章初步构建自己的需求方法论，也很希望通过产品人从产品角度来给我述说正确的解锁需求的姿势，如果你有关于需求的方法，请不吝赐教，在评论里提出，从你那里我获取需要的信息，填补我的需求方法论，谢谢。
网友评论