Berurusan dengan programmer yang tidak fleksibel

17

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?

development-process

— Singleton
sumber

2

Saya pikir Anda perlu memperluas pertanyaan Anda dengan beberapa contoh spesifik. Kalau tidak, "kalahkan mereka dengan tongkat", "berhenti", "tulis whitepaper, grafik, dan presentasi powerpoint untuk mengomunikasikan ide Anda" adalah satu-satunya jawaban yang dapat Anda harapkan ...

— Dean Harding

"Mereka akan bersikeras untuk mengambil saran di papan" - maksud Anda "terhadap mengambil saran di papan ??

— ozz

Terima kasih atas klarifikasi, itu membuat pertanyaannya jauh lebih berharga dan berguna, IMO. +1!

— Dean Harding

2

Saya sering berpikir bahwa pemrograman yang cukup lama pada akhirnya akan menghasilkan ditempatkan di rumah sakit jiwa.

— Marcie

5

@ Marci-Saya selalu percaya bidang pengembangan perangkat lunak telah memungkinkan persentase populasi menghindari rumah sakit kesehatan mental. Bukannya mereka tidak boleh dilembagakan, tetapi mereka bisa bersembunyi di dalam beberapa tim pengembangan.

— Jim Rush

21

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.

— Jim Rush
sumber

+1 untuk memahami sejarah metodologi. Dalam banyak contoh ada hal-hal yang tampak tidak rasional yang memiliki dasar yang sangat rasional. Seringkali masalahnya bukan bahwa prosesnya salah, itu masalahnya, dan alasan di baliknya, telah dijelaskan dengan buruk karena itu semua adalah sifat kedua dari tim yang ada yang akibatnya tidak mendapatkan apa yang perlu dijelaskan kepada pendatang baru. .

— Jon Hopkins

1

@ Jon Hopkins: Secara bergantian, prosesnya salah, tetapi itu terjadi sebagai tanggapan yang buruk terhadap masalah nyata. Dalam kedua kasus, proposal pendatang baru akan ditolak dengan alasan yang sepenuhnya sah bahwa ia tidak memahami masalah yang sebenarnya, dan satu-satunya harapan pendatang baru adalah untuk memahami sejarah dan masalah yang mengarah pada proses saat ini.

— David Thornley

@ David - Itu tentu saja mungkin tapi saya kira poin kami sama - jangan berasumsi, coba dan pahami detail dan sejarahnya lalu buat panggilan.

— Jon Hopkins

2

Saya belum melihat tim "melakukan kesalahan" untuk alasan apa pun selain ketidaktahuan teknis. Ini sepertinya kasus lain di mana "orang baru" tahu lebih baik daripada orang lain tetapi tidak akan didengarkan karena masalah "kredit" ini, sehingga semua orang akan terus melakukan hal-hal yang salah tanpa pernah menyadarinya.

— Wayne Molina

@ Wayne: jika itu hanya ketidaktahuan teknis, cukup menunjukkan kesenjangan dalam pengetahuan akan cukup. Mengingat itu bukan masalahnya, itu jauh lebih dari ketidaktahuan. Banyak orang, berdasarkan sifat dan situasi mereka, tahan terhadap perubahan. Adapun alasannya, banyak. Pencarian sederhana "mengapa orang menolak perubahan" akan menghasilkan sejumlah besar hasil yang bermanfaat.

— Jim Rush

7

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

— Planet terpencil
sumber

1

Silakan gunakan judul buku di tautan alih-alih "buku ini". Ini satu langkah kurang bagi mereka yang pembaca untuk memutuskan apakah akan mengklik atau tidak. Terutama mereka yang sebelumnya pernah membacanya.

— Huperniketes

Terima kasih atas Huperniketes, saya cukup senang ketika saya mengetik ini dan tidak kembali ke kewarasan memeriksa apa yang saya ketik.

— Desolate Planet

4

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.

— etranger
sumber

Kredit harus diberikan ketika kredit jatuh tempo. Orang senior masih bisa memimpin penerapan sistem tetapi harus tetap memberikan kredit kepada yang memberikan saran dan mengerjakan sebagian besar detail implementasi. Itu adil.

— Htbaa

Itulah etika, yang harus selalu diperhatikan. Tetapi sebagai seperangkat aturan yang sangat strategis, etika tidak serta merta berperan dengan baik untuk hasil segera.

— etranger

2

@ Htbaa - benar-benar menyelesaikan pekerjaan mungkin lebih penting untuk memastikan bahwa semua orang mendapatkan kredit jatuh tempo. Mari kita hadapi itu: hidup ini tidak adil.

— Stephen C

Saya kira Anda benar Stephen C

— Htbaa

3

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.

— Stephen C
sumber

2

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.

— StuperUser
sumber

1

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.

1

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.

— Celup
sumber

0

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.

— Hanya sedikit Roger
sumber