Πώς, σε συνθήκες άχρηστης αρχιτεκτονικής και έλλειψης δεξιοτήτων Scrum, δημιουργήσαμε ομάδες πολλαπλών συστατικών

Γεια σας!

Ονομάζομαι Αλέξανδρος και ηγούμαι της ανάπτυξης πληροφορικής στο UBRD!

Το 2017, εμείς στο κέντρο για την ανάπτυξη υπηρεσιών τεχνολογίας πληροφοριών στο UBRD συνειδητοποιήσαμε ότι είχε έρθει η ώρα για παγκόσμιες αλλαγές ή μάλλον ευέλικτο μετασχηματισμό. Σε συνθήκες έντονης επιχειρηματικής ανάπτυξης και ταχείας ανάπτυξης του ανταγωνισμού στη χρηματοπιστωτική αγορά, τα δύο χρόνια είναι μια εντυπωσιακή περίοδος. Επομένως, ήρθε η ώρα να συνοψίσουμε το έργο.

Το πιο δύσκολο πράγμα είναι να αλλάξετε τη σκέψη σας και να αλλάξετε σταδιακά την κουλτούρα στον οργανισμό, όπου συνηθίζεται να σκέφτεστε: «Ποιος θα είναι το αφεντικό σε αυτήν την ομάδα;», «Το αφεντικό ξέρει καλύτερα τι πρέπει να κάνουμε», « Δουλεύουμε εδώ για 10 χρόνια και γνωρίζουμε καλύτερα τους πελάτες μας." , ξέρουμε τι χρειάζονται."

Η ευκίνητη μεταμόρφωση μπορεί να συμβεί μόνο όταν αλλάξουν οι ίδιοι οι άνθρωποι.
Θα τονίσω τους ακόλουθους βασικούς φόβους που εμποδίζουν τους ανθρώπους να αλλάξουν:

  • Φόβος απώλειας εξουσίας και «επωλέτες».
  • Φόβος μήπως γίνει περιττός για την εταιρεία.

Έχοντας μπει στο μονοπάτι της μεταμόρφωσης, επιλέξαμε τα πρώτα «έμπειρα κουνέλια» - υπαλλήλους του τμήματος λιανικής. Το πρώτο βήμα ήταν ο επανασχεδιασμός της αναποτελεσματικής δομής πληροφορικής. Έχοντας καταλήξει σε μια ιδέα-στόχο για τη δομή, αρχίσαμε να σχηματίζουμε ομάδες ανάπτυξης.

Πώς, σε συνθήκες άχρηστης αρχιτεκτονικής και έλλειψης δεξιοτήτων Scrum, δημιουργήσαμε ομάδες πολλαπλών συστατικών

Η αρχιτεκτονική στην τράπεζά μας, όπως και σε πολλές άλλες, είναι «σκουπίδια», για να το θέσω ήπια. Ένας τεράστιος αριθμός εφαρμογών και εξαρτημάτων είναι μονολιθικά διασυνδεδεμένοι με σύνδεση DB, υπάρχει ένας δίαυλος ESB, αλλά δεν εκπληρώνει τον επιδιωκόμενο σκοπό. Υπάρχουν και μερικά ABS.

Πώς, σε συνθήκες άχρηστης αρχιτεκτονικής και έλλειψης δεξιοτήτων Scrum, δημιουργήσαμε ομάδες πολλαπλών συστατικών

Πριν σχηματιστούν οι ομάδες του Scrum, προέκυψε το ερώτημα: "Γύρω από τι πρέπει να συγκεντρωθεί η ομάδα;" Η ιδέα ότι υπήρχε ένα προϊόν στο κουτί, φυσικά, ήταν στον αέρα, αλλά απλώς απρόσιτη. Μετά από πολλή σκέψη, αποφασίσαμε ότι η ομάδα πρέπει να συγκεντρωθεί γύρω από μια κατεύθυνση ή τμήμα. Για παράδειγμα, το "Team Credits", το οποίο αναπτύσσει δανεισμό. Έχοντας αποφασίσει για αυτό, αρχίσαμε να καταλήξουμε σε μια σύνθεση-στόχο ρόλων και ένα σύνολο ικανοτήτων που είναι απαραίτητες για την αποτελεσματική ανάπτυξη αυτού του τομέα. Όπως πολλές άλλες εταιρείες, λάβαμε υπόψη όλους τους ρόλους εκτός από τον Scrum Master - εκείνη την εποχή ήταν σχεδόν αδύνατο να εξηγήσουμε στον CIO ποιος ήταν ο ρόλος αυτού του υπέροχου ατόμου.

Ως αποτέλεσμα, αφού εξηγήσαμε την ανάγκη δημιουργίας ομάδων ανάπτυξης, ξεκινήσαμε τρεις ομάδες:

  1. Πιστώσεις
  2. Χάρτες
  3. Παθητικές Λειτουργίες

Με ένα σύνολο ρόλων:

  1. Υπεύθυνος Ανάπτυξης (Τεχνικός Υπεύθυνος)
  2. Προγραμματιστής
  3. Αναλυτής
  4. Δοκιμαστής

Το επόμενο βήμα ήταν να καθοριστεί πώς θα λειτουργούσε η ομάδα. Πραγματοποιήσαμε ευέλικτη προπόνηση για όλα τα μέλη της ομάδας και καθίσαμε όλοι σε ένα δωμάτιο. Δεν υπήρχαν PO στις ομάδες. Πιθανώς όλοι όσοι έχουν κάνει μια ευέλικτη μεταμόρφωση καταλαβαίνουν πόσο δύσκολο είναι να εξηγήσεις τον ρόλο του PO στην επιχείρηση και ακόμα πιο δύσκολο να τον καθίσεις δίπλα στην ομάδα και να του δώσεις εξουσία. Αλλά «πατήσαμε» σε αυτές τις αλλαγές με αυτά που είχαμε.

Με τόσες πολλές εφαρμογές που εμπλέκονται στις διαδικασίες δανεισμού και στις υπόλοιπες επιχειρήσεις λιανικής, αρχίσαμε να σκεφτόμαστε ποιος μπορεί να είναι ο κατάλληλος για τους ρόλους; Ένας προγραμματιστής μιας στοίβας τεχνολογίας, και μετά κοιτάς - και χρειάζεσαι έναν προγραμματιστή μιας άλλης στοίβας τεχνολογίας! Και τώρα βρήκατε αυτούς που χρειάζονται, αλλά η επιθυμία του υπαλλήλου είναι επίσης ένα σημαντικό πράγμα, και είναι αρκετά δύσκολο να αναγκάσετε ένα άτομο να εργαστεί εκεί που δεν του αρέσει.

Αφού αναλύσαμε τη δουλειά της επιχειρηματικής διαδικασίας δανεισμού και μακροχρόνιες συζητήσεις με συναδέλφους, βρήκαμε επιτέλους μια μέση λύση! Έτσι προέκυψαν τρεις ομάδες ανάπτυξης.

Πώς, σε συνθήκες άχρηστης αρχιτεκτονικής και έλλειψης δεξιοτήτων Scrum, δημιουργήσαμε ομάδες πολλαπλών συστατικών

Ποιο είναι το επόμενο;

Οι άνθρωποι άρχισαν να χωρίζονται σε αυτούς που θέλουν να αλλάξουν και σε αυτούς που δεν θέλουν. Όλοι συνηθίζουν να δουλεύουν υπό τις συνθήκες «μου έδωσαν πρόβλημα, το έκανα, άσε με ήσυχο», αλλά η ομαδική δουλειά δεν συνεπάγεται αυτό. Αλλά λύσαμε και αυτό το πρόβλημα. Συνολικά, 8 στα 150 άτομα τα παράτησαν κατά τη διάρκεια των αλλαγών!

Μετά άρχισε η διασκέδαση. Οι ομάδες μας μεταξύ των συστατικών άρχισαν να αναπτύσσονται μόνες τους. Για παράδειγμα, υπάρχει μια εργασία για την οποία πρέπει να έχετε δεξιότητες στον τομέα του προγραμματιστή CRM. Είναι στην ομάδα, αλλά είναι μόνος. Υπάρχει επίσης ένας προγραμματιστής Oracle. Τι να κάνετε εάν πρέπει να λύσετε 2 ή 3 εργασίες στο CRM; Διδάξτε ο ένας τον άλλον! Τα παιδιά άρχισαν να μεταφέρουν τις αρμοδιότητές τους ο ένας στον άλλο και η ομάδα επέκτεινε τις δυνατότητές της, ελαχιστοποιώντας την εξάρτηση από έναν ισχυρό ειδικό (παρεμπιπτόντως, σε οποιαδήποτε εταιρεία υπάρχουν υπεράνθρωποι που ξέρουν τα πάντα και δεν λένε σε κανέναν).

Σήμερα έχουμε συγκεντρώσει 13 ομάδες ανάπτυξης για όλους τους τομείς επιχειρηματικής ανάπτυξης και ανάπτυξης υπηρεσιών. Συνεχίζουμε την ευκίνητη μεταμόρφωσή μας και φτάνουμε σε ένα νέο επίπεδο. Αυτό θα απαιτήσει νέες αλλαγές. Θα επανασχεδιάσουμε ομάδες και αρχιτεκτονική και θα αναπτύξουμε ικανότητες.

Τελικός μας στόχος: γρήγορη ανταπόκριση στις αλλαγές προϊόντων, γρήγορη μεταφορά νέων χαρακτηριστικών στην αγορά και βελτίωση των υπηρεσιών της τράπεζας!

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο