? 前段時間，公司簽了年終獎確認。覺得公司發放年終獎完全是憑主觀發放，沒有事實依據，由此產生了對如何發放年終獎的一些想法。
獎金發放作為激勵員工最直接的手段，往往也是讓管理人員最難抉擇的，而且很多公司，都是帶有大部分直接主管主觀意識評定的。在我看來，這是最不可取的，因為獎金作為激勵手段，初衷應該是鼓勵員工繼續發揚往年優秀的部分，并識別和看清自身（或者整個團隊甚至部門或公司）的短板，并在來年采取有效的方案或措施進行改進，為自身(或部門或公司)改進提供風向標，這樣才能做到自身水平的不斷提高，為公司創造更大的利益。所以獎金的方案必須是公平公開并且是透明的，而不是不可議論的。至于薪資，可以作為一個保密項，但是獎金比例是完全可以透明，并由直接主管作為橋梁來溝通并指出不足。
至于獎金的考核方案，我先舉個栗子，假設某團隊是以敏捷開發作為管理框架的，評估工作量以故事點作為標準。這里說一下以故事點作為評估工作量的單位。在實際工作中，一個團隊可能有初級、中級、高級的開發人員，他們的技術水平是不一樣的，但是如果是對同一個功能點進行功能的評估，假設需求理解都是一致的情況下，他們完成該功能的時間應該是會不一致的，所以以時間作為評估標準是很不可取的。但是，他們完成不同功能的評估的故事點應該是一致的。我們來幾張圖標說明會更清晰。
對于三個功能，他們評估的故事點可能是這樣的：
他們評估的人天數可能是這樣的（這里為了演示，將他們的比例誤差設置為0，即都是按一定比例估算的，實際上應該會有一些誤差，但是趨勢應該是一致的）：
上面倆張表可以看出，對于能力不一樣的人，他們評估的人天數肯定是不一樣的。你可以假設一個小學生，跟一個大學生搬磚，同樣是100塊磚，比較他們完成的時間。那么我們如何在做績效考核的時候，能夠排除這些能力因素，或者說，能夠達到多勞多得，并且為調薪提供一個比較公平客觀的依據，并能不斷讓開發人員認識到自己的不足并采取改進措施呢？
我認為，敏捷大法不僅僅適應于項目管理，同樣適用于人員的管理。我的方案是，在每個迭代結束時做Sprint Retrospect會議的時候，不僅僅針對團隊，同時可以收集一些數據，例如：本次迭代完成的故事點數、測試bug數、代碼注釋率、代碼簡潔渡(這個比較難，能力上提高了的話，代碼自然會簡潔)，同時，針對個人在這幾方面的數據進行分析，找到自己的薄弱點，采取措施(最好是可量化的)，將每次迭代的數據都記錄到信息發射源。當然，對于表現優秀的，可以采取一些獎勵措施，比如說榮譽墻，涂鴉墻，甚至是調休獎勵。下面，我們看一下我們收集到的故事點的信息：
我們將這些數據制成圖表：
圖表就能看出，每個人每個月(或每次迭代)完成的故事點數的趨勢，很清晰的可以看出哪些人在進步，進步最大的員工是哪位。也可以以此來作為調薪的依據。
我們再將上面的表格做一些修改：
? 我們將所有的月份的故事點加起來，就是這一年完成的故事點總數，再將團隊內所有人員的故事點，取比值，以小李的故事點為基數，小李的故事點比值為1，老張的未423/270=1.566，小陳的是350/270=1.296，同樣，我們將薪資比例計算出來。這樣，我們就可以用這些比例來確定獎金和調薪幅度等。還是如上例子，我們假設年終獎的基數是3個月，那么小李應該得到的獎金應該是1*3*15000，老張應該得到的是1.56*3*30000，小陳應該得到的是1.296*3*24000。這里我們是以故事點(即工作量)這一單一維度來計算的，我們也可以結合其他指標加權來計算這個年終獎。
我們再看一下調薪比例，我們可以用故事點數比值/薪資來確定調薪，這樣就將能力與當年的表現結合起來了。如果格局再高，同樣也可以通過制定部門年度目標或季度目標，來考核部門并確認部門獎金比例。
?
本文寫得有點啰嗦，大家可以發表自己的一些看法。
?
)
：實現購物車)
