聊聊精益需求的产生过程

这是鼎叔的第七十八篇原创文章。行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本公众号《敏捷测试转型》，星标收藏，大量原创思考文章陆续推出。本人新书《无测试组织-测试团队的敏捷转型》​​​​​​​​​​​​​​已出版（机械工业出版社），各大电商平台热销中，30万字350页。

本篇开启第六个专辑《测试左移与右看》的领域主题分享，中间也穿插其他原创的知识思考内容。

对产品研发而言，最大的风险在于用户需求没有挖掘清楚，而且产品的需求描述和传递过程失真，最终导致生产出来的产品不是用户真正想要的。精益需求生产过程，就是希望尽可能地降低这种极大的生产浪费。这套互联网行业的生产过程，也适用于任何行业的产品精益生产。

在互联网行业中，业务需求变化很多，很快，业务人员，产品人员和技术人员经常对要交付需求的上线优先级无法达成一致，产生推诿和争吵。那么，完整的精益需求产生过程应该是怎样的？它如何尽可能提高产品成功的概率，并降低研发过程中的偏差和耗费？

用户需求的本质

业务团队的需求是从愿景出发，围绕商业方向确定目标用户群。

用户的需求是从自己的问题和痛点出发，希望有产品功能能够解决它们。

产品功能方案如果成功解决用户问题，就能积少成多，一步步实现商业价值。

​

用户需求的本质特征是隐形的，只有对市场和用户有深入洞察力的产品经理，才能将其挖掘出来。因为：

用户嘴里说的，不等于用户实际做的，也不等于用户心里想的。

用户需求往往是动态变化的，不是确定不变的。

用户需求是多层次的，产品经理需要一定的创造力才能找出最契合的定义。

需求往往在社会化协作中产生，产品经理需要使用一致的高效的描述语言。

什么是精益产品思维

精益需求的核心设计思维及实践，就是要持续洞察用户和市场，开放探索。精益产品的成功也来自于整个过程中更强的应对不确定性的能力。

​

作为拥抱敏捷的团队，产品的成功来自快速试错，Fail Fast。快速的价值反馈闭环，即“Build-Measure-Learning”，能够降低试错成本，让团队学习到宝贵知识，并更快地走向成功。

产品设计思维，精益思想，敏捷研发，三者互相成就一款成功的产品。设计思维的目标是“挖掘问题”，精益的目标是“做正确的事”，敏捷的目标是“正确地做事”。

​

三者合一的详细指导方法过程如下：一个产品的产生有探索，定义，设计和交付四个主要阶段，精益原则贯彻整个需求生命周期的始终。这个周期中的具体活动包括：定义业务愿景，梳理产品战略，筛选业务重大举措，提炼需求定义，进行实验验证解决方案和确认需求优先级，再通过多个迭代构建产品并运行，交付给用户，同时获得持续改进的知识。

​

精益产品的全生命周期管理

下面我们从一个基本流程开始详细介绍。

精益需求的全流程，大概可以分为十个步骤。前五个步骤是从原始需求到问题定义的推导，后五个步骤是从问题定义到待开发的产品需求确认。

​

在需求产生过程，需要理解并实践的核心问题有：

一 如何定义产品需求？产品的定位和目标是什么？

根据KANO模型，本需求是哪个类型？必备型（基础能力），期望型，还是魅力型？参考：聊聊竞品体验对比评测（上）。

本需求处于什么周期中，是引入期，成长期，还是成熟期？

确定产品的定位和目标，这个过程容易么？如果困难，难在什么地方？

有信息输入不够的地方么，具体是哪些？哪些信息还不太确认，需要做进一步的验证？

产品经理如何让开发、设计、测试和管理者对产品的目标和定位达成一致？

产品的定位和目标可以用下列信息要素来梳理：

• 目标用户：核心用户群体的关键特征是什么？早期用户群体的关键特征呢？

• 客户需求：关键用户的问题和期待是什么？

• 解决方案：提供怎么样的产品或服务？

• 业务价值：业务的定位，贡献的目标和价值。

• 独特卖点：相对于现有方案和竞品，优势和卖点是什么？

• 产品愿景：一句话描述。

当面对新的需求时，如果想不通该不该做，就重新思考产品定位和目标。

二，如何挖掘用户的问题和目标？

注意用户的表达，要求不等于需求，请求不等于需求，反馈也不等于需求！我们给出的解决方案，也不等于需求本身。

需求的第一条原则，还是要从用户的问题出发来推导。

三，产品的用户和干系人是谁？

按用户距离，可以分为直接用户，间接用户或关联用户。

从其他维度，还可以区分为内部用户和外部用户，生产者和消费者，B端用户和C端用户。

针对用户如何建立更细致的类型区分？基于什么属性进行进一步的区分？下面是一个简单的属性分类示范。

​

下一步，如何找出本产品最核心的用户类型？

我们可以通过象限法来绘制不同用户类型所在的地方。横轴是用户数量或规模，纵轴是用户的需求，或用户影响力，或用户贡献。

也可以通过矩阵法，针对当前的价值贡献，潜在的价值贡献和流失风险，定出该类型用户的优先级。

​

四，用户画像如何绘制？

前面说过，内部用户和外部用户的画像可能完全不同，需要区分绘制。

我们可以给典型用户绘制一个卡片，让团队成员觉得真实可信，我们充分想象，人物就在我们眼前，用户形象如何，叫什么，她有什么基本信息，特征描述，他/她的痛点/期待是什么，目标是什么。

​

对于内部用户，我们可以把卡片信息聚焦在内部协作场景，职责，痛点和期待。

比如内部负责监控的IT工程师客户，他的痛点描述语言会更加技术化，痛点场景也以内部典型的跨部门协作场景为主。我们绘制的用户画像会把他的职责和期待目标也定义得非常具体，使用的专业术语比外部用户多出很多。

最后，我们对用户特征梳理进行复盘：

我们的用户特征情报从何而来？如何确认信息靠谱？哪些信息输入还不够？

一定是直接用户的问题才需要关注么？关联用户/间接用户，他们的问题有什么启发？

五，产品电梯演讲

电梯演讲，就是在电梯的一分钟时间里，以XX为对手，用一段话说服老板接受一个产品方案。

​

我们上面的用户对象分析，对标产品电梯演讲的目标用户群，有什么差异？

六 接下来，从用户出发，发现场景

这一块就要利用之前介绍的用户故事知识了。聊聊用户故事与测试启发

一个用户故事发生的场景，包括这些要素：时间（WHEN），地点（WHERE），和谁(WHO)，前情（BEFORE），后果（AFTER）等。

利用用户故事挖掘场景，我们要特别关注逻辑合理性，多问自己这些问题：

• 核心用户、问题（痛点）和场景的逻辑合理么？

• 可以用什么手段去验证这个场景是真实存在的？

• 用户为什么会遇到这样的问题？

• 其内心深处的目标和动机是什么？这个目标是真正的目标么？

• 真正的目标和当初的问题有怎样的关联？

• 当前哪些信息输入还不够？可以通过哪些手段获得这些信息？

七 洞察用户目标

通过上面的过程，用户清楚了，目标清楚了，那准确的问题定义应该是什么？

我们想给用户的可能是一个很复杂的产品，用户想要的东西可能非常简单。

​

为了洞察出用户真正的目标，我们可以不断追问问题的本质，如下：

• 从问题的描述，发生的场景要素，我们判断是哪一类用户的问题？

• 问题的根本原因是什么？

• 问题发生后对用户造成的影响是什么？

• 问题发生后对业务的影响是什么？

明确了用户真正的目标，精益需求的前半部分才算是真正完成，后面的环节就依次是：针对痛点的创意发散，端到端设计用户体验路线，原型设计，最后进入技术评估方案。这些本文就暂不展开了。