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

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

每次写周报、做汇报、发文章，都不免要讲到本身的平常工做，如何说清楚是一个不小的挑战，很是挑战结构化思惟体系。

|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 写在最后

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