Berurusan dengan programmer yang tidak fleksibel

Terkadang programmer yang bekerja pada suatu proyek untuk waktu yang lama menjadi tidak fleksibel, dan menjadi sulit untuk bernalar dengan mereka. Bahkan jika kami berhasil meyakinkan mereka, mereka tidak mungkin menerapkan saran kami.

Sebagai contoh, saya baru-baru ini bergabung dengan sebuah proyek di mana proses build & release terlalu rumit dan memiliki hambatan yang tidak perlu.

Saya menyarankan agar kita menyingkirkan beberapa overhead pengembangan (seperti mengisi beberapa spreadsheet) hanya dengan mengintegrasikan manajemen cacat dan alat kontrol versi (keduanya adalah alat IBM-Rasional sehingga integrasi dapat menjadi upaya sekali saja yang sangat mudah). Juga, jika kita menggunakan alat seperti Maven & Ant (proyek ini melibatkan Java dan beberapa produk COTS) build & release dapat disederhanakan yang seharusnya mengurangi kesalahan & intervensi manual.

Saya berhasil meyakinkan orang lain dan saya siap untuk berupaya mengembangkan bukti konsep. Tetapi pengembang 'Senior' tidak mau, mungkin karena proses saat ini membuatnya lebih berharga.

Bagaimana kita menangani situasi ini tanpa mengembangkan gesekan dalam tim?

Anda adalah anggota tim baru dan Anda ingin mengubah beberapa aspek mendasar tentang cara kerja tim. Semoga beruntung, saya merasakan tim yang bahagia di masa depan Anda.

Oke, beberapa saran praktis:

Buktikan diri Anda ke tim. Anda harus melakukan ini dari perspektif teknis dan keandalan. Jika Anda ingin orang lain mengikuti Anda, Anda harus memberi mereka alasan untuk melakukannya.

Memahami sejarah metodologi. Mengapa itu ada? Masalah apa yang dipecahkannya saat itu? Pastikan solusi Anda benar-benar bermanfaat bagi tim. Mungkin perubahan Anda lebih baik, tetapi mereka mungkin tidak benar-benar memecahkan masalah yang dimiliki tim.

Kenali hambatan Anda. Cari tahu alasan penolakan mereka dan kerjakan barang-barang itu.

Jika Anda ingin menjadi agen perubahan, pelajari cara menjadi agen perubahan yang sukses . Lusinan buku dan sumber lain tersedia untuk memberi Anda informasi yang jauh lebih banyak daripada yang akan Anda dapatkan di sini.

Dan, ya, semoga beruntung. Tapi tolong, demi kebahagiaan Anda dan kebahagiaan tim Anda, cerdaslah tentang hal itu. Keinginan Anda untuk melakukan perubahan proses, tanpa menginvestasikan energi untuk menciptakan jalan yang benar, bisa lebih berbahaya daripada kebaikan.

Saya sudah dalam posisi yang Anda sebutkan. Saya menghabiskan bertahun-tahun sebagai pengembang Java dan akhirnya pergi ke pekerjaan di mana mereka semua menggunakan Smalltalk. Reaksi pertama saya adalah "OMG, mereka menggunakan teknologi kuno ini" dan saya mulai mencoba memecahkan masalah Smalltalk khusus dengan solusi Java. Saya hanya bisa membayangkan betapa sakit kepala saya terhadap pengembang lain dan mereka membenci Jawa dengan penuh semangat.

Tidak sampai saya diberi proyek berukuran sedang untuk dikerjakan sementara saya dibimbing oleh dua pengembang senior selama beberapa bulan saya mulai memahami bahasa Smalltalk dan belajar untuk menyukainya. Sejak meninggalkan pekerjaan itu dan kembali melakukan pengembangan Java, saya merasa jauh lebih fleksibel karena saya dapat mengambil proyek dan mengimplementasikannya dalam bahasa apa pun yang digunakan perusahaan. Hal inti yang perlu dipahami orang-orang ini adalah bahasanya tidak lebih dari medium. Saya juga meluangkan waktu untuk mengajar diri saya Lisp dan Erlang, tetapi itu mungkin tidak berhasil untuk semua orang.

Sebagai strategi membangun tim, saya akan merekomendasikan Seven Languages ​​dalam Seven Weeks kepada orang-orang yang bermasalah dengan Anda.

Saya kira itu juga tergantung pada berapa banyak waktu orang-orang ini bersedia berinvestasi untuk menjadi lebih fleksibel. Masalah dengan sebagian besar Universitas (setidaknya yang pernah saya lihat) adalah bahwa mereka bias terhadap bahasa tertentu dan siswanya menjadi 'dilembagakan' seperti yang Anda sebutkan. Saya pikir bagian dari strategi Anda harus menumbuhkan fleksibilitas dalam tim Anda. Ini bisa dilengkapi dengan Pengembangan Berbasis Domain .

(1) Memodelkan domain (Yang sederhana) (2) Menerapkannya menggunakan dua bahasa yang berbeda (yaitu Java dan Lisp)

Sekali lagi, ini berdasarkan asumsi bahwa mereka termotivasi untuk melakukan hal di atas dan bersedia menginvestasikan waktu mereka sendiri untuk mencapainya.

Semoga ini membantu

Saya mungkin berada di jalur yang benar-benar salah di sini, tetapi bagi saya tampaknya masalah yang sama sering terjadi pada skala yang lebih luas, dan berhubungan dengan konservatisme manusia. Orang sering menolak untuk mengubah pola perilaku yang terkenal, karena alasan yang terlalu banyak untuk disebutkan.

Menjadi pengembang Rusia (dan karena itu melihat kurang dari pragmatisme Barat yang rasional), saya melihat alasan praktis untuk menjadi jauh kurang meyakinkan daripada mencoba berjalan dengan sepatu orang lain.

Dengan kata lain, Anda menyebutkan bahwa programmer senior menghargai posisinya sendiri terkait dengan skema kerja saat ini. Mungkin Anda harus meyakinkannya bahwa cara baru dalam melakukan sesuatu akan membuat posisinya semakin berharga, dan ada banyak cara untuk melakukannya. Misalnya, Anda dapat membuatnya benar-benar mengucapkan ide Anda dan mendapatkan pujian untuknya, atau Anda dapat menemukan tempat tertentu dalam proses yang dapat dikontrolnya secara eksklusif dll.

Saya percaya bahwa menjadi fleksibel di luar keuntungan nyata dari ide Anda, bisa jadi mantra ajaib Anda di sini.

Saya berhasil meyakinkan orang lain dan saya siap untuk berupaya mengembangkan bukti konsep. Tetapi pengembang 'Senior' tidak mau, mungkin karena proses saat ini membuatnya lebih berharga.

Daripada memberikan aspirasi pada karakter pengembang senior (langkah buruk), mungkin Anda harus mencoba memahami mengapa ia tidak antusias:

• Mungkin dia berpikir Anda adalah salah satu dari orang-orang yang menjual ide mereka. Mungkin dia ragu Anda bisa mewujudkannya.

• Mungkin dia berpikir Anda melebih-lebihkan masalah. (Mereka tidak mungkin seburuk itu ...)

• Mungkin dia berpikir Anda tidak sepenuhnya memahami risiko teknis.

• Mungkin dia berpikir (tahu) ada hal yang lebih penting untuk dilakukan sekarang.

• Mungkin Anda hanya menggosoknya dengan cara yang salah.

Saran saya adalah buktikan diri Anda kepadanya. Seperti dengan mengirimkan proyek-proyek yang telah Anda berikan. Ketika dia lebih memercayai kemampuan dan penilaian Anda, maka tinjau kembali masalah ini.

Jika Anda ingin mengejar jalur "perbaikan proses" sekarang, saran saya akan melakukannya perlahan, dalam langkah-langkah kecil.

Ingatlah bahwa ada risiko bahwa perubahan yang Anda usulkan berdampak besar pada produktivitas grup Anda, dan bahkan kemampuan mereka untuk mempertahankan perangkat lunak yang ada. Jika itu terjadi, orang yang bertanggung jawab kemungkinan akan mendapatkan kritik dari manajemen senior.

Melembagakan tentang apa khususnya? Teknologi, pola, praktik?

Jika mereka telah berada di organisasi / proyek untuk waktu yang lama, kemungkinan mereka adalah pengembang senior dan memiliki tanggung jawab / pengalaman untuk melakukan panggilan itu, dan memiliki pengalaman dalam proyek daripada hanya dikondisikan seperti percobaan 5 monyet .

Solusi untuk meyakinkan mereka akan tergantung pada apa subjeknya, karena jika pola / teknologi sudah dipilih, akan ada alasan yang bagus, dan harus ada alasan yang lebih baik untuk berubah untuk membenarkan membuang pekerjaan dan refamiliarising dll ., jika demikian, solusi adalah untuk arsitek / pengembang senior yang mengatur pertemuan untuk secara demokratis memutuskan solusi terbaik.

Jika tim benar-benar MEMILIKI blok jalan yang tidak perlu maka mereka mungkin akan sangat senang Anda membantu mereka memperbaikinya. Namun perlu dicatat bahwa mungkin ada alasan yang sangat baik bagi mereka untuk berada di sana, dan Anda akan terlihat bodoh jika Anda harus mengatakan "oh, well, ide bagus saya tidak berfungsi" setelah menjualnya kepada semua orang untuk waktu yang lama.

Selidiki terlebih dahulu, dan kemudian maju. Juga perhatikan, bahwa mampu MENUNJUKKAN bagaimana Anda menyarankan itu meningkat jauh lebih baik daripada handwaving.

Saya cenderung mengatakan bahwa Anda adalah "Programmer Inflexible". Anda masih baru dalam proyek ini, namun Anda bersikeras bahwa ide Anda adalah yang terbaik dan orang yang memimpin proyek, yang telah lebih lama dan tahu bahwa sistem luar dan dalam hanya keluar dari kursi goyangnya.

Saya cukup berpengalaman dan cukup dihormati dan sering ditugaskan untuk memperbaiki proyek yang sedang berjuang sebagai anggota tim harimau. Bahkan saat itu saya masih meluangkan waktu untuk mempelajari bagaimana, mengapa, dinamika tim, proyek dan praktik mereka dan tidak dengan liar masuk dan mengatakan kepada mereka bagaimana ini dan itu salah. Sebenarnya, saya tidak pernah mengatakan apa yang mereka lakukan salah karena itu tidak mendapatkan respons yang saya inginkan dan biasanya apa yang mereka lakukan tidak salah, itu hanya perlu beberapa penyesuaian.

Setiap proyek itu unik. Setiap tim unik. Solusi Anda mungkin lebih baik untuk Anda dan pengembang, tetapi mungkin tidak lebih baik untuk pemimpin, pelanggan, bisnis atau proyek tetapi karena Anda tidak memiliki pengalaman dengan proyek untuk mengetahui lebih baik, Anda tidak akan tahu jawabannya.

Cara terbaik untuk membuat orang melakukan apa yang Anda inginkan adalah membuat mereka berpikir semuanya adalah ide mereka. Jadi, bukannya langsung membuat saran, berikan opsi. Jika ide-ide Anda jelas lebih baik daripada alternatifnya, berikan kesempatan kepada senior dev untuk memilihnya dan menjadikannya miliknya sendiri. Jangan khawatir tentang mendapatkan kredit. Orang-orang yang penting akan tahu apa yang sedang terjadi.