郭东白的架构课_37_27节点四架构规划之划分任务边界
你好，我是郭东白。
上节课，我们讲了任务边界划分的几个信条。
那么这节课我们就来看看怎么做任务边界的划分。
首先呢是任务梳理和力度，控制我们上节课讲到的实体和用力的过程，其实是建模中最常用的用力梳理的过程。
一般来说呢，产品部门的同事呢会有相对完整的梳理。
那么你作为架构师，在任务梳理的过程中能带来什么价值的？有的架构师呢很少关心从用力到任务的分解过程，认为这是产品和相关技术人员的事情。
事实上，这是你这个架构师为企业注入思考的核心切入点。
也就是从技术角度来理解这些用例对现在和对未来架构设界的影响，然后再在任务定义上体现出你的思考。
比如说你在梳理实物商品的影响，可能会问起平台上有哪些库存类型。
这些类型的库存跟商家仓库的库存是怎么关联的。
这样你才能确认系统和商家的集成边界在哪里。
然后再决定是复用现有的能力，还是重新开发新的能力。
如果复用，那么你的任务分配上其实就有一个约束条件，就是这个任务必须分配给当前实现库存功能的团队。
再举个任务分割的例子，如果商品分控在你们行业是一个非常重要的操作，迟早需要投入。
那么现在就需要把这个任务独立出来，哪怕你最初的分控需求的人是再少，也不能打包到商品相关的需求里去。
因为风控和商品管理的技术，底层和研发能力需求是完全不同的。
只有把任务分开，未来才能通过康威定律的效率产生领域分支和技术。
专业性技术架构分支的判断条件。
还有很多你应该关心的，除了刚才提到的需求相似度、行业特性、技术底层依赖和人才能力外，还要关心用户体验的差异和规模差异以及行业竞争的激烈程度。
这些维度都会影响到当下和未来的技术走向以及需求变化的趋势。
同时这些维度也决定了技术分支是不是有必要。
你可能会问，为什么要做分支判断呢？我们不看细节的时候，几乎所有的实体都差不多。
而一旦分解到最小需求单元的时候，两个需求就不一样了。
就好像你抽象人类的生活需求，也就是衣食住行四个字，似乎全世界人都一样。
但也从中国人美国人、印尼人和埃及人里随便挑出两个人，哪怕他们这四个方向没有类似的地方，哪怕只是从中国人里随机挑出两个，从西处来看，差异也肯定不小。
那么这时候一个好问题就来了，既然宏观层面都类似微观层面都不同，那么正确的分解力度是什么呢？我认为这件事情呢不由你说了算，具体的用户需求和任务的分解力度是由市场说了算的。
我们之前在讲生存法则的时候就提到过，互联网时代赢家通吃。
你做技术是为了服务用户。
那么你给用户提供的服务的精细程度、服务质量、迭代速度，都必须保证你能赢得竞争才行。
这也意味着，架构式的取舍不是一个艺术，而是一个基于商业和技术环境的理性的思考。
决策，完成了任务梳理和力度控制，接下来就要做边界划分的任务分配了。
大多数时候呢，你不是从零开始做一个新系统。
所以产品用例往往已经有现成的从需求到执行方的映射关系。
但这也不妨碍你从用户视角出发，从全局思考最优的从需求到任务，再到执行者的映射。
不论是已经有的映射关系，还是没有确定承接方的新需求都是这样。
那么怎么做分配调整呢？我在这节课的末尾给出了两个做任务分配和调整的讨论。
其中两个比较重要的结论如下，一个是在独立性假设之下，任务分配是一个局部优化的过程，所以不需要在全局上做优化。
另一个是在独立性假设之下，真正导致你失败的是你的软肋，也就是架构活动中成功概率最低的强依赖。
这是你作为架构师最重要的关注点，而不是大家都注意到光环点。
再来。
举个例子，在大促里面呢，交易营销链路呢就是一个光环点。
但是呢往往大促出问题的地方，却不是交易营销链路，而是类似获取物流费用这样一个下单页面的强依赖你。
作为一个架构师，如果你能用我在附件里描述的理性思考的方法来正确摆放你的注意力，那就显示出你的真正的功夫呢。
那是什么东西会影响单个任务的成功率呢？目标设定、设计方案、用人、研发、测试、资源、运维环境，这些都是影响架构活动的因素，在一个更小任务尺度下也同样生效。
而上节课开头提到的四种任务分配的基础情形，也会影响任务的成功概率，准确计算这个概率很难。
不过我们分享给你一个小技巧，如果有多个理性的人，同时对一个随机事件做期望值预估的话，那么参与预估的人越多，他们给出的中位值就越接近实际值。
这里呢仅仅要求参与者是理性决策，而不要求必须是相关项目的负责人这样的角色。
这个呢有点像我们平时做的scwarm,估计人事你和参与者花费时间呢是以分钟来计算的，是顺便完成的。
这个并不需要你花一个小时开会讨论来估算某每个任务的负功率。
总体来说呢，我不太主张在任务梳理、力度控制和任务分配的环节里，有太多的脑暴和发散。
因为此时此刻我们已经进入到执行环节了，那么就要尽量减少分散注意力的动作，尽快做出决策。
一旦任务边境确认，那你就必须迅速锁定所有必报相关的资源。
除了研发人员之外，还包括业务、产品、研发、流量、入口、发布窗口，甚至还包括营销资金池。
不过最难锁定的往往还是研发人员。
互联网企业中呢，每个研发人员都是有多个必保项目在身。
因为你假三夫是常态，不是说一个主管说锁定就锁定了。
在项目交付之前，资源其实都没有锁定。
我的建议是呢，一旦项目可行性确认了，请立即把大家聚在一起做技术规划。
当然这个过程中呢，我也会做一些动员工作，告诉大家这个项目里的机会，也就是大家常讲的画大饼。
你可能觉得这么做没用，因为人人都在画大饼。
而我想强调的是在人人都在画大饼的情况下，你连个小饼都画不出来，那你就别想混了，不信的话，你去翻一翻。
大家在第一节课评论区里写下的思考的答案，让你最兴奋的目标是什么？几乎每个回答者都有自己的选择，但没有人说老板让我做啥，我都兴奋，那是没上过末的。
小驴犊子不是优优秀的研发人员。
如果你的架构活动中呢有隐含的技术需求，比如说在做项目的同时，还需要完成架构代码重构。
那呢你就需要有一个技术PMO的角色来帮你协调和验收了。
我并不建议你这个架构师来兼任这个角色，除非你的项目是十几个人的小项目，否则你的关注度是不能保障重构的质量和交付的时效的。
另外在这个环节呢，你可能还会遇到这么一个棘础的问题。
某个需求承接者有很强的意愿，不过你判断他可能没有能力来承接。
在这种状态下呢，我建议你先冷静一下，你首先要质疑自己的判断。
因为你很可能在项目的压力和交付风险的担心之下做出判断。
你可能会忽略了一个人成长的潜力。
我自己的个人经验是项目的成功概率，跟参与者的意愿度和投入度的关系更大一些。
跟这个人能力的关系呢其实是略小一点的。
如果你对所有的必保需求、任务承接和资源锁定都完成了，那么你的边界划分就初步完成了。
不过你还要从实施细节上来确认架构规划，这个呢我们会下节课讲。
我需要注意的是呢，在实际执行的过程中，你往往会漏算，也会碰到突发事件。
比如说需求方会更更改他们的需求。
在这个过程中呢，你还需要不断的迭代延误、分拣，尽量把用力从粗到细做成多层分拣。
一来你会及早的发掘细节和不自洽的部分。
二来呢你会很快跟自己锁定的核心研发人员建立信任，让他们尽早参与到需求确认中来，从而减少风险的同时呢，增加整个项目的成功概率。
好，这节课的内容呢就是这么多。
我简单总结一下，我们这两节课呢讲了边界划分的过程。
在任务边界划分之前，你必须跟决策者参与方在信条上达成一致。
否则在这个充满冲突的环境中，如果没有任何信条的指引，可以说你堕入了万劫不复的深渊。
所以这些信条呢就是你这个架构师的护身铠甲。
想一想啊，无论是资源冲突还是个人冲突，如果你没有任何铠甲护体，单靠肉身给天神欠甲，你是想找死呢？你是想找死。
这个过程的王道呢，其实是你以最大化项目成功概率为基础来做出决策，引导大家达结共识。
但是在极端的情况下，你也可以邀请决策者来强压，这是霸道的行为呢。
作为架构师呢，你更需要做的呢是用一个相对客观的思考方式。
比如说我们在这个课的附件里面所建议的，你可以对强依赖和备份任务进行区分，并且对成功概率进行估算。
这么做呢，你会把参与者引导到一个基于规则的决策环境中来。
在这个过程中呢，你不但需要保持开放和包容的心态，同时也要引导参与者保持开放和包容的心态，这样呢才能让大家都看到全局视角，最终做出全局最优决策。
我相信所有的人呢都会为一个更高的成功概率而兴奋的。
而你要做的呢就是找到实现这个目标的真实路径，并且和大家一起看清这个路径。
最后呢是我们的思考题环节，一共呢是三个作业，你可以任选一个第一题，在你参与的项目中有没有边界划分不合理的呢？在划分边界刚开始你是怎么判断边界是不合理的呢？你是怎么做出这个判断呢？你跟其他参与者表达过自己的思考吗？最终结果是什么？第二题呢，我在附件内容中讲出了最弱链接这个概念。
第三题呢，架构活动成功率的天花板是成功概率最低的。
那个强依赖，也就是你最弱的链接。
其实呢这是你作为架构师的思考关注点，你可以回忆一下你经历的最弱链接是什么。
第三题呢，我在这节课呢还强调了非常重要的的一个理念，就是架构不是艺术，是一个基于商业和技术环境理性的思考决策。
你有没有被对架构艺术家门片的经历呢？或者反过来说，你有没有参与过一个能带来竞争优势的技术架构呢？如果说这节课对你有帮助呢，我欢迎你把课程转发给你的同事或者朋友，顺便打个广告。
我开了个人抖音号，会定期发表一些比较新，但是不一定那么成熟的观点。
欢迎在抖音上搜索郭咚白并关注，也欢迎你的批评指正，我们下节课再见。