上篇：技术架构的设计方法

上周我写的一篇文章《谈谈技术能力》引起了大家的关注，好多读者的评论“以写代想、以想促真、以讲验真”，大家的感受很深刻，基于上次的文章，这篇文章我其实更想跟大家聊聊一些常用的思考方法，思考问题的方式对了，往往可以帮助大家少走弯路。

常用思考方法

技术常用思考方法

技术思考本质还是结构化思考，所以常见的结构化思考方法也是适用的。这也是大家会看到很多技术架构师都会用一些方法论去分析问题的原因。但这里我不是重新去论述这些常见的技巧，而是分享从技术实战中得到的一些思考方法，为此我分为了技术架构设计的方法和技术 Leader 的思考方法两类。

技术架构思考方法

0--->1

这个思考方法的含义是：

当我们在一堆迷茫和混乱中不知道如何下口时，应该先贴近问题本身，还原客观事实，并快速形成 1 个能够拉起认知并快速讨论迭代优化的版本。大家围绕着这样的一个初始版本去叠加和丰富其他维度的内容，直到方案的共识。

我举一个实际的 CASE，大家在谈某平台能力升级的方案时候会经常喜欢用 PPT 画一些模块图，试图通过一些抽象的词汇来厘定清楚边界，核心概念。大家以为是在讲本质讲原则但实际所有人听了都是云里雾里，不知所云。因为通过概念去推导概念是无法真正回答问题的。

而比较好的应对方法我总结为以下三个步骤：

• 用户视角的客观世界还原

用户故事的串联，基于交互流程和真实的数据来描绘这件事在客观世界中用户视角看来是怎么发生的。这就是我们找准一个大家都能够共识的视角，让所有人快速把客观事实搞清楚画出来这个 1，而这个 1 就是后续讨论的靶子 。这个 1 的表现形式我认为往往都是很简单的，要么是交互时序图，要么是 Excel 表格，而不是复杂的模块概念图。

• 客观信息的结构化整合与提炼

只是树立起来 1 这个初始版本，还远远不够。因为第一个步骤只是将模糊、混乱的东西通过一种方法信息化表达出来，这还远远达不到使用的程度。所以还需要将上述信息进行结构化的整合与提炼，因为信息只有经过结构化才能够变成有意义的知识，才能够与之前的经验形成互动，也才能够进行初版的设计加工。比如对数据流的处理，就会发现有哪些是可以合并的同类项，有哪些平衡校验逻辑等。

• 加入多元视角的检验与抽象

通过第二步的处理把 1 这个版本变得更加丰满，但是要形成完整的可实施方案还远远不够。我们还需要加入更多维度的校验和抽象，比如进一步抽象以看透其本质，比如加入重要异常，ROI，合理性等扩展性等多方的视角去做校验。

所以大家以后在遇到很多方案谈不清楚的时候，不要去听别人讲什么原则，概念，价值等等虚头巴脑的东西。把大家拉回来，回到最简单的最朴素的东西来对焦，那就是 一张交互序列图