Q: 如何一天做 15-20 支的 pull request 的 Release
過去我參與的的團隊一夕之間從 3 人膨脹到 20 人團隊。堆積如山的 pull request 成了我們的 devops 最頭大的問題。因為在當時 codebase 沒有測試（ startup 怎可能會有測試）的情況，一天只能 deploy 一支 pull-request，還可能大爆炸。
而這也是在業界最多人常問我的問題：如何設計一個很多人 (a.k.a 10+ 人） 可以瘋狂拉 pull request，卻不會大爆炸的流程？
以下是我的答案
step 1. 切分 deployable 與 development branch
把 branch 切成
- production
master
production 是正式 deploy 的 branch，只有 devops 可以對他進行變更，其他人不得任意進行操作。正式上 production 是去 deploy production branch。
master 是大家開發基準線的 branch，所以大家要開發什麼功能，以這個 branch 去 git checkout
開發完畢之後的 branch 對 master 拉 pull request
pull-request 的原則
- 須以 ticket branch 為名
- 有自動測試，需綠燈。
- 附上手動測試說明，手動測試需要在 15 分鐘內。
- 手動測試部分，junior 須送 senior 做第一次的 code review，senior 可直送 devops
step 2. 只 deploy production branch
devops 收到這些 pull request 後，手動測試後沒問題，merge 到 production branch。
在明日的上班第一個小時 deploy production branch。
如果是 deploy heroku 的操作可以更細膩。
先 deploy 到 staging 的 server，再 promote 到 production branch
step 3. 寫 release log
這樣的開發速度，是沒有辦法對版號做 release note 的。所以之後的 release note 會以 day 為計算。
一開始的 workround 我們是寫 hackpad 紀綠：今天有哪些 pull request 在排隊，哪些 pull request 被 release 了出去。哪些 pull request 在 production 需要額外的操作（例如 data migration)。
然後這份 hackpad 要 cc 給全技術 team，包括技術 team 外的人知道，我們釋出了哪些功能，這樣 customer support 才會知道要憤怒的 customer 衝進來，大概會是為了什麼事。
後來這個手段 loading 實在還是太重了。我們找到 zendesk 開發的 samson，自動化的解決這一切。
samson 是一套網頁介面的部署軟體。samson 可以做什麼呢？
- 對軟體打版號
- 可以一鍵前進 deploy，可以一鍵後退 deploy
- 網頁介面可以顯示這個 deploy 的版號上面，包含了哪些 pull request
然後我們再對 samson 做了一些 hack
- 把 samson 接上了 slack
- 讓 samson 支援 heroku ( 原本只支援 cap deploy )
- 自動寄信給全 team，這次的 deploy release 了哪些 pull request
- 規範了 pull-request 的 description 要怎麼寫
- 寄給全 team 的信裡面就會有功能說明
- devops 知道按下 deploy 鍵後，還要額外手動執行哪些 rake task
系列文章
Q: 如何讓專案管理系統上的 User Story 可跟程式碼進度同步 (a.k.a 可驗收）?
這當中手續有點複雜，我從幾個原則開始說明。
Ticket branch 使用專案管理系統的票號命名
很多人是使用 gitflow 這個流程去管理程式碼，坦白來說我覺得「不夠用」（a.k.a 很難用）。因為實際上：
- 你面對的隊友程度不同，所以 feature 切的 ticket 粒度也不同
- 實務上遇到的狀況是隊友程度不同，狀況緊急也不同，很多時候你無法強求寫 test，一大包的 pull request 混在一起的 branch，沒有辦法做驗收測試 （也就是風險很大，因為就算綠燈，你也還要測使用者介面，然後一個豬 pull request 就會污染大家）
- 喪失決策歷史。不是每個人寫 code 習慣都很好，且懂得寫好的 commit log，或者交代他為什麼要做這個 pull request。
所以我們的作法就是，拉 pull-request 的程度必須到 ticket level 等級，然後用 ticket 號碼為 branch 命名。這麼做的好處有幾個：
- 大家知道這個 branch 為何而開
- 討論決策在 issue tracking 上可以追朔得到
- 該 branch 至少解決了「 1 個明確需要處理的問題」
單支 Ticket branch 要 deliverable
所謂單支 ticket branch 要 deliverable，是指很多時候，我們理想要在一個 branch 裡面解決一個 User Story，但這是不可能做到的。這在設計一整個 workflow，或者是要 Refactor 一整組功能時，最容易發生。
狀況一：Refactor
工程師 refactor 的很開心，測試也綠燈。送上去 deploy，爆得亂七八糟，然後其他人因為這組 pull reqest，被搞得此次 release delay 連連。
而 release manager 要是擋了這組 pull request，又會回退到大家不開心。
我設計的 policy 是這樣，即便是 refactor 一整組功能。也必須要遵守這樣一系列的原則：
- 單支必須要過可以自動測試
- 單支必須要過同事手動使用者測試，而手動測試不能佔到同事 15 分鐘以上的時間，否則就是粒度太大
也就是這隻 pull request 必須要小到直接 hotfix 上去也不能死人。
狀況二：開發複雜的功能
如果是開發複雜的功能，那麼原則，大 ticket 專注在驗收「流程」，小 Ticket 專注在「功能」。假設今天我們要實作一個 Markdown 編輯器，除了要支援 Markdown 語法之外，還要可以拖拉上傳圖片。那麼 Ticket 可以切成這樣
- (1) 產生文章編輯器後台。（純 Text Field 與純 Text Area )
- (2) 把 Ticket Area 掛上 CodeMirror
- (3) 實作後台上傳功能，用 File Field 實作
- (4) 把 File Field 重構成拖拉上傳
- (5) 把拖拉上傳的 Event Listenr 跟 CodeMirror 掛勾
也就是先解決「可完成 workflow」的功能，然後再把每一個小功能當作是 bug，「修復」上去。
如此一來，所有的功能都可以獨立驗收。
工程部分的原則
這當中最重要的原則精神就是，就是一天至少 15 支 pull request，也可以放心的 deploy，不用擔心晚上需要加班救火。
客戶方面的結案建議
在前面一篇我們提到了第一階段要能夠實作 continuous deployment。是因為很多外包的客戶，對於自己外包出去的進度不安心。
用這樣的過程，你可以將驗收階段切成比較無風險的三階段：
- 工程期間，只驗收 workflow 與基本功能
- 驗收階段，驗收細節與 bug 修復
- 美術階段，驗收 UI 細節
這三件事分開驗收，感覺雖然比較麻煩，但是對於雙方信任程度與金錢、法律責任會有相當大的加分。
系列文章
-
工程團隊如何做專案與程式碼管理 （一）
- 工程團隊如何做專案與程式碼管理 （二） ← You Are Here
- 工程團隊如何做專案與程式碼管理 （三）
寫完創業團隊如何做專案管理。下一篇我要來寫的主題是工程團隊如何做專案與程式碼管理。以前我寫過很多調度專案的文章，但是執行細節我都沒有寫(a.k.a 不想寫 XD）。這一系列我希望解答一些常見的主要實作問題。
Q: 上 Issue Tracking 的 User Story 第一版粒度要切到多細?
這要分兩個層面來說。跟客戶簽約的 User Story 或者是工程團隊的 User Story。基本上是以 Interaction 粒度來切。
跟客戶簽約的 User Story
跟客戶簽合約的 User Story 的最小 Interaction 是 1-3 天。也就是 User Story 的粒度是切到剛好到 billable（在收費程度上無爭議）。（更細反而有爭議）
工程團隊內部時做的 User Story
假設這個專案只是內部的專案的話，那麼 User Story 的粒度是要切到 0.5 - 1 天左右，也就是要切到能
- 粗抓大概工程時間線
- 細抓到你可以找到工程 Risk 結點
大致上的專案規模
所以一個要做 2 個月的中型專案，大約上 issue tracking 之前
- 與客戶簽約的 User Story 版本大概是 60-100 條左右
- 自己內部開發的 User Story 版本大概是 100-200 條左右
結案大概會是 350 條 User Story 左右（含驗收）
Q: 收到 User Story 後要如何排定 Milestone?
我會用 Deadline-Driven + MoSCow method 的方式去排 Milestone。
- 先將 1/3 的工期，預留給 deploy 收尾的 story （或者稱 epic，就是技術細節）
- 再將 2/3 的工期，切成 3 段。
第一段：前期基礎
第一小段，做前期準備，比如說做
- Continous Deployment 架構。讓之後隨時的工期都會有可驗收的進度
- 找出高風險的 User Story，比如說信用卡刷卡需要先書面申請，先委託給其他單位去跑行政作業
- 找出有多少頁需要進行畫面設計
第二段：主要工程開發
實作主線架構。這時候的重點在於
- 完成主要功能
- 無法完成主要功能的話，至少要能完成主要功能「User Story」的 workflow
這個階段的目的是，邊做邊盤點團隊有多少資源。同時藉由 workflow 的拓展，把下一步未知的風險出來。
這時候就可以透過 MoSCow Method 去對所有的 User Story 去做 Milestone優先權升降。
MosCow Method 將資源分成
- Must have
- Should have
- Could have
- Won't have
這階段應該專注於把 must have 的功能或者是 workflow 做完
第三階段：次要工程開發
完成了第二階段後，若有時間的話，接下來在這階段可以實作 should have。
然後把 could have 的優先權，拉到驗收階段。然後誠實跟你的 Product Owner ( PM 或者是客戶）告白，won't have 就是 won't have 了。
驗收階段
因為我們留了一大段驗收階段的時間，這時候就可以心無旁騖的實作 could have。
甚至是最後 finalize 的效能調校與 bug 修正。
Template
這是我以前的切票示範。
系列文章
- 工程團隊如何做專案與程式碼管理 （一） ← You Are Here
- 工程團隊如何做專案與程式碼管理 （二）
- 工程團隊如何做專案與程式碼管理 （三）
- 創業公司 Startup 如何做專案管理（一） 「成長」導向，而非「風險管理」導向
- 創業公司 Startup 如何做專案管理（二） 利用 OKR 找出短期與長期目標
- 創業公司 Startup 如何做專案管理（三） 使用 Deadline 與 MosCow 消除冗事
- 創業公司 Startup 如何做專案管理（四） 舉辦 Standup meeting 透明流程，聚焦重點
- 創業公司 Startup 如何做專案管理（五） NPS 畫出於「對的」產品方向與「對的」TA
- 創業公司 Startup 如何做專案管理（六） After Action Review 讓團隊不再跌入重複的坑洞
小小的系列，總共六篇。
這一系列文章，其實也算自己的一個觀念掙脫蛻變。
我是一個從最底層工程師掙扎爬起來的創業者。從自己只是執行者，帶 1-5 個人、5-10 個人、10-50。小公司、大公司都做過。瀑布流、敏捷專案都經歷過。
我曾經認為公司成長不了是因為內部亂成一團，到處失火，所以跑去學專案管理。學成並精通專案管理以後發現，專案管理並沒有辦法救公司。甚至專案管理的極致，甚至會扼殺成員的主動性。
敏捷沒有辦法讓公司成長
我曾經也相信「一開始」就做好專案管理的規劃，是一個專案日後快速成長的關鍵。但我卻發現 Startup 的「機會」，是存在混亂與風險之中，而不是在完美的時程與 User Story 中。越規劃只會讓團隊越栽在「規劃」與「現實狀況」的掙扎之中。
最後我開始好奇，以前曾經相信的這些「假設」與「鄉野傳奇」是怎麼來的。
經過反覆的思考，我才越來越發現：專案管理是一個「工業化革命」下誕生的「名詞」。目的從來不是解決小組織的挑戰，而是「大組織確定命令後」，為了大幅加速命令執行速度的手法。
不管是「瀑布流」或者是「敏捷」管理。本質上還是只是「假設一個不知道當初時空背景以及誰下的命令」，「埋頭努力執行」的手段。「敏捷」本身並沒有大幅掙脫這樣的輪迴。只是讓中間的冗事被執行的機率被降低了。
所以大家還是能見到在 Startup 界聽到的真實誇張，卻不讓人意外的極端例子：「一個拿到投資的頂尖團隊，完美的執行敏捷手段，最後卻做出一個市場沒人要的垃圾」。
專注於「協作」而非「管理」
環顧世界上，更多產品能夠成長的團隊多半是這樣的狀況：
- 亂七八糟半路自學程式的 Founder
- 莫名其妙的打中市場需求
- 雖然拿到很多錢，但是雇人非常謹慎
- 很少聽到他們分享什麼專案管理的文章，但是卻可以做出厲害以及暢銷的產品體驗
- 他們一直提到「同一價值觀」這件事
我從這一兩年來，深入研究成長這個主題後，才開始發現。原來「專案管理」這個技巧一點都不重要。更重要的是「專案協作」。
- 管理指的是「控制人去做你想做的事」
- 協作指的是「提供工具與基礎設施，讓眾人齊一往同一目標奮鬥」
總結
現在的這個社會，你越仔細觀察，越發現絕大多數的人，做事的方法是類似的：
- 假定一個遠大目標
- 制定高速成長的完美計畫
- 招募一大幫「個體優秀」的團隊成員
- 利用完美的敏捷技巧，快速達成當初的遠大目標
看似完美，但是最後會掉入相似的結局。不斷的投注完美的想像，最後無法承受現實生活中的挑戰，最後崩潰。差別只在於專案目標不同，成員名字不同。
很多人以為異軍突起的 Startup 成功都是機遇。事實上真的不是。他們都有共同的特點，與共同的做事方式。也就是在這六篇文章，裡面我提的方法會造成的結果：
- 共同目標與價值觀
- 互助扶持的同步
- 專注於應對現實的變動，而不是成為一個完美稻草人
- 找出正確以及有價值的 TA 與產品方向
- 不再同樣的蠢事上犯錯
這才是 Startup 需要的做事手段與價值觀。
最後一招，就是進行 After Action Review。
我在之前的文章，也有提過 After Action Review 這套工具
What is After Action Review?
After Action Review 最早在大眾前曝光，是在 HBR( Harverd Business Review ) 上。這個方法也非常單純：
只有一組共三個問題：
- What was supposed to happen? What actually happened? Why were there differences?
- What worked? What didn't? Why?
- What would you do differently next time?
在每次專案完工後，立刻做這件事。
為什麼我們需要 After Action Review?
不知道各位有沒有遇到一個狀況，公司做某件事很久了，老是出現同一個致命的狀況，漏水。但是因為犯錯的是某個你不能動的人，結果這個致命錯誤就一直繼續上演。首先是他，接著破窗效應，其他人有樣學樣。
為什麼這些事情會一再上演？因為在傳統的做事觀念當中，為了「人和」。每次專案有人當中搞砸了，大家要不是避而不談。不然就是承諾下次會改善，但從來沒有做到。
然後下次再發生時，每個人只是用情緒字眼，在事情當下時謾罵，平撫自己愧疚的情緒，等待時間沖淡。然後下次發生類似事情時，再重新輪迴一次。
After Action Review 透過對事不對人，並且以書面形式的檢討，強迫檢討改進。避免相同蠢事不再重複發生。
美國陸軍如何用 After Action Review
很多人以為 After Action Review 是 HBR 發明的，其實不然。AAR 最初發明的起源是美國陸軍。一般在社會中重複的犯錯，不會死人。但是在軍隊中，重複的犯錯，會死一大堆人。
美國陸軍發明了這種 Review 方法，防止了致命的錯誤一再上演。然後利用每一場戰役、演習後的 After Action Review 所產生的經驗與教訓，整理成冊。編輯成各種教戰指南與 SOP。提升部隊的戰力。
我們內部如何使用 After Action Review
- 首先，我們會針對每一次的事件挫折，執行 After Action Review。
- 可以 quick win 的東西先修正。
- 接著再針對沒有辦法一時之間的修正，檢討是否跟 NPS 重疊，來決定執行的優先權。
- 改正的方法紀錄整理回去變成 SOP。下次執行同樣的活動時，用 SOP 照表跑一遍。
Summary
很多人往往以為「成長」，就是去學習快速前進的方法，大步前進。
事實上這樣的「仙丹」非常罕見。
事實上「成長」還有另外一種方向，當別人一直無法克服的輪迴，你能掙脫並且往前，這也算成長。而這件事，非常困難。用了 AAR，它能幫助你加速突破。
系列文章
第五招是，根據 NPS 改進產品
NPS 是什麼？
NPS 全名是 Net Prmoter Score，用大白話翻譯是客戶願意幫你傳播的分數。NPS 被譽為在 Customer Success 界的聖杯問題（The Ultimate Question）。
如果你只能問客戶一個問題，那麼問這個問題就夠了。我在以前的文章有談過這個指標。
為什麼要根據 NPS 改進呢？
Startup 有千奇百怪、堆積如山的改善 feedback 需要做。但是 Startup 也意味著資源稀少。不可能什麼人什麼角度的 Feedback 都照單全收。
如果照單全收，團隊可能面臨兩個下場
- 加班加到死也做不完
- 產品改成四不像
如何利用 NPS 聚焦？
NPS 把顧客分為三種人。一種是正面口碑傳播者，一種是中立者，一種是負面口碑者。
利用中立者改善產品
- 中立者是正確的 TA
- 但是你的產品發生了一些小差錯
- 讓他們不願意主動傳播
如果你可以讓這些顧客主動傳播。那就再好不過了。產品需要成長，而這些「小差錯」就是會妨礙你成長的真正原因。
捨棄負面口碑者，切割市場
每一個產品都有適合他的顧客與市場。但創業者通常會很貪心，通通想要。但事實上你不可能迎合所有階層的顧客與口味。如果通通照單全收這樣的建議，產品只會被改到四不像。
比較好的做法，是在這個產品線中，大膽捨棄負面口碑者這個客群。
這個產品的這群人，不是你要的。你也不需要因為他們的意見改進這個產品。
如果你真的很想要這群人，你應該再開一個產品線賣給這群人。
比如說你的桌子做得很好，客戶希望桌子內建椅子，你試做了這個 prototype，反而引來惡評。那麼這時候，你不應該是繼續強化內建椅子的這個功能。而是推出單獨的椅子產品，去搭配這張桌子。如果把桌子產品改成內建椅子產品，你只會失去桌子族群，而且把你的 TA 狹小到那群「需要四不像」產品的顧客。
系列文章
第四招是，每日執行 Standup Meeting。
坦白說，這是我認為這四招當中最重要的一招了。當你的公司如果只有兩個人，什麼都可以用口頭交代的方式。但是一旦成員到達三人以上。就會發生溝通不良，或者短期目標不一致所以導致執行優先權狀態不一致的狀態。
Agile 專案管理中的 Standup Meeting 可以很好的解決這一個問題。
What is Standup meeting ?
Standup Meeting 是一種團隊例會，長度只有 15 分鐘，也只能有 15 分鐘。在開會時每個人都必須保持站立。（防止有人太囉唆）。這個會議強制各位同事參加。
每個人在會議中都要依序報告三個規定的問題：
- 昨天我完成了什麼
- 今天我要去完成什麼
- 在過程中遇到了什麼樣的阻力
Why we need Standup Meeting?
抓出腳步不一致的人（當然這不是主要重點）
感覺回答這三個問題很容易對吧。非也，如果是對充滿幹勁的人來說，回答這三個問題超容易。但是對於偷懶或散失鬥志的人，超級難。對於偷懶的人，編造這三個問題超級困難。
P.S. 這裏有兩個訣竅
- 絕對不允許同事在 Standup 前臨時請假翹班
- 不要因為貪圖快速，而允許「只用軟體」線上 Standup，這樣大家只會拿到一堆假的濫竽充數互相自慰的報告。
聚焦
從大家的 Standup 大致上就會發現，這一週大家的重點與優先權是什麼。需要協作的狀態是什麼。而不是大家無頭蒼蠅一樣在忙不同焦點的專案。
互助
Standup 不是跟老闆回報的會議，也不是回報同事互相監視的會議。而是一個「互助」會議。
在這個會議裡面，關於專案的進度，大家應該要誠實回報，沒有做、或做砸都沒有關係，重點是我們可以修補彌補這件事。自己不擅長沒關係，遇到專案阻力，也許同事也不同的想法以及專精可以幫助你解決眼前的問題。
畢竟快速往一致的目標前進，才是這個團隊需要的。
我們團隊怎麼做？
我們團隊目前的方式是：
- 每天下午 1:30 Standup Meeting
- 用 Hackpad 在 Meeting 之後記錄 Standup meeting 內容。
Hackpad 格式是：
- 昨天與今天我做了什麼
- 今天預計要做什麼
- 今天我做的東西遇到什麼困難需要別人幫忙的點
- 明天我預計要做什麼
當作寫日記一樣。
這樣的好處是當翻到前幾天日記的時候，你很容易回憶起幾天前我們做了哪些事情。
系列文章
我在創業日子裡面體悟最深的。就是在大公司裡面，做一件事情你擁有有無限的時間與資源。但是在小公司裡，你可能只有三天時間以及一個人手。
我以前熱愛打 Hackathon，我在打 Hackathon 這種需要嚴密調配資源的遊戲裡面，鍛鍊出一種做專案的 mindset 與實踐的方法。具體分為兩個步驟：
Deadline-Driven Planning
小公司的專案裡，通常只有 Deadline 是明確的，其他結構全部不明確。而且 100% 的情況，你不會有任何時間資源去「按照順序去規劃並完成所有你想要完成的事」。
這是跟在公司裡面「假裝敏捷」有很大的差異。按照一般公司的步驟在創業公司裡面做專案。常常會出現「手術成功」，但「病人已經死了」的悲劇。
而且後來，我更進一步地發現，絕大多數人會搞砸專案的原因，往往是因為資源太多，而非太少。如果你把時間抓得非常緊迫，那反而會逼出人類的危機感，自動過濾出「哪一些是是真的該做的」。
就跟期中交作業，期末準備考試一樣的原理。缺少時間，人類自然就會自動按照危機感把該做的事自動做有效的劃分。
所以我在 Startup 裡面執行專案的方式，是把每一個案子都當作 Hackathon 在打一樣。利用 Hackpad 盤點資源，然後用 Deadline-Driven 的方式，把看似無盡的時間與資源，切成幾塊有明確的時間區塊。
每個時間區塊有自己的 KeyResult。這樣就能確保不至於有太大的超時。
MoSCoW method
接下來我會將 Key Result 再次區分，用 MosCow Method 排優先權。
MosCow Method 是把所有的需求照
- Must have
- Should have
- Could have
- Won't have
的方式區分。
MosCow Method 配合時間倒序的專案管理方式特別有效。如果是用正向順序進行專案管理，人們往往會將需求通通定義為「Must Have」。
而如果將 Key Result 鎖在在有限的時間內，反而會迫使人們去決定重要順序。所有人的精力只會 Focus 在 Must have 與 Should have。
團隊可以在很短的時間，不拖泥帶水的取得 MVP 與 small wins。這正是 Startup 最需要的戰果。
系列文章
目標有了。接下來我想談步驟。我覺得創業公司第一件該做的事，是要導入 OKR。
什麼是 OKR 呢？
知乎上有一篇文章，把 OKR 的原理解釋得非常詳細：https://www.zhihu.com/question/22471467。這裏我就不花篇幅照搬運一次了。
這裏我只歸結重點。
OKR
- O 是 Object 目標
- KR 是 Key Result 關鍵成果
- 將公司階段目標「量化」
- 具體聚焦公司當下最重要的大目標
- 下層執行者具體「承諾」自己為了完成「組織大目標」所要完成的「個人工作承諾小目標」。
OKR 是為了指出公司成長北極星
為什麼引入 OKR 是第一件事，也是最重要的事？
創業公司最需要的就是聚焦。創業階段是一段非常混亂的時期。創業團隊會同時
- 湧入太多的機會
- 湧入太多的員工
- 產生太多的方向
眼前有一萬件事情要解決，但你卻只有 5 個人。
如果團隊不聚焦，很容易就被自己人踩到或者是殺掉。
創業跟在公司「上班」也非常不一樣。在「公司」你總希望事情平順進行，在創業每天都會有驚嚇。保持同一個方向前進變成是很困難的事情。
OKR 就是用來確保這個團隊裡，至少 1-3 個月內，大家的成長目標是一致的。而且不是漫無目的的 bullshit，而是實際可量化的指標與方向。
系列文章
在這篇文章裡，我要來談：「在創業公司裡面如何做專案管理」。這是一篇我認為難度很高的題目。
當然，在幾年前的我，是根本不這麼覺得的。甚至大部份熟 Agile 的 RD 都不會這麼覺得。不就是 Lean 嘛、Agile 嘛，少掉公司內囉唆的規格而已。
Agile is not completly for "Startup"
後來我自己在創業過程中，也不斷的思索這些問題。但想來想去，總覺得現有流行的敏捷管理，套在 Startup 的模式裡，總是怪怪的。甚至一些精闢的敏捷經典文，立論沒有錯，但是在這樣的場景內，總覺得哪裡歪了。
後來我理解到這樣的幾個現實，為什麼我會覺得他們歪
- 現有的敏捷開發，誕生的環境不是為了「Startup」。是因為一定規模的公司，人太多，為了改良使用「傳統瀑布流方式規劃專案」，提出的新架構。「增加效率」「減少浪費」。
- 大部份的敏捷提倡與實踐者，是 Engineering 部門的人。這些人跟「真正市場」與「付錢的真正用戶」非常的疏離與脫節。也許敏捷可以快速迭代成「他們想像的產品樣子」。但是做出來的東西，沒有滿足市場上任何人的需求。
- 既然都請得起 Engineering 「部門」。那麼這間公司定義不再是 Startup。而是 Company。
- 專案管理本身的其一目的是「消除風險」。而創業處處都是「驚喜」與「風險」。未知的機會與市場隨時會把你帶向另一個高峰。如果你真的在 Startup 做了非常好的的(so-called)「專案管理」，恭喜你，你的創業公司也離死亡不遠了。最常聽到的是技術團隊創業的公司，"Doing Perfect Agile" 卻把自己管到死掉了。
這就是為什麼我覺得「創業公司 Startup 如何做專案管理」是一個難度很高的主題。
For Growth, not for Risk Management
但是很多 Startup，還是非常希望引入「專案管理」，主要是太多的混亂、與眼前的機會爆發，反而把前進腳步打亂了，到了一個某一個臨界點。原本知道怎麼做把 MVP 做到 pre-PMF 的 Founder。反而不知道怎麼再繼續走下去了。
這時候就會面臨下一個問題「繼續維持高成長，但是公司不再混亂」。這就是我在這篇想要談的目標。
在這裡我有一個目前歸納出的重點：在創業階段的專案管理
- 不需要傳統專案管理的「風險管理導向」技巧
- 需要的是「成長導向」的專案管理技巧
