軟件工程師需要反饋，以便他們可以提高技能并加深知識。傳統指標可能會產生誤導，因為它們并不總是能提供明確的結果。在Git Analytics工具提出數據驅動的工程領導方法來幫助您充分發揮工程師的才能之前，評估員工的工作以前很困難。重要的是要以正確的方式衡量您真正需要什么。選擇取決于您的業務細節和每個工程師的工作職責。我們為您提供了可幫助您評估工程師效率的算法：

　　1.設定目標

從項目開始就應該將設定組織目標并定期檢查所有團隊是否遵循它們作為首要任務。即使您的軟件開發是外包的，工程師團隊也不是一個獨立的組織，其唯一功能就是編寫代碼并對其進行測試。將技術目標與共同的業務目標整合在一起是您旅程中必不可少的一步。在早期階段將任務概念化為在后期階段評估績效奠定了基礎。

每個目標都應與業務的總體目標相對應-在團隊級別或個人級別。

　　2.奠定基礎

績效評估歸結為兩個問題-什么以及如何做。諸如“什么”之類的問題與分配給團隊的實際任務有關。它們包括明確的事實和隱含的期望。諸如“什么”之類的問題的示例可以稱為按時編寫和測試代碼。在這里，時間是一個明確的事實，而卓越的代碼質量是一個隱含的期望。

諸如“如何”之類的問題與過程相關，例如，工程師在團隊中的工作狀況如何，他對問題的處理方式如何創新等等。

對基本“內容”和“方式”的評估不僅會向您顯示團隊正在執行的任務，而且還會顯示團隊的執行情況。Waydev通過“ 工作日志 ”提供了工程師活動的鳥瞰圖 ，使您可以查看和放大某個時間范圍內工程師提出的任何提交或請求。

　　3.注重長期成果

在軟件開發中，您永遠不要專注于所開發產品的定量方面。額外的代碼行只會導致難以維護的軟件過度使用。相反，最小化編寫的代碼行數也不起作用：這將導致軟件難以理解和擴展。

長期以結果為導向的方法意味著，不是量化績效，而是根據團隊績效來評估產品。要評估開發和發布過程，您需要分析穩定性，交付時間和最終產品的更新頻率。

要評估團隊的績效，您需要了解它是否達到了預期的結果。通過專注于此，您不僅可以提高開發人員的生產率，而且可以實現組織目標，并從長遠來看會產生可觀的利潤。您可以使用Waydev的 項目時間軸 功能來查看工作重點和工作量隨時間的變化情況。找出您的工程師的工作重點在哪里。是在創建新代碼，重構舊代碼還是在幫助他人?查看事件如何影響您的團隊績效并指導以數據為依據的決策。

　　4.評估準備

為了建立基礎，有必要在評估時遵循一定的標準。這樣的標準可以是工作說明或預期的工作計劃。

查看現有的職位描述，文檔，記錄，電子郵件以及任何其他可以使您得出員工效力的數據。

如果您最近在團隊中，請與開發人員的負責人，他們的同事以及與他們一起工作的忠實客戶進行交談。

　　成功或失敗不僅取決于人員，還取決于工作條件：

· 是否有不可預見的情況？例如，低估了任務的復雜性還是改變了優先級？也許這就是阻止工程師實現其目標并顯示其能力的原因。

· 公司取得了哪些成功，這位工程師的貢獻是什么？工程師是否正確使用了關鍵技能？

借助Waydev的項目時間表，您可以根據團隊的工作流程確定最相關的數據點，并就哪些學習可以應用于下一個沖刺進行富有成效的討論。項目時間表將幫助您和您的團隊在回顧性評估中的對話期間快速查看過程阻塞的信號，這些信號會影響團隊軟件開發的運行狀況。

　　5.分析目標和關鍵技能

　　將當前性能與工作描述中期望的或定義的進行比較。如果有可見的結果，請使用特定示例備份此數據并確定其重要性：

· 是否達到/超過了預期指標？

· 不利的工作條件是否阻礙了既定目標的實現？

· 員工加班是否實現了目標？

· 工作的結果是否如此出色，以至于值得向這位工程師強調？

· 工程師在實現團隊目標中是否發揮了關鍵作用？

　　如果沒有可見的結果，請詢問以下問題：

· 成功取決于這個人嗎？

· 故障是由于缺少必要設備，任務量太大，任務設置模糊或缺少所需資源等原因引起的嗎？

· 更加杰出的權威會解決這些問題嗎？

· 不完成任務會有什么后果？

　　確定工程師在工作中如何定期有效地運用他的關鍵技能：

· 員工是否每天使用技能?他是運用所有能力還是只運用其中一些能力？哪一種？

· 應用技能如何幫助工程師實現工作目標?這如何影響團隊的工作流程和成功？

· 工程師工作有困難嗎?如果是這樣，這對您的目標和工作流程有何影響？

如果工程師很難完成工作任務，而目標沒有實現，則值得考慮組織額外的培訓或繼續教育課程。

6.討論

您在分析過程中得出的所有結論都應與工程師本人討論。專注于他的成功。為了盡可能準確地描述這種情況，請使用特定示例。從積極的一面開始，但一定要提及已經出現的困難。如果由于工程師無法控制的原因未能實現目標，則他不應認為這只是他的錯。

請務必提出問題并認真聽取問題的答案；這將幫助您發現問題并了解該人與他們之間的關系：他是否想解決這些問題，他看到了什么解決方案以及他想改變什么。

　　7.建議

根據您在與工程師，經理和同事的討論中收到的數據，列出可以提高開發人員生產率的建議列表。

如何撰寫評論和建議

需要對完成的工作發表評論以提供反饋。根據評論，工程師將能夠評估他們的長處和短處，并朝正確的方向進行直接努力。請記住，評論不僅可以針對工程師進行判斷，還可以針對編寫人員進行判斷。它們必須專業，客觀地組成。

　　注釋應描述以下幾點：

· 工程師在多大程度上實現了目標？

· 工程師多久展示一次專業知識和關鍵技能？

· 在評估期內有哪些改進？

· 有什么需要改進的？

　　注釋應具有以下屬性：

· 客觀性。

· 完整性。

· 真實性。

· 具體細節。

· 積極完成。

　　需要注意的方面

　　1.出勤

首先，您需要注意工程師是否會出現在工作中。考慮到達和離開的時間以及缺席的時間。如果團隊中的某人來得太晚，長時間離開工作場所，比必要的時間早了或請病假而沒有充分的理由，則他不會尋求全力以赴的工作。請記住，出勤率低下不僅是由于平常的懶惰，還可能是由于更嚴重的原因缺乏動力，健康問題或情緒疲倦。

避免承擔工作責任會加劇團隊環境。其他工程師必須承擔其他責任，以補償工作場所同事的缺席。如果您的組織沒有足夠的工程師，并且人們已經在處理它，那么情況將會更加嚴峻。盡快開始處理該問題：忽略該問題可能會導致工程師的個人生活和健康出現問題。

　　2.有幫助的行為

我們都致力于幫助客戶，但團隊內部的互助也至關重要。此項是工程師的關鍵性能指標之一：我們向人們提出問題。在過去六個月中，您的部門中誰最響應迅速，并為您提供了比其他人更多的幫助？ 事實證明，這是匿名激勵工程師的，并允許您確定真正的勤奮工作者，而不僅僅是領導的最愛。

愿意互相幫助是團隊合作的關鍵要素。一起完成復雜的任務比嘗試獨自轉身大得多。該 審查協作 功能，使您能夠看到誰分享他與他人的知識。它還提供了可量化的指標，以幫助您評估代碼審查工作流程的運行狀況。

　　3.計劃能力

所有團隊成員必須按時完成工作。他們必須能夠管理時間和資源并正確設置優先級，以盡可能高效地完成工作。

注意截止日期和因匆忙執行截止日期而遭受的工作質量;這將有助于了解員工的工作效率。同樣重要的是，要考慮在工作上花費的時間：如果一個人不斷重復地進行工作，那么就值得與他討論時間計劃了。

　　4.倡議

當同事有興趣知道他們是否可以幫助您某些事情時，這是很好的。如果他們看到工作目標并采取行動實現目標，那就更好了。該倡議是參與工作的指標。對于那些不斷創造新工作且需要快速重新分配人力資源的成長型公司而言，確定最積極的工程師至關重要。為了使新部門最有效地工作，最好配備最主動的人員。他們將能夠快速適應新的條件并在彎道之前工作。

為了確定團隊中最積極的成員，請記錄每次工程師帶頭進行的工作。

　　5.質量

工作質量是最重要的指標，但同時也是衡量績效的最具挑戰性的指標。代表質量的工程師，真正參與工作過程并且可能會顯示出更好的結果的工程師。這種參與可以是質量標準。

開發人員的生產力不僅集中在正在開發的商品的定量功能上;還包括 這不是解決方案。工程師編寫額外的代碼行僅有助于腫的軟件的發展，這帶來了可維護性方面的挑戰。您需要知道工程師是否在為您提供高質量的工作，而不是定量的工作。

HR World網站專家建議根據被拒絕或退回修改的作品數量來評估最終結果的質量。您可以使用此方法，也可以選擇其他更適合您的業務細節的方法。

　　最后

當然，評估特定數字的性能至關重要，但是業務培訓師建議不要局限于數字數字。畢竟，團隊成員是人，而不僅僅是資源。

在評估有效性時，必須與團隊盡可能公開地溝通。人們需要知道您要測量的內容以及如何報告結果。因此，每個工程師都將知道他在團隊中的職位。借助Waydev，您可以代表特定團隊成員倡導，查看他們的進展情況并幫助他們消除瓶頸，實現組織上下的更好溝通，想了解更多關于IT管理的信息，請繼續關注中培偉業。