Die Frage, wie die Wirksamkeit des Entwicklungsprozesses bewertet werden kann, besteht ebenso wie die Entwicklung selbst. Oft können Entwickler an der Idee festhalten, dass Sie nur Qualitätscode schreiben müssen, aber all diese Optimierungen, Rallyes, Aktivitätsnachverfolgung usw. sind eine Laune des Managements. Die Verantwortlichen wiederum glauben, dass vor allem ein Produkt ist und wir hier tatsächlich ein Geschäft haben, keinen Interessenclub. Es ist also unmöglich, auf Metriken zu verzichten. Aber wie wichtig sind Metriken überhaupt?
Anfang September haben wir ein Treffen für Entwicklungsmanager abgehalten und mit Leuten aus
Plesk, Avito, Dodo Pizza, Tinkov, Agima, CIAN, Yandex.Verticals und DocDoc darüber gesprochen - nun, wir haben uns selbst nicht vergessen. Unten finden Sie eine Zusammenfassung dessen, worüber unsere Gäste gesprochen haben.
In einem kleinen Team sind Metriken nicht so wichtig
Wenn Sie ein Team von fünf bis zehn Personen leiten, werden Sie zu einer vereinbarten Kampfeinheit, einem Kollektiv, in dem jeder jeden kennt. Entwickler verbringen Zeit miteinander, arbeiten Schulter an Schulter und kommunizieren häufig außerhalb der Arbeit. Es ist nicht schwer, diesem STO-Team beizutreten: Der Leiter wird ein vollwertiges Mitglied des Teams und hat die Möglichkeit, direkt mit jeder Person zu kommunizieren. Alle Konflikte, Probleme oder Schwierigkeiten, auf die ein Team stoßen kann, sind deutlich sichtbar, und es gibt praktisch keine administrative Barriere zwischen der Tankstelle und ihren Untergebenen.
Das Verwalten kompakter Teams im Hinblick auf die Bewertung ihrer Effektivität ist viel einfacher: Da nicht zu viele Teilnehmer am Workflow teilnehmen, sind ineffektive Lösungen oder Methoden sofort sichtbar. Und Entwickler nehmen leicht Kontakt mit ihrem Senior auf, weil sie täglich mit ihm kommunizieren.
Mit hundert Entwicklern ist alles viel komplizierter
Sobald die Größe des Teams mehrmals zunimmt und nicht 5-10, sondern 50-100 Personen beträgt, ändert sich die Situation dramatisch. Jetzt kann der Leiter nicht mehr persönlich mit jedem kommunizieren, und wir brauchen klare und effektive Metriken.
Die erste und naheliegendste Lösung sind Task-Manager und eine Analyse der Anzahl geschlossener Aufgaben. JIRA und ähnliche Tools können eine bestimmte Reihe nützlicher Daten bereitstellen. Eine Analyse geschlossener Aufgaben zeigt beispielsweise das Vorhandensein einiger Probleme ohne persönliche Kommunikation mit Entwicklern.
Wenn beispielsweise Metriken in DocDoc erstellt wurden, stoppten sie zunächst bei bis zu sieben Indikatoren, aber am Ende gab es nur drei:
- Bequemlichkeit / Vergnügen von der Arbeit ;
- das Verhältnis der versprochenen und der für die Aufgabe aufgewendeten Zeit;
- Task-Lebenszykluszeit.
Die erste Metrik ist subjektiv und signalisiert die Situation im Team und das Mikroklima insgesamt. Der zweite und dritte - bezogen sich direkt auf die Entwicklung und spiegelten wichtige Parameter zu dieser Zeit wider: Viele Teams hatten Probleme mit der Einhaltung von Fristen.
Ein weiterer Kanal zur Informationsbeschaffung sind Fragebögen, die ebenfalls nicht vermieden werden sollten. Zum Beispiel besteht das gesamte Skyeng-Entwicklungsteam aus verteilten Mitarbeitern, und aufgrund der unterschiedlichen Zeitzonen ist es schwierig, persönlich physisch miteinander zu sprechen. Für uns waren regelmäßige Umfragen im Online-Format der Ausweg. Sie nehmen nicht viel Zeit in Anspruch, ein Mitarbeiter kann sie durchgehen, wenn es für ihn günstig ist, und dafür müssen Sie keine Zeitnischen im Kalender oder einen Besprechungsraum im Moskauer Büro reservieren.
Das Problem ist, dass Entwickler nicht immer rechtzeitig darüber sprechen, was sie beunruhigt. Diese Informationen können nur durch persönliche Kommunikation erhalten werden, so dass ein guter CTO eine „Öffnungszeit“ haben sollte oder sogar ein Gespräch mit allen Teamleitern und Entwicklern geplant werden sollte.
Jeder Entwickler sollte das Recht haben, unter Umgehung seines eigenen Teamleiters einen Termin bei einem höheren Manager zu vereinbaren . Andernfalls werden Sie vor der Erhaltung von Problemen und deren Schweigen stehen.
Kommunikation mit dem Kunden
Es spielt keine Rolle, ob Sie in einem Lebensmittel- oder Outsourcing-Unternehmen arbeiten. Jede Entwicklung hat immer einen Kunden: intern oder extern. In einigen Unternehmen wird dies explizit ausgedrückt, in einigen nicht - aber es gibt immer einen Kunden.
Kundenfeedback ist eine wichtige Information, da es Probleme aufdecken kann, die von innen nicht sichtbar sind, und den Entwicklungsprozess von außen betrachtet. Wenn der Kunde vollkommen zufrieden ist und keine Kommentare zu seiner Interaktion mit den Entwicklern abgeben kann, läuft in dieser Hinsicht alles mehr oder weniger erfolgreich und interne Probleme gehen nicht auf das Team über.
Auf der anderen Seite ist ein Szenario möglich, in dem sich die Entwicklung anscheinend bewegt, aber nach Kundenrückruf eher ein Chaos als ein Produkt ist: Nichteinhaltung von Fristen, Kommunikationsprobleme, falsche Interpretation von TK. Jeder dieser Kommentare ist ein ernstzunehmender Grund, sich mit den Prozessen des Teams zu befassen und herauszufinden, ob wirklich alles so ist. Wenn die Worte des Kunden bestätigt werden, müssen Sie nach den Ursachen suchen.
Testergebnisse können unerwartet sein. So stellen sich beispielsweise einige der Fragen aufgrund unzureichender Motivation der Mitarbeiter: Es fällt jedem schwer, jeden Tag sein Bestes zu geben und keine Anreize für seine Arbeit zu bekommen. Und verwechseln Sie in diesem Fall „Ermutigung“ nicht mit „Entschädigung“ (die zweite ist das Gehalt). In diesem Fall sind sowohl materielle als auch immaterielle Anreize geeignet: Boni, Boni, einige Firmenveranstaltungen und Chips für Mitarbeiter. Selbst das Ersetzen von Geräten oder das
Erfüllen von „optionalen“ Anforderungen von Untergebenen kann Entwicklern zeigen, dass ihre Arbeit wertvoll ist und beachtet wird. Dies wiederum erhöht die „Moral“ und Produktivität.
In dieser Situation ist es besonders vorsichtig, die "Support" -Mitarbeiter zu behandeln, die aufgrund ihrer eigenen verrückten Bemühungen die Fakaps anderer Teammitglieder schließen. In jedem Team gibt es solche Leute, und selbst wenn es dem gesamten Team gut geht, sollten Sie den Beitrag dieser Mitarbeiter nicht vergessen. Denn wenn sie „ausbrennen“, fliegt alles in den Abgrund.
Fazit: Metriken sind nutzlos, ohne mit Menschen zu sprechen
Die Grundidee aller Reden zum Thema Metriken: Die Wahrheit kann nur im direkten Gespräch erreicht werden. Mithilfe von Metriken können Sie Probleme auf statistischer Ebene identifizieren. Beachten Sie jedoch, dass sie nur die Konsequenzen anzeigen.
- Die Metriken werden Ihnen nicht sagen, dass ein Troll in dem Team gestartet ist, das die Situation im Team vergiftet, oder dass sie den grünen Mann in das Team aufgenommen haben, der sich vorstellte, der beste Teamleiter zu sein, der jemals auf diesem Planeten gelebt hat.
- Metriken werden nicht sagen, dass das kürzlich eingeführte Tool nicht nur allen Entwicklern schadet, sondern nach dem letzten Update auch ein Teil des Bydlock-Codes einer Person ist, der in jeder Hinsicht unwirksam ist.
- Metriken sagen Ihnen nicht, dass in der Phase der Kommunikation mit dem Kunden und der Diskussion über TK ein solches Durcheinander entsteht, dass das Team anstelle der bedingten „Straßenbahn“ damit begann, einen „Oberleitungsbus aus einem Laib Brot“ zu erstellen.
Metriken können nur die Tatsache eines Problems anzeigen.Aber was ist das Wesentliche - Sie müssen vor Ort verstehen. Verstehen Sie durch Gespräche, Besprechungen, Umfragen, dh durch direkte Interaktion mit lebenden Menschen. Und die Metriken zeigen Ihnen, wo, wann und mit wem Sie sprechen müssen, aber nicht mehr.
ps Am Mitap teilten sie ihre Ansichten:
* Sergey Lystsev (Plesk);
* Egor Tolstoi (Avito);
* Alexander Andronov (Dodo Pizza);
* Andrey Shelyokhin (Tinkov);
* Alexey Parshukov (Skyeng, Ex-DocDoc);
* Andrey Ryzhkin (Agima);
* Alexey Chekanov (TsIAN);
* Danila Shtan (Yandex.Vertical, Ex-Tochka)
Vielen Dank!
pps Wenn Sie daran interessiert sind, die Vollversion des Mitaps anzuhören / anzusehen (es enthält auch Fragen zur finanziellen Motivation, zur Einstellung, zum Grad des Eintauchens des CTO in die Technologie usw.) - schreiben Sie persönlich. Die Platte erwies sich als nicht sehr hochwertig, so dass wir nicht damit begonnen haben, sie öffentlich zu machen. Wir sind jedoch immer bereit, sie mit denen zu teilen, die sie wirklich brauchen.