1樓：java開發
只要你堅信任何東西都可以量化，那麼就可以制定出考核的標準。乙個程式設計師的的考核標準可以從業務輸出、技術輸出、團隊建設三個方面來考核，首先業務輸出，即是負責的專案為公司帶來了什麼？打下了市場、賺取了利潤、提公升了人效都可以看作是業務輸出；其次是技術輸出，包括引進了新技術、研發了元件、優化了架構；最後是團隊建設，企業的三大核心，人才、業務、技術。
由此來看人才是擺在第一位的，所以團隊建設也應該是公司考核的乙個標準。
最後補充一點業務輸出，還應該包括系統的穩定性和線上bug率。
2樓：風雪
凡是制定不出kpi的公司往往問題出在不明白制定kpi是為了解決自己的什麼問題，而是想單純的做個最完美的kpi制度。
沒有評價標準，你會發現你做什麼都是對的，也是錯的。
舉個例子，如果你執行kpi，是為了強化程式設計師環節的執行效率和風險降低，那你可以拿事故率和delay率等指標去定。如果你是要提高程式產出，那就去定工作量方面的指標。
但是，當你為了解決某個問題去制定kpi的時候，你會發現kpi是乙個很蠢的方法，因為你不是用員工的責任心在驅動自己工作，而是用虧損心在驅動，這慢慢會導致有能力的員工離職。
3樓：Alvin Chen
你們搞scrum的時候不是有sprint和timeline嗎？就以sprint的完成度為單位就行。具體可以去搜scrum kpi 或者 agile kpi，有很多現成的經驗。
4樓：qi yu
可以定，但是需要一群高水平的程式設計師來定規則，比如這類模組大概值多少分，比如懸賞解決某個陰險的bug又值多少分，除了分值之外，還要統計難度係數，有的人不願意加班，但他能解決難題，這類人的kpi應該比一般人高。
5樓：
程式設計師的KPI確實是有點不好確定的。因為任何乙個創造性的工作都很難去做明確的衡量，所以不要去衡量它的過程，去衡量結果。但是要監督過程。
舉幾個例子吧。
如果是產品型的公司，那可以按產品的規劃來划這個考核。以按時按質的輸出產品為主要目標。因為產品本身是可以做一定的切分，或者做一定的任務劃分的。
這個劃分的結果與完成的時間點，理論上是乙個可行的評價標準。
如果是專案式的，那就更簡單了。專案就是一切嘛。可以完全以專案的結果為基準做評估啊。
最麻煩的是沒有明確的目標的，非專案、非產品型的。比如研發類的。因為它充滿了不確定性，你不知道一件事是不是能成功，品質怎麼樣？那麼如何辦呢？
找到確定性，越初級的員工，越讓他們的工作確定化。 只要是確定的，那就是能衡量的了。
而不確定性，對於有一定級別的員工來講，他們就已經學會了管理自己的不確定性。所以級別越高，就要越鼓勵他們去吸收不確定性。
6樓：湖東
具體看你們公司規模，開發流程，以及需要達到的目的。
方案需要跟隨著實情更新。讓程式設計師自己參與進來。
具體情況具體來。想和其他職位一樣圖簡單抄乙個方案就用很容易起到反作用
7樓：搬磚的熊貓
有很多維度
比如把績效和公司盈利掛鉤
再加上個人考評，年初定下幾個目標，比如研究某技術的應用，輸出是做兩次相關演講，組織一次workshop一類
組內的話可以參照敏捷開發，做好velocity管理，如果專案組完成了預估的值，可以說是完美達成kpi，未完成則要看原因和解決方式，以此可以大致衡量專案人員的kpi
最後，加入多維度考察，即合作夥伴的意見，專案經理意見，同組人員意見等，綜合評定。
8樓：張逸影
雖然知識型勞動不好去量化勞動過程，但是工作成果一定是客觀存在的
以目標為導向，關注做成了什麼？而放權給員工怎麼去做，作為管理者去關注每個里程碑完成度，及時協助解決下屬遇到的問題。
結果每個人的當前能力，級別和經驗的設定乙個預期，也就是當前人應該完成的工作。最終由自評，員工互評，領導評價來整合乙個最客觀的評價。
9樓：yaoyao
程式設計師的KPI有沒有用？答案是既有用也沒用。
說他有用，是因為對老闆有用。老闆可以通過KPI來知道哪個程式設計師要保住，哪個可以滾蛋。當然，老闆所知道的，並不一定是他想知道的。但這一點不重要，重要的是老闆能不能知道。
說他沒用，那是因為對中層管理人員沒用。目前，還沒有什麼KPI體系可以科學、準確地反映程式設計師的能力和產出。但管理者只要稍微用心觀察，就能夠清楚地知道誰能力強誰能力弱，誰實實在在做事，誰一有機會就摸魚。
為什麼會這樣？最大的原因就是程式設計師不是個標品。程式設計師和程式設計師直接的差距，真的比人和狗的差距都大。而且基本符合二八定律：團隊中80%的產出是由20%的核心人員完成的。
所以根本設計不出乙個科學的、客觀的Key Performance體系，使得Indicator能夠符合正態分佈。只能大搞特搞主觀的Key Performance，最終部門主管能給老闆乙個交代就行了。客觀是永遠不可能客觀的，除非程式設計師真的只是搬磚。
10樓：伍先生
確實很難！
以我來舉例，我的領導之前連我是誰都不認識。
有一次，應邀去出差，由於出差地點非平常辦公的地方，所以就在會議室裡面，領導進來我打了個招呼，他思考了一下，問我，你那個部門的？他怎麼給我評績效？
為了避免我的績效過底，所以我在每次寫月報的時候，都要寫多一點，湊湊字數，我知道反正他也不會看，也許比別人多點，評A的機會更大一些！
如果真的想認真給人評績效，那麼首先就應該了解、明白員工所做的都是是什麼事情，重要性如何、員工之間口碑等等綜合維度，其實我覺得相對更科學一點方式應該採用互評的方式對領導和員工均進行評價，這樣更有利於綜合反映部門的情況。更多時候領導的狗屁決策，往往是績效的第一屏障。集團領導管理公司領導，往往是看PPT，他們根本不知道事情的真相是什麼，讓員工也評一評領導，也許是考核領導更好的方式。
11樓：
提出這個問題說明你想到了乙個事情：
技術人員是難以定製KPI的
實際上別說程式設計師，所有的技術類、甚至是腦力類工種 —— 從作家編輯、到設計師工程師、再到醫生、律師、研究人員……當然也包括了程式設計師在內，做的都是無法進行「短期內量化考核」的工作。
你能給醫生定KPI嗎？說一周不看多少個病人就不合格？
你能給作家定KPI嗎？說一天不寫出多少字就不合格？
而這個短期指的是「幾年之內」。
既然幾年之內的成績都難以量化考核，就更不要說以年、季度甚至月度來進行量化考核了。
事實上，KPI只適用於「可重複性的」、「易培養的」的低技術水平工種 —— 就連高階別的銷售顧問都很難用KPI考察。
這也是為什麼在過去十年內許多科技公司用OKR取代KPI的原因：
制定乙個大的目標，這個目標包含幾個關鍵性的達成點，至少放手讓「團隊」去做就好了，不要去考核團隊中每個成員的細節。
女生怎麼認識程式猿男票？
南搞小孩 認識乙個程式媛，和她成為好朋友。因為程式媛通常認識很多程式猿並且在感覺雙方合適的情況下非常樂意牽線。部分程式媛甚至肩負著多個程式猿幫忙介紹物件的重任。但是怎麼認識程式媛呢？建議再開個提問哈哈哈，程式媛也很想認識小姐姐們啊 涼涼 這太簡單了，直接堵在有程式設計師的公司門口，看見頭髮比較禿的，...
程式猿怎麼才算基礎紮實？
賀嘉 基礎紮實意味著程式跑出來的結果和預期的不一樣的時候，你知道可能是哪些地方可能導致和預期不一樣，然後能夠自己去排查，找到最後的問題原因。看圖說話，優秀的程式設計師會按照專案的需要，往底層和周邊的技術進一步鑽研，方式包括但不限於自己寫個demo，研究Unix Docker這類優秀專案的原始碼。刷面...
一枚在職程式猿，自考與網路教育我該怎麼選？
微lzm62668696 建議網路教育，首先，自考計算機難度大，不容易畢業，其次，自考需要花蠻多時間，不適合你，再次，自考和網路教育的文憑的含金量都是差不多的，所以建議你放棄自考，走網路教育這個方式。 王老師聊學歷 自考需要學員強大的自學能力和學習習慣，如果你基本沒有學習的習慣，自制力一般，要想考過...