之前在上幾梯實作班的時候，很多同學對於 NPS 的下一個衍生問題是：如果問卷回覆率低，NPS 的準確性如何？
這個問題我本來也沒有好解法。不過最近我在持續鑽研的過程中，找到一本專門在研究 NPS 議題的好書：The Ultimate Question 2.0。裡面給了這個問題的解決法。
他們實際對幾個公司量測過 non-responder 的行為後，找出了修正公式。
修正公式是：這些沒有回覆問卷的人，10% 是推薦者，40% 中立，50 % 反推薦。
原始 NPS 是 50，只有 20% 回覆問卷
加上修正公式後， NPS 是 -22。
修正公式：
所以修正公式會是
原始 NPS * 繳交問卷率 + -40 * 沒有交問卷率。
以上圖的例子會是 50* 0.2 + (-40 * 0.8) = - 22
延伸閱讀
最近有幾封來信，希望我提供一下 Growth Hacker 適合的人選標準經驗。就我個人的經驗，以及與其他人交流的經驗。
我會把我的回答拆層兩種層面看，一個是技能 Stack，一個是人格特質：
技能 Stack
一般來說，最棒的當然是挖現有 Growth 團隊的成員，這樣最快。很可惜台灣不可能有 Team 可以挖。所以在台灣，只能找到適合的人自己養。
就技能方面，我推薦背景有這樣基礎
Read on →這篇要講的是 Growth 最重要的基礎在於 Retention。
Retention 強後，你就有基礎的財源，有了更好的 LTV ( Lifetime Value)，有更多資源可以去做更強的 Acquisition。更容易做 Referral。
這個道理很簡單直觀。好像有講等於沒講。
盲區一：沒有人想要「改善舊功能」，但是「成長」多是基於改善舊功能
但是為什麼就算很多人知道了，還是做不到。這歸咎在於在大部分的網路公司，在業務擴張的規則底下，人性對於業務提振的方向還是
- 開發更多產品新功能
- 開發更多產品新功能
- 開發更多產品新功能
別誤會。
開發更多產品新功能不是不好。而是開發產品新功能並不保證「會」成長。
Read on →這篇文是接著羅胖的跨年演講結論寫的衍生。這裏有部分的演講筆記。而羅胖本人正版全演講稿在 Amazon 上有售 。
至於全長的四小時，正式影片在下週會在優酷與 Youtube 放送。
先寫結論： 2016 你該「創業」或「學寫程式」
我的文章正文一向很長，按照慣例還是會先寫結論：
- 2015 是個 Game Changing 年。
- 2016 開始你可以有明確兩個方向：
（1）如果你是個手藝人，2016 你可以勇敢創業做個小生意，接下來世界會是你的。
（2）如果你只是個覺得上班很無聊的文員，2016 年拿到的年終，你可以去報三種班 Android， iOS ，Rails。三門裡面至少學其中一門手藝。（為什麼是這三個，這是另外一篇原因了，為了不岔提，容後再敘）世界也會是你的。
這次的專案管理班 有一個 QA，我覺得很有趣，拿出來分享：
「在規模較大的前公司上班時，使用簡單的甘特圖和每週檢討，使用硬性規定每個人應該達到自己預期規劃的進度，就可以動員整個team把應該完成的工作在上司交代的deadline前提早做完；現在自己開小公司，反而導入scrum、每天畫burndown chart、每天檢討居然還沒有辦法掌握得更好，反而覺得好像更沒效率~大家事情沒有做完就推說自己預估不準，下次再改進就好...然後就越拖越慢..」
我的回答是：中型公司以上適合專案管理。創業公司千萬不能專案管理。
我想這個回答，政治非常不正確。我想 RD 出身的人甚至都會為這個回答震驚。
先不要急著嗆我。你先自行創業一次，用自己的錢 + 專案管理規劃全新的 project，獲得大成功（月入一千萬）。我會誠摯的跟您認錯是我無知。
專業經理人對專案管理的錯覺
第一次創業的人，特別是 execs 出身的人，常常會有一個既定印象的錯誤推斷。
專案混亂 => 經過專案管理 => 順利產出 => 成功。所以，會推出一個結論：凡是經過好的「專案管理」規劃的 project 必定會成功。
我認為這件事其實放在創業公司的起步專案上，甚至是大錯特錯的事，甚至是你退到底限，只寫 user story 進行規劃還是不會達成目標的。
「短視」才是 Startup 常態
我在此有一個大膽建議假設：
- startup 所有的 project 都只能短視。
- 一個月只能有一個很模糊的大目標。
- 想的方案要是在本週五不能 deliver 就是垃圾。
- 沒有所謂 user story ，只有所謂 solution for user。
為什麼呢？
這就牽涉到一般有專案管理「需求」的公司，一般來說通常已經是 PMF 以上的公司了，所以公司養了很多人，所以才有管理專案的需求。
- 產品已經定型
- 已經確定要做的專案目標是什麼（大多是改善）
所以你已經有明確的 input 與 output ，所以這件事才能透過專案管理加速。
但創業不是這樣。你不會有明確的 input。你甚至不知道什麼東西會賣。你只有不斷的試，不斷的調整。所以你永遠不會有清晰的 scope，永遠不會有清晰的 deadline。
只有三天內生出 solution，否則客戶走人。要說什麼風險管理，資源管理，這些都是屁。你甚至沒辦法透過 user story 去解構客戶行為。
既有 PMF 的公司，客戶的臉很明確。沒到 PMF 的公司，客戶的臉大概有幾十張不同的類型。
你只能這樣一直土法煉鋼，煉到你的產品定型，這時候才能開始講所謂的專案管理。
在此之前，你只能用「專案協作」技巧，讓團隊節奏不要被打亂。用「專案協作」技巧，把複雜不能 scale 的事，拆到可以勉強依序執行。
startup 的世界與 PMF 的世界截然不同。startup 也不能透過專案管理技巧通向 PMF。只有 growth 技巧才能帶你走向 PMF。
我想這也是為什麼雖然我的專案管理技巧超強，強到甚至我想通了這層道理。卻選擇把專案管理課毅然決然的關掉的原因。。。。。。。。
這技能已經變成我上輩子的技能。這就是大概笑來所說的：所謂的七年就是一輩子吧。
====
延伸閱讀：https://www.facebook.com/joe.wang.376/posts/10208247441972002 （看到有朋友轉文時得精彩衍伸）
這一篇題目，我想一口氣回答三個常見問題。
- Growth Hack 是鼓勵追求差異化嗎？
- 如果 Growth Hack像美國那樣被玩得很徹底，下個階段變成怎樣？會不會失效了？
- 兩個類似的商品都用這個手法行銷，如何一分高下？
首先，我想解釋為什麼「行銷手法」會被一般從業者認為「成熟後會有失效問題」的原因。
為什麼大家覺得「行銷」是「通靈術」？
如果讀者從未接觸過 Growth Hack，對於行銷的想像，往往會只停留在「Acquisition -> Activation」層次，也就是「大量曝光，然後用戶轉換」。
Acquisition 沒有不好。當你的 Funnel 轉換率很好時，這是最好的手段。因為 Channel 像是超大海洋一樣，引一下就有現成的水可以用。
所以很多朋友做行銷，直覺想到的就是「曝光曝光曝光」。但令人傷心的是，其實絕大多數人的產品，Funnel 轉換率都低到不可思議。而且在外部 Channel 上曝光，還會遇到實際上的幾個挑戰，這幾個挑戰就是造成你覺得行銷是「通靈術」的根本原因。
5 C of Channel Decay
Read on →這一部分講的是如何怎麼畫產品與 Growth 的 Roadmap。
一個 Project 有百百個功能，究竟怎樣排優先權。其實這也有系統性手段，這是我前一陣子從 Andrew Chen 與 Brian Balfour 開的課學到的，真是讓我大開眼界，這篇是我的上課筆記：
Step 1: 將功能分成：產品組 / 成長組
首先你應該把所有產品功能分成兩組，產品功能組與成長組。這兩組的差別主要在於「能不能促進指數型成長」。
比如說「產品組」類型的功能：
Read on →一般產品團隊，在要導入 Growth Hack 進產品團隊時，最常遇到的問題是：
- Growth Hack 的原理與基礎究竟是什麼？ ( 可上 Intro to Growth Hack 心法班 )
- Growth Hack 的基礎建設有哪些？
- 我們的產品目前有哪些基本功基本服務沒有安裝？Why it matters? ( 可上 Intro to Growth Hack 實作班 )
- Landing Page
- Onboarding
- Measuring
- Customer Support
- NPS
- Referral
當基本設施建好後，內部後續最大的問題是：
Read on →坦白說，這個標題若照 Growth Hack 的定義，有點誤用。因為若照矽谷的建議來說，Growth Hack 的 tunning 是建議 Product Market Fit 之後才進行。（ 這個原因是因為 Growth Hack 屬於 Marketing 範圍的一種，而且是創意的 Marketing。實作需要大量資源。而且沒進入 PMF 的話， Funnel 漏水率太兇）。
所以比較正確的標題應該是：「如何用 Growth Hack 中使用的技術工具，將自己半死不活的 MVP 產品推破 Product Market Fit 的下限」。不過顯然這樣「政治正確」的下標法，沒有人要看。所以我還是沿用原標題好了 XD
每月在舉辦 Intro to Growth Hack 講座 傳授「Growth Hack 心法」的緣故。我有時候會收到聽眾事前一些相當精彩的問題，發現大家困擾其實都長的差不多。
這一次因為收到一個「典型技術開發者」的問題，我覺得相當適合整理成具體的 FAQ，因此取得提問者的同意，把產品細節馬賽克之後放上來。
（因為這個問題的相同變形實在出現太多次了，包括我以前也有這樣的困擾）
常見案例：乏人問津的 MVP 屍體
我是個＊＊＊＊，平時喜歡開發一些有趣的網站專案。但是常常發生寫的時候覺得這東西很有趣，把pototype服務丟出來後，發現沒有什麼使用者要用的窘境。
舉例來說，我最近寫了一個服務叫做＊＊＊＊，他可以建＊＊＊＊。一開始決定開發時都討論的很熱烈，幾個朋友都覺得很有趣。但當我實際寫一個把測試版的服務丟出去後，卻發現沒有多少使用者註冊或給予回饋，讓我只能猜測到底怎樣改善才會有人願意使用，但我又不太願意亂猜測亂加功能，因為根據過往經驗這都是很沒系統的try error，因此專案往往就這樣停掉，硬碟塞滿了各種沒下文的專案屍體。
另一個想學的是如何找出客戶care的點，將自己的服務充滿信心的推廣給別人，我目前正在做一個比較偏硬體的專案，目標是透過機器＊＊＊＊，降低工讀生的人力需求，目前還在開發prototype的階段，預計再幾個月就會完成原型，送入合作的店家進行測試，我想要知道的是，因為硬體開發比軟體開發更耗時，而且價格更貴（數十萬），要修改更麻煩（＊＊＊＊就要一個半月），更不可能用try error的方式看客戶想不想要，有什麼系統化的方法可以問早期顧客正確的問題並早出真正的需求，再來充滿信心的推銷給別人。
具體救回 MVP 專案
Step 1: 裝上線上即時問答工具
建議工具：Zopim、Olark、Intercom
每當我建議別人安裝網站上的「線上即時問答工具」時，很多開發者內心是抗拒的。原因是：「我沒有辦法一直掛在線上回答問題」，所以抗拒安裝。
但你可能不知道的是，線上即時問答工具：
1) 許多使用工具的商家，其實也沒有時常在在線上。
2) 使用即時問答工具留下問題的顧客，轉換率非常非常的高（以我自己銷售課程的例子，大概轉換率超過 80%。我本人在線上的時候，轉換率是 100% ）。
線上即時問答工具，很像是降低客戶心理門檻，輕易送出需求的一個方式。寫一封信到 support@yourcompany.com 心理門檻是很高的。但是私密留言門檻是很低的。
我喜歡舉一個例子：傳統我們到體育用品店買球褲時，如果店員招呼我們不殷勤或甚至看不到店員，可能自己四處晃晃就走了。但是如果有一個店員，能夠即時回答你的問題，並且幫你快速找到適合風格的服飾，調貨。你可能不小心手滑就會買了很多運動商品回家。
線上服務正是有這樣的問題，消費者上網站，沒有店員能夠在心裡容忍的時間界線（約一天內）解答他的疑惑，所以這個銷售機會就 Churn 掉了。
你的朋友可能可以到 Facebook 即時找到你，但陌生人沒有辦法。所以即時線上工具，是讓陌生用戶跟你接觸的第一步。
很多人不使用你的服務不是你的產品不好，而是跟他的期望有一點落差。而他們會透過「詢問」透露出他真正的需求，你可以用這個方式逐漸逼到客戶的痛點。
Step 2: 安裝數據量測工具
建議工具：Mixpanel、Amplitude
第二件事，就是裝上量測工具。監測關鍵 Funnel。
什麼是關鍵 Funnel？首先你要釐清：你的用戶是不活躍還是註冊率低。不活躍是因為沒有解決他們的需求，還是學習成本太高？
而第一個步驟，就是找出產品核心使用行為。
假設你的服務是線上記帳軟體。但是使用者登入後，登錄了三筆帳單後，卻不再使用。或者是經營專案管理系統，但是使用者開了一個項目之後，填了幾筆 task，卻沒有再繼續使用。
所以關鍵動作是要找出「為什麼」「流失」。
使用這些工具，追蹤使用者關鍵行為的「轉換率」。如果他沒有完成你預期的動作，請寫信問他為什麼？
寫信成本並不會很高。因為這些數據工具都有 Trigger 可以使用。你可以設定「使用者註冊後三天內沒有完成某某動作」，或「開啟某某專案後」沒有進行下一步，自動寄信給使用者問他你有什麼可以幫忙的地方。
這樣可以有效得找到開發者當初設計的盲點，可能你自認自己的 UX 很棒，但對使用者來說可能困難重重，毫無頭緒。
利用這個手法，開發者可以具體的找到這些「操作上的 BUG」修掉。
Step 3: 撰寫 Landing Page
建議工具：Unbounce、Launchrock
我在演講時，常常反覆跟聽眾強調 Landing Page 的重要性。因為在歐美，製作一個產品或推出一個服務，Landing Page 幾乎是必備款。但在台灣，很多人僅僅視為 Landing Page 是一種「產品首頁設計 style」，是「選擇性的東西」。
「選擇性不設計 Landing Page」的產品，大概佔 70% 以上吧。這就是為什麼很多產品轉換率差到爆炸的原因。
你應該同意開一間餐廳要設計招牌和設計菜單。但為何推出一個線上服務，開發者卻覺得幫你的服務掛上一個招牌，以及介紹說明「不是一件必要的事」？
在這裡必須要說明：「首頁」有「內容」。不代表「有招牌」。
Landing Page 就像是「招牌」。而且 Landing Page 有具體的格式。協助使用者消除疑慮，增強信心，並且 CALL TO ACTION。
Step 4: 設計 Check-in Message，設計 Onboarding 流程
建議工具：Drip、Intercom
Check-in Message 是持續「教育」使用者的一環。使用者剛註冊，未必能馬上理解你的服務能夠 offer 的價值。或者需要很大的精力才能搞懂如何使用你的服務。這時候是 Churn rate 很高的時期。
如果你注意觀察，一些 SaaS 的服務，在使用者註冊之後，會每天寄出一封 tips，教使用者如何使用這個軟體。並且使用進度以及有無卡關。
Growth 通篇談的就是增進 Conversion，降低 Churn。
這就是降低 Churn，增進 Conversion 的一大好招。就像士林夜市水果攤，推銷陸客總先讓他先試吃一塊，然後跟他介紹這水果有多威，結果陸客就只好被迫買單....
Step 5 : 不要沈迷使用 Growth 工具，反覆利用以上提到的工具，持續修正產品
寫到這裡，很多人應該會問，為什麼我沒有繼續介紹下去。講 A/B Testing、Referral 的那一些密技。原因是：不需要。
在 MVP 到 PMF 階段，最重要的是將 Activitaion Rate 與 Retention Rate 衝高。
Referral 必須在產品有高滿意度實作才有效果。A/B Testing 則是太花時間。當顧客跟你說有需求，而且這個需求一直重複被不同顧客提出來時，這是一個直球訊號，你不應該婆婆媽媽的在那裡 A/B Testing，而是應該直接做給他。不要花費太多時間在設定變化球的轉彎係數上。
很多開發者在剛接觸 Growth Hack 議題時，常常會沈迷於上網找尋及安裝一百個 Growth Hack 技巧。這是大量浪費時間且很容易迷路的行為。
最常出現的情形是：當你開始操作這些 Growth 工具時，上網找尋 Growth Hack 密技，在網路上開始找尋相關資訊時，你會驚訝的發現，上網搜尋到的結果不會是找不到增進轉換率技巧（100招），而是找到太多轉換率技巧（10萬招）。這也是我一開始回來台灣後，教 GrowthHack 只教心法，目的正是為了教大家「正確辨認判斷篩選」「適合你現階段的轉換率技巧」。
一般而言，如果想讓產品開始起飛要逼近 PMF，只用以上四招反覆修正，就能夠讓產品快速靠近。
具體前進 PMF
我必須很坦白的說，有 MVP 並不代表可以前進到 PMF。上面的招數是假設你的「開發方向」正確。我在我的另外一個部落格寫過一篇文章：如何挑選正確的創業題目？提到：「正確」的創業題目，其實應該滿足兩個要件其中之一
a) 創業要找你已經非常熟的技能作為題目
b) 或創業要找你周遭非常「高需求」的題目
這兩種題目才能讓你快速前進市場。(a)題目你很明確地知道產業「精確」需求，以及很快能夠製作改善產品 (b) 市場有 high demand，你能夠快速取得用戶，根據用戶 feedback 並搶佔市場獲取利潤。
還有一個重要的關鍵是：做這件事情能夠對用戶貢獻的價值。
這篇文章前面提到的案例是，想開發一台機器，降低工讀生的人力需求。首先我覺得開發者應該去調查出的是：這是一個真需求還是假需求。當然，降低人力成本是一個「顯然賣點」。
但市場未必是這樣看待，如果是開一間餐飲店，工讀生未必是最大成本，照台北的房價來說，店租可能才是最大成本，而這個成本可能遠勝於工讀生人力支出成本。如果這一行都是這樣的狀況，那麼去改善工讀生成本，未必有太大的價值。
如果工讀生人力成本顯然是這個行業最大的成本，這個產品才有被開發下去的價值。後續的第二個衍生問題：引入該機器，是否可以瞬間大量降低工讀生人力成本？
如果不是。那麼開發這個機器也有大量的風險在。
開發者的迷思
純技術開發者常見的迷思是：也許我的某某創意，可以「顯然」的提供「某個市場」價值。於是就一股腦的投入，等到產品照自己想像的產規劃推出後，才發現市場不買單的機率超高。此時頭洗到一半，往往不知道要繼續做下去還是放棄。
解決的方法是：開發產品，你一定要先確定是這是真議題，真到目標客戶已經焦躁到處嚷嚷誰可以開發哪個工具，我馬上買。而且你也確定市場上，現有市場這類替代性方案，成本非常高。也就是開發的產品內容與方向符合止痛藥類產品。
總不能花上大筆成本，才做出一個沒多少人有購買意願的維他命產品。再抱怨自己的運氣不好吧？
Summary
很多人對於 Growth Hack 的幻想是：任意主題 X Growth Hack = 井噴。這是錯誤迷思。
我個人對於 產品 以及使用 Growth Hack 的建議是：
- 請開發「止痛型」產品
- 自己對目標市場有一定的專業
- Growth Tools 的價值在於拉近客戶距離，時時反饋修正
- 基於以上前提都紮實的情況。再利用各樣 Growth Hack 手段把大石頭搬開，達成業績井噴。
這是一套有系統有方法的市場行銷與運營技術，但前提是「開發者」「不能盲目開發產品」。
我第一次接觸到敏捷開發這個詞，大約是 2008 年。本來剛入門對於這個詞是懵懵懂懂，但隨著經歷大大小小過百個專案，試過十數套專案進行方式後。在這七年當中，我逐漸累積建立自己一套系統性的心法與作法。
常有朋友問我「敏捷開發」要如何學習？
當然，最快的方式，我會推薦你來報敏捷專案管理班2015年版。這是許多專案血淚經驗以及書籍精華融會貫通的懶人包。大家最常問的一百多個問題，幾乎答案都在裡面。沒有那麼多時間自己讀書，或者衝不過鬼打牆的天險，報這個最快。
如果有時間讀書，其實我推薦大家自己研究以及實踐。
畢竟自己實踐出來的心得還是最牢靠。
回到主題，為什麼我要寫這篇「如何入門敏捷專案開發」？因為不少朋友想要掌握這門學問，卻因為網路上 google 到太多資料，不知道如何篩選。導入敏捷框架，反而沒有加速，還被團隊裡的反彈搞得鼻青臉腫。總而言之，走了很多冤枉路，所以我想寫一篇導讀，節省大家的時間。
1. 欲練神宮，必先自宮。第一件事：放棄學習專案完美規劃術。
下這個標題，我知道許多 PM 對於這件事，一定完全無法接受。
但在這裡，我也必須要告訴你一件殘酷的事實，這件事情沒得妥協。如果想要導入「敏捷專案開發」，團隊必須完全放棄由 PM 寫規格 -> 美術畫 Mockup -> RD 套版這樣的做事流程。
（如果你在這樣的架構下要導入敏捷開發，只會比當初沒導的情況下還慘，這就是為什麼有人會誤以為敏捷開發是半吊子沒用的技術。因為大家會以為不寫文件、亂寫文件，就是敏捷。）
我了解 PM 想學專案管理，進階技巧，甚至是學習敏捷專案開發。為的是「提前規劃」「巨細靡遺的不漏重點」「不讓大家浪費時間」。但是除非你做的是 repeat 性的專案（也就是你做過一次知道怎麼做了）。否則對於未知性的專案，這樣的方法只會越往反方向的結果走去（也就是越浪費團隊的時間，團隊成員對 PM 不滿的聲浪越大）。
而世界上大多數的軟體專案，處於「未知」的專案。專案成員（包括 PM）對於專案時程未知，耗用資源未知，專案難度未知。大家只明確知道一件事：「deadline」。
2. 敏捷三重點：消除浪費、過程透明、交付正確成果
當然，禁止了「走向完美規劃」這個方向，會讓很多 PM 大腦瞬間當機。因為這是一直以來大家對於「專案管理」的積極作法，甚至是終極方向。
那麼如果採用敏捷開發的方式又是怎麼做？
在談這件事之前，我想先來談談專案結束後，大家最挫敗的是哪些事？
我想應該是：
- 在專案前期中期，錯誤的規劃方向大量的浪費團隊寶貴的時間
- 在專案協作的時候，成員對於「規格」錯誤的「解讀」，導致不必要的「反覆大方向修改」
- 交付成果完全錯誤。當初花了大把時間規劃出的東西，完全沒人要用，當初熬夜死線加班，好像夢一場。
也因為每次都會產生這三樣的挫敗，所以大家會一直想把原因歸咎於「當初沒有完美規劃，所以造成的災難」，所以解決方法就是「研究如何一開始就完美的規畫調查出詳細的細節以避免慘劇發生」。
PM 是專案裡面「最沒有實作專業」的人，PM 的工作是負責協調資源，而不是負責「主觀的翻譯」「主觀的下決定」
事實上這反而是錯誤的解法。「研究如何一開始就完美的規畫調查出詳細的細節以避免慘劇發生」的解法奠基於「PM 是全知全能的」。現實生活中，PM 反而可能是專案裡面「最沒有『執行實作』專業」的人。所以 PM 永遠不可能做到這件事情。
要讓專案能夠準確以及快速地前進，必須要仰賴於「有實作專業的人」，了解「正確要交付的結果」，才能辦到。
過去瀑布流的過程：『 PM 寫規格 -> 美術畫 Mockup -> RD 套版』，反而會造成了
- PM 花了太多時間以「PM自己」的角度，規劃了完全不接近事實的規格與進度
- 因為規格省略了「情境」，所以實作的 RD 以及 ART，對於規格有各自解讀的方式，以及實作的方式。在「沒有時間溝通」的情況下，交付了完全不能用的東西。或起了嚴重的爭執。
- 當初「規劃」的「進度」，完全是綁死在「每個里程碑皆能完美交付，並沒有意外產生」的情況下。忽略了專案進行其實有「溝通來往成本」，結果時間就不知不覺被揮霍掉了。
「消除浪費、過程透明、交付正確成果」的系統性作法
所以這些你在各敏捷領域看到的實際作法
- Scrum 裡面提到的 User Story，其實是來解決「規格被各自解讀」的問題。
- Kanban 的 Story Board，是解決「時間就不知不覺被揮霍掉」的問題。
- Daily Standup 是解決「大家都不溝通，結果執行方向歪掉」的問題。
- Integrate Early, Integrate Often 是解決「最後一個月才開始看到成果，所有人包括金主看到最後成果都大憤怒」的問題。
- etc....
都是為了朝向：「消除浪費、過程透明、交付正確成果」的目標前進。
3. 引入專案管理工具是為了讓「進度透明、時限內交付、可追溯決策」
很多團隊引入專案管理工具，失敗的原因在於：這些團隊只把「專案管理工具」當作是派票（順便可以 email）的工具。
（所以很多執行者，只會在票的內容裡面寫 done）
而忽略了專案管理工具的目的是為了讓「進度透明、時限內交付、可追溯決策」。
反而不小心把專案管理工具將「原先要達到的目標切得支離破碎」，最後人人只 focus 在單項工作的完成，而忽略大局所要完成的「有效成果」。
專案管理工具的發明是為了要在龐大的專案待辦事項（幾百項）中，能夠讓專案成員繼續
- 保持時間感
- 階段性交付、階段性驗收
- 緊密溝通
- 決策回溯
所以在使用專案管理工具時，通常我還是建議要有自己的一套「切票工作方法」，配合這套工作方法，去對應相對的專案管理工具。
大中小團隊的管理方式以及拆分
專案管理工具有百百種。我會建議依照要完成的事的規模以及團隊 size 去選擇。
- 小團隊，小事：Trello
- 中團隊，中事：Brightpod
- 大團隊，大事：Redmine、Jira
主要的心法在於
- 小團隊只要用 Kanban 的方式去管。狀態：待辦、正在實作、完成。
- 大團隊、大項目，則要用 Milestone 與 User Story Mapping 去切分。
4. 框架不是仙丹，專案加速不夠快不是你做的不夠徹底
敏捷世界裡面最有名最熱門的一套框架是 Scrum。這套框架讓許多團隊又愛又恨。愛的是裡面的確很多方法的確是有用的，很多方法卻是詭異到你根本不敢引入團隊的，而且引入以後也發現的確沒用的。
但是你卻不知道，哪一些招術是可用可以不用的，哪一些招術是你執行錯誤還是 Scrum 原先就設計錯誤。甚至是有些 Scrum 培訓老師還會說如果你引入 Scrum 無法加速，一定是你用的方式錯誤或「沒有全用」，需要再進修或者是整個團隊需要繳錢全部來上課。
更討厭的是，Scrum 裡面很多「規則」，團隊實際執行起來非常綁手綁腳，結果 Scrum 書籍出了一大堆「Exception」去解釋例外的狀況以及處理方法。
（ 我個人的想法是正確的道理一定有一套心法說得通，如果這一套道理出了一堆 exception 集，一定是有一個核心前置設定錯誤了）
我在半年前寫的一篇文章如何同時執行 Growth 戰術以及 Project Management 裡面其實就有談到 Scrum 以 Product Owner 為 User Story 的主導角色造成的嚴重問題。
我的看法是你應該取敏捷框架裡面可以『消除浪費、過程透明、交付正確成果、驅動全體成員關心執行成效』的招數，而非所有招數照搬使用。
我建議取用的概念是
- Standup
- Sprint Planning
- Scrum Retrospective Meeting
不建議取用的概念是
- Planning Poker
- Velocity
- Burndown Chart
- Product Owner
5. Deadline-Driven 與 MoSCoW method
以上講的四段，偏向原則。我真正用於實務最有效的主軸執行方法，其實是 Deadline-Driven 與 MoSCoW method。
Deadline-Driven
為什麼是 Deadline-Driven 呢？因為對於幾乎絕大多數的專案來說，幾乎只有 Deadline 是明確的，其他結構全部不明確。所以用 Deadline 去「倒序排定要完成哪些事」是最準確的，而非「順序去規劃」（只會嚴重超時）。
我在 三年前得到世界首獎的 Hackathon 就是用這樣的方式去管理七小時內的可用資源的。
MoSCoW method
MosCow Method 是把所有的需求照
- Must have
- Should have
- Could have
- Won't have
的方式區分。
這配合時間倒序的專案管理方式特別有效，在有限的時間內，會迫使人們去決定重要順序。如果是用正向順序進行專案管理，人們往往會將需求通通定義為「Must Have」。
推薦書籍
當然，以上談的通通是心法與關鍵字。如果真的進行深度研究，每一個主題領域都至少好幾本書專門深入探討該題目。我推薦有幾本「淺顯的聖經」是可以去翻翻的：
- User Story Applied
- Agile Estimating and Planning
- Succeeding with Agile: Software Development Using Scrum
這三本都是 Mike Cohn 寫的，本本是經典。
至於如何與軟體開發搭配，有兩本心法書我是建議用來搭配：
兩本都是 Kent Beck 寫的。都是老書了。一本 2000 年一本 2004 。（所以敏捷不是新把戲了）
至於如何將產品主導權從 PM 交還到團隊成員，我推薦兩本書給你方向：
- Google Venture 出的 The Design Sprint
- 麥肯錫新人培訓7堂課
推薦課程
如果你沒有那麼多美國時間看完，我有一堂專案管理課：
建議有「現在就有打仗需求的人」直接來上 XD！我想你不會真的想真的去花幾萬在買書錢，以及花上三年慢慢把這些東西都練完。肝都先被操到爆掉了。