組織設計的Star Model（7）：People（上）

Nov. 03 21:02~22:40

▲節錄自〈The Star Model〉文章

 

談完《Scaling Lean & Agile Development，簡稱［SLAD］》書中介紹Stat Model的Strategy、Structure、Processes與Rewards，分兩集介紹最後一項People。［SLAD］提出19點關於People的建議，今年先介紹前9點：

• 避免限制人員的視角：傳統上組織大都強調深化單一技能—系統分析師專精於撰寫需求文件、軟體架構師負責設計架構、程式設計師專精於coding、測試工程師專心於找缺陷。這麼做看起來是最佳化單一工作的產能，但過度窄化的專長卻會造成溝通障礙與整合問題，因為不同專長的員工對於彼此的工作內容都非常陌生。因此，組織應該在培養員工深入專長技能的同時，也要提供一個促進廣度學習的環境與機會。
• 避免職稱：職稱鼓勵階層式管理與專業分工—助理工程師→工程師→資深工程師→主任工程師→技術副經理→技術經理→資深技術經理→副處長→處長→資深處長→副總→資深副總…。在這個體系裡面一步步往上爬，組織一大除了容易形成官僚主義，似乎也暗示著官大學問大，底層的人只要扮演好螺絲釘的角色就好，動腦與決策的事就交給長官來負責就好了。

避免職稱的方法之一就是公司員工都沒有職稱，有沒有這種公司？有，Teddy剛出社會的時候所待的公司就是這樣。 稍微不那麼激進的做法，以Scrum來說，建議團隊成員都稱為developer（開發人員），不採用UX、programmer、tester等傳統的職稱。也有公司老闆稱呼每個員工都是「合作夥伴」或「合夥人」。

• 嘗試只建立一種職稱：這一點是上一點的延伸，如果無法不使用職稱，就讓每個人的職稱都一樣。
• 嘗試讓員工自己決定職稱；鼓勵有趣的職稱：如果以上兩點都做不到，可以考慮讓員工自己決定自己的職稱，越有趣越好。例如，催眠者、原力大師、愛玩客、傳道士。
• （如果以上都失敗）嘗試通用職稱加上等級：如果公司的HR堅持以上做法都是胡搞瞎搞，絕對不可行。可以考慮採用幫每個職能訂定一般職稱再加上等級來區分，例如工程師，等級三；分析師；等級五。 
• 嘗試將減化的內部職稱對應到特殊的外部職稱：印在名片上的職稱對於公司內部的員工也許不重要，但到外面交換名片的時候，可能會對於公司以外的人造成綑擾。例如，業務和工程師一起去拜訪客戶，客戶拿到名片一看一頭霧水。沒有職稱，到底這兩個人是做什麼的？難道是公司創辦人？
• 避免（過於詳盡的）工作描述：找過工作的鄉民一定都知道，徵人廣告都會有工作描述（job description），這樣子員工才知道這份工作的權責範圍與所需要的技能。但過於詳盡的工作描述可能導致員工「畫地自限」，只做工作描述有記載的事項，其餘一概不管，也不想學習。
• 嘗試簡單的工作描述：如果完全沒有工作描述員工可能連上班要做什麼都不知道，這樣也不行。所以可以嘗試用比較簡單、一般化的方式取代詳盡的工作描述，例如：「團隊成員對於每個開發迭代的產出物與其他團隊成員負有共享的責任。」
• 避免職涯路徑：大企業通常會針對每一個專長訂定職涯路徑，讓員工可以規劃自己的升遷管道與培訓計畫。在［SLAD］書中所提到的大型Scrum組織中（請參考〈組織設計的Star Model（2）：Strategy與Structure〉），採用以功能團隊為主的扁平式組織結構。在這種情況下，傳統的職涯路徑可能沒有幫助，反而造成敏捷轉型的阻礙。
  

***

▲圖片來源在此

 

看了前9點關於People的建議鄉民們是不是覺得和傳統HR的作法差異很大？ 對於大公司而言，要做到真的不是那麼容易的事啊。

***

友藏內心獨白：有人說HR是第一個可以精簡的部門XD。