概述
最近比較流行OKR，即目標與關鍵成果法，這是一種定義和跟蹤目標及其完成情況的管理工具和方法。在執行上和GitHub的Issues比較相似，正好符合我們團隊的管理方式，可以較好地進行實踐。目前任務貢獻核定遇到了幾個問題：
1. 優先級中包含了順序因素：實際上優先級可以反映任務的輕重緩急，也就是任務的**難度**和**緊急度**，但是由於在優先級中加入了任務間的順序因素，無法很好地反映以上兩點。比如，`吃飯喝水`和`上廁所`在一天的生活中都是十分重要的，優先級應該基本一致，但是由於加入了順序因素，`吃飯喝水`的優先級肯定是高於`上廁所`的。如果需要進行公平的貢獻評定需要分割每個因素，也就是用不同指標標注任務的`難度`、`緊急度`、`預估時長`以及`關聯任務執行順序`，由於指標較多，制定每個任務的指標將變得異常麻煩。
2. 預計時長估計困難：由於對各個同學的個人實力不是很了解，而且很多情況無法指定量化詳細的指標，每個人實際工作時長和預估時長差異較大，任務成果質量和預估時長的工作量不符合。並且有些人可能會刻意謊報任務時長，造成貢獻評定中對時間的因素的核定無解。目前只能默認各個組員是在誠實的情況下反饋工作時長。
3. 任務評價中PM個人傾向影響較大：團隊其它組員和PM沒有上下級隸屬關系，而大部分任務質量的評價就好像語文問答題一樣，是一項相對開放的問題，其它組員對PM主觀評價可能會出現較大的爭議。但是暫時沒有更好的客觀評價方式，如果對每一個任務進行**選擇題**般精確的指標指定是不可能的，一是PM對每個執行者的執行細節不是完全了解；二來這樣做工程量巨大，需要花大量時間調研，極可能比任務的執行還要慢很多。
在參考前序團隊的團隊貢獻分配計划后，以三個因素來評定團隊貢獻值，即工作成果評分、實際工作量（時長和編碼量、難度等綜合商定）和完成系數，這樣較為客觀地從各個方面反映了每個階段任務完成情況。
評定方式
計算公式
Issue評分 = ((Issue個人評分×0.4+IssuePM評分×0.6)×0.5+(周個人計划工作量/周團隊實際工作量)×0.5)×完成系數
參數解讀
- Issue個人評分：對自己Issue完成結果的評分，范圍為0~1。
- IssuePM評分：PM對執行人Issue完成結果的評分，范圍為0~1。
- 周個人計划工作量：每周為一個評分階段，即這一周的個人計划工作量。
- 周團隊實際工作量：每周為一個評分階段，即這一周的團隊工作總量。
- 完成系數：任務進度檢查時完成的百分比。
注：這里由於每天都有且只有一個任務，實際上任務布置的先后順序基本與任務優先級一致，因此優先級在這里效果不明顯，不予采用。
這也是與前序團隊不一樣的地方。
總貢獻計算
每周結束為Issue評分時刻，也就是說整個軟工工作周期一共有8個評分時刻，每個人的Issue評分會進行累積。目前團隊有5個人，也就是總共有250分的團隊貢獻總分，α和β階段分別占125分，每個階段的貢獻值=125×(個人Issue累積評分/團隊Issue累積評分)。最后將兩個階段的貢獻值加合便是整個軟工項目的團隊貢獻總值。
Issue制定Tips
- 發布頻率：每2天制定發布一次團隊Issue。
- 標簽制定：目前Issue有3個任務標簽，分別是
size、priority和deadline。size即工作量，分5個級別，deadline是截止時間，一般為兩天后。發布Issue后，如有異議，執行者在12小時之內對PM進行反饋，過時無效。 - 任務詳情制定：任務詳情是執行Issue的概述綱領，需要仔細閱讀。發布Issue后，如有異議，執行者在12小時之內對PM進行反饋，過時無效。