郭东白的架构课_35_25节点四架构规划之需求确认
你好，我是郭东柏。
上节课我们讲了架构规划这个环节的第一部分，也就是统一语义。
那么这节课我们就来讲第二个部分需求确认，需求确认跟统一语义的过程是密不可分的。
需求确认是在统一语义赋能下进行的，所以他们并不是先后顺序的关系。
通过上节课的学习，我们知道了统一语义的主要场景和目的，就是对目标进行无损的分解和传递，以及理解表达、传递参与者的诉求。
那么需求确认就是在统一语义的情况下，把这种诉求继续无损的分解成研发人员执行任务的过程。
所以在学习这门课的过程中，你仍然需要深度理解，并且随时应用通么前两节课讲的统一语义的内容。
这节课呢我们先来讲讲需求确认之前的一些准备工作。
那么先要梳理一些内容，首先呢要从产品定位的角度来梳理。
一般来说呢你应该从产品经理拿到三部分的信息。
第一呢就是客户的信息，也就是你为你整个架构活动买单的人。
一般来说公司内部站在客户后面受益的人就是你的赞助者。
但是也有赞助者是站在用户角色之后的。
第二呢就是用户，他们呢是最终产出的软件产品的使用者，也就是你创造用户价值的受益者。
需要说明的是，用户呢指的是你整个架构活动设计需要考虑的所有架构活部用户角色。
这里呢包括常规的用户角色，比如说人上，比如说我们上节课提到的商家发行上或平台运营，也包括代理角色。
比如说某个sars服务所扮演的可能是银行金融授信的自动化审批的角色。
第三呢是核心场景。
比如说客户或者是用户这个架构活动的核心诉求是什么？他们因为什么价值而买单？这些需求在哪几个场景中出现。
其次呢要从执行者的定位来梳理。
一般来说呢，你需要从技术团队的leader那里拿到三个方面的信息。
第一是执行团队。
也就是说整个架构活动中相关的执行团队，你需要确认他们会为哪些用户角色服务，可以为这些用户创造什么价值。
第二呢是执行域划分，也就是每个执行团队所负责的领域。
你特别需要关注的是，执行领域之间重叠的部分，以及没有被任何执行域覆盖到的部分。
第三呢是需求承接方。
除了架构活动中已知的执行者之外，整个公司中谁应该承接某个需求，谁有带宽呢？他们愿意吗？有能力吗？最后呢是取舍规则，你应该从决策者和赞助等能得到确认。
第一呢是需求优先级的决策信条，比如说不同需求方的优先级，按什么规则来排序。
第二呢是必保需求，哪些需求是必须完成的？这些必保需求不是在单个角色的视角上，而是由参与方和决策者达成共识的。
第三呢是隐含的技术需求。
多数人认为架构活动肯定会给公司带来新的外部适应性。
因为不同于日常需求，这是一个自顶向下有全局规划的一个大型研发活动。
而具体这个外部适应性在哪里？创造怎么来度量，谁来承接？就是你作为一个架构是必须完成的工作，最终这个隐含的需求也要被显性化的表达出来。
要和其他需求一样，有执行者也要和其他需求一样接受取舍。
梳理完之后呢，你就要进行问题域的划分了。
因为需求确认过程呢，也是从问题域到执行域的映射过程。
一个大的架构活动可能会有几千条需求，有好几百人参与研发。
如果你把需求一条一条都映射到执行域中，那将是一个非常繁琐和低效的过程。
那么应该怎么做呢？在最开始的时候，架构师就要把问题域定义出来。
大多数的需求呢可以由产品经理或者PMO整理到不同的问题域中。
那么你需要做呢，就是把问题域映射到执行域上。
这样的话，你并不是把上千条需求分配给几百个研发，而是把几十个问题域映射到几十个执行域中。
在这之后就是逐层分解了。
只有在边界模糊的场景下才需要你这个架构师的介入。
其中比较核心的呢是问题域的定义。
我在文稿里放了一张图，展示了一种问题域的划分办法。
图里呢不同颜色代表不同问题域的划分，其中绿色代表数字和实物商品整合之后的商品域。
古铜色呢代表实物商家域，蓝色代表发行商域，紫色代表货品和履约域，而黑色部分呢属于数字商品域，多数时候呢问题域和执行域都是同构的。
也就是说呢，如果你把这张图复制一份，就可以在每个问题域上标注出相应执行团队的名字。
当然也有力度不同的情况。
比如说在一个合并后的公司里，你会看到一对多的情况。
在一个收缩的公司里呢，你会看到多对一的情况。
在一个架构和管理混乱的公司里，你会看到多对多的情况，或者是多对零的情况，或者是零对多的情况。
我们也用上节课的例子来解释呢。
假设呢你整合了两个不同的部门，那么整合之后呢，可能会发现某些问题域有多个执行域，也就是踩脚的情况。
当然你也可能会发现，某些问题域没有任何已知的执行域，也就是新建或者是烂尾的情况。
这些呢都是架构活动中风险多发的情况。
你呢必须及早发现，及早处置。
这里我也需要强调一下，问题域和执行域的划分，不是靠你这个架构师的想象，而必须是在多方参与下对事实形成的一个准确描述。
事实上呢，你会发现问题域和执行域的划分并没有我们描述的那么简单。
从形成统一的问题域模型，再到问题域划分，最后到执行域的划分，一次迭代肯定没办法完成。
是因为呢大家语境本来就不一样，不可能给你足够自洽的答案。
而且呢一个实题往往不会正好映射到一个执行域，而是因为各种历史原因形成错综复杂的映射关系。
那么接下来呢我就讲讲从项目目标到需求映射的过程，也就是评估需求。
这个环节呢你是要从架构活动的整体目标出发，确认需求存在的必要性。
很多时候呢，尤其是大的项目需求方呢，经常会夹带私活，实际上他们并没有什么恶意。
但是这些附加的需求不仅会消耗研发资源，而且会增加项目的复杂度和规划的难度。
而且最快的情况下呢，就是附加需求引入的需求，而导致整个项目的失败。
你作为架构师呢，需要准确区分最小必要的需求和无关紧要的需求。
只有那些跟项目目标形成因果关系的强依赖需求，才是属于架构活动的需求。
这个梳理过程之所以放在问题域和执行域划分之后，是因为呢需求属于问题域的范畴，而需求的执行呢属于执行域的范畴。
如果没有领域划分，你自行砍掉复加的需求，那你这个架构师很快就混不下去了。
要知道砍需求是个非常得罪人的事情。
那么你做这件事必须要有个同门，也就是跟需求对应的执行域的负责人。
因为在砍掉不必要需求的这件事情上，你们两个人的利益是一致的。
你呢是为了整个架构活动的成功，他呢是为了控制自己领域的立场，你可以站出来表达比较客观的立场。
而他呢可以帮助你证实这个立场的合理性。
这个过程呢跟确认目标的过程类似，你的关注点要放在五个方面。
第一呢是需求的必要性，这个需求绝对有必要吗？跟整体目标是因果关系吗？不论这个需求的价值有多大，只要它不是架构活动的必要条件，那你就应该分开考虑。
最好完全隔离在架构活动之外，架构活动最既好大喜功。
第二呢是需求的正确性，需求跟架构目标匹配吧。
第得到赞助者就期望的商业价值。
那你你这个需求的目标正确数量级应该是多少？如果一个需求的预期目标比赞助者所需要的小一个数量级，那么这个目标就是不正确的。
事实上呢需求不正确的情况在架构活动中频繁发生。
表面上看呢可能是执行队友不给力，但更真实的原因呢是你这个架构师不给力，没有及早的发现规划的软肋。
第三呢是需求合理性。
在当前交付的时间约束下，需求交付的时间和质量要求合理吗？会出现研发团队的动作和设计完全变现的情况吗？第四呢是需求本身的可达当前的时间要求和资源投入，能产出质量上可以接受的实施方案吗？实施方案高于质量底线吗？如果某个需求需要多个团队协同，那我们留出足够的时间让团队处理集中出现的问题吗？第五呢是需求承接方，这个需求有且仅有一个团队承接吗？是应该他们承接吗？他们有意愿吗？他们能力够吗？有研发带宽吗？一个架构活动中最终要承接的需求就是这五个问题，答案上必须是非否的。
而这个需求梳理的过程，其实也是执行风险的梳理过程。
完成这个梳理过程之后，你应该对需求跟架构目标之间的因果联系有了信心。
那么接下来呢我们需要一个完整的映射关系。
我在文稿里放了一张图，听完音频呢，你可以到文稿里看一下，我也讲也讲解一下这张图。
你需要呢跟每个执行团队逐个确认他们是不是某个需求的承接方。
这是你架构师在架构规划前必须确认的大图。
因为你需要有足够的信心来保证从目标到需求，从需求到核心场景，从核心场景到问题域，从问题域到执行域的映射。
可以被无损的表达，并且没有冗余。
这个映射呢是对事实的反应。
你会发现呢有些需求呢有好几个承接方，有些需求中却没有承接方。
有些高优先级需求，有对应的执行者，没有任何的研发带宽。
而有些低优先级的需求呢对应的执行者呢却有充足的带宽。
这些冲突呢都是我们接下来要解决的问题。
对于那些高优先级需求，也就是从需求到承接都满足一一对应的映射的话，那这时候呢它领域内的规划设计其实就可以启动了。
不过呢在统一语义的过程，你会发现不同角色在不同语境中还隐藏了很多冲突。
日常工作的时候呢，这些冲突呢可能并不明显。
因为大家都在自己的隔离语境中，跟几个团队进行了小范围的合作。
直到我们把不同语境中的概念拿到一个统一语境中来争夺有限资源的时候，这些冲突才会达成忽视。
其实越早暴露，这些冲突对架构活动越有利。
毕竟这些冲突呢是客观存在的，避免不了。
我梳理呢架构活动中最常见的七种冲突。
第一呢是优先级冲突，这是呢互联网最普遍的冲突。
在资源有限的情况下，每个需求方都从自己的视角出发，希望得到最大的冲持，导致各方在需求优先级上没法达成一致。
比如说营销团队由行业运营和大促运营两个团队共享。
而每个运营团队呢都认为自己的需求优先级更高。
这呢是有多个依赖方共享一个开发团队导致的。
再比如呢弱势角色的高优先级需求往往很容易被忽视。
比如说合规部门，另外没有专职的产品经理。
但由于监管形式的变化，合规类的需求优先级呢其实也很高。
但是掌握研发资源的业务团队呢，却不太愿意让研发人员开发这类需求。
第二呢是定位的冲突。
不同角色之间天然就是互相制约的这并不是特例，而是企业中普遍存在的现象。
一个企业内部必须有某种形式监督和制约机制，来确保整个企业的决策有完整的并且相对平衡的视角，而不仅仅是单一视角上的最优。
需要说明的是，这种冲突独立于架构活动并且长期存在。
一个例子来说啊，商家运营的定位呢是商家增长。
那么这个角色呢就要吸引尽可能多的商家到平台上来。
而网规团队的定位呢是减少平台风险，那么这个角色呢就要尽可能打击作弊和劣质商家。
如果我们用算法语言来表述商家运营的定位呢，就是要最大化召回网规。
团队的定位呢是最大化精度，这的是一对矛盾。
第三呢是团队和个人的冲突。
有的公司呢喜欢赛马，针对同一个垂直领域，会让几个部门用不同的商业模式在市场上竞争，或者针对同一个场景，用多个技术和算法来实现这些定位。
大致重叠的团队之间呢，往往会因为内部竞争形成不小的摩擦，久而久之团队的关系就变得不和睦。
也有的人呢日常做事缺乏底线，得罪了同事那么对立。
双方可能会因为同时参加了你的架构活动，而把个人冲突引入进来。
第四呢是边界冲突，多个需求方或者执行团队负责的领域，边界不够清晰，不确定到底谁说了算。
这种情况呢？在大公司里，尤其常见语境的差异性，也是这种冲突的长期业务阴影。
边界冲突呢主要源于三个方面。
首先呢不同的垂直执行域呢定位上本来就有重叠的。
比如说商家和商品团队之间，交易团队和资金团队流量和导购团队之间。
其次呢就是水平分层上的模糊性。
比如说前端团队和后端团队之间的分层，业务团队和财务团队之间分层。
最后呢是因为技术进步带来的执行域边界的迁移，比如说前端转全站工程师，导致前端的职能拓展到后端去，业务中台化，导致业务性的研发任务迁移到了一个共享的中台里面去。
前端低代码化导致之前由前端执行的任务变成了由产品或者共后端工程师来完成。
第五呢问题遇到执行域之间的映射关系，冲突，需求方到执行域之间的领域映射关系，没有形成共识，导致团队之间争夺地盘。
比如说上面那张图的商品在整合之后的数字商品的商品整合成一个商品执行域，由多个业务团队映射到一个执行域的情况。
同样呢，如果产品团队已经完成了整合，但是技术团队的整合没完成，这么订单域，就可能形成一对多的映射情况。
这种一对零一对多多对零多对一多对多的状态都会造成设计和执行的混乱，必须在这个节点上解决掉。
第六呢是生存空间的冲突。
这次呢映射冲突中一对多和多对多的情形在大公司里非常常见，所以值得单列。
比如说呢一个部门里有多个网关的团队，平时大家都相安无事，一旦公司要把几个网关合并成一，那么生存空间的冲突就不可避免。
第七呢是决策权的冲突，在规划和执行决策上，有的决策非常强势。
本来应该属于架构师的决策权，却被某个领域的领导抢夺了，从而形及这个冲突的热点。
比如说某个大厂长期存在着这样的现象，对某个领域有控制权的共享技术团队。
第如说他们管辖的领域需求必须由他们承建设计，也必须由他们决定。
谁也不能替代或者更改。
这呢就导致任何有这个团队参与的架构活动，一旦涉及这个团队的需求设计就全部变形了。
统一语义的关键作用呢，就是让你及早看到这些冲突并且及时解决，否则架构活动就会面临很大的不确定性。
最后呢我们要从问题遇到执行力的领域边界划分了。
从刚才的分析就可以看到，架构活动中你可能要面临四个棘础的问题。
第一呢是团队之间争夺有限资源，第二多个团队争夺生存空间。
第三，无法调和的个人和团队之间的矛盾。
第三呢第四，短期内不合理的组织和决策结构。
我的建议是这样的啊，对于有限资源的争夺，如果没办法缩减交付项，那么必须在这个时间和赞助方决策方参与方讲明白，这么调整质量预期，要么调整上线时间，对于生存空间的争夺，务必请决策者迅速裁决，这是根本没办法调和的冲突。
对于个人和团队之间的矛盾，我认为只有躲开才是上策。
如果活动还没开始就没办法消除。
可以预见，随着项目压力的增加，矛盾必然放大。
我建议呢还是请决策者进行处理。
如果实在没办法处理，那也一定要请决策者提前指定一名裁决人。
一旦出了问题呢，你就能迅速找到裁决人进行拍板。
对于组织和决决策结构的问题呢，可以通过我们前面讲的搭建架构环境，建立决策信条等方法来解决。
最好还是请相关参与者和决策者一起来制定和确认一些决策心态。
总的来说呢，执行欲划分呢是一个压力非常大的环节。
你这个架构师呢也要必须保持开放心态，这个过程中呢你需要充分表达，大胆建议。
不过你也要注意，你并没有决策权，你提供的仅仅是技术视角，而不是整个企业的视角。
换句话说呢，你与决策者拿到的信息是不对称的。
多数时候呢你看不懂，只是你自己视角的问题，别人是上帝来拯救世界的，别人的视角是片面的，你的视角也是片面的。
人才培养团队稳定性、成本控制、商业竞争、监管，甚至是国家之间的关系。
你可以是边界划分划分的理由。
你可以不认同决策者的判断，但是千万不要就上来就阴谋划别人。
这个世界其实没那么多阴谋。
多数时候呢大家都是见招采招。
当然呢如果可能的话呢，你应该试图理解每个参与者视角，并且对最终的执行域划分给出一个合理的解释，否则让参与者能够主动接受领域划分，远远要好于自上而下的强制边界划分。
为了帮助你理解呢，我在文稿里放了一张表，我也在解释一下。
这张表当远要会动自解者所所的问题域到执行域的映射都是无歧义的，也就是表中绿色的部分。
否则则你带带巨大的风险进进入一个环节。
而且你还没有任何的决策权和调解小段。
可以说呢每个执行域划划的过程程乎决决定了整个架构活动的成败进入到下个更细的任务。
边界划分之前，必须解决图表中那些遗留问题，避免给自己埋下一颗定时炸弹。
如果你对所有的问题域和执行域都梳理完了，那么这个需求过确认的过程也初步完成了。
好了，今天的内容就是这些。
我简单总结一下啊，统一语义是让所有的用户作者都能完整的表达自己的需求，并且跟目标相一致的也是自洽的，互相兼容的。
这个统一语义的过程呢也会暴露公司内部很多关系和职能之间已经客观存在的冲突，不过这是好事儿。
如果你这时候不暴露那等架构活动进行一半的时候，再暴露项目就已经无可救药了。
这呢是统一语义的防盗，也就是把真相呈现给大家。
问题的真相再可怕都有解决的办法。
我们这两节课呢花了很长时间去分析语义语境，还有问题与定义，执行与定义，以及映射关系的分歧和问题。
我们的目标呢还是在那个真正值得我们每个参与者去解决的问题上达成共识。
我们今天呢更近几了一步，在问题的分解上也达成了共识。
你发发现没有？这两节课呢，我们没有提到任何架构方案的选择，没有微微服务，没有分层架构，没有统一数据模型。
事实上呢我在这个过程中呢，一直坚持我们在模块一中提到一个法则，那就是尊重人性，用用户思维先看清楚问题。
在进入解决方案的设计之前，你就是要所有的参与方都做下来，放弃一切技术之内。
现在我们要解决什么问题上，以及在问题的分解上达成共识，这才是真正的问题与建模。
最后呢是三道思考题。
第一题呢我们在这节课强调了提前要暴露的问题。
也有人认为，暴露组织中本来就存在的问题是没事找事，一个大型技术活动已经有很多挑战了，没必要暴露更多的问题，人为制造一些难度。
那大型软件架构中，你经历过这两种完全不同的做法呢，结果呢你的体会又是什么呢？第二问题域和执行域不需要同构，因为执行域呢可能是多个问题域的抽象。
那么你结果比较好的抽象呢是什么？第三题呢，我们讲执行域划分的时候，提到了四种棘手的情形。
你经历过吗？有没有比较巧妙的解决方法？如果这节课呢对你有帮助，欢迎你把课程转发给你的同事和朋友，顺便打个小广告。
我刚看了个人抖音号，我会定期发表一些比较新，但不一定那么成熟的观点，欢迎你在抖音上搜索郭东白并关注，也欢迎你的批评指正，我们下节课再见。