Unser Team entwickelt Kredit- und Garantieprodukte für juristische Personen. Die Richtung ist jung, die ersten Ausgaben begannen im Jahr 2018. Wir haben eingecheckt und den Markt untersucht, einen Überziehungskredit, einen Kredit zur Umsatzsteigerung und Bankgarantien aufgenommen. Es war geplant, ein Darlehen gegen einen Vertrag, besicherte Darlehen und andere Produkte aufzunehmen.
Symptome
Unser Prozess vom schnellen Start der Lebensmittelmechanik hat Krücken angehäuft. Wir haben uns damit abgefunden und, wie Sie sich vorstellen können, einmal bemerkt, dass Aufgaben für Prozesse zu lange entwickelt wurden. Dies spiegelte sich in der ständigen Übertragung von Releases wider, Aufgaben wurden nicht rechtzeitig erledigt. Es häuften sich Fehler, die ein kleines, spezifisches Kundensegment betrafen.
Es gab Situationen, in denen die Freigabe für die nächste Aufgabe, die bereits seit zwei Monaten verschoben wurde, erneut auf unbestimmte Zeit verschoben wurde. Gleichzeitig hat die Freigabe der Überziehungsfunktion die Bankgarantien gebrochen. Das Produktverständnis wurde desynchronisiert. Die Entwickler hielten Dinge für wichtig, auf die das Geschäftsteam nicht einmal achtete. Die Hauptmerkmale der Produkte blieben dagegen unbekannt.
Um aus der Krisensituation herauszukommen, wurde eine Arbeitsgruppe eingerichtet, die sich der Aufgabe stellte, aus „schlecht und lang“ „schnell und gut“ zu machen. Für uns selbst setzen wir uns Ziele, um die Leistung zu verbessern und die Anzahl der Fehler zu reduzieren.
Probleme
Nachdem wir uns eingehender mit den Prozessen des Teams befasst hatten, stellten wir eine Reihe von Problemen fest, die nicht separat gelöst werden konnten. Sie erforderten einen integrierten Ansatz:
- alter Technologie-Stack;
- langer und krummer Kanban-Prozess;
- das Geschäft geriet in die inneren Angelegenheiten der Entwicklung;
- Das Entwicklungsteam verlor das Interesse an dem Projekt.
- allgemeine Toxizität.
Ich werde Ihnen genauer sagen, wie dies ausgedrückt wurde.
Alter Technologie-Stack. Unser Prozess wurde in IBM ODM geschrieben, einem System mit einer Reihe von Funktionen, die dem Team im Weg standen. Sie wurden von unserem Architekten Denis ausführlich beschrieben Kotskinim Falle eines benachbarten Projekts (obwohl es IBM BPM gab, aber im Allgemeinen ist alles fair). Unabhängig davon stelle ich fest, dass es auf dem Markt keine Spezialisten mit Erfahrung in diesem System gibt.
Langer Lieferprozess. Offiziell haben wir uns als Kanban-Team positioniert, aber die Prozesse sahen aus wie eine Kreuzung zwischen Wasserfall und Scrum. Das Erbe der Wasserfallentwicklung ist, dass Geschäft, Entwicklung und Test nur auf der Jira-Karte kommunizieren. Alle hatten einen klaren Gedanken: "Ich habe meinen Teil der Arbeit erledigt, meine Hütte ist am Rande."
Wir sind nicht sofort nach Kanban gekommen. Gleich zu Beginn haben wir Scrum mit Sprints verwendet, was sich bei jungen Projekten besser zeigt. Dann erkannten sie, dass es für das Team moralisch schwierig war, Aufgaben von Sprint zu Sprint zu übertragen, und wechselten zu Kanban. Dann wurde klar, dass niemand weiß, wie man mit dem Eingabestream arbeitet, der Entwicklungszyklus begann zu erscheinen. Es zeigte sich in der Tatsache, dass Aufgaben aus dem Geschäft einmal pro Woche eingingen, dann vom Team bewertet wurden, klar wurde, dass nichts klar war, und die Aufgabe für die nächste Woche abgesetzt wurde. Gleichzeitig haben wir in Worten Kanban gemacht und nach Engpässen gesucht.
Ich verstehe, dass sich die Ideen von Kanban und Scrum nicht widersprechen, und es gibt Beispiele, bei denen eine Kombination von Methoden gute Ergebnisse zeigt. Aber ich möchte betonen, dass es eine radikale Position des reinen Kanban gab. Die große Anzahl von Erträgen vom Test zur Entwicklung verlangsamte sich ebenfalls erheblich, was auf die geringe Qualität der Aufgabe in den frühen Stadien hinwies.
Verletzung des Vorbilds. Geschäftsanalysten beschäftigten sich mit Architektur - sie fanden eine technische Lösung für das Problem. Dies führte dazu, dass sie häufig tiefgreifende Entdeckungen zugunsten der Ausarbeitung und Spezifikation der Lösung aufgaben und dieser Hack in Verbindung mit einer schwachen Architektur die Entwicklung mehrmals verlangsamte.
Verlust des Interesses des Teams an dem Projekt.Ein talentiertes, ehrgeiziges, junges Team. Reiner Start. Nach dem Start und der Skalierung begannen wachsende Schmerzen. Ständiger Druck des Geschäfts, die Komplexität der Entwicklung aufgrund des Mangels an Refactoring, akkumulierte interne Probleme und der Rückstand für die kommenden Monate führten zu banaler Müdigkeit und Burnout.
Aus all diesen Gründen hat sich die Atmosphäre im Team verschlechtert. Probleme wurden auf Retro behoben, aber nicht gelöst und wanderten von Woche zu Woche. Die allgemeine Toxizität ging von der Skala ab, und jeder Dialog über die Arbeit führte zu gegenseitigen Vorwürfen.
Was haben wir getan
Ehrlich gesagt haben wir am Anfang nur verstanden, dass wir den Prozess von Grund auf neu schreiben mussten, um Krücken loszuwerden und das Team mit erfahrenen Entwicklern zu verstärken. Sechs Monate später kann ich zwei weitere Dinge nennen, die uns geholfen haben:
- Wiederaufbau des Kanban-Prozesses. Dank des Tinkoff Biznesa-Lieferzentrums, das sich schnell mit unseren Problemen befasste und zur Anpassung von Jira beitrug.
- Geschäfts- und IT-Synchronisation. Hier waren wir von der Überzeugung getrieben, dass das Team ein gutes Verständnis für das Produkt haben und nicht nur die Aufgaben ausführen sollte, die es bringen werden.
Am Ende löste das Umschreiben des Prozesses das Problem des Technologie-Stacks und half, Krücken loszuwerden. Das Überdenken des Kanban-Prozesses trug dazu bei, das Vorbild neu aufzubauen und die Anzahl der Retouren zu reduzieren, dh die Geschwindigkeit der Zustellung von Aufgaben an das Produkt zu erhöhen. Eine Reihe von Synchronisationsaktivitäten und ein Überdenken der aktuellen Formate haben die allgemeine Atmosphäre begradigt.
Teil 1. Umschreiben des Prozesses
Also haben wir begonnen, den Prozess von IBM ODM nach Camunda umzuschreiben. Die Gründe für die Wahl von Camunda sind in Nikolays Artikel beschrieben nshipyakov...
In Antragsprozessen verwenden wir einen Begriff als Phase - einen logisch abgeschlossenen Teil des Prozesses mit einer klaren Bedeutung für den Kunden, z. B. „Dokumente sammeln“ oder „Unterzeichnen eines Darlehensvertrags“. Die erste Aufgabe für uns war die Aufnahme eines Vertragsdarlehens. Wir haben festgestellt, dass die Logik der drei Phasen spezifisch ist, und der Rest unterscheidet sich nicht von ähnlichen Phasen eines zirkulierenden Kredits. Tatsächlich haben wir drei Phasen eines neuen Produkts auf Camunda geschrieben. In der Zukunft wurde die gesamte Phase neu geschrieben, als eine Geschäftsaufgabe für ihre ernsthafte Änderung erschien.
Es stellt sich natürlich die Frage: Wie haben wir mit dem Unternehmen verhandelt? Es ist klar, dass das Umschreiben einer bereits funktionierenden Funktionalität länger dauert als das Ändern der alten Engine. Alles verlief ganz einfach: Die Kollegen waren bereit, in einen neuen Prozess zu investieren, weil sie sahen, wie cool es bei einem benachbarten Projekt funktionierte (und hallo nochmal, DenisKotskin). Gleichzeitig war die Entwicklungszeit für den neuen Motor nicht viel länger, seit wir mit der Rotation begonnen haben: Die ausgebrannten Leute wechselten zu anderen Projekten und stellten Mitarbeiter mit Erfahrung in der Entwicklung und Gestaltung von Geschäftsprozessen ein, um sie zu ersetzen.
Teil 2. Ändern der Reihenfolge der Aufgaben
Bei der Änderung des Entwicklungsprozesses haben wir uns auf folgende Richtlinien verlassen:
- Es sollten keine Schritte vorhanden sein, die nicht auf der Platine angezeigt werden.
- Dem Team sollte technisches Fachwissen vermittelt werden.
- Das Team muss verstehen, wie sich die Aufgabe auf das Geschäft auswirkt.
Durch die Änderung des Kanban-Prozesses haben wir neue Phasen identifiziert, die zuvor implizit die Entwicklungsphase durchlaufen haben: Dies ist Architektur und das Treffen von drei Amigos. Natürlich wird Architektur nicht nach geringfügigen Änderungen ausgeführt, aber wir versuchen, für jede Aufgabe ein Treffen von drei Amigos abzuhalten. Nastya hat einen Artikel über die "Three Amigo" -MethodeTravieso... Ich möchte Nastya ganz besonders danken: Ihre Ausbildung in agilen Tests hat uns dazu inspiriert, viele Änderungen im Team vorzunehmen.
Das Team erhält Daten zum Wert des Produkts im Format einer User Story und eine Bewertung der Auswirkungen der Aufgabe auf das Produkt. Es kann schwierig sein, den Bluff versierter Geschäftskunden zu erkennen. Zum Beispiel ist die Bewertung "Diese Regel ist wichtig, wird bei allen Anträgen überprüft" viel weniger aussagekräftig als "Wir haben eine Analyse durchgeführt, die Regel lehnt 10 zusätzliche Anträge pro Woche ab". Bevor ich eine Aufgabe zur Entwicklung einreiche, überprüfe ich daher die Qualität des schriftlichen Wertes als Vertreter des Geschäftsteams, das die Werte der Entwickler teilt.
Wir haben auch Praktiken aufgegeben, die für uns nicht funktionierten. Zum Beispiel machen wir jetzt selten Retro, nur wenn es nötig ist - wenn sich die Notwendigkeit, etwas zu besprechen, ansammelt. Dies geschieht ungefähr einmal im Monat. Es ist unbedingt erforderlich, dass wir die im Nachhinein angegebenen Probleme lösen, da es wichtig ist, dass jedes Teammitglied positive Änderungen in Bezug auf die Probleme sieht, die ihn belasten.
Wir haben die Verwendung von Storypoints und die Teambewertung der Aufgabe eingestellt. Wir arbeiten mit Fälligkeitsterminen, die wir vom Unternehmen erhalten, und verwalten abhängig davon den Eingabefluss. Bei großen Aufgaben, die einige Monate lang ausgeführt werden, führen wir eine Zerlegung durch: Sie ermöglicht es, eine Art Kontrollpunkte zu erstellen und die Genauigkeit der Fälligkeit zu erhöhen. Um den Fortschritt zu überwachen, treffen wir uns regelmäßig und diskutieren, ob wir pünktlich sind. Wenn wir feststellen, dass dies nicht der Fall ist, passen wir den Eingabestream an und übernehmen weniger kleine Aufgaben. In Bezug auf die Genauigkeit der Einhaltung der Frist kann ich nur sagen, dass wir für unsere derzeitige Hauptaufgabe die Anforderungen erfüllen.
In Bezug auf die Neuverteilung der Rollen haben wir das Team mit einem Architekten und einem zweiten Systemanalysten verstärkt. Das Geschäftsteam versucht klar zu erklären, was für die Aufgabe benötigt wird, welchen Wert sie hat, aber nicht zu beraten oder in das Innenleben der Entwicklung einzusteigen. Ich kümmere mich auch um das Business-Team.
Teil 3. Synchronisation von IT- und Business-Teams
Wir verwenden verschiedene Formate, um Unternehmen und Entwickler zu synchronisieren.
Demo nach Aufgabe. Dies ist ein Treffen aller Interessierten - Portfolioanalysten, Risikoabteilung, Vermarkter und IT-Spezialisten - mit einer Diskussion über den Wert, das problematische Problem und die technische Lösung.
Ein wichtiges Meeting, bei dem Sie Fehler finden, die in der Ermittlungsphase übersehen wurden, und Zeit haben, sie zu beheben. Außerdem weiß der Manager, der die Aufgabe leitet, nicht sicher, welche Unternehmensprozesse von der Freigabe betroffen sind. Mit dieser Werbung können wir Situationen verhindern, in denen Änderungen im Prozess unterbrochen werden, z. B. analytische Berichte.
Retro auf Aufgabe.In diesem Meeting diskutieren wir die Probleme von Entwicklern und Kunden, auf die sie während der Entwicklung des Problems gestoßen sind. Wir führen es nach der Analyse nach der Veröffentlichung durch - wenn die Leidenschaften nachgelassen haben und alle zu einem konstruktiven Dialog bereit sind. Nachdem wir die Gründe herausgefunden haben, bilden wir Wachstumspunkte und eine Ideenwolke, die wir in Zukunft ausprobieren werden.
Wir halten Vorträge zu Produkten im Format eines Bildungsprogramms und anschließende Diskussion. Ihr Ziel ist es, die IT-Mitarbeiter in den Geschäftskontext einzutauchen. Für das gesammelte Feedback in Form einer Umfrage mit dem allgemeinsten Wortlaut "Bewertung der heutigen Vorlesung" beträgt die durchschnittliche Bewertung 8,5 von 10 Punkten.
Ergebnis
Sechs Monate später haben wir mehr als 80% der Prozesse umgeschrieben und einen Kredit gegen einen Vertrag mit einem völlig neuen Motor aufgenommen. Die Teamatmosphäre hat sich verbessert und wir sind effizienter geworden. Um dies zu überprüfen, haben wir eine Umfrage unter dem Team durchgeführt und Statistiken von Jira erstellt.
In der Umfrage wurde nach der Atmosphäre im Team, der Qualität der Spezifikationen, der Entwicklung und Architektur sowie der Qualität der Kommunikation mit dem Unternehmen gefragt. Laut den Ergebnissen der Umfrage stieg die durchschnittliche Punktzahl der Jungs, die seit mehr als einem halben Jahr im Projekt sind, von 6 auf 8 von 10 Punkten. Leider ist die Umfrage nicht ganz ehrlich, da sie nach den Änderungen durchgeführt wurde. Die angegebenen Zahlen beziehen sich auf den Jahresanfang und den Anfang Juli. Man kann also mit Recht sagen, dass sich die Situation im Team verbessert hat, aber es kann nicht gesagt werden, wie viel.
Die Leistung (Anzahl der Aufgaben pro Tag) hat sich in dieser Zeit verdoppelt. Natürlich nicht auf Kosten der Zersetzung: Wir haben uns im Voraus auf bestimmte Standards geeinigt, die wir einhalten.
Die Anzahl der Rückgaben vom Test zur Entwicklung ist leicht zurückgegangen. Das heißt, mit einer mehrfachen Zunahme der Anzahl der für die Produktion angezeigten Aufgaben hat sich die Anzahl der Retouren nicht erhöht. Dies weist auf eine Verbesserung der Qualität der Aufgabenentwicklung in der Erkennungs- und Architekturphase hin. Die Anzahl der in der Produktion gefundenen Fehler hat sich nicht geändert.
Was haben wir gelernt?
Jetzt werde ich einige Ideen formulieren, die das Team und ich aus unserer Erfahrung gelernt haben. Wenn Sie ähnliche Probleme in Ihren Teams haben, hoffe ich, dass sie Ihnen auch helfen.
- , . — . , — , . — .
- , , , , , . , .
- — , , . , , discovery .
- . one-one-, , . Shoom3301, .
- : — , IT — . , .