最小可行性 - Tobie 偷偷

其實每一次在跟陪跑學員諮詢的時候，我都會覺得這是一個很不錯的經驗，可以讓我回頭看看自己過去是怎麼樣一路走來的。

昨天剛好在跟陪跑學員 A 諮詢的時候，就有聊到我平常是怎麼樣去拆解目標，以及那些任務是用哪些導向拆解出來的。

然後我就仔細地思考，其實我大部分針對某一個目標去拆解任務（譬如說這個 Q3 我要做到什麼事情）時，主要好像都是用到 WBS 的架構，加上我會搭配 MECE 的方式去思考，有沒有一些可能就是有包含、沒有遺漏的方式。

可是，這個完全是做在很全面、很完整的方案，就是我必須要去知道說，這些任務可能有哪些自己沒有被遺漏掉、需要做的事情。

但是說是這樣說，我後來也發現，其實我真正做的方式是：我想了一個目標，而在到這個目標中間，可能會有好幾個「最小可行」的步驟或節點，基本上完成它們就夠了，剩下的只是一些不影響大局的細節，我之後再慢慢去補。

我昨天跟諮詢的學員講到這件事情的時候，他蠻驚訝的，直說這是一個很好的方法。

這也讓我開始思考，發現自己過去一直以來的決策模式好像都是這樣。舉例來說，假設我要開線上課程，我會希望用最快的時間把它做出來，具體步驟如下：

這個我覺得是其中一個線上課程的路徑，當然，我有很多細節部分沒有設定得特別好，但基本上我的目標就是「賣出線上課程」這件事。我主要就是透過這四個節點，完成了之後，一個小小的框架就已經建立起來了。

那現在我自己在做一些 AI 的小產品，好像也是這樣：

第一個就是，我希望這個產品可以馬上幫我解決什麼樣子的問題。
那我中間就會是依照每一個節點，去看有沒有最小可行、真的可以做到的點。例如說：UI 要有一版草稿、UX 要有一版人家走過、可行的動線、電腦、手機版和平板的尺寸是要好理解、好操作的。這個產品是不是可以解決目標的幾個痛點？包括設計和這些功能等等、有沒有留下一個聯絡信箱？只要有問題的話，有人可以找到我。

把那幾個階段性的完成之後，對我來說，算是骨架就已經完成了。

仔細想想，我過去好像一直都是這樣做的。

這也讓我滿好奇，以前是不是有人特別提出過類似的想法，或者有跟我一樣的做法？我後來上網查了一下，才發現這種「先搭一個能動的骨架、細節之後再補」的做法，其實一堆人都講過，還各自取了名字。

先講「搭骨架」這件事：

行走骨架（Walking Skeleton）：Alistair Cockburn 在《Writing Effective Use Cases》(2000) 裡提的。先讓整條路從頭到尾跑通，每個環節都做到最薄、能動就好，之後再一段一段長肉。我前面說的「先列出最小、一定要先完成的節點」，其實就是在挑骨架。
Gall's Law：John Gall 在《Systemantics》(1975) 寫的。一個能運作的複雜系統，幾乎都是從一個能運作的簡單系統慢慢長出來的；想從零直接設計出一個很複雜的系統，通常不會動。這條剛好可以當我做法的靠山。
最小可行產品（MVP）：這個詞是 Frank Robinson 在 2001 年提的，後來 Eric Ries 在《精實創業》(2011) 講紅的，講的是用最少的力氣做出一個能驗證市場的版本，先丟出去看看。我做線上課、做那些 AI 小產品的流程，說穿了就是這個。

再來是「細節之後再補」這件事：

技術債（Technical Debt）：Ward Cunningham 在 1992 年提的。他原本的比喻就是：先出貨換速度，等於跟未來借錢，之後要還，拖越久利息越高。差別只在你是「知道自己欠了什麼」，還是「根本不知道」。我算是前者，前提是那筆債我記得住。
YAGNI（You Aren't Gonna Need It）：來自極限程式設計，Kent Beck 那群人在講的。意思是真的需要了再做，不要為了「以後搞不好會用到」先花力氣。這句話幾乎就是我「不影響大局的細節先放著」的白話版。

還有一個有趣的是，我一直掛在嘴邊的「滾動式調整」，原來也有正式的名字，叫滾動式規劃（Rolling Wave Planning）：近期的事規劃到細節，遠期的先抓個大方向，之後再慢慢補細。

最後是關於我這個人的：Satisficing（滿意即可），Herbert Simon 提出來的。找到「夠好」就收手，跟凡事要做到最好才肯動手（maximizing）是兩種很不一樣的決策風格。Simon 後來還因為這一系列的決策研究拿了諾貝爾經濟學獎。

所以我覺得蠻有趣的就是，我一直憑感覺在做的事，原來早就有人認真想過、還一個一個取了名字。

也許在快速的時代可以做到滾動式的調整，並用一個最簡單的骨架去做到我要的事情，是很不錯的適應能力。而有這些人過去提出的理論支持，也讓我更加安心地去做這些事情：）

不曉得你會不會也是一個就是建好小小骨架的人，就直接勇往直衝的人？