Hallo!
Mein Name ist Alexander und ich leite die IT-Entwicklung bei UBRD!
Im Jahr 2017 haben wir vom Zentrum für die Entwicklung von Informationstechnologiediensten an der UBRD erkannt, dass die Zeit für globale Veränderungen, oder besser gesagt für eine agile Transformation, gekommen ist. Unter Bedingungen intensiver Geschäftsentwicklung und schnellem Wettbewerbswachstum auf dem Finanzmarkt sind zwei Jahre ein beeindruckender Zeitraum. Daher ist es an der Zeit, das Projekt zusammenzufassen.
Am schwierigsten ist es, das eigene Denken zu ändern und die Kultur in der Organisation schrittweise zu verändern, wo man häufig denkt: „Wer wird der Chef in diesem Team sein?“, „Der Chef weiß besser, was wir tun müssen.“ „Wir arbeiten hier seit 10 Jahren und kennen unsere Kunden besser.“ „Wir wissen, was sie brauchen.“
Agile Transformation kann nur stattfinden, wenn sich die Menschen selbst verändern.
Ich möchte die folgenden Hauptängste hervorheben, die Menschen daran hindern, sich zu ändern:
- Angst vor Machtverlust und „Schulterklappen“;
- Angst, für das Unternehmen überflüssig zu werden.
Nachdem wir den Weg der Transformation eingeschlagen hatten, wählten wir die ersten „erfahrenen Kaninchen“ aus – Mitarbeiter der Einzelhandelsabteilung. Der erste Schritt bestand darin, die ineffiziente IT-Struktur neu zu gestalten. Nachdem wir ein Zielkonzept für die Struktur entwickelt hatten, begannen wir mit der Bildung von Entwicklungsteams.
Die Architektur in unserer Bank ist, wie in vielen anderen auch, gelinde gesagt „Müll“. Eine Vielzahl von Anwendungen und Komponenten sind durch DB-Link monolithisch miteinander verbunden, es gibt einen ESB-Bus, der jedoch seinen vorgesehenen Zweck nicht erfüllt. Es gibt auch etwas ABS.
Vor der Bildung von Scrum-Teams stellte sich die Frage: „Worauf sollte das Team zusammengestellt werden?“ Die Vorstellung, dass sich ein Produkt in der Dose befände, lag natürlich in der Luft, aber einfach außer Reichweite. Nach langem Überlegen entschieden wir, dass das Team um eine Richtung oder ein Segment herum versammelt werden sollte. Zum Beispiel „Team Credits“, das die Kreditvergabe entwickelt. Nachdem wir uns dazu entschieden hatten, begannen wir mit der Ausarbeitung einer Zielzusammensetzung von Rollen und einer Reihe von Kompetenzen, die für die effektive Entwicklung dieses Bereichs erforderlich sind. Wie viele andere Unternehmen haben wir alle Rollen außer dem Scrum Master berücksichtigt – damals war es fast unmöglich, dem CIO zu erklären, was die Rolle dieser wunderbaren Person war.
Nachdem wir die Notwendigkeit der Gründung von Entwicklungsteams erläutert hatten, gründeten wir drei Teams:
- Kredite
- Karten
- Passive Operationen
Mit einer Reihe von Rollen:
- Entwicklungsleiter (Tech Lead)
- Entwickler
- Analytiker
- Prüfer
Der nächste Schritt bestand darin, festzulegen, wie das Team arbeiten würde. Wir führten für alle Teammitglieder ein agiles Training durch und setzten alle in einen Raum. Es gab keine POs in den Teams. Wahrscheinlich weiß jeder, der eine agile Transformation durchgeführt hat, wie schwierig es ist, dem Unternehmen die Rolle eines PO zu erklären, und noch schwieriger, ihn neben das Team zu setzen und ihm Autorität zu verleihen. Aber wir sind mit dem, was wir hatten, in diese Veränderungen „eingetreten“.
Bei so vielen Anwendungen im Zusammenhang mit Kreditvergabeprozessen und dem Rest des Einzelhandelsgeschäfts begannen wir darüber nachzudenken, wer für die Rollen am besten geeignet sein könnte. Ein Entwickler eines Technologie-Stacks, und dann schauen Sie – und Sie brauchen einen Entwickler eines anderen Technologie-Stacks! Und jetzt haben Sie diejenigen gefunden, die Sie brauchen, aber auch der Wunsch des Mitarbeiters ist wichtig, und es ist ziemlich schwierig, eine Person dazu zu zwingen, dort zu arbeiten, wo sie nicht möchte.
Nach der Analyse der Arbeit des Kreditgeschäftsprozesses und langen Gesprächen mit Kollegen haben wir endlich einen Mittelweg gefunden! So entstanden drei Entwicklungsteams.
Was kommt als nächstes?
Die Menschen begannen sich in diejenigen zu spalten, die sich ändern wollten, und diejenigen, die dies nicht wollten. Jeder ist es gewohnt, unter den Bedingungen zu arbeiten: „Sie haben mir ein Problem gegeben, ich habe es getan, lassen Sie mich in Ruhe“, aber Teamarbeit bedeutet dies nicht. Aber auch dieses Problem haben wir gelöst. Insgesamt haben 8 von 150 Menschen während der Veränderungen gekündigt!
Dann begann der Spaß. Unsere komponentenübergreifenden Teams begannen sich zu entwickeln. Es gibt beispielsweise eine Aufgabe, für die Sie Kenntnisse im Bereich CRM-Entwickler benötigen. Er ist im Team, aber er ist allein. Es gibt auch einen Oracle-Entwickler. Was tun, wenn Sie zwei oder drei Aufgaben im CRM lösen müssen? Bringt es euch gegenseitig bei! Die Jungs begannen, ihre Kompetenzen aufeinander zu übertragen, und das Team erweiterte seine Fähigkeiten, wodurch die Abhängigkeit von einem starken Spezialisten minimiert wurde (übrigens gibt es in jedem Unternehmen Supermänner, die alles wissen und es niemandem erzählen).
Heute haben wir 13 Entwicklungsteams für alle Bereiche der Geschäfts- und Serviceentwicklung zusammengestellt. Wir setzen unsere agile Transformation fort und erreichen ein neues Level. Dies erfordert neue Änderungen. Wir werden Teams und Architektur neu gestalten und Kompetenzen weiterentwickeln.
Unser Endziel: schnell auf Produktänderungen reagieren, neue Funktionen schnell auf den Markt bringen und die Dienstleistungen der Bank verbessern!
Source: habr.com