拙速——解决问题的“快与慢”
在开始之前，先来看一下几个项目中常见的场景。
场景1：项目还在计划阶段，评估结果显示某个功能不能在设定的交付日期之前完成。作为项目经理，你要怎么做？
场景2：执行阶段发现了需求遗漏，你会要求团队增加资源投入，将新需求加入到项目内容？还是将新识别的需求计划到以后的项目中？
场景3：执行过程中，你发现某个模块的进度严重落后，你要怎么处理？
场景4：临近项目交付，测试团队报告说发现了棘手的技术问题，你会延期项目交付来解决这个问题吗？
快还是慢？
生活在一个快节奏的社会，面对工作和时间压力，每个人都在寻找能快速解决问题的方法。在软件项目管理中，我们也经常面对这样的情况。开发进度落后，马上增加开发资源，加班加点赶进度；测试发现了问题，增派更多专家加快解决问题的速度。这些措施表面看起来都没问题，但是往往执行到一半，就再次发现其它问题，于是需要推翻之前的方案，或者选择一个新方案。如此反复，浪费大量人力物力不说，项目也陷入问题的泥潭越拖越久。这些看似快速的方案，实则在拖慢我们项目的进度。
在《思考的快与慢》中说我们的大脑有“快思考”和“慢思考”两种模式，大脑的惰性会让我们更偏好“快思考”。而很多项目中的问题，也恰恰是“快思考”带给我们的陷阱。 要想避免被“直觉”绑架，就需要我们在面对问题，寻求解决方案时，强迫自己进入“慢思考”的理性模式。问题建构的过程，正是将我们从“快思考”模式拉入到“慢思考”模式的过程。
从“快”到“慢”：问题建构
对于我们熟悉领域的问题，我们会自然地在脑海里产生可能的选项，并且对某个选项产生特殊的偏爱，不管是出于项目利益，还是执行难易程度。这时候，我们就可以采取假设金字塔来对我们的偏好进行验证，所有的子假设都有数据可以证实，或者某个子假设被证伪，那就可以很容易知道执行起来可能遇到的问题，根据问题来调整我们的假设方案。
另一方面，对于一时无法给出假设方案的问题，我们可以借助“问题树”框架对问题进行拆解，一直到我们能够直接给出解决方案的子问题，然后对子问题的解决方案进行汇总和整理，就可以形成对核心问题的可行性方案。
“慢”下来看看
再次回到文章开头提到的几个问题，是不是可以得到不一样的处理方案？我们以场景1和场景4为例。
假设金字塔
场景1：项目还在计划阶段，评估结果显示某个功能不能在设定的交付日期之前完成。作为项目经理，你要怎么做？
图片
图1：问题建构：假设金字塔
一旦某个子假设不成立，那么我们的核心假设就不成立。我们要么是子假设成立，要么修改我们的核心假设。问题树
场景4：临近项目交付，测试团队报告说发现了棘手的技术问题，你会延期项目交付来解决这个问题吗？
图片
图2：问题建构：问题树
基于这些问题的答案，我们可以提出假设性解决方案。之后，我们可以再次通过假设金字塔来验证我们的方案是否可行，并根据验证结果对方案做出调整。
拙速：“慢”即是“快”
从以上两个问题构建的例子可以看出，对任何一个问题，我们可能凭直觉就会产生一个假设性方案，但是真正是否可行，还需要我们静下心来，通过问题的建构过程，老老实实分析一遍，最后形成真正可行的应对方案。看似笨拙，实际中却大大降低方案的风险，加速问题的真正解决。这时，慢，即是快！拙，即是速！
道理千万条，实践第一条，真正的高手，是那些能够在实际中坚持践行并不断探索的人。处理项目中的各种问题没有什么捷径，让我们脚踏实地，拙速前行！