專案管理實戰：不知道自己在做什麼時如何推進

一套應對不確定性的專案管理方法：用最小可行團隊快速行動，區分穩妥區與研發，用垂直切片交付完整成果，並告訴你何時該招募、何時該募資，而不是假裝計畫完備、盲目擴張團隊。

模糊的照片：為什麼 waterfall 和 agile 都不夠用

想像一張你的專案及其目標市場的照片。一開始它是模糊的：你能看到色塊，猜得出形狀，但看不清細節。你想開一家酸種麵包店，你知道有人願意為好麵包多付錢，但不知道有多少人、什麼時間買、你真正的問題會是烤箱還是配送。

這張模糊的照片就是你的起點，而且跳不過去。你唯一能做的是提升它的解析度，而解析度的提升只有一種方式：行動。你接待的每個客戶、談判的每個供應商、發布的每個版本，都會還給你以前沒有的像素。

兩個經典模型正是在這裡崩塌：

在一個技術、通路、連客戶行為都每個季度都在變的環境裡，這兩個假設都站不住。你需要別的東西：不是一份完整的計畫，而是一份和團隊同步獲得細部的低解析度計畫。

這是幾乎沒人說的一點，也是整個框架裡最有用的一點。

當你能精確畫出所需的組織架構圖時，你就知道自己贏得了解析度。不是任務清單。不是 roadmap。一張組織架構圖：有哪些職能、每個職能配幾個人、哪些內製、哪些按專案外聘、哪些用技術而不是用人來解決。

畫不出來之前，你還是模糊的。而模糊的時候，你不應該大量招人，也不應該啟動一輪大募資。

注意問題的轉變。它不再是「產品什麼時候做好？」，而是變成**「我什麼時候才能知道，把這件事做好需要一家什麼形狀的組織？」**。

拆解專案時，人們的本能是想到人：我需要一個設計師、一個業務、一個 community manager。這是順序錯誤。

先拆成部門。這裡給出那個改變一切的定義：

部門是一個問題，角色是一個學到的解法。

如果你開一家內容機構，「影片製作」不是一個職位：它是你要解決的一個問題。「獲客」是一個問題。「按時收款」是一個問題。角色是後來的事——等你把問題理解得足夠透徹，知道什麼類型的人能解決它。

把這兩件事搞混，就會為了一個你還沒理解的問題雇一個頭銜漂亮的人，然後在四個月後發現問題其實是另一個。

和同行業的人聊聊，永遠是對的。但別抄大公司的結構。公司變大後，會引入一批唯一職責是避免災難的人：審批、覆核、協調、過濾。這在千人大公司裡是合理的，在一個八人專案裡是毒藥。

如果從第一天就照抄這個結構，你的團隊會有相當一部分人在監督而不是產出。你不會贏得解析度：你只會贏得會議。

人人都在談最小可行產品，幾乎沒人談最小可行團隊。

規則是：第一版追求寬度，不是深度。一個部門一個人。不是兩個人，不是一支小隊，也不是一個帶班子的負責人。每個已識別的問題配一個人，哪怕只達到你所需水準的七成。

聽起來寒酸，確實寒酸。但這支先發陣容的目標不是交付完成的專案：而是發現缺口在哪裡。用一個精簡的團隊跑完整個循環，接縫就露出來了：

有了這些，你就能在該加深的地方加深，而不是在你想像的地方。

整個框架裡，這是你本週就能上手的工具。拿出部門清單，給每個部門貼上兩個標籤之一。

**穩妥區。**你掌握方法。不是說你做這個天下第一；而是說你清楚具體怎麼做，並且能講給別人聽。在這裡，擴張是錢的問題：加人或者加工具，產出就更多。可預測。

**研發。**你不掌握方法。不是時間不夠，而是你的團隊裡還沒人知道這問題怎麼解。在這裡，你不用錢擴張，用實驗擴張。而且它需要你作為創辦人親自盯，沒法委託。