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。
但，Scrum Guideline真的寫得很精巧，也就是說，他並不是像一本使用手冊一樣可以一步一步照著做，沒有什麼必然的作法與流程。所以常常是一個Guideline，各自解讀。
導入Scrum之後，我們一天到晚遇到團隊成員之間在爭執，PO應該要做什麼、Scurm Master要做什麼，Planning Meeting要怎麼開才對、Product Backlog要怎麼列、甚至一個Sprint是三週、兩週、還是要改一週？
我們花了非常非常多的時間，在解讀guideline，在辯論「什麼才是正統的Scrum」，甚至還互相批評「你這樣的作法不是Agile」，「你這個會議不是Scrum的開法」。
結果，好一段時間，我們太過於計較跑步的姿勢，而忘記了跑步的速度，甚至就算跑步姿勢一百了，一抬頭才發現跑錯了方向。
我們開始思考，為什麼當初要導入敏捷式開發？
第五階段：團隊的自主管理
我們後來發現，身為主管層的我們，還是用傳統管理的腦袋，來嘗試「管理」Agile團隊的Scrum跑法。即使團隊已經導入的敏捷開發方法，但主管層仍然不是很敏捷。事事都想干涉，一直嘗試想安排每一件事（上帝之手一直收不回來），而忽視了「團隊自主」是敏捷裡面很重要的精神。
於是我們開始嘗試，讓「團隊自主管理」，團隊可以依據自己的狀態，可以摸索出自己Scurm的跑法，無論3周一個sprint、2周一個sprint，或者站立會議的開法、Planning Meeting的開法。每個團隊可以跑出了自己的樣子。而不是讓管理層事事要求所有團隊，有一套「標準」的Scrum跑法。
我們開始不去計較團隊跑步的姿勢，不管姿勢如何，有跑步的速度就是好團隊。
我們也讓團隊有自主的權利，團隊可以安排自己的年度計畫（在公司的年度目標的前提下），可以安排每個Sprint的工作內容，團隊成員也會在Planning meeting，一起討論每個sprint的工作項目，設法一起努力、互相幫忙，讓團隊可以一起達成團隊目標。
團隊有自己自主的權利，相對就有責任。團隊要為自己的決定負責，團隊有團隊的責任感，對自己的責任範圍的產品的成敗負責。
這樣子權責相符的跑法，讓其中幾個團隊，慢慢跑出了很高的生產力，也跑出了速度。就像是回到了當時創業的「第零階段」一樣，團隊成員互相Cover，一起工作、一起為團隊而努力。團隊成員對團隊的認同感強，向心力也強，團隊內會形成很亢奮的工作氛圍。而如果我們有好幾個這樣子的團隊，那就真的太美妙了。
然後，就出現了新的問題。事情終歸沒那麼簡單。
第六階段：團隊的團隊 - One Team
讓團隊自主管理之後，逐漸形成了超強向心力的專業領域團隊，對團隊而言，向心力很好，但對團隊「之間」而言，就形成了很強的「silo」-穀倉效應，也就是「團隊 v.s. 團隊」之間就出現問題了。
- 因為團隊還是在同一個產品平台上工作，於是團隊之間就需要「協作」；
- 團隊開發的功能之間也有很強的相依性，所以團隊之間就需要「溝通」；
- 因為我們也以團隊的表現做為績效的參考，於是團隊之間也隱含了「競爭」。
團隊自主的結果，也讓某些團隊開始跑錯了方向，各團隊各唱各的調，往不同的方向加速奔跑，結果整個大產品，差一點就被五馬分屍了。
於是我們嘗試在團隊之上 ，成立「團隊的團隊」，我們自己把他叫做「One Team」（缺什麼補什麼的概念）。
所謂「團隊的團隊」，意思就是所有One Team的成員，都是原各團隊裡面的主管階層，做為代表，聚集在一起，在所有團隊之上，形成一個團隊的上層團隊。因為當團隊跑出了了跑步的速度，團隊的團隊就負責拉好跑步的方向。
One Team形成之後，我們做了幾個重要的調整：
- 對齊每一個團隊的sprint週期。所有的團隊一律改成兩個禮拜一個Sprint，並且統一Release的時間。
- 拉齊所有團隊的方向。所有團隊的product backlog都會集中到One Team，One Team會有一份大產品的One Product backlog，做團隊開發相依性的「協調」與「溝通」，做完backlog優先順序的調整，再讓One Team的成員回到自己的原團隊去做討論。
對齊Sprint週期，為了所有的團隊的「節奏」一致；拉齊團隊方向，為了所有團隊是演奏的「樂譜」是同一首歌。整個大產品團隊就像一個交響樂團一樣，雖然各團隊因為自己負責的不同，樂譜有所不同，但大家終歸是演出同一首歌，「節奏」一定要一致，「樂譜」合起來要是同一首曲。
而身為主管層的我們，也終於體會到了Agile的奧妙。透過Agile的落實，團隊會形成自主管理的完整有機體，會自己管理，自我負責，每一天有速度的推進工作，交付產品。而主管層就可以有足夠的心思，討論產品策略、拉齊團隊的腳步，整合團隊的產生。
這個時候，大概有8個左右的Agile Team，我們終於能個感覺到，8個團隊一起往同一個大產品目標跑，而且跑出了推進的節奏感。但，總覺得哪裡還是卡卡的～～。
第七階段：組織重整
一直到了這個階段，大概也走過了五年以上。所謂的「團隊」，已經從「專案團隊」變成「專業領域團隊」，開發方法也從「瀑布」，變成了「敏捷」。雖然團隊的跑法已經演變了好幾代，但回頭過來，其實整個大產品的組織架構，卻仍停留在第一階段，依然還是功能性組織。
也就是說，每一個同仁，等於都有兩個老闆，也會有兩個目標。每個同仁在團隊裡面，要為團隊的目標努力；但每個同仁同時也隸屬於某個部，該部的主管也會要求他另外的目標。
而當兩個工作目標內容完全不同時，同仁就等於要用加倍的時間來完成兩個工作。而當兩個老闆的目標衝突的時候，同仁就常在中間兩邊不是人。
這都是「矩陣式組織」(Matrix）標準常遇到的管理挑戰與議題。
但其實跑到這個階段，團隊已經成為主要的生產單位，本來的功能組織的「功能」也變成不事生產。於是我們開始思考，是不是要整個大規模的做組織重整。
我們決定把整個大產品組織，全部打掉重練。我們把原有的功能組織打散，重新把所有的專業領域團隊部門化。也就是負責生產的團隊，直接轉變成為一個「產品線部門」，從虛擬團隊組織變成一個真正有管理實權的部門。
我們等於直接把一個一個的agile team部門化了。
這些團隊(agile team)，原本都是跨個功能組織所組成，所組成的團隊（虛擬團隊）。我們等於把這些團隊，直接轉變一個部門組織，形成一個產品線部門（實體部門）。
而這個部門的主管，則有的是原有的PO升任、也可能是原有的RD的技術主管。而部門的主管，自然就是One Team的成員之一，同時One Team就變成大產品的重要的決策單位，管理整個大產品組織。
專業領域團隊變成產品線部門後，原有團隊內的PO、UX、RD、QA等同仁，在這些新的產品線部門裡面，變成分別的功能性組織。再反過來在產品線部門裡面，跨功能組出2~3個「團隊」(agile team)，每個團隊一樣跨職能（PO、UX、RD、QA）組成，用Scrum的方法，一個一個sprint推進產品功能交付。
我們等於把原有的功能性組織，打散進去三大產品線部門。然後把整個大產品組織的Matrix，也落進去這三大產品線部門裡面。看起來，一樣還是有功能性組織，一樣還是有Matrix的存在，但整個大產品的跑法的層次就出來了。
- One Team - 負責產品的方向，形成大產品的政策。
- 產品線部門 - 負責實際「團隊的管理」，並落實One Team的策略。
- 「團隊」- 主力的生產團隊，有節奏的推進產品功能。
這個時候，我們大約有12支左右的「團隊」，每個團隊大約有7到15個左右的成員。這些團隊，也就是實際跑Agile的Agile Team。這些團隊是依然是主力的生產部隊。而產品線部門有三個大部，每一個部分別管理 3~5個「團隊」，這些產品線部門是大產品裡面，實際負責「組織運作的管理單位」。而One Team就變成大產品主要的策略單位，負責產品的長期發展，訂立大產品的政策。
而無論是產品線部門，還是One Team，最終的目的都是為了讓所有的「團隊」，可以放心的全力衝刺開發工作，用每一個一個的Sprint，有節奏的穩定推進產品。而其他的議題，就由另外兩個層次的組織架構來解決。產品線部門解決管理與資源問題，one team解決策略與政策問題。
很多人問我們，我們怎麼跑大規模的Scrum，怎麼讓整個200人的產品團隊，一起跑Agile。而這幾個「層次」的開展與佈置，就是我們到目前為止體悟出來的方法，也許我們可以把它叫做「91APP Way」（91APP的軟體開發之道）。
91APP的軟體開發之道仍然在持續往前，從20人到200人之後，我們正在努力的從200人到2,000人，並形成跨國性組織運作。也許再過五年後，我們可以再接續講述這個故事的下一章。
全文來自：零售的科學 https://happylee.blog/91appway/