Wie man Prozesse aufbaut und aufhört, sich über ein Team lustig zu machen

Hallo allerseits! Heute wollte ich über Entwicklungsprozesse sprechen. Während das Unternehmen wächst, entwickelt sich nicht nur das Geschäft selbst, sondern es häufen sich auch Probleme im Inneren, insbesondere während des Entwicklungsprozesses. Oft versuchen sie, sie zu lösen, indem sie einige Praktiken und neue Methoden einführen. Leider führt diese erzwungene Neuorganisation des Prozesses nach Büchern und Schulungen oft zu noch größeren Problemen - Spott über Menschen.

Ich habe kürzlich auf der Saint TeamLead Conf 2019- Konferenz in einem Bericht darüber gesprochen, wie ich eine Reihe von Problemen im Workflow finden und sie dann schrittweise überwinden konnte. Hier werde ich versuchen, die wertvollsten Praktiken zu beschreiben, die mir geholfen haben, nicht nur einen Workflow einzurichten, sondern auch die Entwickler nicht mehr zu verspotten. Die Mitarbeiter haben ihre Einstellung zum gesamten Unternehmen und zum Arbeitsprozess geändert.

Herausforderungen des Entwicklungsprozesses

Als die vorgefertigten Ansätze kein Ergebnis lieferten und wir fast verzweifelt waren, begann ich, die Prozesse zu analysieren und alles anhand der Knochen zu analysieren. Das Ergebnis ist eine Liste von Problemen:

• Das Board ist mit Aufgaben überladen - es herrschte echtes Chaos. Mit Blick auf die Tafel war es fast unmöglich, die Prozesse zu verstehen.
• Es gab keine normalen Bewertungen - wir wussten nicht, wie man Aufgaben entsprechend der Vorlaufzeit richtig bewertet. Aus diesem Grund waren die Fristen ständig auf dem Weg, und die Führungskräfte stießen auf Entwicklung.
• Wir haben ständig die Fristen festgelegt - wir konnten nicht genau sagen, wann das Feature in Produktion gehen würde. Meistens haben wir es aufgrund externer Faktoren viel später als geplant eingeführt. Beispielsweise hat das Unternehmen darauf zurückgegriffen und darum gebeten, schnell ein dringendes Feature zu erstellen.
• Es gab kein Verständnis dafür, wie die Entwicklung beschleunigt werden kann - die Einstellung neuer Mitarbeiter und die 100% ige Verladung von Ingenieuren beschleunigen den Prozess nicht immer.
• Planung und dringende Aufgaben - Wenn es mit aktuellen Aufgaben irgendwie möglich war, Pläne zu erstellen und ungefähre Daten anzugeben, brachen dringende Aufgaben, die normalerweise aus dem Geschäft flogen, alle Pläne.
• Meetings sind zeitaufwändig - unser häufigster Fehler: Etwas funktioniert nicht oder wir müssen Aufgaben priorisieren - und lassen Sie uns zusammenkommen und diskutieren. Oder regelmäßige Besprechungen, bei denen die Entwickler ein oder zwei Stunden saßen und nicht verstanden, was sie dort taten.
• Das Problem der Motivation und Einbeziehung von Teams - oft wurden einige Innovationen einfach von den Behörden von oben herabgebracht, ohne die Meinung des Entwicklungsteams einzuholen, dies hat die Atmosphäre im Team nicht gemalt.

Tatsächlich besteht die Aufgabe eines jeden Leiters, sei es ein TL oder ein CTO, darin, dass er das Bindeglied zwischen Geschäft und Entwicklung wird.

Um aus dieser Situation herauszukommen, haben wir uns der Kanban-Methode zugewandt. Was sagt er uns? Lassen Sie uns verbessern, was bereits da ist. Nun, wir haben unseren Entwicklungsprozess verbessert.

Ordnung an die Tafel bringen

Wir fingen an zu streiten: Wenn die Backender ihre Aufgabe erledigt und an das Frontend übergeben haben, werden sie sie dann sofort starten? Auf der Tafel ist das unverständlich. Nach den Prinzipien von Kanban haben wir jede Entwicklungsrichtung (wir hatten 5 davon: Backend, Frontend, DevOps, QA und Design) in zwei Spalten unterteilt: Do und Done. Das Problem wurde sofort offensichtlich: Unsere Bandbreite ermöglicht es uns nicht, so viele Aufgaben zu erledigen, wie sie von uns wollen.



Kanban sagt auch: Lassen Sie uns ein WIP-Limit einführen und die Anzahl der Aufgaben begrenzen. Wie setzen wir Grenzen? Empirisch. Natürlich haben sie ein paar Mal verpasst, aber dann haben sie es aufgegriffen, damit wir nicht auf engstem Raum Aufgaben ansammeln mussten. Ein zusätzlicher Gewinn von WIP-Limit ist ein Auslöser, der besagt, dass wir, sobald wir die Aufgabe weggenommen haben, Folgendes übernehmen können. Dies ist eine Art Zugsystem.



Was hat das gebracht? Ingenieure begannen, sich mehr um Aufgaben zu kümmern, denn wenn sie ein Problem nicht lösen können, wird ein Blocker darauf gesetzt. Es können keine Aufgaben mehr übernommen werden, da es ein WIP-Limit gibt. Die Ingenieure müssen darauf warten, dass sie bei der Lösung helfen. Es besteht die Möglichkeit, ohne Aufgaben zu bleiben.

Als wir anfingen, das Problem der Rückgabe von Aufgaben im Detail zu analysieren, stellte sich heraus, dass jeder sie anders macht, zum Beispiel schreibt jemand Tests und jemand nicht. Diesbezüglich gab es Regeln, die jedoch von den Behörden enttäuscht wurden. Sie haben das Entwicklerproblem nicht gelöst. Wir haben neue Regeln ( Definition of Done ) eingeführt, die in das Board integriert sind. Sie könnten sowohl auf eine Spalte als auch auf den Kartentyp einwirken. Für eine API benötigen Sie beispielsweise das Backend, um alle Methoden und Inhalte zu dokumentieren. Die Regeln waren für alle zugänglich und an der Tafel sichtbar, und vor allem kamen sie von den Ingenieuren selbst und lösten ihre Probleme. Wenn etwas nicht getan wurde, sah der Ingenieur es und ging, um es zu tun.

Aufgaben benoten

Wir wussten nicht, wie wir Aufgaben fristgerecht bewerten sollten, und Kanban sagt uns: „Keine Schätzungen“. Was zu tun ist? Wir haben Statistiken gesammelt und einen solchen Zeitplan erstellt. Dies ist ein Spektraldiagramm, die Abhängigkeit der Anzahl der Aufgaben von der Zeit.



Wir begannen es zu studieren und sahen in der Grafik 3 Peaks, die drei Arten von Arbeiten entsprechen. Basierend auf diesen Typen wurden eine Klassifizierung und Kriterien für solche Arbeiten entwickelt. Wir haben diese Typen in der Taskleiste eingeführt und dann für jeden im Prozess zusätzliche Regeln hinzugefügt. Wir haben folgendes:



Wir haben mit dem Kunden, dh mit dem Unternehmen, eine Servicequalitätsvereinbarung (SLA) vereinbart. Ein Manager kommt zu uns und fragt: "Und wie viel werden Sie mit dieser Funktion verdienen?" Wir können nicht sagen, wie viel wir mit Sicherheit tun werden, aber wir können sagen, wie viel Zeit für eine ganze Reihe solcher Aufgaben aufgewendet wird. Scrum Poker war nicht nötig und wir haben aufgehört, Leute mit Timing-Fragen zu foltern. Wir haben uns nur die Statistiken angesehen und die Geschäftsdaten genannt.



Natürlich hatte dieser Ansatz auch Nachteile. Dies funktionierte beispielsweise nicht mit Aufgaben eines neuen Typs, für die wir einfach keine Statistiken hatten. Sie gaben vor, auf alte Weise zu sein, aber dann sammelten sie eine ausreichende Menge an Daten und dieses Problem wurde zunichte gemacht.



Dann wurden wir mit der Tatsache konfrontiert, dass einige Aufgaben in andere Arten von Arbeit fielen. Wir haben ein wenig recherchiert und festgestellt, dass einige Aufgaben viel schneller erledigt wurden, weil das Unternehmen den Partnern dort etwas versprochen und die Entwickler gebeten hat, diese dringend zu erledigen. Und einige Aufgaben im Gegenteil waren nicht so wichtig, sie wurden verschoben. Wir haben also Prioritäten gesetzt, dh Vereinbarungen über Serviceklassen von Diensten (CoS), die wir in den Vorstand aufgenommen haben. Damit das Unternehmen es nicht missbraucht und nicht für alle Aufgaben eine erhöhte Dringlichkeit festlegt, wurden horizontale WIP-Grenzwerte eingeführt.

So beschleunigen Sie die Entwicklung

Wieder wandte ich mich der Task-Tracker-Statistik zu. Wir haben festgestellt, dass viele Aufgaben im Vorgriff auf Verbesserungen, Überprüfungen oder zusätzliche Daten auf dem Board hängen, dh sie haben erkannt, dass die Entwicklung beschleunigt werden kann. Sie begannen zu untersuchen, wie viele Aufgaben sich ansammeln, wie viel sie im Leerlauf sind, und stellten fest, dass einige Funktionen weniger entwickelt wurden, als sie erwartet hatten. Wir haben beschlossen, einen Tag für die Annahme von Funktionen festzulegen, und die Zeit für die Ausgabe von Aufgaben wurde reduziert. Und dann befestigten wir die CD (Continuous Delivery) und begannen, Benachrichtigungen zu senden.

Es wurde klar, dass wir ein Tool zur Bewertung unserer Verbesserungen benötigen. Wir haben uns für das kumulative Flussdiagramm entschieden. Kurz gesagt, wie es aufgebaut ist: Wir weisen jedem Arbeitsplatz (Spalten auf der Tafel) eine Farbe zu, erstellen Statistiken darüber, wie viele Elemente (Aufgaben) sich in einer Zeiteinheit in einer Spalte befinden, zeichnen sie in der Grafik auf und platzieren sie untereinander. In der Grafik ist die X-Achse die Zeit, die Y-Achse die Anzahl der Aufgaben.



Was haben wir von hier bekommen? Hier ist die Vorlaufzeit (Produktionszeit) leicht zu erkennen - die horizontale Linie (die Breite des Durchflusses entlang der X-Achse) beginnt mit der Angabe des Problems und erreicht das Stadium der Bereitschaft. So können Sie hier sehen, wie die Aufgabe alle Entwicklungsstufen durchläuft - die Linie schneidet alle Farben, von denen jede ihrer Stufe entspricht. Und auch die gesamte WIP-Grenze der Platine - die Fließhöhe entlang der Y-Achse. Wie kann die Entwicklungsgeschwindigkeit erhöht werden? Sie können die WIP-Grenze verringern (dh den Fluss im Diagramm enger gestalten), oder Sie können unseren Fluss, der vom Ursprung zur oberen rechten Ecke des Diagramms geleitet wird, dazu neigen, noch mehr zu steigen (dh die Flussrichtung noch weiter nach oben zu erhöhen). reduzieren Sie seinen Winkel relativ zur Y-Achse). Um den Fluss stärker nach oben zu lenken, können Sie einige neue Methoden einführen, z. B. Docker implementieren oder eine praktische Wissensbasis erstellen. Dies muss keine technische Innovation sein, ein neuer Managementansatz kann ebenfalls einen solchen Effekt erzielen.


So haben wir ein Tool erhalten, das klar zeigt, welche Verbesserungen funktionieren und welche nicht.

Geschäftsplanung, dringende und nutzlose Aufgaben

Die Planung der Geschäftsentwicklung war der größte Schmerz. Was haben wir gemacht Nachdem die Aufgabe vom Unternehmen erhalten worden war, fand ein Treffen zwischen dem Analysten und dem Entwickler statt, bei dem sie zerlegt wurden, und der Entwickler schlug Lösungen vor. Als Ergebnis haben wir verstanden, wie viel und welche Ressourcen die Aufgabe benötigt. Und erst dann machte das Unternehmen ohne unsere Teilnahme seine Pläne und überlegte, wie viel wir Funktionen veröffentlichen können. In Kanban wird dies als Nachschubkadenz bezeichnet .

Relativ gesehen weisen wir Slots einer bestimmten Größe gemäß den WIP-Grenzwerten zu, in denen Sie Aufgaben platzieren können. Jeder Steckplatz enthält nur eine begrenzte Anzahl von Aufgaben. In anderer Weise wird diese Methode als "Tassenplanung" bezeichnet.



Wir haben ein einfaches Tool für Unternehmen erstellt (eine Tabelle in Excel), mit dem es visuell geplant werden kann. Die Manager kämpften untereinander, diskutierten, wessen Aufgabe wichtiger ist, und kamen dann zu uns und gaben die Aufgaben der Entwicklung.

Da wir bereits Einschränkungen hatten, achtete das Unternehmen mehr auf die Auswahl der Aufgaben, wählte die wichtigsten aus und überwältigte uns nicht mit Unsinn, der ihnen einfiel. Und noch ein großes Plus: Sie haben die Aufgaben ohne unsere Teilnahme selbst ausgewählt, ohne die Entwickler zu Besprechungen abzulenken, sie haben leise gearbeitet und keine Zeit für Besprechungen aufgewendet.

Wir haben uns auch dem Problem dringender Aufgaben zugewandt. Sie begannen, Statistiken über sie zu analysieren und stellten fest, dass diese Aufgaben nicht so dringend sind. Zum Beispiel brauchen wir eine Förderung für den saisonalen Radwechsel von Autofahrern. Wir wissen, dass dies immer zweimal im Jahr passiert. Sobald sie wiederholt werden, reservieren wir im Voraus Slots für solche Aufgaben auf dem Board. Es wird nichts Dringendes geben - wir werden eine weitere Aufgabe aus der Warteschlange nehmen, wir werden nicht ohne Arbeit bleiben. Als Ergebnis haben wir festgestellt, dass 60% der dringenden Aufgaben tatsächlich nicht dringend sind.

Es gab ein anderes Problem. Wir haben oft Features gesägt, die das Geschäft schließlich abgelehnt haben, weil sie sich aus geschäftlicher Sicht als nutzlos erwiesen haben. Wir haben vorgeschlagen, dass Unternehmen MVP-Funktionen ausführen, die um ein Vielfaches weniger Zeit benötigen als die herkömmliche Entwicklung. Das Feedback wurde viel schneller entfernt und die Ingenieure erkannten, dass es sich um Experimente handelte. Zuvor, als wochenlange Arbeit in den Müll geworfen wurde, machten sie sich Sorgen, dass dies ihr Leben vergiftete.

Wir haben begonnen, 85% der Funktionen so zu testen, dass wir am Ende viel Zeit frei haben, die wir dann für in der Praxis getestete Hypothesen aufgewendet haben. Sie haben der Firma bereits Geld gebracht. Wenn dabei ein Fehler aufgetreten ist, kann der Kunde des Features aus dem Unternehmen frühzeitig und nicht während des gesamten Entwicklungszyklus Korrekturen vornehmen.

Infolgedessen wurde eine solche Tatsache entdeckt, dass nicht alle Ideen funktionieren. Und da sie nicht funktionieren, dann tun Sie sie nicht. Seitdem haben die Entwickler aufgehört, sich mit Affenarbeit zu beschäftigen, und genau das getan, was das Unternehmen Geld bringt.

Treffen

Die Verbesserungen, die wir zu diesem Zeitpunkt eingeführt hatten, hatten bereits eine Reihe nutzloser Besprechungen zunichte gemacht. Priorisierungsdiskussionen gab es nicht mehr, da wir dies dem Unternehmen gaben, planten wir auch ohne Ingenieure. Wir haben auch die fünfminütigen Razzien von Managern mit der Bitte "schnelle Hilfe" abgebrochen. Es gab nur wirklich notwendige Treffen. Wir haben auch die Regel eingeführt, dass Besprechungen jetzt für eine bestimmte Zeit geplant sind, damit jeder seinen Zeitplan planen kann.

Infolgedessen wurden alle Sitzungen zur Boltologie in die folgenden Arten von Sitzungen umgewandelt:

• wenn ein Analyst ein bestimmtes Problem mit einem Ingenieur besprechen möchte, um beispielsweise die optimale Lösung oder Zerlegung zu finden;
• wenn etwas auf dem Brett steckt. In diesen Fällen versammelten wir uns und gingen von rechts nach links über das Brett. Wir fragten die Ingenieure, was passiert ist und wer helfen könnte. Es ist wichtig, dass wir uns von den Aufgaben verabschiedeten und nicht versuchten zu berechnen, was die Leute taten.
  
• wenn sie Aufgaben für den Sprint planten (Trittfrequenz für Nachschub);
• als sie Merkmale nahmen;
• Besprechungen zwischen Entwicklungsteams, beispielsweise bei der Erörterung des API-Formats oder bei der Entscheidung, welche Ereignisse gesendet werden sollen.

Kernpunkt: Wir haben zu den Sitzungen nur diejenigen Personen eingeladen, die direkt am Diskussionsthema beteiligt waren, und nicht wie zuvor nominierte Zuhörer angerufen. Ingenieure haben ihre Einstellung zu Besprechungen grundlegend geändert, bevor sie sie nicht mochten, aber jetzt ist es umgekehrt, sie scheinen für sie notwendig und nützlich zu sein.

Teammotivation und Engagement

Alles, was wir implementiert haben: WIP-Limits, Auswertung von Aufgaben auf der Grundlage von Statistiken, Ablehnung nutzloser Aufgaben usw., die oben beschrieben wurden, führten zu einer Zeitersparnis für Ingenieure. Was werden sie jetzt tun? Das größte Missverständnis ist, dass niemand etwas tun wird. Ich selbst habe wiederholt von den Jungs gehört: "Ich hätte diesen Code überarbeitet, sonst würde das Bein des Teufels brechen." Ja, zuerst bekommt der Ingenieur wirklich genug Schlaf und ruht sich 2-3 Wochen aus, und was dann? Er sitzt ohne Aufgaben, beginnt mit einem Hilfevorschlag auf seine Kollegen zuzugehen, hilft bei der Erledigung von Aufgaben, dann sitzen beide bereits ohne Aufgaben. "Lassen Sie uns Fehler beheben" - die Spalte mit den Fehlern war leer. "Senden Sie den Code, den wir umgestalten werden" - der Code ist schneller zu schreiben, das WIP-Limit kann erhöht werden. Dann beginnen sie mit der Implementierung von CD / CI und schreiben eine Wissensdatenbank. Was ist passiert? Ingenieure beginnen viele nützliche Dinge zu tun, zu denen ihre Hände nicht reichten. Dies ist die Geschwindigkeit, die das Unternehmen will, aber aus irgendeinem Grund kann es sie von niemandem bekommen. Früher war der Ingenieur wütend, er wollte, dass alle hinter ihm stehen, und jetzt hat sich das menschliche Paradigma geändert zu: „Wie kann ich Ihnen jetzt helfen?“ Die Zahl der Initiativen ist gestiegen, und alle kamen von unten, nicht von oben. Und am Ende stellte sich heraus, dass es viel nützlicher war.

Zusammenfassung der Ergebnisse

• Wir konnten einen Engpass im System finden und verstehen, dass wir nicht mehr tun können als wir können.
• Sie haben aufgehört, Entwicklern nutzlose Arbeit zu werfen, und Zeit für nützlichere Aufgaben frei gemacht.
• Wenn die Ingenieure nichts zu tun hatten, begannen sie, Aufgaben besser zu bewerten, Fehler zu beheben, Prozesse zu automatisieren, und es erschien eine Wissensbasis.
  
• Die Ingenieure hörten auf, gestresst zu sein und wurden freundlicher.
• Wir konnten die Veröffentlichung neuer Funktionen durch Verbesserungen und Arbeitsoptimierung (erhöhte WIP-Grenzwerte aufgrund von Automatisierung und Verbesserungen) viermal beschleunigen.
• Wir haben Statistiken für Unternehmen und ein klares Verständnis dafür, was und wie mit der Entwicklung vor sich geht.
• Wir haben gelernt, Zeit zu sparen (Ablehnung unnötiger Aufgaben, begann, Aufgaben im Voraus zu überdenken, um zusätzliche Faktoren zu vermeiden usw.).
• Meetings und Meetings wurden abgehalten, wenn sie wirklich gebraucht werden (flexibler werden).
• Alle begannen mehr nachzudenken, die Zahl der Initiativen nahm zu. Die Initiativen, die in Teams geboren werden, sind immer besser als die, die von oben kommen. Der Prozess ging ständig weiter und alle beteiligten sich daran.

Schlussfolgerungen

In diesem Artikel und Bericht wollte ich nicht nur auf die von mir angewandten Tools und Ansätze aufmerksam machen, sondern auch auf den wichtigsten Aspekt, der oft unbemerkt bleibt, aber meiner Meinung nach nicht weniger wichtig ist. Wir haben diese ganze Perestroika begonnen, weil wir Schmerzen hatten und sie loswerden wollten.

Sie können etwas „auf der Stirn“ implementieren, indem Sie intelligente Bücher lesen oder einen Bericht über flexible Methoden anhören, sodass die Entwicklung sogar beschleunigt werden kann oder Produkte besser funktionieren. Aber wir vergessen oft, dass Menschen diese Produkte herstellen, und je besser wir ihr Leben gestalten, desto besser werden sie Produkte herstellen. Zum Beispiel gehe ich zu den Jungs und frage: „Und was sind deine Schmerzen? Was ist los? “, Bevor Sie mit der Implementierung beginnen. Und nur dank dieses Ansatzes konnte ich das tun, was das Unternehmen will - Geschwindigkeit und Qualität in der Entwicklung.

PS Mir wurde von einer Firma in Europa erzählt, wenn Sie dort ins Büro kommen, scheint es, dass eine vollständige Anarchie herrscht: Die Entwickler, wie Käse in Butter, spielen Konsolen, niemand arbeitet. Dies ist jedoch nur auf den ersten Blick der Fall, es gibt eine Atmosphäre, die speziell für Menschen geschaffen wurde, damit sie etwas schaffen und verbessern können. In der Zeit zwischen den Unterhaltungsaufgaben schrieb ein Knie eine Lösung, die anschließend implementiert wurde, und begann, dem Unternehmen Gewinn zu bringen. Ich hoffe, dass sich unser russisches Management in naher Zukunft in diese Richtung bewegen wird. Und wenn Sie aus irgendeinem Grund etwas falsch machen, denken Sie darüber nach, was Sie tun. Nun, oder werfen Sie diesen Artikel zum Chef, aber was ist, wenn es hilft :)