73 lines
6.4 KiB
Markdown
73 lines
6.4 KiB
Markdown
# 1
|
||
|
||
我思考，定义问题后，对问题的分解主要有几种方法：
|
||
|
||
1. 按项目生命周期分解
|
||
* 里程碑驱动
|
||
* 业务&工作流程
|
||
* 价值链
|
||
2. 按可交付成果分解
|
||
* 结果导向型
|
||
* 产品&组件（产品构成）
|
||
3. 按专业类比分解
|
||
* 职能驱动型
|
||
* 岗位&人员分工
|
||
* 组织结构
|
||
|
||
其他还有按地域/地理，按条件的，但是不太常用。
|
||
对此你怎么看？
|
||
|
||
你这个清单整理得很有条理，像个勤勉的会计师在盘点自己的工具箱。这说明你有一个清晰、结构化的头脑，这是个非常好的起点。但我们都知道，仅仅拥有一个装满锤子、锯子和扳手的工具箱，并不能让你成为一个伟大的建筑师。真正的关键在于，你是否知道什么时候该用哪件工具，以及更重要的——建筑的整体设计图是什么。
|
||
|
||
让我们用“六层深度思考阶梯”来审视你这个关于“问题分解”的框架。
|
||
|
||
---
|
||
|
||
### **第一层 (本质提取): 你在做什么？**
|
||
|
||
你正在尝试为“如何拆解复杂性”这件事建立一个分类系统。本质上，这是所有理性思考的起点：将一个巨大、模糊、令人望而生畏的“大象”，切成一块块可以处理的“牛排”。你的分类——按时间、按结果、按分工——是三种非常经典且实用的切法。这很好。
|
||
|
||
### **第二层 (领域同构): 其他领域是怎么切大象的？**
|
||
|
||
这个问题并非商业或项目管理所独有，它是普适的。
|
||
* **生物学：** 一个生物学家如何理解一只青蛙？他会从不同的维度分解：按**生命周期**（卵、蝌蚪、成蛙），按**系统**（循环系统、神经系统），按**物理构成**（头、躯干、四肢）。你看，这和你清单上的方法几乎是完全对应的。
|
||
* **物理学：** 为了理解一个物体的运动，物理学家会将其分解为不同方向上的矢量（x轴，y轴），并分析不同时间点的状态。这同样是按“组件”和“生命周期”分解。
|
||
|
||
这告诉我们，你的分类方法之所以有效，是因为它触及了理解复杂系统的几种基本模式。
|
||
|
||
### **第三层 (反转假设): 如果分解是错误的怎么办？**
|
||
|
||
现在，我们来玩一个更有趣的游戏。你默认的假设是“分解问题是通往答案的正确路径”。我们反过来想：**在什么情况下，对问题进行分解反而会导向灾难性的失败？**
|
||
|
||
1. **当各部分之间的“联系”比“部分”本身更重要时。** 在一个复杂的自适应系统（比如一个经济体、一个生态系统，或者一个公司的文化）里，系统的行为是由无数个组件之间的反馈循环决定的。你把它拆开，分别“优化”每个部分，就像一个庸医，头痛医头、脚痛医脚，最后却杀死了病人。你可能会完美地解决了每一个被分解出来的“小问题”，却导致了整个系统的崩溃。
|
||
2. **当你沿着错误的“纹理”去分解时。** 一块好的木头有它自己的纹理，一个好的屠夫懂得顺着关节来分割牛体。如果你用错了分解方法——比如，强行按照你的组织架构（职能分工）去分解一个本该按客户价值链来组织的项目——你创造的沟通成本和部门壁垒，会远远超过分解带来的好处。这就是所谓的“康威定律”的诅咒：你的产品结构，最终会和你公司的沟通结构一模一样。
|
||
|
||
### **第四层 (变换尺度): 这套方法在不同尺度下表现如何？**
|
||
|
||
* **微观尺度：** 比如“策划一次家庭烧烤”。用你的方法就非常有效。按**生命周期**（采购、准备、烧烤、清理），按**可交付成果**（肉、蔬菜、酱料、饮料），按**人员分工**（爸爸负责生火，妈妈负责串串）。简单明了。
|
||
* **宏观尺度：** 比如“如何解决城市交通拥堵问题？”。这时你的框架就开始变得脆弱了。你可以按**生命周期**（早高峰、晚高峰），可以按**组件**（道路、车辆、信号灯），可以按**职能**（交通局、规划局、警察）。但很快你会发现，这些部分互相掣肘，形成了一个动态的、不断演化的复杂系统。单纯优化任何一个部分，都可能引发意想不到的“报复”。比如，拓宽道路，短期内缓解了拥堵，长期看却可能因为刺激了更多人买车而导致更严重的拥堵。
|
||
|
||
### **第五层 (定位支点): 那个能让问题豁然开朗的关键视角是什么？**
|
||
|
||
你的清单是关于“**怎么分**”（How）。这是一个战术层面的问题。但你完全忽略了更重要的战略层面的问题：“**为什么这么分？**”（Why）以及“**沿着什么原则去分？**”（According to what principle?）
|
||
|
||
真正的支点在于：**最好的分解，是顺应问题本身的内在结构，而不是试图将外部的框架强加于问题之上。**
|
||
|
||
在你选择任何一种分解方法之前，必须先回答一个更根本的问题：“这个系统最重要的杠杆点在哪里？”或者说，“是什么关键因素在驱动整个系统的行为？” 你应该围绕这个杠杆点去进行分解，而不是你的项目管理流程图。
|
||
|
||
### **顶层 (整合洞见): 超越原始维度的结论**
|
||
|
||
你的框架是一个非常有用的“战术清单”，但它缺少一个统领全局的“战略思想”。它让你成为一个高效的“工头”，但可能会阻碍你成为一个深刻的“建筑师”。
|
||
|
||
**与其痴迷于分解问题的方法论，不如专注于理解问题本身的“本质结构”。** 不要一上来就问“我该用哪种WBS（工作分解结构）？”。
|
||
|
||
你应该先问：
|
||
* 这是一个简单的、多部件的问题（像造一辆汽车），还是一个复杂的、多反馈的系统（像养一个孩子）？
|
||
* 如果这是一个系统，它的关键驱动回路是什么？它的“生长”和“衰败”遵循什么规律？
|
||
* 如果我必须找到一个地方“下刀”，那一刀应该切在哪里，才能让系统的能量自然而然地流向我想要的方向？
|
||
|
||
**所以，给你一个挑战性的问题，用于取代你原有的思考起点：**
|
||
|
||
> **在开始分解任何一个复杂问题之前，先问自己：“如果我只能做一个动作来改变这个系统，这个动作应该是什么？为什么？”**
|
||
|
||
找到那个支点，你的分解方法自然会水到渠成。否则，你只是在用不同的姿势，勤奋地切割一头你根本不了解的“大象”。 |