l

2015年10月23日 星期五

Subtle Control

Oct. 19 15:11~16:45

擷取

 

昨天提到〈The New New Product Development Game〉文章提出「新的新產品開發方法」—Rugby approach(橄欖球方法),其中第五個特色是subtle control(含蓄控制)。今天詳細介紹一下這個特點。一個自組織團隊並非不需要管理,若是採用subtle control策略,有下列七個步驟可參考:

  1. 謹慎挑選團隊成員,觀察團隊合作氣氛,並且視需要增減團隊成員。有些人就是天生不對頭,把兩個死對頭的人故意放在同一個團隊裡面,就算最後他們可以勉強一起合作,長時間的摩合期加上脆弱的合作關係,對團隊可能是有害的。有些人很適合在command-and-control(一個口令一個動作)的模式下工作,但自主管理的能力非常薄弱,這樣的人也不合適直接放在自組織團隊中。
  2. 建立一個開放工作環境。
  3. 鼓勵開發人員到第一線聆聽客戶的心聲。
  4. 建立基於團隊表現而非個人表現的績效考核系統。
  5. 管理開發步調,避免專案一開始轟轟烈烈,到了結尾的時候大家都沒力了。換句敏捷開發(XP)的術語,就是要讓團隊維持Sustainable Pace(可持續開發步調)。
  6. 容忍與預期犯錯。Handa的工程師說:「1%的成功率來自於99%的失敗」。犯錯是正常現象,關鍵在於儘早發現錯誤,從錯誤中學習,採取步驟立即改正。
  7. 鼓勵供應商也採行自我組織。在設計的初期就邀請供應商參與,但不需直接告訴供應商要怎麼做,讓它們發揮自己的創意,找出自己的解決方案。

***

看完這七個步驟,鄉民們有沒有聞到濃濃的敏捷開發味道?除了第7點敏捷開發比較少直接討論以外(精實開發有類似的作法),其他1~6點根本和敏捷開發所談的沒什麼不同。

組織一個有戰鬥力的團隊並非易事,但卻很有價值。《SCRUM:用一半的時間做兩倍的事》書中提到,好的工程師和差的工程師生產力可相差十倍。好的團隊和差的團隊,生產力則可相差一萬倍(信不信由你 XD)。看一下上面七點,回想一下自己的敏捷團隊,有沒有什麼可以改進的地方呢?

***

友藏內心獨白:考古的工作還是有其必要。

2 則留言:

  1. Hi, Teddy
    今日有幸拜讀此篇, 看到第四點
    "建立基於團隊表現而非個人表現的績效考核系統。"
    這點是否不容易達成? 若以scrum 來說, 以整個團隊為考量來打考績, 感覺很難公平
    獲得的獎勵相同, 但有些人事情就是做得比較少
    近日有感...

    回覆刪除
    回覆
    1. 『建立基於團隊表現而非個人表現的績效考核系統』可以解釋為在設計考核項目的時候以鼓勵團隊表現為主,而非只鼓勵個人表現卻傷害團隊合作(個人很強但團隊的專案或產品開發失敗,對公司來說也是沒有意義)。在實務上的確很多公司還無法做到沒有個人考績,關於在敏捷開發中如何打考績又不要傷害團隊合作這件事,可參考《Management 3.0》。

      刪除