扫码阅读
手机扫码阅读

聊聊精益需求的产生过程

197 2024-01-12

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

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

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

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

用户需求的本质

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

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

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

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

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

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

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

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

什么是精益产品思维

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

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

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

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

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

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

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

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

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

根据KANO模型,本需求是哪个类型?必备型(基础能力),期望型,还是魅力型?参考:聊聊竞品体验对比评测(上)

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

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

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

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

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

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

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

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

  • 业务价值:业务的定位,贡献的目标和价值。

  • 独特卖点:相对于现有方案和竞品,优势和卖点是什么?

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

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

二,如何挖掘用户的问题和目标?

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

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

三,产品的用户和干系人是谁?

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

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

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

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

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

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

四,用户画像如何绘制?

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

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

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

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

最后,我们对用户特征梳理进行复盘:

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

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

五,产品电梯演讲

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

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

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

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

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

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

  • 核心用户、问题(痛点)和场景的逻辑合理么?

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

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

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

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

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


七 洞察用户目标

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

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

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

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

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

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

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

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

原文链接: http://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484381&idx=1&sn=ce816930d994d70721a86f3b14299f00&chksm=c24fb6bff5383fa9a38ddeeb4ad81015bcebc9ee935f7f5528be934794983b3407c9a5819898#rd

《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。

81 篇文章
浏览 15K
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线