Wie bewerte ich als Teamleiter Projekte?

Timlids schätzen Projekte oft und nicht jeder macht es gut. Hier hängt vieles von der Persönlichkeit des Teamleiters selbst sowie von seinem Verständnis des Teams ab. Es gibt viele Techniken zur Bewertung von Projekten von der Methode „analog“ bis zur PERT. Aber heute werde ich darüber sprechen, wie ich Planungspoker und andere Techniken verwende, um genauer und mit größerem Nutzen zu bewerten.




Bevor auf spezifische Ansätze eingegangen wird, lohnt es sich, auf die Hauptschwierigkeiten des Prozesses einzugehen.

Eine Bewertung hat immer zwei Seiten: ein Team und einen Kunden. Der Teamleiter oder Manager ist gezwungen, einen Ausgleich zwischen den Interessen zu suchen. Es ist unmöglich, die Schätzung zu überschätzen, da der Kunde sich weigert, mehr zu zahlen. Unterschätzen lohnt sich auch nicht. In diesem Fall müssen Sie das Tempo des Teams stören und riskieren übermäßige Müdigkeit, Burnout und die Tatsache, dass der Code ungeprüft in die Produktion geht.

Die Tiefe des Studiums der Bewertungsaufgabe ist eine philosophische Frage. Aufgaben können lange besprochen werden, dann verzögert sich die Bewertung des gesamten Sprints. Wenn Sie sich jedoch nicht mit der Essenz befassen, können Sie etwas Wichtiges übersehen, das sich auf die Frist auswirkt.

Schwache und starke Entwickler verhalten sich unterschiedlich. Wenn ein starker Entwickler die Aufgabe schätzt, wird der schwache seine Fristen nicht einhalten. Umgekehrt machen die Starken die Aufgabe viel schneller als die Schwachen. In Anbetracht des Unterschieds in der Arbeitsgeschwindigkeit sind bei der Bewertung unterschiedliche „soziale“ Fehler möglich, z. B. wenn ein schwacher Entwickler zu einem Zeitpunkt „guckt“, zu dem ein starker Entwickler eine Aufgabe bewertet und dieselben Fristen festlegt, um nicht zu erklären, warum seine „Schätzung“ länger ist: „ Er hat die Woche angerufen, kann ich nicht sagen, dass es drei dauern wird? Ich werde mindestens eineinhalb sagen ... "

Das sogenannte Planungspoker hilft, dieses Problem zu umgehen, wenn das gesamte Team an der Bewertung teilnimmt, nicht weiß, wer die Aufgabe sein wird, und sie blind bewertet, ohne zu sehen, was die Kollegen anbieten.


Autor: Hkniberg aus der englischen Wikipedia - Von en.wikipedia nach Wikimedia Commons verschoben., Public Domain Jeder führt die

Aufgabe in seinen Köpfen aus. Wenn die von den Teammitgliedern angegebenen Bedingungen sehr unterschiedlich sind, beginnt die Diskussion. In diesen Momenten stellt sich normalerweise heraus, dass das Team keine Funktion bemerkt hat, die als Teil der Aufgabe implementiert werden müsste. Danach werden alle wieder abstimmen. Und dann gab es keine Behauptungen, dass jemand etwas falsch eingeschätzt hatte - alle nahmen daran teil. Selbst wenn es einen Fehler gibt, wird niemand Zeit damit verschwenden, nach den Schuldigen zu suchen. Es wird ein konstruktiveres Gespräch darüber geben, welche neuen Faktoren aufgetreten sind und die Ausrichtung geändert haben (und wie man sie in Zukunft berücksichtigt - wenn ich an Fehlern arbeite, habe ich in einem früheren Artikel in darüber geschrieben Absatz 5 ).

Eine genauere Bewertung des Projekts hilft dem Kunden bei zusätzlichen Fragen. Aber hier kann man leicht zu weit gehen. Einige Entwickler werden nicht um eine Bewertung gebeten, gerade weil sie den Kunden mit einer großen Anzahl von Klärungsschreiben bombardieren. Aus Sicht der Kundenbeziehungen wird die Anzahl der zusätzlichen Fragen am besten minimiert, was die Unsicherheit der Aufgabe erhöht.

Einige Tipps zur Vermeidung von Fehlern

Um den Fehler bei der Bewertung zu minimieren, befolge ich einige einfache Regeln.

Ich initiiere einen Einführungsanruf mit dem Kunden, bevor ich den ToR lese. Bei diesem Aufruf bitte ich Sie, aus der Vogelperspektive über das Problem zu sprechen: Wer wird der Endbenutzer sein, wie wird das Ergebnis angewendet, welche Geräte werden beteiligt sein (mit solchen Berechtigungen), wie sieht das Backend aus, wenn es bereits vorhanden ist usw. Danach können Sie mit dem Lesen von TK beginnen.

Beim Lesen des ToR mache ich eine Liste mit Fragen an den Kunden. Wenn Sie die Aufgabe studieren, sollten Sie in Ihrem Kopf versuchen, das gesamte Projekt zu „kodieren“ - stellen Sie sich vor, wie es aussehen wird. Die Liste der Fragen sollte so sein, dass nach Erhalt der Antworten eine verlässliche Bewertung möglich ist.
Die Hauptidee dabei ist, dass Fragen nicht schrittweise, sondern gleichzeitig gestellt werden sollten. Und oft ist es besser, eine vorbereitete Liste von Fragen aufzurufen, um die Korrespondenz nicht zu überdehnen. Dennoch vermittelt der Text viel weniger Informationen. Während des Anrufs können Sie den Bildschirm durchsuchen, wenn dies die Situation irgendwie verdeutlicht.

Wenn das Telefonieren aus irgendeinem Grund nicht möglich ist, suche ich nach einem Google-Dokument, in dem ich diese Fragen hinzufüge und der Kunde sie zu gegebener Zeit beantwortet. Dies ist eine effektivere Art der Kommunikation über eine Aufgabe als ein persönlicher Chat oder eine E-Mail. Dieses Dokument kann anschließend an Entwickler gesendet werden, die an dem Projekt teilnehmen. Sie müssen dieselben Fragen nicht erneut stellen.

Übrigens ist es wünschenswert, dass die für das Projekt verantwortliche Person die Fragen des Kunden beantwortet und nicht der ehemalige Sekretär des Direktors, der einfach die Rolle eines beschädigten Telefons spielt. Dies verringert das Risiko, dass sich die Projektparameter direkt während des Betriebs ändern.

Wenn möglich, bringe ich Entwickler ins Feld.Wenn Sie verstehen, wie das Produkt in der Realität verwendet wird, können Sie das „und“ markieren und die Punktzahl verbessern. Beispielsweise wird Software für Registrierkassen entwickelt. Und Ihre Entwickler sitzen seit 15 Jahren am Computer und haben die Kasse nicht in ihren Augen gesehen. Sie bringen sie zu Endbenutzern und bitten sie, nicht irgendwo, sondern speziell in diesem Geschäft einzukaufen. Und sie sehen, dass Tante Masha dort sitzt, die gleichzeitig zwei Knöpfe mit ihren Fingern drückt und die Buchstaben auf dem Monitor in Gläsern nicht erkennen kann. Infolgedessen verschwinden viele Fragen zum Projekt von selbst - die Schriftart wird größer, die Bestätigung der Vorgänge wird hinzugefügt. Es ist schwer, sich solche Dinge in meinem Kopf vorzustellen. Und das Gefühl der Realität, das durch einen persönlichen Besuch entsteht, wird den Entwickler für ein weiteres Jahr befeuern.
Leider ist ein solches Eintauchen nicht in allen Projekten möglich.

Ich bewerte die Aufgabe nicht, wenn die Bedingung "und" / "oder" ist. Zum Beispiel, wenn vorgeschlagen wird, "Autorisierung und Registrierung durchzuführen". Es ist kein Problem, diesen Punkt in zwei Aufgaben zu unterteilen und jede einzeln zu bewerten. Eine solche Bewertung ist genauer, da Sie keine ähnlichen, aber immer noch unterschiedlichen Entitäten mischen. Je besser die Zersetzung ist, desto genauer ist das Ergebnis.

"Oder" ist noch schlimmer, es ist immer identisch mit der unscharfen TK, aus der es unmöglich ist, genaue Schätzungen zu erstellen. Ist eine Autorisierung über soziale Netzwerke erforderlich oder nicht? Was ist, wenn es eine bestimmte API für das Backend gibt? Wenn Sie die Einzelheiten nicht kennen, können Sie einfach keine genaue Einschätzung abgeben.


Bild: Michael Dubakov @ Medium

Es kann keine 40-Stunden-Bewertung für die Aufgabe geben.Dies ist eine weitere Variation der vorherigen Regel. Agile empfiehlt, ein Projekt in Aufgaben von nicht mehr als 20 Stunden zu zerlegen. Es sollte keine unteilbaren Aufgaben für eine Arbeitswoche geben. In kleinen Portionen ist die Schätzung viel genauer.

Beim Zerlegen einer Aufgabe versuche ich, sie zu protokollieren. Es ist gleichzeitig aus zwei Blickwinkeln nützlich.

Erstens vereinfacht es den Prozess. Sobald Sie anfangen, Gedanken zu einem bestimmten Thema aufzuschreiben, entwickelt das Gehirn sie mit Vergnügen. Aus diesem Grund empfehle ich nicht, die Zerlegung mit der Schätzung zu mischen, d. H. Wählen Sie eine Aufgabe aus und bewerten Sie jede sofort. Es ist besser, das gesamte Projekt in Komponenten aufzuteilen, zu reparieren und dann sofort zu bewerten, damit Ihr Kopf nicht in zwei Modi gleichzeitig arbeitet.

Zweitens hilft das „Protokoll“ der Zerlegung, die mögliche Diskrepanz zwischen Schätzungen und Realität in der Zukunft zu erklären. Tatsächlich haben Sie eine vollständige Beschreibung der zu bildenden Aufgabe - welche Optionen haben Sie in Betracht gezogen? Sie haben beispielsweise die Autorisierung durch Login und Passwort mit einem Token, einer Token-Erneuerung usw. berücksichtigt, und der Kunde wollte, wie sich herausstellte, immer noch eine Autorisierung über soziale Netzwerke, hat jedoch einfach nicht darüber geschrieben. Ihre "Protokoll" -Zerlegung schützt das Team vor Behauptungen, dass Sie etwas geschätzt haben, aber die Fristen nicht eingehalten haben.

Ich bringe dem Team bei, die damit verbundenen Aufgaben nicht zu erledigen, bevor sie erledigt sind.Entwickler verbringen viel Zeit mit zusätzlichen Funktionen. Sie autorisieren, während sie sehen, dass irgendwo etwas repariert werden muss, und vertiefen sich in diesen Nebenprozess. Ich versuche einen Reflex hervorzurufen: Ich habe eine begleitende Aufgabe gesehen - ein separates Ticket bilden. Sie müssen die Aufgabe nicht einmal über den Teamleiter oder Manager ausführen. Wenn der Teamleiter die Aufgaben analysiert, wird er sie selbst sehen und gegebenenfalls zur Bearbeitung senden. Sie müssen also niemanden von der Arbeit nehmen (eine Aufgabe erstellt und vergessen), und die Genauigkeit der Bewertung bleibt erhalten.

Ich lege Zeit zum Testen.Bei der Bewertung vergessen viele Tester. Tatsächlich muss jede Aufgabe, insbesondere eine schwierige, von lebenden Menschen getestet werden - sie sollten darüber nachdenken und nach Fehlern suchen. Wenn sie etwas finden, gehen Fehler an Entwickler, die es bereits geschafft haben, in einen anderen Kontext zu wechseln. Sie müssen sich erneut mit dem Thema befassen. Und dieser Zyklus kann mehrmals wiederholt werden.
Zeit für die Prüfung muss gelegt werden. Diese Einschätzung erfolgt in der Regel getrennt von den Aussagen des Entwicklers.

Ich berücksichtige die Zeit für die Paarprogrammierung und andere Funktionen der Arbeit.Paarprogrammierung hilft, Erfahrungen auszutauschen und Entwickler zu motivieren. Sie setzen sich zusammen oder stöbern auf dem Bildschirm, besprechen die Aufgabe und die verwendeten Werkzeuge und nehmen der Reihe nach einige Änderungen vor. Dieser Ansatz zahlt sich für das Team aus, aber aus Sicht des Kunden bewegt sich die Aufgabe nicht doppelt so schnell. Bei Projekten, in denen ich gearbeitet habe, haben wir die Paarprogrammierung nicht ständig geübt, aber einige Aufgaben waren praktisch, um genau das zu tun. Und das haben wir in der Bewertungsphase berücksichtigt.

Ebenso müssen Sie Zeit für eine Demonstration des Kunden, Telefonieren, Korrespondenz usw. einplanen. Und im Allgemeinen muss der Entwickler effizient arbeiten, um in die Bewertung zu passen. Dazu muss er genügend Schlaf bekommen, sich normal ausruhen (und nicht das gesamte Team, das am Wochenende in der Produktion im Dienst ist) und die Arbeit nicht schneller, schneller fahren. Daher sollte die Bewertung immer auf der tatsächlichen Arbeitspraxis basieren und nicht auf der optimistischen Prognose, dass wir uns alle zusammensetzen und „den Fünfjahresplan in drei Jahren erstellen“ werden.

Ich lege Zeit für die Berechnung des Projekts. Es gibt vier Arten von Ständen: Entwicklung, Prüfung, Vorproduktion und Produktion. Es ist besser, diese Stände zu Beginn des Projekts bereitzustellen und sofort für diese Zeit abzulegen. Wenn dies nicht getan wird, wird die Synchronisation von Entwicklung, Test und Bereitstellung unterbrochen, was zu einem echten Gag werden kann.

Ich mache keine Einschätzungen von oben und unten - ich nenne einen bestimmten Begriff. Nach den Marketingregeln bedeutet ein Entwickler, wenn er "von 4 bis 12 Stunden" sagt, "schneller als 12 Stunden". Der Kunde hört "4 Stunden". Wenn die Aufgabe in 11 abgeschlossen ist, wird der Entwickler davon ausgehen, dass alles in Ordnung ist, und der Kunde wird unzufrieden sein. Es kommt vor, dass der Kunde unglücklich ist, auch wenn die Aufgabe in 4 Stunden und 15 Minuten erledigt ist. Selbst wenn ein Label mit einer minimalen und maximalen Laufzeit innerhalb des Teams (Unternehmens) erstellt und dann der Durchschnitt berechnet wird (dies ist sinnvoll), wird dem Kunden nur das Endergebnis angezeigt.

Ich nenne die Daten nur in Stunden - nicht in Tagen oder Monaten.Viele Leute denken, wenn das Projekt auf 96 Stunden geschätzt wird, wird es in 12 Tagen für 8 Stunden abgeschlossen sein, vorausgesetzt, nur eine Person arbeitet daran. Die Situation lässt sich leicht auf zwei Entwickler mit einer Bewertung von 6 Tagen hochrechnen. Aber das ist nicht wahr. Es gibt viele Aufgaben, die voneinander abhängen. Erstens können Entwickler erst dann mit der Arbeit beginnen, wenn eine Projektvorlage mit allen Montagesystemen und Ständen erstellt wurde (und diese 2-3 Tage unter Berücksichtigung der Kundenwünsche erstellt wird). Zweitens hört alles auf, wenn Planungsaufrufe vorliegen. Drittens gibt es blockierende Fehler, die Sie daran hindern, weiterzumachen. Mit anderen Worten, 96 Stunden am Arbeitsplatz bedeuten überhaupt nicht, dass 100% der Zeit (8 Stunden pro Tag) speziell für diese Aufgaben aufgewendet werden. Für die Bewertung in Tagen können wir davon ausgehen, dass der Entwickler nicht 8 hat, aber sagen wir,6 Arbeitsstunden pro Tag (die genaue Zahl muss aus der Praxis ermittelt werden).

Ich frage Entwickler immer, wie viele Stunden eine Aufgabe von einem Computer dauern wird (und nicht „nach wie lange sie fertig sein wird“). Dies ist eine Folge des vorherigen Absatzes. Bei der Interaktion mit dem Team im Rahmen der Bewertung ist es wichtig, die Frage richtig zu formulieren.

Ich berücksichtige den "Teamkoeffizienten".Normalerweise gehen die Senioren von gestern zu den Timlids. Sie bewerten Aufgaben basierend auf ihrer Erfahrung, auch wenn sie Mittelstücke in ihrem Team haben. Vielleicht arbeitet der Senior nicht viel schneller, aber nach ihm gibt es fast keine Fehler. Die Mitte ist keine solche Qualität. Daher gibt es in Agile den sogenannten „Teamkoeffizienten“, der den Unterschied zwischen dem Optimismus des Bewerters und dem tatsächlichen Leben eines bestimmten Teams zeigt. Es wird nur in der Praxis berechnet: Eine theoretische Schätzung wird mit einer realen für die letzten Sprints verglichen. Je besser der Teamleiter sein Team kennt (und je besser er die Bewertung erhalten hat), desto näher liegt dieser Koeffizient an 1.

Der „Teamkoeffizient“ berücksichtigt bei der Bewertung unter anderem auch den sogenannten „Optimismus der Entwickler“. Aufgaben werden immer anhand des Fehlens von Fehlern, des Sättigungsgefühls und der guten Laune der Darsteller sowie des Fehlens von Problemen in der Umgebung bewertet. Aber die Realität ist voller Eventualitäten und es gibt keine Möglichkeit, sich davor zu schützen. Das über einen angemessenen Zeitraum berechnete „Team-Verhältnis“ ermöglicht es, dies zu berücksichtigen.

Beim Versuch, den Einfluss des Teams zu bestimmen, gehen sie bei der internen Bewertung manchmal von Stunden zu Story-Punkten über. Da sie wissen, dass die Aufgabe 8 Story-Punkte benötigt, erinnern sie sich daran, dass 1 Story-Punkt letzte Woche 8 Stunden gekostet hat. Daraus prognostizieren sich die Arbeitskosten. Aber es fällt mir leichter, in Stunden zu denken.

Ich führe keine zusätzlichen Faktoren ein, um andere Teilnehmer des Prozesses nicht zu verwirren.Ich sehe oft Leute, die eine Bewertung auf Teamebene durchführen und Zeit für Verhandlungen legen. Die Bewertungseinheit sollte diesen Bestand jedoch nicht legen oder andere fremde Dinge berücksichtigen. Und es stellt sich heraus, dass der Entwickler die Aufgabe um 8 Uhr bewertet hat, aber aus Gründen der Wiedergabetreue mit 2 multipliziert hat. Timlid hat seine Bewertung erneut verdoppelt und sich an das Team angepasst. Und der Manager von 32 Stunden machte 40 für den Kunden (für ein ausgeglichenes Konto oder nur mit dem Ziel, dann 30 Stunden lang zu verhandeln). Dies ist eher eine Wahrsagerei auf Kaffeesatz. Ja, und der Kunde, der eine Schätzung von 40 Stunden für eine 8-Stunden-Aufgabe sieht, wird entscheiden, dass das Team nicht weiß, wie.

Wie oben erwähnt, müssen Sie auf Teamebene nur die Merkmale des Teams selbst berücksichtigen und vereinbaren, wer höhere Gewalt in die Bewertung einfließen lässt (und dies sollte dort berücksichtigt werden, da wir immer Aufgaben bewerten, vorausgesetzt, der Code-Editor fordert keine Lizenz an, Entwickler nicht krankgeschrieben werden usw.).

Ich bin fest entschlossen, die Einschätzung zu verteidigen. Die Folge des vorherigen Absatzes - Ich stehe immer fest auf meiner Einschätzung. Wenn ich weiß, dass das Projekt 6 Monate lang durchgeführt wird und von mir eine Bewertung von 3 erwartet wird, werde ich niemals 4 Monate nennen, um den Kunden oder Manager zu „befriedigen“.
Es sollte beachtet werden, dass es manchmal interne Verhandlungen gibt. Wenn Sie wissen, dass das Projekt für das neue Jahr bereit sein sollte, beginnen Sie unbewusst, die Ergebnisse der Evaluierung zu jonglieren, um die verbleibende Zeit einzuhalten. Das Gehirn dreht diese Dinge perfekt aus. Selbst wenn Sie dort eine Liste mit 200 Unteraufgaben haben, laufen diese so zusammen, dass sie den Silvesterabend feiern.

Trotz alledem bin ich bereit, dass sich die Bewertung ändert. Das ist normal - Projekte leben, entwickeln sich. Ich verstehe, dass dies ein Merkmal des Projekts zu diesem bestimmten Zeitpunkt ist.

Und das letzte Abschiedswort: Zwingen Sie Entwickler, die Termine nicht einhalten, nicht dazu, lange Briefe an Manager zu diesem Thema zu schreiben. Erstens sind sie wahrscheinlich schüchtern. Zweitens wird der Manager wahrscheinlich etwas fragen und noch einmal ablenken. Drittens geht sein Erklärungsschreiben einfach in der Korrespondenz verloren. Normalerweise bitte ich Sie, einen Kommentar zu einer Aufgabe in Jira zu schreiben. Ohne die Teilnahme einer lebenden Person (Manager) ist es normalerweise einfacher und schneller. Und während der Nachbesprechung wird es leicht zu finden sein. Und timlidu plus - alle Aufgaben, die außerhalb der Marke liegen, werden kommentiert. Arbeiten Sie erneut an Fehlern, um die Qualität der Bewertung in Zukunft zu verbessern.

Der Autor des Artikels: Eugene Wetzel ( @imater )

PS Wir veröffentlichen unsere Artikel auf mehreren Websites der Runet. Abonnieren Sie unsere Seiten inVK , FB , Instagram oder Telegramm Kanal über alle unsere Publikationen und andere Maxilect Nachrichten zu lernen.