組織設計的Star Model（8）：People（下）

Nov. 04 12:00~14:20

▲節錄自〈The Star Model〉文章

 

今天把《Scaling Lean & Agile Development，簡稱［SLAD］》書中關於Stat Model的People分類所剩下的10點建議介紹完畢：

• 嘗試工作輪替：將員工調動到不同的功能部門是一種很好的跨職能學習方法，輪調時間短則數月長則數年。這個制度在許多公司早已實施，推行起來阻力應該不大。
• 嘗試工作輪替：工作輪替的時間越快越好，在日本的Toyota，新人必須要通過一般訓練，包含在工廠裡面組裝車輛，然後到第一線去賣車。如此可傳達這樣的訊息：「你為Toyota工作，而不是為某一個特定部門工作」。

Teddy有一個客戶也有類似的做法，新人到公司報到之後必須要先在支援部門工作一段時間之後才分發到各個不同的團隊。讓新人在一開始的時候就親身面對客戶所提出的抱怨，也同時藉此了解公司的所有產品是如何運作。

• 嘗試聘請最好的人才：公司都想找最好的人才（至少老闆嘴巴上都這麼說），軟體開發公司尤其是如此。原因很簡單，因為軟體是人寫出來的，Toyota也有「造物必先造人」的說法。個人之間的生產力高低可以相差到10倍。與其想用低薪找便宜的人，還不如用優於同業的待遇找到最好的人才，對公司而言才是真正的高效益。
• 避免找不到最好的人而被迫聘用：好的人大家都要搶，公司經常在搶不到好的人的情況底下，被迫找次一等的人。對軟體開發而言，用少數傑出的人比用許多一般能力的人要來的好。因此，儘量避免因為找不到合適的人而隨便找一個人來充數。
• 嘗試讓團隊決定聘用：傳統上是否聘用新人都是由主管、高階主管，以及HR來決定。這些有決定權的人，未必會與新人一起工作。如此便可能產生「聘用」與「使用」的落差。相信很多鄉民都有遇過「這個 天兵 新人是誰找進來的」那種疑問（迷之音：更可惡的是薪水居然還比我高XD）。

因此在找人的時候可以嘗試讓團隊參與這個過程，甚至讓團隊擁有決定權。面試官不要僅限於主管，可以廣邀有興趣的團隊成員一起參與。 

• 嘗試長時間與深入的實作評估：有的人寫的一嘴好程式，混進公司之後才發現嘴砲功力遠大於實作能力。面試的時候加入實作測驗是一種方法，但實作的題目有時候又可能淪於傳統的資料結構、演算法考題（比較容易準備且無法反應出軟體開發流程面的因素）。因此，可以嘗試請新人和團隊成員一起工作幾個小時，來實際感受與評估新人的能力。
• 嘗試與面試者結對編程：如果面試者是開發人員，最好的實作評估方法就是結對編程。花個半天到一天的時間結對編程，很容易可以發現面試者的能力與限制。
• 嘗試試用代迭：如果面試者通過結對編程，但你想更進一步確認他是否可以和團隊合作愉快，則可以嘗試請面試者參與一個迭代（iteration）開發。當然公司需要支付費用給面試者，而不是要求面試者「無償實習」。
• 嘗試很多正規教育與指導：敏捷與精實開發思維牽扯到很多技術、行為與思維的改變。包含Scrum、TDD、CI、自組織等。這麼多的學習項目，必須要安排正規的培訓以及指導（coaching）活動，才能夠讓團隊在一個共同的基礎上，順利進行敏捷轉型。
• 嘗試很多指導活動：有些想法可以在培訓課程中交代的很清楚，有些則需要在實際工作中經由顧問的指導（coaching）來落實。例如，Design Pattern、單元測試、refactoring、TDD或CI。很多人上課之後覺得很棒，但實際回到團隊中，要落實卻遇到很多阻礙。例如：遺留系統（legacy code）太複雜又沒有測試案例，不知道要如何著手、團隊同仁不配合，光是我自己一個人也搞不起來。在這種情況下，在上完培訓課程之後，如果可以搭配顧問的現場指導，和團隊成員一起從專案中解決問題，可以讓讓這些實務做法比較容易扎根落實。

***

▲泰迪軟體2016年新課程表

*** 

只要營造好的環境，找到好的人（對的人），給他們優於同業的報酬，然後讓這群人自組織解決問題，組織的戰鬥力就可以被解放出來。敏捷轉型需要學習很多新的技能、知識、心態，要落實敏捷轉型最快的方式就是找到合適的培訓課程，以及導入顧問或教練，協助團隊度過這一段轉型期。自己慢慢試當然可以，但這種做法不但省不到錢，最糟糕可能會白忙一場，徒然浪費時間而且沒有達到組織原本設定的目標。

***

友藏內心獨白：對企業而言，能用錢買時間大都是划算的交易。