项目管理实战：不知道自己在做什么时如何推进

一套应对不确定性的项目管理方法：用最小可行团队快速行动，区分稳妥区与研发，用垂直切片交付完整成果，并告诉你何时该招人、何时该融资，而不是假装计划完备、盲目扩张团队。

模糊的照片：为什么 waterfall 和 agile 都不够用

想象一张你的项目及其目标市场的照片。一开始它是模糊的：你能看到色块，猜得出形状，但看不清细节。你想开一家酸面团面包店，你知道有人愿意为好面包多付钱，但不知道有多少人、什么时间买、你真正的问题会是烤箱还是配送。

这张模糊的照片就是你的起点，而且跳不过去。你唯一能做的是提升它的分辨率，而分辨率的提升只有一种方式：行动。你接待的每个客户、谈判的每个供应商、发布的每个版本，都会还给你以前没有的像素。

两个经典模型正是在这里崩塌：

在一个技术、渠道、连客户行为都每个季度都在变的环境里，这两个假设都站不住。你需要别的东西：不是一份完整的计划，而是一份和团队同步获得细节的低分辨率计划。

这是几乎没人说的一点，也是整个框架里最有用的一点。

当你能精确画出所需的组织架构图时，你就知道自己赢得了分辨率。不是任务清单。不是 roadmap。一张组织架构图：有哪些职能、每个职能配几个人、哪些内制、哪些按项目外聘、哪些用技术而不是用人来解决。

画不出来之前，你还是模糊的。而模糊的时候，你不应该大量招人，也不应该启动一轮大融资。

注意问题的转变。它不再是"产品什么时候做好？"，而是变成**"我什么时候才能知道，把这件事做好需要一家什么形状的组织？"**。

拆解项目时，人们的本能是想到人：我需要一个设计师、一个销售、一个 community manager。这是顺序错误。

先拆成部门。这里给出那个改变一切的定义：

部门是一个问题，角色是一个学到的解法。

如果你开一家内容机构，"视频制作"不是一个岗位：它是你要解决的一个问题。"获客"是一个问题。"按时收款"是一个问题。角色是后来的事——等你把问题理解得足够透彻，知道什么类型的人能解决它。

把这两件事搞混，就会为了一个你还没理解的问题雇一个头衔漂亮的人，然后在四个月后发现问题其实是另一个。

和同行业的人聊聊，永远是对的。但别抄大公司的结构。公司变大后，会引入一批唯一职责是避免灾难的人：审批、复核、协调、过滤。这在千人大公司里是合理的，在一个八人项目里是毒药。

如果从第一天就照抄这个结构，你的团队会有相当一部分人在监督而不是产出。你不会赢得分辨率：你只会赢得会议。

人人都在谈最小可行产品，几乎没人谈最小可行团队。

规则是：第一版追求宽度，不是深度。一个部门一个人。不是两个人，不是一支小队，也不是一个带班子的负责人。每个已识别的问题配一个人，哪怕只达到你所需水平的七成。

听起来寒酸，确实寒酸。但这支首发阵容的目标不是交付完成的项目：而是发现缺口在哪里。用一个精简的团队跑完整个周期，接缝就露出来了：

有了这些，你就能在该加深的地方加深，而不是在你想象的地方。

整个框架里，这是你本周就能上手的工具。拿出部门清单，给每个部门贴上两个标签之一。

**稳妥区。**你掌握方法。不是说你做这个天下第一；而是说你清楚具体怎么做，并且能讲给别人听。在这里，扩张是钱的问题：加人或者加工具，产出就更多。可预测。

**研发。**你不掌握方法。不是时间不够，而是你的团队里还没人知道这问题怎么解。在这里，你不用钱扩张，用实验扩张。而且它需要你作为创始人亲自盯，没法委托。