Masalah apa dari pemimpin tim dapat diselesaikan dengan bantuan permainan

Halo semuanya! Nama saya Yevgeny Rtishchev, di Sbertekh saya bekerja sebagai kepala pengembangan sistem TI pada proyek-proyek Unified Frontal System. Pada 24 September, saya berbicara di konferensi Saint Teamlead Conf 2018 di St. Petersburg. Laporan saya adalah tentang permainan yang diadakan di tim, yang sangat meringankan sakit kepala saya sebagai seorang pemimpin, membantu dengan motivasi dan disiplin. Penonton dengan sangat hangat menerima topik tersebut dan mengajukan banyak pertanyaan menarik dan berharga.

Bagiku beberapa poin dalam laporan itu terlewatkan. Karenanya, dalam artikel tersebut, saya memutuskan untuk berbicara lagi tentang percobaan saya dan membagikan hasilnya. Siapa yang belum ke konferensi dan ingin membaca cerita tentang alat alternatif untuk Tinjauan Kinerja cepat, mengelola tim melalui permainan, meningkatkan keterlibatan dalam pengembangan produk, dan bagaimana menggabungkan konsep "gamification" dan birokrasi di perusahaan besar - selamat datang .

Intro

Selanjutnya, akan ada cerita yang konsisten tentang saya menjadi pemimpin tim, masalah sadar dan kesalahan yang dibuat. Saya tidak akan menyembunyikannya - solusinya adalah memperkenalkan permainan tim khusus, jadi jika Anda tidak memiliki keinginan dan minat untuk menghabiskan 10-15 menit dari waktu berharga Anda, Anda dapat melompat ke bagian "Sekarang semua orang menambang MotC" dan membaca langsung tentang esensi permainan, kesalahan perhitungan dalam keseimbangan dan penyesuaian , serta apa yang terjadi.

Masalah dan rasa sakit

Ketika saya datang ke Sberteh, sebuah program internal baru dimulai, dan perlu segera membentuk tim pengembangan seluler. Sebulan setelah saya pergi, manajer saya (yang mempekerjakan saya) berhenti, dan semua tugas dan masalahnya menjadi milik saya. Jujur, sebelum itu saya punya sedikit pengalaman dalam mengelola tim dua orang selama setahun. Sebaliknya, itu seperti pendampingan teknis dan pendampingan pengembang baru. Tim dengan cepat berkembang menjadi 11 orang, saya benar-benar menghindari penulisan kode, mengembangkan arsitektur dan tugas-tugas sulit lainnya. Saya menjadi rentan terhadap emosi dan prinsip-prinsip manajemen saya berhubungan dengan manajemen situasional, dan saya harus melihat lebih jangka panjang, mengembangkan orang-orang dalam tim, mengumpulkan pemimpin baru, merayakan dan mendorong mereka yang menarik dengan baik, dan mengidentifikasi serta menghukum "orang jahat" dan orang-orang malas.

Saya melihat jalan keluar dalam pengenalan elemen-elemen manajemen reguler. Yaitu membutuhkan sistem dengan aturan transparan untuk imbalan dan hukuman. Pada saat yang sama, saya benar-benar tidak ingin mengurangi segalanya
metode biasa, reaksi yang selalu ternyata sebaliknya.



Pertama, saya memutuskan untuk membuat daftar masalah bersyarat, atau lebih tepatnya, hal-hal yang saya inginkan
ingin meningkatkan sebagai tim. Sebagai contoh, saya ingin mereka tidak terlambat untuk bersiap, bersiap untuk itu, mendengarkan satu sama lain dengan hati-hati dan membantu menyelesaikan masalah. Banyak orang tidak suka stand-up atau harian, karena menganggapnya sebagai pemborosan waktu kerja.

Langkah pertama adalah mengubah bahasa yang kami ucapkan pada upacara lincah - kami mulai melakukan penaikan dalam bahasa Inggris. Keputusan berjalan dengan cepat: banyak yang menyiapkan teks sebelumnya, durasinya dikurangi (bahasa Inggris singkat dan semua orang mencoba berkonsentrasi hanya pada esensi).

Dan kemudian saya menyadari bahwa saya perlu bereksperimen

Kami merumuskan bidang masalah

Kecenderungan berpikir sistemik memberi tahu saya bahwa untuk melakukan sesuatu, perlu dirumuskan terlebih dahulu masalah atau, lebih tepatnya, hal-hal yang ingin saya tingkatkan. Lalu saya
menguraikan area utama.

Pemeringkatan anggota tim

Perusahaan kami memiliki serangkaian nilai - ini adalah level tertentu yang memiliki tanggung jawab formal, hak istimewa, dan garpu gaji. Penyelarasan kekuatan yang sebenarnya sering berbeda dari yang formal karena alasan yang jelas: jumlah lowongan dan nilai mereka terbatas, semua orang datang ke tim pada waktu yang berbeda dan dalam kondisi yang berbeda, seseorang menunjukkan pertumbuhan yang kuat dalam waktu singkat, dll. Prosedur peningkatannya rumit, cukup langka dan Anda harus siap untuk itu, mis. secara objektif mencalonkan orang-orang yang pantas mendapatkannya. Dalam prosedur pertama seperti itu, saya sangat keliru: karena sulit bagi saya untuk mengingat semua kelebihan atau kegagalan dari masing-masing lelaki, saya melanjutkan dari pendapat subjektif saya, mungkin di beberapa tempat karena disposisi saya sendiri. Dan ini salah.

Kesalahan dalam situasi seperti itu sangat sulit untuk diperbaiki. Dan saya keliru untuk pertama kalinya (satu menit pengakuan). Tetapi pengalaman negatif adalah guru yang baik. Saya menyadari bahwa kita membutuhkan alat yang jelas - satu indikator sederhana untuk melihat semua pencapaian dan kegagalan seseorang, di bidang apa dia tumbuh. Informasi harus selalu dapat diakses dan relevan, dan boleh saja untuk umum - maka semua anggota tim akan memiliki lebih sedikit pertanyaan dengan perubahan berikutnya.

Bantuan Pengembangan Produk

Ketika saya tiba, perusahaan bekerja sesuai dengan model air terjun - pada kenyataannya, bank adalah pelanggan, dan tim dari Sberbank-Technologies adalah kontraktor internal. Setahun kemudian, perusahaan beralih ke Agile - tim yang besar menjadi terdesentralisasi, fokus pada pengembangan produk mereka sendiri (yang bisa menjadi submodul dari satu besar
sistem). Di pundak pemilik produk dari tim semacam itu, selain manajemen linier dan arsitek layanan (dalam hal produk teknis), ada juga fungsi baru - manajemen produk, mis. pembentukan visinya, peta strategis pengembangan, perincian dan prioritas tugas, serta tanggung jawab atas waktu pelaksanaan.

Dan saya, sebagai pemilik produk, benar-benar ingin anggota tim tidak hanya memenuhi tugas mereka, tetapi juga membantu produk tumbuh, membawa ide-ide baru yang segar, mengambil bagian dari tanggung jawab dan sakit kepala saya. Sebagai contoh, banyak waktu dihabiskan untuk mengumpulkan persyaratan, mengembangkannya dan menguraikannya menjadi tugas logis dan berurutan tertentu. Masalah lain adalah dukungan produk dan komunikasi dengan pengguna. Produk kami adalah perpustakaan internal untuk mengembangkan aplikasi iOS seluler (sudah ada serangkaian artikel tentang Habr tentang ini). Dan konsumen kami adalah tim aplikasi lain. Pada titik tertentu, jumlah pengguna kami mencapai sekitar 120 pengembang, perancang, dan manajer. Dan saya bahkan tidak punya 12 jam sehari untuk berkomunikasi dengan semua orang. Saya benar-benar ingin tim untuk secara aktif membantu dalam hal ini.

Merencanakan akurasi dan penentuan waktu pembunuh

Untuk waktu yang lama, indikator Poin Cerita kami (selanjutnya disebut SP) melonjak kuat dari sprint ke sprint. Setiap kali, situasi yang sama terjadi baik karena cacat kedatangan dari PROM, atau
beberapa tugas super penting yang tidak direncanakan langsung dari pimpinan. Orang-orang itu secara teratur mengeluh dan tidak puas diri mereka sendiri, karena mereka tidak bisa memahami ke mana perginya waktu, apakah tugas yang baru diterima itu lebih penting daripada lari cepat, apa nilai yang akan diberikannya pada produk. Menambahkan kompleksitas dan pendekatan yang diterima secara umum untuk menilai cacat pada 0 SP - Saya selalu menambahkan sprint
sejumlah cacat sehingga mereka dapat ditukar dengan yang kritis yang tiba tepat saat sprint.

Sesuatu yang segar dan baru

Setelah dua tahun bekerja pada satu produk dan pada tim yang sama, orang-orang mulai lelah, mata mereka kehilangan kilau dan penurunan produktivitas.
Solusi yang harus ditemukan adalah menyalakan cahaya lagi dan sedikit
menghibur tim.

Sedikit tentang tim

Saya ingin berbicara lebih banyak tentang tim: pemilik produk, analis (alias Scrum Master) dan 9 pengembang iOS. Apakah Anda mengerti sekarang mengapa saya sangat ingin memahami keseimbangan kekuatan dalam tim yang homogen?



Beberapa data sosial: kami memiliki dua anak perempuan, dan usia peserta adalah pada
berkisar antara 22 hingga 33. Area minat berbeda, tetapi kami mencoba mengaturnya
kegiatan tim umum: permainan papan reguler, acara mini-corporate,
perjalanan bersama ke konferensi, dll.

Sekarang semua orang menambang MotC

Saya selalu memiliki minat besar dalam industri game. Sebagai seorang anak, saya membangun seluruh dunia dari lego-cubes, menggambar permainan papan sederhana di selembar kertas, terbawa oleh 3D Max, lalu saya mulai belajar alat sederhana untuk membuat game komputer - seperti Dark Basic atau Game Factory. Saya menghabiskan banyak waktu di MMO, dan dari hal yang paling aneh - saya membuat versi saya sendiri dari game Diablo 2 di editor peta untuk Warcraft 3 (bahkan menikmati kesuksesan di jaringan lokal kota).

Seperti yang Anda mengerti, sekali lagi saya ingin menciptakan dunia game dan membenamkan
anggota tim dalam tantangan waktu nyata



Game, sendiri, mengandung dasar yang sangat berguna, yaitu: kompetisi, poin dan peringkat, peraturan dan pelanggaran, prestasi tunggal dan tim. Game menginfeksi kegembiraan (yang dalam kasus kami mirip dengan keterlibatan), dan juga mengajarkan kepahitan kekalahan dan sukacita kemenangan.

Satu-satunya yang tersisa adalah memilih pengaturan, membuat mekanika dan aturan, menyeimbangkan keseimbangan, dan juga mengerjakan virality bersyarat.


Bagian terbesar dari laporan saya tentang Saint Teamlead Conf dikhususkan hanya untuk membuat game dan menyelesaikan semua poin yang diperlukan (gameplay, masalah keseimbangan, psikologi 4 jenis pemain, dll.). Saya tidak akan menerjemahkan semua informasi itu ke dalam teks - Saya harap pembaca yang tertarik akan menunggu enam bulan ketika olegbunin membuat entri menjadi publik (atau menulis saya secara pribadi). Anda juga dapat datang untuk mendengarkan konferensi pemimpin tim pada 2 November .

Bagaimana cara mendapatkan MotC?

Singkatnya, Anda bisa mendapatkan koin virtual untuk melakukan tindakan tertentu:
1. Menutup tugas sprint. Ini penting dan perlu didorong, karena inilah yang membawa nilai bisnis. 1 Story Point membawa 1.2 MotC. Mengapa nilainya tidak sama? Ya, itu sederhana: pertama, angka ajaib sudah mengatakan bahwa ada semacam koefisien, dan setelah menunjukkan keberadaannya, Anda selalu dapat mengubahnya dengan hati-hati (untuk menyesuaikan keseimbangan). Plus MotC - integer, mis. itu juga merupakan insentif tambahan untuk menutup sejumlah besar poin cerita. Untuk 3 Anda mendapatkan 3 Motc, dan untuk 5 sudah 6.

2. Koreksi cacat. Karena tidak ada evaluasi dalam SP, jadi biarkan di MotC. Tingkat kekritisan yang berbeda memiliki bobot yang berbeda dalam hal MotC. Tetapi sekali lagi, untuk mendorong koreksi cacat (yang tidak semua pengembang inginkan), satu bug tertutup selalu membawa sejumlah kecil koin, yang dapat dibulatkan ke bawah jika satu cacat lainnya tidak ditutup.

3. Koreksi tugas-tugas non-cetak. Selain cacat, ada tugas mendesak lainnya: server build mogok, tes UI jatuh, tugas penting dan penting tiba dari manajemen, dan banyak lagi. Sekarang, bagi mereka, orang tersebut menerima MotC dan dengan demikian mengkompensasi kekurangan SP dalam sprint.

4. Peringkat dan peringkat. Sudah 4 kategori diciptakan: juara SP, maksimalizer kontribusi (jumlah maksimum MotC), sprint hero, dan penghargaan tim. Prinsip dua yang pertama, saya pikir, harus jelas dari namanya, dengan sisanya - lebih menarik. Pahlawan sprint dipilih oleh tim yang memilih secara retro, dan ini adalah salah satu penghargaan paling terhormat dalam tim baik dalam hal jumlah Mot dan dalam hal prestise dan signifikansi. Kehadiran penghargaan tim adalah kunci karena Ini menunjukkan bahwa tidak hanya hasil pribadi yang penting, tetapi juga hasil keseluruhan dari seluruh tim. Tiga gradasi diciptakan: sprint reguler, sprint teratas dan sprint gagal. Sprint dianggap normal, jika lebih dari 78% dari sprint backlog ditutup, jika 100%, maka ini adalah sprint teratas. Dalam hal sprint top, seluruh tim menerima peningkatan yang murah hati. Tapi ada sisi lain dari koin - ini adalah sprint yang gagal.

Menambang Motive Negatif

Masalah MotCs. Karena itu, dimungkinkan untuk mendapatkan koin dengan nilai negatif. Apa yang menyebabkan anti-jasa:

1. Sprint gagal. Dalam hal melakukan kurang dari 78% dari sprint backlog, seluruh tim menerima penambangan negatif.
2. Membuka cacat. Jika ada cacat tegas dalam tugas infus, maka MotC negatif diperoleh oleh pengembang yang menyuntikkan Permintaan Tarik, serta pengulasnya.
3. 3. Sistem tambahan yang didanai juga ditemukan karena terlambat untuk berdiri atau tidak memperhatikan rekan kerja. Dia bertindak berdasarkan prinsip "3 berturut-turut." 3 ikon identik runtuh menjadi yang baru, di mana ada penambangan negatif. Ada aturan amnesti: ketika menerima lebih dari 25 MotC dalam sprint, keruntuhan itu tidak mengarah ke penambangan negatif, tetapi lencana tidak diatur ulang.

Bagaimana cara membelanjakan MotC?

Ya, ya Makna koin tidak hanya dalam peringkat pribadi, tetapi juga dalam kenyataan bahwa mereka dapat dibelanjakan. Untuk ini, fungsi aktivasi diciptakan. Hanya koin positif yang dapat diaktifkan. Ada seluruh toko di mana ada barang dan nilainya. Untuk kontrol, jumlah mereka terbatas.

Apa yang ada di toko?

1. Kemampuan untuk meninggalkan pekerjaan lebih awal atau kembali lagi nanti. Hodovichok paling penting.
2. Hari kerja jarak jauh.
3. Kemungkinan pemilihan tugas prioritas pada perencanaan.
4. Rekomendasi LinkedIn.
5. Memilih modul untuk pengembangan di Swift. Semua kode ada di Objective-C, dan orang-orang ingin sekali mengembangkan di Swift.
6. Tiket konferensi (jika tersedia).

Ada posisi lain, tetapi di sini aturan yang paling penting adalah untuk menjamin kemungkinan pembelian mereka, jika tidak, kepercayaan akan dirusak.

Koreksi selama pertandingan

Selama percobaan, pada titik-titik tertentu, masalah keseimbangan utama menjadi nyata.
Yang mana

1. Pemain model peran. Selain para pengembang, ada satu analis di tim, dan kemampuannya untuk mendapatkan MotC sangat terbatas, karena bagian terbesar dari tugas untuk titik penyimpanan dipertajam untuk pengembangan. Juga, fungsi analis termasuk bagian dari tugas administrasi, yang mahal untuk terus dipantau. Solusinya adalah memperkenalkan konsep "penambangan istimewa", yaitu. sejumlah MotC secara otomatis dikreditkan untuk memenuhi tugas sehari-hari. Sangat menarik bahwa di masa depan ketidakseimbangan lain ditemukan: dengan tidak adanya analis (misalnya, liburan), seseorang mengambil alih tugasnya dan, dengan demikian, mengambil bagian dari produksi untuk penambangan istimewa.

2. Penyusutan tugas. Seiring waktu, tugas berulang tertentu menjadi lebih mudah untuk diselesaikan. Sebagai contoh, kami memiliki prosedur untuk merilis versi baru kerangka kerja (produk kami) - yang memakan waktu murni sekitar 1,5-2 jam. Dengan perkembangan DevOps, waktu yang dihabiskan berkurang menjadi 30 menit. Sejalan dengan itu, remunerasi di MotC juga telah turun. Atau secara berkala ada tugas untuk menyiapkan bentuk laporan atau status baru. Sulit untuk melakukan ini untuk pertama kalinya, tetapi lebih mudah untuk mengulanginya - karena itu, estimasi dalam koin menurun. Tim memahami penyesuaian semacam itu dengan tepat.

3. Poin ganda untuk cacat. Contoh untuk menunjukkan bahwa di setiap tim akan ada situasi yang tidak terduga, dan aturan harus "disetel." Kami duduk di penggabungan kaskade otomatis untuk waktu yang lama (mis., Ketika menyuntikkan perbaikan terbaru, penggabungan otomatis muncul di versi rilis sebelumnya dan dikembangkan). Pada titik tertentu, kami memutuskan untuk menghentikan praktik ganas ini karena terus-menerus menggantung konflik penggabungan pada pengembangan-e dan beralih ke gagasan tugas duplikat untuk semua versi di mana Anda ingin mengunggah perubahan. Hal ini menyebabkan munculnya beberapa tugas serupa di JIRA:



Hasilnya, secara resmi sesuai aturan, pemain dapat dengan cepat mengambil dan menyelesaikan 2-3 tugas dan mendapatkan 2-3x koin. Saya harus memperkenalkan koreksi untuk tugas-tugas seperti itu, karena kompleksitasnya menurun (tetapi tentu saja tidak sampai nol karena potensi konflik karena perubahan dalam cabang individu).

4. Gagasan menghargai untuk bekerja dengan pengguna. Saya benar-benar ingin "memaksa" orang-orang untuk membantu konsumen kami (dan ini adalah sekitar 100 pengembang aplikasi, penuh dengan pertanyaan bodoh dan berulang-ulang). Kami mencoba berbagai pendekatan: menunjuk petugas, memelihara basis pengetahuan yang terperinci, menumbuhkan komunitas pengguna ahli dan mendorong mereka. Tetapi solusi sederhana muncul: 1 kali sehari saya dengan cepat melihat melalui obrolan dukungan di Slack dan memberi konsultan kecil yang paling aktif dari tim hadiah kecil tetapi menyenangkan dalam bentuk MotC. Guys dinilai

Secara umum, permainan adalah proses hidup yang harus berubah di sepanjang jalan. Hal utama adalah memastikan diri Anda dari awal dan membiarkan diri Anda kesempatan untuk melakukan manuver organik. Mengubah mekanisme permainan dapat menyebabkan kebencian di antara para pemain. Awalnya, saya takut bahwa saya tidak dapat menghitung dengan benar keseimbangan antara penambangan dan biaya "hadiah" - jadi saya segera menunjukkan bahwa jumlah mereka di toko terbatas dan akan diisi ulang sebanyak mungkin. Plus, seperti yang Anda tahu, pasar pasokan dikendalikan oleh monopoli, yang selalu dapat menyatakan defisit atau inflasi!

Hasil dan Pengamatan

Seluruh percobaan berlangsung 9 sprint (4 bulan). Sebanyak 968 MotC dihabiskan, dan 262 dihabiskan. Ada 3 sprint teratas, orang yang sama menjadi pahlawan sprint 4 kali, distribusi MotC pada tim terlihat seperti ini:

	MotC	MotC +
Pemain 1	104	86
Player 2	203	203
Pemain 3	148	128
Pemain 4	65	47
Pemain 5	172	92
Pemain 6	58	40
Pemain 7	68	68
Pemain 8	95	77
Pemain 9	55	55

Ini dia - satu-satunya indikator yang ingin saya buat.

Omong-omong, seluruh basis data disimpan dalam Angka (xls untuk MacOS) dan dikirim ke peserta seminggu sekali (pada saat mengeluarkan MotC untuk retro). Ada 5 halaman dengan rumus lintas sektoral: riwayat penambangan, riwayat pembelian, toko penawaran, detail penambangan, dan tabel ringkasan.

Saya ditanya pertanyaan di konferensi - tidak butuh banyak waktu untuk melakukannya.
Jawabannya adalah tidak. Sebaliknya, saya mulai menghabiskan lebih sedikit waktu untuk menyiapkan tugas di JIRA di
setiap hal kecil dan untuk menyinkronkan dengan notebook di mana saya secara teratur menulis
semua tugas yang didelegasikan. Tabel yang disebut "Detailing" itu adil
jenis baru notebook di mana saya bisa menuliskan instruksi, dan ketika mereka dieksekusi
catat hadiahnya. Di bawah ini adalah contoh dari satu sprint per pemain:

MotC	Penambangan
1	Proposal untuk Masalah X
1	Bantu Makov dengan memperbarui ikon perpustakaan untuk demo
2	Mempersiapkan repositori dengan boilerplate untuk IP (demo untuk manual)
2	Mempersiapkan skema XSD untuk contoh IP, serta konsultasi boilerplate
3	Penutupan yang rusak
16	Konversi 14 SP
4	Maximizer SP

Ketika percobaan berakhir, saya bertanya kepada teman-teman - semua orang senang dengan inovasi dan mengkonfirmasi bahwa itu segar dan menarik.


Hasilnya adalah situasi Menang-Menang. Menjadi lebih mudah bagi saya untuk mengelola pengembangan, orang-orang memiliki peluang baru dan semangat tantangan. Beberapa pria telah menemukan sendiri cara-cara baru pengembangan dan cara-cara menguntungkan produk. Pada saat yang sama, seluruh tim bersama-sama mencoba untuk mendapatkan hasil teratas pada akhir sprint.

Saya tidak mencoba membuktikan bahwa ini adalah opsi manajemen yang tepat atau alat yang ideal - ini hanyalah contoh bagaimana mendiversifikasi gaya manajemen saya dan dengan cara yang baik "menghibur" tim. , , , . Performance Review .

!

PS Facebook LinkedIn , - 2 .