Saya akan mendeskripsikannya menggunakan contoh pengembang abstrak Tom. Tom mendapat pekerjaan di Internetmagazinzaden sebagai pengembang php menengah. Perusahaan membuat toko online dari templat hingga yang kompleks dengan banyak integrasi. Perusahaan ini memiliki semua Agile, SCRUM, stand-up dan retro terbaik. Tom telah bekerja selama 3 bulan dan semuanya berjalan dengan baik untuknya, dia meluncurkan beberapa IM, mereka bahkan bekerja dan pelanggan senang.
Di sinilah tugas baru untuk pengembangan IM, tetapi dengan integrasi dengan CRM. Tom mulai dengan tugas integrasi dan di beberapa titik dia gagal dan istilah itu membentang selama seminggu. Pada saat yang sama, pada rapat umum umum, Tom mengatakan bahwa dia "sedang mengatasi masalah", berharap dia sudah mendekati solusi. Tom beralih ke pengembang senior Mike (yang bukan mentornya dan hanya duduk tidak jauh dari Tom), dia mengarahkannya ke manual dan menjelaskan secara singkat apa yang perlu dilakukan.
Tom pergi untuk membaca tutorial dan mengatasi masalah tersebut. Setelah beberapa hari lagi, dia kembali ke Mike dengan pertanyaan tentang integrasi, dan bersama-sama mereka menyelesaikannya.
Tom pergi untuk menyelesaikannya selama beberapa hari, setelah itu dia kembali ke Mike lagi dan memberinya solusi terakhir. Mike memeriksa tugas tersebut dan menunjukkan beberapa bug kecil yang akan segera diperbaiki oleh Tom.
Tampaknya ini merupakan gambaran yang berfungsi, tetapi ada beberapa poin yang menunjukkan kepada kita bahwa Tom bukan lagi pengembang menengah seperti yang kita duga sebelumnya, tetapi Juni.
- Tom menghabiskan waktu yang sangat lama (dalam hal ini, seminggu) menangani masalah dan tidak memberi tanda masalah tepat waktu.
- Saya tidak bisa mengetahuinya dengan tutorial sendiri dan alih-alih mencari di Google beberapa momen yang tidak bisa dipahami, saya pergi ke Mike.
- Tom menghabiskan waktu pengembang lain daripada menggunakan stand-up dan mendiskusikan masalahnya di sana.
Terkadang pada wawancara untuk posisi pemimpin tim, mereka mengajukan pertanyaan "Bagaimana Anda membagi pengembang menjadi Juni, tengah, senior?" Dan jawaban saya kira-kira seperti ini:
- , ;
- , ;
- - .
Dalam kasus Tom, dia baru saja mendapatkan deskripsi tutorial dan implementasi dari Mike, tetapi dia tidak dapat mengetahuinya dan kembali ke Mike. Bagi saya ini adalah "panggilan" penting pertama yang kita tidak tengah. Panggilan penting kedua adalah bahwa skill “menandakan masalah” sangat penting bagi middle, dan jika dia tidak memilikinya, maka dari segi soft skill ini membawanya kembali ke junior. "Bel" ketiga adalah sikap ceroboh terhadap waktu pengembang lain yang melekat pada diri Juniors, yang terkadang tidak memahami pentingnya mengikuti proses dan beralih ke pengembang yang paling "baik" alih-alih memimpin dan mendapatkan mentor melalui dia. Ini penting, karena mungkin pengembang Mike sibuk dengan proyek yang sangat bertanggung jawab atau tugasnya membutuhkan konsentrasi tinggi, tetapi programmer John benar-benar duduk di meja sebelah,yang baru saja menyelesaikan sebuah proyek dan belum punya waktu untuk memulai proyek baru.
Mari pertimbangkan kasus lain. Pengembang senior Vasya telah bekerja di perusahaan sejak lama. Vasya memiliki pemimpin tim, Petya. Dan kebetulan Petya adalah pemimpin yang sangat bijaksana dan dia tidak hanya menetapkan tugas, tetapi bekerja sama dengan seorang analis sistem pada setiap aspeknya dan kemudian memberikannya untuk bekerja. Vasya dan Petya telah bekerja di perusahaan selama 4 tahun dan skema ini sudah diatur sebelumnya. Pada saat yang sama, Vasya dengan sempurna mengimplementasikan tugas-tugas sesuai dengan spesifikasi teknis tertulis, mendokumentasikan kode dan senang bahwa semuanya begitu "baik dan baik" dengannya.
Tapi nasib buruk, setelah beberapa saat perusahaan tutup dan Vasya harus mencari pekerjaan dan untuk beberapa alasan mereka mulai memenuhi syarat Vasya selama wawancara bukan sebagai senior, tapi sebagai perantara. “Bagaimana ini bisa terjadi? Di mana saya jatuh? " Dia bertanya pada dirinya sendiri.
Segalanya menjadi sederhana lagi, Vasya kehilangan keterampilan untuk menemukan solusi optimal untuk masalah tersebut, dalam 4 tahun analis sistem dan pimpinan tim yang peduli sangat mengendurkan Vasily sehingga keterampilan ini tidak lagi diperlukan.
Apa yang harus dilakukan dalam kasus ini? Paling sering, setelah menemukan ini di sebuah perusahaan, Anda tidak boleh mengambil rubel dari pengembang dan menurunkan gaji mereka (meskipun secara tidak langsung), tetapi bingung dengan pertanyaan "dapatkah ini diperbaiki?" Dan jika jawabannya "tidak", lebih baik mengucapkan selamat tinggal kepada karyawan dengan "baik hati", karena pada suatu saat dia akan merasa tidak senang karena gajinya tidak naik, dan anggota tim lainnya mungkin bermasalah dengan hal ini. Jika jawabannya ya, maka Anda memerlukan pekerjaan yang sangat cermat dari departemen pelatihan personalia dan pemimpin tim. Memang, dalam hal ini, Anda harus memompa keterampilan karyawan dan melakukannya selembut mungkin, agar tidak melukai harga dirinya dan memberinya motivasi untuk berkembang.