Tampaknya banyak yang Yandex adalah perusahaan monolitik besar dengan proses yang diatur secara ketat, tetapi ini tidak demikian. Kami terus mencari arah baru, memulai proyek baru dan mencoba pasar baru. Layanan untuk konsultasi online dengan Yandex.Health adalah salah satu startup internal klasik.
Saya datang untuk memimpin pengembangan Kesehatan pada saat layanan masih berupa halaman dengan penjelasan singkat tentang wiki internal. Dalam posting ini saya ingin berbagi pendekatan pengembangan yang telah kami kembangkan selama dua setengah tahun bekerja pada layanan ini.
Penafian:Sebuah startup memiliki karakteristiknya sendiri. Tugas utama kami adalah melakukan jumlah percobaan maksimum per satuan waktu dan mengeluarkan fitur produk pada kecepatan setinggi mungkin. Pada saat yang sama, kita harus menjaga kualitas produk pada tingkat tertentu sehingga tidak memalukan untuk itu.
[Tempat untuk nyala api tentang kurangnya hati nurani beberapa orang] . Saya perhatikan bahwa kecepatan tinggi pengiriman fitur menyiratkan, antara lain, mempertahankan kode kualitas yang cukup tinggi. Jika tidak, produk cepat atau lambat akan tersedak bug.
Semua poin di bawah ini entah bagaimana menderita, hampir setiap orang memiliki kasus dari kehidupan nyata.
Kualitas dan Arsitektur Kode
- Kami meminimalkan waktu untuk menghadirkan fitur pada produksi dengan tetap menjaga kualitas yang dapat diterima.
- Tugas apa pun melibatkan dua solusi: cepat dan benar. Untuk fitur apa pun, kami memikirkan kedua opsi tersebut sehingga dimungkinkan untuk meningkatkan solusi cepat ke solusi yang benar, menjadikan pekerjaan "ejeksi" menjadi minimum. Setelah meluncurkan solusi cepat, kami mencari beberapa saat dan memahami jika yang tepat diperlukan.
- Secara kritis. Seringkali, perbedaan waktu antara "menyelesaikan cara pertama yang Anda dapatkan dengan mencetak kruk" dan "menyelesaikan dengan indah dan akurat" adalah sepuluh menit. Karena itu, kami selalu berpikir sebelum menulis.
- Jika ada pilihan antara optimasi kecil dan keterbacaan / arsitektur - pilih yang kedua. Dua milidetik tidak akan menyelesaikan apa pun, dan dengan kode ini kita masih harus hidup dan memelihara.
- Kami sedang memikirkan masa depan. Masa depan yang dekat lebih penting daripada prospek yang jauh. Jika keputusan dapat dibuat sulit (baca "panjang") dan fleksibel, atau sederhana, tetapi dipaku, ada baiknya dipaku dan kemudian refactoring seperlunya. Lebih baik menghabiskan satu hari untuk solusi sederhana sekarang dan sebulan untuk kemungkinan refactoring dalam setahun, daripada dua minggu sekarang (ya, inilah yang disebut utang teknis). Penting bahwa keputusan seperti itu layak dibahas dengan tim. Saja, Anda dapat menilai secara keliru kemungkinan perluasan fitur ini dalam waktu dekat.
Teknologi baru
Teknologi baru itu keren, mari kita gunakan. Tetapi produk kami bukan tempat uji coba. Jika Anda ingin menerapkan algoritma atau teknologi baru, ini dapat dilakukan dengan ketentuan sebagai berikut:
- teknologi membawa keuntungan nyata (optimasi, kualitas arsitektur, kode, skalabilitas, dan semua ini benar-benar harus dibutuhkan, dan tidak dibuat-buat);
teknologi ini biasanya masuk ke tumpukan saat ini (Anda tidak perlu menulis beberapa layanan on Go jika semua kode ditulis dengan Python); - teknologi tidak menurunkan kualitas arsitektur dan keterbacaan kode (ini subyektif, oleh karena itu, dibahas dengan tim);
- Tidak perlu lagi waktu untuk menerapkan dan mendukung teknologi baru (termasuk mencari pengembang baru) selain bekerja dalam kerangka teknologi saat ini. Sekali lagi, semuanya tergantung pada laba yang diharapkan dan didiskusikan dengan tim;
- setiap teknologi baru didiskusikan dengan tim: jika itu keren, maka itu tepat bagi semua orang untuk menggunakannya, jika tidak benar-benar, maka diskusi kelompok memungkinkan Anda untuk dengan cepat memahami hal ini;
Anda tidak perlu mengimplementasikan algoritme yang sudah diterapkan secara mandiri di perpustakaan yang sudah jadi (kecuali untuk kasus ini adalah bagian kecil dari kerangka kerja besar dan tidak masuk akal untuk menyeret semuanya untuk satu solusi). - jika Anda melakukan sesuatu yang keren dan nyaman, bagikan solusinya dengan tim (atau lebih baik, di dalam Yandex).
Komunikasi
- Kami mendiskusikan solusinya bersama. Semakin kompleks dan kritis fungsionalitasnya, semakin penting diskusi semacam itu. Jika seseorang tidak menyukai solusinya, kami saling meyakinkan sampai kesepakatan tercapai. Atau waktu diskusi tidak akan melebihi waktu yang wajar.
- Jika tidak memungkinkan untuk setuju, kata terakhir terserah pada kepala. Kami memiliki demokrasi yang masuk akal, bukan Sejm Polandia abad ke-17 . Pada saat yang sama, pemimpin menerima minus besar dalam karma dan harus mengalami penderitaan moral. Dan tentu saja tidak sering menggunakan hak ini.
- Setelah kami memutuskan, kami melakukan sesuai kesepakatan. Bahkan jika saya sangat tidak setuju. Tidak ada "Saya tahu lebih baik dari semua pakar produk ini cara membuat layanan, jadi saya akan melakukan apa yang menurut saya perlu"
- "Tidak di prod - tidak dilakukan." Setiap orang mengikuti tugasnya sendiri. Jika fitur ini siap untuk pengujian, Anda perlu memastikan bahwa itu masuk ke pengujian. Jika dia siap untuk rilis, Anda harus memastikan bahwa dia masuk ke dalam produk sesegera mungkin. Orang-orang yang bertanggung jawab untuk pembentukan rilis tidak selalu ingat tentang setiap fitur. Jangan ragu untuk mengingatkannya. [Tempat untuk nyala tentang distribusi tanggung jawab antara peran dalam tim.] .
- Perlu untuk menghidupkan kepala. Jika tugas itu tampak aneh, tidak dapat dipahami atau terlalu lama, maka ini harus diberitahukan dengan jelas dan keras kepada manajer yang bertanggung jawab. Dan lakukan ini sampai Anda memiliki pemahaman yang jelas tentang mengapa semuanya harus seperti itu. Kebetulan pertanyaan yang tepat ditanyakan pada waktu yang tepat menghemat minggu pembangunan.
Manajemen waktu
- Jika tugas tidak sesuai dalam waktu yang wajar, kita harus membicarakannya dengan keras. Anda seharusnya tidak duduk dan memotong tugas selama beberapa bulan dengan penilaian tiga hari. Jika itu sangat menyeret, maka ada sesuatu yang salah. Mungkin ada kesalahpahaman dalam produksi atau kami meremehkan jumlah pekerjaan. Dalam kasus apa pun, tugas-tugas tersebut harus didiskusikan kembali (dan sebagai hasilnya, terkadang ditunda atau bahkan dikubur).
- Masalah yang muncul harus diselesaikan secara mandiri. Tetapi jika jelas bahwa prosesnya sedang tertunda, pastikan untuk membicarakannya dan minta bantuan dari rekan kerja. Menempel selama beberapa hari di negara bagian "Saya harus melakukan semuanya sendiri dan tidak mengganggu rekan-rekan saya" sangat buruk.
- Tidak ada yang melihat jam berapa kita masing-masing datang dan pergi sampai kita berhasil, dan rezim kita tidak mulai mengganggu pekerjaan tim. Tetapi duduk di malam hari hanya karena Anda tidak punya waktu untuk melakukan sesuatu tidak perlu. Jika ini berubah menjadi kebiasaan, maka masalahnya lebih dalam - dalam perencanaan, menilai kembali kemampuan sendiri, dll. Sementara pengembang lembur di malam hari (dan sebagai hasilnya semuanya tepat waktu), kemungkinan seseorang akan melihat dan menyelesaikan masalah ini sangat berkurang.
- Kebetulan kami perlu meluncurkan fitur penting pada tanggal yang disepakati (atau sesegera mungkin). Dalam hal ini, kami bekerja lembur. Selain itu, pemimpin menerima minus besar dalam karma dan harus mengalami penderitaan moral. Dan tentu saja tidak sering menggunakan kesempatan ini. Waktu lembur seperti itu diimbangi. [Tempat api tentang lembur dan kompensasi] .
Dosa berat
Ini adalah bagian yang terpisah. Di sini saya mencoba membuat daftar apa yang saya pikir salah dan berbahaya ketika bekerja dalam tim. Masing-masing item memiliki bobotnya sendiri. Beberapa berbicara tentang masalah yang sangat besar, yang lain tidak begitu kritis. Jadi, apa yang harus dihindari dengan segala cara:
- Bekerja, tidak termasuk kepala: "Saya disuruh melakukan - saya lakukan." Setiap anggota tim harus memahami esensi dari fitur yang ia buat dan dampaknya pada produk.
- Fitur melempar tidak mengempis ke dalam tusukan dengan kata-kata "Aku melakukan segalanya." Apa yang kita lakukan harus bekerja dalam produksi. Meskipun fitur ini tidak ada dalam prod, itu tidak siap.
- Setuju untuk melakukannya dengan satu cara, dan kemudian diam-diam melakukannya dengan cara Anda sendiri. Di atas sudah tentang "Aku tahu lebih baik daripada siapa pun apa yang lebih baik." Tetapi sekali lagi mengingat bahwa ini buruk tidak akan sakit.
- Kencangkan fitur-fitur penting, gali ke dalam diskusi tentang masalah langka dan tidak realistis, tetapi berpotensi terjadi. Jika dalam waktu yang masuk akal Anda tidak dapat menemukan cara untuk mengatasi masalah kecil dan jarang dapat direproduksi , kami hanya setuju tentang bagaimana hidup dengannya.
- Jangan menyuarakan masalah tepat waktu, mencoba menyelesaikan semuanya sendiri (biasanya di malam hari). Kepahlawanan seperti itu hanya mengarah pada kegagalan persyaratan, kelelahan, dan perasaan diremehkan: "Saya melakukan hal-hal di sini, tetapi saya juga dikritik karena pekerjaan yang lambat!"
- Sangat menyakitkan untuk bereaksi terhadap kritik terhadap kode dan masuk ke klarifikasi hubungan. Bahkan jika seorang kolega mengatakan bahwa kode tersebut adalah coprolit begitu-begitu ("mari kita menulis ulang semuanya!"), Perlakukan ini dengan pemahaman dan diskusikan mengapa ia berpikir demikian. Bagi Anda pribadi, ini tidak kurang bermanfaat daripada untuk layanan secara keseluruhan.
- Pergi ke orang itu. Mengkritik kode atau solusi, kami hanya mengkritik kode atau solusi, tetapi tidak dalam kasus orang yang menulis atau menyarankannya. Mengingat paragraf sebelumnya, jangan takut untuk mengkritik. Lebih baik waktu yang masuk akal untuk berdebat dengan rekan kerja daripada mengirim keputusan yang gagal kepada prod.
Total
Di sini Anda dapat menulis lebih banyak tentang sejuta hal. Tapi semakin pendek posnya, semakin mudah untuk membacanya
sampai akhir , dan saya sangat berharap begitu. Dan ya, saya tidak menerima kritik dengan susah payah (dengan syarat Anda tidak menjadi pribadi;). Jadi mari kita bahas!