慢思考，快行动：怎样做成大事？（航空经理2手机版）

有一种读书方法，叫“把书读薄”，就是看完书后根据自己的理解和认识写读后感。这篇文章就是一个典型的例子，作者读完书后，根据自己的理解和自身案例，写出了一篇参考意义非常大的文章，希望可以帮到大家。

《怎样做成大事》作者收集了25个不同行业（如国防、建筑、核能、航空、奥运会等）的1.6万个大型项目发现：

在预算、成本与收益三个方面，只有0.5%的项目达成预期目标；
在预算、成本两个方面，也只有8.5%的项目达成预期目标；
仅预算一个方面，也只有47.9%的项目达成预期目标。

如何达成预期目标？作者提出了“慢思考，快行动”的方法论，以及“模块化”的解决方案。

这本书带给我很多启发，仿佛打通任督二脉一般，所以今天分享给你，希望对你有启发。

一、一个失败的项目

2023年9月初，我们立项通过了一个大型项目（代号：S）。

S项目在产品方案阶段历时1个多月，前后推翻了3个版本后，磕磕绊绊进入研发阶段；

2024年2月下旬提测，但在3月下旬测试进度完成40%后，因方案的用户复杂度、计算的精确度与后期维护成本等原因决定放弃。

项目投入7、8个人，历时近5个月，损失近百万。

为什么会这样？

当项目阶段性复盘时，我们发现的都是执行阶段的问题。

比如产品经理需求文档不清晰，沟通后也更新不及时，导致研发过程中进度被影响；

比如现有系统复杂度太高，基于当前架构，无法有效控制研发周期与最终效果，导致无法达到预期目标；

或缺少项目经理角色，无风险预警与管理，才导致工期延误。

事实却并非如此，它大概率是失败于项目立项之前。

二、策略性虚假称述与沉没成本才是主因

S项目由一位领导主抓，其在2023年下半年时承诺某标杆客户A，将于2024年3月底之前上线。

当承诺过后，剩下的就是实现，这是一种策略性虚假称述。

策略性虚假称述是指出于策略性目的而有意的、系统的歪曲或错误称述信息的倾向

比如领导为了挽留这一家标杆客户，策略性选择把它当做通用需求做，并寻找相关需求来作证通用化的必要性。

前期先让产品经理介入方案设计，中间反复沟通，确认初版方案时，已经到了2023年10月；

为确保方案可行，提前让研发同学介入评审，发现方案不可行，又反复调整了两个版本，时间又过去了一个多月；

伴随着沉没成本的不断累加，所有人（研发/设计/测试等）都已经被卷进来，每个人心里都觉得有问题，却碍于沉没成本与权威，只是私下抱怨，却无人说推翻方案。

研发2个多月后提测，谁都无法保证质量与效果，直到临近截止日期，无法如期交付，最终只能登门拜访当面道歉后，重新设计新方案，再次承诺2024年6月底解决。

如何才能避免这类事情的发生？

三、慢思考，快行动

林肯曾经说过：如果我有5分钟砍一棵树，我会用3分钟来磨刀。这就是我们常说的“磨刀不误砍柴工”，也是“慢思考，快行动”的本质。

与之相反的是“快行动，慢思考”，就像上述案例一样，前期好像行动迅速，实际评审、研发、测试阶段却问题不断，最终导致项目失败。

什么才是“慢思考，快行动”？

1. 以终为始，从右往左思考

因思考惯性，我们的思考习惯是从左往右。

左边是什么？是看得见摸得着的产品方案（且大概率是第一个方案），是眼前的这家标杆客户；

右边是什么？是为什么要立项？项目目标是什么？有最佳解决方案吗？

为什么S项目要立项？

因为这是一家标杆客户，且领导已承诺？显然不应如此。

项目目标是什么？

目标是解决标杆客户的需求，还是解决所有类似客户的需求？

如果是前者，则解决方案可以用更低成本的方式；

如果是后者，那其他客户的需求是什么？对应解决方案能覆盖吗？

实际情况是：有3-4家客户有同类需求，但实际业务规则差异非常大，根本无法通用化处理。

当前是最佳解决方案吗？

从评审反复近1个月到研发时间2个多月，测试1个多月排期确认时，基本已经说明方案的可行性，却因沉没成本而忽略风险而继续投入，直到崩溃。

吃一堑，长一智。

下次如何避免此类问题？

我提炼了一个大型项目（1个月以上工期）的需求分析表（如下图），以及两个产品原则。

原则1：产品经理应该把50%以上精力放到立项之前，只有慢思考，才能快行动。

原则2：但凡项目工期超过2个月，则重新思考方案或分拆子项目。

2. 最大虚拟性产品

互联网行业推崇的是：最小可行性产品，而现实世界的大型项目却推荐：最大虚拟性产品。

关键区别在于：时间周期与成本。

如果做一款互联网产品，时间周期短，可用最小成本验证需求后，逐步迭代，用户是可接受的；

如果是拍一部电影、建一栋楼等，时间周期长，投入巨大，这就需要用最大化虚拟性产品。

它的本质与最小可行性产品一致，即尽可能用更小的成本验证需求，获取反馈后迭代方案，但为了保证验证效果，则应采用更逼真、更精细化的方案。

比如建筑行业的数字建模与实体模型，它不是最小可行性产品，而是一个超逼真、细节极其精细的产品（即最大虚拟性产品）；

或者是电影行业的模拟视频，它是有一帧帧真实画面构建而成，所有图片细节都是逼真的，所有动效都是真实的，这是最大虚拟性产品。

那对于互联网产品来说，最小可行性产品与最大虚拟产品的界限在哪儿呢？

最小可行性产品更适用于C端产品，而最大虚拟性产品更适用于B端产品（尤其是大型项目），它的形态可以是逼真、有细节数据、有真实交互的原型方案。

是的，它在前期非常耗时耗力，但也是综合成本最低的方案。

因为项目研发前的工作，最多只是浪费产品经理的时间精力，而立项通过后，将浪费设计、研发、测试等同学的时间精力，后者成本是前者的N倍

所以我才提出：产品经理应该把50%以上精力放到立项之前。

具体把时间花在哪呢？

通过调研、分析等方式，明确需求（需求是1，方案是0）；
思考并完成需求分析表，明确为什么做与目标；
制作最大化虚拟性产品，与用户完成反确认，并基于反馈反复打磨它。

3. 一个成功的项目

即我入职时接收到的任务目标是：全面研究竞品，重构考勤系统。

经过【需求是1，方案是0】的方法论指引，最终选择的并非重构路径，而是有效解决客户需求的方案。

当时也犯了一个错误，初审时的产品方案太大（评审3个小时才完成一半）。

初审完成后，及时止损，重新把方案拆分为5个独立可上线的子项目，逐步迭代，最终历时近8个月，全部如期上线。

现在复盘成功经验的话，至少有三个方向决策正确：

这背后的本质，就是“慢思考，快行动”在互联网行业的践行（尤其是面向企业端产品）。

所以我才提出：但凡项目周期超过2个月，就需要重新设计方案或拆分子项目。

4. 模块化

最后，再聊一聊模块化。

互联网行业推崇的是：小步快跑，快速迭代的最小闭环产品原则，以及相互独立且自我闭环的微服务设计。

同理，实体行业则推崇：模块化。

它的本质是重复与抽象。

比如搭建一个巨型太阳能发电厂，核心就是设计一个个以太阳能电池为基础组件的“积木块”，在项目现场把多个太阳能电池组装在一起，就可高效完成。或者在贫困地区创建成千上万所学校，也可设计几种学校结构，拆解为一间一间独立的教室，再把它们进行组合，就可以得到许多所的学校。
比如特斯拉的一体式压铸技术，把上万个零部件打包成一个模块。如果把它迁移至互联网软件行业，本质也适用。
比如Workday是一款财务与人力资源SaaS产品，它的架构设计核心就抽象为两大“积木块”：业务流程、对象。
比如发简历、面试、入职、调岗、排班、加班等，都是一个个的业务流程，把它们进行抽象与封装，形成一个个流程“积木”，不同的企业可以进行组合使用。

每一个流程则由：类型、触发条件、触发节点、触发对象等组件组合而成，按需配置。

有了流程，剩下就是面向对象。

每个流程会面向一个或多个对象，同时流程流转又会对对象产生信息流，遵循领域设计原则，把每个对象的流程与记录独立封装，即可形成一个对象的详情。

比如员工调薪是一个流程，它作用对象是员工，操作对象是薪酬专员，可以根据需求配置不同流程节点，流程结束后，员工花名册跟薪资档案信息同步更新。