Direktur teknis ivi,
Evgeny Rossinsky (
eross ), sangat mengenal para peserta dalam konferensi kami tentang laporan tentang sisi teknis streaming. Tetapi hari ini Anda memiliki transkrip laporan Eugene tentang
TeamLead Conf tentang bagaimana transformasi Agile tercermin dalam pemimpin tim.
Belum lama berselang di ivi, kami melakukan transformasi Agile dan mendapat untung besar dalam hal:
- bisnis
- kecepatan pengembangan
- waktu ke pasar;
- metrik menarik lainnya.
Tetapi konsekuensi dari keputusan kreatif ini cukup serius menghantam para pemimpin tim. Laporan ini hanya tentang bagaimana menangani hal ini, dan alat apa yang digunakan.
Sebelum transformasi
Untuk memahami apa yang akan saya bicarakan, kita perlu sedikit berkenalan dengan produk kita. Kemudian kita akan menganalisis mengapa kita memiliki format perintah seperti itu dan mengapa kita memilih jalur ini.
Pengembangan ivi berjalan di bawah
lima platform utama :
- iOS
- Android
- Web
- TV pintar
- Windows + Xbox.
Dan, tentu saja, backend, yang tanpanya tidak ada. Sebelum kami memutuskan untuk melakukan transformasi, tim kami dibentuk oleh kompetensi.
Orang yang tahu, misalnya, Swift atau Objective C:
- duduk di ruangan yang sama;
- menerima tugas dari manajer produk;
- kerjakan dan hasilkan.
Semuanya tampaknya baik-baik saja, tetapi ada satu masalah - platform sangat berbeda dalam hal konsumsi produk dan konten pengguna.
Ini berarti bahwa
dalam setiap tim simpanan dan prioritasnya
mulai muncul . Misalnya, pengguna aplikasi web tidak suka membayar, dan konten dikonsumsi melalui model iklan. Fitur yang diperlukan untuk platform ini secara alami muncul di jaminan simpanan. Smart TV ditandai oleh fakta bahwa mereka dibeli dengan baik, dan fitur-fitur model berbayar terwujud.
Ternyata situasi berikut ini: seseorang datang dengan ide cemerlang bagaimana meningkatkan suatu produk; Saya menulis banyak tiket kepada manajer produk, masing-masing bertanggung jawab untuk platform mereka. Manajer melewati ide melalui prisma persepsi mereka, mungkin mereka memodernisasi sesuatu dan memasukkannya ke dalam rencana kerja mereka. Masalahnya di sini adalah bahwa satu fitur dapat dirilis di semua platform selama lebih dari satu tahun, karena "Saya percaya itu sama sekali bukan prioritas untuk platform saya." Dan dalam satu tahun, enam bulan, atau hanya beberapa bulan, apa pun bisa terjadi pada produk - misalnya, desain ulang atau perubahan konsep terjadi, dan fitur ini sudah perlu diluncurkan, dan itu sama sekali tidak seperti semua platform lainnya.
Akibatnya, setelah beberapa waktu ternyata
pada platform yang berbeda kami memiliki produk yang sama sekali berbeda dengan pesan komunikasi dan logika bisnis yang berbeda. Pengguna dalam situasi ini mulai bingung, karena ia tidak memiliki ruang tunggal di mana ia merasa percaya diri. Selain itu,
sangat sulit untuk membangun hipotesis , karena tidak selalu jelas pada platform mana fungsi yang paling baik. Itu semua tergantung pada ukuran layar, pada bagaimana orang mengkonsumsi konten. Dan semuanya terlihat seperti ini:
Produk yang cerdik membawa ide, dan pengembang pada platform yang berbeda melihatnya agak tidak ramah, dengan pengecualian backend, yang secara umum tidak peduli apa yang harus ditulis.
Jadi, karena perusahaan memiliki kompetensi yang cukup mengenai metodologi fleksibel, kami sepakat dengan bisnis yang kami butuhkan untuk menghilangkan penghalang antara:
berinteraksi secara produktif, dan melakukan satu hal yang sama.
Setelah transformasi
Ini menghasilkan arsitektur dengan
Value Stream khusus , di mana setiap tim terlibat dalam bidang bisnis tertentu.
Untuk membentuk struktur baru kami:
- melakukan beberapa pelatihan;
- Menentukan apa saja area utama untuk bisnis kami;
- mereka secara sukarela memaksa orang ke dalam aliran nilai;
- mulai diimplementasikan.
Benar, sebelum ini kami membuat satu tim seperti itu, pada contoh yang kami
lakukan demonstrasi , setelah mencuci satu fitur di semua platform dengan waktu-ke-pasar yang sangat baik.
Selain itu, fitur ini dipilih dengan sangat baik dan berhasil di semua platform. Jadi kami punya contoh yang menunjukkan bahwa
semuanya bisa dilakukan lebih cepat dan lebih baik . Ini memungkinkan seluruh tim pengembangan yang terdiri dari 130–140 orang untuk memahami bahwa Anda dapat bekerja secara berbeda.
Ketika kami menentukan value stream, muncul pertanyaan tentang apa yang harus dilakukan dengan para pemimpin tim. Sebelumnya, mereka adalah dasar untuk segala sesuatu ke arah mereka, tetapi sekarang ada aliran nilai dan pengaruh bisnis yang lebih besar. Apa yang telah kita lakukan Kami mengumpulkan orang-orang dari kompetensi berbeda ke dalam setiap aliran nilai, setidaknya masing-masing satu:
- Pengembang iOS
- Pengembang Android
- Pengembang JavaScript
- Spesialis TV Cerdas
- desainer tata letak,
- ke tester.
Ternyata menjadi tim independen, tetapi
mandiri dalam kata -
kata dan pada slide indah dari seorang pelatih Agile. Bahkan, semua orang lupa bahwa masih ada kesamaan di antara orang-orang yang dapat menulis dalam bahasa pemrograman yang sama - ini adalah kode program mereka, di mana mereka harus berkomunikasi entah bagaimana. Untuk beberapa alasan, banyak yang diam tentang hal ini, tetapi ini benar-benar masalah yang cukup besar yang perlu diingat.
Misalkan Anda menempatkan orang di lantai atau kamar yang berbeda, dan mereka menulis kode yang sama. Ada siklus rilis dan fitur yang tidak boleh saling mengganggu. Ada banyak masalah.
Dari konsepnya
Kami telah mengadopsi beberapa konsep dasar:
Kami mendapat
value stream dan
perintah platform . Dalam value stream, orang-orang mengimplementasikan fitur tertentu, dan di platform ada pemimpin tim - pusat kompetensi. Di dalam platform, beberapa fitur juga dapat dikembangkan, tetapi ini lebih merupakan pandangan arsitektur tentang pengembangan perangkat lunak.
Kami memperkenalkan konsep "
Persekutuan ". Dengan menempatkan pengembang iOS yang sama di ruangan yang berbeda, kami perlu memberi mereka tanda formal dan bahkan yang informal, bahwa mereka tetap menjadi pengembang iOS yang sama, dan bukan hanya peserta dalam arus nilai produk iklan, misalnya. Dan kemudian dengan guild ini kamu perlu melakukan sesuatu dan entah bagaimana mengajar orang untuk berkomunikasi di dalam.
Pertanyaan selanjutnya adalah
apa yang harus dilakukan dengan siklus rilis . Pada platform tersebut di mana Anda dapat melakukan roll out saat fitur siap, tidak ada pertanyaan. Dan dalam kasus iOS atau Android, ketika, karena spesifik dari menerima penerimaan Apple, tidak mungkin untuk mengirim aplikasi dua kali sehari untuk rilis, itu perlu untuk mengumpulkan beberapa paket.
Kami memutuskan bahwa setiap platform yang tidak dapat segera dirilis akan dirilis
setiap dua minggu sekali . Mereka membuat kalender khusus tersedia untuk semua orang, di mana tim menerbitkan tanggal
pembekuan fitur dan tanggal rilis. Jika, dalam aliran nilai, Anda ingin tugas Anda tersedia bagi pengguna nyata, Anda harus tepat waktu untuk pembekuan fitur. Punya waktu - yah, tidak punya waktu - Anda sedang menunggu kereta berikutnya.
Timlid dalam skema baru
Apa yang terjadi dengan Timlids? Mereka melalui skema klasik kesadaran masalah yang tidak dapat diselesaikan.
Awalnya kami menemukan
penolakan . Karena pemimpin tim telah membangun tim yang keren selama beberapa tahun, memelihara setiap karyawan, memikat seseorang dari pesaing. Dan para spesialis ini sekarang ditugaskan untuk bekerja yang tidak selalu memenuhi harapan mereka.
Tentu saja, setelah penyangkalan itu ada
amarah .
Ada banyak skandal, setelah itu
tawar menawar dimulai. Semua orang datang dengan pertanyaan: "Mari kita semua memiliki cara Anda sendiri, tetapi saya memilikinya seperti sebelumnya, tetapi saya akan mengambil spidol, menulis" Agile "di rumah saya, saya akan memakai T-shirt dengan tulisan ini, tetapi semuanya akan seperti sebelumnya." Itu tidak berhasil.
Tetapi pada akhirnya, apa yang sebenarnya saya harapkan terjadi - orang mengerti mengapa kami melakukan ini. Saya harap mereka mengerti, meskipun mungkin mereka berbohong. Kasus sukses pertama menunjukkan perbedaan nyata yang mencolok antara apa yang sebelumnya dan bagaimana hal itu dapat dilakukan secara berbeda. Waktu ke pasar yang terbelah dua memungkinkan kami menetapkan patokan untuk semua orang. Langkah selanjutnya terjadi, yang dalam model klasik psikologi disebut
Sindrom Stockholm . Orang-orang yang mengadopsi aturan baru belajar untuk ada di dalamnya dan mulai perlahan-lahan menyebarkan "agama" ini. Saya tidak bisa mengatakan untuk semua Timlids, tetapi sekitar 30% dari mereka sekarang adalah “pengkhotbah” aktif dalam arah ini.
Masalah dan kesulitan
Sekarang saya akan mencoba membuat daftar kesulitan yang kami temui secara struktural:
Karena fakta bahwa karyawan duduk di kantor yang berbeda, komunikasi verbal terputus.
Itu menjadi sangat sulit selama sebulan , karena sebelum itu mungkin dengan cepat bertanya kepada tetangga, misalnya, apa yang perlu Anda warisi, dan kemudian dapatkan jawabannya. Dan sekarang Anda duduk di ruang yang terpisah, ada orang-orang di sekitar Anda yang teknologinya mungkin tidak Anda sukai, dan tidak ada yang berkonsultasi. Untuk mengajukan pertanyaan kepada seseorang, Anda perlu menulis dalam obrolan, dan orang yang dapat menjawabnya hilang - itu saja, Anda harus menyerahkan perangkat Anda sendiri.
Kami segera mulai
mengalami masalah dengan Peninjauan Kode , yang saya pikir bukan masalah, tetapi penemuan besar. Kami menemukan bahwa sejumlah
besar karyawan tidak mandiri . Misalkan ada seorang karyawan yang, menurut statistik, masalah ulasan melewati maksimum kedua kalinya, biasanya pertama kali semuanya baik-baik saja. Dan ketika dia pergi untuk bekerja di value stream, untuk beberapa alasan itu menjadi 5-6 iterasi.
Mereka mulai memahami, dan ternyata pendapat otoritatif dari tokoh ikon pemimpin tim, yang mengendalikan, memusatkan semua aliran informasi relatif terhadap dirinya sendiri, tidak terlalu mempengaruhi perkembangan pengembang.
Orang-orang malas , mereka meminta bantuan pada semua masalah dan menerima jawaban yang kompeten. Jadi ulasannya cepat dan keren. Sendiri dengan diri mereka sendiri, banyak pengembang harus
tumbuh cukup signifikan di
atas diri mereka sendiri untuk membuat keputusan arsitektur yang sama . Tidak ada yang suka mendengar lima kali berturut-turut bahwa kode Anda tidak terlalu baik. Ini membuat frustrasi, itu membuat Anda menganggap diri Anda seorang karyawan yang tidak memenuhi syarat, bahkan dapat menyebabkan depresi atau keyakinan bahwa mungkin pekerjaan itu buruk. Tetapi intinya adalah bahwa Anda perlu melihat diri Anda sendiri, untuk memahami bahwa dalam mode operasi sebelumnya Anda tidak memikirkan hal-hal ini, tetapi sekarang Anda sedang
berkembang dan harus mulai memikirkannya .
Di sisi lain, kami memiliki beberapa hal yang sangat menarik yang, menurut pendapat saya, berlebihan sehubungan dengan Peninjauan Kode. Ada aturan di salah satu tim: agar tugas untuk lulus review, semua anggota tim harus membuat keputusan. Ketika mereka duduk bersama, mereka kurang lebih berhasil, dan sekarang mereka semua duduk - beberapa memiliki pertemuan harian pada satu waktu, yang lain memiliki beberapa bisnis lain - dan meninjau tugas menjadi hambatan yang sempit. Berkali-kali dalam retrospeksi, mereka belajar bahwa beberapa tugas menunggu selama dua minggu, dan dipaksa untuk mengubah sesuatu.
Kemudian mulai:
separatisme, diskriminasi dan kecemburuan .
Sebelumnya, seseorang mengira dia tahu apa yang ingin dia lakukan. Dan dengan pemisahan value stream dan platform, muncul kecurigaan bahwa “tetangga lebih enak”: tugas lebih menarik dan pertumbuhan lebih cepat. Masalah kedua adalah bahwa ketika semuanya menjadi
fitur-centered ,
kualitas kode sangat
menurun . Di sekitar Anda adalah orang-orang yang ingin mendapatkan hasilnya dengan cepat, dan bukan tugas mereka untuk berpikir bahwa itu akan perlu didukung, dimodernisasi dengan cara apa pun, dan tidak boleh ada yang terlepas dari rekan kerja dari fitur baru.
Situasi mulai muncul di mana kecepatan perkembangan tinggi memiliki sisi berlawanan -
kode berkualitas buruk , yang mulai berkembang biak dalam jumlah yang tidak manusiawi. Ketika pemimpin tim yang bertanggung jawab mengambil koreksi kesalahan-kesalahan ini dan refactoring, ternyata hidupnya berubah menjadi sampah besar untuk karyawan yang lalai. Para pengembang cepat untuk mendapatkan semuanya, semua orang senang, dan mereka tidak memperhatikan pekerjaan raksasa dari pemimpin tim, berkat itu, pada kenyataannya, semuanya bekerja. Setelah sekitar dua bulan, masing-masing ketua tim menyatakan ketidakpuasan dengan situasi saat ini.
Untuk mengatasi masalah ini, kami mengadakan beberapa pertemuan pertama dengan Timlids, dan kemudian dengan semua guild untuk menjelaskan kepada orang-orang bahwa mungkin untuk bekerja secara berbeda. Jika Anda ingin mencoba sesuatu yang lain, maka dengan ini Anda harus menjadi pemimpin tim, dan Anda dapat dengan mudah bertukar tempat. Hal utama yang harus disepakati di antara mereka sendiri.
Kekuatan metodologi yang fleksibel adalah bahwa tidak menjadi masalah bagi semua orang bagaimana segala sesuatu terjadi, hal utama adalah bahwa orang setuju dan puas.
Ini di satu sisi. Di sisi lain, sehingga ada keadilan mengenai siapa yang terlibat dalam refactoring dan siapa yang melakukan fitur-fitur baru, para pemimpin tim mulai bekerja dengan jaminan simpanan, saya akan kembali ke sini nanti.
Dan kemudian
kesulitan dimulai
dengan Manajemen Rilis . Ada penguji dalam value stream, penguji di platform, ada yang otomatis, ada yang tidak otomatis, Anda perlu memikirkan cara membuat regresi umum. Dan ada istilahnya. Kami secara sukarela memutuskan untuk melepaskan sekali setiap dua minggu, dan bagaimana jika seorang mitra datang bersama dengan permintaan untuk melakukan semuanya besok (dan sekantong uang, misalnya), katakan padanya untuk menunggu siklus berikutnya? Tetap saja,
kompromi harus dicari . Dan kemudian skema yang indah dengan rilis bisa banyak berubah.
Contoh yang baik adalah undang-undang FZ-54, yang menyatakan bahwa semua pembelian di Internet harus disertai dengan mengirimkan cek elektronik kepada pengguna dan pajak. Anda dapat berbicara di konferensi sebanyak yang Anda suka dan berbicara tentang metodologi yang fleksibel dan tentang apa yang ada peraturan dan sebagainya, tetapi begitu ada risiko mendapatkan penalti 70% dari pendapatan Anda, Anda beralih ke rezim yang sama sekali berbeda dan memastikan bahwa perusahaan Anda tidak didenda. Kasus seperti itu jarang terjadi, tetapi ada. Secara khusus, kami harus membuat komunikasi tingkat kedua jika terjadi perubahan skema. Itu tidak mudah, tetapi mungkin.
Masalah berikutnya yang kami temui sebagai akibat dari transformasi terkait dengan
karyawan baru . Menurut pendapat saya, pemula harus tenggelam dalam lingkungan sedekat mungkin dengan lingkungan di mana ia akan bekerja. Dan di sana, karena lingkungan, ia akan dengan cepat menerima pengetahuan yang diperlukan. Tetapi kami menyeret spesialis yang membuat lingkungan ini ke lantai dan kamar yang berbeda. Kehidupan seorang pemula di sebuah perusahaan menjadi tugas manajerial yang agak serius, solusinya harus dipikirkan.
Alat-alatnya
Berikut adalah alat yang kami gunakan.
Saya akan memulai ceritanya dengan
peta rute untuk karyawan baru. Sayangnya, ini adalah sesuatu yang belum kita pelajari bagaimana mengotomatisasi sepenuhnya dan, pada kenyataannya, memikirkan untuk setiap karyawan secara terpisah, tergantung pada apa yang akan dia lakukan.
Ada contoh yang agak menarik: kami perlu menumbuhkan
tester universal , yang akan dapat menguji sepenuhnya semua produk untuk aliran iklan. Mereka memiliki banyak kesamaan, tetapi mereka juga memiliki kekhasan masing-masing. Bukan rahasia lagi bahwa penguji yang keren dalam menguji aplikasi web akan hilang untuk pertama kalinya ketika bekerja dengan alat, misalnya, untuk iOS. Untuk penguji ini, direktur kontrol kualitas kami membangun peta rute khusus. Pada kartu ini, seorang karyawan baru di setiap kompetensi memperoleh pengetahuan selama dua minggu, berpartisipasi dalam regresi, dan banyak lagi. Dengan pengembang, situasi dengan implementasi kira-kira sama. Jadi, bahkan pada saat wawancara, kami mencari tahu apa yang menarik Candida dan apa yang menarik baginya, dan kami mencoba memilih ke arah mana untuk mengirimnya.
Tentu saja, pertama kali seorang karyawan baru memompa kompetensi, yaitu, dalam istilah kami, berada di tim platform, dan kemudian sudah dapat bermigrasi ke aliran nilai yang kami butuhkan. Ngomong-ngomong, peta rute bagus, tetapi kemampuan adaptasinya juga tidak perlu dikesampingkan.
Kemudian kami memperkenalkan
Sinkronisasi Kelompok - sinkronisasi tindakan serikat .
Mengapa ini dibutuhkan? Semua orang mendengarkan ceramah tentang Scrum, yang berbicara tentang perlunya pertemuan harian untuk memberi tahu Anda apa yang sedang terjadi. Tetapi spesialis kami, misalnya, adalah pengembang Android, di satu sisi, dan anggota tim produk, di sisi lain. Jika dia harus berjalan dan berkomunikasi dua kali sehari, dia akan mendapatkan semacam kultus Cargo. Pada tingkat ini, Anda dapat menghabiskan seluruh hidup Anda dalam rapat. Jelas, itu akan mengganggu orang.
Jika kita mengatakan bahwa kita didasarkan pada model fitur-sentris, maka pertemuan harian lebih penting dalam aliran nilainya. Tetapi pada saat yang sama, Anda dapat melepaskan diri dari apa yang terjadi di guild. Untuk melakukan ini, beberapa guild mengatur pertemuan seminggu sekali, beberapa - dua kali seminggu. Dan di sini pemimpin tim secara metodis berpikir tentang apa yang layak dibicarakan. Ini seharusnya tidak diterjemahkan menjadi pembicaraan kosong, ini adalah strategi pengembangan untuk tim teknologi, yang merupakan guild. Rapat Guild Sync diperlukan agar semua orang memahami teknologi apa yang akan digunakan perusahaan, keputusan strategis apa yang dibuat terkait platform ini. Di atasnya, sebagian tinjauan solusi arsitektur terjadi.
Di beberapa tim kami memiliki lebih dari satu pemimpin tim. Secara umum, definisi pemimpin tim sangat ambigu. Ada
pemimpin opini yang bisa menjadi pemimpin tim dan membawa solusi dari beberapa masalah organisasi. Mungkin ada beberapa pemimpin opini dengan keterampilan manajemen dalam tim. Dan kemudian mereka dapat mengatur diri mereka sendiri, siapa yang bertanggung jawab untuk apa. Sebagai contoh, salah satu pemimpin opini dapat pergi ke aliran nilai. Dalam hal ini, Anda perlu menyinkronkan keputusan arsitektur Anda, yang di masa depan akan menentukan strategi pengembangan seluruh platform teknologi.
Kemudian kami mulai melakukan
mitaps internal dan eksternal di area tertentu. Secara umum, ini adalah sebagian kasus SDM yang cukup standar, sebagian kasus pembentukan tim. Untuk rapat internal, kadang-kadang diadakan pemungutan suara dengan topik yang paling menarik, pembicara dicari baik di dalam perusahaan, atau kami mengundang seseorang dari luar, menyewa ruang khusus dan membahas berbagai poin penting. Rata-rata, kami memiliki dua mitaps internal per bulan, tetapi terkadang empat. Orang-orang dari kompetensi lain dapat datang ke mitaps ini untuk mendengarkan bagaimana tetangga hidup dan melihat apakah mereka ingin mengubah spesialisasi mereka. Ini juga terjadi.
Sekarang di pasar tenaga kerja dalam hal pengembang, semuanya tidak terlalu sederhana. , , . , ,
, . , , .
. , , Agile- , Guild Sync .
, , , . , , Guild Sync , .
, , , ,
, . 10 .
—
. , , -. - , , , . - , , , . , - . , , , , , - .
. , . , , , , . , , , . , - , , , , , .. .
, « ». , , .
Guild , . - , , .
, product owner' value stream. , 10 , - , , . , product owner' . backlog' . , , . , ( , , , , ).
— , .
Teamlead —
, , -
.
,
. , , , , , , — .
, , , « ». , , , . , , , , value stream. , , .
, , .
Reli berikutnya untuk pertukaran trik Timlid dijadwalkan pada 24 dan 25 September. Kami akan bertemu di St. Petersburg di Saint TeamLead Conf untuk membahas semua jenis masalah manajemen tim.
Program sudah mulai terbentuk, ada lebih dari 40 aplikasi dalam daftar laporan yang disampaikan , dan sejauh ini ada peluang untuk menambahkan topik Anda di sana - Komite Program menerima aplikasi hingga 10 Agustus .