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。反而不知道怎麼再繼續走下去了。
這時候就會面臨下一個問題「繼續維持高成長,但是公司不再混亂」。這就是我在這篇想要談的目標。
在這裡我有一個目前歸納出的重點:在創業階段的專案管理
- 不需要傳統專案管理的「風險管理導向」技巧
- 需要的是「成長導向」的專案管理技巧