，使得一些重要的事情會被拋之于腦后，而一些難度小確信能夠完成的事情會被當(dāng)作重要事項看待，從而導(dǎo)致重要的、緊急的事情沒有做，而不緊急的事情卻很好的被完成了，形成本末倒置的現(xiàn)象。
3.拋開KPI、3-5件事的評價體系的有效性不說，KPI與3-5件事帶來的管理成本也很高的。尤其在我們公司實現(xiàn)季度KPI+月度3-5件事的考核模式，則更加重了管理負擔(dān)。假定某個月份既要做KPI考核又得做3-5件事考核，我們以一個35名員工的部門管理者來說：在月初，首先需要制定35份員工的KPI計劃，并與員工達成共識，我們以每份30分鐘計算，將消耗管理時長30*35=1050分鐘;然后再制定35份員工3-5件事，也以每份30分鐘計算又將消耗管理時長30*35=1050分鐘;在月末，先針對3-5件事，進行數(shù)據(jù)采集，評判，消耗管理時長30*35=1050分鐘;然后，對每個員工季度的KPI進行數(shù)據(jù)采集、評估、溝通，每份以50分鐘計算將消耗管理時長50*35=1750分鐘。這樣四項時間累計為1050+1050+1050+1750=4900分鐘，以每個工作日扎實工作7小時計算為11.7工作日。上述時間還不包括部門的KPI、月度3-5件事制定。一個月22天的工作日，將有一大半時間耗費在這樣的考核上去，必然對日常的管理造成極大的沖擊，而一些真正需要管理、把控的東西，如需求分析、迭代會議、迭代演示、沖突解決、架構(gòu)設(shè)計、組織協(xié)調(diào)等丟棄一邊了。
我們仔細地分析上述問題，可以得出一個上述KPI+3-5件事考核存在的弊端的根源，人為的定義一些難以評判員工的指標(biāo)或者任務(wù)，并導(dǎo)致管理成本的增加。那么是否可以尋找到一條在現(xiàn)成研發(fā)體系中存在的可度量手段并以此為依據(jù)進行員工評價的路徑，成為解決問題的關(guān)鍵。
我們知道在敏捷開發(fā)SCRUM模式下，需要準(zhǔn)備任務(wù)的backlog并在迭代啟動前把任務(wù)分解成一個一個不可再分的子任務(wù)，然后由開發(fā)人員評估每項子任務(wù)的工作量，并把任務(wù)分配到開發(fā)人員手中。在上述過程中，客觀的進行了工作任務(wù)的分解和工作任務(wù)的度量，而歷史的團隊績效數(shù)據(jù)則成為進度估算的依據(jù)，尤為重要的是這些度量是被接受并被承諾的。而“建立估算”、“開發(fā)項目計劃”和“獲得項目承諾”是CMMI中"Project Planning"域的三個特定目標(biāo)。與3-5件事中的任務(wù)制定和分解比較，這里的數(shù)據(jù)沒有經(jīng)過人為修飾，是客觀實際情況的真實反映;而且這些任務(wù)分解不是為了考核而考核，而是為了項目推進而進行的，并沒有額外的增加管理工作;更重要的一點是，除了完成與否之外，還有具體每項子任務(wù)所需要的工作量(估算點)，可以方便的度量項目每個人員付出的勞動量的多少。因而在SCRUM模式下，3-5件事是簡單的、不完整的、多余的。
績效考核最終的目的是為了能夠客觀的反應(yīng)人員在工作上的投入度、獲得的成果，從而識別出優(yōu)秀者與糟糕者。3-5件事是績效考核的一個補充手段，并非全部，我們往往還有每年或者每季度的一系列KPI指標(biāo)。就像前面所說的一樣，針對研發(fā)人員而言，這些指標(biāo)往往不具有有效性，因為缺乏有效的度量手段?？墒窃赟CRUM模式下，對于工作量的度量卻能夠做得非常容易了，因為我們可以輕易的獲取到每個開發(fā)人員所完成的故事點(工作量)。
因而，在SCRUM模式下，無需額外的進行3-5件事，管理者可直接關(guān)注到每個項目的完成情況。在進行績效評價時，可以方便的獲取到工作量數(shù)據(jù)，有效解決KPI指標(biāo)失靈問題。
上面的結(jié)論，讓人很輕松，我們找到了一個有效的績效考核方法。不過，上述方法還存在一定的瑕疵：在SCRUM模式中，度量更多的是針對開發(fā)人員，缺乏對測試、需求、實施人員的有效度量，雖然開發(fā)人員占了研發(fā)50%以上的人員比重，但畢竟他們不是全部。