Der beste Weg, um die Leistung von Softwareentwicklern zu bewerten?

Es ist eine gute Möglichkeit, SVN täglich zu überprüfen, um Codes zu überprüfen und zu beurteilen, wie viele Codes von jedem Entwickler übertragen wurden. Ist es fair und wird es in der Industrie verwendet?

Die vorgeschlagene Metrik ist absolut unfair, wird leider in einigen Organisationen verwendet und ist meiner persönlichen Meinung nach ein Rezept für eine Katastrophe.

HasaniK und Jakub haben bereits einige sehr triftige Gründe dafür identifiziert, warum es unfair ist. Es müssen jedoch einige sehr ernsthafte Überlegungen zu den Auswirkungen angestellt werden, die sich aus der Einführung dieser Kennzahl als leistungsbezogene Metrik ergeben können.

Die Verwendung von LOC (und tatsächlich jeder anderen Art von linearer Metrik, z. B. Fehlerbehebung) zur Bewertung der Produktivität oder Leistung von Ingenieuren ist grundlegend fehlerhaft, sie bestraft im Wesentlichen gewünschte Verhaltensweisen wie Refactoring. Wenn ich einen Funktionspunkt entwickelt und 350 LOC dazu verpflichtet habe, dann überprüfe ich ihn, vielleicht nach etwas Zusammenarbeit mit einem Kollegen und entdecke, dass es in nur 150 LOC erledigt werden kann, werde ich es tun? Es ist unwahrscheinlich, dass es sich auf meine wahrgenommene Produktivität oder Leistung auswirkt.

Eines der schlimmsten Beispiele, die ich je gesehen habe, war die Verwendung von sowohl LOC als auch Fehlerbeseitigung als Leistungsmetriken. Dies ermutigte Entwickler im Wesentlichen, Unmengen von entsetzlich fehlerhaftem Code zu schreiben und dann ihre eigenen Fehler zu beheben! Nicht gerade förderlich für die Steigerung von Geschwindigkeit und Qualität.

Meiner Ansicht nach kann dieser Ansatz im Alleingang für die Schaffung einer Kultur von Design, Code und Dokumentation von schlechter Qualität verantwortlich sein, da sich Ingenieure zunehmend auf die Übergabe von Code konzentrieren und nicht auf robustes und solides Design, Zusammenarbeit und Innovation. Ich habe gesehen, wie gute Teams von enthusiastischen und hochwertigen Ingenieuren in wenig enthusiastische Roboter umgewandelt wurden, die sich ausschließlich darauf konzentrierten, jeden Tag das zu liefern, was sie für das erwartete Maß hielten.

Unnötig zu sagen, dass ich die genannte Organisation so schnell wie möglich verlassen habe und seither bei jedem einzelnen Interview danach gefragt habe, welches PAR-Framework gilt, wie kann ich erwarten, dass meine Leistung gemessen wird? Wenn LOC erwähnt wird, danke ich ihnen sehr für ihre Zeit und wenn mir die Stelle angeboten wird, lehne ich ihr freundliches Angebot höflich ab.

Ich persönlich habe die besten PAR-Frameworks für Entwickler als weitgehend subjektiv empfunden, die Verwendung von 360-Grad-Reviews kann helfen, sicherzustellen, dass die gewünschten Verhaltensweisen wie z Feedback basierend auf demonstrierten Verhaltensweisen enthalten und sich nicht „beschweren“). Die Code- und Dokumentationsprüfung ist eine echte und unvoreingenommene Methode zur Messung der Qualität, Vollständigkeit und Genauigkeit der Ausgabe.

Es ist eine gute Möglichkeit, SVN täglich zu überprüfen, um Codes zu überprüfen und zu beurteilen, wie viele Codes von jedem Entwickler übertragen wurden. Ist es fair und wird es in der Industrie verwendet?

Dies ist definitiv kein korrektes Maß für einen PAR für Software-Ingenieure. Wie Jakub auch erwähnt hat, braucht das Design Zeit, manchmal gibt es Blocker, die das Entwicklerteam daran hindern, ein Feature fertigzustellen und ein Commit durchzuführen (z. B. - Nichtverfügbarkeit von Entwickler-/Testservern) und auch in einem funktionsübergreifenden Team könnten einige Mitglieder einem anderen Mitglied helfen mit ihrer Arbeit. Die Liste ließe sich fortsetzen..

Meiner Meinung nach ist die folgende Liste ein grundlegender Satz von Zielen für Softwareentwickler aller Stufen (Junior/Senior).

1. Vollständigkeit , Qualität und Produktivität der Leistungen ( Code, Dokumentation, Fehlerbeseitigung – Bitte beachten Sie, dass diese akzeptierten Standards und Werte vor Arbeitsbeginn mitgeteilt werden müssen)
2. Teamarbeit (wie kooperativ, unterstützend sie bei der Arbeit mit einem Team sind)
3. Kommunikation (korrekt, klar, zeitnah)
4. Gemeinsame berufliche Etikette (Pünktlich zu Besprechungen, Einhaltung akzeptierter Anwesenheitsgrenzen/Personalrichtlinien in der Organisation, Respekt gegenüber anderen)

Zusätzlich zu den oben genannten sind für einen Senior-Ingenieur die folgenden Parameter zutreffender, da von Senior-Ingenieuren erwartet wird, dass sie mindestens einige andere Junior-Ingenieure anleiten

1. Vollständigkeit , Qualität und Produktivität der Teamleistungen (Wenn möglich, wenn dies auf Ingenieure aller Ebenen anwendbar ist, sollte sich theoretisch die allgemeine Vollständigkeit, Qualität und Produktivität verbessern, aber ich hatte nicht die Gelegenheit, dies aus erster Hand zu sehen)
2. Beitrag zur Kompetenzentwicklung (Training to Team, Tech Talks & etc.)

Wie Messkriterien für jeden oben hervorgehobenen Bereich definiert werden, würde ich der jeweiligen technischen Führung überlassen.

es ist definitiv nicht fair. Unterschiedliche Aufgaben erfordern unterschiedliche Herangehensweisen. Möglicherweise verbringen Sie mehr Stunden damit, Ihre Lösung zu entwerfen, anstatt sie zu implementieren.

Meine Empfehlung ist:

• Häufige Code-Reviews.
• Bitten Sie den Entwickler, den Code für andere zu überprüfen, und sehen Sie sich die bereitgestellte Überprüfung an.
• Überprüfen Sie ihre Dokumentation.
• Beobachten Sie, wie ihnen die Arbeit / Teamarbeit Spaß macht.
• Setzen Sie sich häufig zu zweit zusammen und stellen Sie Fragen zum Projekt. Wie er über das Projekt denkt. Positive/negative Seiten. Ich glaube, es ist alles individuell und es ist schwer, die Leistung zu bewerten, indem man Tools verwendet und Check-Ins zählt. Persönlicher Ansatz sollte Ihnen mehr sagen.

LOC ist nur ein einfacher zu messender Faktor, wenn es darum geht, die Leistung von Personen zu bewerten, die als Tech Lead/Team Lead oder in höheren Positionen arbeiten.

Weil sie im Vergleich zur Entwicklung (Code-Schreiben) mehr Arbeit leisten. Zum Beispiel:

1. Anforderungserfassung.
2. Lösungen gestalten.
3. Dokumentation.
4. Wöchentliche Fortschritts-Update-Calls mit Kunden.
5. Überprüfen Sie die Verhaltenskodizes für Nachwuchskräfte auf Best Practices und Unternehmensstandards.
6. Überprüfen Sie den Code auf gute Qualität (wie @Clair erwähnt, um zu identifizieren: „Wenn der Entwickler einen Funktionspunkt entwickelt und 350 LOC dafür bereitgestellt hat, könnte dies möglicherweise nach einer Zusammenarbeit mit einem Senior in nur 150 LOC erledigt werden“).

Bei der Bewertung dieser Personen (Tech Lead/Team Lead oder höhere Positionen) denke ich, dass wir Bereiche berücksichtigen sollten, auf die @timeman789 hinweist.

Aber wenn es um Entwickler geht, denen klare Ziele und klare Aufgaben mit Hilfe ihrer Vorgesetzten gesetzt werden, denke ich, dass LOC einen akzeptablen Teil zur Bewertung ihrer Leistung gibt. Aber ich denke, es sollte nicht LOC sein, sondern ob es sich um Source Lines of Code (SLOC) oder Effective Lines of Code (ELOC) handelt. Abgesehen davon können FP (Functional Points) auch als Gegenmaßnahme verwendet werden, um diese Mitglieder zu bewerten.

Alles in allem denke ich, dass es besser ist, eine Recherche durchzuführen und unterschiedliche Maßnahmen für unterschiedliche Rollen von Menschen zu entwickeln. um die Leistung der Mitarbeiter Ihres Teams oder Unternehmens zu bewerten.

Jede Metrik, die sich auf Code wie LOC, Codequalität (Sonarwürfel), Fehler usw. bezieht, ist sehr schlecht. Entweder, wenn Sie ein metrisches System finden, das in einem Team funktioniert, wird es in einem anderen Team nicht funktionieren. Außerdem möchten Entwickler immer Leistungsmetriken hacken/knacken (weil es Teil ihrer Arbeit sein wird, komplexe Aufgaben zu lösen).

Aus dem Technologieteil kann ich nur solide Prinzipien vorschlagen - Schreibt das Team wirklich guten Code, der einfach zu warten ist (80-90% der Zeit, in der Entwickler Code pflegen).

Auch gibt es einen guten Ansatz von Google:

1. Google misst die Leistung auf der Grundlage von Selbsttrainings- und Bildungsaufgaben. Jeder Entwickler sollte sich entscheiden, welchen Bereich er/sie in den nächsten 6 Monaten verbessern möchte. Und danach überprüft der Manager/Teamleiter in Einzelgesprächen, welche Fortschritte erzielt wurden.
2. Berechnen Sie den Beitrag jedes Entwicklers zur Verbesserung des Technologieprozesses. Wie CI/CD, Training für ein Team und etc.

https://www.quora.com/Wie-messen-tech-unternehmen-wie-Google-die-leistung-ihrer-ingenieure-oder-softwareentwickler-werden-sie-an-ihren- codierfähigkeiten-produktivität-feedback-von-kunden-etc-welche-art-von-menschen-kann-wahrscheinlich-befördert-werden

Dies hängt jedoch sehr von der Art der Aufgabe ab. Wenn Sie als Outsourcer arbeiten, können Sie wahrscheinlich versuchen, etwas Messbares zu finden. Wenn Sie in einem Produktunternehmen mit einem langlebigen Produkt arbeiten, ist es besser, die langfristige Verbesserung eines ganzen Teams zu messen.