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