郭东白的架构课00020

你好，我是郭东白。从这节课开始，我们就进入到架构活动第二个环节的学习，那就是目标确认。

为架构活动确认一个正确目标，是架构师能为架构活动做出最大贡献的环节。从我的个人经验来看，一大半架构活动的目标都不具备正确性和合理性，也缺乏基本的逻辑论证。一旦目标错误，整个架构活动就没什么成功的希望了。所以，你如果能在这个节点上为架构活动注入理性思考，提升架构目标的正确性和合理性，那就能为公司贡献出巨大的价值了。

在大多数时候，架构师没有权力定义目标，但却有权力验证目标的正确性和合理性，进而将架构项目引导到一组正确的目标上去。不过这个非常重要的节点，经常被刚入行的架构师所忽略。那么这节课，我们就来看看怎么走好目标确认这一步。

什么是目标确认？

什么是目标确认呢？架构师在目标确认这个节点上，不仅要保障目标的正确性和合理性，还要保障目标的可达性。也就是说，目标确认是以终为始的。架构活动必须始于一个明确的目标，而一个成功的架构活动，最终也要止于这个目标。

正确、合理和可达，这三个词很常见，不过在架构活动这个上下文中，它们的含义会更有针对性一些。所以我先来澄清下这三个概念。

首先是目标正确（Correct），指企业在当下应该追求的目标。

比如在一家电商公司，我们到底是要追求GMV、订单数、DAU、NPS还是利润呢？虽然这几个目标对于电商企业来说都很重要，但是在企业发展的不同生命周期、细分产品的具体定位和竞争态势之下，当前最关键的目标只能有一个。

因而架构师就是要理解并验证自顶向下的决策逻辑，去保障分配到你的架构活动上的目标是正确的，并与企业的战略意图强相关。

其次是目标的合理性（Reasonable）, 指目标的设置是合理的：既具备足够的挑战性，但是又不会引起大面积的动作变形。具体而言，合理性覆盖架构活动具体的目标值、交付时间和质量期望。

最后是目标的可达性（Achievable），指目标最终可以被实现。任何架构活动都需要承担一定的风险，而“目标可达”的意思就是当某个风险实实在在发生的时候，这个目标实现的成本可能会增加（时间、人力、计算等成本）。但是目标仍旧需要突破风险，直到被实现，而不是被风险击败。

这三个维度看起来非常相似，不过你仔细推敲的话，会发现各自的出发点完全不同：

• 目标的正确性：站在企业决策者的角度去思考目标，从而帮助决策者做出正确取舍。
• 目标的合理性：以执行者的角度去审视目标，从而以乐观的心态给团队设置一个能带来成就感的合适的挑战。
• 目标的可达性：以赞助者的视角去审视目标，从而以悲观的心态来确保投资在重大风险发生时也能有回报。

总的来说，在确认目标的过程中，我们需要从决策者的视角来看目标是否正确，从执行者的视角来看目标是否合理，从赞助者的角度来看目标是否可达。这是行王道的做法。

如果不去做这些探索，或者明知目标不正确、不合理和不可达，却还要强行推进架构活动，那就是在绑架企业的决策者、架构活动的执行者和赞助者了，是行霸道的做法。

目标确认前的准备工作

在进入目标确认之前，我们需要做好一些准备工作，这将是目标确认和后续决策的重要输入。比如：

• 对企业目标的准确感知；
• 对架构项目核心角色（决策者、赞助者和执行者）的确认；
• 明确架构活动可以为这些角色创造的核心价值是什么，以及怎么度量这个价值。

我先解释一些企业层面的概念，因为架构师必须从全局来理解目标。

首先，要从决策者的视角来审视目标的正确性。决策者一般是企业或者部门的高层，应该清楚地知道架构活动的真实意图、对企业愿景所贡献的价值，以及在企业内的真正优先级。决策者这个角色在资历和层级上，往往高于其他角色，并对资源有调度权。从目标确认这个动作来说，你需要与决策者确认目标是否与企业的使命和愿景相一致。

其次，要从赞助者的视角来审视目标的可达性。赞助者必须是能真正为架构活动提供有限资源的人。也就是说，他应该对你需要的人力资源、奖金激励等核心资源有支配权。架构活动可以有不止一个赞助者，但最多不应该超过三个。若赞助者过多，诉求不一致，可能让架构活动的目标被多个利益方牵扯，最终导致失衡。

你需要了解赞助者在企业商业价值链中的位置。比如增长部门是通过花钱来获取用户，售后部门是通过服务用户来减少流失，而法务部门则是通过降低风险来减少损失。只有了解赞助者在企业价值链的位置，才能明白他们的核心诉求在哪里。

赞助者有时候不一定是受益方。比如刚才提到的电商项目，一个大的业务部门作为赞助者，需要出具研发资源做迁移，但真正受益的可能是另外一个业务部门。在法则二里我们就提到过，这是一个不符合人性的非常尴尬的设置。如果碰到这种情况，一定要和赞助者确认他的底线，这是他忍耐的极限。

有了赞助者提供的资源、细节，以及他背后的真实诉求，我们才能确认他真正最关心的目标是否可达。

最后是从执行者的视角来审视目标的合理性。执行者是架构活动所涉及的运营、产品和技术团队的负责人，可以调配他管理的人力或者运营资源。对于一个大型架构活动而言，架构师往往需要面对多个执行者。因而这里的关键是了解这些执行者所面临的挑战是什么，比如已经在执行中的大项目、剩余研发带宽等。只有了解相关执行者在你这个架构环境中投入的真实带宽，才能判断目标是否合理。

你可能发现了，刚才提到的这些概念，与上节课提到的使命、愿景，以及我们在模块一里提到的商业价值、回报和用户价值，不仅在课程里经常出现，而且又有点类似。其实这些概念都与目标密切相关，如下图所示：

在架构活动中有四个核心角色：决策者、赞助者、执行者和用户。前三个角色都是为企业愿景服务的。除此之外，企业中的所有架构活动最终也都服务于企业愿景。

每个架构活动都有一个正确、合理且可达的架构目标，可以把整个架构活动引向商业价值创造。而商业价值，则会帮助企业决策者和赞助者实现企业愿景。同时，架构目标也会把架构活动引向用户价值创造，然后帮助到企业的用户。

最后，架构活动由于它本身定位的宏观性、规划的完整性和目标的长期性，还会产生其他的长期回报，比如对决策者、赞助者、执行者的决策效率、工作效率和个人成长的提升。那么这些角色，最终也都会因此而更加支持架构活动。

这张图也解释了建设决策环境时行王道的必要性。如果架构活动是自带光环的，也就是带着长期的回报，那么吸引到优秀的参与者自然就是情理之中的事情了。比如过去两年内，你组织过一个私有云和公有云混合云部署的双活架构改造，那么交易或者营销团队的研发人员就会非常愿意加入其中。

一是因为他们都能学到当下最新的前沿技术。二是因为方案上线后，他们可以在两个环境间做灰度发布，并在出问题时做秒切。这样一来，未来他们自己的运维和稳定性压力就小得多了。三是，虽然没有额外的激励，但目标会吸引那些年轻而又愿意接受挑战的人加入其中。与这些人在一起工作，可以说是既轻松又有成长。

那么接下来我们就讲讲在这个节点上你该如何行王道。

架构师在目标确认过程中的工作

确认核心角色

如前所述，我们要确认架构活动的三个核心角色，也就是决策者、赞助者和执行者。这些人必须满足我们刚才提到的对应的角色条件。比如决策者，不仅需要知晓企业的真正战略意图，而且必须亲自参与重大决策。而不是派个没有决策权的代表来象征性地支持一下，走个过场。

如果锁定的核心角色没有满足相应的角色条件，那你就需要找到真正的核心角色。举个例子。假设你负责由内审部门主导的审计合规的项目，但是内审部门没有任何资源调度权。这个时候，如果认为赞助者是内审主管，就说明你的判断是错误的，必须找到真正的赞助者，比如业务部门的负责人。只有他才能认定审计的优先级足够高，并愿意把当前的研发带宽挪用到审计中去。而内审部门，只是项目的需求方而已。

你或许以为CTO可能是一个完美的决策者和赞助者，因为技术团队或产品团队会向他汇报。其实不是的。

我作为CTO，并不认为自己是技术资源的掌控者，而只是一个监护人。要知道，这些技术资源都要从财务上反算到各个业务部门。从理论上来说，每个业务部门才是技术资源的真正拥有者，因为他们要支付相关费用。而我只是被授予信任，来帮助业务部门更好地管理技术团队。

所以我的工作是看到更具长远发展的技术机会，在多个团队中找到可以合力的地方。这样的话，企业才可以用更少的资源完成更多的工作，同时给未来打好更坚实的基础。

我虽然对技术人员有调配权，但我大多数时候并不会使用这个权力，而是期望通过正确的组织架构把调配降到最低。因此我一般拒绝担任业务线架构活动的赞助者。

我仅仅会担任大规模技术重构项目的赞助者。对于这种大规模的技术重构项目，我的判断条件是：项目必须在半年内拿回投资回报。也就是说，我投入200人日做重构，那么半年内节省的人力要在200人日以上。如果不满足这个条件，我就需要反复审视这个项目的合理性。

所以在整个节点上，我们要锁定核心角色，得到他们的真实承诺，并确认一个正确、合理、可达的架构目标。这个过程就像剧本杀里的非凶手角色一样，我们的目标是通过反复对话和分析，来帮助自己逐渐逼近真相。

在目标确认后，还需要对目标进行一个完整的描述。这个描述要符合SMART原则：具体（Specific）、可度量（Measurable）、可达（Achievable）、相关（Relevant）、有时效的（Time-bound）。

如下所示，是几个描述比较清晰的目标：

1. 三个月内，把90%的商家发布商品的时间，从平均每件30分钟降低到平均每件1分钟以内。
2. 三个月内，把导购下单的核心链路稳定性从三个九提升到四个九。
3. 12月31日以前，完成电商、云、跨境业务的合规审计中所有高优先级整改项目。

从这三条架构目标，就可以大致推断出这些目标背后的核心角色了。但多数时候，我们项目的目标是不满足SMART原则的。如果是这样，那么作为架构师，就要主动根据你的理解来撰写一个建议版，然后再请不同的角色反复确认。

这三个目标在多数企业中看起来都是正确的。但是在特殊的资源和竞争环境之下，这些目标也有可能不正确、不合理或者不可达。

比如第一个例子，假设这个类目的商品需要大量图片，本来商品上传工具中有一个图片辅助拍摄的功能。有了这个功能，那么在拍摄的过程中，商家的工作人员就可以根据提醒来对镜头角度做调整。但是为了达到每件1分钟的完成目标，拍摄过程就变成了照片批量上传的过程。而上传后又发现照片有10%的不合格率，需要返工。

结果就是，一个不正确的目标被满足了。商家的效率不但没有提升，反倒降低了，而平台也没有达到提升上架商品数的最终目标。

这个分析告诉我们，一个描述完整的目标，本身并不具备正确性、合理性和可达性。所以作为架构师，必须要理解企业当下的优先级，梳理核心角色，然后再确认目标是否具有正确性。

这个描述还不能看出架构师在目标确认过程的增值。事实上，一个正确的目标，不是自上而下的简单分配，而是一个发现的过程。下节课，我会给出一个详细的案例来帮助你认识到这一点。

小结

这节课我们介绍了目标确认的一些基本环节。我特别强调了目标确认需要从不同的视角来完成，其中最重要的三个视角分别是决策者、执行者和赞助者：要从决策者的视角来看目标是否正确，从执行者的视角来看目标是否合理，从赞助者的角度来看目标是否可达。

这三个角色不是随随便便指定的，而是需要具备相应的权利。换句话说，只有具备相应权利的人才可以是这些角色的充当者。此外，如果要确认目标是否正确，首先需要寻找到正确的角色。要知道，大公司里一般不会公开这些角色。

一旦锁定了角色，就可以通过高质量的沟通，来打磨出满足SMART原则的目标了。

思考题

1. 你之前遇到的架构目标是正确、合理和可达的吗？如果不是，那当时发现问题了吗？结果如何？
2. 我们经常会见到一个口号式的目标，而不是一个满足SMART原则的目标。能分享一下你的经历吗？
3. 在你经历的N个项目里，目标定义不正确、不合理或者不可达，各自所占的大概比例是多少？请给出N的值和大致的整体失败率。同时，为了让答案具有一定的可比性，我们限定一下项目的大小，要求项目期限必须超过一个月，参与人数至少等价于10名全职员工。