Geekly articles weekly

Identitas Masalah Di Antara Pengembang



Di gurun bakat yang memenuhi syarat, pengembang air laris seperti air, bahkan jika mereka dibawa dengan tangan atau dihina, tetapi ini adalah fakta. Tanpa mereka, tidak akan ada industri, dan mereka sendiri sangat menyadari hal ini. Ini mengarah pada perasaan hak diri yang menarik, yang jarang terlihat dalam sejarah manusia. Akibatnya, seluruh spektrum kepribadian masalah yang sangat cerah lahir.

Pengembang yang baik bisa bernilai emas - secara harfiah . Dalam beberapa profesi, pemasukan seperti itu dimungkinkan. Beberapa orang terkaya di planet ini dulunya adalah programmer, jadi menjadi pengembang pada waktu yang tepat di tempat yang tepat adalah salah satu jalan termudah dan paling langsung menuju kekayaan besar.

Tetapi dengan kesempatan seperti itu sering muncul kurangnya rasa hormat terhadap peserta proyek dalam profesi lain. Kurangnya rasa hormat ini bisa berubah menjadi begitu dalam sehingga memunculkan keyakinan kuat pada pikiran pengembang bahwa ia bukan hanya peserta paling berharga dalam proyek perangkat lunak, tetapi juga diperlukan bagi perusahaan secara keseluruhan. Sayangnya, meskipun hanya sejumlah kecil pengembang yang dapat mengakumulasi apa pun yang menyerupai kekayaan, banyak yang berperilaku seolah-olah mereka mengikuti Mark Zuckerberg, Bill Gates atau Steve Jobs; meskipun sangat jauh dari kebenaran. Ini mengarah pada masalah kepribadian, yang sama menariknya untuk dilihat dari sisi seperti menakutkan untuk direnungkan dalam diri Anda.

Berikut ini adalah identitas bermasalah di antara pengembang perangkat lunak:


Prima donna


Pengembang sangat yakin akan perlunya ia menjadi sombong dan tidak mungkin untuk memimpin.


Masalah


Pada level tertentu, untuk mengelola karyawan, dia harus melakukan apa yang Anda katakan. Primadona tidak dapat dikontrol, karena pada dasarnya ia tidak percaya bahwa itu bekerja untuk Anda. Menurutnya, adalah hak istimewa Anda untuk bekerja dengannya. Dia menganggap dirinya sangat diperlukan dan benar dalam setiap diskusi.

Berlawanan dengan keyakinannya sendiri, primadona tidak selalu merupakan pengembang yang berkualitas (lihat tipe bintang rock ). Kesombongannya didasarkan pada presentasi tempatnya di organisasi, dan bukan pada keterampilan teknis yang sebenarnya. Akibatnya, prima donnas terlalu sering menilai tingkat keterampilan mereka jauh lebih tinggi daripada rekan-rekan mereka, meskipun ini sebenarnya tidak terjadi . Ini biasanya mengarah pada fakta bahwa diva biasanya tidak disukai oleh rekan kerja.

Anda dapat mengidentifikasi primadona dengan frasa khas:

  • "Ini bodoh - aku tidak akan melakukannya dengan cara itu"
  • "Kita harus melakukannya seperti ini."
  • "Jika Anda tidak menyukainya, Anda dapat berbicara dengan manajer saya"
  • "Baiklah, kita akan lihat."
  • "Aku akan bicara dengan bosmu dan melihat apa yang dia katakan"

Primadona tidak menerima kepemimpinan. Dia melihat setiap upaya kepemimpinan sebagai penghinaan, karena dia di atas bertanggung jawab atas tindakannya. Masalah kepribadian ini umumnya ditemukan di kalangan pengembang lama yang sangat terlibat dalam keberhasilan awal perusahaan. Sekarang, bertahun-tahun kemudian, berkat hubungan bertahun-tahun dengan para pendiri perusahaan, ia menganggap pendapatnya lebih tinggi daripada manajer tingkat menengah yang sederhana.

Primadona tidak menimbulkan bahaya material bagi proyek, karena biasanya tidak melakukan apa-apa, tetapi hanya mengguncang hukum. Namun, hal itu berdampak negatif terhadap moral tim, terutama pengembang baru yang lebih produktif. Karena itu, harus diberlakukan agar proyek berjalan dengan lancar.

Solusi


Solusi bagi diva adalah menyangkal keyakinan dasar: bahwa ia tidak tergantikan dan karenanya dapat melakukan apa pun yang diinginkannya . Cara paling langsung untuk menyangkal keyakinan ini adalah dengan menyewa pengganti untuk bekerja sama dengannya. Untuk menyampaikan secara memadai kepada prima donna bahwa ini memang penggantinya, dua syarat harus dipenuhi:

  • Penggantian harus lebih berkualitas.
  • Penting untuk menjelaskan kepada prima donna bahwa penggantinya tidak memiliki pekerjaan selain mengikuti bayangan prima donna dan belajar bagaimana cara menggantinya.

Semakin cepat penggantian akan mengumpulkan semua pengetahuan tentang kode warisan yang dapat dimiliki prima donna (lihat jenis pengembang yang menyimpan kode warisan dan penyandera sandera ), semakin cepat prima donna akan kembali mengendalikan. Efeknya bisa dramatis: semuanya bisa berubah hanya dalam beberapa hari. Dalam bentuk, diva mulai melakukan fungsi tambahan untuk penggantinya. Pada akhirnya, ia tidak lagi diperlukan, dan karena itu tidak lagi seorang diva, tetapi hanya seorang karyawan yang buruk.

Satu-satunya harapan primadona adalah mempertahankan rasa status - untuk mendapatkan promosi ke posisi manajerial (lihat pengembang seperti penandaan manajer ). Semakin baik kecerdasannya, semakin cepat ketika penggantinya muncul ia akan mencoba melakukannya. Namun, peningkatan ini tidak disarankan, karena Anda cenderung melihat pemberhentian pengembang yang menjadi tanggung jawab diva. Karena itu, ketika menolak permintaan untuk promosi, ia hanya memiliki dua opsi: berdiri sejajar dengan pengembang lain atau pergi. Bagaimanapun, masalah Anda teratasi.

Idealis


Pengembang sangat terobsesi untuk mencapai keanggunan arsitektur dan keunggulan kode sehingga ia lupa bahwa karyanya harus menguntungkan bisnis.

  • Dapat bermutasi menjadi optimis atau diva
  • Berbahaya dalam kombinasi dengan kipas teknologi
  • Kemungkinan koreksi: tidak
  • Bahaya proyek: sangat tinggi

Masalah


Profesi seorang insinyur perangkat lunak membutuhkan keseimbangan konstan dari dua tugas yang berlawanan:

  1. Keinginan untuk menguntungkan bisnis (dan dibayar).
  2. Keinginan untuk menulis perangkat lunak yang luar biasa (dan bangga).

Idealis benar-benar mengabaikan tujuan menguntungkan bisnis, dan sebaliknya hanya berfokus pada penulisan perangkat lunak yang hebat.

Pengembang idealis biasanya sangat cerdas, berpengalaman dan profesional. Dia benar-benar tahu apa yang dia bicarakan. Dia benar-benar tahu cara menulis perangkat lunak yang hebat, dan jika dia diberikan waktu yang cukup, dia dapat menciptakan sistem yang sempurna. Masalahnya adalah dia percaya bahwa dia memiliki semua waktu di dunia dan kebebasan penuh , meskipun ini jauh dari kasus.

Alih-alih berkompromi, ia berfokus pada menciptakan sistem yang sempurna. Dia percaya bahwa ini lebih baik untuk bisnis. Jangan membingungkan mereka dengan para ilmuwan yang menciptakan sesuatu yang "absolut" atau "keren": idealis dengan tulus percaya bahwa sistem ideal mereka paling cocok untuk pengembangan perusahaan. Karena ketabahan dari iman ini maka mereka sangat sulit untuk dikoreksi.

Idealis sangat berbahaya untuk sebuah proyek karena mereka biasanya memiliki kekuasaan atas pengembang kunci lainnya, karena mereka mewakili ideal yang sedang diperjuangkan pengembang, sehingga mereka begitu mudah untuk mendapatkan programmer lain di pihak mereka, karena semua pengembang ingin bangga dengan perangkat lunak yang mereka tulis. Dengan demikian, mereka mengambil seluruh sandera tim pengembangan , dan Anda sekarang dalam kekuasaan mereka. Jika Anda beruntung, mereka akan mulai memberikan nilai pada bisnis, tetapi itu hanya akan menjadi efek samping acak dalam upaya mereka menciptakan perangkat lunak yang hebat. Bahkan, manfaat untuk bisnis hanya akan muncul di akhir pekerjaan, tetapi mereka tidak dapat memberi tahu Anda kerangka waktu atau mengevaluasi manfaat ini. Sebenarnya, mereka bahkan tidak tertarik untuk menyelesaikannya, karena proses itu sendiri, bukan tujuan, yang memuaskan mereka.

Solusi


Kami merangkum sifat-sifat idealis:

  • Sangat cerdas, berpengalaman dan profesional.
  • Hormat kami percaya bahwa sistemnya lebih baik untuk masa depan perusahaan.

Dalam banyak hal, dia adalah karyawan yang sangat baik, dan jika Anda melihat perusahaan paling inovatif di dunia, mereka memiliki banyak idealis di departemen penelitian dan pengembangan. Namun, perusahaan terbaik memiliki tiga hal yang tidak dimiliki oleh sisanya:

  1. Staf manajemen sama kompetennya dengan para idealis, menawarkan pemeriksaan dan keseimbangan untuk keputusan teknis mereka.
  2. Harapan bahwa sejumlah proyek akan gagal, yang merupakan biaya yang biasa untuk melakukan bisnis.
  3. Anggaran besar untuk terus membiayai proyek yang tidak menguntungkan.

Jika perusahaan Anda memiliki tiga hal ini, tinggalkan idealis sendirian, biarkan dia melakukan apa yang diinginkannya. Tetapi jika Anda, seperti kebanyakan perusahaan, tidak memiliki kondisi mewah ini, maka masalah nyata muncul, karena hampir semua yang Anda lakukan akan menyebabkan bencana:

  • Jika Anda langsung memecatnya, maka pengembang yang loyal dapat segera mengikutinya.
  • Jika Anda menetapkan aturan ketat, maka dia mungkin secara mental memutuskan dari proyek, yang akan meninggalkan Anda tanpa bimbingan teknis.
  • Jika Anda meninggalkannya sendirian, maka pihak berwenang pada akhirnya akan bosan dengan kurangnya kemajuan nyata.

Untuk memaksa seorang idealis untuk mengubah perilaku, Anda perlu menemukan seseorang yang dapat meyakinkannya. Orang ini harus menunjukkan kepada idealis bahwa dia juga dapat menciptakan sistem yang sangat baik. Ini penting, karena seseorang tanpa kompetensi teknis hanya akan diabaikan karena tidak dapat memahami kejeniusan desain yang ideal.

Jika seseorang dengan kepercayaan diri seperti itu ditemukan, ia harus secara perlahan dan metodis mengambil idealis dari cara berpikir idealistiknya. Ini menuntut seorang profesional yang sangat cerdas dan berpengalaman untuk siap melakukan apa yang menurutnya benar. Kemungkinan ini sedikit, dan oleh karena itu, ada sedikit peluang untuk mengoreksi idealis.

Bintang rock


Pengembang sangat berbakat, sangat produktif, sangat penting sehingga jika dia pergi, seluruh proyek akan runtuh.

  • Dapat bermutasi menjadi penyandera dan diva
  • Ini berbahaya dalam kombinasi dengan manajer tipe optimis
  • Kemungkinan koreksi: tidak
  • Bahaya proyek: sangat tinggi

Masalah


Dalam industri perangkat lunak, istilah "bintang rock" sering digunakan oleh perekrut yang mencoba menarik minat pengembang dengan menggembungkan ego mereka, yaitu, "kami mencari beberapa pengembang bintang rock." Sulit untuk menemukan bintang rock nyata, karena mereka adalah programmer yang ideal:

  • Tidak ada masalah yang tidak dapat mereka pecahkan (dan cepat).
  • Mereka bekerja sepanjang malam untuk mengejar tenggat waktu.
  • Praktis tidak ada bug dalam kodenya atau bug apa pun cepat diperbaiki.
  • Mereka mengambil bagian paling sulit dari proyek ini.
  • Mereka biasanya sangat menyukai rekan kerja.

Sayangnya, setelah dipekerjakan, mereka menjadi sangat diperlukan dalam proyek.

Seorang bintang rock terlihat seperti lubang hitam: pekerjaan terakumulasi di sekitar mereka dan akhirnya terhisap untuk dilakukan. Mungkin sampai pada titik bahwa mereka mengambil pekerjaan dari pengembang yang lebih lambat untuk memenuhi tenggat waktu - untuk semua orang lega. Jika proyek menemukan dirinya dalam kesulitan, mereka akan menyelamatkan situasi. Jika sesuatu yang dramatis dan tak terduga terjadi, mereka akan tahu apa yang harus dilakukan. Mereka sangat hebat - dan setiap perekrut tahu itu.

Perekrut akan memanggil bintang rock beberapa kali setiap hari. Reputasi mereka ada di depan mereka. Perusahaan selalu ingin memikat bintang rock, karena mereka memahami nilainya, dan dalam banyak kasus mereka akan melakukan hampir segalanya untuk mendapatkannya. Karena itu, situasinya adalah bahwa ada seseorang yang sangat diperlukan untuk proyek Anda, yang ingin dipikat oleh setiap perusahaan. Jika ya, proyek akan gagal. Kasing klasik adalah ketika terlalu banyak telur ditempatkan dalam satu keranjang.

Solusi


Tidak ada "solusi" untuk bintang rock. Pada akhirnya, hanya orang bodoh yang ingin "memperbaikinya", karena ia adalah pengembang paling produktif Anda hingga saat ini. Yang dapat Anda lakukan adalah mengurangi kerusakan dengan membuat tim di sekitar yang dapat berfungsi secara efektif jika dia pergi. Kemungkinan besar, Anda akan membutuhkan beberapa pengembang untuk menggantikan kinerja satu bintang rock, tetapi setidaknya Anda bisa selamat dari kepergiannya.

Untuk memeriksa seberapa buruk situasi Anda, perhatikan produktivitas pengembang ketika bintang rock pergi berlibur. Jika selama absen setiap minggu semua pengembangan berhenti, maka Anda perlu menggandakan upaya dalam membawa pengembang lain ke tingkat di mana mereka dapat menjaga pengembangan proyek tanpa adanya bintang rock.

Ini bisa sulit jika pengembang terbiasa dengan kenyataan bahwa ia mengatasi masalah yang kompleks, mereka menjadi malas dan sombong. Ada kemungkinan bahwa dengan kepergian tiba-tiba bintang rock, pengembang lain akan mengambil tindakan. Tapi, kemungkinan besar, mereka sangat mencintainya sehingga mereka akan mengikutinya ke perusahaan baru.

Menandai manajer


Pengembang yang memutuskan untuk menghindari kesulitan pemrograman dan menjadi salah satu manajer.


Masalah


Pemrograman sulit dipelajari. Itu membutuhkan kemampuan untuk dengan cepat menyelesaikan masalah, sejumlah besar pengetahuan dan bahkan pengalaman yang lebih nyata. Tidak seperti bidang profesional yang sebanding, pengetahuan dan pengalaman ini menjadi usang jauh lebih cepat (kadang-kadang dalam beberapa bulan), yang membutuhkan pengembangan metode, teknologi, dan alat baru secara konstan. Melemparkan manajer ingin menyingkirkan keributan ini, dan melihat jalan keluar dalam manajemen .

Sebagai aturan, untuk manajer pengembangan, persyaratan untuk keterampilan pemrograman lebih rendah daripada untuk pengembang. Waktu dihabiskan untuk rapat, mengirim email, atau bahkan berjalan dan mengobrol dengan orang lain. Manajer juga cenderung menghasilkan lebih dari coders, tetapi dengan status datang kekuatan. Ini adalah pilihan yang jelas bagi pengembang yang ingin menyingkirkan perangkat lunak penulisan.

Masalah dengan pengembang, yang mulai berpikir tentang karier manajer, adalah bahwa ia berupaya menunjukkan keterampilan manajemennya dengan harapan peningkatan, daripada memikirkan pemrograman . Untuk mempraktikkan keterampilan manajemen, manajer masa depan mencoba untuk memerintah sesama pengembang: menugaskan pekerjaan, berbicara di rapat dan, sebagai suatu peraturan, berupaya berpartisipasi dalam membuat keputusan yang lebih strategis. Oleh karena itu, mereka tidak sama-sama dicintai oleh sesama pengembang dan manajer lain yang melihat ancaman terhadap pekerjaan mereka.

Solusi


Tidak mungkin untuk memecahkan masalah manajer masa depan, karena dia telah membuat pilihan karier yang jelas. Setelah keputusan dibuat, tidak ada jalan untuk kembali. Anda tidak dapat memaksanya untuk menulis program lagi. Bahkan jika dipaksakan, Anda akan segera menemukan alasan mengapa ia mulai berpikir tentang karier seorang manajer: pria itu tidak pandai pemrograman. Karena kerumitan situasi ini, begitu banyak programmer dan manajer mendapatkan apa yang mereka inginkan: promosi ke posisi manajer, jika ada lowongan.

Sebagai aturan, pengembang dalam posisi ini tidak terlalu berbahaya bagi proyek, karena produktivitas mereka terlalu rendah, dan mereka biasanya tidak memiliki kepercayaan khusus baik dari pengembang atau manajer. Seringkali orang-orang ini sepanjang karier mereka nongkrong di organisasi, dan manajemen senior berjuang untuk menemukan aplikasi untuk mereka . Dengan demikian, mereka dapat menjadi berbahaya jika dipercayakan dengan misi kritis, tetapi karena ini dapat sepenuhnya dihindari, mereka dapat dengan aman tetap menjadi faktor kecil yang mengganggu.

Penyandera


Seorang pengembang yang telah menulis perangkat lunak penting dan tidak mengizinkan siapa pun untuk mengerjakannya untuk mempertahankan ketidaktergantungannya.


Masalah


Penting bagi siapa pun yang memiliki kewajiban keuangan untuk memastikan keamanan tempat kerja dan gaji mereka. Selain itu, bekerja dengan kode yang sudah dikenal jauh lebih mudah daripada bekerja dengan kode yang tidak dikenal. Dari kombinasi dua keinginan ini, seorang penyandera lahir - seorang pengembang yang menulis dan sendirian memiliki perangkat lunak yang kritis, menolak untuk mengerjakan hal lain .

Sebagai aturan, ini adalah insinyur perangkat lunak yang buruk, yang ironisnya menjadi keuntungan penting: kodenya biasanya tidak dapat dipahami oleh orang lain , sehingga pengembang lain takut masuk ke rawa seperti itu, takut melakukan lebih banyak ruginya daripada kebaikan. Oleh karena itu, semua pekerjaan baru pada sistem kritis ditransfer ke penyerang, sehingga melanjutkan siklus setan.

Penyandera biasanya mengambil posisi defensif dan konfrontatif, ia benar-benar tertutup terhadap kritik atau kerja sama mengenai basis kode-nya. Jika Anda benar-benar mendorongnya ke sudut, ia akan mengancam untuk pergi, dan karena tidak ada orang lain yang mau mengambil produk yang dirancang dan ditulis dengan buruk, gertakan seperti itu jarang dihukum. Mereka dapat menjadi hambatan dalam proyek, karena seluruh nasib proyek akan tergantung pada keinginan dan kemampuan mereka untuk mengeluarkan kode.

Solusi


Tidak peduli betapa berbahayanya pengangkat sandera, solusinya sederhana: menugaskan dua atau lebih tanggung jawab pengembang untuk bagian dari sistem penyerang, mentransfernya ke bagian lain. Untuk beberapa waktu, kinerjanya akan rendah hingga pengembang baru mencoba memahami dan mengerjakan ulang kode, tetapi pada akhir periode ini, penyerang sepenuhnya dinetralkan dan tidak akan lagi menimbulkan masalah.

Gajah di toko Cina


Pengembang sangat fokus menyelesaikan pekerjaan sehingga ia benar-benar meninggalkan konsep kualitas apa pun.

  • Dapat bermutasi menjadi seorang prajurit
  • Berbahaya jika dikombinasikan dengan manajer proyek seperti tiran dan tester tipe selang kebakaran
  • Kemungkinan koreksi: tinggi
  • Bahaya untuk proyek: sedang

Masalah


Pengembang selalu di bawah tekanan luar biasa. “Internet tidak pernah tidur” berarti pengembang sering tidak tidur juga. Untuk mengembalikan kemiripan keseimbangan antara pekerjaan dan kehidupan, seekor gajah di sebuah toko Cina ingin menyelesaikan daftar tugasnya sesegera mungkin dan kembali ke rumah untuk keluarganya.

Programmer jenis ini menciptakan tekanan proyek. Tidak peduli seberapa bagus pengembangnya, jika tekanan naik sampai batas tertentu, ia pasti akan berhenti menguji pekerjaannya sendiri dan sebagai gantinya bergantung pada departemen pengujian (lihat jenis penguji jaksa penuntut).) sebagai satu-satunya cara untuk menemukan kesalahan. Selain itu, untuk kenyamanan, mereka akan menolak verifikasi kode peer, pengujian otomatis dan refactoring, meninggalkan kode dalam perbaikan. Perangkat lunak yang dirancang dengan buruk ini kemudian menyebabkan kesalahan baru, dan basis kode dengan cepat berubah menjadi rawa-rawa bug yang tidak dapat sepenuhnya diperbaiki.

Seekor gajah di toko Cina hidup dalam tekanan konstan karena tekanan dari atasannya. Dia adalah korban dari proyek yang tidak direncanakan dengan baik, tetapi pengembang masih dianggap masalah. Sehubungan dengan gajah di toko Cina bahwa frasa "kelelahan dan penggantian" digunakan, karena stres yang terus-menerus pada akhirnya akan menghancurkan mereka dan mereka akan pergi atau dipecat karena ketidakmampuan mereka yang tampak.

Solusi


Karena masalahnya bukan pada individu, organisasi harus mengambil langkah-langkah berikut:

  1. Beristirahat sejenak pada proyek untuk memberikan istirahat. Biasanya ini dilakukan dengan secara drastis mengurangi volume pekerjaan atau dengan secara signifikan menunda tenggat waktu.
  2. Periode tenang mempromosikan diskusi yang jujur ​​ketika seekor gajah di sebuah toko Cina memiliki kesempatan untuk menyuarakan keluhannya.
  3. Buat analisis tentang akar penyebab kesalahan dan perbaiki. Jangan terburu-buru dengan ini. Pastikan semuanya sudah diperbaiki sebelum melanjutkan proyek.
  4. Menangani semua kasus pemadaman di antara pengembang, membuat mereka mengambil liburan yang luar biasa. Organisasi jarang melakukan ini, tetapi sangat efektif.
  5. Ketika tim menyusun kembali, lakukan penilaian komprehensif terhadap proyek, tentukan beban kerja dan tenggat waktu baru.

Meskipun langkah-langkah ini jelas dapat memecahkan masalah, mereka hampir tidak pernah diambil. Artinya, manajemen tetap menjadi penyebab masalah, bukan sumber solusi. Tetapi jika kepemimpinan mengakui perannya dalam penampilan gajah di toko Cina, maka dalam beberapa minggu kerusakan dapat dikompensasi, dan pengembangan proyek akan kembali normal.

Tidak kompeten


Pengembang yang tidak memiliki kecerdasan atau keterampilan untuk menulis perangkat lunak.

  • Dapat bermutasi menjadi tentara atau pesimis
  • Berbahaya dalam kombinasi dengan manajer pengembangan tanpa pelatihan teknis
  • Kemungkinan koreksi: tidak
  • Bahaya untuk proyek: sangat tinggi

Masalah


Tidak semua orang mampu menjadi atlet profesional atau musisi yang berpengalaman, atau dokter. Ada juga orang-orang yang tidak diciptakan untuk menjadi pengembang perangkat lunak. Pengembang yang tidak kompeten ini sering menyangkal ketidakmampuan mereka dan menolak meninggalkan profesi karena gaji yang tinggi dan banyaknya lowongan yang tersedia.

Mungkin sulit bagi seorang manajer tanpa pendidikan teknis untuk mengenali pengembang yang tidak kompeten, tetapi ada beberapa tanda:

  • Dalam produktivitas rendah mereka, mereka menyalahkan kurangnya pelatihan perusahaan.
  • Penggunaan teknologi, alat, dan metode yang “terlalu rumit” masih diperdebatkan.
  • Sangat melebih-lebihkan waktu pekerjaan (lihat pesimis ), dan kemudian masih tidak lulus tepat waktu.
  • Mereka menghasilkan fungsi yang tidak memenuhi spesifikasi.
  • Fungsi yang diimplementasikan penuh dengan kesalahan.
  • Pengembang berpengalaman menghindari atau menolak bekerja dengan mereka.
  • Ketika ditanya tentang kemajuan, mereka membuat alasan dan sering mengambil posisi defensif.
  • Mereka melamar posisi manajerial (lihat manajer penandaan ) untuk membawa “lebih banyak manfaat”.

Seluruh industri perangkat lunak menderita masalah ketidakmampuan. Ini adalah contoh sederhana penawaran dan permintaan ketika tidak ada cukup pengembang yang memenuhi syarat di pasar tenaga kerja.

Solusi


Ketika seorang manajer memperhatikan pengembang yang tidak kompeten, rasa empati yang alami sering mendorongnya untuk memberikan tugas lebih mudah. Sayangnya, sama seperti seseorang tidak bisa menjadi ahli bedah jantung semi-melek atau pilot yang kompeten sebagian, tidak ada yang bisa hanya menjadi pengembang perangkat lunak yang sebagian kompeten. Jika Anda tidak memiliki kompetensi untuk mengembangkan perangkat lunak, maka Anda tidak akan dapat melakukan tugas dengan baik bahkan sederhana.

Ketika tugas-tugas sederhana terlalu rumit, langkah selanjutnya biasanya menyisihkan anggaran pelatihan. Masalah utama di sini adalah bahwa jika pengembang yang tidak kompeten dapat belajar, ia sudah akan melakukannya - sebagai rekan yang lebih kompeten, karena pengembang yang kompeten belajar sendiri.

Ada pemikiran bahwa kehadiran pengembang yang tidak terlalu produktif di negara bagian itu tidak membahayakan, tetapi ini adalah kesalahan besar. Mereka menyebabkan dua efek yang sangat merusak:

  1. Penghancuran kualitas basis kode, tampilan kode kereta baru dan pengenalan bug dalam kode kerja (lihat juga gajah di toko cina )
  2. Mereka mengusir pengembang yang kompeten yang bosan bekerja dengan mereka.

Pada akhirnya, jika proyek tergantung pada pengembang yang tidak kompeten, maka proyek tidak akan selesai . Ini mengarah pada kesimpulan yang menyedihkan bahwa pekerja seperti itu harus meninggalkan organisasi. Jika mereka tidak setuju (biasanya setelah semakin banyak petunjuk langsung), maka mereka harus dipecat.

Optimis


Pengembang yang terus-menerus meremehkan jumlah waktu yang dibutuhkan untuk menyelesaikan tugas.

  • Dapat bermutasi menjadi pesimis
  • Berbahaya jika dikombinasikan dengan manajer proyek yang optimis
  • Kemungkinan koreksi: tinggi
  • Bahaya untuk proyek: sedang

Masalah


Meremehkan tenggat waktu adalah gejala umum dalam industri perangkat lunak sehingga banyak yang bahkan tidak menganggap ini sebagai masalah. Setiap orang selalu meremehkan waktu, dan dalam banyak kasus ini diterima sebagai bagian dari bisnis. Namun demikian, pengembang yang optimis membawa masalah tersebut ke tingkat yang sama sekali baru, karena ia hampir selalu menyerah begitu saja.

Seorang optimis memengaruhi prediktabilitas suatu proyek: tanpa nilai bagus, tidak mungkin merencanakan masa depan. Rilis perangkat lunak kadang-kadang dikaitkan dengan kewajiban kontrak dengan pelanggan dan / atau mitra, yang menjadikan prediktabilitas sebagai kebutuhan bisnis. Tentu saja, Anda selalu dapat mengharapkan sedikit ketidakpastian, karena pada kenyataannya seluruh industri perangkat lunak dibangun berdasarkan fakta bahwa tidak mungkin untuk secara akurat memprediksi berapa lama waktu yang dibutuhkan untuk menulis perangkat lunak. Orang optimis menyalahgunakan toleransi ini karena gagal memenuhi tenggat waktu, menyelesaikan tugasnya dalam beberapa minggu, bukannya beberapa hari yang dijanjikan; atau, lebih buruk lagi, dalam beberapa bulan, bukan beberapa minggu yang dijanjikan.

Optimis pada dasarnya tidak memahami dampak negatif dari keterlambatan tersebut pada keberhasilan proyek secara keseluruhan. Dia mungkin juga menganggap bahwa evaluasi itu sendiri adalah praktik yang sia-sia, karena tidak ada yang dapat diperkirakan secara akurat. Dengan demikian, ia dapat dengan mengesankan menilai atau memberikan nomor sewenang-wenang tanpa analisis apa pun.

Solusi


Untungnya, seorang optimis dapat dikoreksi dengan mengikuti beberapa aturan:

  • Minta mereka untuk mengevaluasi hanya untuk kode yang mereka kenal.
  • Mintalah penilaian hanya untuk teknologi yang mereka kenal.
  • Jangan pernah meminta untuk mengevaluasi waktu pelaksanaan fungsi-fungsi baru, tetapi hanya memperbaiki yang sudah ada.
  • Perawatan harus diambil untuk memastikan bahwa mereka sepenuhnya memahami semua persyaratan - mereka tidak dapat secara bebas menafsirkan persyaratan dengan cepat.
  • Minta optimis untuk menambahkan komentar “TODO” di area di mana mereka harus melakukan pengeditan. Ini akan memperkuat hubungan antara kompleksitas perangkat lunak dan jadwal.
  • Buat mereka bertanggung jawab: tunjukkan nilai mereka kepada kelompok yang dapat menantang tenggat waktu tersebut.

Ketika optimis telah melalui proses ini beberapa kali dan memenuhi kewajibannya, Anda dapat mulai memercayai penilaiannya tentang persyaratan untuk fungsi-fungsi baru, serta untuk basis kode dan teknologi yang dengannya ia kurang terbiasa.

Selama proses rehabilitasi seorang optimis, perhatikan dengan cermat bagaimana ia mengamati tenggat waktu:

  • Apakah kualitas pekerjaan menderita karena meningkatnya kewajiban (lihat gajah di toko cina ). Jika demikian, sarankan tambahkan waktu yang diperlukan untuk pengujian.
  • Apakah mereka bekerja lembur untuk memenuhi tenggat waktu (lihat prajurit )? Dalam hal ini, sarankan menambahkan waktu untuk menyelesaikan pekerjaan selama jam kerja, dan lembur harus tetap untuk keadaan yang tidak terduga.

Jika seorang optimis menganggap serius rehabilitasi, ia dapat tumbuh menjadi anggota tim yang sangat tepercaya, karena pengembang dipercaya yang mengeluarkan kode kualitas yang memadai yang memenuhi persyaratan dalam kerangka waktu yang disepakati. Segera setelah mereka membuktikan bahwa mereka dapat melakukan ini dengan stabil, mereka dapat memperoleh promosi atau gaji, yang dengan sendirinya dapat ditawarkan sebagai insentif untuk rehabilitasi mereka.

Pesimis


Pengembang yang sangat takut kehilangan tenggat waktu sehingga ia meminta waktu maksimal untuk menyelesaikan tugas.

  • :
  • :

Masalah


Jika ada pilihan, sebagian besar manajer proyek lebih memilih pesimis daripada optimis. Meskipun mereka dapat bekerja untuk waktu yang lama, tetapi mereka setidaknya dapat diprediksi. Orang pesimis mengetahui hal ini dengan sangat baik dan memanfaatkan keadaan ini sepenuhnya, meminta waktu maksimum untuk tugasnya, alih-alih mempertimbangkan istilah yang realistis.

Pesimis kadang-kadang tidak mungkin diperhatikan. Mereka bisa disalahartikan sebagai orang dewasa dan bertanggung jawab, karena tidak seperti sesama pengembang yang tampaknya kurang berpengalaman, mereka tidak pernah melewatkan tenggat waktu. Tetapi ada beberapa tanda:

  • Rekan pengembang mereka dengan penilaian yang sama memberikan waktu tenggang yang jauh lebih singkat.
  • Jika Anda menetapkan batas waktu, mereka langsung setuju, tanpa penilaian formal apa pun.
  • Ketika mereka dengan cepat setuju, jika Anda sedikit memindahkan tanggal ke tanggal sebelumnya, mereka akan menyetujui tanggal itu juga. Ini berarti bahwa antara dua tanggal itu benar-benar tidak membutuhkan waktu ekstra untuk menyelesaikan tugas.

Seorang pesimis dapat mengurangi daya saing perusahaan. Jika Anda terlibat dalam perlombaan dengan pesaing, Anda akan selalu lebih lambat darinya.

Solusi


Orang pesimistis dilahirkan melalui kesalahan organisasi yang menghukum kegagalan memenuhi tenggat waktu. Reaksi alami orang adalah meminta waktu sebanyak mungkin untuk meminimalkan kemungkinan hukuman. Ini mungkin tampak seperti perbaikan yang mudah, tetapi tiga hal bekerja melawan Anda:

  1. Pekerjaan pesimistis jauh lebih sedikit stres daripada pekerjaan normal.
  2. Pesimis biasanya dihargai dan dipromosikan lebih sering daripada mereka yang melewatkan tenggat waktu penting.
  3. Bisnis harus lebih toleran terlambat. Ketika budaya pengembangan tertentu didirikan, sebagian besar perusahaan tidak mampu melakukan ini.

Oleh karena itu, masalahnya dapat diperbaiki, tetapi biasanya tidak ada keinginan untuk memperbaikinya. Secara alami, pesimis tidak menimbulkan ancaman bagi proyek, tetapi berpotensi sangat berbahaya bagi kelangsungan hidup perusahaan di masa depan.

Seorang tentara


Pengembang yang melakukan persis apa yang mereka katakan, tanpa pertanyaan, terlepas dari apakah itu benar.

  • Dapat bermutasi menjadi gajah di toko Cina
  • Berbahaya dalam kombinasi dengan manajer proyek tipe tiran
  • Kemungkinan koreksi: tidak
  • Bahaya untuk proyek: rendah

Masalah


Dari sudut pandang manajer, siapa yang bisa lebih baik daripada pengembang yang melakukan persis apa yang dikatakan? Memang, masalah utama dengan primadona adalah tidak mengikuti perintah. Tentu saja, pengembang yang sepenuhnya patuh adalah anugerah bagi proyek ini. Sayangnya, prajurit itu memiliki kekurangannya sendiri: dia akan dengan patuh melompat ke dalam jurang, jika mereka mengatakannya kepadanya, dengan membawa seluruh proyek kepadanya .

Seorang prajurit dapat memiliki tingkat keterampilan apa pun: dari yang tidak kompeten hingga bintang rock . Karakteristik utama adalah kepatuhannya: setiap kali dia akan melakukan apa yang Anda katakan padanya. Sangat mudah untuk membuat kesalahan, mengingat ini merupakan efek dari kepemimpinan yang fantastis, tetapi bos yang hebat sangat jarang.

Tentara dilahirkan dengan beberapa cara:

  • , : . , , .
  • , , , .
  • , , , .
  • , , , - .
  • , , .
  • , — , .
  • Mereka meyakinkan diri mereka bahwa penyerahan lengkap adalah jalan menuju pertumbuhan karier, yang sangat menyedihkan, karena ini hampir tidak pernah benar dalam bidang inovatif pengembangan perangkat lunak.
  • Mereka benar-benar mantan prajurit militer yang membawa mentalitas khusus.

Akibatnya, tidak peduli betapa menyenangkan rasanya memiliki seorang prajurit dalam perintahnya, ini hampir tidak baik.

Solusi


Jika Anda memberikan pesanan yang benar, prajurit tidak akan menyebabkan masalah. Padahal, dengan kepemimpinan yang kuat, kehadiran detasemen prajurit adalah senjata yang sangat efektif. Tetapi jika Anda membutuhkan umpan balik dari pengembang untuk membantu memimpin proyek bersama, Anda tidak akan mendapatkan kerja sama tersebut. Ini membuat Anda berada dalam situasi ketegangan, ketika Anda bahkan tidak tahu bahwa Anda kehilangan sesuatu. Tetapi prajurit itu tidak akan memberi tahu.

Jika Anda dapat menentukan alasan mengapa prajurit mematuhi Anda secara implisit, maka ada kemungkinan untuk memperbaikinya. Namun, secara alami ia tidak akan mengatakan secara terbuka mengapa ia menjadi demikian. Biasanya, seorang prajurit lebih suka berkomunikasi tentang topik pekerjaan tertentu. Jika Anda menekan dan bertanya apakah ada masalah, jawaban yang paling mungkin adalah "Tidak," terlepas dari perasaan sejatinya.

Anda hanya bisa berharap rekan-rekannya akan menceritakan tentang prajurit itu, tetapi kemudian mereka akan mengkhianati kepercayaannya, yang tidak mungkin terjadi. Bahkan jika Anda mengidentifikasi masalah sebenarnya, Anda harus memperbaikinya, yang mungkin sulit. Kemudian, setelah menghilangkan akar penyebabnya, tetap berharap bahwa prajurit itu akan mengubah perilakunya. Hanya dia yang bisa mengubah dirinya sendiri.

Secara umum, mereka hampir mustahil untuk diperbaiki. Jadi, ini biasanya karyawan yang baik untuk mendukung pemimpin yang kuat.

Penggemar teknologi


Seorang pengembang yang sangat senang mencoba teknologi baru sehingga ia akan menerapkannya dalam proyek, apakah pantas atau tidak.

  • Dapat bermutasi menjadi penyandera
  • Berbahaya dalam kombinasi dengan idealis
  • Kemungkinan koreksi: tinggi
  • Bahaya untuk proyek: rendah

Masalah


Agar berhasil meluncurkan produk, Anda harus memilih teknologi. Ini adalah pilihan yang cermat dengan memperhatikan serangkaian masalah bisnis tertentu yang perlu ditangani. Penggemar teknologi menyukai mainan baru.

Semua pengembang agak jatuh cinta dengan teknologi: mereka harus sedemikian rupa untuk mempertahankan keterampilan mereka. Tetapi ketika seorang pengembang mengacaukan tanggung jawab profesional dan keingintahuan pribadinya, Anda mungkin berakhir dengan tumpukan teknologi yang sangat tidak konsisten dengan tugas bisnis.

Seorang pengembang yang jatuh cinta dengan teknologi sangat mudah dibedakan dari orang banyak. Dia akan sering dan secara terbuka menganjurkan penggunaan teknologi baru, seringkali dengan argumen yang tidak meyakinkan. Dia juga tiba-tiba mengubah teknologi di tengah pekerjaan, tanpa memberi tahu siapa pun, mengejutkan orang lain. Dalam banyak kasus, ini bisa menjadi solusi teknis yang sangat baik untuk masalah tertentu, tetapi karena teknologi belum lulus tes yang tepat, itu sebenarnya mungkin kurang cocok untuk proyek secara keseluruhan.

Solusi


Penggemar teknologi akan memperbaiki diri jika perusahaan telah menginstal tumpukan teknologi standar. Maka Anda hanya perlu memastikan bahwa pengembang tidak menyimpang darinya. Jika Anda tidak memiliki tumpukan teknologi yang terpasang, sangat disarankan untuk mendefinisikannya terlebih dahulu, karena akan merepotkan untuk memasukkannya setelah kipas teknologi mulai aktif.

Berita bahwa Anda tidak dapat menggunakan teknologi baru Anda kemungkinan akan merusak moral seorang pecinta teknologi, tetapi semangat itu dapat dengan cepat dipulihkan dengan memintanya membuat presentasi tentang teknologi baru ini. Ini adalah keputusan yang sangat sehat, karena setelah presentasi, tim dapat berdiskusi bersama apakah masuk akal untuk memperluas tumpukan teknologi perusahaan. Sebagian besar pecinta teknologi akan puas dengan uji coba semacam itu, bahkan jika mereka tidak menyukai keputusan akhir.

Penjaga Warisan


Pengembang yang hanya memiliki kemampuan untuk memelihara perangkat lunak yang sudah ketinggalan zaman, dan karenanya tidak dapat mengambil pekerjaan baru.


Masalah


Ketika pengembang baru datang ke perusahaan, ia biasanya penuh api dan semangat, berusaha membuktikan dirinya dengan segala cara yang mungkin. Namun seiring berjalannya waktu, tempat gairah membutuhkan rasa puas diri: pengembang percaya bahwa pengalaman di perusahaan memberinya hak istimewa tertentu. Untuk dirinya sendiri, dia mengakui kewajiban untuk memelihara sistemnya, tetapi tidak melakukan pengembangan bagian-bagian baru.

Masalah dengan kode warisan penjaga terkait dengan penskalaan: mereka hanya tidak termasuk dalam kumpulan sumber daya yang tersedia untuk pekerjaan baru. Pada titik ini, muncul pertanyaan apakah Anda mampu mempertahankan mereka sebagai staf, yaitu, apakah pengembang lain dapat melakukan tugas mereka untuk memperbaiki kode warisan. Biasanya sulit meyakinkan pengembang lain untuk melakukan ini karena dua alasan:

  1. Kode kuno biasanya ditulis dengan buruk dan sulit untuk dikerjakan.
  2. Dukungan adalah jalan karier yang buntu karena Anda tidak melakukan sesuatu yang baru atau inovatif, yang dapat ditandai.

Inilah sebabnya mengapa pengelola lama telah bersama perusahaan begitu lama. Seringkali mereka telah bersama perusahaan sejak awal dan merupakan penulis perangkat lunak tempat perusahaan tersebut dibangun. Namun, seiring pertumbuhan perusahaan, mereka tidak maju dalam layanan atau tidak mencoba untuk menguasai keterampilan baru atau bagian-bagian baru dari sistem, sebagai akibatnya mereka melekat erat pada satu-satunya kode yang mereka tahu.

Solusi


Pemelihara kode lama tidak membuat masalah jika Anda memahami bahwa itu bukan salah satu sumber daya untuk mengerjakan proyek baru. Dalam kasus terbaik, Anda dapat memintanya untuk memperbaiki kesalahan dan mengimplementasikan peningkatan fitur kecil. Satu-satunya masalah muncul jika mereka melarang orang lain membiasakan diri dengan bagian dari sistem mereka (lihat penyandera ).

The Guardian tidak dapat diperbaiki karena dia tidak memiliki keinginan seperti itu. Dia memiliki mentalitas pekerja pabrik: memutar kacang yang sama setiap hari sepanjang karirnya, dan kemudian pensiun. Sikap ini tidak dapat diubah, karena itu adalah esensi manusia.

Salah satu opsi yang dapat mengubah sikap ini adalah jika seseorang mengalami peristiwa penting dalam kehidupan (pernikahan, persalinan, membeli rumah, dll.), Yang akan membutuhkan penghasilan tambahan. Dalam hal ini, ia akan mengerti bahwa dukungan untuk perangkat lunak yang ketinggalan jaman tidak akan mengarah pada peningkatan. Sayangnya, Anda tidak mengontrol faktor ini.

Lihat juga:

Source: https://habr.com/ru/post/id431534/

More articles:


All Articles