Halloween adalah waktu untuk berbicara tentang ketakutan. Saya bekerja sebagai manajer produk di perusahaan IT, jadi ini akan menjadi mimpi buruk pengembang. Tapi tidak biasa, tetapi yang muncul saat perubahan.
Ketika sebuah perusahaan berkembang, ia mengubah pendekatannya terhadap pengembangan, menciptakan produk-produk baru dan memperluas kemampuan produk-produk saat ini, menerima puluhan karyawan, dan mereka yang bekerja dengan cara lama dapat menemukan kesulitan untuk membangun kembali. Kami bersukacita atas perubahan itu, tetapi kadang-kadang, mengapa bersembunyi, kami takut terhadapnya. Saya telah bekerja sebagai manajer produk selama setahun dan selama ini saya telah menghadapi lima ketakutan utama tim saya. Hari ini saya akan berbicara tentang ketakutan ini dan bagaimana kami berhasil mengatasinya.
1. Takut menjatuhkan segalanya
Pengujian adalah cara pasti untuk merilis produk tanpa bug. Tetapi kadang-kadang tidak ada peralatan untuk memeriksa kode.
Kami membuat
DCImanager , panel untuk mengelola server dan pusat data, dan seringkali tidak mungkin untuk membuat kondisi di mana kode akan bekerja di lingkungan virtual. Misalnya, kami menambahkan dukungan untuk model switch, router atau PDU yang baru ke panel kontrol, tetapi tidak ada peralatan seperti itu di bangku tes.
Dalam beberapa kasus, pengujian dapat diabaikan, tetapi tidak untuk kita. Kesalahannya mahal. Anda tidak menginisialisasi hanya satu variabel, dan dalam setengah kasus sistem operasi akan berhenti diinstal. Anda salah dalam beberapa baris kode - dan pusat data akan "berbaring". Seperti yang Anda ketahui, tidak ada yang ingin bertanggung jawab atas pusat data yang "jatuh", jadi rasa takut ini ada di tempat pertama di tim saya (meskipun tidak terhubung dengan transformasi di perusahaan).
Bagaimana mengatasi rasa takut akan menjatuhkan segalanya- Semua pengembang tim membuat peninjauan kode untuk setiap fitur.
- Kami menyimpan daftar hal-hal yang tanpanya tugas tidak dapat dirilis.
- Setelah rilis pengembangan, kami menganalisis bahwa kami tidak memperhitungkannya. Kami menjelaskan secara rinci apa yang telah dilakukan dan perilaku apa yang telah diamati sehingga setiap saat Anda dapat kembali ke tugas dan mengembalikan semua yang ada dalam memori.
- Memperbarui basis pengetahuan secara konstan. Kami menyediakan waktu untuk dokumentasi untuk pengembang, berbagi pengetahuan di antara kami tentang hal itu. pelatihan dan stand-up.
- Dan yang terakhir. Kami menguji perkembangan kustom untuk pelanggan dengan mereka pada peralatan yang disediakan.
Setelah kami menambahkan kontrol agregasi port untuk switch yang ada. Jika kesalahan dibuat, pengoperasian peralatan jaringan di pusat data akan sepenuhnya dihentikan. Klien tiba di pusat data pada pukul tiga pagi dan mengendalikan situasi sehingga, dalam hal ini, ia akan segera kembali ke versi lama dan melanjutkan operasi peralatan. Kami bisa kehilangan akses jarak jauh, dan pusat data akan lumpuh.
2. Takut ditinggalkan tanpa tester
Pengembang kami menulis pengujian unit, dan setiap orang terlibat dalam pengujian manual. Tapi begitu ada force majeure, dan tim dibiarkan tanpa penguji manual. Kami tidak dapat merilis fitur, sehingga pengembang harus saling memeriksa.
Itu merupakan pukulan terhadap harga diri. Kebetulan semua programmer dari tim saya meninggalkan penguji (manual dan otomatis). Kembali ke pengujian manual untuk mereka - mundur selangkah. Orang-orang takut bahwa jika mereka bisa mengatasinya sendiri, penguji tidak akan dikembalikan kepada mereka. Tetapi rasa takut itu ternyata tidak berdasar, setelah beberapa sprint penguji mengambil tempat di tim, dan dari pengalaman kami belajar banyak hal berguna.
Apa manfaat pengujian silang- Mereka mengingat "masa muda" dan sekali lagi melihat perkembangan dari sisi penguji. Dalam beberapa kasus, tindakan tambahan ditambahkan untuk membuat hidup lebih mudah bagi penguji. Misalnya, membuat statistik untuk verifikasi.
- Mereka mengkonfirmasi fakta yang sudah lama diketahui bahwa pengembang tidak dapat menguji kodenya, karena ia menutup mata terhadap beberapa hal. Karena itu, mereka menguji kode masing-masing.
- Sekali lagi kami yakin bahwa penguji adalah bagian penting dari tim. Mereka bertanggung jawab atas kualitas fitur yang keluar dalam rilis.
3. Takut masuk ke tim lain
DCImanager dirilis pada 2013. Selama enam tahun, teknologi telah berubah, saatnya membuat versi baru, kami memutuskan untuk melakukannya dari awal. Kami membuat prototipe, menentukan MVP, dan memprioritaskan. Pengembangan versi lama dibekukan, tetapi mereka tidak dapat memulai yang baru - dua produk baru sudah disiapkan untuk rilis, semua kekuatan dikhususkan untuk mereka, kami harus menunggu sedikit. Selama jeda, pengembang saya akan menjadi tim proyek
BILLmanager , produk kami yang lain untuk otomatisasi hosting.
Dan kemudian rasa takut lain muncul. Para pengembang teknik dalam setiap arti kata produk takut menerima tagihan. Tampaknya bagi mereka bahwa ini bukan wilayah mereka, bahwa tidak menarik untuk memahami tumpukan akun. Saya khawatir itu akan menurunkan motivasi pengembang saya. Tidak seperti kami, tim penagihan bersukacita karena dibongkar.
Untuk beberapa sprint, kami mulai mengerjakan BILLmanager, dan pengalaman ini juga berguna.
Secara singkat tentang bagaimana implementasi berlangsung- Untuk meminimalkan tekanan beralih ke produk lain, tim tetap menjadi tim dan tidak bergantung pada orang-orang dari BILLmanager.
- Tugas dipilih sesuai dengan prinsip "Anda harus melakukannya kemarin, tetapi Anda tidak memiliki cukup tangan". Pakar produkologi membahas tugas-tugas itu, lalu ketika merencanakan sprint berikutnya, saya menerjemahkannya ke dalam tim.
- Pengembang BILLmanager adalah mentor kami. Resepsionis menerima semua pertanyaan, dan ketua tim mengatakan apa dan bagaimana cara kerjanya
- Kami memiliki dua standup. Awalnya kami pergi ke penagihan, lalu kami mendiskusikan hasilnya di dalam tim kami.
Apa manfaat yang dibawa pengembang dari pengantar ke tim lain- Produk lain adalah kode orang lain yang perlu Anda pahami; ditambah logika kerja lainnya untuk dipahami. Berkat mentor mentl dan kesabaran dari petugas eksekusi, kami berhasil membiasakan diri menagih, memompa keterampilan baru dan melihat perbaikan dengan cukup cepat.
- Tentu saja, kami memata-matai bagaimana beberapa hal bekerja di dalam tim lain. Tampaknya semuanya sama untuk semua orang, tetapi bagaimanapun caranya. Perbedaannya terletak pada detailnya. Mereka mengambil yang terbaik dan paling nyaman untuk diri mereka sendiri sebagai aturan (misalnya, mereka memata-matai dan, setelah sedikit berubah untuk diri mereka sendiri, mulai menggunakan papan scrum, mengadopsi beberapa poin dalam gaya kode, dll.).
4. Takut menjadi mentor / tinggal tanpa pemimpin tim
Perusahaan membutuhkan sebanyak mungkin programmer yang kuat, jadi ketika seorang pengembang memompa keterampilan keras dan pindah ke tingkat Menengah, pelatihan pemula menjadi tanggung jawabnya. Tetapi keseluruhan mentoring biasanya ada pada pemimpin tim. Jadi itu ada di tim kami, sampai pengalaman pengembang terkemuka sangat dibutuhkan di produk lain. Programer yang dibiarkan tanpa teamlade harus mengikuti pelatihan untuk pemula dan satu sama lain.
Menjadi seorang mentor itu menakutkan. Anda perlu mengalihkan perhatian dari tugas-tugas Anda, mendengarkan orang lain, menjelaskan apa yang kadang-kadang Anda sendiri pahami pada tingkat intuisi dan menjelaskan sedemikian rupa agar dapat dipahami. Jika Padawan tidak mengerti, ini masalah Anda. Jika dia melakukan kesalahan dan Anda tidak memperhatikan, Anda menjawab.
Saya tidak akan memberikan saran tentang bagaimana menjadi mentor yang baik, ini adalah topik untuk artikel terpisah. Tetapi kami berhasil, dan dari pengalaman yang agak menegangkan ini kami mempelajari yang berikut:
- Dalam menjelaskan, lebih banyak konteks perlu diberikan. Semuanya indah di kepala, dan ketika Anda mengatakannya, ternyata menjadi sobek dan tidak bisa dipahami.
- Seseorang seharusnya tidak hanya melihat kode dalam ulasan, tetapi memahami apa yang seseorang coba pecahkan dengan kode ini. Maka lebih mudah untuk memahami logikanya dan menemukan kesalahan.
- Berbagi pengetahuan sangat membantu: belajar merumuskan pikiran; letakkan segala sesuatu di rak di kepala Anda; saat Anda menjelaskan, Anda menemukan solusi terbaik untuk masalah tersebut.
5. Takut tidak belajar teknologi baru
Ketika jeda selesai, saatnya untuk memulai versi baru dari produk DCImanager. Tampaknya inilah saat yang telah lama ditunggu-tunggu. Sekarang, dengan tim yang penuh dengan orang-orang yang ambisius, kami akan memulai semuanya dari awal - tanpa melihat bug lama dan secara historis mengembangkan dependensi aneh dalam kode. Tapi ada tempat untuk ketakutan.
Selama beberapa tahun, teknologi telah maju jauh. Kami menulis versi lama di C ++ 11 dan menggunakan make, untuk yang baru kami memilih C ++ 17, CMake, Conan dan Docker. Tim perlu mempelajari semua ini dan belajar cara mendaftar. Jalan keluar berikutnya dari zona nyaman, tantangan dan pemikiran "bagaimana jika saya tidak bisa dan akan lebih buruk daripada yang lain", "bagaimana jika ada lebih banyak masalah yang menunggu saya, saya tidak akan mencari tahu dan mengusir saya." Kami masih menguasai teknologi baru, dan perjuangan melawan ketakutan ini masih dalam proses.
Cara belajar teknologi baru lebih cepat- Jangan malu untuk bertanya pada rekan yang lebih tua dan berpengalaman, jangan takut terlihat bodoh.
- Dokumentasikan untuk mempercepat proses pendatang baru dan jangan katakan hal yang sama 10 ribu kali. Pertahankan basis pengetahuan.
- Oke Google selalu ada untuk membantu. Jika tidak berhasil, lihat poin 1.
Bukan Ketakutan, tapi Tantangan
Saya mengambil eksperimen sebagai kesempatan untuk mempelajari hal-hal baru, menjadi lebih baik, dan saya mencoba membuat tim saya melihat ketakutan mereka juga. Saya pikir suasana hati para lelaki sangat tergantung pada saya. Ketika Anda percaya pada suatu produk dan pengembang, dengarkan mereka di stand-up dan analisis masalah dalam retrospeksi, dukung mereka dalam masalah dan jelaskan perlunya perubahan, maka lebih mudah bagi mereka untuk mengatasi ketakutan.
Tapi jujur saja, kita masih punya beberapa fobia tak terkalahkan. Ketakutan akan tenggat waktu, misalnya, atau takut tidak cocok dengan pemula. Sejauh ini, tampaknya tidak ada yang bisa dilakukan terhadap mereka - hanya memasang. Tapi mungkin pada saatnya nanti pandangan kita akan berubah.
Kenapa kamu takut
PS Jika Anda ingin menjadi yang pertama melihat versi demo DCImanager - kirim kontak ke bizdev@ispsystem.com dengan subjek "Saya ingin melihat DCImanager baru". Ketika sudah siap, kami akan menulis kepada Anda. Atau jika Anda memerlukan produk untuk manajemen server, tetapi DCImanager saat ini karena alasan tertentu tidak cocok dan tidak ada solusi yang sesuai di pasaran, tulis keinginan Anda untuk perangkat lunak tersebut, mungkin kami akan memasukkan sesuatu dalam rencana pengembangan.