高效組織永遠是企業想要的, 可是大家都會怎麼去設計呢? LeSS 這邊會希望透過以下原則, 來設計出更簡約的敏捷組織
(1). 從專家角色到團隊
受到泰勒科學管理的影響, 組織普遍提倡單一專家/職能, 他們在這個領域很擅長, 交給他們來做可以又快又好. 可是在現今複雜的社會中, 很難只用單一專業就能解決所有問題, 需要考慮不同角度不同場景, 才能處理掉問題. 此外, 也因為專業的緣故, 容易產生偏見, 或是局部優化. 不屬於自己擅長的部分, 便只能等待其他人去處理. 這樣只是個人最佳化, 不見得能整體最佳, 或是提高適應性
LeSS希望組織以客戶為中心的團隊, 自己決定如何工作和分工. 每個人自然有其偏好, 但不限於單一專業. 原先測試人員, UX設計師或業務分析師這類角色不再存在. 因為這些都變成了團隊的職責, 寬泛的職責和自管理增加了適應性.
(2). 從資源思維到人才思維
傳統組織把人當作資源來管理, 每個人是可以取代的. 就好像在換可替代性的消耗品, 像是輪胎, 毛巾等等, 只要是個數上對得齊, 錢給的夠, 換個人都不是問題
LeSS不會把人視為資源. 為了讓人才可以發揮, 作法是讓人才可以發展新技能. LeSS有意造成現有技能知識和所需技能知識之間的不匹配, 為了增加適應性, 會要求人員去學習. 雖然因此帶來不安, 但是學習到新技能也會有成就感.
(3). 組織從圍繞技術到圍繞客戶價值
傳統組織圍繞著他們的技術來創建組織. 例如前端團隊, 後端團隊, 資料庫團隊, 數據處理團隊等等. 圍繞著專業技術的組織, 看起來能最大化個人生產力. 但要交付價值給客戶, 需要超過一種以上的技術, 所以需要協調各個技術一起合作, 這會讓各個技術團隊減少適應性
LeSS會圍繞著客戶價值來創造組織. 根據系統提供哪些服務給客戶使用, 就依照那些場景來切割團隊, 而非是依內部技術元件來切割. 透過圍繞客戶價值的組織, 讓團隊可以更靠近客戶. 從而導致更大的適應性和更多的客戶價值.
(4). 從各自獨立的團隊到持續的跨團隊合作
傳統組織傾向於能夠聚焦於自己的團隊. 各個團隊為了避免被打擾, 需求會切割清楚, 並且定好明確的介面, 利用嚴格的變更和評審流程, 避免這些介面頻繁變更. 但這卻導致問題常常被隱藏起來, 或者最後才發現問題. 團隊的隔離反而降低了組織的靈活性
LeSS組織傾向於多個團隊之間有共享的工作. 他們像一個更大的團隊在運作, 儘管每個團隊有各自的目標, 但會不時地協作討論, 並且知道其他團隊在做什麼. 有問題很早就會被看到, 可以簡化嚴格的變更和評審流程
(5). 從協調來整合到透過整合的協調
因為團隊有各自的交付, 傳統組織會透過協調者, 來整合不同團隊的產出, 所以會有專案經理, 整合工程師, 發佈經理等來負責協調和整合的事情. 並且協調時產生衝突很正常, 有了衝突後便要重新評估時程和優先順序. 這些協調角色, 是在團隊以外的人, 不一定知道團隊在做什麼, 並且反應也會比較慢一點
LeSS組織要持續整合自己的工作. 透過CI 等機制, 團隊可以及早發現跨團隊的問題, 並且因為平時有共享的工作, 團隊需要自己負責協調
(6). 從專案到產品
傳統組織把開發當作專案來管理, 專案有清晰的起止日期和範圍, 人員被預定分配到專案, 預算根據預定的範圍來編列. 專案成功是如值, 如期, 如預算. 也就是要落實計劃, 但是外面的變化常常很頻繁, 導致這樣的規劃不切實際並且也是種浪費
LeSS把開發當作產品來管理. 產品有清晰的目的, 但沒有固定的終點或範圍. 人員被分配到產品, 不確定多長時間. 預算是根據潛在價值來決定, 不會綁定一個具體範圍. 這樣就留出很多空間來因應變化.
(7). 從許多小產品到幾個廣泛的產品
傳統組織傾向於管理基於技術的小產品, 例如服務、組件、應用或平台. 但是它們需要互相互動並整合在一起, 才能交付給客戶價值. 這樣就導致需要複雜的跨產品協調、優先排序和預算.
LeSS傾向於管理以顧客為中心的廣泛產品. 那些服務、組件、應用程式和平台都屬於一個產品, 只有一份產品待辦清單和一個產品負責人. 以客戶價值來共同考慮優先順序, 而非誰比較大聲. 人員可以依據價值相互支援, 而非只固定在某個產品中
發表迴響