91APP的軟體開發之道—從20人到200人的組織發展旅程

91APP現在有一個200多人多大產品單位，包含PO、RD、UX/UI、QA等等都在這個單位，也是整個公司佔了一半以上人數的單位，負責91APP的SaaS產品的開發工作。

聽說我們跑的是Agile（敏捷式開發），在台灣，很少聽到有一家軟體產品公司，如此大規模的運作Agile。很多人問我們，這麼大規模的組織運作Agile，要怎麼跑？

這篇文章主要就是嘗試說明這個問題，但其實真實的關鍵已經不是agile，是軟體開發組織運作方法。經過多年的演變，Agile也已經不是原來以為的Agile了，如果硬要說我們現在的開發方法的話，我會說是91APP Way（91APP的軟體開發之道）。

這個故事大概是截至目前為止，最長的一篇文章，足足有將近6,000字。但本來組織發展，就是一個公司能否長期成長的關鍵，千言萬語也無法道盡其中奧妙，所以就用一篇故事的形式，簡化了一些過程，提煉其中的關鍵轉折，串連起來變成起承轉合，或者你也可以把它當作一篇寓言故事，希望能給大家一些啟示。

第零階段：最美好的時光

跟大多數創業公司一樣，我們一開始也只不到20個人，而這個階段，是旅程中最美好的時光。

記得當時ㄧ開始的這群人，除了同事，更像是朋友，中午會一起吃飯，下班還會約唱歌，假日還會約出遊。然後邊玩邊討論工作，邊工作邊玩。

剛開始的這個階段，大家其實會非常有默契。工作目標決定之後，會一起想辦法達成，有麻煩就互相幫忙，有挑戰一起打怪，有經驗一起練功，有問題就快速溝通，有想法就快速討論。

或者更可以說像是革命夥伴。革命是很讓人亢奮的。創業初期雖然辛苦，但創業就是一起追求一個夢想，一起做夢，看起來未來無限可能，所以會莫名的型成一種很High的氛圍，感覺我們什麼都做得到。

通常這個階段，也沒什麼明確的組織，也沒有明確的分工，反正就是一起想辦法，貢獻自己可以做的事，看做什麼可以讓公司往夢想彼岸推進一步。

其實這個階段通常也不喜歡什麼組織分工、設立流程制度，都很點綴，想辦法讓公司可以活下去、找到成長的動能才是最重要的。

第零階段的創業團隊，是最美好的階段，如果你還在這個階段，請好好珍惜。

第一階段：瀑布來了

可是當團隊成長到50人以上，管理的問題就開始來了。

通常一定是公司做對了什麼，產品有了第一批的客戶，營收有了進展，團隊也才因此開始成長。

這時候會開始有新成員加入，有了「新人」，原來的舊人就變「資深」了，資深就厲害了，就會開始對新加入的菜鳥有很多的指點。於是，某一種奇妙的「階層感」就開始發生了。

順理成章，「資深」就變成了「主管」，而有主管就會有部門、有部門就開始分工，有分工就開始要溝通，有溝通就開始分你我。

就我們來說，就開始分成有產品部門、設計部門、工程部門、測試部門等等。然後每一個產品專案，都會需要跨部門討論，落下各單位的工作項目，PM就會畫出「甘特圖」，來追蹤整個專案的進度。

產品規劃完交給設計部門、設計畫完交給工程部門，一棒接一棒，很自然的就變成了知名的「瀑布式開發」的跑法，一個功能專案從開始規劃，到開發、測試後上線，通常至少要跑到3個月以上，然後也常常還超出預期。

第二階段：上帝之手

不過隨著團隊規模再跨大，也不可能是一個團隊，一起跑一個專案，一個瀑布跑到底，老闆是不會接受的。最好是整個產品團隊，能同時跑幾個專案，越多越好。

意思就是說，如果我們有70個人，而同一個時間，通常就會有6~8個專案一起跑，所以就得依據專案需求，想辦法分配人手，把人分別丟進不同的專案裡面。

所以依據不同的專案的特性，指派一個PM、UX、再指派幾個RD、QA，組成一個臨時的專案團隊，然後專案結束就解散，大家各自又被「分配」到其他專案去努力了

而分配大家工作的管理階層，就像是決定大家命運的「上帝之手」。

這種跑法，非常講求「上帝之手」的資源調撥的功力。調撥資源的人要知道每個人的長項、每一個人當下的loading等等的，然後把對的人塞進專案裡面。一沒弄對，有的人就會過載，專案超多，命運坎坷，而有的人就像生在好人家， 涼的很，平常也沒什麼事。

「上帝之手」安排每個人的故事與角色，設法讓整個世界可以正常的運作。

通常這種跑法一開始問題也不大，而調資源的主管層越強，這個跑法可以運作的很好，至少好一陣子。

然後問題就來了。

通常這種跑法所形成的「專案團隊」，「團隊」感是很弱的，甚至也根本不是一個團隊。

因為終歸是一個瀑布型的跑法，每一個專案的時程都拉得很長。所以像是專案團隊內的PM，通常專案啟動後，工程師還要寫一段時間，所以他已經被安排跑去寫另一個專案的規格了。

大家彼此都是生命中的過客，因為專案而短暫交集，專案結束就分開了，很難有什麼「團隊默契」。

第三階段：形成專業領域團隊

而且，隨著公司的發展，產品的複雜度也在變高，於是不同產品線功能之間的 「專業領域知識」，也開始越來越深。因此接下一個專案的人，從理解專案的「專業領域知識」 到真正可以上工的時間，也越來越長。

例如本來做金流的人，好不容易把金流搞懂，下一個專案被安排去做會員機制。所以常常一個專案成員，好不容易把一個產品線的專業領域弄熟了，團隊默契也熱起來了。但專案一結束，團隊就解散，各自去接下一個案子，而且可能還是自己完全陌生的案子。

好像是你好不容易找到打棒球的感覺，就突然調你去打打籃球了。

隨著團隊成長到100人，這種跑法幾乎快要跑不去。大家工作都很不開心。

於是我們開始思考，是不是應該把團隊成員固定下來，讓做金流的這20個人，長期形成一個固定的「專業團隊」（而不是「專案」團隊」），就一直做金流相關的題目。做會員的那20個人也一樣。

也就是依據專業領域，畫分出一個一個的「專業領域團隊」，然後整個團隊固定成員，就一起在這個專業領域，長期發展。

也就是會打棒球的就一直打棒球，會打籃球的就打籃球。固定團隊成員在固定的專案領域裡面長期耕耘，理論上會越做越熟練，團隊默契越好，工作效率就會越好，生產力應該會更提升。

但，我們的軟體工程方法，一直以來還是瀑布式開發。不管怎麼切分人員成團隊，每個團隊裡面，還是瀑布式開發。整體專案從PM把規格寫完，到實際RD開發完成上線，產出工期還是很長，而且常常PM一直在寫案子，但工程師怎麼樣都來不及寫完。

於是，我們開始尋找有沒有更好的軟體工程方法，就在這個時候，我們開始嘗試開始導入「敏捷式開發」（Agile）。

第四階段：敏捷式開發

我們選擇採用的是Agile的思維下的Scrum的方法。

我們依照Scrum Guideline，讓每一個「專業領域團隊」，都設定成為一個Agile Team，也剛好原來的「專業領域團隊」，就是跨功能組織的成員所組成，長期一起合作的固定團隊，內有各種角色：PO、UX、RD、QA的等等，可以End to End的生產並交付產品功能。

我們再依據Scrum Guideline，嘗試設定3週為一個「Sprint」，每一個Sprint，跑Agile的四大會議，從每日的站立會議(Daily Stand)，到Planning meeting、Review meeting、Retrospective meeting。透過每一個 Sprint一個release，不停循環sprint，來推進產品功能交付。

我們再依據Scrum Guideline，嘗試導入新的Scrum Master的角色，但因為一開始摸索Scrum Master在團隊內要怎麼做，實在花了很多的時間（吵了很多的架）。於是我們也從業界，找進了敏捷教練，跟專業的Scrum Master。