Sendiri di lapangan bukan seorang pejuang. Jalan menuju kerja tim yang efektif

Sebuah tim adalah sekelompok orang yang bergerak bersama menuju tujuan bersama, mendistribusikan tugas dan tanggung jawab untuk hasil tertentu di antara mereka sendiri. Tim diciptakan untuk menyelesaikan tugas-tugas yang tidak dapat diselesaikan oleh satu orang. Tim yang efektif mencapai tujuan dalam waktu sesingkat mungkin dengan biaya minimal.

Kumpulkan beberapa orang dan katakan: "Sekarang Anda adalah sebuah tim, kami sedang menunggu hasil dari Anda", itu tidak akan berhasil. Orang-orang perlu mengatur, memberi mereka tujuan yang waras, motivasi dan menyelesaikan masalah.



Hanya tentang decoding ini dari laporan Evgeny Fedoreev di TeamLead Conf . Dalam laporan itu, Eugene menjelaskan secara bertahap proses pengorganisasian tim pengembangan yang efektif di Banki.ru: merekrut, berkomunikasi, berbagi pengetahuan dan mengembangkan pengembang dan penguji di dalam tim dan departemen.


Tentang pembicara : Evgeny Fedoreev ( hardj ) telah terlibat dalam pengembangan web selama 15 tahun, 6 di antaranya dalam posisi pemimpin tim, dan sekarang ia memimpin pengembangan proyek baru di Banki.ru.

Apa itu Banki.ru?

Konteks perusahaan adalah untuk mengetahui pengalaman mana yang akan dibahas. Banki.ru adalah portal keuangan independen terbesar dari Runet dengan pemirsa bulanan lebih dari 8 juta pengguna unik.

Departemen TI mempekerjakan 50-70 orang, dibagi menjadi 7 tim pengembangan. Semua pengembangan dilakukan di rumah, tidak ada pengembang jarak jauh, sehingga tidak perlu untuk proses dan metrik yang sesuai.

Tugas utama tim pengembangan

Saat mempersiapkan laporan, saya mengajukan pertanyaan kepada orang:

- Apa tujuan tim pengembangan?
- Berkembang.
- Apa artinya itu? Jika seseorang duduk, refactor, tidak membawa manfaat, tidak menyelesaikan masalah bisnis - apakah ini juga perkembangan?
- ... Perlu dikembangkan secara efektif.

Efisiensi Pengembangan

Konsep efisiensi adalah satu hal untuk manajer, dan yang lain untuk pengembang.

Untuk manajer, pengembangan efektif dapat diprediksi : ketika tanggal rilis fitur atau batas waktu untuk menyelesaikan tugas diketahui untuk melakukan beberapa acara bisnis.

Untuk pengembang, ini berfungsi dengan hutang teknis . Ini adalah salah satu rasa sakit sejak bekerja dengan mereka. hutang, untuk refactoring, untuk koreksi dan peningkatan diberikan sangat sedikit waktu.

Kriteria kinerja berikutnya adalah jumlah minimum bug. Orang bisa menulis bahwa kriterianya adalah tidak adanya bug sama sekali, tetapi kita tahu bahwa ini tidak terjadi. Selain itu, penguji akan tersinggung, karena mereka tidak akan diperlukan.

Tantangan di masa depan . Saya sengaja tidak menulis "arsitektur yang bijaksana." Menggali lebih dalam dan memikirkan arsitektur terlebih dahulu adalah kejahatan, sehingga pembangunan harus disentuh untuk masa depan, tetapi tanpa fanatisme.

Kriteria lain yang dimiliki setiap tim.

Proses pengembangan

Kami mulai membangun proses pengembangan di Banki.ru setelah perusahaan mulai berkembang dan tumbuh. Mitra dan proyek baru muncul, dan 6-9 pengembang backend tidak cukup. Kami sampai pada kesimpulan bahwa kami perlu membangun proses pengembangan dan memformalkannya untuk pekerjaan yang efektif.

Awalnya, kami memiliki 3 tim, masing-masing dengan 3 pengembang backend dan seorang manajer yang bertanggung jawab atas bagian-bagian situs. Pengembang Backend, selain pekerjaan mereka, masih mengeset dan menghubungkan plugin jQuery, karena pada saat itu ada beberapa orang di frontend.



Kami mengambil dua pengembang front-end dan dua penguji lagi untuk hidup tanpa bug dan berpikir bahwa konfigurasi ini sudah cukup.

Di dunia yang ideal, proses pengembangan harus terlihat seperti ini.

• Manajer proyek menjatuhkan tugas ke tim backend dan mereka melaksanakannya.
• Jika diperlukan revisi, mereka mengirim tugas ke tim front-end.
• Setelah perbaikan, frontend memberikannya ke QA.
• Tidak ada bug? - Dalam produksi.

Kami menyarankan bahwa dunia tidak sempurna, dan QA akan mengembalikan tugas, karena bug hadir dalam pengembangan apa pun, dan menambahkan dua panah lagi.



Setelah memperbarui skema, kami memutuskan bahwa semuanya keren dan mulai mengerjakannya - kami melakukan perencanaan sprint, dan tim backend sendiri yang memasukkan tugas ke dalam rencana. Mereka bekerja selama 2 bulan dan menyadari bahwa ada sesuatu yang salah.

Skema kami telah berubah. Tugas melompat seperti bola di ping-pong: dari QA ke depan dan kembali ke pengembang, dan bahkan mencapai manajer.



Panah membutuhkan banyak waktu - proses pengiriman tugas untuk memerangi server terlalu lama. Ini tidak cocok untuk kita. Kami ingin meminimalkan jumlah panah sehingga tugas diselesaikan lebih cepat.

Bagaimana cara mengurangi waktu pengiriman?

Hal pertama yang terlintas dalam benak saya adalah mengajukan pertanyaan tentang mengapa kami mengembalikan tugas ? Mengapa backend, frontend, dan QA memahami masalah secara berbeda? Mengapa pandangannya berbeda? Kami sampai pada kesimpulan bahwa kami menemukan pihak yang bersalah di manajer proyek, bahwa dia tidak sepenuhnya menggambarkan tugas-tugas, dan kami mengatakan kepada PM untuk menjelaskan tugas-tugas lebih lengkap, sehingga semua orang dapat memahami apa yang dimaksud.

Kami memiliki tiga tim perencanaan backend. Kami melibatkan penguji dan pengembang front-end dalam perencanaan , tetapi untuk 3 tim hanya ada 2 pengembang front-end dan 2 penguji. Seringkali mereka tidak berhasil memanggil mereka, karena seseorang harus bekerja.

Kami membagi tugas secara terpisah menjadi frontend dan backend untuk mengirimkannya ke pengembangan secara paralel, menguji lebih cepat dan tidak menunggu seluruh rantai.

Kami mencoba semua solusinya. Akibatnya, waktu berkurang, tapi tetap saja kami tidak bahagia.

Kami pikir apa yang harus dilakukan selanjutnya. Ada banyak perusahaan dan praktik di pasar, dan kami mulai belajar, menonton, menggali, dan sampai ke tim fitur.

Tim fitur

Inilah saat tim memiliki semua orang untuk menyelesaikan tugas:

• pengembang backend.
• pengembang front-end.
• Pengembang QA.

Ada juga koneksi di antara mereka, tugas melompat dan bermain ping-pong, tetapi koneksi jauh lebih pendek dan membutuhkan waktu lebih sedikit. Seluruh tim mengambil bagian dalam perencanaan, dia tertarik pada hasilnya dan membuat satu gambar: apa yang harus dilakukan dan bagaimana menyampaikan tugas ke mode pertempuran dalam waktu singkat.

Pada saat itu, kami beralih ke Agile dan Scrum: kami mengundang pelatih dan pelatih, mengadakan kelas master di perusahaan, dan memulai Scrum klasik - sprint dua minggu, penilaian, perencanaan, dan perawatan. Sekarang tugas masuk ke mode pertempuran lebih cepat, tetapi banyak masalah keluar.

Masalah tim fitur

Saat itu, kami memiliki 6 masalah.

• Faktor bus .
• Perencanaan panjang . Untuk perencanaan, kami menyisihkan setengah hari atau lebih: kami memilah-milah tugas, pergi untuk makan siang, lalu kami mengurutkannya. Ketika perencanaan berakhir, tidak ada yang bisa bekerja dan tidak mau - hari itu hilang.
• Sprint tertutup . Ini adalah rasa sakit yang serius - sebagian besar tugas dalam sprint tidak mencapai kolom “Selesai”.
• Sifat tugas yang berbeda dari tim .
• Munculnya tim baru .
• Pertukaran pengalaman antar tim .

Ada masalah, kami akan menyelesaikannya.

Faktor bus

Awalnya, setiap tim terdiri dari pengembang front-end, penguji, dan tiga pengembang backend. Kami merekrut pengembang front-end tambahan - menggandakan peran .

Memperkenalkan pertemuan mingguan di arahan . Pengembang front-end bertemu secara terpisah setiap minggu dan membahas teknologi baru, pemecahan masalah, dan menyepakati praktik dan pendekatan umum. Penguji juga berkumpul, berunding, memutuskan cara menguji, membahas autotest.

Pengembang front-end memperkenalkan peninjauan kode lintas-perintah , ketika satu pengembang memecahkan masalah dalam satu tim dan memberikannya untuk ditinjau ke tim lain, dan setelah setidaknya dua pernyataan, tugas masuk ke pengujian.

Autotests telah ditambahkan . Ada satu penguji dalam tim dan tidak mungkin untuk menduplikasinya, karena tidak ada tugas untuk jumlah seperti itu. Kami sepakat atas bantuan penguji dari tim lain : dia akan mengurus tugas-tugas tim tetangga dan menggantikan karyawan yang pergi berlibur. Ini sedikit meningkatkan waktu, tetapi tugas diuji.

Perencanaan panjang

Kami menganalisis tugas perencanaan. Pada saat sprint, semua orang bekerja dan berkode, dan pada perencanaan hampir pertama kali mereka membuka tugas dan mencari tahu apa yang harus dilakukan, penguji mengklarifikasi "definisi selesai" untuk memahami cara menguji tugas.

Prosesnya memakan waktu. Kami memutuskan untuk membongkar tugas sebelum perencanaan : kami menyarankan agar pengembang melihat tugas di waktu luang mereka, mengajukan pertanyaan sehingga mereka dapat dipersiapkan untuk perencanaan.

Kami mengundang manajer untuk menjelaskan tugas-tugas secara lebih rinci , tetapi tidak terlalu banyak agar tidak menggali banyak dokumentasi.

Kami sengaja menyisihkan waktu perawatan tambahan dan bukan waktu luang. Mereka berkumpul sebagai satu tim, membahas tugas-tugas, dan bersiap untuk perencanaan.

Sprint Tidak Tertutup

Ini menyakitkan. Mungkin seseorang menutupnya, tetapi bersama kita saat itu - tidak.

Kami memutuskan untuk mengurangi kapasitas sprint dari 10 hari kerja menjadi 8 . Kami berpikir bahwa kami akan merencanakan selama 8 hari, dan meninggalkan penguji selama 2 hari.

Pada kenyataannya, ternyata ketika seorang pengembang melihat lebih sedikit tugas, maka ia melakukannya dengan lambat. 20% lebih sedikit tugas dalam sprint tidak memberikan apa-apa.

Di awal sprint, sementara ada waktu, tester membuat test case. Secara teori, pada awal sprint, saat pengembang bekerja, tester tidak memiliki tugas. Kami sepakat bahwa pada saat ini tester dapat menjalani semua tugas, menyusun kasus pengujian, dan ketika tugas datang untuk pengujian, ia akan menjalankannya pada kasus pengujian yang disiapkan, dan mengurangi waktu untuk pengujian. Secara global, ini tidak membantu, walaupun waktu sedikit berkurang.

Mengurangi kapasitas sprint dan memuat tester tidak membantu, dan kami berpikir bagaimana menyelesaikan masalah. Pada saat itu, sebuah buku tentang tujuan dan beberapa praktik Maxim Dorofeev menarik perhatian kami. Kami menyadari bahwa mendorong "non-pushable" tidak akan berhasil dan mulai merencanakan sprint dari hambatan - dari pengujian . Pada perencanaan, tester membuat penilaian, kapasitas sprint dihitung darinya, dan tugas berlari untuk tester.

Kelas! Kami pergi ke manajer untuk menjual ide ini:

- Kami memutuskan untuk merencanakan dari penguji. Sprint akan ditutup, itu akan keren!
- Tunggu, apa yang akan dilakukan pengembang bebas saat ini? Akan ada lebih sedikit tugas, mereka akan memiliki waktu luang!
- Apakah Anda ingin sprint ditutup, pengembangan dapat diprediksi atau tujuan utama orang untuk mengambil?
- Tidak, ini masih perkembangan yang dapat diprediksi. Mari kita tutup sprint.

Setelah dialog, satu tim mulai bekerja dengan cara baru. Skema ini menunjukkan kemampuan bertahannya, kami mengerjakannya, sprint tertutup dan pengembang punya waktu.

Ternyata pengembang dapat melakukan banyak hal ketika mereka bebas.

Yaitu: bekerja dengan mereka. hutang Tim selalu memiliki teknologi yang sama. hutang ke departemen. Tugas-tugas ini dapat diambil untuk bekerja dan diuji. Sebagai aturan, itu. utang adalah sistem refactoring. Pengujian regresi diperlukan untuk tugas-tugas ini, dan penguji tim seharusnya tidak selalu melakukan ini. Departemen pengujian mengidentifikasi penguji khusus yang melakukan regresi, termasuk kepala departemen pengujian. Tugas untuk itu. hutang diberikan kepada karyawan lain untuk pengujian dan penguji kami tidak menderita.

Pisahkan tugas dari jaminan simpanan dan klarifikasi . Ketika pengembang tidak memiliki tugas, dia melihat tumpukan, menjelaskan persyaratan. Pada saat perencanaan, tugas-tugasnya sepenuhnya dijelaskan, semua pertanyaan diajukan, dan keputusan dibuat. Masih mengklarifikasi detail dan hanya itu - penguji mengevaluasi, dan tugas telah hilang.

Bantu tim lain . Pada saat itu, kami masih berlatih membantu tim lain, di mana saya dalam kesulitan, seseorang berlibur atau jatuh sakit, dan proyek itu terbakar. Tugas pribadi yang terpisah dapat diambil dan dibantu oleh tim lain.

Selain itu, selalu ada cuti, pelatihan, partisipasi dalam konferensi, yang juga perlu waktu untuk mempersiapkan. Ketika seorang karyawan diberi kesempatan untuk mempelajari sesuatu, membaca Habr, menonton video di tempat kerja selama jam kerja, loyalitas meningkat. Kami memecahkan masalah ini, dan semua orang menjadi nyaman.

Sifat tugas yang berbeda untuk tim

Kami memiliki tim produk yang melakukan sesuatu yang baru. Mereka memiliki perencanaan dua minggu, sprint, proyek panjang dan mereka akan dirilis dalam 1-2 bulan atau lebih.

Kami memiliki tim pemasaran yang bekerja lebih reaktif: tugas telah selesai, tugas telah selesai. Katakanlah departemen penjualan menjual pendaratan - Anda harus segera membuatnya. Tim-tim ini awalnya juga bekerja pada Scrum dan sprint dua minggu, tetapi ternyata pada akhir sprint tugasnya benar-benar berbeda daripada di awal. Ketidakpuasan tim, kesibukan terus-menerus, sprint tidak berakhir - situasinya tidak menyenangkan.

Kami memutuskan untuk berbicara dengan PM dan bisnis:

- Guys, kami memiliki Agile, Scrum, sprint, proses - jangan membuang tugas baru, tapi kami akan mengembangkannya dengan mudah.
- Lihat, kami menjual pendaratan, itu perlu dilakukan dalam 3 hari. Kami dibayar satu juta untuk ini. Proses apa? Uang juga harus diperoleh!

Satu juta meyakinkan kami. Kami mulai berpikir lebih jauh.

Kami memutuskan untuk mengurangi sprint hingga seminggu - sehingga kami dapat merespons lebih cepat. Itu juga tidak berhasil, karena merencanakan pada saat itu untuk tim ini tidak bekerja sama sekali.
Kemudian kami memutuskan untuk tidak merencanakan sprint, tetapi untuk mengerjakan Kanban alih-alih Scrum : tugas datang, mulai bekerja, dilepaskan. Itu berhasil. Tim bekerja lebih produktif, karena pada awalnya mengerti bahwa tidak ada perencanaan, tetapi hanya ada tugas yang harus dilakukan.

Untuk meningkatkan proses dalam tim dan menerima umpan balik, kami mulai melakukan retrospektif setiap 2 minggu : tim berkumpul, membahas apa yang berjalan dengan baik, apa yang tidak, apa pro dan kontra, dan bekerja dengannya.

Munculnya tim baru

Pada saat itu, kami mulai tumbuh, tim-tim baru muncul: kami mendapat pemimpin tim, pengembang, tim berkembang, dan orang-orang belum terbiasa satu sama lain. Kami tidak berbicara tentang perencanaan selama periode ini - orang melihat kode kami untuk pertama kalinya, dan itu bisa buruk, misalnya, kami memiliki sedikit bitrix. Sesuatu harus dilakukan dengan ini.

Itu mungkin untuk mengambil Kanban yang sama sehingga pengembang melakukan tugas yang mereka bisa, tetapi ini adalah tim produk, itu perlu diajarkan. Kami memutuskan - biarkan mereka belajar merencanakan dan mengevaluasi tugas, tetapi mengurangi sprint menjadi 1 minggu .

Kami akan menambah waktu menjadi 2 minggu dalam 1-2 bulan, ketika tim terbiasa, memasuki pekerjaan produk umum, akan menetapkan proses dan pengembang akan dapat mengevaluasi tugas secara normal.

Pertukaran pengalaman antar tim

Di dalam tim, pengembang dan penguji berkomunikasi satu sama lain dan bertukar pengalaman, tetapi pengalaman ini tidak diperbarui, karena tim "memasak sendiri." Pengalaman baru tidak datang dari mana.

Kami mulai berpikir apa yang harus dilakukan dengan itu, dan memperkenalkan pertemuan tim mingguan. Tujuan pertemuan adalah untuk mentransfer pengalaman dari satu tim ke tim lainnya melalui pemimpin tim.

Pertemuan pertama adalah sebagai berikut:

- Halo, nama saya Eugene, kami sekarang memotong berita.
- Keren!

Pertemuan selanjutnya:

- Halo, nama saya masih Eugene, kami terus memotong berita.
- Ok

Tidak ada yang luar biasa terjadi.

Pertemuan ketiga: Halo ... Dan semuanya sama.

Kami menyadari bahwa kami perlu mengubah format. Baca buku tentang rapat dan
memperkenalkan agenda tetap.

Sekarang kami memiliki halaman wiki dengan tanggal untuk pertemuan Timlid, di mana kami menguraikan masalah dan tugas untuk diskusi selama seminggu.

Kelebihan dari keputusan ini

• Timlids sedang mempersiapkan pertemuan, karena mereka tahu agenda, dan memahami apa yang akan dibahas.
• Halaman wiki tersedia untuk semua pengembang. Setiap karyawan dapat mempelajari topik diskusi, berpartisipasi dalam proses dan mengajukan pertanyaan mereka. Setelah pertemuan, kami memperbaiki keputusan dalam komentar, yang juga tersedia.
• Jika masalah belum terpecahkan setelah 1-2 bulan, maka Anda dapat melihat di arsip rapat bagaimana diskusi tentang masalah itu diputuskan dan untuk menendang tim atau pimpinan tim karena kegagalan.

Kami menyukai format pertemuan dan kami mulai mengadakannya secara teratur.

Kami memperkenalkan cross-command code-review . Ini adalah semacam pertukaran pengalaman yang sudah dipraktekkan oleh pengembang front-end, dan orang-orang dari backend. Tidak perlu memberikan semua kode ke tinjauan kode lintas-perintah, hanya hal-hal penting yang cukup, misalnya, perpustakaan bersama atau potongan kode umum. Untuk tinjauan kode, kami hanya memilih tim yang berminat, tidak ada persetujuan wajib.
Ada situasi ketika tim tetangga yang berurusan dengan bank meminta untuk memperbaiki fungsionalitas - menambahkan bidang, dan kami berurusan dengan pinjaman. Anda dapat meminta tim lain, tetapi mereka memiliki rencana mereka sendiri dan tidak jelas kapan mereka akan memenuhi permintaan tersebut, tetapi Anda tidak bisa menunggu. Dalam situasi ini, kami membantu tim tetangga, tetapi pada tinjauan kode kami memberikan yang lain.

Kebetulan pengembang diminta untuk pindah ke arah lain atau mengubah teknologi. Sebagai contoh, kami memiliki satu karyawan yang telah berurusan dengan kartu kredit selama setahun dan meminta untuk mengubah area, sementara yang lain ingin mengubah teknologi dari UI ke Symfony. Dengan persetujuan, kami akan mengatur transisi pengembang antar tim .

Beberapa perusahaan berlatih rapat pada hari Jumat: orang-orang berkumpul untuk bertukar pengalaman, mendiskusikan sesuatu, dan berbicara. Kami juga memutuskan untuk mengatur pertemuan Jumat - kami memulai halaman di Wiki, di mana setiap orang yang ingin berbicara menulis topik laporannya.

Semuanya keren. Pada pertemuan, tim berbicara tentang apa yang mereka lakukan, apa yang baru. Misalnya, dengan salah satu tim kami memiliki kesalahpahaman, tidak ada yang tahu apa yang dia lakukan. Pada pertemuan Jumat, tim berbicara tentang pekerjaan mereka, menunjukkan analitik dan semua orang mengerti arti dari pekerjaan mereka. Pengembang Frontend berbicara tentang bagaimana perakitan berlangsung, membahas topik teknis umum, misalnya, bagaimana menggunakan Debugger di PHPStorm, bagaimana penyebaran terjadi.

Dan kemudian topik pengembangan berakhir, kami beralih ke topik psikologis dan cerita mulai memudar. Bagaimana selanjutnya merangsang pengembang untuk mengatakan sesuatu?

Dan kemudian kami ingat tentang KPI ! Mari kita ajarkan setiap pengembang untuk berbicara dan memasukkan dalam laporan KPI 2-nya selama enam bulan pada pertemuan Jumat. Kami pikir idenya keren dan semua orang akan maju.

Ternyata setelah pengenalan KPI, para pengembang berhenti membuat laporan. Penampilan negatif muncul untuk pertunjukan wajib. Programmer memutuskan untuk mengorbankan implementasi KPI 100%, hanya untuk tidak membuat laporan wajib-sukarela.

Kesimpulan

Sementara kami memecahkan masalah dengan efisiensi, perusahaan berkembang dan proyek-proyek baru muncul dan kami harus beradaptasi. Inilah yang kami mengerti dari ini.

• Sesuaikan dengan perubahan dan jangan fokus pada apa yang diterima, lihat perubahannya dan pilih praktik terbaik untuk bekerja dengan tim. Jika pengembang tidak dapat mengerjakan Scrum - kerjakan di Kanban sehingga semua orang senang dan senang.
• Terus memantau dan mengubah proses . Sebagai pemimpin tim, Anda harus mengontrol proses dalam tim. , . , , . , .

— .

. , , , : , PM, .

— , .

, :
— . — , PM.
PM .
— , ? — PM , .

, , .

. .

, . Jira Slack, , , . Scrum-, .

, .

.

. , . , . , - , — , — - . , . :

— ?
— !
— !
— , iMessage!

, - : , .

, : , , , 2 , .

« » .

— , , .

. , «», — , , . , , , . , , .
Jadilah filter antara lingkungan dan tim. Semua informasi harus ditutup agar tidak mendemotivasi pengembang.

Pengumpulan program TeamLead Conf , yang akan diadakan pada 25 dan 26 Februari di Moskow, sedang dalam tahap terpanas. Saya akan memberi tahu Anda tentang hasilnya di sini, ketika semuanya akan terikat dengan jadwal, dan koleksi tematis reguler akan datang di milis .