研发之路结构化的思维体系
每次写周报、作汇报、发文章，都难免要讲到自己的日常工作，如何说清楚是一个不小的挑战，非常挑战结构化思维体系。
|0x00 如何形成结构化的思维
形成结构化思维，首先要有一个定义：“建立中心化的要素，并能够对中心进行逐步的分解，形成分类子结构。以一定的方法论对分类子结构进行分析，寻找对策，制定行动计划”。
例如，当我们接手一项任务时，应当首先思考任务的核心目的是什么：
- 任务的当前目标是什么？（事）
- 为什么这个任务交给我？（人）
从事、人两个维度向上推导，思考这个任务，在整个业务、团队中，是在什么层次和分类上，从全局的角度看，这个任务被赋予了怎样的期望。
先思考事，再思考人，最后向上推导，思考“价值”。这样就建立起了结构化思维体系的“中心”。
当形成“中心”后，再反向对任务进行拆解，通过一定的方法论，分析任务的有效解决方法。
例如SWOT方法，通过Strengths 优势 / Weaknesses 劣势 / Opportunities 机会 / Threats威胁，四类象限，能够两两组合得到不同的分析思路。最早用于进行企业竞争态势分析，对个人而言用于分析自身的竞争态势也是极佳的。
例如AHP方法，将与决策总是有关的元素分解成目标、准则、方案等层次，在此基础之上进行定性和定量分析的决策方法。
有了分析问题的思路，再用Xmind等软件进行任务可视化，一条清晰的路径，就展示了出来。
但这还不够，因为“事情是无限的，而人的精力是有限的”。如果认知的高度不够，那么总会陷入“战术勤奋、战略懒惰”的陷阱。那么就有必要清理任务中的噪点，让精力更加专注。
主要有三个方法：
- 泛化：对客观事实进行抽象，精简维度。
- 补漏：补充缺失的关键信息，避免误差。
- 剪枝：去除非核心的影响因素，聚焦精力。
最后，结构化思维，就是一个非常清晰的方法论：
- 从人、事出发，推导主要价值，形成中心思想；
- 以中心思想出发，拆解任务结构；
- 通过一定的方法论对子任务进行分析，寻找对策；
- 制定行动计划。
|0x01 思考力、知识树
技术人通常有误区：只要努力了，就会有结果。这是不对的。成长这件事，取决于每个人对于重复性劳动的思考成果，换句话说，思考力是能力的最重要影响因素。
例如：
- 为什么要建数据中台，中台一旦拖累了业务发展，应该如何取舍；
- 为什么工作中要有“一号位”意识，业务兜底会带来什么影响；
- 业务系统这么复杂，是否一定有必要提炼中心思想？
现代互联网技术的飞速发展，带来的业务增长是空前绝后的，知识的记忆量也已经爆炸到了一定的地步。但“万变不离其宗”，其实技术原理一定是数量可控的。
例如单纯学习Dubbo怎么用，其实对于业务系统帮助并不大。但如果了解了Dubbo对于寻址、容灾、扩展的核心思想后，这套中间件思维，就可以复制到其他场景中。
所以，对于每个人而言，都应该形成属于自己的知识树。如果对于每件事情，都能够有一种习惯性总结的方法，那么再复杂的业务，也能够快速的通过方法论来提炼要点。可以说，思考力，能够充实个人的知识树，是结构化思维的底座，决定了结构化思维的扩展能力。
如何培养，道理简单，就看个人的坚持程度：
- 保持对自己的信息，时常反思工作；
- 放低自己的姿态，对新技术、新思想持开发心态；
- 学会组织碎片时间，学会平衡看消息与做事情的节奏；
- 用好工具，锻炼好习惯；
- 多交流、读书、分享。
|0x02 结构化思维在研发工作中的应用
形成了结构化思维，回看日常的工作，无非就是：技术、业务、管理，这三大类。
对于技术而言，通常关注如下几个核心点：
- 技术基本功：对于数据而言，就是SQL的熟练程度，以及思考问题的反应速度；
- 架构经验：用过哪些大数据框架，特点如何，优劣势如何；大公司里，即便是一个小需求，也会涉及到非常多的系统，这个过程中项目的协同与推进会远比想象中的有难度，架构经验非常有用；
- 项目经历：数仓结构设计、技术架构设计、模型抽象能力等；技术都是有债务的，如果给自己挖了坑，早晚都要有填上的一天；
- 质量与稳定性：做出来的东西，如何保证不出问题；这是一个先有意识再有能力的问题，千万不要在故障复盘会上，体现你的风采。
对于业务而言，核心点如下：
- 技术规划源于业务：技术同学在做规划的时候往往有一个习惯，那就是先写现状与痛点，再写对应的解决方法，最后展望未来；但往往总结下来，发现部门的业务规划跟自己的规划没什么关系，于是干脆自己搞自己的，矛盾也就起来了；其实在写规划的时候，慢一点，先跟平级的团队，包括产品和运营，聊一聊，了解其他团队，以及大部门的重点是什么，然后再平衡自己的规划，这样来的更加实在一些；
- 比PD更懂业务：这个道理很简单，就是避免成为“工具人”，做到业务上的“向上兼容”；
- 系统边界：团队协作，总是避免不了“纠纷”，系统的边界纠纷会一直存在，在实际的开发中我们做不到至臻完美；所以需求评审的时候，一定要聚焦一下“解耦”的工作，把东西拆到足够清晰，减少可能的矛盾点；
对于管理而言，要注意这些事：
- 计划不如变化快：大多数情况下，“加人”并不能解决团队困境，因为未来是变化的；平时多打听打听，培养一种面对变化的敏感性，如果能在在变化到来之前主动发起变化，那么化被动为主动是最好的；
- 生产力与生产关系：大公司通常有比较好的生产力，但生产关系比较混乱；生产关系的梳理要依赖于业务本身的定义和发展的预判，最终要体现在明确的权责和协作效率上；
- “向上”兼容：“向上”，本质是要求和老板达成一致的目标和互相认可的结果，很多问题，也只有老板能推得动。
简单列了一下，不具体展开。
碰到问题，先基于上述的三个方向，理解问题，并且总结抽象，把关键点拆分出来，并根据方法论，做计划和执行，最后补全自己的知识树。
|0xFF 写在最后
归根结底，技术人员的成长路线上，大多数人，还是要成为“复合型人才”。学会学习的能力，不断实践，经验变成能力，能力促成结果，在结果中积累信心，深化能力。有的时候，能力只是坚持的结果，仅此而已。
