Wie man Entwicklern genügend hochwertige Entwicklungszeit ermöglicht und gleichzeitig Support- und Wartungsverpflichtungen einhält

Mir ist etwas unklar, wie Sie die Verwaltungs-/Supportanfragen verwalten. Eigentlich ist mir unklar, ob Sie sie überhaupt verwalten. Sie müssen diese Anforderungen verwalten, um Ihre Entwickler zu schützen.

Softwareentwickler können nur dann produktiv sein, wenn sie viel Zeit „in the zone“ haben. Unterbrechungen sind das Hauptproblem, das die Produktivität und Moral von Entwicklern beeinträchtigen kann. Wenn Sie ständig im Unterbrechungsmodus sind, wo Sie sie für eine neue Anfrage unterbrechen, dann machen Sie es wahrscheinlich falsch.

Stattdessen klingt es so, als müssten Sie eine Warteschlange für Support-/Wartungsanfragen haben, in der ihnen eine Priorität zugewiesen wird. Anstatt sie sofort zu implementieren, warum lassen Sie sie nicht in der Warteschlange warten, bis Sie planmäßig daran arbeiten?

Haben Sie darüber nachgedacht, welchen Zeitanteil Sie für die Wartung im Vergleich zur Neuentwicklung aufwenden möchten, und Ihren Entwicklern dann einen entsprechenden Zeitplan zuzuweisen? Wenn Sie beispielsweise 25 % Ihrer Zeit für Wartung/Support und 75 % Ihrer Zeit für Neuentwicklung aufwenden möchten, haben Sie mehrere Möglichkeiten: Sie können jedem Entwickler eine Woche im Monat zuweisen, in der er für Wartung/Support zuständig ist und 3 Wochen des Monats, in denen sie sich auf neue Entwicklungen beziehen. Wenn eine neue Support-/Wartungsanfrage eingeht, wird sie in die Warteschlange gestellt, ihr wird eine Priorität zugewiesen, und wenn ein Entwickler Zeit für Wartung/Support eingeplant hat, beginnt er, die höchsten Elemente aus der Warteschlange zu ziehen, bis die geplante Zeit abgelaufen ist.

Eines ist klar: Sie müssen anfangen, Prioritäten zu setzen. Wenn Ihnen zu irgendeinem Zeitpunkt jemand eine Wartungs-/Support-Anfrage sendet, „springen Sie direkt darauf an“, dann haben Sie implizit eine Prioritätsentscheidung getroffen: Sie haben entschieden, dass jede Wartungs-/Support-Anfrage (egal wie geringfügig) wichtiger ist als Neuentwicklung (egal wie wichtig). Wenn dies nicht mit den Prioritäten übereinstimmt, die für Ihr Unternehmen am sinnvollsten sind, müssen Sie vielleicht noch einmal überdenken, wie Sie Prioritäten setzen und wie sich diese Prioritäten in der Arbeit Ihres Teams widerspiegeln.

Sobald Sie mit der Priorisierung beginnen, stellen Sie möglicherweise fest, dass Sie mit Ihrem bestehenden Team nicht alles erledigen können. An diesem Punkt haben Sie zwei Möglichkeiten: Stellen Sie mehr Entwickler ein oder akzeptieren Sie, dass es einige Aufgaben gibt, die Sie mit Ihren vorhandenen Ressourcen nicht erledigen können und wollen.

Verwenden Sie Swimlanes auf Ihrem Board (oder verschiedenfarbige Karten), um die Art der Arbeit anzugeben.

Ein Team, mit dem ich zusammengearbeitet habe, teilte sein Board horizontal in zwei Teile – oben für die Entwicklung neuer Produkte, unten für Support/Wartung. Jeder Steam hatte ein separat priorisiertes Backlog, aus dem die Teams Arbeit ziehen würden, wenn sie bereit wären. Das bedeutete, dass wir immer eine Mischung aus neuer Entwicklung und laufender Wartung hatten.

Verwenden Sie Work-in-Progress-Limits , um deutlich zu machen, wie Sie die Teamzeit ausgleichen.

Im obigen Team hatten wir ein Work-in-Progress-Limit von 3 Stockwerken für die Entwicklung neuer Produkte und 1 für die Wartung, sodass klar war, welches Verhältnis der Teamzeit wir für jede Art von Arbeit aufwenden würden.

Verwenden Sie Beschleunigungskarten , um wichtige Arbeiten zu beschleunigen .

Wir haben auch zugelassen, dass ein Beschleunigungs-Token (wir haben nur einen großen roten Stern verwendet) vom Product Owner auf Karten platziert werden kann. Es wurde erwartet, dass eine Karte mit einem Beschleunigungsmarker die erste Priorität für die Bearbeitung erhält, sodass sie schneller über das Brett fließen würde, auf Kosten anderer Arbeiten, die langsamer abgeschlossen werden. Dies ermöglichte es dem PO, Live-Probleme schnell zu lösen und machte deutlich, wann wir etwas im Spiel hatten, das alles andere verlangsamen würde.

Beobachten Sie jedoch, wie oft dies verwendet wird. Sie müssen das PO trainieren, es nur dann zu verwenden, wenn es wirklich notwendig ist, und sich nicht angewöhnen, es einfach immer in einer Geschichte im Spiel zu haben.

Das Kanban-Buch von David Anderson untersucht diese Konzepte ausführlicher und ist sehr zu empfehlen.

Es ist etwas unklar, ob Sie nach Schätzung oder nach Priorisierung fragen.

Ich denke, viele Antworten hier befassen sich mit dem Aspekt der Priorisierung, daher werde ich nicht darauf eingehen.

Wenn Sie sich fragen, wie Sie Ihren Aufwand einschätzen sollen, da viele davon ungeplante Arbeit sind, dann gibt es eine Menge Dinge, die Sie tun können, aber eine vollständige Lösung ist wahrscheinlich unmöglich zu finden, aus dem einfachen Grund, dass F & E-Projekte beinhalten naturgemäß ein hohes Maß an Unsicherheit, die zu Beginn eines Projekts nicht ohne Weiteres quantifiziert werden kann.

Aber lassen Sie uns zuerst darüber sprechen, was Sie tun können .

Woher kommt diese ungeplante Arbeit?

Es kann manchmal so aussehen, als ob ungeplante Arbeit einfach von oben, von der Seite und aus allen anderen Richtungen auf Ihr Team abgeladen wird. Aber manchmal kann ein Team es selbst herbeiführen. Ein triviales Beispiel: Ein Team, das in großer, großer Eile versendet und fehlerhaften Code liefert, verbringt später natürlich viel Zeit damit, Brände zu löschen. Übrigens ist das Versenden von Buggy-Code keine Art zu sagen: „Hey, du bist scheiße beim Codieren“ – manchmal ist es wirklich der Druck von außen oder das Team, Qualität für Kosten zu opfern.

Wie können Sie ungeplante Arbeit vermeiden?

Wenn Sie die Zeit, die Sie für ungeplante Arbeit aufwenden, reduzieren möchten, müssen Sie zunächst ermitteln, um welche Art von Arbeit es sich handelt, und dann daran arbeiten, sie zu reduzieren. Wenn Ihr Entwicklungsteam beispielsweise ständig damit beauftragt wird, Außendiensttechniker bei der Installation und Konfiguration des Systems in Produktionsumgebungen zu unterstützen, sollten Sie vielleicht der Automatisierung dieser Bereitstellungsaufgaben Vorrang einräumen. sie umzugestalten, damit sie einfacher, weniger riskant usw.

Das Messen von ungeplanter Arbeit bringt Ihnen nichts

Es mag wie eine gute Idee erscheinen, zu messen, wie viel Zeit Sie während der letzten paar Sprints für ungeplante Arbeit aufgewendet haben, und von dort aus zu extrapolieren, aber es ist ein Irrweg. Das Unvorhersehbare vorherzusagen ist zwecklos. Ihr nächster Sprint kann völlig reibungslos verlaufen, und der darauffolgende könnte durch das größte Clusterf&ck-Produktionsproblem entgleisen, dem Sie jemals begegnet sind. Das wirst du einfach nicht vorhersagen können.

Das Problem ist, dass die Softwareentwicklung in fast allen Fällen einen guten Teil ungeplanter Arbeit enthält. Manchmal zählt man es einfach nicht dazu. Es ist leicht, ein verzögertes Projekt als einfach unterschätzt anzusehen, aber meistens liegt das Problem nicht darin, wie Sie schätzen, sondern womitdu schätzt. Sofern Ihre Entwicklungsprojekte nicht vollständig repetitiv sind (d. h. ständig dasselbe Produkt immer und immer wieder entwickeln), sind sie aufgrund der Verwendung neuer Tools, der Bewältigung neuer Probleme usw. mit einem hohen Maß an Ungewissheit ausgestattet. Sie beginnen mit einem großartigen Arbeitsplan, aber nach zwei Tagen stellen Sie fest, dass die Bibliothek, die Sie verwenden wollten, nicht wirklich von der Zielplattform unterstützt wird, und jetzt müssen Sie eine Alternative finden oder, Gott bewahre, etwas entwickeln allein. Das sind die wirklichen Kicker – die Dinge, die Sie bei der Planung überhaupt nicht gezählt haben.

Wie schätzen wir also angesichts all dieser unvermeidlichen ungeplanten Arbeiten ein ?

Die ganze Idee, nur das zu tun, was Sie geplant haben, mit minimaler ungeplanter Arbeit, ist für die meisten F&E-Teams einfach nicht in Sicht. Offensichtlich. Deshalb ist Agilität so beliebt. Sie können versuchen, ungeplante Arbeiten bis zu einem gewissen Grad zu minimieren, aber am Ende werden die Zeitpläne Ihrer Projekte immer von ungeplanten Dingen dominiert. Sobald Sie erkennen, dass ungeplante Arbeit Ihr Brot und Butter ist, können Sie jetzt Ihre Projektmanagementmethoden anpassen, um besser damit umzugehen:

• Machen Sie einen Drilldown und planen Sie Ihre Iterationen im Detail. Es braucht nicht viel Zeit, wenn Sie ein anständiges PM-Tool haben. Brechen Sie die Dinge gegebenenfalls auf stundenlange Aufgaben herunter. Dies wird eine Menge "ungeplanter" Dinge ausspülen.
• Priorisieren Sie die riskanten Dinge. Wenn Sie Dinge in kleine Stücke zerlegen, sehen Sie sofort, wo Ihre Unsicherheit liegt. Bei diesen Aufgaben weißt du nicht wirklich, wie du sie weiter aufschlüsseln sollst, und du bist dir nicht wirklich sicher, wie lange sie überhaupt dauern werden. Beginnen Sie, wenn möglich, damit. Auf diese Weise wird Ihre Schätzung immer noch abweichen, aber sie wird sich im Verlauf Ihrer Iteration erheblich stabilisieren. Sie werden in den letzten paar Tagen der Iteration nicht plötzlich feststellen, dass Sie noch 10 Tage brauchen, um das zu beenden, was Sie begonnen haben.
• Verhandeln Sie mit den Projekt-/Produktmanagern, um an der häufigsten externen Quelle ungeplanter Arbeit zu arbeiten. Würde zB eine bessere Dokumentation Ihren Technikern viel Zeit sparen, die sie Außendiensttechnikern oder Kunden erklären müssen? Fordern Sie dann, im Rahmen der Entwicklungsarbeit Zeit dafür einzuplanen.

Das ist eine sehr gute Frage. Was unser Entwicklungsteam, die Art unserer Arbeit und die Notwendigkeit, auf Supportanfragen zu reagieren, betrifft, sitzen wir genau im selben Boot wie Sie. Mit anderen Worten, ich kann nachvollziehen, wie schwierig es ist, dieses Gleichgewicht zu finden, das Sie suchen.

Unsere Lösung – die keineswegs perfekt ist – bestand darin, einen strengen täglichen Feedback-Zyklus mit unseren Kunden einzuführen, der wie folgt funktioniert:

1. Jeden Morgen überprüft der Projektmanager ausstehende Supportanfragen und bespricht sie mit dem Team. Das Team arbeitet dann an der Support-Anfrage ganz vorne in der Warteschlange (Last-in-Last-out), während der Projektmanager dem Kunden antwortet, um zu bestätigen, was an diesem Tag bearbeitet wird.
2. Jeden Morgen, wenn die Support-Anfrage des Vortages teilweise abgeschlossen ist und eine weitere Support-Anfrage eingeht, wird diese neue Support-Anfrage am Ende der Support-Anfrage-Warteschlange hinzugefügt. Dies muss in der täglichen Feedback-E-Mail am nächsten Morgen explizit kommuniziert werden.
3. Wenn es keine ausstehenden Supportanfragen gibt, macht sich das Team jeden Morgen an die Produktentwicklung. Wenn tagsüber eine Support-Anfrage eintrifft, bearbeiten Sie diese erst am nächsten Morgen. Auf diese Weise unterbrechen Sie Ihr Team nicht, aber gleichzeitig wissen sie, weil Sie eine tägliche Feedback-Routine mit Ihren Kunden erstellt haben, dass sie Ihre E-Mail erst am nächsten Morgen erwarten können.

Der wichtigste Punkt hier ist, die Erwartungen zu managen, indem man jeden Morgen eine tägliche Feedback-Routine erstellt (und durchsetzt). Wenn Sie sich Sorgen darüber machen, wie Sie diese Idee Ihren Kunden verkaufen können, konzentrieren Sie sich darauf, Ihre kompromisslose Haltung zu Qualität explizit zu kommunizieren.

Sie werden feststellen, dass Ihre Kunden nach einiger Zeit lernen werden, mit Ihrem morgendlichen Feedback-Zyklus zu arbeiten und das Gefühl der Stabilität, das sich aus der täglichen Routine ergibt, zu schätzen wissen.

Wie gesagt, es ist keineswegs perfekt, aber es funktioniert gut für uns.

Es gibt viele Meinungen über Multitasking und seine Auswirkungen auf Leistung und Produktivität und vielleicht auch auf die Moral. Die einzigen definitiven Studien, die ich über Multitasking gesehen habe, sind die Dinge zwischen Männern und Frauen, also weiß ich nicht, ob ich eine harte Haltung einnehmen würde, wenn eine Person sowohl eine Entwicklungs- als auch eine Unterstützungsrolle tragen soll. Klar ist jedenfalls, dass Sie Ihre Schätzungen und Planungswerte anpassen müssen.

Wenn Sie nicht mehr Leute einstellen können, müssen Sie die Dauer Ihrer Sprints anpassen, sie nach rechts schieben, sekundär zu den niedriger als erwartet verfügbaren Entwicklerauslastungsraten. Unterstützung ist Unterstützung. Das Angebot muss die Nachfrage decken; sonst haben Sie unzufriedene Kunden. Und die Nachfrage variiert, daher muss Ihr Planungswert auf dem Niveau liegen, um den größten Teil des Angebots aufzunehmen.

Entwicklungspläne können verschoben werden und niemand stirbt. Der Versuch, Ihre Reaktion auf den Support zu kontrollieren, und jemand stirbt ... natürlich metaphorisch. Schätzen Sie also die Nachfrageseite der Unterstützung neu ein und erstellen Sie einen Fall, um entweder mehr Talente einzustellen, damit Sie die Rollen neu strukturieren und trennen können, oder planen Sie die Entwicklung mit der verbleibenden Zeit für die Arbeit.

Hier würde ich gerne denken, dass die Lean-Konzepte sehr gut funktionieren, wenn sie praktiziert werden.

Verwenden Sie ein Kanban-Board und verpflichten Sie sich, jeden Tag 3 bis 4 Aufgaben im Rahmen des Supports zu erledigen, und verwenden Sie die restliche Zeit für Entwicklungsarbeit.

Dies bedeutet sicherlich, dass Sie die Wahl haben, 28 Stunden an einem Tag zu planen und etwas voranzutreiben, das schnell mit Chaos zurückkommen kann, oder einem kontinuierlichen Lieferfluss über beide Ströme zuzustimmen und schließlich den Produktivitätsfaktor beim Erreichen der Ziele zu steigern.

Ich hatte einige Erfolge bei der Überprüfung des Umfangs der „Business-as-usual“- und Support-Arbeit, die in den nächsten zwei Wochen erforderlich ist (aus JIRA und anderen Quellen), während unserer Sprint-Planung und der entsprechenden Reduzierung der verfügbaren Zeit für „neue“ Entwicklung. Dies vermeidet übermäßige Versprechungen in Ihrem Sprint und stellt sicher, dass der Supportbedarf erfüllt wird.

Wenn Sie dies noch nie zuvor getan haben, wird dies natürlich Auswirkungen auf Ihre Geschwindigkeit haben. Daher müssen Sie dies entweder im Laufe der Zeit überprüfen und zukünftige Liefertermine gegebenenfalls anpassen oder eine realistische Einschätzung des Prozentsatzes Ihrer verbrauchten Entwicklungszeit vornehmen unterstützen und auf dieser Basis anpassen. Was Sie unbedingt vermeiden müssen, ist, dass Ihr Produktmanager (oder wer auch immer) denkt, dass Sie in einem Sprint beispielsweise 100 Story Points abschließen können, wenn Sie in Wirklichkeit normalerweise nur 80 abschließen.

Es kann anfangs etwas chaotisch sein und es ist möglich, dass die Leute enttäuscht sind, dass Fristen verschoben werden müssen. Sie müssen dies bewältigen, indem Sie darauf hinweisen, dass realistische Fristen für die geistige Gesundheit aller nützlicher sind, und die Auswirkungen erklären, die Multitasking und Last-Minute-Anfragen auf Entwickler und die Codequalität haben.

Die Bedeutung einer guten Priorisierung ist – wie andere bereits betont haben – ebenfalls absolut entscheidend. Eine offene Bewertung des geschäftlichen Werts von beispielsweise einer Fehlerbehebung gegenüber der Entwicklung einer neuen Funktion muss vorgenommen werden, bevor sich Ihr Zeitplan ändert.

Es gibt verschiedene Themen, die geclustert werden sollten, manche sind kulturell, manche sind Prozesse (oder deren Fehlen). Ich verstehe die Situation, in der Sie sich befinden, vollkommen, ich war auch dort. So pflegst du es:

Verfahren

1. Komponententests – erhalten Sie eine Codeabdeckung von über 90 %. Auf diese Weise kann Ihr Team Fehlerbehebungen und Systemänderungen vornehmen, ohne sich Sorgen machen zu müssen, dass etwas anderes kaputt geht. Es spart Ihnen Zeit, da es automatisiert und gründlich ist, anstatt manuelle Tests durchzuführen.
2. Kontinuierliche Integration - automatisches Starten von neuem Code. Ich sehe nicht, ob Sie ein Webunternehmen sind oder nicht. Unabhängig davon gibt es Möglichkeiten, Code buchstäblich in der Sekunde, in der er fertig ist, an das Live-Produkt zu senden.
3. Aufgabenverwaltung - Messen Sie den Fortschritt, während er erledigt ist. Die Verwendung eines dieser Tools stellt sicher, dass jeder Entwickler, Sie und alle anderen Manager in Echtzeit genau sehen können, was getan wird und wer wofür zuständig ist. Es gibt mehrere Systeme und viele Plugin-Adapter für viele IDEs, insbesondere Eclipse.
4. Genaue Schätzungen - Wenn Sie die Zeit schätzen, fragen Sie einen Entwickler, oder machen Sie es nicht die ganze Zeit selbst als Projektmanager. Lassen Sie sich nicht sofort antworten, geben Sie ihnen 1 Tag oder länger. Wenn Sie dies nicht tun, werden sie unbewusst versuchen, den Leuten zu gefallen, und sie werden nicht in der Lage sein, genau einzuschätzen, da sie nicht an alle Details der Implementierung gedacht haben. Das Backen eines Kuchens ist innerhalb von 2 Stunden einfach, aber es wird davon ausgegangen, dass Sie alle Zutaten, Kochgeschirr usw. haben.

Kultur

1. Jedes Mal, wenn ein Team unter Druck gerät, liegt dies daran, dass es „die Erwartungen nicht erfüllt“. Die Menschen über / neben Ihnen haben eindeutig ein Unverständnis dafür, wozu Ihr Team fähig ist. Sie müssen es ihnen beibringen. Ein Task-Management-System hilft dabei. Es wird ihnen beibringen, wie viel Zeit es braucht, um eine bestimmte Aufgabe zu erledigen, und ihnen zeigen, was gerade getan wird. Viele Leute außerhalb einer Abteilung gehen davon aus, dass die Abteilung 10+ Stunden hat. pro Woche "offene Zeit". Zeigen Sie ihnen, dass dies nicht der Fall ist.
2. Die Projektplanung sollte in kleineren Schritten erfolgen, mit der Erwartung, dass 1/3 oder mehr des Teams für andere Dinge aufgewendet wird. Je weiter Sie ein Projekt in die Zukunft planen, desto ungenauer wird diese Schätzung. Ich ziehe es vor, auf monatlicher Basis oder weniger zu planen.
3. Priorisieren Sie eingehende Anfragen. Ich erstelle gern einen „Ideenspeicher“ und eine „Liste der nächsten Versionen“ für Funktionsanfragen. Der Ideeneimer eignet sich gut für allgemeine Ideen, die entweder nicht geschäftskritisch sind oder deren Umsetzung viel Zeit in Anspruch nehmen würde. Die nächste Versionsliste ermöglicht es Ihnen, den Bereich einzuschleichen. Wenn Sie 1 Monat Zeit haben, um ein bestimmtes Projekt fertigzustellen, Zeit für andere Dinge verloren geht, können Sie einige der weniger wichtigen Funktionen auf die nächste Versionsliste auslagern .
4. Konzentrieren Sie sich auf Feedback von jeweils einer Abteilung. Es gibt für jedes Projekt eine Anlaufzeit, und wenn mehr als 3 Abteilungen gleichzeitig Funktionen anfordern, bedeutet dies, dass viel Zeit für die Anlaufzeit aufgewendet wird, anstatt Code zu starten. Ich habe festgestellt, dass es sehr effektiv ist, sich alle 4 Wochen auf die Anfragen einer Abteilung zu konzentrieren. Einen Monat für den Verkauf, den nächsten Monat für das Marketing, den nächsten Monat für die Redaktion usw.
5. Holen Sie sich einen engagierten Kundenbetreuer, auch wenn es sich um einen Praktikanten handelt. Die Zeit Ihrer Entwickler ist sehr wertvoll, sie sollten nicht unterbrochen werden, da sie jedes Mal, wenn sie gebeten werden, etwas Neues zu tun, für mehr als 15 Minuten aus dem Fluss (Deep Thinking Mode) geraten. Entwickler sind gut darin, Code zu schreiben, und sollten eine Umgebung haben, in der sie dies tun können.
6. Machen Sie ein Wiki. Dieses Wiki ermöglicht es Ihnen und dem Team, alles zu posten, was mehr als 4 Sätze zur Erklärung erfordert. Ihre Standardantwort auf jede Frage lautet jetzt: Haben Sie das Wiki überprüft? Es spart Zeit, teilt Informationen und macht alle glücklicher.

Viel Glück!

Wir wenden zwei Techniken an, um dies in den Griff zu bekommen:

Zunächst müssen Sie sich für die Bandbreite (Kapazität) entscheiden, die Sie für die Erledigung der gesamten Arbeit zur Verfügung haben. Dies ist Ihre Teamkapazität, die produktive Arbeit leistet (also Urlaub, Training, durchschnittliche Krankheitstage usw. extrahieren).

Als nächstes teilen wir diese Kapazität in feste Eimer auf : unsere ist

• 60 % Geplante Entwicklung : genehmigte Entwicklungsarbeit, um neue Dinge zu schaffen (Investition); Mit diesen 60 % verfügbarer Kapazität können Sie planen, wann all diese neuen Sachen frühestens geliefert werden (wenn die 60 % eingehalten werden).
• 20 % Ad-hoc-Kundenanfragen : kleine Änderungen und spezifische Konfigurationen
• 20 % Support und Wartung

Wenn mehr Support benötigt wird, wird zuerst die Kapazität der Kundenanfragen in Anspruch genommen.

Nach jeder Periode (Sprint, zweiwöchentlich, monatlich, was auch immer) werden die Ist-Werte überprüft und eine Entscheidung über die Buckets für die nächste Periode getroffen und diese entsprechend geplant. z.B

• Es war mehr Support erforderlich, und infolgedessen stehen genehmigte Kundenanfragen an. Daher werden wir für den nächsten Zeitraum 30 % für Kundenanfragen und nur 50 % für die Entwicklung zuweisen. Dies wird sich auf die Lieferung der geplanten Entwicklung auswirken, daher wird dies neu geplant und die Auswirkungen genehmigt.
• es war eine schwache Zeit für Unterstützung (selten, aber es passiert :-) ), also haben wir einige Fortschritte bei der geplanten Entwicklung gemacht, also machen wir entweder wie vereinbart weiter (60-20-20), um dem Zeitplan voraus zu sein, oder wir etwas mehr Arbeit an Kundenanfragen erledigen.

Wenn die Kapazität für den Support dauerhaft nicht ausreicht, ändern Sie die Kapazitätszuordnung (mit Auswirkungen auf die anderen beiden natürlich). Oder entscheiden Sie sich, die Gesamtkapazität zu ändern, indem Sie (falls möglich) Personen zum Team hinzufügen.

Hier geht es darum, die verfügbare Kapazität für alle sichtbar zu halten, die Arbeit nach Eimern (und nicht nach Schätzungen) zu planen und fundierte Entscheidungen über Korrekturmaßnahmen zu treffen.

Die zweite Technik, die wir anwenden, dient eher dazu, die einzelnen Ingenieure zufriedener zu halten, und besteht darin , jede Woche eine (oder mehrere, zB funktionale und technische) Person für den Support zuzuweisen (wir nennen ihn den "Geek of the Week" :-) ). Er/sie versucht, alle Support-Probleme selbstständig zu beheben; nur wenn es wirklich komplex ist, bittet er die anderen teammitglieder um hilfe. Wenn die Unterstützung gering ist, nimmt er andere Dinge wie eine kleine Änderung in Angriff oder arbeitet weiter an der geplanten Entwicklung. Dadurch können sich die anderen Teammitglieder besser auf ihre jeweiligen Themen konzentrieren, ohne zu oft durch Supportprobleme gestört zu werden. Da sich die Rolle jede Woche ändert, wird sie als fair für alle angesehen.

Das funktioniert gut für uns. Viel Glück!

Versuchen Sie, einen Teil Ihrer Entwickler Wartungs-/Supportaktivitäten zu widmen. Dies vermeidet Probleme im Zusammenhang mit Multitasking, die Notwendigkeit, Support gegenüber neuen Projekten zu priorisieren, beseitigt eine Quelle der Unvorhersehbarkeit aus Ihrer Sprintplanung und sollte den Stress für Ihr Team reduzieren.

Der genaue Anteil Ihrer Entwickler, die Wartungs-/Supportarbeiten durchführen, hängt von Ihrem durchschnittlichen monatlichen Volumen an Problemen mit aktuellen Produkten im Vergleich zu laufenden Arbeiten ab. Wenn Sie diesen Ansatz ausprobieren, möchten Sie auf jeden Fall ziemlich häufig und regelmäßig wechseln, wer Wartungs- / Supportarbeiten durchführt, damit jeder die Möglichkeit hat, die "coolen Sachen" zu machen.

Als jemand, der in einem Inhouse-Team arbeitet, kommt mir das sehr bekannt vor. Abgesehen von der Möglichkeit, dass Sie einfach nicht genug Ressourcen haben, um die ganze anfallende Arbeit zu bewältigen, sind dies einige Strategien, die funktionieren könnten:

• Weisen Sie einen oder zwei Entwickler der Unterstützungsarbeit zu und rotieren Sie sie regelmäßig, es sei denn, Sie haben Leute, die eigentlich die ganze Zeit Unterstützung leisten möchten. Dies hat den Vorteil, dass sehr deutlich wird, wie viel Zeit für die Unterstützung von Aufgaben benötigt wird. Wenn Sie 2 von 6 Entwicklern dem Support widmen und sich herausstellt, dass dies nicht ausreicht, sind Sie sich zumindest der einfachen Tatsache bewusst, dass der Support 50 % oder mehr Ihrer Entwicklungszeit auffrisst.
• Verwenden Sie WIP-Limits religiös. Expedite Tokens/Lanes sind toll, sollten aber limitiert sein, sonst stellt sich alles als sehr dringend heraus. Stellen Sie sicher, dass WIP-Limits auf der Realität basieren. Siehe den vorherigen Punkt, wie man diese Realität bestimmt.
• Versuchen Sie herauszufinden, ob Ihr Code ständig bereitgestellt wird, während er noch mit Fehlern behaftet ist, und beheben Sie das. Eiljobs sind eine Tatsache des Lebens, wenn/wenn der Druck hoch ist, aber normalerweise zahlen Sie danach den Preis. Angesichts überhitzter Marketingleute, die sofortige Aufmerksamkeit verlangen, ist mein einziger Rat, einen kühlen Kopf zu bewahren und ruhig, aber streng an der „Eine Arbeit, die es wert ist, getan zu werden, ist es wert, richtig gemacht zu werden“-Routine festzuhalten.
• Wenn sich irgendwann herausstellt, dass Sie sich in einer Unternehmenskultur befinden, in der Geschwindigkeit jedes Mal die Qualität übertrumpft, kehren Sie zu meinem ersten Punkt zurück. Weisen Sie einen oder zwei Entwickler zur Unterstützung zu, rotieren Sie sie und kümmern Sie sich um die wirklich dringenden Dinge. Wenn sich der Rückstand zu füllen beginnt, erklären Sie dem Management, dass Sie bereits 1/3 Ihrer Zeit für den Support aufwenden, und vielleicht, nur vielleicht, können Sie damit beginnen, diese Unternehmenskultur umzukehren.

Im Grunde läuft mein Rat darauf hinaus, die Menschen dazu zu bringen, sich auf das Wesentliche zu konzentrieren. Wenn die ständige Nachfrage nach „dringenden“ Support-Jobs der wirklich produktiven Zeit im Wege steht, müssen Sie diese ständige Nachfrage von so vielen Menschen wie möglich entfernen.

Überschätzen Sie die Zeit, die Sie in jedem Zeitraum für Support und Wartung aufwenden werden, mit einem angenehmen Spielraum, den Ihr Team als schwere Last betrachten würde. Planen Sie diese Zeit für die Wartung ein und planen Sie Ihre verfügbare Entwicklungszeit darum herum. Sie können die verbleibende Wartungszeit jederzeit für zusätzliche Entwicklungen verwenden, und es sieht gut aus, wenn das Team mehr erreicht, als Sie erwartet haben. Es ist nicht möglich, die genaue Zeit zu schätzen, die Sie für die Wartung benötigen, und jeden Sprint perfekt zu planen.

Andere haben vorgeschlagen, Ihre Entwicklungsschätzungen aufzufüllen, um Support/Wartung abzudecken. Dies ist ein guter erster Schritt.

Um das Problem wirklich zu kommunizieren und Ihre Zahlen zu rechtfertigen, sollten Sie die Entwickler die Zeit verfolgen lassen, die sie mit der Beantwortung von Kundensupportproblemen verbringen, im Gegensatz zu Codewartungsproblemen und tatsächlichen Neuentwicklungen.

Das Nachverfolgen Ihrer Zeit auf dieser Ebene ist definitiv lästig, hilft aber dabei, ein solides Bild davon zu erstellen, wo das Team seine Zeit verbringt.

Eine gröbere Schätzung (anstelle von Stunden) kann die Menge der während eines Sprints bearbeiteten Support-Tickets sein. Dies erfordert keine zusätzliche Zeiterfassung durch die Entwickler, sondern nur ein Feld auf dem Ticket, um anzugeben, dass es sich um ein Kundensupportproblem handelt, anstatt um ein normales Entwicklungsticket. Wenn Sie dann mit der Bereitstellung neuer Funktionen in Verzug geraten, können Sie sich die Anzahl der Support-Tickets während Ihrer Sprints ansehen und dem Management zeigen, dass sie zB 50 % höher als normal ist und dass Sie den Zeitplan nach rechts verschieben müssen.

Diese Art von Kennzahlen hilft dem Management auf jeden Fall zu erkennen, dass das Team überlastet ist, und kann es davon überzeugen, zusätzlichen engagierten Support einzustellen.

UPDATE - Vom Fragesteller in der Frage gepostet und in eine CW-Antwort verschoben.

Ich bin eigentlich Teil des Entwicklungsteams, aber ich bin in der Lage, Vorschläge zur Verbesserung der Situation zu machen. Jeder hat einige sehr gute Vorschläge gemacht, also vielen Dank an alle, einige Anmerkungen:

David Espina hatte einige gute Punkte, als er sagte: "Die Entwicklung von Zeitplänen kann sich verschieben, und niemand stirbt. Der Versuch, Ihre Reaktion auf den Support zu kontrollieren, und jemand stirbt ... natürlich metaphorisch." -- Dies ist ein Problem für uns, die Supportarbeit muss erledigt werden, ob es uns Entwicklern gefällt oder nicht.

Assaf Lavie erwähnte ungeplante Arbeit, die durch fehlerhaften Code in Eile entsteht – Dies ist ein Problem für uns, auch hauptsächlich aufgrund der Befugnisse, die Fristen von oben auferlegen, aber auch wegen der Unsicherheit unserer Sprints, die wir nicht erreichen können die erforderliche Entwicklungszeit, so dass wir mit zu viel zu tun an einen Termin herangehen.

Assaf hatte auch einen guten Punkt darin, ungeplante Arbeit nicht zu messen. Dies wird den Chefs schwer zu verkaufen sein, da wir bereits verpflichtet sind, unsere aufgewendete Zeit in einem Zeiterfassungssystem aufzuzeichnen, aber bisher hat uns die Aufzeichnung nicht weitergebracht.

Bens Vorschläge zur Verwendung der Swimlanes und des Expidite-Tokens könnten meiner Meinung nach für uns funktionieren, es gibt eine Menge ungeplanter Arbeit, die Konten, Feeds und andere Dienste für Kunden einrichtet. Das Verkaufsteam möchte, dass dies so schnell wie möglich erledigt wird, muss aber wahrscheinlich ab und zu eine Chill-Pille nehmen und nur Dingen eine hohe Priorität einräumen, die absolut notwendig sind. Das Verkaufsteam hat auch direkten Kontakt mit dem Entwicklungsteam, also müssen wir wahrscheinlich diese Kommunikationslinie durchtrennen und die Arbeit nur über den Product Owner zulassen.

DW & Doug B schlugen vor, in jedem Sprint einen bestimmten Prozentsatz der Zeit für Wartung und Support aufzuwenden. Aber ich denke, die Ungewissheit wird dazu führen, dass die Wartungszeit in einigen Sprints unterbewertet und in anderen überbeansprucht ist. Also ich denke in unserer Situation wird das nur zeitweise funktionieren.

Um die Entwickler zu schützen, versuchen Sie, Leute zu haben, die Anrufe von Benutzern bearbeiten können. Eher Level 1 Support. Diese Personen (könnte 1 Person sein) sollten für den Umgang mit Routineproblemen geschult sein und sollten in der Lage sein, die Benutzer zur Problemlösung an die richtige Person weiterzuleiten. Diese Person hilft bei der Reduzierung der Belastung des Entwicklungsteams. Haben Sie auch 2 Entwickler auf Rotationsbasis für Support-Jobs. Sie können die Anzahl der Entwickler im Support-Job basierend auf der Menge der gemeldeten Probleme auswählen. Dies wird es dem Rest der Bande ermöglichen, neuen Code zu produzieren, und aufgrund der Rotation können die meisten Leute jeden Monat Entwicklungsarbeit leisten.

Es gibt ein paar Ansätze, die meine Teams eingesetzt haben, jeder mit unterschiedlichen Vor- und Nachteilen. Ich werde diese Ansätze im Folgenden skizzieren. Welches oder ein Hybrid davon, hängt alles von Ihrem Unternehmen und Ihren Benutzern ab.

Die erste Faustregel lautet, mit den Daten eine Geschichte zu erzählen. Wie viel Zeit wenden Sie für den Support auf? Wenn Sie es nicht wissen, beginnen Sie mit dem Messen. Hier könnten tiefere Probleme im Spiel sein, und Sie brauchen die Daten, um die Geschichte zu erzählen.

1. Lassen Sie jedes Teammitglied in jedem Sprint einige Stunden für den Support aufwenden. Beispielsweise weist jedes Teammitglied 5 Stunden pro Sprint zu, um an Supportproblemen zu arbeiten. Der Trick dabei ist, die Prioritäten innerhalb des Teams auszurichten. Erstellen Sie SLAs/Teamarbeitsvereinbarungen für die Art und Weise, wie der Support verwaltet wird. Beispielsweise wird jedes Problem mit der Priorität H in den aktuellen Sprint gezogen. Tickets mit mittlerer Priorität werden im folgenden Sprint bearbeitet. Messen Sie die Zykluszeit von Support-Problemen nach Priorität, um das Volumen zu bestimmen und festzustellen, ob für jeden Sprint mehr/weniger Zeit erforderlich ist.

2. Scrumban – alle Arbeiten werden priorisiert und mit Work-in-Progress-Limits gezogen, z. B. nicht mehr als 2 Storys in einer bestimmten Spalte Ihres Boards. Wenn Tickets eingehen, werden sie gegenüber allen anderen Aufgaben priorisiert und in den Sprint gezogen. Funktioniert gut mit Teams, die keine bestimmten Fristen oder Supportprobleme haben, die normalerweise sofort nach Eingang behoben werden müssen.

3. Entwickeln Sie ein schnelles Reaktionsteam – funktioniert besser, wenn Sie ein größeres Volumen an Supportanfragen/Benutzerfragen haben, die beantwortet werden müssen. Funktioniert wie folgt. 2 Mitglieder, in der Regel ein Paar Entwickler/QA, übernehmen in einem bestimmten Sprint keine Aufgaben für neue Aufgaben. Während des gesamten Sprints reagieren sie auf jedes eingehende und adressierte Ticket sofort. Für die Probleme, die mehr Aufwand erfordern, wird die Arbeit als Arbeitsprodukt (Story oder Fehler) für einen bevorstehenden Sprint priorisiert.

Hoffe das hilft und gibt dir ein paar Ideen.

Sie haben erwähnt, dass Sie agile Methoden verwenden und in Sprints arbeiten, also nehme ich an, dass Sie Scrum verwenden, da es eine der beliebtesten Methoden ist. In Scrum ist die Arbeit etwas eingeschränkt, Teammitgliedern werden Aufgaben zugewiesen und diese Aufgaben haben Fristen, die vor dem Ende jedes Sprints erledigt werden müssen. Unerwartete Aufgaben können die Teamleistung daran hindern, Aufgaben rechtzeitig zu erledigen, wodurch mehr Druck auf die Entwickler ausgeübt wird.

Die Verwendung von Scrumban kann den Druck etwas verringern, da es sowohl Scrum- als auch Kanban-Funktionen kombiniert. Kanban hat weniger Einschränkungen als Scrum und kann einen stetigen Strom eingehender Aufgaben wie Support- oder Wartungsaufgaben besser bewältigen, es ist eine eher ereignisgesteuerte agile Methodik.