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

91APP運作200人以上的SaaS產品開發團隊,透過導入Agile的開發方法,用Scrum的方式有節奏推進交付,並大規模的不停地做組織重整,用91APP Way的三個層次來運作產品開發組織。

Happy Lee 李昆謀
Happy Lee 李昆謀

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

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

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

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

第零階段:最美好的時光

91APP的軟體開發之道-創業初期

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

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

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

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

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

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

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

第一階段:瀑布來了

91APP的軟體開發之道 - 功能性組織

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

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

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

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

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

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

第二階段:上帝之手

91APP的軟體開發之道 - 上帝之手

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

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

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

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

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

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

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

然後問題就來了。

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

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

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

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

91APP的軟體開發之道 - 專業領域團隊

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

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

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

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

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

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

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

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

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

第四階段:敏捷式開發

91APP的軟體開發之道 - 敏捷式開發(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。

相關標籤

🛍️ 零售的科學 91APPSaaS產品發展資訊系統