Lassen Sie uns über Metriken sprechen, um die Arbeit eines Programmierers zu bewerten

Metriken - sie sind wie Filzstifte, jeder nach seinem Geschmack. Ohne Metriken ist die Existenz eines profitablen Geschäfts als solches unmöglich, sie umgeben uns ständig, das ist unangenehm, aber ein Axiom. Für einige ist die Metrik der Verkaufsplan für den Monat, für andere der Abschluss der Bestellung vor dem vereinbarten Termin und für andere die Anzahl der geleisteten Arbeitsstunden.


Zu diesem Thema gibt es keine geeigneten „Attraktionsbilder“. Behalten Sie also eine Katze

Aus irgendeinem Grund ist das Wort "Metriken" im IT-Bereich in seinen Dummheitspraktiken, wie dem Zählen geschriebener Codezeilen oder geschlossener Aufgaben, eng mit solchen "hervorragenden" verbunden. Wir können mit Zuversicht sagen, dass dies die nutzlosesten und zahnlosesten „Managementinstrumente“ der Kontrolle sind. Tatsächlich gibt es unter angemessenen Bedingungen, aber immer noch, nur zwei Arten von Metriken: Metriken für das Projekt und / oder die Arbeit, deren Ergebnis und Ausführungszeit zeitlich klar und vorhersehbar sind, und umgekehrt Metriken für das Projekt und / oder die Arbeit, das Ergebnis und deren Ausführungszeit physikalisch unmöglich vorherzusagen ist. Für den ersten Typ werden Metriken des Ergebnisses festgelegt, und für den zweiten Typ - die Entfernung, dh die Arbeitszeit.

Die erste Art von Metriken "nach Ergebnis"

Es gibt kein universelles Rezept für die Festlegung von Metriken für einen Mitarbeiter - dies ist immer ein Situationsphänomen. Die Metrik des Mitarbeiters wird immer aus einer einfachen Antwort auf die folgende Frage gebildet: Können wir das Endergebnis und damit die Arbeitszeit auf kurzen oder mittleren Entfernungen klar vorhersagen?

Schauen wir uns die Situation der Freiberufler an. In den meisten Fällen bauen Kunden Beziehungen zu den Darstellern auf der Grundlage der Bezahlung des geleisteten Arbeitsaufwands auf. Das heißt, es gibt ein Budget für das Projekt, und die Redline und die Frist für die Lieferung werden während dieses Verhandlungsbudgets vereinbart. So arbeiten Designer, Layoutdesigner und eine Reihe von Entwicklern. Meistens bewegt sich das Budget nicht, dh die "Laufzeit" ist der bewegliche Teil.

Es ist jedoch immer ein vorhersehbares Plus / Minus, dh der Kunde weiß genau, wie viel „ungefähr“ Zeit für die Ausführung seiner Bestellung aufgewendet wird. Basierend auf dieser Zahl wird ein Budget zugewiesen, nach dem ein geeigneter Darsteller gesucht wird.

Im Allgemeinen wird das Prinzip "Es ist uns egal, wie viel Zeit Sie für die Ausführung eines Auftrags aufwenden, machen Sie es einfach gut und pünktlich, was für uns akzeptabel ist" in der freiberuflichen Umgebung klar gepredigt. Daher werden viele Fragen entfernt, um die Arbeit eines angestellten Freiberuflers oder Zeitarbeitnehmers zu überwachen, die Notwendigkeit, ihm das Drei-, Vier-, Zehnfache des „Gehalts“ zu zahlen, und so weiter. Es gibt eine Vorauszahlungstranche, es gibt eine Schließung des endgültigen, im Voraus vereinbarten Kontos.

Ein ähnlicher Ansatz hat sich sowohl für kleine als auch für mittlere Unternehmen durchgesetzt, in denen Menschen zu arbeiten scheinen, und für Vollzeitbeschäftigte. Das Unternehmen befindet sich jedoch in einem Zustand harten Wettbewerbs und kurzer Entfernungen, wenn das Ergebnis zu einem bestimmten Zeitpunkt benötigt wird. Mit „verrückten Anstrengungen“ können Sie ein so grobes Blockdiagramm zeichnen, das Sie bei der Entscheidung unterstützt:

Was ist mit UpWork-Stundensätzen und anderen freiberuflichen Zeitmodellen?

Vielleicht wurde diese Frage bei Ihnen, dem Leser, am Anfang des Artikels geboren, aber wir sind erst jetzt auf die Antwort darauf gekommen. Genauer gesagt zu den Antworten, weil es mehrere davon gibt.

Erstens: Das Vermietungsunternehmen ist an die Kontrolle gewöhnt, da der Stundensatz in 50% der Fälle einen Tracker und in 100% - regelmäßigen Berichten eine Prüfung der durchgeführten Arbeiten umfasst. Das heißt, der Kunde überträgt einen Teil der Managementfunktionen an den Auftragnehmer selbst, der für sich selbst berichtet.

Zweitens: Das Unternehmen benötigt die Kontrolle über den Entwicklungsprozess, da es nur einen Versuch hat. Wenn sich das Projekt über mehr als ein paar Wochen erstreckt, muss der Kunde verstehen, "in welchem ​​Licht" die Arbeit ist. Meistens wird das Budget für solch massive Aufträge nur einmal zugewiesen, und es gibt nur einen Versuch. Tatsächlich gab es einmal Unternehmen auf dem Markt, die keine so regelmäßige und manchmal harte Berichterstattung von Testamentsvollstreckern über große Projekte benötigten, aber ihnen passierte dasselbe wie Elefanten mit kleinen Ohren - sie starben aus (Elefanten durch Überhitzung, aber Unternehmen - wegen Fristen).

Die zweite Art von Metriken ist "in time".

Aber alles wird viel, viel komplizierter, wenn wir über ein großes Projekt sprechen, dessen Lieferfristen zwischen „ein bis drei Jahren“ und „dies ist eine ewige Entwicklung“ liegen. Bei „ewiger Entwicklung“ ist es fast unmöglich, den Zeitpunkt für das Erreichen des Endergebnisses vorherzusagen folgende Gründe:

• An dem Projekt arbeitet nicht nur eine Person, sondern auch mehrere Teams.
• Jedes Team "in den Richtungen" hat zwei bis drei bis mehrere Dutzend Mitarbeiter;
• Wann die Arbeit am Projekt endet, weiß niemand.

Unter solchen Bedingungen ist es leicht, sich zu verirren und bekannte Birnen mit einem bekannten Objekt zu streuen. Da das Unternehmen jedoch nicht an Wohltätigkeitsarbeit beteiligt ist, muss von Kennzahlen „nach Ergebnissen“ zu einer komplexeren Kategorie von Kennzahlen „nach Zeit“ gewechselt werden.

Das einfachste und logischste Beispiel für „pünktliches Arbeiten“ ist das übliche Vollzeitbüro in Unternehmen mit 30 bis 50 Mitarbeitern in der Entwicklungsabteilung. Unter diesen Bedingungen stimmt das Unternehmen „am Ufer“ mit einem potenziellen Mitarbeiter überein, dh in der Interviewphase nicht über den Zeitpunkt des Abschlusses des Projekts, sondern über die Kosten einer Arbeitsstunde auf der Grundlage einer 40-Stunden-Woche gemäß Arbeitsgesetzbuch. Für uns sieht es nur nach einem Gehalt aus.

Gleichzeitig muss man klar verstehen, dass Geschäfte keine Dummköpfe sind. Die Größe des RFP (genauer gesagt seine Reduzierung) umfasst Persönlichkeitskrisen, das Herumtollen im Büro, Rauchpausen, zusätzliche 20 bis 30 Minuten für das Mittagessen (dh eineinhalb Stunden statt einer Stunde) und nur Aufschub auf YouTube. Einige Unternehmen können sich diese Kosten leisten, da das Geschäft derzeit rentabel ist und er sich eine „leichte“ Version der Kontrolle leisten kann, indem er einfach kurzfristige Aufgaben mit verschwommenen Fristen einrichtet, an denen das Junior- und Middle-Management beteiligt ist.

Aber wenn das Geschäft margenschwach ist oder in einem wettbewerbsorientierten Legacy-Umfeld existiert, wird alles schlimmer. Und hier beginnt die einheitliche Hölle, für die die Entwickler das Wort "Metriken" nicht so sehr mögen.

Ein wirklich enger Bezug zur Arbeitszeit ist keine unabhängige Effizienzmetrik, hier werden Krücken benötigt

Wenn eine Person nicht für das Ergebnis, sondern für die geleistete Arbeitszeit bezahlt wird, wie kann dann ihre Wirksamkeit bewertet werden? Diese Frage wird von der Wirtschaft ständig gestellt. Hier gibt es mehrere Variablen:

1. Verknüpfung der Teamleistung mit der Ergebnismetrik über eine kurze Distanz.
2. Die Verwendung kleinerer Metriken auf der Ebene von Aufgaben und Sprints.
3. Bauen Sie eine klare Struktur von Verantwortung, Begriffen und Prioritäten auf und nennen Sie es das, was Sie wollen, zum Beispiel „Entwicklungspolitik“.

Tatsächlich ist das Unternehmen mit einer Situation konfrontiert, in der es anscheinend auf einen mehr als verständlichen Mechanismus des „Zeitkaufs“ umgestellt hat, aber es ist immer noch zu kontrollieren, ob für die Bezahlung dieser Zeit etwas in Form von Arbeitsergebnissen eingegangen ist. Das heißt, unser Konzept des "Kaufens eines Ergebnisses" wird zu einer eingebetteten Variablen im Konzept des "Kaufens von Zeit".

In den meisten Fällen kann das Management die Bedürfnisse von Unternehmen und Mitarbeitern nicht gleichzeitig klar nachvollziehen, dh ein System und eine Richtlinie zur Anwendung von Metriken erstellen, bei denen beide Parteien mit dem Geschehen zufrieden sind. Was ist gemeint: Metriken müssen gleichzeitig die Interessen des Unternehmens erfüllen und für die Mitarbeiter verständlich und machbar sein.

Hier stehen wir vor einem weiteren Problem: Wenn bei kurzen Arbeiten „auf Bestellung“ die Aufgabe für alle Beteiligten meist klar und verständlich ist, ist bei der Entwicklung eines großen Produkts die gesamte Struktur in ständiger Bewegung. Trite: Konkurrenten veröffentlichten ein neues Produkt oder ein neues Toolkit, und alle Pläne, die vom Management liebevoll erstellt wurden, gingen verloren.

An diesem Punkt hängt viel vom Management ab. Hier können Sie einfach die unzureichenden und angemessenen Ansätze zum Festlegen von Metriken beschreiben.

Unzureichende Metriken:

• Anzahl der Codezeilen und Commits;
• Anzahl geschlossener Aufgaben ohne Berücksichtigung der Komplexität;
• dem Entwickler das Stimmrecht entziehen;
• Ignorieren der Dynamik und des Entwicklungsbedarfs im Berichtszeitraum (Kennzahlen, die über den gesunden Menschenverstand hinausgehen);
• langwieriger Prozess der Überprüfung von Metriken, mangelnde Flexibilität, Ignorieren von Entwicklungsmeinungen.

Hier habe ich eine typische "Galeere" beschrieben, wenn sich ein Entwickler von einer Person in eine "Code-Schreibmaschine" verwandelt und es ihm egal ist, wie er mit kurzfristigen Aufgaben / Metriken umgeht, die von oben auf ihn zukommen. In diesem Fall verliert der Entwickler jede Möglichkeit, die Entwicklung zu beeinflussen, selbst wenn er das "Innere" des Problems sieht. Gleichzeitig wird die Komplexität der Aufgaben nicht berücksichtigt und alles hängt vom Affenjob ab.

Angemessene Metriken:

• Berücksichtigung der Komplexität der Aufgabe;
• Die Fähigkeit, die Metriken nachträglich zu überprüfen, wenn Probleme auftreten;
• Fähigkeit, die Aufgabe zu kommentieren;
• Fehlende enge Bindung an quantitative Indikatoren für Codezeilen / Anzahl der Aufgaben;
• Falls erforderlich, teilweise Nichteinhaltung von Metriken ignorieren.

Angemessene Metriken sind Metriken, die nicht auf den Boden genagelt sind und die verschoben werden können. Wenn ein Unternehmen maximale Effizienz anstrebt, sollte diese Effizienz auf allen Ebenen liegen. Es ist seit langem klar, dass die Anzahl der Aufgaben oder Codezeilen in der Tat nicht viel bedeutet, da einige Aufgaben einen entscheidenden Einfluss auf das Produkt haben können und Hunderte anderer Kosten verursachen.

Darüber hinaus ist eine enge Bindung an die Einhaltung der Metriken kontraproduktiv: Wenn der Entwickler weiß, dass er „Probleme“ haben wird, weil er 19 Aufgaben in einer Woche statt 20 abgeschlossen hat, tritt die Qualität der Aufgabe in den Hintergrund. Und mindestens die letzte, 20 Aufgaben, wird mit Krücken und Fahrrädern auf die Müllkippe gelegt, anstatt die Aufgabe wirklich und ein für allemal zu lösen.

Feedback als integraler Bestandteil des „Time Purchase“ -Modells

Tatsächlich ist ein gut aufgebautes Entwicklungsmodell, das an die Arbeitszeit gebunden ist, viel komplizierter, als es auf den ersten Blick erscheinen mag. Um effektiv an diesem Modell arbeiten zu können, sollte ein qualitativ hochwertiges Feedback zwischen Darstellern und Führungskräften organisiert werden, die die „Parteipolitik“ auf allen Ebenen ständig anpassen müssen. Schließlich ist eine unzureichend gestellte Aufgabe, dh eine formulierte Metrik, für Entwickler kein Problem, obwohl es üblich ist, dieses Problem an die Darsteller weiterzuleiten. Eine unzureichend formulierte Metrik ist ein Problem, nur für das Management, das diese Aufgabe für die Auftragnehmer festgelegt hat, vorausgesetzt, die Arbeit beider Parteien ist transparent.

Es ist das Management, das die Arbeit so organisieren sollte, dass die Arbeitszeit effizient verbracht wird, dh die Budgets werden nicht „verbrannt“, aber gleichzeitig könnten Entwickler ihre Aufgaben in wenigen Wochen ohne vollständigen Burnout bewältigen. Weil die Humanressourcen zwar riesig, aber nicht unendlich sind, besonders wenn es um qualifiziertes Personal geht.

Das Vorhandensein von Feedback und die Verantwortung für Entscheidungen des Managements unterscheiden sich von einem Unternehmen, das detaillierte Aufzeichnungen über die geleisteten Arbeitsstunden führt, von einer expliziten „Galerie“, in der Entwickler in einen bedeutungslosen Fleischwolf fallen.

Es ist das Feedback, das es dem Unternehmen ermöglicht, Engpässe in der Entwicklung zu finden. Wie oft sind Sie auf eine Situation gestoßen, in der Mitarbeiter einer Abteilung erstickten, wegen Abnutzungserscheinungen arbeiteten, aber keine „Verstärkung“ in Form von zwei neuen Spezialisten erhielten, die ihre Schultern ersetzten und einen Teil der Last übernahmen? Solche Situationen entstehen immer wieder, gerade weil es an qualitativ hochwertigem Feedback zwischen Entwicklung und Management mangelt. Anstatt die Effektivität des Teams und seine Arbeitsbelastung klar zu verfolgen, greift der Manager mit dem Finger in die Nase. Wenn jemand zusammenbricht und einem solchen Rhythmus nicht standhält, schiebt er alles an die verbleibenden Entwickler. Nicht so.

Anstelle von Ausgabe

Das Schlimmste, was bei der Organisation eines Arbeitsprozesses passieren kann, ist die „Verzerrung“ der Mechanismen, die einem Modell in einem anderen innewohnen. Zum Beispiel, wenn für langfristige Projekte harte Fristen festgelegt werden, ohne dass die Komplexität und die Fähigkeiten des Teams fundiert beurteilt werden müssen. Oder wenn bei kurzfristigen autarken Projekten und Aufgaben solche Kontrollformen eingebaut sind, die in den Bereich der Raketenwissenschaft passen, und wir sprechen nur von einem Auftrag für Freiberufler.

Ein klares Verständnis der Angemessenheit bestimmter Arbeitsmethoden in Unternehmen unterschiedlicher Strukturen und Größen wird dazu beitragen, bei der Arbeitssuche einen großen Teil der Gesundheit und des Nervensystems zu erhalten. Und je mehr Entwickler, Manager und Geschäftsinhaber diese Mechanismen verstehen, desto besser wird es für alle Teilnehmer im IT-Segment.