你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

在客户同理心的基础上进行构建

“必要性是发明之母。这句话捕捉到了人类精神的不可磨灭性和我们自然的发明动力。 正如牛津英语词典中所解释的那样，“当对某事的需求变得势在必行时，你将被迫寻找获得或实现它的方法。”很少有人会否认这些关于发明的普遍真理。 然而，正如 数字经济中的创新 一文所解释的，云创新需要在发明和采用之间实现平衡。

如果我们继续打个比方，创新来自一个更扩大的家庭。 客户同理心是创新的骄傲之父。 若要创建推动创新的客户同理心解决方案，需要合理的客户需求，让他们能够回来解决关键挑战。 这些解决方案基于客户需求，而不是所需或异想天开。 若要找到客户的真实需求，请从同理心和对客户体验的深刻理解开始。 对于许多工程师、产品经理甚至商业领袖来说，同理心是一项欠发达的技能。 幸运的是，云架构师角色的多样化交互和快速节奏培养了这种技能。

如何建立同理心，为什么客户同理心如此重要？ 客户同理心可帮助你了解和分享客户体验。 从第一版最低可行产品 (MVP) ，到市场级解决方案的正式发布，客户同理心可以帮助你构建更好的解决方案。 更重要的是，同理心可以更好地使团队能够发明鼓励采用的解决方案。 在数字经济中，能够最轻松地同情客户需求的产品团队可以使用更好的工具来重新定义和引领市场，从而打造更光明的未来。

定义假设以客户同理心构建

定义假设是规划的基本部分。 你计划得越多，就越清楚地看到你的假设逐渐成为一个好主意的基础。 假设通常是自我同理心的产物。 换句话说， 如果我处于这个位置，我会想要什么？ 从生成阶段开始时，它会最大程度地减少假设可能入侵解决方案的时间段。 这种方法还加速了与真实客户的反馈循环，触发了更早学习和增强同理心的机会。

注意

正确定义生成的内容可能不是那么容易，需要一些练习。 如果生成内容太快，它可能无法反映客户需求。 如果你花费太多时间来尝试了解最初的客户需求和解决方案要求，则市场可能会满足这些要求，然后才有机会构建任何内容。 在任何一种情况下，学习的机会都可能大大延迟或减少。 有时，数据甚至可能会损坏。

历史上最具创新性的解决方案始于一种直觉的信念。 这种直觉来自现有的专业知识和第一手观察。 从生成阶段开始，因为它允许快速测试你的直觉。 从那里，你可以培养更深入的理解和更清晰的同理心程度。 在解决方案的每次迭代或发布中，平衡都来自于构建展示客户同理心的 MVP。

为了稳定这种平衡行为，以下两个部分介绍了如何用同理心构建和定义 MVP 的概念。

定义以客户为中心的假设

当你以同理心进行构建时，这意味着你根据定义的假设创建一个解决方案，这些假设说明了特定的客户需求。 以下步骤制定一个假设，鼓励以同理心进行构建。

1. 以同理心进行构建时，客户始终是焦点。 这种意图可以有多种形式。 你可以参考客户原型、特定角色，甚至是你想要解决的问题中的客户图片。 请记住，客户可以是内部的（员工或合作伙伴）或外部的（消费者或企业客户）。 此定义是供你检验的第一个假设：我们能帮助这个特定的客户吗？
2. 了解客户体验。 以同理心进行构建意味着你可以与客户的体验相关联并了解他们的困境。 这种思维方式表明了下一个要测试的假设：我们能否帮助这个特定的客户解决这个可管理的难题？
3. 为单个挑战定义明确的解决方案。 如果依赖于跨人员、流程和主题专家的专业知识，则这可能会导致潜在的解决方案。 那么，要测试的完整假设是：我们能否通过建议的解决方案帮助此特定客户应对这种可管理的挑战？
4. 到达价值陈述。 你希望为这些客户提供什么长期价值？ 这个问题的答案创建了你的完整假设：通过使用建议的解决方案来解决这个可管理的难题，这些客户的生活将如何得到改善？

最后一步是客户同理心驱动假设的高潮。 它定义了受众，问题，解决方案以及进行改进的指标，所有这些都以客户为中心。 在度量和学习阶段，应测试每个假设。 随着团队对可解决的客户群产生更大的同理心，预测客户、问题陈述或解决方案的变化。

注意

目标是以客户同理心构建，而不是以客户同理心进行规划。 我们很容易陷入无休止的计划和调整循环中，目的是找到完美的客户同理心声明。 在你尝试制定这样的声明之前，请查看以下有关定义和构建 MVP 的部分。

证明核心假设后，以后的迭代除了同理心测试外，还侧重于增长测试。 构建、测试和验证同理心后，你开始大规模了解可寻址的市场。 通过扩展前面所述的标准假设公式，可以更深入地了解可寻址市场。 然后，根据可用数据估计总市场的规模， () 潜在客户的数量。

从那里，估计遇到类似挑战并因此可能对解决方案感兴趣的总市场的百分比。 然后，你有你的可寻址市场。 下一个要 检验的假设 是：如何使用建议的解决方案来解决这一可管理的挑战，将如何改善客户的生活？ 少量客户抽样显示领先指标，这些指标表明对参与的客户池有百分比影响。

定义一个解决方案来测试假设

在构建-度量-学习反馈循环的每次迭代中，你对构建具有同理心的尝试都是由 MVP 定义的。

MVP 是创建足够多的解决方案以与客户一起学习所需的最小工作单位（发明、工程、应用程序开发或数据体系结构）。 每个 MVP 的目标是测试部分或全部先前的假设，并直接从客户那里获得反馈。 输出不是一个漂亮的应用程序，具有改变行业所需的所有功能。 每次迭代的期望输出是一个学习机会，一个更深入地测试假设的机会。

时间盒是确保产品保持精益的标准方法。 例如，确认开发团队认为可以在单个迭代中创建解决方案，以便进行快速测试。 若要更好地了解如何使用速度、迭代和发布来定义最小含义，请参阅 规划速度、迭代、发布和迭代路径。

降低复杂性并延迟技术峰值

创新方法中所述的发明规则探索了提供成熟创新或可缩放的 MVP 解决方案通常需要的功能。 使用这些学科作为特征包含的长期指南。 同样，在早期测试客户价值和解决方案中的同理心时，将它们用作警示指南。

功能广度和不同的发明层面不能在一次迭代中全部创建。 MVP 解决方案可能需要经历多个版本才能包含多个层面的复杂性。 根据对开发的投资，可能会有多个平行团队在不同层面内工作以测试多个假设。 尽管保持这些团队之间的体系结构一致性很明智，但在验证价值假设之前，尝试构建复杂的集成解决方案是不明智的。

在 技术峰值的频率或数量中，可以最好地检测复杂性。 技术峰值指的是创造无法轻松通过客户来测试的技术解决方案。 当客户价值和客户同理心未经测试时，技术高峰会代表创新的风险，应尽量降低。 对于在迁移工作中发现的成熟测试解决方案类型，技术尖峰可能在采用过程中很常见。 但是，它们会推迟对创新工作中的假设的测试，你应该尽可能推迟测试。

无情的简化方法有助于任何 MVP 定义。 此方法意味着删除任何无助于验证假设的功能。 为了最大限度地降低复杂性，请减少测试假设不需要的集成和功能的数量。

构建 MVP

在每次迭代中，MVP 解决方案可以采用许多不同的形式。 共同的要求只是输出允许对假设进行测量和测试。 这个简单的要求启动科学过程，让团队以同理心进行构建。 为了实现这种以客户为中心的理念，最初的 MVP 可能只依赖于一种发明层面。

在某些情况下，最快的创新途径意味着暂时完全避开这些规则，直到云采用团队确信该假设得到准确验证。 从像 Microsoft 这样的科技公司，本指南听起来可能违背直觉。 但它强调，客户需求（而不是特定的技术决策）是 MVP 解决方案的最高优先级。

通常，MVP 解决方案由具有最少功能且功能有限的应用程序或数据解决方案组成。 对于具有专业发展专业知识的组织来说，这条路径通常是学习和迭代最快的路径。 以下列出了一些球队可能会采取的其他方法来构建 MVP：

• 一种预测算法，在 99% 的时间内是错误的，但它显示了特定的预期结果。
• IoT 设备在生产规模上无法安全通信，但演示进程中几乎实时数据的价值。
• 由公民开发人员构建的应用程序，以测试假设或满足较小的规模需求。
• 一个手动过程，可重新创建要遵循的应用程序的优势。
• 足够详细的线框或视频，让客户进行交互。

开发 MVP 不应该需要大量的开发投资。 最好尽可能限制投资，以尽量减少一次测试的假设数。 然后，在每个迭代和每次发布中，你都会有意地将解决方案改进为代表多个发明学科的可缩放就绪解决方案。

加速 MVP 开发

上市时间对于任何创新的成功都至关重要。 发布越快，学习也就越快。 学习越快，产品的扩展速度也就越快。 有时，传统的应用程序开发周期会减慢这个过程。 更常见的情况是，创新会受到可用专业知识的限制。 预算、员工人数和员工可用性都会限制团队可以处理的新创新的数量。

人员配备限制和同理心建设的愿望催生了公民开发人员的快速增长趋势。 这些开发人员可降低风险，并在组织的专业开发社区中提供规模。 公民开发人员是客户体验方面的主题专家，但他们没有接受过工程师培训。 这些人员使用原型设计工具或轻量级开发工具，这些工具可能会被专业开发人员所轻视。 这些与业务相关的开发人员创建了 MVP 解决方案和测试理论。 如果对齐良好，此过程将创建可提供价值但未通过足够有效的规模假设的生产解决方案。 在开始缩放工作之前，Teams 还可以使用这些解决方案来验证原型。

在任何创新计划中，云采用团队都应使其产品组合多样化，以包括平民开发人员的工作。 通过缩放开发工作，可以在减少投资的同时形成和测试更多的假设。 验证假设并确定可寻址市场时，专业开发人员可以使用新式开发工具强化和缩放解决方案。

最终生成门：客户痛点

当客户同理心很强时，一个明显存在的问题应该很容易识别。 客户的痛点应该是显而易见的。 在生成期间，云采用团队正在研究一个解决方案，以根据客户痛点来测试假设。 如果假设定义明确，但痛点不是，则解决方案并不真正基于客户同理心。 在此方案中，生成不是正确的起点。 而是要首先要投资于建立同理心，并向真正的客户学习。 建立同理心和验证痛苦的最佳方法很简单：倾听客户心声。 花点时间和他们见面，观察他们，直到你能找到经常发生的痛点。 充分了解客户痛点后，即可测试一个假设的解决方案来解决该难题。

什么情况下不能采用这种方法

有许多法律、合规性和行业要求可能需要采用替代方法。 如果公开发布开发解决方案，则此方法可能不适用：

• 给专利计时、知识产权保护或客户数据泄露创造风险
• 违反既定的合规性要求

如果存在这些感知到的风险，请在采用任何引导式发布管理方法之前咨询法律顾问。

参考

本文中的一些概念基于 Eric Ries 中 The Lean Startup 讨论的想法。

后续步骤

构建 MVP 解决方案后，可以度量同理心值和缩放值。 了解如何衡量客户影响。

客户影响度量值