《结构化的思考、做事、成长》笔记

能力要素

要重点建设的三种能力：

结构化的思维
结构化的工作模式
结构化的能力建设

什么是结构化

structured：建立中心（问题、目标）以中心的核心要素对中心进行分解，形成分类子结构。以一定的范式、流程顺序进行分类子结构的合理分类、减少非关键分类结构；对关键分类子结构进行分析，寻找对策，制定行动计划。

同理，按照逆向的顺序，对多种杂乱的内容，进行分类、剪枝、归纳归总成一个中心，也是结构化。

案例

建立结构化的中心

一个业务需求，通常可以按照两个维度分解为不同的子结构：

1 当前业务需求的目标是什么？（事的维度）。

目标是快速完成上线试一试业务效果：目标事的维度为高效稳定上线。
目标是建立后续业务铺开的基础方案：目标事的维度是强架构设计下的核心与功能拆分方案。

2 为什么需要我来做？（人的维度）

是因为我工作量还有 buffer 所有承担这部分：目标人的维度是完成职能范畴内的工作。
是因为我在这方面技术比较擅长：目标人的维度是利用事情强化自身能力和使用能力把事儿做好。

沿中心上行

对单个业务需求而言，从事、人两个维度建立起的中心即其核心，是最主要部分，建立一颗结构树的基础。但我们不应当停止于此，还应当向上推导：这个需求在整个业务的范畴内，是在哪一层次，哪一分类的。即应当更高层面、或整体业务和行业发展，对这方面业务是怎样的期许。（价值的维度）

一个团队接手某项业务或需求，其背后都会有思考。我们是期望借着这个业务打造一个平台，提升整体行业的表现；还是突击这个业务方向，占领局部的商业蓝海。。。
接到一个需求时一定要思考更大层面这事的价值，才能更好的判断优先级、做事模式。

例如：我们做采购系统，当前需求是，提供采购单列表，按总价范畴搜索单据的能力。按结构化的中心建立，它是：高效稳定上线（事）、我职能范围内的工作（人）。

如果止步于单个需求建立的中心，我们后续的分解应当是如何快速搞定、如何更稳定。。。
如果我们继续向上构建树，我们可以和产品、使用者深度沟通下为什么要做价格搜索
- 管理员期望能看到高价订单的情况。那么这个需求的上一个中心节点应当是：管理提效。
- 继续向上，是基于什么原因需要做管理提效？因为防止贪腐、提高工作效率。那么上一个中心节点应当是：降低成本。
- 依次向上，直到抵达整个业务的目标。比如总结觉得，我们的业务是构建一个集成高效的集团采购系统。
再以此反思：
- 降低成本是不是当前工作的重点？团队是否有足够的架构设计和人员组织来支撑？
- 下一步到到管理提效层面，订单的搜索是否真的是当前最佳的提效工具，因为用户如何定义高价格？他执行这种搜索式查阅工作是否真的是有效不遗漏的？查阅到了订单有问题他能做什么？。。。我们会发现这个需求背后更多的问题。我们也可以沿着更大的中心树，去思考是否构建更好的方案可以更根本的解决这个问题。
再回过头来看当前的任务，是否真的是高效稳定上线（事）、我职能范围内的工作（人）。或者当前最紧急的部分（用户直接需求嘛）是高效稳定上线（事）、我职能范围内的工作（人），但后续更要做更多的其他的根本性解决方案。

沿当前的中心向上建立更大的结构化的认知体系

会让我们对当前事情的判断（中心）更加清晰，也有更好的认知基础，极有利于与合作方的沟通碰撞和内容创新。
建立更大结构化认知体系的过程，也是深入业务、扩展认知力的过程。一定要多和老板、业务方交流，从各自认知的差异性上提升自身的认知能力。

此外，构建更大认知体系，对个人和团队发展也是有价值的

很多时候我们忙于业务实现，都没有花时间去思考业务的价值。一部分是因为忙，一部分是因为懒，一部分是因为不懂，一部分是因为我们是来做事拿工资的，而不是带着愿景想把事做好的。这都不是真正能把事情做好的方式。
作为团队的一员，我们不应当只做“花时间、生鸡蛋”的极低人效、技术外包的母鸡模式，而应当积极的尝试做“建机器、铺厂房、出产品”的工厂模式。这对业务和个人的发展才是积极的作用。

中心的分解

建立完成中心后，有多种对中心进行分解的方式。其目标在于将中心拆解为多个内聚的子部分。整体思想是MECE（Mutually Exclusive Collectively Exhaustive）原则，即相互独立，完全穷尽不重叠、不遗漏的分类。够借此有效把握问题的核心，并成为有效解决问题的方法。

SWOT 法
AHP 法

进行分解的顺序逻辑：

时间顺序
结构顺序
程度顺序

清理

事业是无限的，人力总是有穷、认知高度总是不够的。我们不能把分析出的所有点都做好，也不是分解出的所有层次都真正有价值的。那么针对分解的产出物，应当以数据挖掘的物料准备类似的逻辑进行前期处理，来提高效率、去除噪声。常用的分别为：

泛化：过度细碎的层次应当抽象总结到更高层次，以进行更有效分类。
补漏：针对中心，某些关键决策子层级缺失，应当补充完全。
剪枝：针对中心，与中心紧密度关联较低或无可操作性的部分应当去除，以降低整体分析复杂度。

结论

建立中心；

以中心的核心要素对中心进行分解，形成分类子结构；

以一定的范式、流程顺序进行分类子结构的合理分类、减少非关键分类结构；

对关键分类子结构进行分析，寻找对策，制订行动计划。

实践的效果

老板问我当前做的事情怎么样了，我讲了合作中的难点、视觉风格问题、业务情况、代码质量。。。工作的进展，说了半小时，老板还是get不到我做的事情的情况和价值：按照事情核心目标的达成情况，各子部分重点问题和解进行结构化的讲述，两分钟说清楚。
我这一年做了很多事情，都有一定产出，但是跳出细节来看，发现对业务、对团队价值都不大：先建立团队当前业务的核心目标，分解目标达成所需的各个部分，自身努力在某个部分上做深，或者补全当前缺少的部分，或者强力推进将团队目标向上拔高一层更大的目标。
最近流行codeless，我打算研究下可视化搭建；团队业务涉及到流程编排，我打算研究下TMF。。。一年下来折腾了不少成果出来，老板却不提名我晋升：先确定自身技术能力提升的目标，分解到需要提升的各个部分，针对不同部分向老板强求从事相关工作、在当前工作内尝试和深耕，从深入一个部分到横切一个面的能力提升，晋升自然水到渠成。