《架构师修炼之道》摘录04-换位思考

本系列内容来自《架构师修炼之道》。在自己的笔记中以半摘录的方式，用 blockquote 穿插自己的思考和感悟，以加深对内容的理解和消化。

全书整体分为三个部分

• 第一部分介绍软件架构的基础知识和架构师必备的设计思维

• 第二部分讲解架构师需要掌握的核心技能和知识

• 第三部分讨论一系列使用的架构设计方法

前两部分适合从头到尾通读，第三部分用于参考和检索。

第四章的标题是“换位思考”，本章主要阐述如何从利益相关方的角度出发，换位思考，理解业务目标，为后续的架构设计铺路。

开发软件是为了服务于人，因此必须理解受软件影响的人。只有理解他们的需求，才能搞清楚到底要解决什么问题。

与软件有关、受软件影响的人称之为利益相关方。架构师有责任确定利益相关方并了解他们的需求。利益相关方对系统的期望将直接或间接影响我们的设计方式。

换位思考也叫同理心，是推动设计的引擎。

4.1 找合适的人谈

用户是重要的利益相关方，开发系统和维护系统的人也是。通常情况下，利益相关方不止一个人。与团队合作不同于与个人合作。每个人都有自己的看法，同一个团队也会有相左的意见。所以必须设法了解整个团队的想法。

利益相关方关系我们开发的软件，他们将会影响架构设计。在要求利益相关方参加未来的设计研讨会时，需要先确定他们是谁。这时候得用上利益相关方关系图（stakeholder map)。

4.2 创建利益相关方关系图

下图是书中的一个案例。在实际工作中，你可以按照自己喜欢的方式来构建关系图。形式不重要，重要的是能够清楚表达利益相关方的关系

架构是为客户服务的，如何确保架构能够为客户带来价值呢？通用电气的软件架构师的办法是运用 “ 以客户为中心 ” 的设计流程。先搞清楚谁是客户，他们想做什么；然后将系统按照客户的任务进行划分。架构师需要了解每项任务的启动步骤，以及哪里容易出错。这样，由表及里，确保深层结构能实现客户价值，通用电气将其称之为 “ 客户体验架构 ”，设计流程如下：

• 观察客户在正常流程下如何完成任务，向对方提问，确定对客户至关重要的事项，包括功能需求和质量属性需求。

• 围绕客户需求设计系统并记录在原型里。原型应尽可能具有交互性，而不仅仅是流程图。

• 尽早与客户一起评审原型，确保对方真正了解新系统的变化，以及这些变化对他们的影响。

• 根据客户评审会上的反馈修改调整架构设计。

这让我想到了一些B端系统的场景。参与的系统中有服务于开发人员的云平台系统，也有面向普通人的商家系统。这两类人群在工作方式、生活场景、对技术理解程度等多方面都有不同。但他们都是某一个系统的客户，在设计开发对应系统时，采用“以客户为中心”的设计流程来做。如果按照通用电气的设计流程来做，便可以在架构设计工作开始之前，了解到不同用户群体的操作习惯和工作方式，从而在设计阶段为我们提供更多帮助。

4.3 了解业务目标

所有的软件系统的开发都是为了满足业务目标。讨论系统的质量属性，权衡取舍、技术债务都需要以业务目标为基础。

业务目标是架构的主要驱动因素。当多个需求发生冲突时，可以根据业务目标对他们进行优先级排序。描述业务目标应该使用简单明了的文字，从需求出发，阐明利益相关方想从软件系统中获得什么。

4.3.1 记录业务目标

清晰的业务目标应该是可衡量的，有明确的成功标准。这样的业务目标至少包含三个方面：

• 主体 特定的人或角色。如果利益相关方有名称，就加上名称。

• 结果 用可衡量的结果表达利益相关方的需求。如果系统成功，会带来哪些变化？

• 背景 背景信息有助于我们进一步理解需求。

大多数系统只有三到五给业务目标。与多个利益相关方合作时，一定要标注目标的相对重要性，比如写上必须有（must have)或者最好有（nice to have)能起很好的效果。

4.3.2 帮助描述业务目标

虽然利益相关方通常知道他们在做什么，但大部分人很难将需求用可衡量的方式描述出来。架构师应该准备一些简单的模板，帮助其表达需求。比如观点填空：

（...）希望（...），因为（...）

举个例子：运营希望可以一键导入数据，因为人工填写数据很浪费时间

架构师应该与产品经理或者其他业务相关方合作，确定系统的业务目标。这些人通常可以毫不费力地描述系统的业务目标。如果他们也不能清楚地描述业务目标，你们应该一起搞清楚。

这里可不是所谓的“技术驱动赋能业务”。所谓“赋能”是用更高级的手段解决问题。目前还处于确定业务目标的阶段。在我看来，这是从项目负责人的角度出发，帮助确定业务目标。为后续架构设计扫清模棱两可含糊不清的问题。

结束语

换位思考很重要，只有清楚了利益相关方是谁以及他们的预期，我们才能做出更好的设计决策。

理解业务目标也很重要。只有理解了业务目标，团队才能清楚架构设计的目标。