Tim kami mengembangkan produk kredit dan jaminan untuk badan hukum. Arahnya masih muda, masalah pertama dimulai pada 2018. Kami check-in dan mempelajari pasar, meluncurkan cerukan, pinjaman untuk meningkatkan omset dan jaminan bank. Rencananya adalah untuk meluncurkan pinjaman terhadap kontrak, pinjaman hipotek dan produk lainnya.
Gejala
Proses kami dari mekanik mulai cepat mulai menumpuk kruk. Kami tahan dengan mereka dan, seperti yang Anda duga, setelah menyadari bahwa tugas untuk proses mulai dikembangkan terlalu lama. Ini tercermin dalam transfer rilis yang konstan, tugas tidak selesai tepat waktu. Bug yang menumpuk mempengaruhi segmen kecil pelanggan tertentu.
Ada situasi ketika rilis untuk tugas berikutnya, yang sudah dipindahkan selama dua bulan, kembali ditunda tanpa batas waktu. Pada saat yang sama, pelepasan fitur cerukan merusak jaminan bank. Ada desinkronisasi pemahaman produk. Pengembang mempertimbangkan hal-hal penting yang bahkan tidak diperhatikan oleh tim bisnis. Sebaliknya, fitur utama produk tetap tidak diketahui.
Untuk keluar dari situasi krisis, dibentuklah kelompok kerja yang dihadapkan pada tugas membuat “cepat dan baik” dari “buruk dan panjang”. Untuk diri kami sendiri, kami menetapkan tujuan untuk meningkatkan kinerja dan mengurangi jumlah bug.
Masalah
Setelah mempelajari lebih dalam proses tim, kami menemukan jalinan masalah yang tidak dapat diselesaikan secara terpisah, mereka membutuhkan pendekatan terintegrasi:
- tumpukan teknologi lama;
- proses kanban yang panjang dan bengkok;
- bisnis naik ke urusan internal pembangunan;
- tim pengembang kehilangan minat pada proyek;
- toksisitas umum.
Saya akan memberi tahu Anda lebih rinci bagaimana hal ini diungkapkan.
Tumpukan teknologi lama. Proses kami ditulis dalam IBM ODM, sistem dengan sejumlah fitur yang menghalangi tim. Mereka dijelaskan secara rinci oleh arsitek kami Denis Kotskindalam kasus proyek tetangga (meskipun ada IBM BPM, tetapi secara umum semuanya adil). Secara terpisah, saya perhatikan bahwa tidak ada spesialis di pasar yang berpengalaman dalam sistem ini.
Proses pengiriman yang lama. Secara resmi, kami memposisikan diri sebagai tim kanban, tetapi prosesnya tampak seperti persilangan antara waterfall dan scrum. Warisan pengembangan air terjun adalah bisnis, pengembangan, dan pengujian hanya berkomunikasi di kartu Jira. Setiap orang memiliki pemikiran yang jernih: "Saya telah melakukan bagian saya, pondok saya berada di ujung tanduk."
Kami tidak langsung menggunakan kanban. Pada awalnya, kami menggunakan Scrum dengan sprint, yang menunjukkan dirinya lebih baik pada proyek-proyek muda. Kemudian mereka menyadari bahwa secara moral sulit bagi tim untuk mentransfer tugas dari sprint ke sprint, dan beralih ke kanban. Kemudian menjadi jelas bahwa tidak ada yang tahu bagaimana bekerja dengan aliran input, siklus pengembangan mulai muncul. Itu terwujud dalam kenyataan bahwa tugas dari bisnis diterima seminggu sekali, kemudian tim mengevaluasinya, menjadi jelas bahwa tidak ada yang jelas, dan tugas dikirim untuk minggu depan. Pada saat yang sama, dengan kata lain, kami melakukan kanban dan mencari kemacetan.
Saya memahami bahwa ide Kanban dan Scrum tidak saling bertentangan dan ada contoh di mana kombinasi metodologi menunjukkan hasil yang baik. Tetapi saya ingin menekankan bahwa ada posisi radikal kanban murni. Jumlah pengembalian yang besar dari pengujian ke pengembangan juga sangat melambat, yang menandakan rendahnya kualitas tugas pada tahap awal.
Pelanggaran model peran. Analis bisnis terlibat dalam arsitektur - mereka menemukan solusi teknis untuk masalah tersebut. Hal ini mengarah pada fakta bahwa mereka sering meninggalkan penemuan mendalam demi elaborasi dan spesifikasi solusi, dan peretasan ini, ditambah dengan arsitektur yang lemah, memperlambat pengembangan beberapa kali.
Kehilangan minat oleh tim dalam proyek.Tim muda yang berbakat, ambisius. Startup murni. Setelah peluncuran dan penskalaan, nyeri tumbuh dimulai. Tekanan konstan dari bisnis, kompleksitas pengembangan karena kurangnya refactoring, masalah internal yang menumpuk, backlog selama berbulan-bulan ke depan menyebabkan kelelahan dan kelelahan yang dangkal.
Karena semua hal di atas, suasana dalam tim menjadi suram. Masalah diperbaiki pada retro, tetapi tidak terpecahkan, dan mengembara dari minggu ke minggu. Toksisitas umum meledak, setiap dialog tentang pekerjaan digulung menjadi saling mencela.
Apa yang telah kita lakukan
Sejujurnya, pada awalnya kami hanya memahami bahwa kami perlu menulis ulang proses dari awal untuk menghilangkan kruk dan memperkuat tim dengan developer berpengalaman. Enam bulan kemudian, saya dapat menyebutkan dua hal lagi yang membantu kami:
- Membangun kembali proses kanban. Terima kasih kepada pusat pengiriman Tinkoff Biznesa, yang dengan cepat menyelidiki masalah kami dan membantu menyesuaikan Jira.
- Sinkronisasi bisnis dan TI. Di sini kami didorong oleh keyakinan bahwa tim harus memiliki pemahaman yang baik tentang produk, dan tidak hanya melakukan tugas yang akan menghasilkannya.
Pada akhirnya, proses penulisan ulang memecahkan masalah tumpukan teknologi dan membantu menyingkirkan kruk. Pemikiran ulang proses kanban membantu membangun kembali model peran dan mengurangi jumlah pengembalian, yaitu meningkatkan kecepatan pengiriman tugas ke produk. Sejumlah kegiatan sinkronisasi dan pemikiran ulang tentang format saat ini telah meluruskan suasana secara umum.
Bagian 1. Menulis ulang proses
Jadi kami mulai menulis ulang proses dari IBM ODM ke Camunda. Alasan memilih Camunda dijelaskan dalam artikel Nikolay nshipyakov.dll...
Dalam proses aplikasi, kami menggunakan istilah seperti tahapan - bagian yang secara logis tertutup dari proses, dengan arti yang jelas bagi klien, misalnya, “Mengumpulkan dokumen” atau “Menandatangani perjanjian pinjaman”. Tugas pertama kami adalah meluncurkan pinjaman kontrak. Kami menyadari bahwa logika dari ketiga tahap tersebut khusus untuk itu, dan sisanya tidak berbeda dari tahap serupa dari pinjaman yang beredar. Sebenarnya, kami menulis tiga tahap produk baru di Camunda. Di masa depan, seluruh tahapan ditulis ulang ketika tugas bisnis muncul untuk perubahan seriusnya.
Sebuah pertanyaan wajar muncul: bagaimana kami bernegosiasi dengan bisnis? Jelas bahwa menulis ulang fungsi yang sudah berfungsi membutuhkan waktu lebih lama daripada mengubahnya di mesin lama. Semuanya ternyata cukup sederhana: rekan kerja siap untuk berinvestasi dalam proses baru, karena mereka melihat betapa kerennya itu bekerja pada proyek tetangga (dan halo lagi, DenisKotskin). Pada saat yang sama, waktu pengembangan mesin baru tidak lama lagi, sejak kami mulai rotasi: orang-orang yang kelelahan pindah ke proyek lain, mempekerjakan karyawan yang berpengalaman dalam mengembangkan dan merancang proses bisnis untuk menggantikannya.
Bagian 2. Mengubah urutan pelaksanaan tugas
Saat mengubah proses pengembangan, kami mengandalkan pedoman berikut:
- Seharusnya tidak ada langkah yang tidak tercermin di papan tulis.
- Keahlian teknis harus diberikan kepada tim.
- Tim harus memahami bagaimana tugas tersebut memengaruhi bisnis.
Dengan mengubah proses Kanban, kami telah mengidentifikasi tahapan baru yang sebelumnya secara implisit melalui tahap pengembangan: ini adalah arsitektur dan pertemuan tiga amigos. Secara alami, arsitektur tidak dilakukan pada perubahan kecil, tetapi kami mencoba mengadakan pertemuan tiga amigos untuk tugas apa pun. Nastya punya artikel tentang metode "Tiga Amigo"Travieso... Saya ingin mengucapkan terima kasih khusus kepada Nastya: pelatihannya dalam pengujian Agile menginspirasi kami untuk membuat banyak perubahan dalam tim.
Tim menerima data tentang nilai produk dalam format cerita pengguna dan penilaian dampak tugas pada produk. Sulit untuk menemukan tebing pelanggan bisnis yang cerdas. Misalnya, peringkat "Aturan ini penting, akan diperiksa pada semua aplikasi" jauh lebih tidak informatif daripada "Kami melakukan analisis, aturan akan menolak 10 aplikasi tambahan per minggu". Oleh karena itu, sebelum menyerahkan tugas pengembangan, saya memvalidasi kualitas nilai tertulis, sebagai perwakilan dari tim bisnis yang berbagi nilai-nilai pengembang.
Kami juga menghentikan praktik yang tidak berhasil untuk kami. Misalnya, sekarang kita jarang melakukan retro, hanya jika perlu - ketika kebutuhan untuk membahas sesuatu menumpuk. Ini terjadi sebulan sekali. Masalah yang ditunjukkan dalam retro sangat penting untuk diselesaikan, karena setiap anggota tim harus melihat perubahan positif pada masalah yang membebani dirinya.
Kami berhenti menggunakan storypoint dan penilaian tim dari suatu tugas - kami bekerja dengan tanggal jatuh tempo yang kami terima dari bisnis, dan bergantung pada mereka, kami mengelola aliran input. Pada tugas-tugas besar yang dilakukan selama beberapa bulan, kami melakukan dekomposisi: memungkinkan untuk membuat semacam titik pemeriksaan dan meningkatkan akurasi tenggat. Untuk memantau kemajuan, kami bertemu dan berdiskusi secara berkala apakah kami tepat waktu. Jika ternyata tidak, kami menyesuaikan aliran input dan mengambil lebih sedikit tugas kecil. Adapun keakuratan mencapai tenggat waktu, saya hanya dapat mengatakan bahwa untuk tugas utama kami saat ini, kami sesuai dengan waktunya.
Mengenai redistribusi peran, kami memperkuat tim dengan seorang arsitek dan analis sistem kedua. Tim bisnis mencoba menjelaskan dengan jelas apa yang dibutuhkan dalam tugas, nilai apa yang dibawanya, tetapi tidak untuk memberi saran atau masuk ke dalam pekerjaan pengembangan. Saya juga menjaga tim bisnis.
Bagian 3. Sinkronisasi TI dan tim bisnis
Kami menggunakan beberapa format untuk menyinkronkan bisnis dan pengembang.
Demo demi tugas. Ini adalah pertemuan semua yang tertarik - analis portofolio, departemen risiko, pemasar, dan spesialis TI - dengan diskusi tentang nilai, masalah bermasalah, dan solusi teknis.
Pertemuan penting tempat Anda dapat menemukan kesalahan yang terlewat pada tahap penemuan dan punya waktu untuk memperbaikinya. Selain itu, manajer yang memimpin tugas tidak mengetahui secara pasti proses perusahaan mana yang akan terpengaruh oleh rilis tersebut. Bersama kami, publisitas semacam itu memungkinkan kami untuk mencegah situasi ketika perubahan dalam proses rusak, misalnya, laporan analitis.
Retro dalam tugas.Pada pertemuan ini, kami membahas masalah pengembang dan pelanggan yang mereka temui selama pengembangan masalah. Kami melakukannya setelah analitik pasca-rilis - ketika gairah telah mereda dan semua orang siap untuk dialog yang konstruktif. Setelah mengetahui alasannya, kami membentuk titik pertumbuhan dan awan ide, yang akan kami coba di masa depan.
Kami mengadakan ceramah tentang produk dalam format program pendidikan dan diskusi selanjutnya. Tujuan mereka adalah untuk melibatkan orang-orang TI dalam konteks bisnis. Untuk umpan balik yang dikumpulkan dalam bentuk survei dengan kata-kata paling umum "Beri nilai kuliah hari ini", nilai rata-rata adalah 8,5 dari 10.
Hasil
Enam bulan kemudian, kami menulis ulang lebih dari 80% proses, meluncurkan pinjaman terhadap kontrak menggunakan mesin yang benar-benar baru. Suasana tim telah meningkat dan kami menjadi lebih efisien. Untuk memverifikasi ini, kami melakukan survei terhadap tim dan mengambil statistik dari Jira.
Survei tersebut menanyakan tentang atmosfer dalam tim, kualitas spesifikasi, pengembangan dan arsitektur, kualitas komunikasi dengan bisnis. Menurut hasil survei, skor rata-rata orang-orang yang telah berada di proyek selama lebih dari setengah tahun naik dari 6 menjadi 8 poin dari 10. Sayangnya, survei tersebut tidak sepenuhnya jujur, karena dilakukan setelah adanya perubahan. Gambar yang ditampilkan adalah untuk awal tahun dan awal Juli. Jadi adil untuk mengatakan bahwa situasi di tim telah membaik, tetapi tidak bisa dikatakan seberapa.
Kinerja (jumlah tugas per hari) menjadi dua kali lipat selama ini. Secara alami, tidak dengan mengorbankan dekomposisi: kami telah menyetujui sebelumnya standar tertentu yang kami patuhi.
Jumlah pengembalian dari pengujian ke pengembangan sedikit menurun. Artinya, dengan beberapa kali peningkatan dalam jumlah tugas yang ditampilkan untuk produksi, jumlah pengembalian tidak meningkat. Ini menunjukkan peningkatan kualitas pengembangan tugas pada tahap penemuan dan arsitektur. Jumlah bug yang ditemukan dalam produksi tidak berubah.
Apa yang telah kami pelajari
Sekarang saya akan merumuskan beberapa ide yang saya dan tim pelajari dari pengalaman kami. Jika Anda memiliki masalah serupa di tim Anda, saya harap mereka juga akan membantu Anda.
- , . — . , — , . — .
- , , , , , . , .
- — , , . , , discovery .
- . one-one-, , . Shoom3301, .
- : — , IT — . , .