前陣子開始釐清薪資與績效的抉擇的觀念後,不時有人問我說:
一個人績效賺的不多,團隊合作是否能賺比較多呢?
在用幾篇文章釐清因果關係後,我的直覺也開始告訴我,團隊合作好像真的能賺的比較多,雖然沒有實際去驗證,但先前的研究讓我覺得團隊合作下賺的績效獎金絕對能夠屌打個人拚出來的績效獎金。
But!就是這個But!近期剛設計好計算個人與團隊的績效理論模型,並將現行計算個人績效的方法,與假設團隊績效的公式套入比較後,發現結果跟想像中的不盡相同!
最終出來的結果大相逕庭,理論上團隊合作所獲得的總體績效,確實屌打每個人單打獨鬥後所加總起來的團隊績效,但現實中的操作,卻是反之,個人單打獨鬥所加總起來的團隊績效,卻是勝於團隊合作所獲得的總體績效。
意外的結論,也讓我重新體驗一回何謂
也再次打臉自以為是的認知,是多麼經不起推敲。
現行版本的計算方式
績效分成兩種方式計算,一種是用團隊整體的數值下去計算,一種是個人績效算出來後再加總成團體績效。
以下圖舉例來說:
團隊績效有兩種計算方式:
- 可以從總公斤數除上總採果時數,可得出平均每小時速度,最後就能算出團隊績效獎金為1479.78。
- 個人績效加總則是1480.06。
兩種算法得出來的結果只有小數點進位的差異,可以忽略不計。
兩者計算的差別在於,計算個人績效時,沒有達到公司標準的每小時採300公斤,該者的績效為零,但如果是算在團隊績效時,低於目標值的採手會將團隊績效給吃掉。
將原本的16位達標的採手,現在再配上5位未達標的採手,用上述兩種計算方式,分別算出1404.55(團隊計算)與1480.06(個人加總),而兩者得出的結果差異,就是該5位未達標的採手所稀釋的團隊績效。
假設版本的計算方式
簡單說明一下假設的算法邏輯:
- 將團隊最快的採手當作核心
- 其他人將採到的重量分給核心採手
- 核心採手分到的獎金,依照貢獻值比例,將績效分給團隊成員
- 比較現行與假設版本,哪種方式可以讓團隊與個人獲得的績效最大化
依照考慮公司要求的低標方式不同,又分成兩種假設:
- 僅看團隊低標,不看個人低標
- 看團隊低標,也看個人低標
假設1:僅看團隊低標,不看個人低標
在這假設下,我們只考慮只有一個核心採手是有重量的,其他採手不論採多久,雖然保有時數,但一周下來的時數皆為0,但原則上整體團隊的採果量、每小時採果速度以及工作時數,都要與現行方案完全一樣才是,唯一有變化的,就在於績效獎金多寡的差異上。
同現行版本中所假設21位採手,其中16位達標,5位速度低於公司標準的情況下,在不考慮公司訂給採手的最低標準(每小時300公斤),來看看各項數值是如何變化:
由上表可知,核心採手僅採了9973.67公斤,剩下的194086.59公斤都是由其它採手貢獻,團隊的工作時數、時速、總公斤數都跟現行方案的數值是一樣的,唯一的變數全集中在核心採手身上,績效獎金從原本的1404.55元(若用個人績效去算則為1480.06元)變成5846.33元!共差了四倍之多!
雖然核心採手拿了那麼多績效獎金,但是團隊合作來的,理當要在分紅給大家,不然下次誰要在找他合作呢?
因此我們依照貢獻值,用以下方式將績效獎金照比例分出去:
假設1的個人績效獎金=原來的獎金/原來的團隊獎金*假設1團隊績效獎金
21位採手,其中5位速度低於300Kg/Hr,因此貢獻值仍然為0
這方法會讓原本就有績效拿的人,比公司的現行方案多拿快4倍的獎金!
但這方法會延伸出速度未達300公斤的人,因為原先的獎金是0,所以假設1的情況下還是拿不到績效,雖然他們對團隊有絕對貢獻,但不論團隊整體績效多寡,他們都分不到任何一塊蛋糕,會導致速度不達標的人可能會不願參與團隊合作。
因為核心採手的公斤數幾乎都來自其他採手,若改用公斤數當作貢獻值,更能反應每個採手的貢獻度:
假設1的個人績效獎金=採果重量/團隊總重量*假設1團隊績效獎金
用採到的公斤數當作基準,即便速度未達標,也能獲得相對應的績效獎金
從上表可以明顯看到,每個人能獲得的績效獎金都顯著提升,雖然採得快的人分到的獎金比用績效比例算的方式少了些,但這樣人人有份的分法,較能促進長久的團隊合作,畢竟造的餅越大,那怕份額少,領的獎金也是原先的兩三倍。
假設2:看團隊低標,也看個人低標
假設2與假設1最大的差別在於,我們發現績效最大化的方法,屌打慢慢靠時數去撐起的微薄薪水,可是現實中公司不一定能接受團隊績效達標,速度表上卻只有一位採手超標,其它人的速度都是0的情形。
因此假設2可說是為了更能貼近現實而有存在的必要,多了個每位採手壓在公司每小時要求300公斤的限制式,每小時多出來的公斤數才能分給核心採手。
同上述假設21位採手,其中16位達標,5位速度低於公司標準的情況下,在考慮最低標準每小時300公斤的情況下,各項數值的變化:
由上表可知,核心採手僅採了9973.67公斤,剩下的46027.59公斤都是由其它採手貢獻,團隊的工作時數、時速、總公斤數都跟現行方案的數值是一樣的,該數值都跟假設1也都一樣,但因為假設2只有在每小時超過300公斤的部分才能分給核心採手,最終結果為假設2的績效獎金跟現行方案是一樣多的!
同樣我們依照貢獻度,用以下方式將績效獎金照比例分出去:
假設2的個人績效獎金=原來的獎金/原來的團隊獎金*假設1團隊績效獎金
21位採手,其中5位速度低於300Kg/Hr,因此貢獻值為0,獎金也為0
現行績效獎金的算法是個人計算,因此全部加總起來的績效為1480.06元,但是假設1與2都是打團體戰,是將大家的績效放到其中一個人身上,把他當作團隊指標,最後在將那個人的績效獎金照貢獻比例跟紅給大家。
這也是為什麼假設2的團隊績效算出來只有1404.55,因為少掉的75元都被速度不達標的採手給吃掉,連帶只要速度達標的採手績效獎金也會跟著減少。
如果換作公斤數來反映貢獻度:
假設2的個人績效獎金=個人採果重量/團隊總重量*假設2團隊績效獎金
速度低於300的採手也能分得獎金,等於是用其它採手的績效補貼過去
從上表得知,用重量計算貢獻值的方式雖然人人有獎,但是採慢的人獎金是從採快的人那邊補過來的,慢手得利但快手吃虧,用這種方式計算分紅的話,只會讓快手退出團隊合作。
因此假設2最大的問題就在於:
如果團隊沒有人速度低於300,個人績效加總的團隊獎金(現行方案)=團隊績效獎金(假設二);
如果團隊有人速度低於300,個人績效加總的團隊獎金(現行方案)>團隊績效獎金(假設二)。
正所謂牽一髮而動全身,簡單來說,假設2最佳解就跟現行方案拿到的績效獎金完全一樣,不會有更高的情形了。
在蛋糕有限的情形,要做到互不吃虧已經是相當困難,何況自已的蛋糕被人動了,自然有著要捍衛到底的理由。
結論
以下依照現行方案、假設1(績效比例、重量比例)與假設2(績效比例、重量比例),整理出各方案績效獎金的比較表格,再將每個採手能在哪個方案中拿到最多的績效獎金用紅字做標記:
理想解
假設1毫無疑問輾壓其它方案,而在假設1大勝的情況下,分贓的方式又以重量計算貢獻值的方式優於績效比例,因為在沒有考慮個人達標的情形下,每個人速度都是0,採的重量都扎扎實實加到核心採手的重量上,因此推出來的高績效獎金,自然是人人有份。
雖然這解很美好,但鑽政策規定上的漏洞,攸關公司利益問題,公司不可能會願意多付幾倍的獎金給採手,因此如果真在現實中發生,除非公司給採果主管的要求就是只看團隊績效,只要是達標且數值正常即可。
假設1就是建立在此推測上,採果主管如果只是公司的應聲蟲,那麼自己的主要份內工作,就是顧好自己的團隊達到公司要求的團隊績效即可,個人速度與公司付薪水的部分,就不多管也不歸他管了。
畢竟採手裏頭,也是有採了半年下來但沒幾次達標的老手留在團隊中,表示公司與部門,對於未達標的採手還是有容忍度,只要團隊績效有達標,個人速度的部分就睜一隻眼閉一隻眼(個人推測)。
現實解
早在入職受訓時,就已經清楚說明要求的速度目標,因此假設1的理想很豐滿,不是說不可能,只是現實中實施的可行性不高,而假設2就是為了補上這個規定,但出來的結果是
與其改用假設2,不如保持現狀不變。
當大家都有錢賺的時候,沒人會計較太多,但假設2不論團隊績效獎金怎麼分,都會有快手與慢手不滿的問題發生,因此假設2的難題解法就是將團隊分成達標與不達標組,不達標組確定只有時數沒有績效,這樣也能避免達標的採手速度被吃掉。
只是達標組速度再快,績效獎金再高也就跟公司現行制度下計算出來的值是一樣的,與其這麼麻煩,分成兩組可能還會造成對立,破壞採果團隊氣氛,不如就維持現狀,大家各自為戰的團隊績效還比假設2來得好。
後記
近期有朋友在鼓吹打團體戰,因此特別研究怎樣合作才能讓績效收益最大化,透過上述分析,發現每小時採300公斤是一道吃績效的鐵門檻,想要賺績效獎金,就必須先跨過去,不然就是索性放棄它。
就如假設1所述,避開每個人都必須跨越的坎,僅有核心採手一人需要達到績效門檻,而其他人的重量疊加在核心採手已經跨越的門檻上,因此團隊的採手越多,採的越重,團結力量大的效果加成自然就愈驚人。
正因為只有在假設1的情況下獎金才能顯著成長,雖然表面上的團隊績效不變,但速度表上大家的速度卻都為0,而且績效獎金還得加發原本的好幾倍出去,因此必須考量到公司是否不認帳的情形,甚至改變規定或是直接解雇員工。
因此實務上想要驗證假設1,可以小幅度使用假設1的方式配速,多次、多方面試探部門主管看到速度變化後的反應與態度,最好的方式就是在摸索期,透過詢問或是試探的方式,了解公司對部門的期待與規則,以及部門主管在回報每天或每周速度的流程與情形,頂頭上司是否對這樣的異常有任何表示,或是只要團隊績效有達標,壓根就不管這回事。
至於是否會在實務上實驗與驗證,那又是另外一個故事了,就看後續有無相關文章更新拉~
文末至此,我們有緣澳洲見!
位於塔斯的卡塔瑞克特峽谷( Cataract Gorge Reserve)