结构化思维
在说结构化思维之前，先看下面两个小案例：
案例一：
产品进行一次比较大的重构和功能迭代，因为改动较大，对产生 Bug 的数量和修复 Bug 的速度预估不足，导致延迟了两周才进行交付。
1、技术负责人认为整个团队都很做的很辛苦，每天都在加班加点地赶进度，感觉不算是延期，处理了很多本次功能之外的问题；
2、对公司来说版本没有准时发布，多耗费了两周的成本。
案例二：
在项目实施过程中如果发现产品有 Bug ，实施人员会提问题单，产品团队接收到问题单后会安排开发人员进行排查和修复，经常发现一些问题单没能及时关闭，最后问起原因，有下面几种：
1、问题无法重现，需要提供日志或特定数据，但一直没提供；
2、和实施人员沟通，采用其他变通方式解决；
3、实施人员说这个问题不用处理了。
案例一的技术负责人很认真负责，但在开发前只考虑了新增功能，没有考虑改造带来的关联影响，没有控制好风险，导致延期。交付后进行复盘，会认为不能定义为延期，因为在初始的时间节点内当前版本的功能都完成了，而且还处理了很多「额外」的问题。
案例二的开发人员也认为自己能做的都做了，但从客户或管理者的角度来看，这些问题单是没有完结的。
之所以会出现这些情况，我认为是缺乏结构化思维。
什么是结构化思维？
最近看了《极简项目管理》这本书，对结构化思维的定义是：
所谓结构化思维，是指一个人在面对工作任务或者难题时能从多个角度进行思考，深刻分析导致问题出现的原因，系统地制定行动方案，并采取恰当的手段使工作得以高效地开展，取得高绩效。
书中还给出了一个例子来介绍怎样使用结构化思维。
200 毫升的水怎样倒进 100 毫升的杯子？
分析：
1、为什么倒不进去？因为水会流出来；
2、为什么会流出来？因为杯子小；
3、杯子小就一定流吗？因为地球有引力；
4、杯子小，地球有引力就一定流下来吗？因为水是液体。
三个方面来思考问题：
1、问题本身：
杯子：杯子是否是能有弹性的？ 水：水是不是可以进行冷冻，将其变成固体？
2、环境：
地球有引力，那么是不是能到太空中去完成？
3、解决问题的主体：
我们的能力和认知觉得无法解决的问题，是不是能协调资源，找专家、高手就能解决？
上面的例子，是站在一个全局的视角下，从多维度去提出问题，最终找到合适的手段，制定行动方案，这种方式可以用在平时工作和生活的很多地方。
再回到上面的两个案例。
案例一可以分为重构前、重构中、和事后复盘。
在重构前：
1、分析重构部分的关联影响；
2、重构部分和新增迭代功能是否存在冲突，存在应该怎么应对？
3、测试需要协助提供一些主线用例供开发自测使用；
4、综合各种考虑到的场景来制定计划和时间节点。
重构中：
1、不管前期规划多详细，总会出现在落地时才能发现的一些问题，比如：实现一个很细节的点可能导致一些需求设计或代码设计上的变更；
2、发现问题需要及时提出，并且对工期进行重新评估，是否会影响发布节点？
3、如果有影响，需要向上沟通，确认某些调整能否放到下一个迭代？
4、如果时间节点和功能都需要保证，需要进行资源协调，引入更多的资源来保证功能和时间，不过在迭代后期，加更多人不一定是明智的选择；
5、如果资源协调也不行，那就只能付出更多的时间来弥补之前的分析和评估的不足。
事后复盘：
1、延期如果已成事实，需要正视问题，不要找客观的原因，否则就无法改进；
2、找到关键点和根因，并制定改进措施，虽然鼓励试错，但要避免犯同样的错误；
3、改进措施可能是规范、也可能是流程，沉淀到文档，监督执行。
案例二其实就一个关键点：让事情有始有终，形成闭环。
1、一个问题单指定了责任人，那么责任人就需要跟进到底；
2、跟进到底的意思不仅仅只对代码进行了修改，目的是要最终解决客户的问题，而且是快速地解决客户的问题，所以问题单的优先级一般都很高；
3、有些问题开发环境不能重现，就需要多维度来思考：
能不能协调资源，找到高手来一起分析？ 对紧急线上问题，有没有应急的方式先进行处理，然后再分析原因？ 添加日志是否对排查问题有帮助？ 是否需要实施提供特定数据？如果不能提供，应该怎么模拟？ 此类问题是否在其他的项目中也存在，是否需要发放补丁包？
4、确定一种方案后，就需要快速执行，直到问题解决。
两个案例中存在的问题都是在思考问题的时候，考虑的是点，不是面，就像玩积木，每一个块都是一个独立的个体，将其组合，搭建出一个房子的时候，需要考虑各种问题，形状是否合适，颜色是不是搭配起来好看，因为一个房子模型的结构是系统的。
现在有很多的思维方式、做事的方法，比如：
1、把事情分为重要紧急、重要不紧急、不重要紧急、不重要不紧急四象限；
2、5W2H 分析法；
3、黄金思维圈；
4、DPCA 环；
5、金字塔原理。
这些我认为都属于结构化思维，结构化思维就是把零散的、无序的信息加工成系统有序的信息，有了结构化思维后，我们对事物的认知会提高，有助于高效实现目标。