高效研發流程那些事一:打造高效的研發組織架構

游舒帆 gipi
瀏覽人數:13443
要談高效研發流程這回事,首先我想先跟大家聊聊高效這詞。

我對高效的定義是:更快的將事情做對、做好。也就是說產出要快,內容要對,而且品質要好,又快、又好、又有價值才符合我對高效的期待。

「快」,在互聯網時代,通常強調的是應變的快,調整的快,這與組織架構、分工,以及決策過程有關。

「好」,就是交付的品質,說得出做的到,總是能交付出可預期的成果,這與軟體工程的成熟度有關。

「有價值」,則是源自於方向與優先順序正確,這與企業戰略與目標設定有關。

因此,談高效研發流程,我們便不能只談研發流程本身,必須將視野拉到外部環境、企業戰略與組織架構等層面來思考。

兩種最高效的場景

在我過去接觸過千千百百種流程裡,其中有兩類場景最高效:

第一類,製造業的生產線,每個關卡、每個環節都被精密計算,關卡與關卡間毋須溝通,也甚少出現停頓等待前一個關卡的狀況。各關卡只需負責完成它所負責的那項任務,內容的變化性極少,突發狀況也幾乎都被控制,成果的可預測性極高,可以大規模、重複的產出相同的成品。

第二類,全棧型員工,毋須分工,毋須溝通,可以自己一個人從釐清需求、設計架構,到編寫前後端代碼,同時搞定測試與佈署等所有事情。少了溝通這個環節,他不用分心向其他人說明自己的想法,不會有衝突,也不用相依於其他人的工作,這種狀況下,工作還能不高效嗎?

然而,這兩種場景都有很大的侷限性,第一類場景並無法很有效的應對高變化性的環境與需求,即便在今日,多樣少量的按需生產仍有極高的困難度,想當然也很難適用于現今多變的軟體與互聯網環境。

第二類場景的侷限性則在以下兩點,第一,生產力有限,面對較大規模的工作量時,團隊分工顯然會更高效;第二,專業性問題,全棧型員工並不意味著所有的技能點都點滿,例如設計工作他能做到80分,應付初期的需求可能堪用,但當產品逐漸成熟,我們需要設計能提供90分的水準,此時顯然就需要更另一位元更專業的設計師參與才行了。

從上述兩種極端的案例中,我們可以先瞭解到一個最基本的觀念「流程高效的前提是對應了適當的場景,而場景,則源自於我們所面對的挑戰以及所發展出來的戰略與組織架構」,這與我們開頭提到的又好又快相互呼應。

四種企業組織架構

前面一段我們提到了兩類高效的場景,第一類是高度確定性場景,第二類則是高度不確定性場景。這個段落我將為各位摘要一下我經歷過的幾種主要的場景,以及對應的戰略與組織架構。

大家可以先透過以下這張彙整表對這幾類組織結構有個基本認識:

功能型

講究專業分工,基本上製造業或傳統產業,大多仍沿用這種組織架構,因其所面對的環境變化性小,流程與技術的變化性也相對較小,穩定狀況下,明確的分工有助於效率的提升。

產品型

又稱BU(Business Unit)型或專案型,通常是為了快速搶佔市場而組成的團隊。功能型組織分工明確,但容易形成穀倉效應,彼此各自為政,不利於戰略的快速推進,若企業資金充裕,且追求快速推進,一般會讓各產品線或BU自建銷售、行銷、服務等相關功能部門,並且各自進行管理,所有功能的主管權集于一人身上,決策相對高效。當然了,對應的問題或許是資源的重複投入問題。

混合型

一家經營5年以上的企業,可能會具有多個產品或事業,某個產品A已經相對成熟,對變化的可預期性提高,此時可能會從產品型組織轉換成功能型組織;而另外有個產品B則尚在起步階段,仍須快速推進,產品型組織則相對適合。這種狀況下便會出現功能型與產品型組織並存在企業內的狀況,就我過去的經驗,大多數的大型企業最終都會走向這種型態。

戰鬥小組

當你面對極端不確定的環境,例如全新市場、新科技早期的技術探索等,組織過大的產品型團隊一來成本高,二來效率也會受到限制,此時,最佳的解法通常是派出2-3人的團隊組成戰鬥小組,在這團隊中所有人都是多能工,每個人都能同時處理多個職能的工作,如同新創團隊一般,小而全的高效運作。

以創業團隊來說,剛起步時大多都是創始團隊組成戰鬥小組,隨著市場需求的釐清與擴張,會逐漸轉為產品型,然後隨著分工愈來愈清晰,制度愈來愈完善,則會步入功能型,等開始切入第二個產品或事業時,就會變成混合型組織。

企業組織架構與研發組織架構如何高效匹配

前一個段我們談到了企業組織架構,這個段落就讓我們來進一步談研發組織架構如何與企業組織架構高效匹配。

企業在草創初期,走的大多是戰鬥小組模式,研發在此時仍未形成一個獨立編制。但隨著企業日漸成長,公司規模成長到100人,業務、行銷、服務都成立了獨立部門,研發團隊也來到20-30人的規模,為了有效的管理與確保研發資源的最有效運用,研發通常也會被獨立成一個部門,而企業內,也會自然的走向單一產品型或功能型組織。

集中式的研發團隊

習慣上我會稱這個階段為集中式的研發團隊,此時期基本的運作模式如下圖,各部門對研發部門提出需求,研發部門則依循一套機制來排序所有部門的需求,並且按著談定的順序進行開發工作。

然而,企業在此時往往仍在追求快速成長,因此銷售與行銷的需求往往會優先被考慮,而服務與後勤的需求,以及研發團隊針對產品或技術架構優化的需求,則往往被滯後。需求順序往往偏重支援短期的營收增長,而客戶服務與產品優化等長期專案則嚴重被忽略。

分散式的研發團隊

有鑒於集中式研發團隊的問題,許多企業會在此時選擇擴張或重整研發團隊,將一部分的研發資源放在處理各功能部門的短期性需求上,我習慣稱這樣的團隊為功能部門研發團隊;另一部分資源則專注於產品與技術的持續進步上,這個團隊我則習慣維持研發團隊這個稱呼。

經過調整後,各功能部門都將擁有一個屬於自己的小規模研發團隊,所有的需求都可以先提交給這個團隊,若需求本身較緊急,且規模較小、複雜度較低,那就直接由這個團隊直接處理,若判斷後認定為長期需求,則將需求pass給研發團隊來評估與開發。

這樣的組織架構,雖然可以同時兼顧長期與短期的需求,但那些被分配在功能部門的研發成員們則難免會有所怨言,總認為自己所做的事沒有太高的技術含量,更多的是例行庶務與簡單的程式設計工作,時間久了便會失去工作熱情。我們曾經嘗試過輪崗,讓成員能在各團隊間輪替,但在幾次實踐之後,我發現這樣的做法成效並不好。

因為所有人都傾向於做那些看起來更高價值的事,如果技術領導者在做組織分工時,已經先排出團隊價值的高低,那被分派到低價值團隊的成員,自然會覺得自己的工作價值不高,也會覺得自己是不被重視的一群,團隊的向心力、熱情與使命感都會大幅降低。

為了有效的解決這個問題,我們又嘗試了第三種組織架構-矩陣式研發團隊。

矩陣式研發團隊

矩陣式組織架構最主要的特色在於,重新定義了功能部門研發團隊的角色。過去我們指派給這個團隊的任務是支援功能部門排除問題與開發短期需求,現在我們則把各個功能部門定義成一個個獨立的產品,每個產品都有單獨的產品經理負責,而這個產品經理的核心任務就與各功能部門的產出直接掛鉤。

例如,銷售系統被定義成一個獨立的產品,它擁有自己的銷售PM,目標就是讓銷售部門達成所有KPI,可能是業績、退貨率、客單價提升等。

當角色從消極的支持轉為積極的負責後,團隊的定位就更加清晰且重要了。

此外,推動矩陣式組織的另一個觀點是,產品經理可以通過改善產品,或通過運營的手法來促使業績達成30%的增長,然而產品經理始終是產品專長,對於銷售、行銷、服務的理解並不見得非常深入,因此,若能在銷售、行銷、服務等崗位上設立產品經理的職務,肯定也能對增長帶來重大效益。

舉例來說,如果銷售PM能通過技術帶來30%的銷售效率提升,就能一次性的讓多個產品同時受惠;如果服務PM能通過技術更個性化的服務顧客,有效的降低了15%的退換貨,也有機會讓數個產品都得到提升。過去經驗裡,這些PM本身都熟稔技術與業務知識,能同時從兩方思考系統問題,所提出的解決方案往往會比純技術PM或純業務PM來的更加到位。

從這個角度來思考,功能部門研發團隊的重要性便明顯提高了,他們能直接為公司的績效帶來貢獻,團隊成員們有了相對清晰的目標,使命感與熱情便有了非常明顯的提升。

本文跟大家討論了較多關於場景與組織架構的內容,往下幾篇,我將分別與各位聊聊關於研發流程管理的選型、研發管理過程中最困難的幾件事,以及如何打造追求更快、更好、更有價值的組織文化與人才梯隊。

很高興能與大家交流關於高效研發流程這個議題,咱們下次見。



游舒帆 gipi

探索原力共同創辦人,熟悉策略規劃、產品發展與運營,以及數據化管理。現為多家互聯網企業營運顧問,亦為經理人雜誌、inside等多家知名媒體專欄作家,擅長以簡單方式解釋複雜行為,以互利雙贏方法帶動組織變革,個人網站-gipi的學習筆記:https://dotblogs.com.tw/jimmyyu/。


本篇文章主題研發