【持续交付2.0学习笔记】探索环

Love__Tay

已于 2023-04-20 16:17:58 修改

阅读量150

点赞数 1

文章标签：学习 devops

于 2023-04-12 11:09:49 首次发布

本文链接：https://blog.csdn.net/Love__Tay/article/details/130100064

版权

持续交付"8"字环之探索环

探索环（Discovery Loop）可以看作一个理解真实需求、判断优先级、再评估需求的过程，具体包括提问、锚定、共创和精炼4个过程。

探索环的意义

产品或服务开发过程中的3个风险假设：

用户假设，即我们提供的产品服务是针对某类潜在用户人群的需求的假设；
问题假设，即目标用户群之所有有这种需求，是因为他们的确存在某些痛点（或问题）需要解决的假设；
解决方案假设，即我们提供的解决方案可以解决这些痛点或问题，而且比其他现存的解决方案都有效且高效。

这三类假设中，任何一个假设不成立，都会导致我们事半功倍，前功尽弃。因此，探索环的目标就是要持续识别和定义这些有价值的假设，选择并验证其中风险最高或最易验证的价值假设，并借助价值验证环得到数据反馈，以便深入理解用户需求，把握业务前进方向。
在工作中遇到的一个案例：我们的团队要在已有系统A的基础上开发出一个系统B。从启动到现在已历时半年——从一开始的人员培训，到期间的几次需求调研和修修改改，再到今天与客户面对面沟通。沟通的结果就是系统A的设计与当前用户的需求不太匹配。系统B是作为新系统来取代客户当前在使用的旧系统C的，但从与客户的沟通中我们意识到，系统B并没有表现出比系统C更高效。客户表示，系统B起码要达到与系统C同样的水平，他们才会考虑同意新系统B上线。虽然速度很重要，但起码要保证质量。

四个环节

1、提问

提问环节不仅是要找到“实现什么”以及“如何实现”，更是要了解客户需求背后要解决的真正问题“为什么要实现”，以便规划更加方便快捷的验证方案或解决方案。
为了解决客户的问题，我们可能会找到很多种解决方案，但前提是我们必须发现“正确的需求”。所谓“正确的需求”，是那些能够解决客户真正想要解决的问题，而不一定是由客户提出的解决方案。
多问几个“为什么”，尽量避免因为感觉自己熟悉这个问题域，而过早地放弃探索。更加深入地理解所要解决的问题、了解其背后的真正原因，才能更好地解决问题。

2、锚定

该环节确定要达成的具体目标与结果。应尽量清晰地描述目标，这样我们可以知道自己当前所在的位置，离目标还有多远。清晰的目标应有时间限定，否则很可能成为一个企业愿景，无法直接指导企业日常生产管理的具体活动。

愿景与目标

3、共创

在理解了问题和制定目标后，团队设法验证或达成目标而找到多种可行性解决方案的过程。
每一个解决方案都是基于一定的假设条件或猜想得到的，而每一个假设都等同于一个风险项。
分析方法包括“量化式影响地图”和“用户旅行地图”等。（我没太看懂，感觉这块好难hh)
在寻找解决方案的过程中，要注意分析瘫痪(paralysis by analysis)和直觉决策(extinct by instinct)两个陷阱。

1、分析瘫痪：指因为过度分析（或过度思考）而无法决策或采取行动，最终影响结果产出的一种状态。通常是由于有太多的细节选项，或者过于寻求最佳或“完美”的解决方案，并担心做出任何可能导致错误结果的决定。
2、直觉决策：指不做分析，基于匆忙的判断或直觉反应而做出致命的决定。它是与分析瘫痪相反的另一个极端。

4、精炼

对共创环节中得出的众多方案进行评估，从中筛选出团队认为最小可行性解决方案的过程。评估因素包括实施成本、时间与人力、效果反馈周期，以及该方案对业务目标的影响程度。

5、探索成果表述

经过以上几个环节，可将探索的成果以下述形式表述出来，并且达到团队共识：
我们相信，通过实现（xxxxx这样的最小功能组合），我们的指标可以达到（yyyyy程度），说明我们关于（zzzzz）的假设是成立的。

探索环的三个工作原则

分解并快速试错
在相同的成本下，尽管快速试错失败次数多，但可能会得到更多成功的想法
一次只验证一点
一次只验证一个需求假设。时刻提醒自己，我们的目标是验证我们的假设，实验方案只是我们验证假设的手段，而不是我们的目标。
允许失败
我们却无法保证每个方案都会获得成功，只要具有开放的心态，我们就可以从所有方案中都学到很多新的知识，而这些收获无论是对产品今后的成功，还是团队人员的能力提升，都具有非常重要的作用。

共创与精炼的常用方法

装饰窗方法
为新功能预留一个“入口”，让用户能够看到，但实际上并没有真正实现其功能。目的是利用最小成本，来验证用户是否喜欢某个功能，以及其紧迫程度，为是否研发后续更全面的解决方案提供数据支持。
最小可行特性法
产品在从1到n的过程中，寻找用户可直接感知到的需求假设作为产品的最小可行特性优先开发的方法，以尽可能少的成本快速增加或修改某个产品特性，让用户使用，收集真实反馈，专注于验证功能改进，验证用户是否喜欢该功能，再决定是否还要继续开发后续的功能。
特区法
在特定用户范围内进行试验，以验证某个新功能的有效性。这样，即使新功能无效或者效果不好，也不会影响特区外的用户。试图回答“该需求是否真实存在？该需求是否强烈？”这类的问题
定向探索法
针对具有某种特定行为的特定用户群体，依据该用户的具体行为模式，设计调查提纲，有针对性地探索其行为背后的动机。
稻草人法
并没有开发功能，而是假装这个功能已经完成了，并向用户展示该功能的真实效果（与装饰窗方法的不同之处），从而得到用户的真实反馈。
最小可行产品法
从0到1的过程中使用，以尽可能少的成本快速开发产品的核心功能，并找到用户，收集真实反馈，验证真实的用户需求，以确定新产品方向和形态的方法，其目标是找到合适的产品形态。