Hallo!
Mein Name ist Alexander und ich leite die IT-Entwicklung bei UBRD!
2017 haben wir vom UBRD Information Technology Services Development Center erkannt, dass die Zeit für globale Veränderungen bzw. agile Transformationen gekommen ist. Unter den Bedingungen einer intensiven Geschäftsentwicklung und eines raschen Wachstums des Wettbewerbs auf dem Finanzmarkt sind zwei Jahre eine beeindruckende Zeit. Es ist also Zeit, eine Bestandsaufnahme des Projekts vorzunehmen.
Am schwierigsten ist es, Ihr Denken und schrittweise die Kultur in der Organisation zu ändern, in der es üblich ist zu argumentieren: „Wer wird der Chef in diesem Team sein?“, „Der Chef weiß besser, was wir tun müssen“, „Wir arbeiten hier seit 10 Jahren und wissen es besser als unsere Kunden Wir wissen, was sie brauchen. "
Agile Transformation kann nur stattfinden, wenn sich die Menschen selbst darin verändern.
Ich möchte die folgenden zentralen Befürchtungen hervorheben, die verhindern, dass sich Menschen verändern:
- Angst vor Machtverlust und „Schulterklappen“;
- Angst, für das Unternehmen unnötig zu werden.
Nachdem wir einen Transformationspfad eingeschlagen hatten, wählten wir die ersten „erfahrenen Kaninchen“ aus - Mitarbeiter des Einzelhandelssektors. Der erste Schritt war die Neugestaltung der ineffizienten IT-Struktur. Nachdem wir das Zielkonzept der Struktur ausgearbeitet hatten, begannen wir, Entwicklungsteams zu bilden.
Die Architektur in unserer Bank, wie in vielen anderen, um es milde auszudrücken, "Thrash". Eine große Anzahl von Anwendungen und Komponenten, die nahtlos über eine DB-Verbindung miteinander verbunden sind, verfügen über einen ESB-Bus, der jedoch seinen Zweck nicht erfüllt. Es gibt auch mehrere ABS.
Vor der Bildung von Scrum-Teams stellte sich die Frage: „Und um was soll das Team zusammengestellt werden?“. Das Konzept, dass es ein Produkt in der Bank gibt, lag natürlich in der Luft, aber in einer Entfernung von Unzugänglichkeit. Nach langen Überlegungen entschieden sie, dass sich das Team um eine Richtung oder ein Segment versammeln sollte. Zum Beispiel „Team Loans“, das die Kreditvergabe entwickelt. Nachdem wir uns dazu entschlossen hatten, begannen wir, die Zielzusammensetzung der Rollen und eine Reihe von Kompetenzen zu entwickeln, die für die effektive Entwicklung dieses Bereichs erforderlich sind. Wie viele andere Unternehmen haben wir alle Rollen außer Scrum Master berücksichtigt - zu dieser Zeit war es fast unmöglich, dem CIO die Rolle dieser wunderbaren Person zu erklären.
Nachdem wir die Notwendigkeit geklärt hatten, Entwicklungsteams zu starten, haben wir drei Teams gestartet:
- Kredite
- Karten
- Passive Operationen
Mit einer Reihe von Rollen:
- Entwicklungsleiter (Tech Lead)
- Entwickler
- Analyst
- Tester
Der nächste Schritt bestand darin, zu bestimmen, wie das Team arbeiten würde. Wir haben für alle Teammitglieder ein agiles Training durchgeführt und alle in einen Raum gebracht. PO war nicht in den Teams. Wahrscheinlich versteht jeder, der die agile Transformation durchgeführt hat, wie schwierig es ist, die Rolle von PO für Unternehmen zu erklären, und es ist noch schwieriger, sie neben das Team zu stellen und Autorität zu erteilen. Aber wir sind mit dem, was war, in diese Veränderungen „eingetreten“.
Da eine große Anzahl von Anträgen in die Kreditvergabeprozesse und andere Bereiche des Einzelhandelsgeschäfts involviert war, begannen wir zu überlegen, wer die Rollen übernehmen kann. Der Entwickler eines Technologie-Stacks, und da sehen Sie - und Sie brauchen einen Entwickler eines anderen Technologie-Stacks! Und so haben Sie diejenigen gefunden, die gebraucht werden, aber der Wunsch des Mitarbeiters ist auch eine wichtige Sache, und es ist ziemlich schwierig, eine Person dazu zu bringen, dort zu arbeiten, wo sie nicht mag.
Nach der Analyse der Arbeit des Geschäftskreditprozesses und langen Gesprächen mit Kollegen fanden wir immer noch einen Mittelweg! Es gab also drei Entwicklungsteams.
Was weiter?
Die Menschen begannen sich in diejenigen zu teilen, die sich ändern wollen, und diejenigen, die es nicht wollen. Jeder ist es gewohnt, unter den Bedingungen zu arbeiten, dass „sie mir eine Aufgabe gegeben haben, ich habe es getan, mich in Ruhe gelassen“, und Teamarbeit bedeutet dies nicht. Aber wir haben dieses Problem gelöst. Insgesamt haben 8 von 150 Personen während der Änderungen gekündigt!
Dann begann der Spaß. Unsere komponentenübergreifenden Teams begannen sich zu entwickeln. Zum Beispiel gibt es eine Aufgabe, für die Sie Kenntnisse im Bereich eines CRM-Entwicklers benötigen. Er ist im Team, aber er ist allein. Es gibt auch einen Oracle-Entwickler. Was tun, wenn Sie 2 oder 3 Aufgaben in CRM lösen müssen? Lehre einander! Die Jungs begannen, ihre Kompetenzen aufeinander zu übertragen, und das Team erweiterte ihre Fähigkeiten, um die Abhängigkeit von einem starken Spezialisten zu minimieren (übrigens gibt es in jedem Unternehmen Supermenschen, die alles wissen und niemandem davon erzählen).
Heute haben wir 13 Entwicklungsteams für alle Bereiche der Geschäfts- und Serviceentwicklung zusammengestellt. Wir setzen die agile Transformation fort und bewegen uns auf eine neue Ebene. Dies erfordert neue Änderungen. Wir werden Teams und Architektur neu gestalten, wir werden Kompetenzen entwickeln.
Unser letztes Ziel: schnell auf Produktänderungen zu reagieren, schnell neue Funktionen auf den Markt zu bringen und die Dienstleistungen der Bank zu verbessern!