研发之路：结构化的思维体系

研发之路结构化的思维体系

每次写周报、作汇报、发文章，都难免要讲到自己的日常工作，如何说清楚是一个不小的挑战，非常挑战结构化思维体系。

|0x00 如何形成结构化的思维

形成结构化思维，首先要有一个定义：“建立中心化的要素，并能够对中心进行逐步的分解，形成分类子结构。以一定的方法论对分类子结构进行分析，寻找对策，制定行动计划”。

例如，当我们接手一项任务时，应当首先思考任务的核心目的是什么：

1. 任务的当前目标是什么？（事）
2. 为什么这个任务交给我？（人）

从事、人两个维度向上推导，思考这个任务，在整个业务、团队中，是在什么层次和分类上，从全局的角度看，这个任务被赋予了怎样的期望。

先思考事，再思考人，最后向上推导，思考“价值”。这样就建立起了结构化思维体系的“中心”。

当形成“中心”后，再反向对任务进行拆解，通过一定的方法论，分析任务的有效解决方法。

例如SWOT方法，通过Strengths 优势 / Weaknesses 劣势 / Opportunities 机会 / Threats威胁，四类象限，能够两两组合得到不同的分析思路。最早用于进行企业竞争态势分析，对个人而言用于分析自身的竞争态势也是极佳的。

例如AHP方法，将与决策总是有关的元素分解成目标、准则、方案等层次，在此基础之上进行定性和定量分析的决策方法。

有了分析问题的思路，再用Xmind等软件进行任务可视化，一条清晰的路径，就展示了出来。

但这还不够，因为“事情是无限的，而人的精力是有限的”。如果认知的高度不够，那么总会陷入“战术勤奋、战略懒惰”的陷阱。那么就有必要清理任务中的噪点，让精力更加专注。

主要有三个方法：

• 泛化：对客观事实进行抽象，精简维度。
• 补漏：补充缺失的关键信息，避免误差。
• 剪枝：去除非核心的影响因素，聚焦精力。

最后，结构化思维，就是一个非常清晰的方法论：

1. 从人、事出发，推导主要价值，形成中心思想；
2. 以中心思想出发，拆解任务结构；
3. 通过一定的方法论对子任务进行分析，寻找对策；
4. 制定行动计划。

|0x01 思考力、知识树

技术人通常有误区：只要努力了，就会有结果。这是不对的。成长这件事，取决于每个人对于重复性劳动的思考成果，换句话说，思考力是能力的最重要影响因素。

例如：

• 为什么要建数据中台，中台一旦拖累了业务发展，应该如何取舍；
• 为什么工作中要有“一号位”意识，业务兜底会带来什么影响；
• 业务系统这么复杂，是否一定有必要提炼中心思想？

现代互联网技术的飞速发展，带来的业务增长是空前绝后的，知识的记忆量也已经爆炸到了一定的地步。但“万变不离其宗”，其实技术原理一定是数量可控的。

例如单纯学习Dubbo怎么用，其实对于业务系统帮助并不大。但如果了解了Dubbo对于寻址、容灾、扩展的核心思想后，这套中间件思维，就可以复制到其他场景中。

所以，对于每个人而言，都应该形成属于自己的知识树。如果对于每件事情，都能够有一种习惯性总结的方法，那么再复杂的业务，也能够快速的通过方法论来提炼要点。可以说，思考力，能够充实个人的知识树，是结构化思维的底座，决定了结构化思维的扩展能力。

如何培养，道理简单，就看个人的坚持程度：

1. 保持对自己的信息，时常反思工作；
2. 放低自己的姿态，对新技术、新思想持开发心态；
3. 学会组织碎片时间，学会平衡看消息与做事情的节奏；
4. 用好工具，锻炼好习惯；
5. 多交流、读书、分享。

|0x02 结构化思维在研发工作中的应用

形成了结构化思维，回看日常的工作，无非就是：技术、业务、管理，这三大类。

对于技术而言，通常关注如下几个核心点：

• 技术基本功：对于数据而言，就是SQL的熟练程度，以及思考问题的反应速度；
• 架构经验：用过哪些大数据框架，特点如何，优劣势如何；大公司里，即便是一个小需求，也会涉及到非常多的系统，这个过程中项目的协同与推进会远比想象中的有难度，架构经验非常有用；
• 项目经历：数仓结构设计、技术架构设计、模型抽象能力等；技术都是有债务的，如果给自己挖了坑，早晚都要有填上的一天；
• 质量与稳定性：做出来的东西，如何保证不出问题；这是一个先有意识再有能力的问题，千万不要在故障复盘会上，体现你的风采。

对于业务而言，核心点如下：

• 技术规划源于业务：技术同学在做规划的时候往往有一个习惯，那就是先写现状与痛点，再写对应的解决方法，最后展望未来；但往往总结下来，发现部门的业务规划跟自己的规划没什么关系，于是干脆自己搞自己的，矛盾也就起来了；其实在写规划的时候，慢一点，先跟平级的团队，包括产品和运营，聊一聊，了解其他团队，以及大部门的重点是什么，然后再平衡自己的规划，这样来的更加实在一些；
• 比PD更懂业务：这个道理很简单，就是避免成为“工具人”，做到业务上的“向上兼容”；
• 系统边界：团队协作，总是避免不了“纠纷”，系统的边界纠纷会一直存在，在实际的开发中我们做不到至臻完美；所以需求评审的时候，一定要聚焦一下“解耦”的工作，把东西拆到足够清晰，减少可能的矛盾点；

对于管理而言，要注意这些事：

• 计划不如变化快：大多数情况下，“加人”并不能解决团队困境，因为未来是变化的；平时多打听打听，培养一种面对变化的敏感性，如果能在在变化到来之前主动发起变化，那么化被动为主动是最好的；
• 生产力与生产关系：大公司通常有比较好的生产力，但生产关系比较混乱；生产关系的梳理要依赖于业务本身的定义和发展的预判，最终要体现在明确的权责和协作效率上；
• “向上”兼容：“向上”，本质是要求和老板达成一致的目标和互相认可的结果，很多问题，也只有老板能推得动。

简单列了一下，不具体展开。

碰到问题，先基于上述的三个方向，理解问题，并且总结抽象，把关键点拆分出来，并根据方法论，做计划和执行，最后补全自己的知识树。

|0xFF 写在最后

归根结底，技术人员的成长路线上，大多数人，还是要成为“复合型人才”。学会学习的能力，不断实践，经验变成能力，能力促成结果，在结果中积累信心，深化能力。有的时候，能力只是坚持的结果，仅此而已。