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

https://www.notion.so/images/page-cover/gradients_11.jpg

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

全书整体分为三个部分

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

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

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

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

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

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

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

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

4.1 找合适的人谈

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

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

4.2 创建利益相关方关系图

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

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

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

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

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

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

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

4.3 了解业务目标

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

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

主体 目标
个人 增加收入,扩大知名度,享受生活,获取知识
组织 增加营收,实现利润最大化,发展业务,成为市场领导者,提高稳定性,进入新市场,击败竞争对手
员工 获得工作意义,获取知识,帮助用户,成为专家
开发团队 提升指定的质量属性,降低成本,增加新功能,实施标准,缩短上市时间
国家/政府 安全、福利、社会责任、公民遵纪守法

4.3.1 记录业务目标

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

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

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

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

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

4.3.2 帮助描述业务目标

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

...)希望(...),因为(...

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

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

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

结束语

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

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