Artikel hebat dari John Olspau ini berjudul "Menjadi Insinyur Utama" . Pertama kali saya membacanya sekitar empat tahun yang lalu, ketika saya baru saja beralih ke pekerjaan saya saat ini, dan itu benar-benar memengaruhi gagasan tentang bidang karier saya ini.

Setelah membaca ulang sekarang, ada satu hal yang tampaknya sangat menarik di sana, bahwa empati dan membantu tim adalah bagian penting dari pekerjaan senior. Yang mana tentu saja benar!

Tapi sekarang saya melihat bahwa sebagian besar atau semua insinyur terkemuka yang saya kenal mengambil bantuan yang signifikan untuk karyawan lain di samping pekerjaan pemrograman pribadi mereka. Sekarang saya merasa bahwa kolega saya dan saya dihadapkan pada masalah “Apa ?? Perlu BICARA DENGAN ORANG ?? INCREDIBLE ", seberapa banyak dengan masalah lain:" Bagaimana cara menyeimbangkan semua kepemimpinan ini bekerja dengan input / pemrograman individu Anda? Berapa banyak dan jenis pekerjaan apa yang harus saya lakukan? " Karena itu, alih-alih berbicara tentang tanda - tanda seigneur dari artikel Olspau (yang saya setujui sepenuhnya), saya ingin berbicara tentang pekerjaan yang sedang kami lakukan.

Tentang apa artikel ini

"Apa yang dilakukan seorang insinyur utama" adalah topik yang sangat besar, tetapi di sini hanya sebuah artikel kecil, jadi Anda harus ingat:

• Hanya ada satu deskripsi yang mungkin tentang apa yang dapat dilakukan oleh seorang insinyur terkemuka. Ada banyak pendekatan untuk bekerja, dan ini seharusnya tidak menjadi dogma.
• Saya hanya bekerja di satu perusahaan saja, jadi pengalaman dan pandangan saya jelas sangat terbatas.
• Jelas, ada banyak tingkatan "senior". Ini tentang level P3 / P4 dalam hierarki Mozilla (insinyur senior / insinyur staf), mungkin sedikit lebih dekat dengan level "staf".

Apa tanggung jawabnya?

Ini adalah hal-hal yang saya lihat lebih sebagai pekerjaan seorang insinyur utama dan lebih sedikit sebagai pekerjaan seorang manajer (walaupun manajer pasti melakukan beberapa hal di atas, terutama membuat proyek baru dan menghubungkan proyek dengan prioritas bisnis).

Hampir semua pekerjaan ini pada dasarnya bersifat teknis : membantu seseorang mengatasi proyek yang kompleks jelas merupakan interaksi manusia, tetapi masalah yang akan kita kerjakan bersama biasanya bersifat teknis! ("Mungkin, jika kita menyederhanakan desain, kita dapat mengatasinya lebih cepat!").

• Tulis kode (jelas).
• Buat ulasan kode (jelas).
• Tulis dan tinjau dokumentasi desain . Seperti ulasan lainnya, tampilan pihak ketiga kemungkinan akan membantu meningkatkan desain.
• Bantu kolega jika mereka mandek . Terkadang orang terjebak pada proyek, dan penting untuk membantu mereka! Saya berpikir tentang ini bukan tentang “terjun payung dari langit dan memberikan pengetahuan magis Anda kepada orang-orang”, tetapi tentang “bekerja bersama untuk memahami masalah dan melihat apakah dua otak dapat mengatasi lebih cepat dari satu” :). Ini juga berarti bekerja bersama, bukan menyelesaikan masalah, bukan orang lain.
• Pertahankan rekan kerja tetap tinggi . Untuk orang yang berbeda, "level" memiliki arti yang berbeda (untuk tim saya ini berarti keandalan / keamanan / kenyamanan produk). Jika seseorang membuat keputusan yang tidak saya sukai, itu berarti saya tahu sesuatu yang dia tidak tahu, atau dia tahu sesuatu yang saya tidak tahu! Karenanya, Anda tidak perlu mengatakan: "Hei, Anda salah, Anda harus melakukan X," tetapi lebih baik memberi mereka informasi tambahan yang tidak mereka miliki, dan sering kali ini menyelesaikan masalah. Dan cukup sering ternyata ada sesuatu yang hilang untuk saya, dan sebenarnya solusi mereka cukup masuk akal! Di masa lalu, saya kadang-kadang melihat insinyur terkemuka mencoba mempertahankan standar kualitas dengan mengulangi pendapat mereka lebih keras karena mereka menganggap pendapat mereka benar. Secara pribadi, saya tidak menemukan pendekatan seperti itu berguna.
• Buat proyek baru . Tim pengembangan perangkat lunak bukanlah tempat zero-sum! Insinyur terbaik yang saya tahu tidak meninggalkan pekerjaan yang paling menarik untuk diri mereka sendiri, mereka menciptakan proyek baru yang menarik / penting dan menciptakan ruang bagi orang lain untuk melakukan pekerjaan ini. Misalnya, seseorang dari tim saya mulai menulis ulang sistem penempatan kami. Proyek ini ternyata sangat sukses, dan sekarang seluruh tim bekerja pada fitur-fitur baru yang menjadi lebih mudah diimplementasikan!
• Rencanakan pekerjaan proyek Anda . Ini tentang menuliskan / melaporkan peta jalan untuk proyek yang sedang Anda kerjakan dan memastikan orang memahami rencana tersebut.
• Laporkan risiko proyek sebelumnya . Sangat penting untuk mengenali ketika sesuatu tidak berjalan dengan baik, memberi tahu insinyur / manajer lain tentang hal itu dan memutuskan apa yang harus dilakukan.
• Laporkan kesuksesan!
• Untuk melakukan proyek pihak ketiga yang menguntungkan tim / perusahaan . Saya melihat bahwa banyak manula terkadang membuat proyek kecil tapi penting (misalnya, membuat alat pengembangan / membantu menetapkan kebijakan), yang pada akhirnya membantu banyak orang melakukan pekerjaan mereka dengan lebih baik.
• Waspadai bagaimana proyek berhubungan dengan prioritas bisnis.
• Putuskan kapan harus menghentikan proyek . Ternyata sangat sulit dipahami ketika Anda perlu berhenti / tidak mulai mengerjakan sesuatu. :)

Saya meletakkan "menulis kode" di tempat pertama, karena pada kenyataannya tugas ini dengan mudah memasukkan daftar prioritas. :)

Tidak ada item "buat perkiraan / perkiraan" dalam daftar. Saya belum terlalu bagus di sini, tapi saya pikir suatu hari nanti akan layak menghabiskan lebih banyak waktu untuk itu.

Daftarnya tampaknya besar. Tampaknya jika Anda melakukan semua hal ini, maka mereka akan menyerap semua sumber daya intelektual Anda. Saya pikir secara umum masuk akal untuk mengisolasi beberapa bagian dan memutuskan: "Saat ini saya akan fokus pada X, Y dan Z, saya pikir otak saya akan meledak jika saya mencoba membuat B dan C".

Apa yang bukan kewajiban

Ini sedikit lebih rumit. Saya tidak mengatakan bahwa Anda tidak dapat menangani hal-hal semacam itu secara kategoris. Sebagian besar insinyur terkemuka yang saya tahu menghabiskan banyak waktu untuk memikirkan masalah ini, dan bekerja sedikit ke arah ini.

Tetapi bagi saya itu berguna untuk menggambar batas tertentu, karena beberapa orang memiliki rasa tanggung jawab yang tinggi terhadap tim dan perusahaan - dan mereka siap untuk mengambil segalanya, sebagai akibatnya mereka akan kelebihan beban dengan pekerjaan dan tidak akan dapat memberikan kontribusi teknis, yang sebenarnya adalah milik mereka. bisnis utama. Oleh karena itu, penetapan batas-batas tertentu membantu menentukan masalah apa yang masuk akal untuk meminta bantuan ketika situasi menjadi bergejolak. Batas Anda yang sebenarnya terserah Anda / tim Anda. :)

Sebagian besar dari berikut ini adalah pekerjaan manajerial. Penafian: manajer melakukan lebih dari apa yang tercantum di sini (misalnya, "membuat proyek baru"), dan di beberapa perusahaan beberapa di atas mungkin sebenarnya adalah pekerjaan seorang insinyur utama (misalnya, manajemen sprint).

• Pastikan bahwa setiap karyawan dihargai sesuai dengan kemampuannya untuk pekerjaannya.
• Pastikan pekerjaan itu didistribusikan secara adil.
• Pastikan orang bekerja sama dengan baik.
• Pastikan kohesi tim.
• Berbicara secara pribadi dengan setiap karyawan.
• Latih manajer baru, bantu mereka memahami apa yang diharapkan dari mereka (walaupun saya pikir programmer terkemuka sering benar-benar datang ke kegiatan seperti itu?).
• Kelola proyek pihak ketiga (di tempat kerja saya ini adalah pekerjaan insinyur mana pun yang memimpin proyek itu).
• Jadilah manajer produk.
• Pimpin manajemen sprint / tentukan tahapan kerja untuk masing-masing / lakukan rapat mingguan.

Ini berguna untuk menetapkan batasan secara eksplisit.

Baru-baru ini saya menghadapi situasi yang menarik ketika saya membahas tanggung jawab saya dengan manajer - dan kami menyadari bahwa kami memandangnya dengan sangat berbeda! Kami mengklarifikasi situasinya, dan sekarang semuanya beres, tetapi saya sadar bahwa sangat penting untuk menyepakati harapan. :)

Ketika saya mulai sebagai insinyur, pekerjaannya cukup sederhana - saya menulis kode, mencoba membuat proyek yang masuk akal, dan semuanya sempurna. Manajer saya selalu memiliki gagasan yang jelas tentang pekerjaan saya, tidak ada yang terlalu rumit. Sekarang situasinya telah berubah! Karena itu, sekarang saya percaya bahwa saya harus menentukan pekerjaan yang:

• Saya bisa melakukan / cocok jangka panjang untuk saya.
• Saya ingin melakukan / yang umumnya menyenangkan dan konsisten dengan tujuan pribadi saya.
• Berharga bagi tim / organisasi.

Kata-kata yang tepat akan berbeda untuk orang yang berbeda (tidak semua orang memiliki minat dan kekuatan yang sama, misalnya, saya tidak terlalu pandai dalam tinjauan kode!). Saya pikir karena alasan ini, lebih penting lagi untuk membahas topik ini dan menyepakati harapan.

Jangan puas dengan pekerjaan yang tidak bisa / tidak ingin Anda lakukan

Saya pikir sangat penting untuk berhenti bekerja yang tidak bisa saya lakukan atau yang tidak akan membawa sukacita dalam jangka panjang! Tampaknya tergoda untuk melakukan banyak pekerjaan, bahkan jika Anda tidak benar-benar menyukainya ("Oh, ini bagus untuk tim!", "Yah, seseorang harus melakukannya!"). Tentu saja, kadang-kadang saya mengambil tugas hanya karena mereka harus diselesaikan, tetapi saya pikir untuk kesehatan tim, sangat penting bagi karyawan untuk melakukan apa yang umumnya mereka sukai dan apa yang dapat mereka lakukan dalam jangka panjang.

Oleh karena itu, saya akan mengambil tugas kecil yang hanya perlu dilakukan, tetapi penting untuk tidak mengatakan pada saat yang sama: "Oh, tentu saja, saya akan menghabiskan sebagian besar waktu saya untuk apa yang saya lakukan dengan buruk dan apa yang tidak saya sukai, tidak ada masalah" :). Dan jika "seseorang" perlu melakukan ini, mungkin itu hanya berarti bahwa kita perlu mempekerjakan / melatih seseorang yang baru untuk mengisi kekosongan. :)

Saya masih harus banyak belajar!

Meskipun saya merasa bahwa saya mulai memahami apa itu "insinyur pemimpin" (sudah 7 tahun dalam karir saya), tetapi saya masih merasa bahwa saya perlu belajar lebih banyak tentang ini, dan saya akan tertarik untuk mendengar bagaimana orang lain mendefinisikan batasan. pekerjaanmu!