Ketika sebuah produk besar, pengembang melakukan ekstrem:
- kode terlalu indah - rilis lambat,
- terlalu banyak perhatian pada proses - sedikit perhatian pada pengembangan,
- Pengiriman cepat fitur baru dalam produksi - kode yang terlalu buruk,
- terlalu banyak perhatian pada autotest - sulit untuk melakukan perubahan,
- Kekhawatiran tentang kecepatan antarmuka - menghindari fitur baru,
- Perbaikan UI - sedikit perhatian pada arsitektur kode.
Dalam laporan itu, saya berbicara tentang cara menghindari hal-hal ekstrem ini dan mencapai kerja tim yang sukses.
- Saya ingin berbicara tentang cara hidup dalam tim besar. Sebuah tim besar adalah ketika ada lebih banyak orang daripada di ruangan ini.
Dan saya ingin mereka bekerja semulus orang-orang ini di GIF:
Saya tidak punya tim yang sangat besar, tetapi saya hanya sedikit memata-matai apa yang terjadi dengan tim besar di perusahaan secara keseluruhan, dan saya hanya ingin berbagi dengan Anda.
Untuk membayangkan skala, Anda harus mengatakan hal-hal yang sangat jelas. Yandex itu sedikit lebih dari sekadar halaman pencarian. Ada banyak dari kita, lebih dari 10 ribu
Dan di antara "banyak" ini, sebagian besar adalah pengembang. Kami membuat banyak produk berbeda, tidak hanya untuk web. Ada semua tentang barang, tentang mobil, tentang makan, semua jenis besi, kecerdasan buatan. Dan para pengembang terlibat dalam hal ini. Bahkan jika, tampaknya, kita berbicara tentang mobil atau makanan.
Kami memiliki banyak layanan. Mereka tidak muat di slide. Saya harap saya meyakinkan Anda bahwa Yandex sangat besar. Hal-hal besar sulit untuk dikelola.
Poin penting. Apa yang akan terus saya katakan adalah, pertama, penyederhanaan yang sangat kuat; kedua, saya mengalami penyimpangan memori, jadi saya akan menafsirkan sesuatu; ketiga, beberapa hal yang sengaja saya biasakan dengan sedikit demi koherensi cerita, dll. Sangat tidak berdalih. Gagasan umum, sementara itu, akan benar.
Saya akan mulai dari masa lalu. Saya kemudian datang ke Yandex. Maka itu diatur sangat berbeda dari sekarang. Divisi ini dengan spesialisasi - keren untuk pengembang. Itu terlihat seperti ini. Perusahaan secara struktural dibagi menjadi manajer, mereka melakukan sesuatu di antara mereka sendiri. Ada spesialisasi lainnya. Sebenarnya, tidak ada desainer saat itu, tapi itu menyampaikan artinya. Dan, tentu saja, ada pengembang. Di dalam struktur ini, itu kemudian dipotong menjadi fragmen yang bahkan lebih kecil.
Para pengembang menggunakan gergaji atau tang. Ada cowok di topi dengan smoothie, cowok di helm lebih hardcore, desainer yang tidak ada di sana, dan manajer yang mendapatkannya untuk semua orang. Karena itu mereka bersiap.
Jika Anda mempelajari kisah ini, maka di dalam hierarki adalah sesuatu seperti ini. Ada pria di helm paling keras, yang mendapatkan semua benjolan. Dia memiliki manajer yang halus di bawah komandonya, kemudian yang kurang parah. Saya melebih-lebihkan, tetapi idenya jelas. Dan hierarki yang sama berfungsi untuk setiap spesialisasi.
Dudes dengan smoothie dalam topi bekerja dengan cara yang sama, dan itu menyenangkan. Anda adalah seorang pengembang, Anda mematuhi pengembang lain, dia mengerti apa yang Anda lakukan, dia memuji Anda untuk sesuatu yang dia sukai. Bagus
Tetapi anggaplah suatu ide datang ke suatu produk. Dan dia hanya memiliki manajer bawahan lainnya - ini jika dia beruntung dan setidaknya dia memiliki seseorang yang bawahan. Semua yang lain tidak mematuhinya sama sekali, tetapi entah bagaimana idenya perlu diwujudkan.
Dan dia berkata, “Desainer Kepala Kamerad, saya punya ide keren. Saya butuh desainer. ” Dia akan menjawab: “Ya, pertama, idenya aneh, dan kedua, semua desainer sibuk dengan saya. Datanglah ke Q5. "
Jika manajer memercayainya pada saat ini, ia tidak akan memiliki apa-apa. Jika dia gigih, berbakat, dan siap untuk melewati semua kesulitan, mungkin dia akan meyakinkan kepala desainer ini. Dia akan berkata - oke, dalam dua bulan kamu akan menerima pria ini, dia pasti bebas. Bung, tentu saja, batas waktu akan terisi dan dilepaskan dalam empat bulan, tetapi setidaknya akan ada peluang untuk pengembangan proses.
Kemudian manajer ini akan pergi ke pengembang utama, mengatakan: "Saya punya desain keren, ide yang luar biasa. Saya butuh back-end. " Dan semua ini akan berlanjut: "Backender sedang sibuk, Anda punya ide begitu-begitu, desainnya buruk."
Pada akhirnya, ia dapat membuat dirinya menjadi tim pengembangan dan melakukan sesuatu. Di satu sisi, dengan cara ini hanya ide paling keren yang bertahan, di sisi lain, sangat sulit untuk melakukan sesuatu.
Tapi untuk pengembang, ini keren. Pengembang dievaluasi oleh pengembang lain. Pengembang, tentu saja, menyukai semuanya teknis. Dan tentang toko kelontong biarkan manajer terlebih dahulu meyakinkan bahwa ini adalah ide yang keren. Dan karena fakta bahwa semua pengembang dalam struktur yang sama berkomunikasi satu sama lain, setiap orang memiliki pihak yang sama, pertukaran keahlian teknis sangat mapan. Dengan keahlian produk, segalanya tidak terlalu keren, tetapi siapa yang peduli? Dan banyak penelitian, karena ini untuk penggemar. Akan dievaluasi oleh pengembang lain yang juga penggemar. Anda dapat menemukan hal-hal berteknologi tinggi.
Jelas, pendekatan ini memiliki masalah. Pengembang tidak terlalu khawatir tentang apa yang terjadi dengan produk, karena mereka tidak mematuhi manajer. Manajer helm akan diejek jika terjadi kesalahan, tetapi mereka tidak memiliki pengaruh khusus pada pengembang. Dan produknya, pada gilirannya, cukup sulit untuk diubah. Mereka dapat, pada kenyataannya, hanya membujuk, meyakinkan, dan entah bagaimana menari untuk membuktikan bahwa ide mereka keren. Kemudian pengembang akan mempercayainya dan, tentu saja, akan membuat semuanya sakit.
Tetapi ternyata dari deretan pengembang besar ini Anda harus mengambil seseorang secara kebetulan, semua orang melakukan sesuatu yang menarik - tetapi untuk merakit hal yang besar dan kompleks, yang terus berinteraksi merupakan masalah.
Sementara itu, semua ini terjadi, perusahaan mengambil dan tumbuh dua kali dalam setahun. Dan Anda perlu melakukan sesuatu. Seperti yang dikatakan Arkady Volozh, mengelola sebuah perusahaan seperti menggoreng bakso. Itu perlu terus-menerus diserahkan.
Struktur perusahaan berubah. Alih-alih membagi semua orang dengan spesialisasi, membaginya dengan produk. Dan manajer menjadi pria yang jauh lebih penting.
Ternyata sekitar skema seperti itu, jika sangat disederhanakan dan sangat dibesar-besarkan. Kami memiliki sebagian besar produk, di dalamnya pecah menjadi bagian-bagian yang lebih kecil, dan untuk setiap bagian, tim yang lengkap menonjol. Ada desainer, pengembang, manajer, dan mereka semua membuat produk ini.
Tampaknya masalah itu dirawat, tetapi ada masalah baru. Tim bisa sangat kecil, dan secara alami akan ada satu front-end, satu back-end, satu desainer, setengah analis, dan orang lain. Mereka klise dengan tidak ada yang berbicara tentang bidang subjek mereka, dan tampaknya ini tidak diperlukan. Mereka melihat proyek mereka, tetapi semua penemuan yang mereka terima dalam proses, mereka tidak memiliki siapa pun untuk disampaikan, mereka tidak memiliki siapa pun untuk bertanya bagaimana melakukan yang lebih baik. Mereka tidak tahu apa yang mereka lakukan di balik tembok yang berdekatan, dan mungkin mereka melakukan hal yang sama. Apalagi mereka langsung melakukan hal yang sama secara alami.
Manajer tampaknya memiliki lebih banyak kekuatan, tetapi ia tidak memahami semua seluk beluk perkembangan dengan baik. Pengembang yang berbakat, jika diinginkan, dapat memberitahunya bahwa tanpa penulisan ulang proyek yang lengkap, sama sekali tidak ada. Dan apa pilihan manajer selanjutnya? Entah dia akan mempercayainya, atau dia akan melarangnya untuk melakukannya, semua orang akan merasa tidak puas. Secara umum, ada masalah.
Saya ingin menyeimbangkan segalanya dalam hal produk. Misalnya, produk memiliki tim dan, misalnya, percaya bahwa kode yang indah itu penting. Dan sementara mereka mengasah kode ini ke ideal, jelas bahwa rilis sedang ditunda. Tidak keren. Atau tim berpikir: "Oke, kalau saja ada proses keren, dan kode itu akan terjadi entah bagaimana". Padahal, tidak, itu tidak terjadi. Hal ini juga perlu diperhatikan oleh seseorang.
Atau tim mengatakan: "Kita harus bergerak maju dengan sangat cepat, penting bagi kita untuk menggulirkan fitur setiap hari," tetapi pada saat itu kualitas kode tidak lagi fokus. Atau tim mengatakan: “Oke, terakhir kali kami menyapu, kami menyadari bahwa kualitas itu penting. Mari kita tutupi semuanya dengan autotest. ” Autotests ditulis untuk setiap fitur, tetapi sekarang tes ini harus dijalankan pada setiap permintaan kumpulan, dan mereka membutuhkan waktu lama untuk menyelesaikannya, dan semuanya menjadi lambat.
Atau: “Kami tahu bahwa pengguna kami, jika antarmuka lambat, akan pergi. Mari kita buat antarmuka yang cepat. " Tapi kemudian ternyata setiap fitur baru adalah kode tambahan yang perlu dikirim melalui jaringan dan dieksekusi, dan memperlambat antarmuka. "Kalau begitu, jangan membuat fitur baru - semuanya akan bekerja lebih cepat." Atau: “Pengguna suka ketika cantik. Ayo lakukan dengan indah. ” Tetapi tidak masalah apa yang ada di dalamnya.
Dalam mencari keseimbangan ini, ternyata sesuatu perlu diubah lagi. Sementara itu, tim ini tumbuh secara dramatis lagi.
Bagaimana ini biasanya diselesaikan? Ambil kata kunci. Kami juga mengambilnya. Kami memiliki scrum yang cukup umum, tetapi dengan penemuan kami sendiri. Apa isinya? Dikatakan bahwa mari kita mendinginkan staf tim sehingga semua orang bertanggung jawab untuk hasil akhir, ada semua keahlian yang diperlukan. Dan biarkan tim ini memilih tugas mana yang harus dilakukan terlebih dahulu, pilih proses mana yang harus mereka miliki di dalam. Secara umum, suatu produk lebih penting daripada proses. Itu saja. Kedengarannya bagus. Tampaknya bahkan memecahkan sebagian dari masalah.
Namun masih ada masalah. Misalnya, diasumsikan bahwa tim scrum seperti itu terus-menerus beradaptasi dengan apa yang terjadi di sekitar mereka, terus berubah (komposisi mereka berubah, mereka dapat terus-menerus terbentuk, bubar), dan, pada prinsipnya, tidak ada tempat umum di mana sejarah pengembangan karyawan dikumpulkan.
Artinya, ada semacam pengembang dan dia memiliki beberapa kekuatan, dia membakar suatu tempat. Dan jadi dia masuk ke tim scrum baru, dan mereka tidak tahu tentang kekuatan ini, dan mereka tidak mulai menggunakannya di sana. Dan, sebaliknya, mungkin dia tidak bertahan dalam sesuatu, tidak ada orang yang tahu tentang hal itu, memastikan bahwa dia dipompa dalam hal ini, dan memastikan bahwa proyek tersebut tidak menderita dari kenyataan bahwa ia tidak memiliki keahlian di sana.
Dan ada solusi yang sekarang kami coba terapkan di bagian perusahaan yang terpisah dan lihat apa yang terjadi. Idenya adalah sebagai berikut. Ada beberapa struktur yang cukup stabil di mana ada hubungan antara pengembang dan pemimpinnya, juga pengembang. Semuanya seperti di awal, ketika pemimpin memahami apa yang Anda lakukan, berbagi minat dengan Anda, dia dapat memberi tahu Anda sesuatu dalam hal cara bekerja lebih efisien dan membantu Anda di suatu tempat. Tautan ini telah dipelihara sejak lama selama beberapa tahun.
Untuk memenuhi kebutuhan produk, bersama dengan struktur stabil yang konstan, tim scrum virtual cepat masih dibentuk untuk setiap produk, dan bahkan untuk setiap aspek individu dari produk. Sekarang saya akan memberi tahu Anda lebih banyak tentang hal itu.
Tim bersifat sementara, cepat, mereka dapat fokus pada beberapa hal paling kritis saat ini.
Itu terlihat seperti ini. Di sini kita memiliki beberapa bagian kecil, misalnya web. Dan di dalam, jika Anda melihat, sejumlah besar orang yang melihat web ini.
Beginilah cara menyeimbangkan keseluruhan cerita. Ada dudes hijau, mereka bertanggung jawab untuk memastikan bahwa antarmuka cepat. Dan yang menarik bagi mereka adalah bahwa semuanya harus sekeren mungkin menurut metrik kecepatan. Biarkan semuanya menjadi sesuka Anda. Tapi ada dudes lain yang pada prinsipnya kecepatan tidak begitu penting, tetapi penting untuk beberapa waktu kami berhasil meluncurkan banyak fitur keren baru untuk pengguna dalam produksi. Dan sekarang situasinya tidak mungkin sehingga pria akan mengatakan: "Kecepatan adalah yang paling penting. Jangan jalankan apa pun. " Karena untuk tim itu secara fundamental tidak dapat diterima.
Tetapi sebaliknya, tim yang bertanggung jawab atas fitur tidak dapat lagi melemparkan banyak kode baru dan berkata: "Jadi kami harus memulai fitur, semuanya menjadi lebih lambat, tetapi kami memulai fitur". Mereka akan setuju satu sama lain, entah bagaimana saling membantu, dan pada akhirnya semuanya akan baik-baik saja. Dudes biru sedang menulis tes dengan panik, terus-menerus. Dan mereka menutupi semuanya dengan tes, dan sekarang ada banyak tes, dan mereka semua bekerja dengan lambat. Dan dudes tidak peduli, karena mereka hanya bertanggung jawab untuk pertanggungan.
Tapi itu bagus bahwa ada orang lain yang mengatakan: "Tapi penting bagi kita bahwa proses pengembangan secara keseluruhan cepat. Dari saat kami menetapkan tugas ke saat ketika pengguna kami mulai menggunakannya, periode waktu ini harus dikurangi. " Dan mereka akan setuju, dan semuanya akan baik-baik saja. Mereka akan membantu orang yang menulis tes untuk membuat tes ini berjalan lebih cepat.
Seseorang hanya bertanggung jawab untuk memastikan bahwa semuanya keren secara arsitektur. Selain itu, mereka bahkan mungkin tidak perlu memikirkan apa yang terjadi saat ini dalam kode. Mereka dapat berpikir dalam hal: "Dan kemana semuanya harus berjalan dalam satu setengah tahun?" - dan sekarang fokus pada masa depan ini. Tetapi pada saat yang sama akan ada seseorang yang memperketat sudut-sudut bundar, mengoreksi bayangan dan berpikir tentang animasi sehingga pengguna lebih bahagia besok. Dan ketika ada pembagian tanggung jawab seperti itu, dan masing-masing tim saling melengkapi, keseimbangan diperoleh.
Ada beberapa peran untuk ini semua. Saya sudah mengatakan sesuatu tentang ini, tetapi, bagaimanapun, ini adalah hal yang penting. Masing-masing memiliki atasan langsungnya, yang tahu segalanya tentang dia dan memastikan bahwa seseorang tumbuh secara profesional, tumbuh secara pribadi dan bahagia. Pada saat yang sama, ada pemimpin tim semacam itu yang mengatakan bahwa cakupan tes harus tumbuh, dan yang lainnya kurang penting. Dan ketika dua peran seperti itu terjadi secara simultan, ternyata kurang lebih baik.
Dan ada beberapa hal berbeda yang berbeda. Dalam situasi seperti itu, ternyata bagi pengembang yang terlibat dalam produk yang sama, yang dikumpulkan dari struktur yang berbeda menjadi tim virtual, perhatian lebih besar diterima dari manajer yang berbeda. Dan secara total, pengalaman ini memungkinkan produk menjadi lebih baik ...
... dan kemudian pindah ke produk lain yang dilihat oleh manajer struktural, beberapa penemuan yang muncul selama pekerjaan tim besar ini. Atau sebaliknya, yaitu, panah-panah ini dapat diputar ke arah yang berlawanan, dan ini juga akan benar. Ternyata meluap dan keahlian, dan cara entah bagaimana nyaman untuk merakit kembali tim menjadi produk di mana itu lebih penting sekarang. Dengan demikian, jumlah perhatian pada produk yang berbeda dari kawan yang paling berpengalaman di perusahaan meningkat.
OK, semacam menyetujui bagaimana semuanya harus bekerja. Tetapi jika kita memiliki bos struktural dan bos tentang suatu produk, bagaimana kemudian mengevaluasi apakah semuanya berjalan baik? Sergey Berezhnoy membicarakan hal ini secara rinci pada tahun sebelum Sabtu lalu. Saya akan mengulangi ide umum secara singkat.
Keputusan apakah seseorang telah bekerja dengan baik dibuat, pertama, dibandingkan dengan peserta lain dalam proses, dan kedua, secara kolektif oleh semua pihak yang berkepentingan. Yaitu, pemimpin strukturalnya, yang memantau bagaimana ia berkembang dalam segmen jangka panjang, dan orang yang bertanggung jawab atas tugas produk jangka pendek dan memperkirakan bukan dalam hal fakta bahwa orang itu berusaha keras dan tidak tidur di malam hari, tetapi dalam hal tentang bagaimana dia benar-benar mencapai tujuannya. Dan ini adalah suatu cara yang menurut kami paling adil saat ini. Jika Anda menonjol, bahkan tanpa terlalu memaksakan - tampan, mari kita memuji Anda. Keseimbangan seperti itu bagi kita tampaknya bekerja, bagus.
Manfaat tambahan. Ketika kami sepakat bahwa kami dapat dengan cepat mengumpulkan tim individu, mengumpulkan kembali orang-orang untuk setiap kebutuhan spesifik, menjadi penting bahwa transisi ini sesederhana mungkin. Dan ini hanya mungkin jika semuanya dijelaskan, didokumentasikan dengan baik. Konstruksi seperti itu sendiri memaksa perlunya dokumentasi. Dan ketika menulis dokumentasi, produk secara otomatis menjadi lebih baik secara keseluruhan. Itulah manfaatnya dalam dua arah.
Selain bertukar keahlian, transisi orang membuat produk yang berbeda lebih mirip satu sama lain - baik dalam hal penampilan mereka maupun dalam hal bagaimana mereka diatur di dalam. Anda juga dapat mengambil manfaat dari ini - pengguna memahami cara menggunakan sistem, karena mereka hanya menggunakan hal serupa pada proyek lain. Dan tentu saja, Anda akhirnya dapat menggunakan kembali praktik terbaik.
Tim semacam itu fokus pada setiap aspek secara terpisah: mereka bisa menulis tes, atau bertanggung jawab untuk kecepatan, atau untuk kecantikan - tetapi mereka masih tidak bisa menilai apa yang terjadi dengan tetangga. Faktanya adalah bahwa pemimpin mereka bertanggung jawab untuk pengembang di tim lain, dan mereka sendiri dapat segera pindah ke tim lain. Jelas bagi mereka bahwa, dengan syarat, besok itu akan mempengaruhi mereka. Karena itu, ketika fokus, tanggung jawab untuk semuanya secara keseluruhan tidak hilang. Akibatnya, beralih antar proyek cukup mudah.
Pada saat yang sama, orang memiliki banyak peluang untuk tumbuh. Karena dalam suatu struktur di mana segala sesuatu dibentuk dalam granit dan tidak bercampur, orang-orang pada satu titik sampai pada situasi bahwa mereka sudah memahami segalanya. Mereka mencoba semua yang ada di proyek ini dan mengikuti arus. mereka tidak perlu melakukan upaya yang tiba-tiba pada diri mereka sendiri setiap saat. Dan jika mereka terus-menerus harus mengubah tim, terus-menerus mengubah sudut kelanjutan dari bakat mereka, keahlian mereka secara otomatis tumbuh, semua ini memperkuat sistem secara keseluruhan. Lagi pula, itu tidak membosankan. Sepertinya Anda tidak akan setuju dengan ini.
, : « , , ?». , . , , . , - , , .
, . , , . ? , , , , .
,
. , - , , . , . , , — , , , : «, , . ».
, — . , , , , , ? . . , , , . , , . . , — , , , . -, , .
: — , , , , . — . .