在之前的文章中，我曾介紹我們公司的一些資訊和創業歷程，在 17 年到 21 年之間，我們的商業模式也歷經了許多修正調整；作為團隊的決策核心，我也不斷的學習與精進。

幸運的是，在我的同溫層中，有許多優秀的創業前輩與朋友，這讓我能輕易向他們取經。從 16 年開始籌備創業項目時候，我開始積極與新創圈的團隊接觸，藉此了解創業者真實的想法與思維。在相互學習的過程之中，我也開始進修一些創業課程，並模仿創業家的思考方式。這中間當然也探索了許多商業模型工具的應用。

一次透過朋友的介紹，我認識了 iiiNNo 的 David。

iiiNNO 是台灣的新創育成中心及加速器，創辦人 David 算是加拿大的老鄉，還是財富自由的那種（哈），但這絲毫沒有阻攔他對創業教育的熱忱；回台灣後，他毅然投入了台灣新創的教育。

我幾乎每隔幾年，就會到 iiiNNo 取經；最近的一次，則是 20 年底。

這次的課程是由 David 本人親自主講，內容則主要圍繞 Agile，雖然進社會多年，但我曾經用過的商業工具 (framework)，主要也就是三種，也可能是最常見的三種，分別是：Waterfall、Agile 和 Lean。

隨著數據時代的日新月異，乃至資本創造的加成效果，新世代的企業領導者，必須根據目標任務與團隊屬性，在不同的情境，選擇使用不同的工具方法。近十年的歷練中，我多數時候作為一名專案經理人行動；在學期間，雖然唸過一、兩年的電腦，但最終還是投入了商學領域。這導致主流的商業工具，我都還算略有耳聞。

當然，在落實和使用上，又是另外一件事了。

下面的文章，將簡單介紹上述的三種工具；除了給出說明和定義，也會加註一些我個人的見解，並與大家分享我在創業上，真實應用的工作情境。

Waterfall 流水線

Waterfall（流水線）應該是歷史最悠久的一套工作方法，最早設計給製造產業使用，也是目前最廣泛應用的方法。Waterfall 使用起來非常的簡單明確，屬於方便追朔的一套線性架構。

Wafterfall 的出現是為了符合工業時代的發展背景。當大量生產的「目的」被明確定義，生產端開始著手規劃符合產品所需的材料、工具、人力，同時完善符合一切工藝流程的作業標準流程（ S.O.P.），以便按部就班的進行生產。

每個生產環節在 Waterfall 中有明確的排程、檢查點與規格，這樣的好處顯而易見：簡單（S.O.P.）、明確（定義清晰）、可追朔（有明確的規範）的線性（時間）管理。

但 Waterfall 在運作前，將有繁瑣浩大的規劃工程，比如定義工作的範圍，定義合理的執行動作與追朔時間的確切截點。等萬事備妥，Waterfall 將如其名般，似流水的運行輪轉。

Waterfall 因為線性的特徵，在後續的管理上，將十分單純與便利；而 Waterfall 的缺點，卻也展現在線性的特徵之上。

單一方向的線性流程，對於任何非預期的變因，都要付出昂貴的調適成本。當前段的錯誤未能即時被偵測，後續的影響一句話來說，就是差之毫釐，失之千里。比如汽車生產中的零件公差，可能造成組裝後的失控風險，若錯誤上市後才被發現，車輛招回的成本和品牌商譽的損失，會是企業可怕的災難。

一般認為在數位時代中，少量多樣的生產趨勢將讓 Waterfall 逐漸走下神壇，被電子、軟體等高速運轉的產業所拋棄，但事實上仍有高達 56% IT 專案，依然持續使用 Waterfall 的方式執行專案工作。

在我看來，Waterfall 或許真的有一天會退出主流， 但在之前的工作經驗中，Waterfall 一直是非常實用的管理工具。

其實 Waterfall 對於變動不大或相對單純的工作，往往能起到很好的效果。從大量生產與追求效率的面向來看，Waterfall 是非常優秀的商業工具，特別是當組織規模大到一定程度， Waterfall 會因其管理的便捷性與直觀的執行率，成為大企業當然的選擇之一。

我進入社會第一份的工作是外銷業務，當時主要負責歐美客戶的 account，工作內容則是客戶與工廠間的聯繫橋樑，其業務流程大致如下：

1. 參展
2. 取得海外採購窗口的接洽
3. 報價與樣品寄送
4. 客戶下單訂購
5. 安排生產（或庫存出貨）。

而訂單簡單來說就是三件事：品質、價格與交期。

確切的來說，品質就是規格，規格將影響到價格，價格在某種程度上，也決定了交期。Waterfall 在品質與價格確定後，就開始發揮簡單而強大的能耐；專案人員這時需要執行的，不過是根據預測的排程，反覆確認並跟催一切可能超時或交不出貨的風險。

Waterfall 或許是枯燥和單純的，操作人員具有高取代性，誰都可以做得不錯；但對於人員的素質要求不高，也是其優點所在，而高度重複的工作，也幾乎都會透過 Waterfall 的方式管理。大公司也因此多數採用 Waterfall 的管理方法。

最後，小結一下 Waterfall 的優缺點與合適的使用情境：

優點：

1. 客戶將明確知道價格與交期，並有可預期的品質與規範。
2. 有明確的文件流，存在一站站間的自我防呆機制。（Project Management 的主要工作是監督每一個工作站）
3. 工作範圍在執行前已定義清楚，成本和預算是可衡量的狀態。

缺點：

1. 前置的工作量繁瑣龐大，若方向和規範定義錯誤，會造成巨大的損失。
2. 錯誤未必能在每一個工作站被發現和防堵，比如第 2 站出現的錯誤，可能在第 12 站才被偵查的異常。這導致中間過渡的 10 個工作站，都有重工的損失。

使用情境：

由上面的優缺點分析，我們總結適合 Waterfall 的使用環境，通常有幾個特點 ：

1. 正確性是最重要的考量（比如銀行系統），而且時間沒有迫切性。
2. 專案的工作流程相對較短或單純。
3. 執行團隊的成員水平可能存在落差。

個人創業分享：

作為一個專案經理人，Waterfall 無論在創業前後，都是我經常使用的商業工具。

放在我自己創業的咖啡公司來說，由於一切的基礎系統源自於前公司的 DNA，舉凡採購、生產與財務流程，都講求 a. 正確性 b. 嚴謹性 與 c. 重複性。因此，我認為 Waterfall 仍是最適任的管理工具。

在生產這件事來說，Wafterfall 的機制，協助我們公司在品質上的穩定性，也讓接單後的生產排程，有明確的節奏感。事實上，無論在製造業或科技產業中，Waterfall 在規模化的市場，有其必要性的存在。

特別愈是巨大的系統與機構，若過多的追求敏捷與靈動，某種程度必會喪失其嚴謹性與稽核功能，比如銀行的系統或公家的機構，一定更加適合與需要 Wafterfall 的管理機制；因為在這些特定產業中，其風險所需承擔的成本，是難以想像的昂貴。

Agile 敏捷式

Agile 是去年 David 課程學習的重點，也是近年新創圈和軟體開發主流的模式，在 SaaS 與資訊相關的專案中，Agile 也經常被提及。

Agile 一詞最來自 2001 年初，是一群軟體大神在滑雪聚會中，茶餘飯後所訂定出的一個宣言。這份宣言包含了 4 個關鍵價值觀與 12 個工作原則，最終的願景是發掘更優良的軟體開發方法。Agile 的出現，是根據軟體產業的實際狀況，並在 Waterfall 不適用基礎上，提出的改良調整與解決辦法。

我們在正式談論 Agile 前，應該定義清楚： Agile 屬於一種原則和精神。很多人可能都知道 Scrum，但 Agile 和 Scrum 的關係，更像概念原則和執行細節，是一種承先啟後卻又密不可分的存在。

Agile 的中文翻譯是「敏捷」，但這其實有失偏頗，容易令人對之產生誤解，以為 Agile 類型的組織，只追求極致效率的高速開發。事實上，Agile 更貼切翻譯可能會是：願意隨時根據市場變動、進行快速調整的靈活組織。

Agile 是一套開發管理的內功心法，是抽象與概念的；前述的 Scrum，則是基於 Agile 的原則與理念，所訂定出來的一套流程和 Process（外功）。讓我們來看看 Agile 宣言的原文：

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

個人與互動 重於 流程與工具

可用的軟體 重於 詳盡的文件

與客戶合作 重於 合約協商

回應變化 重於 遵循計劃

source: http://agilemanifesto.org/

原文中我們了解到， Agile 所重視的，是「個人」與「互動」。

「個人」在這裡指的，除了獨立思考的每個專案成員，更泛指專案相關的全體利害關係人 ( Stakeholder)，如專案負責人、工程師、客戶、潛在用戶等。這群利害關係人必須定期互動，透過大量的「溝通」與「情報交換」，打造符合目前市場變化的、「可用性」產品。

這與單一方向、線性架構的 Waterfall 有極大的區別。

實務上來說，台灣許多企業受日式文化薰陶，格外重視流程的嚴謹性與文件流的簽呈，專案管理人也被要求嚴格遵守紀律，嚴格執行最初制定的計畫流程。在 Waterfall 的思維中，很多資訊因此不被允許透漏給客戶，避免不必要的干擾，造成開發時間上的耽誤。

這與「擁抱改變」的 Agile 精神，有根本上的差異。

我們再來看看 Agile Manifesto 背後的 12 個原則 (Principles behind the Agile Manifesto)：

We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

我們最優先的任務，
是透過及早並持續地交付有價值的軟體
來滿足客戶需求。

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

竭誠歡迎改變需求，甚至已處開發後期亦然。
敏捷流程掌控變更，以維護客戶的競爭優勢。

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

經常交付可用的軟體，
頻率可以從數週到數個月，
以較短時間間隔為佳。

Business people and developers must work
together daily throughout the project.

業務人員與開發者
必須在專案全程中天天一起工作。

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

以積極的個人來建構專案，
給予他們所需的環境與支援，
並信任他們可以完成工作。

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

面對面的溝通
是傳遞資訊給開發團隊及團隊成員之間
效率最高且效果最佳的方法。

Working software is the primary measure of progress.

可用的軟體是最主要的進度量測方法。

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

敏捷程序提倡可持續的開發。
贊助者、開發者及使用者應當能不斷地維持穩定的步調。

Continuous attention to technical excellence
and good design enhances agility.

持續追求優越的技術與優良的設計，
以強化敏捷性。

Simplicity–the art of maximizing the amount
of work not done–is essential.

精簡──或最大化未完成工作量之技藝──是不可或缺的。

The best architectures, requirements, and designs
emerge from self-organizing teams.

最佳的架構、需求與設計皆來自於
能自我組織的團隊。

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behaviour accordingly.

團隊定期自省如何更有效率，
並據之適當地調整與修正自己的行為。

source: http://agilemanifesto.org/

閱讀後我們可以抓到幾個重點：

1. 兵貴神速：遠水救不了近火，快速進入市場將取得些微的領先者優勢，並有助於成為最早替前期用戶提供解決辦法的廠商。
2. 且戰且走：深謀遠慮在 Agile 的思維中，遠不如以戰養戰，更能貼近市場與變化。數位時代的日新月異，讓開發一個 100 分的產品，還要在正確的時間推出，變得異常困難；70 分的半成品適時切入市場，將變得更為重要。
3. 擁抱改變：今日的成功可能是明日的失敗。過往的成功經驗可用，但不能一昧的從過去取經，保持開放的姿態，將有助於開發者學習成長，符合市場快速的動盪與變化。
4. 換位思考：商場如戰場，客戶與你已經不完全是買賣關係，開發者與客戶會更像戰友。客戶是最貼近市場的人，客戶與你將攜手面對市場，這個最為強大的挑戰。
5. 共同參與：在 Agile 思維中，開發是全體利害關係人的工作；專案經理人、工程師與使用者，在 Agile 的前提下，應該定期聚會（Sprint），每個人都親身理解開發過程的推演。
6. 個人本位：開發中每一位參與者，都有百分之百的發言權，是平等的地位。
7. 自我組織：奉行 Agile 思維的組織，在定期（可能是周或月）的聚會中，需要有自我成長與調整的能力。

上述的 1 – 4 點，還可以說是 Agile 的一種態度；但 5 -7 的三個點，就是在探討 Agile 團隊的底氣了。

對於想發展 Agile 的組織來說，團隊成員的素質，先天就有極大的侷限性，因為每個 Agile 的利害關係人，都需要提供寶貴的回饋，所以他們注定是某個領域的專家或菁英份子。 事實上，David 在課堂上也不只一次提到：「不想追求卓越的團隊，Agile 將不是最理想的模式」。

當然， Agile 的框架背後，還有許多衍生的概念與細節，比如 Scrum 中的 Sprint（衝刺，指定期會議、回報與調整） 的安排和 throughout （吞吐量，指工作量與優先順序）的計算；若之後有機會，也可以再寫一篇文章，仔細與大家分享。

最後，小結一下 Agile 的優缺點與合適的使用情境：

優點：

1. 不同工作階段若有發現錯誤，能即時偵測，不會等到最終階段才被發現。
2. 定期的溝通討論，開發中可隨時調整；若市場出現新的技術，也能加以應用。

缺點：

最終的產品因為及時的調整，可能與最初投資人的構想，完全不同。

使用情境：

1. 「最適速度」比「完美品質」更為重要的產業，比如 3C 產品。
2. 產業或市場的規範，可能隨時產生變動，比如稅務、法條。

個人創業分享：

總結來說，Agile 的核心價值在於讓產品與服務，盡可能貼近市場「眼下的需求」，並以此前提，透過全體利害關係人的意見參與，開放高度調整的彈性 (flexibility)。

我們在創業的初期產品，曾苦於對咖啡市場的偏好掌控力不足，經過多次內部的會議與溝通後，我們決定免費提供開發中的公關品，並海放問卷到市場當中，藉此打開局面。根據問卷回填的信息，我們將產品最終切割成小型的市場模組，並作出不同的產品定位與社群區隔。

現今我們的主力產品已經轉為辦公室咖啡的訂閱方案，因此我們每個月都有機會與企業客戶近距離的溝通與接觸。會面時，我們將與客戶討論產品是否有需要調整之處，作為科學烘焙的信奉者，我們完全有能力根據客戶的回饋，進行烘焙曲線的快速調整，打造後續符合期待的訂製商品。

用 Agile 的語言來說，每次與客戶的會面，就是 Sprint 的環節，頻率則是一個月一次；若客戶提出意見，在後續的配貨當中，我們將加贈一包公關樣品 (working sample)，讓客戶做風味的品鑑參考。

這種做法的好處，是客戶始終能得到完全符合偏好的咖啡；缺點則是最後的風味呈現，往往與最初的預想 (專業咖啡師的偏好) 不全然相同。比如客戶建議調整的烘焙方向，通常是將咖啡烘焙的更深，這在第三波精品咖啡的思維中，反而是逆勢而行的。 (現今的精品咖啡多數以淺焙為主）

而正因為高度的彈性與 user-based ，我們在產品供應上，有較為昂貴的溝通成本與頻繁的試喝會議，這是與同業相比，我們不可避免的 Trade-offs。

Lean 精實創業

「用最低的成本完成產品，用最快的速度進入市場。」這是Lean 的核心概念。

簡單來說，Lean 的宗旨是減少不必要的時間、金錢投入，並創造一個最小可行性商品，我們稱之為：MVP ( Minimum Viable Product ）。透過創造 MVP ，Lean 的產品或服務，只聚焦在必要的功能上；這個 MVP，也將投放到市場實際運作，故除了增進開發效率，MVP 也確保了用戶得到必要的使用功能。

但 MVP 中提到的「最低成本」只是一個相對的概念；在特定產業中，創造一個 MVP，可能是上百萬到千萬的投入，比如電動車。MVP 的另一層目的，在於快速吸收市場的信息回饋，並著手進行調整。

通常 MVP 的執行階段，更著重的並非客戶文字或言語的回饋，而是實際貼近消費行為的觀察與反思；這是因為很多 MVP 在被創造出來的時候，用戶甚至還沒有具體的消費習慣和思維。

在市場給出回饋後，客戶應該要能無感取得 MVP 的優化升級；這一點在培養後續的用戶忠誠度上顯得十分重要；如何進行後續的優化實踐，並保有同等或更多的利潤收入，是 Lean 極其重要的思考，也是商業模型的一環，比如 Office 365 跟過往的 Office 軟體相比，就是一個讓用戶能享受無痛更新的案例。

而 Lean 相較 Agile 和 Waterfall 在使用情境上，也有非常大的差異。

後兩者的探討階段，可能還處於研究或偵錯的開發環境，但 Lean 已經實際切入市場，並期待有明確的獲利模式與商業模型；我們甚至可以不誇張地說，在正常情況下，一個持續獲利的 MVP，就已經足以成立一個獨自營運的事業體了。

而「目標市場」與「付費用戶」的設定，在 Lean 中不只重要，更是必要：客戶為什麼要買單 (Why)？在哪裡產生消費行為 (Where)？競爭對手是誰 (Who)？這些問題在 Lean 的前提之下，團隊應該有明確而統一的答案。

最後分析一下 Lean 的優缺點與使用情境：

優點 ：

1. 能以最低的資源與成本，打造可行性商品，藉此避免未來更大的損失。
2. Lean 的思維能幫助企業快速聚焦在小規模與簡單的商品上，降低攏長的規劃期。

缺點：

1. 參與的成員都要聚焦每個流程，無法採取專業專才的分工。
2. MVP 的未來發展與延續性，在這個時期無法被驗證。

使用情境：

Lean 一般適合較小的專案。大型的專案通常涉及過多的團隊與專業人士參與，成本過高，無法符合成本最低的定義。

個人創業分享：

在我的創業歷練上，無論是 Lean、Agile 還是 Waterfall，都在不同的階段對我發生關鍵性的影響。

在生產、財務和採購上，我們公司大多採用 Waterfall 的模式，藉此確保工作的嚴謹性與可稽核性；在團隊建構與客戶溝通上，我們奉行的是 Agile 原則，藉此確保內部溝通的順暢與貼近市場。而 Lean 則在最早選定創業項目時，對我們起到關鍵的作用。（詳見創業筆記#0)

所以無論是何種工具，不外乎結構、計畫與流程控制；在了解個別優缺點與使用情境後，每個人都能找到，當下最合適的工作模型了。