Oct. 28 11:50~14:30
▲節錄自〈The Star Model〉文章
Star Model剩下的兩個類別—Rewards（獎勵）與People（人）在傳統上主要是由Human Resources（HR，人力資源）部門所管轄的範圍。今天和明天分兩集先談Rewards。
在敏捷開發中，開發活動由團隊所驅動，但傳統的HR在打考績的時候卻是採取以個人為主的考核方式。這兩種不同的思維方式造成了本質上的衝突，因此在敏捷轉型的過程中，希望HR可以思考獎勵制度如何能夠促進真正團隊的成形。
***
《Scaling Lean & Agile Development，簡稱［SLAD］》書中建議了幾點可以嘗試的做法：
- 嘗試讓HR參與：公司內HR原有的制度不會因為「敏捷開發」這個理由而一夕之間突然改變。想要改變這些行之有年的的做法，需要邀請HR一起參與敏捷轉型。例如，讓他們接受敏捷精神、Scrum、敏捷轉型等培訓課程。這樣可以協助HR將現有的制度調整到符合敏捷與精實開發的做法。
這一點Teddy有切身的感受。今年有一個敏捷轉型的客戶，HR負責人就和開發團隊一起上Scrum培訓課程。而這位HR負責人也跟Teddy討論很多HR在敏捷轉型過程中所扮演的角色以及哪些傳統做法需要調整。
- 嘗試詢問HR可信的研究證據：通常公司越大，越難改變現行做法。對於大公司的HR主管，有時候就算你已經提供了很多證明敏捷與精實開發優點的證據或研究資料，他們還是有可能基於一些深信不疑的假設而不願意接受新的觀點。這時候可以反過來請HR提供支持現有做法的證據，也許在尋找證據的過程中，可以讓HR自己重新思考現有做法的合適性。
- 避免將表現連結至獎勵措施：每個人都是組織內工作流程的一環，很少有個人的表現可以直接反應的最終結果的成效。就算可以，原本獎勵措施是希望提升員工把工作做好的動機，但是一旦將獎勵與工作掛勾，最後只會提高員工追求獎勵的動機，而不是做好工作本身的動機（原文是：Giving a reward for a job well done motivates a person for the reward but not for the job.）。
例如，媽媽為了鼓勵小朋友養成幫忙做家事的習慣，每次只要幫忙洗碗就給50元獎金。小朋友為了賺零用錢一開始看起來很樂意幫忙洗碗，但是一但取消獎金，小朋友再也不願意幫忙洗碗。媽媽提升了小朋友賺零用錢（獲得獎勵）的動機，而非做家事這件工作本身的動機。
- 嘗試淡化獎勵：獎勵措施是管理者很喜歡使用的工具，因為它的確有短期的「刺激效果」。例如，第四季只要業績提升20%年底業務就加發獎金。但就像吸毒一樣，這種刺激的效果很短暫，很快你就需要另一波的獎勵措施來刺激你的員工。搞到最後只要沒有獎勵就沒有人想努力做事。
哪怎麼辦？如果無法完全取消獎勵，至少淡化它的重要性。強調其他可以增強內在動機（intrinsic motivation）的因素，像是提供具挑戰性的任務、有意義的工作（所開發的產品或服務真的可以改變世界，至少真正解決客戶的問題）、在工作中學習、提升成就感以及促進個人成長等。
- 避免獎勵與生產力度量掛勾：生產力越高，代表員工表現就越好，這聽起來是很合理的假設。但對於軟體開發這種知識工作者而言，想要度量「生產力」有時候可能會造成反效果（因為生產力很難度量）。一個常用的軟體生產力度量就是程式碼行數（line of code, LOC）。如果公司的獎金依據每人個所寫出的LOC來發放，鄉民們應該可以預料會發生什麼事—鼓勵開發人員產生大量的重複程式碼（duplicated code）。
《Measuring and Managing Performance in Organizations》這本書提出區分full measurement與partial measurement的看法。Partial measurement會導致最佳化度量數字本身，而不是原本設定的目標（區域最佳化）。例如，軟體開發的目標是希望產生更多對使用者有價值的功能，而不是更多程式碼，這兩者是不相等的。LOC是一種間接度量功能的數據。如果度量的數據離目標越不直接，這個數據就越容易被扭曲。
度量就是一種KPI，用得不好（很遺憾在大部分情況底下都是這樣）很容易讓開發人員以犧牲品質、累積技術債的方式來優化度量數據。
***
好的獎勵制度可以提升團隊士氣與凝聚共識，發揮員工的戰鬥力。不好的獎勵制度很容易造成組織分崩離析，離心離德，抵銷員工的戰鬥力。真得不可不慎啊。
***
友藏內心獨白：每個月五號最快樂。
沒有留言:
張貼留言