Cara membangun proses dan berhenti mengejek tim

Halo semuanya! Hari ini saya ingin berbicara tentang proses pengembangan. Ketika perusahaan tumbuh, tidak hanya bisnis itu sendiri berkembang, tetapi juga masalah menumpuk di dalam, khususnya selama proses pengembangan. Seringkali mereka mencoba menyelesaikannya dengan memperkenalkan beberapa praktik dan metodologi baru yang ketinggalan jaman. Sayangnya, proses reorganisasi yang dipaksakan ini menurut buku dan pelatihan sering menyebabkan masalah yang lebih besar - ejekan orang.

Saya baru-baru ini berbicara di konferensi Saint TeamLead Conf 2019 , dalam sebuah laporan saya berbicara tentang bagaimana saya dapat menemukan sejumlah masalah dalam alur kerja dan kemudian secara bertahap mengatasinya. Di sini saya akan mencoba menggambarkan praktik paling berharga yang membantu saya tidak hanya untuk membuat alur kerja, tetapi juga untuk berhenti mengejek para pengembang. Karyawan telah mengubah sikap mereka terhadap perusahaan secara keseluruhan dan proses kerja.

Tantangan Proses Pengembangan

Jadi, ketika pendekatan yang sudah jadi tidak memberikan hasil, dan kami hampir putus asa, saya mulai menganalisis proses dan mulai menganalisis semuanya dengan tulang. Hasilnya adalah daftar masalah:

• Papan penuh dengan tugas - ada kekacauan nyata di atasnya. Melihat papan tulis, memahami prosesnya hampir mustahil.
• Tidak ada evaluasi normal - kami tidak tahu bagaimana cara mengevaluasi tugas dengan benar sesuai dengan tenggang waktu, karena ini, tenggat waktu terus-menerus dalam perjalanan, para pemimpin bisnis mengalami perkembangan.
• Kami terus-menerus menyusun tenggat waktu - kami tidak dapat mengatakan dengan tepat kapan fitur tersebut akan diproduksi, paling sering kami meluncurkannya lebih lambat dari yang direncanakan karena faktor eksternal, misalnya, bisnis terpaksa dan meminta untuk segera melakukan fitur mendesak di tempat pertama.
• Tidak ada pemahaman bagaimana mempercepat pengembangan - mempekerjakan orang baru dan memuat insinyur hingga 100% tidak selalu membuat proses lebih cepat.
• Perencanaan dan tugas - tugas yang mendesak - jika dengan tugas-tugas saat ini, entah bagaimana mungkin membuat rencana dan menunjukkan perkiraan tanggal, maka tugas-tugas mendesak yang biasanya terbang dari bisnis melanggar semua rencana.
• Rapat memakan waktu - kesalahan kita yang paling umum: sesuatu tidak berhasil atau kita perlu memprioritaskan tugas - dan mari kita berkumpul dan berdiskusi. Atau pertemuan rutin, di mana para pengembang duduk selama satu atau dua jam dan tidak mengerti apa yang mereka lakukan di sana.
• Masalah motivasi dan keterlibatan tim - seringkali beberapa inovasi dijatuhkan begitu saja oleh pihak berwenang dari atas, tanpa meminta pendapat tim pengembangan, ini tidak melukiskan suasana di tim.

Sebenarnya, tugas pemimpin mana pun, apakah itu TL atau CTO, adalah ia harus menjadi penghubung antara bisnis dan pengembangan.

Untuk keluar dari situasi ini, kami beralih ke metode Kanban. Apa yang dia katakan pada kita? Mari kita tingkatkan apa yang sudah ada. Ya, kami pergi untuk meningkatkan proses pengembangan kami.

Menempatkan pesanan di papan tulis

Kami mulai berdebat: jika para backender menyelesaikan tugas mereka dan diserahkan ke front-end, apakah mereka akan segera memulainya? Melihat papan tulis, ini tidak bisa dimengerti. Menurut prinsip-prinsip Kanban, kami membagi setiap arah pengembangan (kami memiliki 5 di antaranya: backend, frontend, DevOps, QA dan desain) menjadi dua kolom: Do and Done. Masalahnya segera menjadi jelas: bandwidth kami tidak memungkinkan kami untuk melakukan tugas sebanyak yang mereka inginkan dari kami.



Kanban juga mengatakan: mari kita perkenalkan batas WIP dan batasi jumlah tugas. Bagaimana kita menetapkan batasan? Secara empiris. Tentu saja, mereka melewatkan beberapa kali, tetapi kemudian mereka mengambilnya sehingga kami tidak harus mengumpulkan tugas di tempat tersempit. Keuntungan tambahan dari batas-WIP adalah pemicu, yang mengatakan bahwa segera setelah tugas diambil, kita dapat mengambil yang berikut. Ini adalah semacam sistem penarik.



Apa yang menyebabkan ini? Insinyur mulai lebih memperhatikan tugas, karena ketika mereka tidak dapat menyelesaikan masalah, maka pemblokir diletakkan di atasnya. Tidak ada lagi tugas yang dapat diambil, karena ada batas WIP, para insinyur harus menunggu mereka untuk membantu menyelesaikannya. Ada kesempatan untuk tetap tanpa tugas.

Ketika kami mulai menganalisis secara detail masalah pengembalian tugas, ternyata setiap orang melakukannya secara berbeda, misalnya, seseorang menulis tes, dan seseorang tidak. Ada aturan dalam hal ini, tetapi yang dikecewakan oleh pihak berwenang. Mereka tidak memecahkan masalah pengembang. Kami memperkenalkan aturan baru ( Definisi Selesai ), yang terintegrasi ke dalam papan. Mereka dapat bertindak baik pada beberapa kolom, dan pada jenis kartu. Misalnya, untuk API, Anda memerlukan backend untuk mendokumentasikan semua metode dan hal-hal. Aturan dapat diakses oleh semua orang dan terlihat di papan tulis, dan yang paling penting, mereka datang dari para insinyur sendiri dan menyelesaikan masalah mereka. Jika sesuatu tidak dilakukan, insinyur melihatnya dan pergi untuk melakukannya.

Tugas Kelas

Kami tidak tahu bagaimana cara mengevaluasi tugas dengan tenggat waktu, dan Kanban memberi tahu kami: "Tidak ada perkiraan". Apa yang harus dilakukan Kami mengumpulkan statistik dan membuat jadwal seperti itu. Ini adalah diagram spektral, ketergantungan dari jumlah tugas tepat waktu.



Kami mulai mempelajarinya, lihat pada grafik 3 puncak yang sesuai dengan tiga jenis pekerjaan. Berdasarkan jenis ini, klasifikasi dan kriteria untuk pekerjaan tersebut dikembangkan. Kami memperkenalkan jenis ini di papan tugas, dan kemudian untuk masing-masing proses kami menambahkan aturan tambahan. Kami mendapat yang berikut:



Kami sepakat dengan pelanggan, yaitu, dengan bisnis, pada perjanjian kualitas layanan (SLA). Seorang manajer mendatangi kami dan bertanya: "Dan berapa banyak Anda akan membuat fitur ini?" Kita tidak dapat mengatakan berapa banyak yang akan kita lakukan dengan pasti, tetapi kita dapat mengatakan berapa banyak waktu yang akan dihabiskan untuk seluruh tugas tersebut. Tidak perlu scrum poker, dan kami berhenti menyiksa orang dengan pertanyaan waktu. Kami hanya melihat statistik dan menyebut tanggal untuk bisnis.



Tentu saja, pendekatan ini juga memiliki kelemahan. Misalnya, ini tidak berfungsi dengan tugas-tugas tipe baru, yang kami tidak punya statistik. Mereka berpura-pura dengan cara lama, tetapi kemudian mereka mengumpulkan cukup data dan masalah ini menjadi sia-sia.



Kemudian kami dihadapkan pada kenyataan bahwa beberapa tugas mulai jatuh ke jenis pekerjaan lain. Kami melakukan sedikit riset dan menemukan bahwa beberapa tugas dilakukan lebih cepat, karena bisnis menjanjikan mitra di sana sesuatu dan meminta pengembang untuk melakukannya dengan segera. Dan beberapa tugas sebaliknya tidak begitu penting, mereka ditunda. Jadi kami mendapat prioritas, yaitu, perjanjian pada kelas layanan jasa (CoS), kami menempatkan mereka di papan tulis. Dan agar bisnis tidak menyalahgunakannya dan tidak menetapkan urgensi yang meningkat untuk semua tugas, batas horizontal WIP telah diperkenalkan.

Cara mempercepat pengembangan

Kembali beralih ke statistik pelacak tugas. Kami menemukan bahwa banyak tugas menggantung di papan untuk mengantisipasi perbaikan, pemeriksaan atau data tambahan, yaitu, mereka menyadari bahwa pengembangan dapat dipercepat. Mereka mulai melihat berapa banyak tugas yang terakumulasi, seberapa banyak mereka menganggur, dan menemukan bahwa beberapa fitur dikembangkan kurang dari yang mereka harapkan diterima. Kami memutuskan untuk menetapkan hari untuk menerima fitur, dan waktu untuk menerbitkan tugas berkurang. Dan kemudian kami memasang CD (Pengiriman Berkelanjutan) dan mulai mengirim pemberitahuan.

Menjadi jelas bahwa kami membutuhkan alat untuk mengevaluasi peningkatan kami. Kami memutuskan untuk menggunakan diagram alir kumulatif. Singkatnya, bagaimana itu dibangun: kami memberikan warna ke setiap pusat kerja (kolom di papan), mengambil statistik tentang berapa banyak elemen (tugas) dalam satu unit waktu dalam kolom, dan plot mereka pada grafik, menempatkan mereka di bawah yang lain. Pada grafik, sumbu X adalah waktu, sumbu Y adalah jumlah tugas.



Apa yang kita dapat dari sini? Di sini mudah untuk melihat lead time (waktu produksi) - garis horizontal (lebar aliran sepanjang sumbu X) dimulai dengan pernyataan masalah dan mencapai tahap kesiapan. Dengan demikian, di sini Anda dapat melihat bagaimana tugas melewati semua tahap pengembangan - garis memotong semua warna, masing-masing sesuai dengan tahapannya. Dan juga total WIP-batas papan - ketinggian aliran sepanjang sumbu Y. Bagaimana cara meningkatkan kecepatan pengembangan? Anda dapat mengurangi batas-WIP (yaitu, membuat aliran pada grafik lebih sempit), atau Anda dapat membuat aliran kami, yang diarahkan dari titik asal ke sudut kanan atas grafik, cenderung naik lebih tinggi (yaitu, untuk meningkatkan arah aliran bahkan lebih ke atas, kurangi sudutnya relatif terhadap sumbu Y). Untuk mengarahkan aliran lebih kuat ke atas, Anda dapat memperkenalkan beberapa praktik baru, misalnya, mengimplementasikan Docker atau membuat basis pengetahuan yang nyaman. Ini tidak harus menjadi inovasi teknis, pendekatan baru terhadap manajemen juga dapat memberikan efek seperti itu.


Jadi, kami mendapat alat yang jelas menunjukkan perbaikan mana yang berhasil dan mana yang tidak.

Perencanaan bisnis, tugas mendesak dan tidak berguna

Perencanaan pengembangan bisnis adalah rasa sakit terbesar. Apa yang kita lakukan Setelah menerima tugas dari bisnis, pertemuan diadakan antara analis dan pengembang, di mana mereka membusuk, dan pengembang mengusulkan solusi. Sebagai hasilnya, kami mengerti berapa banyak dan sumber daya apa yang dibutuhkan oleh tugas itu. Dan hanya dengan demikian bisnis tanpa partisipasi kami membuat rencana dan mempertimbangkan seberapa banyak kami dapat merilis fitur. Di Kanban, ini disebut irama pengisian .

Secara relatif, kami mengalokasikan slot dengan ukuran tertentu, sesuai dengan batas WIP, tempat Anda dapat melakukan tugas. Setiap slot hanya memiliki sedikit tugas. Dengan cara lain, metode ini disebut "perencanaan cangkir".



Kami membuat alat sederhana untuk bisnis (sebuah tabel di Excel), yang dapat direncanakan secara visual. Para manajer bertempur di antara mereka sendiri, berargumen tugas siapa yang lebih penting, dan kemudian mereka mendatangi kami dan memberikan tugas untuk pengembangan.

Karena kami sudah memiliki batasan, bisnis lebih memperhatikan pilihan tugas, memilih yang paling penting, dan tidak membanjiri kami dengan omong kosong apa pun yang terjadi pada mereka. Dan satu lagi kelebihan besar: mereka memilih tugas sendiri tanpa partisipasi kami, tanpa mengganggu pengembang untuk rapat, mereka bekerja dengan tenang dan tidak menghabiskan waktu untuk rapat.

Kami juga mengalihkan perhatian ke masalah tugas mendesak. Mereka mulai menganalisis statistik tentang mereka dan menyadari bahwa tugas-tugas ini tidak begitu mendesak. Sebagai contoh, kita perlu promosi untuk perubahan musim musiman dari pengendara. Kita tahu bahwa ini selalu terjadi 2 kali setahun. Setelah itu diulang, mari kita memesan slot untuk tugas-tugas tersebut di papan terlebih dahulu. Tidak akan ada yang mendesak - kami akan mengambil tugas lain dari antrian, kami tidak akan tetap tanpa pekerjaan. Sebagai hasilnya, kami menemukan bahwa 60% dari tugas yang mendesak sebenarnya tidak mendesak.

Ada masalah lain. Kami sering melihat fitur, yang akhirnya mematikan bisnis, karena ternyata tidak berguna dari sudut pandang bisnis. Kami menyarankan agar bisnis melakukan fitur MVP yang memerlukan waktu beberapa kali lebih sedikit daripada pengembangan konvensional. Umpan balik mulai dihapus lebih cepat, dan insinyur mulai menyadari bahwa ini adalah eksperimen. Sebelumnya, ketika minggu kerja dibuang ke tempat sampah, mereka khawatir, itu meracuni hidup mereka.

Kami mulai menguji 85% fitur sedemikian rupa sehingga pada akhirnya kami membebaskan banyak waktu, yang kemudian kami habiskan untuk hipotesis yang diuji dalam praktik. Mereka sudah membawa uang perusahaan. Juga, jika terjadi kesalahan dalam proses, pelanggan fitur dari bisnis dapat melakukan koreksi pada tahap awal, dan tidak melalui seluruh siklus pengembangan.

Akibatnya, fakta semacam itu ditemukan bahwa tidak semua gagasan berfungsi. Dan karena mereka tidak bekerja, maka jangan lakukan itu. Sejak itu, para pengembang tidak lagi terlibat dalam perburuan monyet, dan melakukan apa yang perusahaan peroleh dengan uang.

Rapat

Perbaikan yang kami perkenalkan saat itu telah membunuh sejumlah pertemuan yang tidak berguna. Diskusi prioritas tidak lebih, karena kami memberikan ini kepada bisnis, kami juga merencanakan tanpa insinyur. Kami juga meninggalkan penggerebekan manajer selama lima menit dengan permintaan "bantuan cepat." Hanya ada pertemuan yang benar-benar diperlukan. Kami juga memperkenalkan aturan bahwa pertemuan sekarang dijadwalkan untuk waktu tertentu sehingga semua orang dapat merencanakan jadwal mereka.

Akibatnya, semua pertemuan tentang boltologi diubah menjadi jenis pertemuan berikut:

• ketika seorang analis ingin membahas masalah tertentu dengan seorang insinyur, misalnya, untuk menemukan solusi atau dekomposisi yang optimal;
• ketika ada sesuatu yang macet di papan tulis. Dalam kasus ini, kami berkumpul dan berjalan di sepanjang papan dari kanan ke kiri, menanyakan insinyur apa yang terjadi, siapa yang bisa membantu. Penting bagi kami untuk beralih dari tugas, dan tidak mencoba menghitung apa yang dilakukan orang;
  
• ketika mereka merencanakan tugas untuk sprint (irama untuk pengisian ulang);
• ketika mereka mengambil fitur;
• Pertemuan antara tim pengembangan, misalnya, ketika membahas format API atau memutuskan acara yang akan dikirim.

Poin utama: kami diundang ke pertemuan hanya orang-orang yang terlibat langsung dalam topik diskusi, dan tidak memanggil pendengar nominee, seperti sebelumnya. Para insinyur secara mendasar telah mengubah sikap mereka terhadap rapat, sebelum mereka tidak menyukainya, tetapi sekarang sebaliknya, mereka tampaknya diperlukan dan berguna bagi mereka.

Motivasi dan keterlibatan tim

Semua yang kami laksanakan: Batas WIP, evaluasi tugas berdasarkan statistik, penolakan tugas yang tidak berguna, dll. Yang dijelaskan di atas, menyebabkan waktu bebas bagi para insinyur. Apa yang akan mereka lakukan sekarang? Kesalahpahaman terbesar adalah bahwa tidak ada yang akan melakukan apa pun. Saya sendiri telah berulang kali mendengar dari orang-orang: "Saya akan refactored kode ini, kalau tidak, kaki iblis akan patah". Ya, pada awalnya insinyur benar-benar cukup tidur dan beristirahat selama 2-3 minggu, lalu apa? Dia duduk tanpa tugas, mulai mendekati rekan-rekannya dengan proposal bantuan, membantu menyelesaikan tugas, lalu keduanya sudah duduk tanpa tugas. "Ayo kirim perbaikan bug" - kolom dengan bug kosong. “Kirim kode yang akan kami refactor” - kode menjadi lebih cepat untuk ditulis, batas WIP dapat ditingkatkan. Kemudian mereka mulai mengimplementasikan CD / CI, menulis basis pengetahuan. Apa yang terjadi Para insinyur mulai melakukan banyak hal berguna, yang tidak dapat dicapai oleh tangan mereka. Ini adalah kecepatan yang diinginkan bisnis, tetapi karena alasan tertentu ia tidak bisa mendapatkannya dari siapa pun. Sebelumnya, insinyur itu marah, dia ingin semua orang berada di belakangnya, dan sekarang paradigma manusia telah berubah menjadi: "Sekarang bagaimana saya bisa membantu Anda?" Jumlah inisiatif telah tumbuh, dan mereka semua berasal dari bawah, bukan dari atas. Dan pada akhirnya, ternyata jauh lebih bermanfaat.

Ringkasan hasil

• Kami dapat menemukan hambatan dalam sistem dan memahami bahwa kami tidak dapat melakukan lebih dari yang kami bisa.
• Mereka berhenti membuang pengembang yang tidak berguna dan meluangkan waktu untuk tugas yang lebih bermanfaat.
• Ketika para insinyur tidak melakukan apa pun, mereka mulai mengevaluasi tugas dengan lebih baik, menyapu bug, mulai mengotomatiskan proses, dan basis pengetahuan muncul.
  
• Para insinyur berhenti stres dan menjadi lebih baik.
• Kami mampu 4 kali mempercepat pelepasan fitur baru melalui peningkatan, optimalisasi kerja (peningkatan batas WIP karena otomatisasi dan peningkatan).
• Kami mendapat statistik untuk bisnis dan pemahaman yang jelas tentang apa dan bagaimana perkembangannya.
• Kami belajar menghemat waktu (penolakan terhadap tugas yang tidak perlu, mulai memikirkan tugas-tugas sebelumnya untuk menghindari faktor-faktor tambahan, dll.).
• Pertemuan dan pertemuan diadakan ketika mereka benar-benar dibutuhkan (menjadi lebih fleksibel).
• Semua orang mulai berpikir lebih, jumlah inisiatif meningkat. Inisiatif yang lahir dalam tim selalu lebih baik daripada yang turun dari atas. Proses itu berlangsung terus-menerus, dan semua orang terlibat di dalamnya.

Kesimpulan

Dalam artikel dan laporan ini, saya ingin menarik perhatian tidak hanya pada alat dan pendekatan yang saya terapkan, tetapi lebih pada aspek yang paling penting, yang sering tidak diperhatikan, tetapi, menurut saya, itu tidak kalah pentingnya. Kami memulai seluruh perestroika ini, karena kami memiliki rasa sakit dan kami ingin menyingkirkannya.

Anda dapat menerapkan sesuatu "di dahi" dengan membaca buku pintar atau mendengarkan laporan tentang metodologi yang fleksibel, sehingga bahkan mungkin untuk mempercepat pengembangan atau produk akan bekerja lebih baik. Tetapi kita sering lupa bahwa orang membuat produk ini, dan semakin baik kita membuat hidup mereka, semakin baik mereka akan membuat produk. Sebagai contoh, saya pergi ke teman-teman dan bertanya: “Dan apa rasa sakitmu? Apa yang salah? ", Sebelum mulai menerapkan sesuatu. Dan hanya berkat pendekatan ini, saya berhasil melakukan apa yang diinginkan bisnis - kecepatan dan kualitas dalam pengembangan.

PS Saya diberitahu tentang satu perusahaan di Eropa, ketika Anda datang ke kantor di sana, mungkin tampak bahwa anarki lengkap berkuasa: pengembang, seperti keju dalam mentega, konsol bermain, tidak ada yang bekerja. Tapi ini hanya pada pandangan pertama, ada suasana yang diciptakan khusus untuk orang-orang sehingga mereka dapat membuat dan meningkatkan. Dalam selang waktu antara tugas untuk hiburan, satu lutut menulis solusi yang kemudian diimplementasikan, dan itu mulai membawa keuntungan bagi perusahaan. Saya berharap bahwa manajemen Rusia kami akan bergerak ke arah ini dalam waktu dekat. Dan jika karena alasan tertentu Anda memiliki sesuatu yang salah, pikirkan apa yang Anda lakukan. Baik, atau lemparkan artikel ini ke bos, tetapi bagaimana jika itu membantu :)