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

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

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形成之後,我們做了幾個重要的調整:

  1. 對齊每一個團隊的sprint週期。所有的團隊一律改成兩個禮拜一個Sprint,並且統一Release的時間。
  2. 拉齊所有團隊的方向。所有團隊的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/


CC BY-NC-ND 2.0 授权

喜欢我的作品吗?别忘了给予支持与赞赏,让我知道在创作的路上有你陪伴,一起延续这份热忱!

Happy LeeHello,你好,我是91APP的產品長,因為一直在協助零售業做系統,所以寫了很多零售業相關的文章,希望能與大家多交流分享。
  • 来自作者
  • 相关推荐

《第五項修煉》-從組織管理看到人生哲學

RUN!Happy,run 快樂跑
3 篇作品
Trippin & YOU 旅行去
3 篇作品