▏沉痛之鉴：从昂贵代价中汲取教训
在获得利益相关者首肯后，我们开启了一项扩展云原生平台的项目，欲借强大的 Netflix 堆栈及其蓝绿部署等工具，化解平台现存的可用性难题。我们对平台需求自信满满，旋即投入开发。然而，当向与项目利益相关者不同的用户展示新功能时，却遭遇负面反馈。历经反复迭代与演示，用户期望与我们的开发方向之间的巨大鸿沟愈发凸显。最终，我们不得不承认用户永远不会接纳我们的成果，项目遂被取消。预算付诸东流，回报渺无踪迹。这个初衷良善、意在赋能团队的尝试，以失望落幕，深刻揭示了我们的假设与用户现实之间的强烈反差。
事后反思，我们意识到未考虑用户观点实乃关键疏失。事实证明，我们的一致性假设错误百出，这也凸显了真正的用户参与和反馈对引导项目走向成功的至关重要性。
▏同理之蕴：明晰同理心的深刻内涵
我们务必区分同理心与同情心。同情心是对处于困境之人做出反应，却未必理解其观点，而同理心则意味着从他人视角去体悟其经历。
区分二者至关重要，只因同情仅仅涉及承认负面情绪或在目睹他人的痛苦时感到痛苦。例如，下图或许能唤起有服务器机房经验之人的同理心，使其理解图片中人物的所历之事。同理心超越负面情绪，它还涵盖分享他人的兴奋或喜悦。
同理心有其该做和不该做的事。
首先，要学会倾听而非急于给出解决方案，这对许多技术脑来说都是一个挑战。与其假设并解决问题，不如提出探究性问题，更好地洞悉此人的经历与需求。
通过提出开放式问题来揭示核心问题与痛点，练习倾听。要勇于承认自身的未知，拥抱脆弱，而非急切地展示能力。避免解释为何某人的方法有误，因为这会让人感到被孤立而非被同理。同样，避免将他人的担忧最小化，比较他们的经历无法培育同理心或理解。
▏筑台之由：探寻构建平台的深层缘由
当扩展引发复杂性骤增时，组织会借助平台来简化运营。DevOps 文化激励工程师拥有所有权，通过消除其他团队的瓶颈来提升速度。然而，随着公司的发展，安全性、合规性、性能等诸多因素的需求会产生认知负担。
认知负荷乃是学术研究的一个课题，它探究学习任务的难度对人们的影响。适度平衡认知负荷有助于人们在学习环境中更好地汲取新信息。这一理念亦被应用于理解工作场所的任务。美国国家航空航天局（NASA）有一个饶有趣味的概念叫脑力负荷，它是在航天飞机计划期间开发的，建立在认知负荷的概念之上，增添了截止日期、环境因素以及其他可能面临的压力源的影响。
认知负荷有三个主要构成部分：
- 内在认知负荷 描绘了手头任务的潜在复杂性——比如规划去超市的路线以及开车的行为本身；
- 关联认知负荷 代表完成任务所需的知识与技能——如拥有驾驶执照并知晓如何操作汽车；
- 外在认知负荷 包括干扰注意力的因素——例如意外的交通状况或迫使调整路线的弯路。
在企业层面，当过多的人参与过多的流程时，无关的认知负担会呈指数级增长，致使整体组织效率下滑。平台通过吸纳大部分这种无关的认知负荷来实现规模化，要么直接承揽工作，无需用户亲力亲为，要么通过抽象显著简化工作。对于任何无法完全消除的剩余任务，平台竭力使用户能够尽可能轻松地进行交互。
将平台构建为产品意义非凡，缘由众多，这与以客户为中心的思维方式不谋而合。产品有客户，客户有选择。这与我们通常处理内部工具的方式大相径庭。然而，我们曾目睹内部客户拒绝提供的产品，他们选择动用自身资源在别处购置解决方案，从而催生了影子 IT。
▏成果之基：构建可交付成果的平台
将平台视作产品，你能够优先考虑使其成为最佳解决方案。这一点举足轻重，因为替代方案（用户拒绝迁移或采用你的平台）同样不可取。一个平淡无奇的平台或许只是成为公司不断增长的技术堆栈中的另一层，无法解决真正的用户问题。它可能会在未被正式取消的情况下持续存在，最终导致公司的技术债务，而非创造价值。
旧方法极具事务性。用户通过工单系统提交请求，请求特定功能或更改构建系统。我们要么尝试将这些请求直接融入平台中，要么设法自动化处理以应对数量之多。不幸的是，由于其反应性，这种旧方法导致理解和同理心十分有限。
平台工程以替他人构建为核心，而非为自己构建。与传统的系统管理相比，这标志着思维方式的根本转变。系统管理员甚至 DevOps 工程师都专注于维护和修改系统的共享组件。相比之下，平台工程团队构建自助服务产品供其他人使用。新的重点在于创造富有吸引力的产品，这需要了解用户的需求。通过运用同理心并设身处地为用户着想，你将比单纯依据对他们需求的假设提供解决方案更加成功。
▏益处之显：领略此方法的显著好处
这种方法好处斐然。通过专注于依据用户的直接反馈构建用户实际所需的内容，你可以优化公司资源的使用。例如，倘若你开发了五项功能，但仅有两项对内部客户真正有价值，那么其余三项功能则意味着浪费精力并导致技术债务。然而，如果所有五项功能都对工程团队切实有用，你将显著提升他们的有效性。这种方法能够加速增长，并可能大幅提高员工满意度。
开发人员体验的大部分内容都聚焦在满意度上，这自有其道理。通过了解用户需求，为他们构建解决方案，并积极消除他们的痛点，你自然会培育出更快乐的工程师。这构建了一个良性循环：从确定用户需求开始，接着构建满足需求的产品，他们会欣然采用。这提高了公司的整体效率和有效性，进一步提升了用户满意度。循环持续进行。反之，若你在未采用此方法的情况下构建了某些东西并期望被采用，一旦用户不参与，这个循环就会停滞不前。你无意中阻碍了公司提高效率的潜力，并为这种积极循环制造了障碍。
▏成果之途：利用同理心获取卓越成果
要在构建平台时运用同理心，你需要营造一种同理心文化。由于我们正在处理人类的情感，因此建立文化基础至关重要。这意味着积极鼓励每个人练习倾听，专注于理解他人，而非立即制定回应。此外，以个人身份了解同事和客户也极为重要。建立这些联系能够更轻松地设身处地为他们着想，理解他们的经历，所有这些对于以同理心进行建设至关重要。
从产品的角度来看，建立同理心文化使你能够与用户就他们的真实需求进行坦诚的对话，而非仅仅局限于请求。这要从自己示范所需的行为开始。通过积极向同事和客户展示这种方法，你可以为其他人树立榜样。请记住，领导力可以来自组织的任何级别，你无需一个管理头衔来展现这些原则。
运用产品管理实践深入了解你的用户、他们的痛点以及他们所需的解决方案。在构建内部平台时，这些技术同样大有益处。例如，调查可能有利于获取主观数据。要了解某人的观点，你需要了解他们对系统的看法，而不仅仅是衡量部署频率或其他客观指标。直接调查你的用户，提出诸如“你觉得自己是否尽可能有效？”这样的问题，这种类型的反馈对于平台开发价值非凡。
DevEx 框架还提供了一种强大的方法来识别关键的改进领域，并就你的平台如何解决用户痛点提出正确的问题。这是因为它的要素——反馈回路、认知负荷和心流状态——紧密交织在一起。例如，如果缓慢的构建时间会破坏反馈循环，直接解决这个问题将有助于用户更长时间地保持心流状态。同样，如果简化部署选项，降低 AWS 中的复杂性，就可以降低认知负载并提高效率。强调心流状态至关重要，用户保持专注和高效状态的时间越长，他们为公司创造的价值就越多。
▏核心之要：总结同理心构建平台的要点
同理心意味着首先看到人，而非仅仅是问题。通过与人建立联系，你能够接触到更广泛的解决方案。只专注于解决特定问题会过早地限制你的选择。花时间积极倾听和理解这个人及其更广泛的挑战，最终将带来更有效的解决方案。
永远牢记你的目标受众，你不是为自己构建，作为打造产品的平台团队，是在为客户构建。将这种心态置于首位将指引你满足他们的需求。我们在本文中讨论的大部分内容在个人层面上皆可行，比如集成产品管理技术等。但是，如果你是平台团队的一员，你可以立即开始有所作为。专注于积极倾听，拒绝提供即时解决方案。
- end -