Ketika dalam artikel dan laporan mereka berbicara tentang kasus dalam manajemen tim, mereka sering membatasi diri untuk mengatakan apa yang salah dan bagaimana mereka mengubah situasi. Tapi kali ini kami memiliki kesempatan unik untuk mengetahui bagaimana tim hidup lebih jauh dan bagaimana semuanya berakhir - pada kenyataannya, itu tidak berakhir, tetapi berlanjut.

Berikut ini adalah kelanjutan dari cerita yang berjudul " Bagaimana cara bertahan hidup di kulit kepala dalam scram scalable dan mempertahankan kontrol atas kualitas kode " tentang transformasi Agile di ivi. Di TeamLead Conf, direktur teknis perusahaan, Yevgeny Rossinsky ( eross ), menjelaskan mengapa mungkin diperlukan untuk memutar kembali seluruh reorganisasi tim, bagaimana tidak bertengkar dan membantu pengembang, tetapi juga untuk mempertahankan dan meningkatkan efisiensi bisnis.

Konteks perusahaan

ivi - sinema Internet legal terbesar dengan pemirsa 48 juta pengguna, yang secara kolektif menghabiskan 70 juta jam setiap bulan. Ivi memiliki 62 ribu unit konten, yang tersedia dari berbagai perangkat dan selalu dalam kualitas yang sangat baik.

Kebetulan pada hari ketika Eugene berbicara di TeamLead Conf dengan laporan ini, itu adalah hari ulang tahun perusahaan. 9 tahun yang lalu, rilis pertama dari versi web proyek berlangsung, dan setelah 2 hari, kekuatan Channel One membawa sejumlah besar pengguna ke ivi. Perusahaan bahkan berpikir bahwa itu adalah DDoS, tetapi mampu bertahan dengan bermartabat.

Artikel ini adalah tentang meluncurkan produk baru - restart penuh dari semua aplikasi.

Tonton video untuk mendengar versi yang tidak disensor atau baca transkrip laporan secara langsung.



Pertama, mari kita bicara tentang teknologi dan kompetensi yang digunakan untuk memahami tingkat kerusakannya.

Kompetensi:

• Backend (Python, Golang, Java);
• Web (JavaScript, Node.js);
• Android (Jawa)
• iOS (Objective-C, Swift);
• SmartTV (JavaScript);
• Windows / XBox (C #);
• Sony PS (JavaScript).

Untuk masing-masing kompetensi ini di tahun 2016, kami memiliki tim kami sendiri, yaitu Tim iOS, tim Android, dll. Ada juga tim backend dan secara terpisah, tim manajer produk yang datang dengan fitur-fitur baru.

Masalah utama, karena itu perlu diubah, adalah bahwa semua platform berbeda, termasuk bahwa mereka memiliki jaminan simpanan dan prioritas yang berbeda. Dan kami benar-benar ingin membangun ruang informasi tunggal dalam aplikasi kami.

Sering terjadi bahwa fitur kompleks muncul di semua platform 4 bulan setelah dikandung. Pada saat yang sama, itu muncul pada satu platform setelah 3 hari, dan kemudian, tergantung pada prioritas backlog, itu diluncurkan pada platform yang berbeda dengan kecepatan yang berbeda. Ternyata mengerikan karena alasan berikut:

• Selama 4 bulan, fitur tersebut sudah bisa mendapatkan arti yang sama sekali berbeda dan kebutuhan untuk itu bisa hilang.
• Karena masalah komunikasi, yang jelas dalam kasus ini, orang menerapkan fitur dengan cara yang berbeda.

Karena produk memiliki tiga model monetisasi yang bekerja dengan efisiensi berbeda pada platform berbeda, prioritas backlog pada setiap platform berbeda. Beberapa fitur pada prinsipnya tidak pernah dapat diimplementasikan pada platform terpisah.

Menceritakan kembali transformasi secara singkat

Pada 2017, kami memperkenalkan konsep Value Stream - ini adalah tim lintas fungsi yang bertanggung jawab untuk tugas bisnis tertentu. Untuk memahami apa tugas spesifik bisnis kami, kami mengumpulkan sekitar 25-30 orang dari seluruh perusahaan, mengundang pelatih yang terlibat dalam metodologi fleksibel, dan dalam 2 hari kami merumuskan Nilai seperti apa yang seharusnya kami miliki - arahan pengembangan.

Mendapat 5-6 Nilai Aliran. Mereka menanam orang-orang ini bersama-sama, memberikan masing-masing Pemilik Produk, yang akan tenggelam untuk arahan khusus ini (lebih detail di sini ).

Kami tahu rasa sakit, darah, air mata dan kegembiraan dan mencapai indikator yang sangat baik:

• Bongkar sinkron dari fitur identik pada platform yang berbeda .
• Penurunan beberapa kali dari waktu ke pasar . Pelepasan banyak fitur hanya ada dalam siklus manajemen rilis di setiap platform, karena, misalnya, Apple tidak mengizinkan untuk membongkar setiap fitur secara terpisah. Oleh karena itu, fitur dikelompokkan dan rata-rata kami akan dirilis setiap dua minggu sekali.
• Eliminasi "kemacetan" , yang merupakan Pemilik Produk, dan manajer teknis serta pemimpin tim.
• Pengembang mulai memahami mengapa mereka "menggergaji" fungsi baru.

Kami berhasil melewati tahun dengan sangat baik - pada tahun 2017, pendapatan hampir dua kali lipat .

Tapi ini tidak cukup, dan kehidupan di akhir 2017 - awal 2018 memberi kami kejutan.

Mengapa Anda membutuhkan produk baru?

Bisnis telah menetapkan tujuan baru. Yang mengejutkan adalah bahwa pengembangan perangkat lunak apa pun ada demi sesuatu. Beberapa kode tulis untuk alasan altruistik. Agar perusahaan dapat membenarkan keberadaannya, pemilik dan pemegang sahamnya menetapkan tujuan tertentu yang harus dipenuhi oleh tim.

Para pemegang saham kami tidak mengatakan bagaimana melakukannya, mereka mengatakan apa yang ingin mereka capai. Bagaimana - tim harus memutuskan.

Tim menghadapi tugas menghasilkan cara mendapatkan lebih banyak . Kami melakukan brainstorming, dan departemen kelontong, bersama dengan yang teknis, sampai pada kesimpulan bahwa untuk mewujudkan tujuan yang ambisius (dengan konvensi, untuk menggandakan ukuran audiens yang membayar), pada prinsipnya kita harus menggeser penekanan dari menonton film secara gratis menjadi berbayar.

Hampir semua hipotesis yang diajukan sangat tidak sesuai dengan konsep produk lama. Lebih tepatnya, itu sama sekali tidak cocok - aliran motivasi pada transisi pengguna didasarkan pada kenyataan bahwa pada beberapa platform ini diterapkan, pada beberapa tidak, ada beberapa keterbatasan, yang lain ada. Tim kami berusia 9 tahun, dan kami telah mengumpulkan banyak hal yang menyeret kami ke bawah. Dalam cara yang baik, perlu menulis ulang semuanya.

Beberapa penelitian kualitatif dan kuantitatif telah menunjukkan masalah pada produk lama . Ternyata kita berada 2-3 tahun di belakang apa yang dipikirkan umat manusia yang bijak. Sebagai contoh, jika sekitar 5 tahun yang lalu pada perangkat seluler, mode dan modern untuk meletakkan menu burger di sudut kiri atas, maka dengan munculnya layar besar orang berhenti mencapai di sana. Hingga 2018, kami benar-benar memiliki menu burger, dan orang-orang entah bagaimana mengatasinya.

Pengguna yang buruk terbiasa dengan segalanya, tetapi ini tidak berarti bahwa Anda harus meninggalkan semuanya apa adanya.

Banyak kerangka kerja yang membutuhkan refactoring. Kami menemukan kelemahan logis dan, seperti pada kode lama, kami memiliki banyak kode lama yang tidak terlalu bagus. Pengembang benar-benar tidak menyukainya.

Sebagai contoh, sangat sulit untuk mempekerjakan pengembang yang ingin menulis di Objective-C. Kita semua dipengaruhi oleh mode, dan bahkan malas - jika ada alat yang memungkinkan Anda melakukan hal yang sama, tetapi lebih cepat dan lebih efisien, kami ingin menggunakannya. Dan situasi di pasar kerja sedemikian rupa sehingga Anda dapat menulis dalam ringkasan: "Saya ingin menulis di Swift," dan bahkan jika Anda tidak tahu cara menulis di Swift, Anda pasti akan mendapatkan suatu tempat.

Sesuatu harus dilakukan dengan ini, dan ini adalah salah satu masalah yang menghambat pembangunan. Oleh karena itu, kami harus menulis ulang komponen usang dan menerapkan kerangka kerja modern.

Tujuan

Kami ingin:

• Buat produk baru dengan desain tunggal.
• Jadikan sistem rekomendasi kami yang baik bertanggung jawab untuk menerbitkan semua blok dalam produk kami.
• Kesalahan antarmuka logis yang benar.
• Bersihkan kodenya.
• Bermigrasi ke sistem statistik baru.
• Menerapkan sistem desain.

Semua tantangan cukup ambisius, terutama sistem desain, karena ada sangat sedikit sistem desain yang bekerja lintas-platform dan bercerai dari kode program. Mereka terutama memproduksi mesin JS, yang digunakan pada platform yang berbeda. Bahkan, mekanisme untuk mentransmisikan informasi tentang bagaimana produk seharusnya terlihat ada di dalam kode.

Kami tidak dapat melakukan ini dengan sangat baik, karena kami bekerja dengan video, dan bekerja dengan video memerlukan penggunaan lebih banyak atau lebih sedikit alat asli. Plus, jika Anda tidak menggunakan alat asli, akan selalu ada 1-2 langkah jaminan dari rilis sistem operasi. Semua kerangka kerja universal seperti Xamarin masih harus menyusul setelah rilis. Dan kami sangat serakah sebelum kami tampil - Google dan Apple merekomendasikan kami hanya karena kami menggunakan alat asli.

Alat asli membantu membuat aplikasi yang berkualitas, baik, dan cepat. Dalam hal video, ini hanya perlu.

Cari solusi manajemen

Setelah menentukan tujuan, kami menyesuaikan dengan pencapaian cepat mereka. Biarkan saya mengingatkan Anda bahwa kami dibagi menjadi Value Stream, pengembang yang berbeda duduk di tim yang berbeda, dan kami dihadapkan dengan kenyataan pahit - apa yang harus dilakukan?

Tampaknya kami memiliki sistem yang kami gunakan untuk membiasakan orang selama beberapa waktu, dan sekarang aturan mainnya telah berubah.

Tentu saja, pada awalnya kami mencoba bekerja seperti sebelumnya, menggunakan Value Stream, menerima perhitungan logis berikut: "Biarkan Value Stream, yang bergerak dalam arah bisnis seperti itu, akan memperbaiki semua komponen yang terkait dengan area ini."

Oh betapa salahnya kami! Sekitar sebulan kemudian ternyata bahwa untuk menulis ulang inti dari masing-masing aplikasi, sebenarnya, Anda harus masuk ke semua bidang aturan bisnis.

Sangat sulit untuk membedakan bidang tanggung jawab Value Stream, yang mengambil bagian apa ketika orang-orang duduk di lantai yang berbeda, di ruangan yang berbeda.

Yang paling menyedihkan, karena berbagai bahasa dan fitur platform pengembangan, efek kolaborasi telah sepenuhnya hilang.

Dalam kerangka Value Stream, pengembang iOS dan Android melihat fitur yang sama, dan mereka memiliki sesuatu untuk dibicarakan, mereka sedang mendiskusikan logika bisnis. Dan ketika masing-masing dari mereka melihat kerangka kerja tingkat rendah, yang berkorelasi lemah dengan apa yang nantinya akan ada dalam produk akhir, sinkronisasi menghilang sepenuhnya.

Ada orang-orang yang, pada prinsipnya, memisahkan diri dari makna dari apa yang terjadi. Timlids adalah yang pertama menjadi patah semangat, karena mereka, sebagai orang yang bertanggung jawab, perlu tersandung dan tidak percaya pada karyawan kemanusiaan untuk kembali ke pangkuan gereja yang benar sehingga mereka akan menulis kode yang memadai di arah yang benar. Ternyata sangat buruk.

Setelah satu setengah bulan, ia menyadari bahwa Value Streams bekerja dengan baik untuk produk jadi, tetapi umumnya tidak efektif ketika suatu produk perlu ditulis dari awal.

Seperti semua kebenaran sederhana, Anda memahaminya hanya setelah Anda berjalan menyapu tanpa alas kaki, dan bahkan membiarkan arus mengalir melalui menyapu.

Semua yang baru sudah lama terlupakan.

Kami akan mengembalikan semuanya seperti semula

Setelah transformasi Agile yang berjaya, kami memutuskan untuk melakukan segalanya seperti pada 2016, karena hak atas demokrasi harus diperoleh.

Agar setiap orang memiliki hak untuk memilih, dan hak ini diklaim dan digunakan, perlu untuk membentuk aturan dan ekosistem di mana ia akan bekerja.

Ketika tidak ada ekosistem, beberapa hal harus dilakukan secara otoriter sehingga aturan tersebut terbentuk.

Lakukan yang berikut:

• Mereka membawa orang kembali di bawah sayap timlids, memfokuskan kembali mereka dari pemrograman berorientasi fitur ke pemrograman biasa.
• Manajer produk ditugaskan untuk mengalirkan pengguna. Dalam kasus kami, ini sedang mengunduh, otorisasi, dll.
• Kami mencoba memformalkan semua persyaratan untuk produk baru, yang kami sepakati pada awal pengembangan.

Segalanya tampak logis, tetapi seperti dua tahun lalu kami mengalami masalah yang sama.

Itu tidak akan berhasil, lagi masalah dalam organisasi

Masalah utama dua tahun lalu adalah: sentralisasi dan pengambilan keputusan.

Otoritarianisme mengarah pada munculnya "kemacetan" - pemimpin tim, manajer teknis dan manajer produk yang tidak punya waktu untuk menyampaikan fitur-fitur untuk pengembangan. Produk yang telah digergaji selama 8 tahun sebelumnya sulit untuk dipikirkan kembali dalam beberapa bulan. Itu tidak keren ketika 80% dari konsep siap, dan 20% (hanya di mana bubur kertas) belum ada. Ini sangat mengganggu dan membuat marah tim.

Ketika para pengembang secara resmi kembali ke manajemen pemimpin tim, ada komunikasi langsung yang jauh lebih sedikit dengan manajer produk, dan ada kebutuhan untuk meresmikan TK. Apa yang digantikan dengan sempurna oleh komunikasi verbal kembali menjadi formalisme - dia kembali, tidak ada yang mengembalikannya. Tetapi para insinyur diatur dengan cara ini, mereka diajar di institut: ada pernyataan masalah - itu perlu dipecahkan, tidak ada pernyataan masalah - dunia terhempas, algoritma tidak akan berfungsi.

Dalam prosesnya, kesalahan dan kesalahan perhitungan ditemukan, baik logis maupun arsitektural. Bayangkan membuat kode selama beberapa tahun, dan selama ini Anda ingin memperbaikinya, dan ketika ada kesempatan, ternyata semua ide dan konsep itu tidak terlalu bagus atau tidak berfungsi sama sekali. Mimpi itu ternyata salah.

Pada saat yang sama, seperti yang biasanya terjadi ketika mengevaluasi tenggat waktu, sebuah bisnis mendengar satu hal, pengembangan mendengar hal lain. Selain itu, bisnis masih terbagi menjadi dua, dan kemudian mulai memberikan tekanan pada tenggat waktu dan ingin mendapatkan produk baru kemarin. Pada jam X, ternyata pengembangan berpikir bahwa masih ada 3-4 bulan, dan bisnis sedang menunggu rilis kemarin. Semua orang kesal, tim mulai sobek.

Apa yang telah kamu lakukan

Kami melakukan retrospektif skala besar tentang bagaimana kita hidup, dan mengungkapkan apa yang paling mengkhawatirkan tentang pengembang dan pemimpin tim.

Kebutuhan untuk mengulang fungsi , dan sering 3 kali. Sejujurnya, setengah dari masalah ada di sisi pernyataan masalah, setengah lainnya di sisi implementasi. Namun, para pengembang, tentu saja, sangat yakin bahwa seluruh masalah ada dalam rumusan masalah. Di sisi tugas direktur adalah sama. Tidak ada yang ingin menganggap diri mereka salah atau bersalah, semua orang mengatakan bahwa masalahnya ada di sisi lain.

Dukungan untuk aplikasi lama . Layanan dengan audiensi jutaan dolar tidak bisa ditinggalkan begitu saja. Sejalan dengan menulis produk baru, sesuatu harus dilakukan dengan yang lama. Ini sangat menjengkelkan!

Implementasi sistem desain. Kami sangat bangga dengan arah ini: itu benar-benar memungkinkan Anda untuk dengan cepat melakukan hal-hal yang sangat kompleks, dan produk terlihat seragam. Tapi saya harus melatih desainer tentang apa itu JSON, dan desainer harus menyampaikan kepada pengembang bahwa penampilan juga sangat penting. Banyak salinan rusak tentang ini.

Kurangnya informasi dan jawaban untuk pertanyaan "Mengapa?". Tanpa Value Stream, beberapa pengembang tidak lagi mengerti mengapa mereka melakukan sesuatu. Ada jeda dalam pengiriman informasi, dan hubungan sebab-akibat sebagian hilang. Mereka yang menemukan kekuatan untuk bertanya mengapa kami melakukan ini bahagia. Tidak terlalu komunikatif orang berpikir bahwa orang idiot sedang duduk di suatu tempat di lantai atas yang menciptakan hal-hal yang tidak dapat dirancang.

Kurangnya dokumentasi tentang aturan bisnis baru. Karena kurangnya informasi, ada kekurangan dokumentasi di mana akan dijabarkan bagaimana aplikasi harus bekerja dengan benar.

Semua orang mencoba peran arsitek, dan tidak semua orang menyukainya. Bagi saya itu adalah penemuan terbesar. Untuk pertama kalinya, pemimpin tim memperkirakan tenggat waktu untuk memproses aplikasi sekitar satu setengah tahun, yang tidak berharga. Ini terjadi karena setiap pemimpin tim ingin membiarkan semua bagian dari sistem melalui dirinya sendiri, yaitu, dia benar-benar tidak ingin mendelegasikan dan menguraikan arsitektur aplikasi, tetapi ingin menyimpan semuanya untuk dirinya sendiri.

Dengan pendekatan ini, Anda benar-benar membutuhkan satu setengah tahun untuk memperbaiki arsitektur. Tetapi dengan istilah seperti itu di dunia ini tidak ada yang bisa dilakukan. Oleh karena itu, setelah diskusi panjang, kami sampai pada kesimpulan bahwa fungsi arsitektur pemimpin tim harus didelegasikan kepada pejuang berpengalaman tertentu dari pengembangan di bidang-bidang utama tertentu, yang, antara lain, ingin berpartisipasi dan merasa seperti seorang arsitek.

Ternyata fakta yang menarik - ternyata mengambil tanggung jawab itu tidak menyenangkan.

Menyebut diri Anda seorang arsitek atau pemimpin tim dan menjadi pemimpin tim adalah dua perbedaan besar. Tidak semua orang ternyata siap untuk menerima bahwa jika Anda berhati-hati dan menyia-nyiakan konversi, maka ini hanya akan menjadi tanggung jawab Anda.

Saya naif dan karena alasan tertentu berpikir bahwa semua orang di tim kami memiliki keberanian seperti itu. Saya lupa bahwa sebelum Timlid Anda perlu menjadi dewasa dan tumbuh sedikit. Sepanjang tahun, banyak dari kita yang menempuh arah ini, dan beberapa menyadari bahwa mereka tidak ingin tumbuh dewasa, tetapi dalam luasnya, dan tidak ingin menjadi pemimpin tim.

Cara memperbaiki situasi

Selain dekomposisi dan diferensiasi peran timlid menjadi berbagai bidang arsitektur, kami membentuk apa yang disebut Flying Retaliation Units (VOC) dan menarik spesialis kendali mutu (QA) kepada mereka. Pertama, mereka lebih bebas daripada semua orang - belum ada produk baru, dan Anda dapat menulis test case dan test suite untuk regresi selanjutnya sekarang.

Kemudian ternyata aturan bisnis belum sepenuhnya dirumuskan, dan perusahaan tidak memiliki banyak orang yang tahu bagaimana aplikasi baru harus bekerja.

Kami telah menetapkan tugas berikut untuk QA:

• Kami membutuhkan dokumentasi terkini tentang aturan bisnis dan logika tempat aplikasi bekerja.
• Penganut logika bisnis baru diperlukan, dan tidak hanya manajer dan manajer teknis.

Karena kita memiliki aplikasi baru, dan kita perlu mengulanginya lagi, kita membutuhkan orang-orang yang dapat mengajukan pertanyaan seperti: bagaimana menangani kesalahan seperti itu, bagaimana aplikasi harus berperilaku dalam situasi seperti itu. Saya ulangi, kasus utama dijelaskan, tetapi iblis ada dalam rincian - 20% yang sama harus ditutup.

Kami mulai membuat microcommands dinamis. Terlepas dari kenyataan bahwa orang-orang tidak ditransplantasikan ke mana saja, tetapi terikat pada produk dari arah tertentu, seseorang dari QA yang secara metodis terlibat dalam pekerjaan proyek, yaitu, bertanggung jawab untuk:

• mengumpulkan pertanyaan dari pengembang, membuat kuesioner;
• organisasi dan rekaman pertemuan;
• formalisasi dokumentasi;
• menulis test case dan test suites terlebih dahulu.

Ketika kami mencapai garis finish, ini memungkinkan kami untuk menghubungkan agen outsourcing, tenaga penjual untuk pengujian untuk meningkatkan kecepatan persiapan untuk rilis. Kami memiliki sejumlah besar platform, apa yang saya daftarkan hanyalah alat yang kami gunakan. Misalnya, di SmartTV terdapat 6-7 platform, untuk masing-masing platform yang perlu Anda rilis secara terpisah, melakukan regresi terpisah, dll. Jika Anda memiliki kasus bisnis yang telah ditentukan, Anda dapat dengan mudah menghubungkan agen outsourcing dan outstaffer di sini.

Pengenalan VOC sangat melegakan Timlids. Mereka mendapat kesempatan untuk tidak terganggu oleh tugas-tugas manajerial, tetapi untuk membuat keputusan strategis mengenai pengembangan kode berdasarkan bahan yang dikembangkan.

Proyek "Pasukan Retribusi Terbang" memenuhi harapan, dan kami memasuki garis rilis tanpa saling membunuh.

Apa selanjutnya

2018 , — , , . . , , . «, ,» — .

, , 2016 Value Stream. , . , , . .

, , .

, , . , , , 2018 4 . , , , .

.

.

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

: , , , . . .

Program St. Petersburg TeamLead Conf hampir siap. Mari kita lakukan beberapa langkah, tambahkan sentuhan akhir untuk mengungkapkan semua topik yang direncanakan, dan mulai berbicara tentang laporan dalam blok. Untuk saat ini, Anda dapat secara independen mengevaluasi daftar laporan dan memesan 23 dan 24 September untuk keterampilan memompa rekan tim.