作者：朱春茂（知明）
上周我写的一篇文章《谈谈技能才能》引起了咱们的关注，好多读者的评论“以写代想、以想促真、以讲验真”，咱们的感受很深刻，根据前次的文章，这篇文章我其实更想跟咱们聊聊一些常用的考虑办法，考虑问题的办法对了，往往能够帮助咱们少走弯路。
常用考虑办法
技能常用考虑办法
技能考虑实质仍是结构化考虑，所以常见的结构化考虑办法也是适用的。这也是咱们会看到许多技能架构师都会用一些办法论去分析问题的原因。但这儿我不是重新去论说这些常见的技巧，而是共享从技能实战中得到的一些考虑办法，为此我分为了技能架构规划的办法和技能 Leader 的考虑办法两类。
技能架构考虑办法
0—>1
这个考虑办法的意义是：
当咱们在一堆苍茫和紊乱中不知道怎样下口时，应该先贴近问题本身，复原客观事实，并快速构成 1 个能够拉起认知并快速讨论迭代优化的版本。咱们围绕着这样的一个初始版本去叠加和丰厚其他维度的内容，直到计划的一致。
我举一个实践的 CASE，咱们在谈某渠道才能晋级的计划时分会经常喜爱用 PPT 画一些模块图，试图经过一些笼统的词汇来厘定清楚鸿沟，核心概念。咱们以为是在讲实质讲准则但实践一切人听了都是云里雾里，不知所云。由于经过概念去推导概念是无法真实答复问题的。
而比较好的应对办法我总结为以下三个步骤：
- 用户视角的客观世界复原
用户故事的串联，根据交互流程和真实的数据来描绘这件事在客观世界中用户视角看来是怎样产生的。这便是咱们找准一个咱们都能够一致的视角，让一切人快速把客观事实搞清楚画出来这个 1，而这个 1 便是后续讨论的靶子 。这个 1 的表现办法我以为往往都是很简略的，要么是交互时序图，要么是 Excel 表格，而不是杂乱的模块概念图。
- 客观信息的结构化整合与提炼
仅仅建立起来 1 这个初始版本，还远远不够。由于第一个步骤仅仅将模糊、紊乱的东西经过一种办法信息化表达出来，这还远远达不到运用的程度。所以还需要将上述信息进行结构化的整合与提炼，由于信息只要经过结构化才能够变成有意义的常识，才能够与之前的经历构成互动，也才能够进行初版的规划加工。比方对数据流的处理，就会发现有哪些是能够合并的同类项，有哪些平衡校验逻辑等。
- 参加多元视角的查验与笼统
经过第二步的处理把 1 这个版本变得愈加丰满，可是要构成完好的可施行计划还远远不够。咱们还需要参加更多维度的校验和笼统，比方进一步笼统以看透其实质，比方参加重要异常，ROI，合理性等扩展性等多方的视角去做校验。
所以咱们今后在遇到许多计划谈不清楚的时分，不要去听他人讲什么准则，概念，价值等等虚头巴脑的东西。把咱们拉回来，回到最简略的最朴素的东西来对焦，那便是 一张交互序列图 或许 一张表格。越快速从一堆苍茫中快速提炼出这个 1 ，就越简略快速拿到成果。
1—>0
这个考虑办法的意义是：
当咱们在做一个计划时面临许多要素无法捉住要害点时，咱们应该考虑删除法（把这个 1 拿掉不要行不行）去寻找决定性要素，以保证咱们是真实的抓到了要害点。
我举一个实践的 CASE，每年都会做技能规划，信任这是许多架构师/Leader 很苦楚的事。苦楚的本源便是在脑子里面有许多需求，有许多的待优化点，也有许多的想法在萦绕，看到每个点觉得值得在新一年做攻坚。终究多半构成的便是一个表格，把本年要做的事罗列下，最多还排个优先级，好一点的换个办法变成 xmind 或许 PPT，再稍微好一点的或许会搭配上事务的方针和战略打法。但透过这些外表现象，其实质便是一个表格，没有捉住重点的表格。信任咱们应该都看得蛮多的了。
怎样应对这类问题我总结为一下几个技巧：
- 因果判断法
许多时分咱们都在谈，要捉住工作的实质，要具有化繁为简的才能，其实便是在谈经过外表的成果去探求真实的原因。所以在看哪些是决定性要素时，咱们不妨用因果法去查验：这个要素到底是深层次原因仍是诱导的成果。
- 树干树枝法
有时分各个要素之前并不是单纯的因果联系，而是依靠联系，就像是树枝依靠在树干上一样。而咱们要找到决定性要素，能够测验这个办法去查验：如果把这个要素去掉会不会影响大局，是不是导致结论不成立。经过这样多轮的分析，是能够绘制出来树干的与树枝的联系，这个树干便是要找的决定性要素。
- 支点撬动法
有时分各个要素之间或许没有直接或许直接联系，或许这个关联联系太弱很难经过以上两个手段去确定要害点。能够测验支点撬动的办法，即寻找能够激起这一堆要素的要害要素。我之前给团队举一个比如，国家抓经济必定不或许是米面粮油各种琐碎地抓，必定是找到几个要害点起到支点撬动的作用，如房地产行业。捉住这个就能够带动上下游产业，进而激起各行各业。
以上是目前实践下来的抓取要害点的一些办法。但这儿必定也要留意一个粒度问题，千万不要走极端。比方一提要害点，就去考虑实质，一提到实质就去找根因，一找根因就挖到人道，然后得出来便是人道的原罪问题。这种都是没有任何养分的做法，也不利于工作的推动解决。
1—>2
这个考虑办法的意义是：
当咱们考虑一些笼统问题/计划时分，需要对问题进行拆分（一分为二），经过分而治之的办法来确定每个小问题的鸿沟，经过对小问题的解决来降低大局的考虑难度，以赶快构成解决计划。
这个应该不需要举比如了，咱们日常都应该有所触摸，这儿仅仅罗列几个比较典型的技能架构动作：
- 纵深拆解
拆解是十分好的一个将问题分而治之的办法，但要留意的是要做有机的拆解而不是物理的分化。比较典型的事例便是关于毛病指标这个课题的处理，我是见过有团队层层分化，把毛病指标分化到每个同学身上，这是极端错误的做法，也不或许得到想要的成果。咱们应该是要做拆解，便是把要守住毛病指标这个成果拆解成哪几类要害动作，进而要求团队要害动作做到位，而不是强行分化指标。
- 横向解剖
做过实践研发的同学必定遇到一些事务需求的讨论，许多时分来来回回扯不清楚，并且经常会呈现产品说这是技能架构问题，技能架构说这是事务需求问题，事务方说这是产品规划问题的现象。要破解这个僵局就需要把这个问题进行解剖，一层一层解剖清楚，把事务需求问题描述清楚，把产品规划搞清楚，把技能计划搞清楚。每一层都面向上游屏蔽下游的细节，才有或许把问题定义得清楚。一般来说，将这件事参与的人物进行解剖会更简略看得全面，更透彻。
以上是我实践对问题拆分的一些办法技巧，凡事多看几层终归是能够愈加有结构性地认知工作本事，也越有利于问题的解决。
1—>N
这个考虑办法的意义是：
当咱们考虑一些技能计划时分，不要仅局限在其时当刻的条件束缚，要适当考虑体系的承载从 1 变到 N 的进程中的对体系架构带来的应战。
做技能架构师的都知道做架构要求有前瞻性，不能被事务拖着走。但许多时分咱们其实没有细心考虑怎样才能够做到前瞻性，我总结为最要害的考虑的要素便是时间，把时间拉长来考虑要害生产材料或许产生什么改变，经过去架构这种改变所得出来的计划就具有了前瞻性。一般意义上来说，咱们渠道演进的生产材料笼统地概括为三类：
-
事务场景：这是最原始的生存材料，更是渠道演进的源动力。典型的如市场份额改变，用户体价值的改变，竞对动态等。
-
团队安排：是人发明了渠道，也是主导渠道的演进开展，这个生产材料如果不能得到有效利用，充沛开释能动性就会呈现渠道无法支撑事务快速开展，同时人也在渠道中内卷。
-
技能架构：技能架构其实本身也是十分重要的生产材料，这是许多人会疏忽的地方。咱们想一个最简略的比如，同一个变量分散在多个地方导致语义不清，维护本钱巨大就理解了。
针对这几个生产材料我抽取了几个技巧去考虑怎样从 1 扩张到 N：
- 架构考虑一切或许性但做有限明确施行
从事务场景的改变状况来看，确实充满许多不确定性。也遇到过一种典型的事务与架构的死循环的状况：前端事务面临太多不确定性需要技能架构给予专业意见和评价，可是技能架构以为事务啥都想不清楚还要我评价这评价那，两边就开端相互死锁。
而比较好的做法便是架构能够根据自己的经历和事务改变的理解，将或许性进行罗列考虑，然后给出来根据 XX 事务假设下，体系架构需要 XX 量级的工作量做 XX 样的才能迭代晋级，能够做到 XX 的事务效果和价值，但需要进一步 XX 的事务输入。这便是架构考虑一切的或许性的意义，是需要给予事务的挑选。
但技能架构施行却未必是要留有太多的空白，架构要大可是施行要小，关于值得留白的地方做好扩展规划，关于真实看不清楚的地方就要明确阻拦（甘愿不做也不错做），将或许性留足但也不瞎埋坑。
- 没有靠谱的人只要靠谱的机器
我常常去听一些毛病复盘会议，在谈今后怎样改善的时分许多同学都价值观爆棚，说今后XX类改变都加签上我来审阅一道，我承认没问题再往后走。虽然这种精神值得鼓励可是这种做法真实是很不值得推荐，这样沉积出来的渠道其实是十分脆弱的，在做技能计划时必定要考虑能够交给体系的绝对不能用流程，能够做到领域模型校验的千万不要靠旁路体系的侧面印证（如不必要场景下的核对）。
- 提早考虑“美好”的烦恼
许多技能同学都希望做高并发大流量的体系，但许多时分在写代码的时分身体很诚笃，怎样简略怎样来。实践做的时分既不考虑大流量也不考虑高并发，关于资损风险考虑也极端少，并且基本上都很有道理：现在的事务量没到不需要考虑那么多，这种事产生概率极端小一期先这样……要对技能架构做提早考虑就必须从每行代码做起，提早考虑高并发大流量和严谨性。
通常来说咱们其实都比较喜爱从 0 到 1 的进程，依照互联网的迭代式打法，后边的 1 到 N 的进程也会被不断压缩。所以提早在 0 到 1 的进程参加 1 到 N 的架构预判十分重要，由于许多时分结构性的问题在最开端就决定了，并且只要一次机会。
-1<—>1
这个考虑办法的意义是：当咱们考虑一些技能计划时分，不要一条道走到黑，要前后、上下、左右、正反多个方面去考虑，让技能计划具有更多维的视角。
我把常用的技巧总结如下：
- 正反考虑法
日常也 review 了许多同学产出的架构计划和系分以及测分，咱们关于正常事务需求功用的论说基本上都没有啥大问题，墨守成规去写就能够。但普遍的问题都是对问题的不和论说不多，如支付正常流程浓墨重彩，退款/拒付等逆向流程就没那么细致，事务功用正常流通论说很丰满可是异常场景就寥寥几笔。但正面与不和结合起来才是完好的一体，并且对不和的考虑其实是对正面的有益弥补。并且通常来说，咱们在正面呈现的概率大于不和，可是不和呈现过失的影响所需要支付的精力却远远大于正面。
- 极限考虑法
在 review 技能架构计划风险相关的内容时，我都会特意问一下，如果呈现 XX 问题最坏的事务影响是什么。为什么是问最坏的事务影响，是由于如果谈风险那必定都是有一点点的，不利于咱们去深究最要害的问题。经过极限设问，其实是激起咱们去做最坏的计划，有了终究极的兜底手段才能够更乐观去做技能改变。
- 对称考虑法
在 review 代码或许逻辑结构时，在深挖细节和要害点后，我时常会拔出来看看全体的逻辑结构是不是丰满，是不是对称，是不是美。最简略的比如便是写了 if 我必定要有 else，不然没对称结构就让我很不舒畅。由于我信任对称的美便是一种生产力，由于美的东西必定是简练且直达实质的。而咱们写程序要的便是逻辑明晰简略直达事务实质，逻辑结构明晰的基本上没大问题，不明晰（如变量瞎命名，办法无语义）的深挖下去多半都能发现大问题。本源便是逻辑明晰代码才明晰，代码不明晰基本上便是逻辑紊乱，逻辑紊乱就会产生 BUG。
M*N —> M+N
这个考虑办法的意义是：当咱们考虑技能问题时，能够测验从体系耦合的视点去考虑，测验找一些突破口。
我举一个实践的 CASE，高速公路网的衔接不是把一切目的地之间都修一条高速公路，而是会挑选建筑复用的高速公路主干道 + 分支路途的办法来安排这个网络。一条一条串联的办法便是耦合在一起的，这便是 M * N。经过主干道 + 分支路途的办法 便是解耦的，M + N 就能够组成这个高速网络。
在技能架构上怎样运用解耦这个技法，我有如下几个提炼。
- 解耦上下游关联性
在事务和技能架构开展的前期，把许多东西糅杂在一起是最快解决问题的办法。但随着事务和渠道架构的进一步演进，势必是要做解耦，目的便是重新去界定各个模块的鸿沟，平衡新的事务开展要求下各方开展快慢的诉求差异，经过解耦相互松绑快速开展。
这种技法在服务化的分布式架构中十分常见，基本上跨域的渠道架构晋级都有解耦的影子。
- 解耦各个人物的依赖
解耦上下游关联性其实更多是在技能模型的笼统上，但在落入到技能模型领域之前，还有便是咱们在做愈加笼统的解决计划讨论时要留意解耦各个人物之间的依赖。上述【架构考虑一切或许性但做有限明确施行】中提及的便是最好的事例。其实这儿的实质表达便是，技能架构的规划应该要与商业挑选，产品规划等解耦开来。
经过这一层的解耦其实能够多个人物之间根据 SLA 去交互，并且能够根据本身的专业考虑给予对方更多的选项和或许性。许多时分的前瞻性和竞争力或许便是比他人多一个挑选。
解耦考虑法其实很有意思，简直一切的大型渠道架构晋级都有这个考虑法的影子，所以下次没啥思路的时分能够从这个视点做一个审视考虑，说不定是有新的收成。
小结
以上是我在做技能架构计划时沉积总结的一些考虑办法，这些考虑办法不或许解决遇到的一切实践问题，只能算是一个考虑提示，在遇到问题能够测验从这几个办法去看看是否有创意。根据办法论可是不局限于办法论才是办法论最大的意义和价值。接下来一篇文章，我会从技能 Leader 的视角谈谈我在实践中的一些考虑。
作者简介：知明，蚂蚁金服世界事业群资深技能专家，全球资金渠道技能负责人，负责了蚂蚁全球化进程中底层资金清结算、外汇等渠道才能的搭建和迭代演进。
