🔭 🥇 🤚🏼 “Apa yang harus dilakukan ketika perubahan dramatis dalam proses mendemotivasi tim.” Pengalaman insinyur backend yang menjadi pemimpin tim 💈 🕧 🧓🏼

Selama 7 tahun saya bekerja sebagai insinyur backend di Miro, kemudian menjadi pemimpin tim. Selama beberapa tahun terakhir, tim teknik kami telah berlipat ganda, menjadi terdistribusi dan internasional, yang memerlukan banyak perubahan.

Salah satunya adalah pengenalan tim lintas fungsi yang dapat menyelesaikan masalah sepenuhnya, mulai dari mengembangkan ide hingga merilis fitur. Untuk ini, para insinyur backend dan frontend harus cepat belajar banyak dari apa yang belum pernah kami lakukan sebelumnya: menguji, bekerja dengan rilis, melakukan ritual scrum - tanpa kehilangan kecepatan dan kualitas.

Langkah-langkah pertama ke arah ini menyebabkan peningkatan jumlah kesalahan, penurunan kecepatan pengembangan dan penurunan motivasi tim. Selama periode yang sulit ini, saya hanya menjadi pemimpin tim, jadi ketakutan pribadi saya akan kegagalan dan ketidakmampuan saya sendiri menambah tekanan umum.

Sebagai hasilnya, kami menghadapi badai, membagi waktu menjadi dua dan secara signifikan maju dalam efektivitas tim lintas fungsi. Ini sebagian besar dibantu oleh perubahan sikap kami terhadap perubahan yang sedang berlangsung, transisi dari mindset tetap ke mindset pertumbuhan.

Di bawah ini adalah video dan transkrip kinerja saya di Saint TeamLead Conf 2019, di mana, menggunakan tim saya sebagai contoh, saya berbicara tentang proses dan alat yang memungkinkan perubahan ini.

Sejarah No. 1. Mengubah proses pengembangan untuk mengurangi lead time

Pada 2016, pengembangan kami terdiri dari 20 orang dan 5 tim. Tim berinteraksi secara efektif satu sama lain, dengan cepat bertukar informasi dan pengalaman. Dengan pertumbuhan karyawan dan tim, pengenalan proses CI / CD dan tinjauan kode, jumlah saling ketergantungan antar tim meningkat.

Misalnya, untuk meluncurkan fitur besar pada prod, tim perlu bekerja dengan 6 tim teknik lainnya:

Berikan kode untuk meninjau kode.
Berikan fitur pada tes QA. Jika perlu, QA akan menyertakan perintah DevOps untuk membuat lingkungan pengujian khusus.
Meringankan fitur menggunakan manajer rilis, yang bertanggung jawab atas semua rilis di perusahaan.
Hubungkan perintah tambahan jika terjadi kesalahan selama rilis.

Dan ini tanpa memperhitungkan ketergantungan dengan tim pemasaran, desain dan dukungan teknis, yang juga secara aktif terlibat dalam peluncuran fitur.

Semakin banyak dependensi, semakin banyak Waktu Timbal, yaitu waktu dari awal pengembangan hingga rilis. Semakin tinggi Lead Time, semakin sedikit nilai yang kami berikan kepada pengguna.

Sejumlah besar komunikasi dan kecepatan pengiriman yang rendah mendemotivasi tim. Apa yang harus dilakukan? Mengurangi ketergantungan dan mempersingkat waktu tunggu.

Kami mencoba membangun konveyor dalam pengembangan

Untuk mengatasi masalah ini, pertama-tama kami mencoba membuat konveyor:

Jelaskan semua tahapan dan proses;
memperkenalkan SLA (Perjanjian Tingkat Layanan, tingkat kualitas yang diperlukan) untuk menentukan waktu tugas harus melalui setiap tahap;
luruskan arus untuk mencegah tugas mundur ke tahap sebelumnya untuk perbaikan.

Sayangnya, pipa tidak bekerja: kesalahan pada tahap apa pun menyebabkan penangguhan seluruh rantai, sementara masing-masing tim secara bersamaan dipaksa untuk menyelesaikan masalah dari simpanannya sendiri. Misalnya, QA perlu memilih: untuk menangani bug di saluran pipa atau untuk terlibat dalam tugas-tugas untuk meningkatkan proses pengujian. Masalah penentuan prioritas ini mengarah pada fakta bahwa kami merilis fitur, tetapi tidak berhasil memperbaiki proses internal, atau terlibat dalam optimasi proses dan tidak punya waktu untuk merilis fitur.

Kemudian kami memutuskan untuk membangun kembali conveyor untuk memindahkannya ke dalam masing-masing tim.

Mencoba membangun tim lintas fungsi

Tim lintas fungsi dapat menangani tugas dari awal hingga akhir: mulai dari menyusun ide hingga menempatkan fitur yang sudah jadi pada produk. Untuk ini, tim perlu memiliki semua kompetensi, pengetahuan, dan proses yang diperlukan.

Kami memutuskan untuk melakukan percobaan pada beberapa tim sebelum meluncurkan perubahan ke seluruh perusahaan. Tim saya juga masuk ke dalam eksperimen, yang terutama berhubungan dengan tugas-tugas tingkat rendah (saya menulis tentang salah satu contoh pekerjaan kami - mengimplementasikan ActiveMQ dan Hazelcast). Tim terdiri dari 3 pengembang backend, seorang insinyur QA paruh waktu dan saya sebagai pemimpin tim.

Kami menentukan saling ketergantungan

Pertama-tama, kami menentukan dependensi saat ini yang ingin kami singkirkan:

Tidak ada insinyur QA penuh-waktu, yang karenanya kami dapat menunggu pengujian dari beberapa hari hingga seminggu.
, -.
full-time -, , .

Ada dependensi lain, tetapi kami memutuskan untuk fokus terutama pada ketiganya. Sekarang kami perlu belajar banyak dari apa yang dilakukan insinyur QA, master Scrum, dan manajer rilis sebelumnya.

Kami belajar untuk menguji secara mandiri.
Sebelumnya, para insinyur secara independen menulis unit test dan menguji fungsi dasar, sisanya memeriksa QA. Sekarang kami telah belajar bagaimana menguji situasi perbatasan secara independen dan menulis tes ujung ke ujung untuk menguji interaksi antara klien dan server.

Belajar melepaskan diri Anda
Kami sepakat bahwa kami ingin merilis setidaknya seminggu sekali. Untuk melakukan ini, kita memerlukan manajer rilis di dalam tim. Salah satu pengembang backend menjadi atas kemauan mereka sendiri.

Kami melakukan ritual scrum sendiri
Master scrum eksternal tidak punya waktu untuk berurusan dengan semua tim, jadi di dalam tim kami kami memilih orang yang menginginkan peran ini. Dia perlu belajar bagaimana secara mandiri melakukan perencanaan, perawatan, dan retro.

Tentu, tidak ada yang melempar kami ke barikade. QA, manajer rilis dan master scrum memberikan pengetahuan dan disarankan dalam kasus-kasus sulit.

Kegagalan pertama

Hasil dari sprint pertama tidak berhasil. Kami benar-benar mulai membawa tugas ke cabang master jauh lebih cepat, tetapi kami tidak dapat secara independen membuat satu rilis. Ternyata proses dan skrip kami tidak siap untuk ini. Skrip rilis hanya dapat merilis semua layanan sekaligus, sehingga kami tidak dapat merilis bagian dari layanan kami secara terpisah.

Kami memutar bagian dari proses dan pada akhir sprint kedua kami menempatkan tugas dari sprint pertama ke dalam rilis. Namun, ada yang salah lagi. Setengah dari fungsionalitas yang dirilis berisi bug kritis, jadi kami memutuskan untuk memutar kembali rilis. Dan mereka menghadapi masalah baru: pengembang backend kami dan manajer rilis paruh waktu di tim, belajar untuk rilis, tetapi masih tidak belajar untuk mengembalikan perubahan. Oleh karena itu, kami memerlukan bantuan manajer rilis eksternal.

Semua ini mengarah pada penurunan motivasi tim: kami gagal dalam sprint kedua berturut-turut, melepaskan fungsionalitas dengan bug penting - perasaan bahwa kami tidak dapat melakukan apa-apa sendiri.

Sejarah No. 2. Peran Baru dan Ketakutan akan Kesalahan

Pada awal percobaan dengan tim lintas fungsi, Max, salah satu insinyur backend, mengajukan diri untuk menjadi master scrum. Namun, setelah sprint pertama, dia mendatangi saya dan mengatakan bahwa dia tidak lagi ingin menjadi master scrum. Mengikuti Max datang Andrei, insinyur lain, dan mengatakan bahwa dia tidak akan menguji: "Saya seorang pengembang, bukan tester." Sebagai pemimpin tim, penting bagi saya untuk memahami penyebab kedua kegagalan tersebut.

Sebagai aturan, salah satu dari 4 alasan yang dapat bekerja dengan masing-masing dari mereka adalah landasan keputusan untuk meninggalkan tugas:

   → , , .
(, , ) → , .
  , → : , .
   → .

Max memahami nilai yang dibawa oleh scrum master ke tim, tetapi takut untuk tidak mengatasi tugas-tugas sulit memfasilitasi pertemuan. Menyetujui peran baru, dia hanya tahu sedikit tentang pekerjaan master scrum dan tidak memberi dirinya akun lengkap keterampilan yang akan dia butuhkan untuk ini. Max takut dia tidak bisa mengatasinya, dia akan membuang waktu tim dan akan terlihat tidak kompeten di mata rekan-rekannya.

Dalam situasi dengan Andrei, ternyata dia menguji kodenya sendiri dan yakin semuanya baik-baik saja. Namun, untuk berjaga-jaga, saya memberikan QA untuk verifikasi, dan dia menemukan 5 bug dalam kode. Ini diulangi beberapa kali, yang menurunkan semangat Andrei, dan dia memutuskan untuk tidak melakukan pengujian lagi.

Saya sangat mengenal situasi Max dan Andrei. Saya sendiri baru-baru ini berubah dari seorang insinyur backend yang berpengalaman menjadi pemimpin tim yang tidak berpengalaman. Dan sama seperti saya takut bahwa saya tidak dapat mengatasi tugas-tugas, saya tidak akan memenuhi harapan dan, secara umum, kepemimpinan tim bukan milik saya.

Instalasi pada pertumbuhan dan instalasi diberikan

Ketika saya menjadi pemimpin tim, saya disarankan untuk membaca buku " Fleksibel Kesadaran " oleh profesor Universitas Stanford Carol Dweck . Singkatnya, ini menggambarkan dua jenis pemikiran:

Fixed mindset - keyakinan bahwa kecerdasan dan kemampuan ditetapkan sekali dan untuk semua, tidak mungkin untuk memengaruhi mereka, dan kegagalan menunjukkan kurangnya bakat. Orang dengan pemikiran seperti itu berusaha untuk tidak mengambil tugas yang rumit agar tidak kehilangan motivasi dan kepercayaan pada diri mereka sendiri.
Mindset berkembang adalah keyakinan bahwa kecerdasan dan kemampuan dapat ditingkatkan sepanjang hidup jika upaya dilakukan untuk melakukannya. Kegagalan adalah alasan untuk mempelajari sesuatu, sehingga orang-orang dengan pemikiran seperti ini terus-menerus berusaha keluar dari zona nyaman mereka dan melakukan tugas-tugas kompleks.

Secara alami, dunia tidak terbagi menjadi hitam dan putih, dalam situasi yang berbeda orang yang sama dapat didominasi oleh jenis pemikiran yang berbeda. Misalnya, seseorang dapat menganggap bahwa pemrograman adalah keterampilan yang dapat dipelajari oleh siapa pun, tetapi pada saat yang sama ia percaya bahwa memasak dengan nikmat adalah bakat yang melekat di alam, dan ini tidak dapat dipelajari.

Seluruh skema ada di situs web Carol Duque.

Pendekatan ini menggambarkan sikap seseorang terhadap perubahan yang terjadi.

Orang-orang dengan dominasi Pola pikir tetap (ditetapkan untuk diberikan)
: « , ».
, . , , .

Growth mindset ( )

, , .
, .
, .

Pendekatan ini telah membantu saya mengubah sikap terhadap kesalahan. Oleh karena itu, saya memutuskan untuk berbicara tentang pendekatan kepada tim, karena itu dapat memberi kita sistem koordinat tunggal, mengajarkan kita untuk memperlakukan perubahan secara berbeda dan mengurangi rasa takut akan kesalahan. Seperti alat apa pun, orientasi pertumbuhan berfungsi untuk memecahkan masalah tertentu, jadi saya membicarakannya pada pertemuan 1: 1 untuk memberi semua orang informasi yang akan berguna baginya secara khusus untuk menyelesaikan situasinya.

Selain itu, saya memberi tahu semua orang di tim tentang contoh saya sendiri bekerja dengan pengaturan pada saat perubahan peran dari insinyur menjadi pemimpin tim. Ini menambah kepercayaan diri lainnya ("Saya bukan satu-satunya yang menghadapi ini", "situasi ini benar-benar dapat diubah").

Kelanjutan cerita nomor 2

Eksperimen mengurangi harapan dan stres. Setelah membahas pendekatan dengan mindset Pertumbuhan & Tetap, kami sepakat dengan Max untuk meluncurkan percobaan di mana ia akan mencoba peran baru sebagai scrum master. Kata "percobaan" dengan baik mengurangi tingkat stres. Dalam percobaan, itu tidak menakutkan untuk membuat kesalahan, tetapi penting untuk melakukan kesalahan dan membuat pengalaman yang berguna. Dalam nada yang sama, kami berbicara tentang peran baru Max kepada tim, yang menurunkan harapan tim.

Bakat adalah pengalaman yang didapat.Andrei, ketika membahas penolakannya untuk menguji, menjatuhkan frasa: "Saya berbakat dalam pemrograman." Ternyata Andrei menganggap pemrograman dan pengujian sebagai bakat bawaan. Dia memiliki yang pertama, tetapi bukan yang kedua. Kami mulai membahas pengalaman Andrei dan menyadari bahwa Andrei menjalani pemrograman melalui malam tanpa tidur untuk mencari kesalahan, berhari-hari terbenam dalam proyek orang lain, secara mandiri menulis puluhan ribu baris kode. Ternyata keahliannya dalam pemrograman bukan bakat, tetapi pengalaman yang ia pergi untuk waktu yang lama dan sengaja. Hanya dengan mempelajari sesuatu, kita sering lupa tentang langkah pertama yang diambil dalam arah ini.

OKR pribadi.Agar kemajuan kami terlihat bahkan dengan sedikit kemajuan, kami sepakat dengan tim bahwa kami akan melacak kemajuan setiap pelatihan. Ini akan membantu tidak hanya untuk melihat jalan yang dilalui, tetapi juga untuk memahami berapa banyak lagi yang Anda butuhkan untuk mencapai tujuan yang dimaksud.

Di tingkat perusahaan, kami memiliki OKR, jadi kami memutuskan untuk menerapkannya pada tingkat pelatihan pribadi. Syaratnya adalah sebagai berikut:

Kami menambahkan ke OKR pribadi hanya apa yang membantu dalam pekerjaan saat ini;
Hasil-hasil utama harus dapat diukur pada waktu tertentu dan membantu menjawab pertanyaan “Seberapa jauh saya mengalami kemajuan dibandingkan dengan minggu lalu?;
Setiap hasil utama memiliki daftar inisiatif yang memungkinkannya untuk dicapai;
(, ), , ;
OKRs 1:1.

Menerapkan OKR pribadi untuk kuartal ini
Beberapa minggu setelah peluncuran inisiatif, kami menyadari bahwa tidak ada yang terjadi. Ternyata kami berdiri di atas penggaruk kami sendiri - melebih-lebihkan harapan kami sendiri. Tim khawatir bahwa perlu untuk membuat OKR yang ideal untuk waktu yang lama dan ini adalah hal yang bodoh.

Kemudian kami sepakat bahwa kami akan menganggap ini sebagai salah satu iterasi. OKR selalu dapat ditinjau dan disempurnakan, ini bukan sesuatu yang diukir menjadi batu, melainkan hanya arah yang ingin Anda kembangkan. Ini membantu memahami inisiatif sebagai permainan yang menarik, dan banyak hal berjalan.

Contoh OKR oleh Andrey

Bonus, kami sepakat untuk membagikan OKR pribadi dalam tim. Ini membantu untuk saling belajar dan bekerja seperti komitmen publik.

Kelanjutan dari cerita nomor 1

Berkat perubahan sikap, dalam retrospeksi kami mulai mencari penyebab kesulitan dalam diri kita, dan bukan di luar. Sekarang tidak ada alasan yang bisa terdengar lebih awal: "Jadi prosesnya sudah dibangun, apa yang bisa saya lakukan." Kami mulai memperbaiki proses yang tidak cocok untuk kami. Tim merasa memiliki proses yang sedang berlangsung.

Ini memungkinkan kami untuk mulai mengimplementasikan sejumlah tugas dengan stabil. Meskipun itu setengah dari sebelumnya, tetapi kami membawanya untuk dijual sepenuhnya secara mandiri dan tanpa bug.

Semua ini menambah kepercayaan diri kita. Setelah beberapa waktu, Andrey secara mandiri mengotomatiskan kasus uji yang rumit. Roma, yang bertanggung jawab atas rilis, mengoptimalkan proses sehingga setiap anggota tim sekarang dapat merilis secara mandiri.

Hasilnya, berdasarkan hasil kuartal, kami dapat mengurangi Waktu Timbal sebanyak 2 kali karena pengurangan ketergantungan, peningkatan kompetensi dalam tim dan perubahan sikap terhadap kesulitan dan kesalahan.

Produktivitas kita dipengaruhi tidak hanya oleh pengetahuan dan keterampilan yang kita miliki sekarang, tetapi juga oleh bagaimana kita berhubungan dengan perubahan dalam perusahaan. Terkadang proses baru dapat menurunkan motivasi, dan tugas yang terlalu kompleks dapat merusak kepercayaan diri. Tetapi dengan ini, Anda dapat bekerja untuk diri sendiri dan di tingkat seluruh tim.

Tim saya dibantu untuk mengatasi perubahan dan sikap terhadap kesalahan mindset berkembang & Tetap. Kami memperlakukannya sebagai alat kerja yang memecahkan masalah tertentu. Tentu saja, instalasi tidak berubah dalam beberapa minggu dan bulan. Tetapi mengubah sikap ke situasi tertentu, kami dapat bergerak maju secara signifikan di kuartal tersebut sehubungan dengan tugas dan kesulitan pekerjaan sehari-hari.

“Apa yang harus dilakukan ketika perubahan dramatis dalam proses mendemotivasi tim.” Pengalaman insinyur backend yang menjadi pemimpin tim