你好，我是郭东白。从这节课开始，我们就进入到架构活动的第六个环节——阶段性价值交付。
对于企业来说，这是成本花费最多的节点了，因为大量的研发人力资源开始投入到架构活动中去。
有的架构师认为，到了这个节点，自己似乎已经完成了主要任务。接下来，就主要靠项目经理深度介入到每个团队的交付过程中，来保障任务的完成了。有的架构师甚至认为从这个节点起，就要将自己的角色转换为项目经理。
从架构师的角度看，我们在这个节点所要起的最大作用并不是像项目经理一样去推动执行方，而是对用户价值点的提纯。
架构活动不仅庞大，任务也错综复杂。不过它也符合二八原则，即：最具商业价值的占比基本不会超过20%。而我们架构师的目标就是找到那些20%左右的高价值用户点，确保这部分的交付万无一失。
那么这节课，我们就来聊聊怎么保障这些高价值用户点的交付。
为什么要做阶段性的价值交付？
一般大型的架构活动都会有项目经理的参与，这个角色的工作就是将项目分割成几个更小、更容易跟踪和管理的交付模块，以降低团队之间的耦合，最大化项目成功的概率。
项目经理经常会采用分时间段交付的方法来降低交付的风险。也就是从时间角度出发，将一个大项目切割成几个交付阶段。从架构师的角度看，这种交付方式其实忽略了交付内容的价值差异。说得不好听一点，是不知道架构目标和规划细节的人才会采用的交付方式。
作为架构师，我们对整个架构活动的目标、商业价值、用户价值了然于胸，清晰地知道用户价值点。所以我们不能采用这种外行的交付方式。或者说， 哪怕决策者已经跟项目经理商量好了，决定采用分时间段的交付方式，那我们架构师的注意力也要放在高用户价值点的任务交付上。
这里我要借用敏捷开发中的一个概念——最小可行产品（Minimal Viable Product，MVP）。不过我要稍稍做一些更改，将这个概念称为最小价值单元（Minimal Value Proposition Unit），指的是从架构活动中分离出最小的、有增量价值的交付单元。
最小可行产品并不是一个独立的产品，只是一个交付单元。它具备如下三个性质：
- 独立性：从用户视角看，这个单元可以被单独识别。
- 结论的完整性：从阶段性交付的商业价值的角度看，我们从这个单元得出的结论是完整的。比如这么做的价值足够大吗？对于这个问题，我们得到的答案必须为“是”或“否”，而不能是“很难说”这种模棱两可或欲言又止的回答。
- 可度量性：这个单元为目标用户创造的价值可以被数字化、被度量。对于“最小价值单元是不是达到了预期目标”这个问题，我们得到的回答应该是精确的，而不能是定性的。
这个定义，跟我们刚才讲的项目交付里程碑的定义是有差异的。在大的项目中，最常见的交付阶段是由项目经理推动、按项目时间平均切割的。比如把为期三个月的项目，切割成三个为期一个月的阶段性交付目标。这样的交付方式虽然可以最小化集成风险，但交付的意义其实是完全拼凑出来的。
而每个团队内部，可能有不少由Jira等工具来推进的功能交付，但这些功能并不具备独立性。所以我们的阶段性价值交付，强调的是单元的独立性和结论的完整性，也就是交付了一个最小价值单元（MVPU）。
互联网时代，不能追求延迟满足。如果有多个最小价值单元，就要从预期价值最大的那个单元开始交付。
当然，这里肯定会有一些细节上的问题。如果说项目足够大，有专门的项目经理在负责交付，那么他的所有排期目标很可能是将团队聚拢起来，在一个大会议室里做项目攻坚，时间到了再把人释放出去。这个时候，你跟项目经理很可能就会起冲突。毕竟军队只有一个，他相信阵地战，你崇尚运动战。岂不是要乱套？
一个公司崇尚什么，往往不是你跟项目经理说了算的。我认为互联网时代就是要靠运动战，所以我建议我们架构师去追求最小交付单元。但是从组织、团队协调、资源配给等角度来说，阵地战可能是大公司最常见的模式。
在这种情况下，我们的价值就是为架构活动注入正确的交付视角，以架构师的身份去验收最小交付单元。从这个视角出发，有时候会给你意想不到的惊喜。你会发现，之前认为要等到项目结束之后才能拿到的结论，现在提前很多时间就能拿到。我们已经强调无数次了，时间是最宝贵的资源。
事实上，最小价值单元交付也是被很多团队主管和架构师频繁忽略的地方。不信的话，可以随便问问公司里某个大项目的架构师：“项目进行一多半了，我们拿到了什么完整的价值点吗？”他肯定是一脸懵逼：“不是还没做完吗？”
现在请你回顾一下法则四里讲的性能优化的例子。我跟团队最初就是把项目切割成了最小的价值交付单元，不过在这个基础之上，我们又逐渐找到了更多和更大的价值交付单元。而在这个过程中，项目本身也在逐渐演变，不仅技术更成熟，应用领域也更为广泛了。
架构师的核心关注点是什么？
我们之前就提到过，互联网时代，企业的很多尝试都是有很大风险的，多数架构活动都是以失败收场。而阶段性价值交付的目的，就是让决策者及早看架构活动的真实价值。此外，这么做的意义还在于，确保我们架构师把注意力放在交付的增值上，而不是交付功能或者交付代码上。
怎么做呢？在价值单元交付的过程中，要在保障结论有效性的前提下，尽早把一个完整的功能发布给目标用户，同时向他们及时收集反馈。我们的目标是把问题尽早提给市场，让市场给我们指点迷津，而不是凭空猜测。
收集反馈主要有两个目的。一是帮助团队将目标锁定在正确的目标上，避免偏离；二是验证预期增值是否满足期望。
依据这些反馈，我们可以对架构目标、架构设计方案、任务边界和交付节奏做出调整。而每一次反馈，我们也都能得到更好的数据，以更准确地估算项目的ROI，甚至找到新的增值空间。
这个过程的王道是忠于架构目标，尊重市场反馈，以最大化企业ROI的原则，选择正确的交付路径。
进入阶段性交付前的准备工作
明确了为什么要做阶段性的价值交付，以及架构师在这个过程中的核心关注点，接下来我们就可以进入准备工作了，主要有如下三个方面。
- 阶段性MVPU：从目标用户的视角看，最小可用的价值单元是什么？用户是如何感知到这个功能的价值的？
- 阶段性目标：用什么量化指标来度量这个功能的价值？如何通过A/B测试来验证这部分的价值？要知道，做拆分的主要目的就是尽早拿到一个结论性的量化评估。
- 最短路径：在不破坏项目结构的前提下，交付MVPU的强依赖是什么？这是我们架构师必须给出的答案。当然，强依赖可能包括一些非技术的依赖，比如招募参与前期实验的商家、营销费用和培训内部运营人员等。
在准备工作的过程中，你肯定还会发现一系列的挑战，主要有如下四个方面。
第一，项目的原子性。有些人非常反对对架构活动做拆分。一方面认为项目是一个整体，只有项目完全交付之后，项目的价值才能体现出来。另一方面，则是担心将价值较大的项目拆分后，剩下那些价值较小的项目就可能烂尾。
对于前者，这种担心在我个人看来并不成立。我很少见到一个完全不可拆分的项目。哪怕是合并部署这样的项目，也可以先合并部署最大、最相关的两个应用，看看真实效果和难度。
对于后者，这种考量的确成立。有些价值不够高的项目永远没人管，比较常见的就是网关。人人都需要，但是放在自己的团队中，怎么做都不划算。哪怕是专职的网关团队，也并不想支持，因为网关是最难量化到商业增值的。
对于这种情况，我建议专门起一个项目来做网关改造，而不是把网关项目附着在另外一个大的项目上。
第二，项目的最小化浪费。很多架构师认为拆分会浪费测试和联调资源。的确，拆分之后，联调和上线成本会增加不少。但这是一个基于总成本的决策问题。
如果说整个项目大概率会失败，那么拆分其实是明智的选择，至少可以避免更大的浪费，或者挽救一些有价值的子项目。我们做MVPU拆分，想解决的主要问题就是减少缺乏提前验证而导致的浪费，而不是减少提前验证带来的浪费。
第三，项目的大规模验证。有一种说法是“没有规模化部署之前，得出来的结论不靠谱。哪怕提前验证，得出的结论也是错误的”。这种说法在某些大数据和氛围烘托的场景下的确有一定的道理，比如双十一大促和春晚红包。
不过在工程领域，哪怕是双十一这种有数万人日投入的活动，其实也可以拆分成子项目，然后做提前验证。有些验证需要看规模效应，那么就可以放在小一点的大促中做验证，比如618大促。
越是大规模投入的场景，越是要对底层逻辑做验证。有很多非常失败的玩法，完全可以通过小规模验证来避免。而且多数时候，产品逻辑、营销效果、人群行为的验证，都可以拆分开，并不是每个子项目都要在全量数据之下才能验证的。
第四，项目的探索空间。项目本身是高风险的，太早验证，得到的负面结论会让赞助者丧失信心，项目很容易被取消。
这个担心的确有根据，尤其是在大公司里。但是我觉得这是架构师与赞助者期望设定的问题。架构师的命运是与公司深度绑定的，而不是绑定在项目上。我们跟赞助者都是在一个高风险的赛道上寻求长期回报，所以都应该做好失败的准备。做互联网很少有江郎才尽的时候，重要的是尽早发现自己的弱点，并快速迭代招数。
那么下节课，我们就来讲讲在这个节点上架构师该如何行王道，以最大化ROI的方式拆分架构活动。
小结
这节课我们提出了阶段性价值交付的概念，并强调了架构师要持续关注和创造商业价值。如果留心的话，会发现这是我们在法则四已经拆解过的一个话题，所以这节课其实是对这个法则的具体应用。
在阶段性价值交付这个节点上，还隐藏着一个职业成功者所必需的思考习惯：时刻做取舍。在架构活动中，最具用户价值和最具商业价值的部分，就是我们这节课提到的最小价值交付单元。这才是你这个架构师的核心注意力所在。其他的事情虽然重要，但算不上核心。
这也是为什么有些人能把事做成，持续“拿结果”。因为他们找到了最需要投入自己全部精力的MVPU。最终，项目可能并没有完全成功，但他们保障了最具商业价值或最具用户价值的单元能够被成功交付。
我观察那些职业非常成功的人，往往都是在更值得关注的事情上，做出了独到且高回报的决策。反过来，许多职业上不太成功的人，一个显而易见的共性就是相信“勤能补拙”，靠大量不分重点的高强度投入，试图补救决策上的短板。
我的观察是：对于一个架构师来说，正确决策比持续努力更重要。
思考题
这次的思考题只有一个。希望你可以花点时间，认真思考一下这个问题。如果有必要的话，你也可以思考一两天，然后再来留言区写下你的回答。我认为这很有可能帮助你复盘自己的职业历程。
请回顾你的职业生涯，你有没有因为找错重点而错失了什么重大机会？如果你作出什么样的改变，可以让你拿到这个机会呢？
标签：架构,项目,31,郭东白,交付,架构师,价值,单元 From： https://www.cnblogs.com/gongxianjin/p/16989186.html