这是鼎叔的第七十八篇原创文章。行业大牛和刚毕业的小白,都可以进来聊聊。
欢迎关注本公众号《敏捷测试转型》,星标收藏,大量原创思考文章陆续推出。本人新书《无测试组织-测试团队的敏捷转型》已出版(机械工业出版社),各大电商平台热销中,30万字350页。
本篇开启第六个专辑《测试左移与右看》的领域主题分享,中间也穿插其他原创的知识思考内容。
对产品研发而言,最大的风险在于用户需求没有挖掘清楚,而且产品的需求描述和传递过程失真,最终导致生产出来的产品不是用户真正想要的。精益需求生产过程,就是希望尽可能地降低这种极大的生产浪费。这套互联网行业的生产过程,也适用于任何行业的产品精益生产。
在互联网行业中,业务需求变化很多,很快,业务人员,产品人员和技术人员经常对要交付需求的上线优先级无法达成一致,产生推诿和争吵。那么,完整的精益需求产生过程应该是怎样的?它如何尽可能提高产品成功的概率,并降低研发过程中的偏差和耗费?
用户需求的本质
业务团队的需求是从愿景出发,围绕商业方向确定目标用户群。
用户的需求是从自己的问题和痛点出发,希望有产品功能能够解决它们。
产品功能方案如果成功解决用户问题,就能积少成多,一步步实现商业价值。
用户需求的本质特征是隐形的,只有对市场和用户有深入洞察力的产品经理,才能将其挖掘出来。因为:
用户嘴里说的,不等于用户实际做的,也不等于用户心里想的。
用户需求往往是动态变化的,不是确定不变的。
用户需求是多层次的,产品经理需要一定的创造力才能找出最契合的定义。
需求往往在社会化协作中产生,产品经理需要使用一致的高效的描述语言。
什么是精益产品思维
精益需求的核心设计思维及实践,就是要持续洞察用户和市场,开放探索。精益产品的成功也来自于整个过程中更强的应对不确定性的能力。
作为拥抱敏捷的团队,产品的成功来自快速试错,Fail Fast。快速的价值反馈闭环,即“Build-Measure-Learning”,能够降低试错成本,让团队学习到宝贵知识,并更快地走向成功。
产品设计思维,精益思想,敏捷研发,三者互相成就一款成功的产品。设计思维的目标是“挖掘问题”,精益的目标是“做正确的事”,敏捷的目标是“正确地做事”。
三者合一的详细指导方法过程如下:一个产品的产生有探索,定义,设计和交付四个主要阶段,精益原则贯彻整个需求生命周期的始终。这个周期中的具体活动包括:定义业务愿景,梳理产品战略,筛选业务重大举措,提炼需求定义,进行实验验证解决方案和确认需求优先级,再通过多个迭代构建产品并运行,交付给用户,同时获得持续改进的知识。
精益产品的全生命周期管理
下面我们从一个基本流程开始详细介绍。
精益需求的全流程,大概可以分为十个步骤。前五个步骤是从原始需求到问题定义的推导,后五个步骤是从问题定义到待开发的产品需求确认。
在需求产生过程,需要理解并实践的核心问题有:
一 如何定义产品需求?产品的定位和目标是什么?
根据KANO模型,本需求是哪个类型?必备型(基础能力),期望型,还是魅力型?参考:聊聊竞品体验对比评测(上)。
本需求处于什么周期中,是引入期,成长期,还是成熟期?
确定产品的定位和目标,这个过程容易么?如果困难,难在什么地方?
有信息输入不够的地方么,具体是哪些?哪些信息还不太确认,需要做进一步的验证?
产品经理如何让开发、设计、测试和管理者对产品的目标和定位达成一致?
产品的定位和目标可以用下列信息要素来梳理:
-
目标用户:核心用户群体的关键特征是什么?早期用户群体的关键特征呢?
-
客户需求:关键用户的问题和期待是什么?
-
解决方案:提供怎么样的产品或服务?
-
业务价值:业务的定位,贡献的目标和价值。
-
独特卖点:相对于现有方案和竞品,优势和卖点是什么?
-
产品愿景:一句话描述。
当面对新的需求时,如果想不通该不该做,就重新思考产品定位和目标。
二,如何挖掘用户的问题和目标?
注意用户的表达,要求不等于需求,请求不等于需求,反馈也不等于需求!我们给出的解决方案,也不等于需求本身。
需求的第一条原则,还是要从用户的问题出发来推导。
三,产品的用户和干系人是谁?
按用户距离,可以分为直接用户,间接用户或关联用户。
从其他维度,还可以区分为内部用户和外部用户,生产者和消费者,B端用户和C端用户。
针对用户如何建立更细致的类型区分?基于什么属性进行进一步的区分?下面是一个简单的属性分类示范。
下一步,如何找出本产品最核心的用户类型?
我们可以通过象限法来绘制不同用户类型所在的地方。横轴是用户数量或规模,纵轴是用户的需求,或用户影响力,或用户贡献。
也可以通过矩阵法,针对当前的价值贡献,潜在的价值贡献和流失风险,定出该类型用户的优先级。
四,用户画像如何绘制?
前面说过,内部用户和外部用户的画像可能完全不同,需要区分绘制。
我们可以给典型用户绘制一个卡片,让团队成员觉得真实可信,我们充分想象,人物就在我们眼前,用户形象如何,叫什么,她有什么基本信息,特征描述,他/她的痛点/期待是什么,目标是什么。
对于内部用户,我们可以把卡片信息聚焦在内部协作场景,职责,痛点和期待。
比如内部负责监控的IT工程师客户,他的痛点描述语言会更加技术化,痛点场景也以内部典型的跨部门协作场景为主。我们绘制的用户画像会把他的职责和期待目标也定义得非常具体,使用的专业术语比外部用户多出很多。
最后,我们对用户特征梳理进行复盘:
我们的用户特征情报从何而来?如何确认信息靠谱?哪些信息输入还不够?
一定是直接用户的问题才需要关注么?关联用户/间接用户,他们的问题有什么启发?
五,产品电梯演讲
电梯演讲,就是在电梯的一分钟时间里,以XX为对手,用一段话说服老板接受一个产品方案。
我们上面的用户对象分析,对标产品电梯演讲的目标用户群,有什么差异?
六 接下来,从用户出发,发现场景
这一块就要利用之前介绍的用户故事知识了。聊聊用户故事与测试启发
一个用户故事发生的场景,包括这些要素:时间(WHEN),地点(WHERE),和谁(WHO),前情(BEFORE),后果(AFTER)等。
利用用户故事挖掘场景,我们要特别关注逻辑合理性,多问自己这些问题:
-
核心用户、问题(痛点)和场景的逻辑合理么?
-
可以用什么手段去验证这个场景是真实存在的?
-
用户为什么会遇到这样的问题?
-
其内心深处的目标和动机是什么?这个目标是真正的目标么?
-
真正的目标和当初的问题有怎样的关联?
-
当前哪些信息输入还不够?可以通过哪些手段获得这些信息?
七 洞察用户目标
通过上面的过程,用户清楚了,目标清楚了,那准确的问题定义应该是什么?
我们想给用户的可能是一个很复杂的产品,用户想要的东西可能非常简单。
为了洞察出用户真正的目标,我们可以不断追问问题的本质,如下:
-
从问题的描述,发生的场景要素,我们判断是哪一类用户的问题?
-
问题的根本原因是什么?
-
问题发生后对用户造成的影响是什么?
-
问题发生后对业务的影响是什么?
明确了用户真正的目标,精益需求的前半部分才算是真正完成,后面的环节就依次是:针对痛点的创意发散,端到端设计用户体验路线,原型设计,最后进入技术评估方案。这些本文就暂不展开了。