Bagaimana, dalam kondisi arsitektur yang buruk dan kurangnya keterampilan Scrum, kami membentuk tim lintas komponen

Hi!

Nama saya Alexander, dan saya memimpin pengembangan TI di UBRD!

Pada tahun 2017, kami sebagai pusat pengembangan layanan teknologi informasi di UBRD menyadari bahwa sudah waktunya untuk perubahan global, atau lebih tepatnya, transformasi agile. Dalam kondisi perkembangan bisnis yang intensif dan pesatnya pertumbuhan persaingan di pasar keuangan, dua tahun merupakan periode yang mengesankan. Oleh karena itu, inilah waktunya untuk menyimpulkan hasil proyek.

Hal yang paling sulit adalah mengubah pemikiran Anda dan secara bertahap mengubah budaya dalam organisasi, di mana sering kali kita berpikir: “Siapa yang akan menjadi bos di tim ini?”, “Bos lebih tahu apa yang perlu kita lakukan”, “ Kami telah bekerja di sini selama 10 tahun dan mengenal klien kami lebih baik.” , kami tahu apa yang mereka butuhkan."

Transformasi tangkas hanya dapat terjadi jika masyarakatnya sendiri berubah.
Saya ingin menyoroti ketakutan-ketakutan utama berikut yang menghalangi orang untuk berubah:

  • Takut kehilangan kekuasaan dan “tanda pangkat”;
  • Takut menjadi tidak berguna bagi perusahaan.

Setelah memulai jalur transformasi, kami memilih “kelinci berpengalaman” pertama - karyawan departemen ritel. Langkah pertama adalah mendesain ulang struktur TI yang tidak efisien. Setelah menemukan konsep target struktur, kami mulai membentuk tim pengembangan.

Bagaimana, dalam kondisi arsitektur yang buruk dan kurangnya keterampilan Scrum, kami membentuk tim lintas komponen

Arsitektur di bank kami, seperti di banyak bank lainnya, adalah “sampah”, secara halus. Sejumlah besar aplikasi dan komponen saling terhubung secara monolitik melalui tautan DB, ada bus ESB, tetapi tidak memenuhi tujuan yang dimaksudkan. Ada juga beberapa ABS.

Bagaimana, dalam kondisi arsitektur yang buruk dan kurangnya keterampilan Scrum, kami membentuk tim lintas komponen

Sebelum membentuk tim Scrum, muncul pertanyaan: “Tim harus dibentuk berdasarkan apa?” Konsep bahwa ada produk di dalam kaleng, tentu saja sudah mengudara, tapi di luar jangkauan. Setelah berpikir panjang, kami memutuskan bahwa tim harus dikumpulkan di sekitar suatu arah atau segmen. Misalnya, “Kredit Tim”, yang mengembangkan pinjaman. Setelah memutuskan hal ini, kami mulai menyusun komposisi target peran dan serangkaian kompetensi yang diperlukan untuk pengembangan efektif bidang ini. Seperti banyak perusahaan lain, kami memperhitungkan semua peran kecuali Scrum Master - pada saat itu hampir tidak mungkin untuk menjelaskan kepada CIO apa peran orang yang luar biasa ini.

Hasilnya, setelah menjelaskan perlunya meluncurkan tim pengembangan, kami meluncurkan tiga tim:

  1. Pinjaman
  2. Kartu-kartu
  3. Operasi Pasif

Dengan serangkaian peran:

  1. Manajer Pengembangan (Pimpinan Teknologi)
  2. Pembangun
  3. Analis
  4. Penguji

Langkah selanjutnya adalah menentukan bagaimana tim akan bekerja. Kami melakukan pelatihan tangkas untuk semua anggota tim dan mendudukkan semua orang dalam satu ruangan. Tidak ada PO di tim. Mungkin setiap orang yang telah melakukan transformasi tangkas memahami betapa sulitnya menjelaskan peran PO dalam bisnis, dan bahkan lebih sulit lagi untuk mendudukkannya di samping tim dan memberinya wewenang. Namun kami “melangkah” ke dalam perubahan ini dengan apa yang kami miliki.

Dengan begitu banyak lamaran yang terlibat dalam proses peminjaman dan bisnis ritel lainnya, kami mulai berpikir, siapa yang cocok untuk peran tersebut? Seorang pengembang dari satu tumpukan teknologi, dan kemudian Anda melihat - dan Anda memerlukan pengembang dari tumpukan teknologi lainnya! Dan kini Anda telah menemukan orang-orang yang dibutuhkan, namun keinginan karyawan juga merupakan hal yang penting, dan cukup sulit memaksa seseorang untuk bekerja di tempat yang tidak disukainya.

Setelah menganalisa jalannya bisnis proses peminjaman dan perbincangan panjang dengan rekan kerja, akhirnya kami menemukan jalan tengahnya! Ini adalah bagaimana tiga tim pengembangan muncul.

Bagaimana, dalam kondisi arsitektur yang buruk dan kurangnya keterampilan Scrum, kami membentuk tim lintas komponen

Apa selanjutnya?

Masyarakat mulai terpecah menjadi mereka yang ingin berubah dan mereka yang tidak. Setiap orang terbiasa bekerja dalam kondisi “mereka memberi saya masalah, saya melakukannya, tinggalkan saya sendiri”, tetapi kerja tim tidak menyiratkan hal ini. Tapi kami juga memecahkan masalah ini. Secara total, 8 dari 150 orang berhenti selama perubahan!

Kemudian kesenangan dimulai. Tim lintas komponen kami mulai mengembangkan diri. Misalnya, ada tugas yang mengharuskan Anda memiliki keterampilan di bidang pengembang CRM. Dia ada di tim, tapi dia sendirian. Ada juga pengembang Oracle. Apa yang harus dilakukan jika Anda perlu menyelesaikan 2 atau 3 tugas di CRM? Saling mengajar! Orang-orang mulai mentransfer kompetensi mereka satu sama lain, dan tim memperluas kemampuannya, meminimalkan ketergantungan pada satu spesialis yang kuat (omong-omong, di perusahaan mana pun ada manusia super yang tahu segalanya dan tidak memberi tahu siapa pun).

Saat ini kami telah membentuk 13 tim pengembangan untuk semua bidang pengembangan bisnis dan layanan. Kami melanjutkan transformasi tangkas kami dan mencapai tingkatan baru. Hal ini memerlukan perubahan baru. Kami akan mendesain ulang tim dan arsitektur, serta mengembangkan kompetensi.

Tujuan akhir kami: merespons perubahan produk dengan cepat, segera menghadirkan fitur-fitur baru ke pasar, dan meningkatkan layanan bank!

Sumber: www.habr.com

Tambah komentar