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