Rekan kerja saya adalah orang yang baik, tetapi kinerjanya di bawah standar. Apakah saya memberi tahu bos saya? [Tutup]


24

Saya ditempatkan pada proyek sekitar tiga bulan lalu yang sampai saat itu sedang dikembangkan oleh pengembang tunggal yang baru direkrut karena masih tertinggal. Agar adil, proyek ini merupakan antarmuka ke perangkat medis yang memiliki banyak kehalusan dan relatif kompleks, sehingga menempatkan satu orang pada proyek yang tidak memiliki pengalaman di perusahaan mungkin merupakan keputusan yang buruk dari perspektif manajerial.

Ngomong-ngomong, begitu saya mulai mengerjakannya, saya menyadari bahwa ... yah, itu sama sekali tidak berhasil. UI terlihat bagus, tetapi sebenarnya tidak melakukan banyak hal, dan apa yang dilakukan itu salah. Sekali lagi, agar adil, sebagian besar dari ini disebabkan oleh fakta bahwa pengembang ini tidak siap untuk menulis antarmuka ke perangkat kami. Namun, saya juga dengan cepat menyadari bahwa kode yang ada di sana rapuh dan sangat sulit dipertahankan.

Sekarang saya tidak mengklaim sebagai programmer terbaik di dunia. Saya bekerja dengan banyak orang yang sangat pintar yang merupakan pengembang yang lebih baik daripada saya. Namun saya berusaha sangat keras untuk menulis kode yang sesederhana mungkin dan kuat. Saya menguji checkin saya. Jika saya melihat bahwa kode saya menjadi berantakan dan sulit untuk dikerjakan sejak dini, saya mengubahnya. Saya telah melakukan beberapa pembicaraan dengan rekan kerja saya dalam upaya membantunya menulis kode yang lebih baik. Ini agak sulit karena a) dia memiliki 20+ tahun pengalaman di bidangnya dan saya hanya 5, dan b) dia dipekerjakan sebagai apa yang disebut "pakar UX" dan yang lain melihatnya sebagai individu yang berpengalaman.

Yang mengatakan, saya hanya tidak melihatnya. Dia adalah orang yang sangat baik dan dia masuk akal, namun dari waktu ke waktu dia memeriksa kode yang rapuh, hanya berfungsi dalam kasus yang paling optimis, dan 9 kali dari 10 saya akhirnya memperbaiki bug dalam pekerjaannya. Kode-nya tampak seperti amatir dan dia jelas tidak memiliki tingkat pengalaman yang dia klaim miliki ketika dia dipekerjakan. Ini telah sampai pada titik di mana jam tambahan yang saya habiskan untuk refactoring kodenya dan memperbaiki bug-nya telah membebani saya. Cara saya melihatnya saya punya dua pilihan:

  1. Jangan lakukan apa-apa, tekan pantat saya untuk memastikan produk ini keluar tepat waktu dan kuat dan tunggu dia gagal di masa mendatang (saya tidak akan bekerja dengannya dalam proyek ini setelah rilis awal.)
  2. Ceritakan kepada bos saya tentang penampilannya. Bos saya adalah orang yang masuk akal, tetapi saya merasa canggung mengambil pendekatan ini. Saya tidak suka 'bash' (karena tidak ada istilah yang lebih baik) rekan kerja saya dan saya tidak tahu bagaimana dia akan menerimanya.

Jadi, itu saja. Saya telah mencoba untuk menyelesaikan hal ini dengan rekan kerja saya dengan menjelaskan mengapa implementasinya tidak bekerja atau bagaimana kodenya dapat dibuat lebih dapat dipertahankan, tetapi ia terus melakukan kesalahan yang sama. Saya sangat tertarik untuk mendengar bagaimana orang lain menangani situasi serupa, terutama orang-orang dalam manajemen saat ini. Terima kasih sebelumnya atas saran yang dapat Anda tawarkan kepada saya.


3
Tidakkah akan jauh lebih mudah jika dia bukan orang baik? Sungguh menyebalkan berada dalam situasi Anda ... Tidak memiliki saran nyata, saya memang menemukan diri saya dalam situasi yang sama tetapi dia tidak dengan arti kata "baik". Jadi apa yang harus dilakukan sangat jelas dan langsung didukung oleh manajemen, seolah-olah mereka di mana hanya mencari alasan. Tetapi seseorang yang benar-benar Anda sukai, itu sulit. Semoga berhasil.
yannis

1
@Yannis Rizos: ya, ya tentu saja. Saya suka pria itu, dan saya akan benci untuk berkontribusi padanya mungkin kehilangan pekerjaannya, tapi dia sepertinya tidak cocok dengan harapan yang diberikan pada pengembang di perusahaan kecil yang melakukan banyak hal. Saya hanya memiliki 5 tahun pengalaman dan saya tidak pernah diberi tugas tingkat "junior" di sini. Saya menulis antarmuka perangkat keras dari hari pertama dan itu hebat.
LostInCode

Apa itu UX? .....

@ Thorbjørn Ravn Andersen: UX biasanya berarti User eXperience
Matt Ellen

Jawaban:


24

Setidaknya saya akan mempertimbangkan kemungkinan bahwa jika ia dipekerjakan sebagai seorang pria UX, mungkin saja tidak ada yang benar-benar mengharapkan kode yang hebat darinya - mereka mungkin berharap bahwa kodenya pada dasarnya hanya akan menjadi prototipe yang menjabarkan UX, dan terserah coders lain untuk menulis kode produksi berdasarkan itu.

Sekarang, aku tentu tidak mengatakan bahwa ini terjadi, tetapi itu tidak akan menyerang saya sebagai sangat mengejutkan. Setidaknya dalam pengalaman saya, sama sekali tidak jarang bagi orang-orang UX untuk terutama memproduksi hal-hal seperti prototipe dan storyboard. Jika ada, jika orang itu benar-benar dipekerjakan secara khusus sebagai spesialis UX, saya sangat terkejut dengan gagasan tentang kode check-in sama sekali. Saya cukup yakin saya belum pernah melihat itu dilakukan.

Jika orang itu benar-benar seorang spesialis UX, obatnya mungkin bukan untuk mencoba membuatnya menghasilkan kode yang lebih baik, tetapi untuk membuatnya keluar dari pengkodean (setidaknya apa pun kecuali prototipe) sepenuhnya. Jika dia benar-benar bagus dalam desain UX, kesalahan sebenarnya mungkin dengan memintanya untuk menulis kode produksi sama sekali. Sebagai gantinya, dia mungkin (paling banyak) bekerja di kotak pasir prototipe-UX di mana hasilnya digunakan untuk memandu putaran kode nyata berikutnya yang diproduksi, tetapi tidak pernah masuk sebagai kode produksi sama sekali.


Saya memikirkan hal ini sedikit dan itu membuat saya bertanya-tanya. Saya tidak terlibat dalam proses perekrutan, dan dia pasti diharapkan untuk kode, tapi mungkin sebagai orang UX dia tidak punya banyak pengalaman sama sekali pemrograman. Yang mengatakan, agak sulit untuk percaya karena ia telah mengembangkan perangkat lunak selama lebih dari 20 tahun, dan tidak ada banyak "UX" yang terjadi di tahun 80-an.
LostInCode

Tidak, tetapi jika dia telah melakukan sedikit pengkodean selama (katakanlah) 10 tahun, dia bisa sangat berkarat (terutama jika dia bahkan sedikit lemah dalam pengkodean untuk memulai dengan). OTOH, ketika Anda bekerja 90+ jam minggu, Anda pasti memiliki alasan yang sah untuk berbicara dengan atasan Anda, meskipun saya pikir saya akan lebih berkonsentrasi untuk memperbaiki masalah itu daripada pada kelemahan rekan kerja ini.
Jerry Coffin

18

Saya mencoba untuk memiliki aturan bahwa saya selalu memberi tahu atasan saya tentang hal-hal yang mempengaruhi proyek. Positif dan negatif ... dan dalam kasus seperti ini saya mencoba menyalahkan hal-hal seperti kode yang bertentangan dengan orang yang menulisnya. Kedengarannya kurang seperti Anda memukul rekan kerja dan lebih seperti Anda mencoba meningkatkan kualitas produk.

Dari sudut pandang manajemen, ada 3 cara umum untuk berurusan dengan karyawan dalam situasi ini:

  1. Lindungi kelemahan mereka
  2. Mainkan dengan kekuatan mereka
  3. Singkirkan mereka (bukan pilihan Anda)

Kendalikan kelemahan mereka dengan mencari bantuan dari luar.

Hei Bos, saya agak khawatir tentang keadaan kode ... itu sangat rapuh dan banyak rusak. Butuh beberapa usaha untuk membuatnya menjadi kondisi di mana saya merasa itu bisa dipercaya. Apakah ada kemungkinan saya bisa meminjam salah satu arsitek selama satu atau dua hari untuk melihat apakah kita bisa menghasilkan desain yang bagus?

Anda tidak meminta orang lain untuk bergabung dengan proyek ini, Anda meminta lebih banyak 'masukan ahli' untuk waktu yang singkat. Menghasilkan dokumen apa pun yang mereka butuhkan, diagram UML, dan cuplikan kode jika itu yang diinginkan arsitek. Mereka akan melihat status kode tersebut dan kemudian bos Anda akan meminta orang lain untuk menggemakan pendapat Anda.

Dari pertemuan itu, semoga Anda akan mendapatkan desain yang lebih baik yang bisa Anda dan pengembang lainnya ikuti tanpa dia mengacaukannya. Inilah yang desain dan spesifikasi dalam banyak kasus: mengurangi kerusakan yang dapat dilakukan para dev jahat.

Mainkan dengan kekuatan mereka

Hai Bos, saya sedang bekerja dengan kode untuk proyek x, dan itu sangat bagus. Kode, di sisi lain, bisa menggunakan sedikit kerja yang adil. Saya pikir proyek akan lebih baik jika [ux guy] dapat lebih fokus pada UX, sementara saya melakukan beberapa refactoring untuk membuatnya menjadi lebih stabil. Setelah UX solid, proyek b mungkin bisa menggunakan sentuhan Midas-nya.

Di sini, bos Anda kemungkinan akan melihatnya; bahwa kau memberitahunya bahwa dev lainnya tidak terlalu baik ... tapi setidaknya kau tidak menjadi brengsek tentang itu. Dan jika dia benar-benar bagus dalam pekerjaan UX, maka dia mungkin menemukan posisi stabil melompat ke setiap proyek dan membuatnya hebat dari sudut pandang kegunaan. Saya membayangkan dia juga akan lebih baik seperti itu.


+1 Untuk spesifikasi dan diagram teknologi yang mengurangi kerusakan yang dapat dilakukan oleh pengembang jahat. Betapa benar itu.
maple_shaft

+1 karena menempatkan fokus pada kode yang buruk alih-alih memainkan permainan menyalahkan. Konflik internasional selalu berdampak negatif pada jadwal, dan pada kualitas kode secara umum.
TMN

9

Berhentilah memperbaiki kesalahannya berulang kali . Dia tidak akan belajar; Saya tahu saya tidak akan melakukannya.

Pemrograman sebagian besar adalah tugas yang logis, tetapi juga melibatkan ingatan memori. Ketika Anda sering menulis kode umum, Anda ingat bagaimana Anda mengimplementasikan solusi terakhir kali , daripada memikirkan semuanya lagi. Jika dia tidak pernah menerapkan kode yang benar, saya bisa melihat mengapa dia terus mengulangi kesalahan yang sama.

Tunjukkan padanya apa yang dia lakukan salah, dan mungkin perbaiki dulu. Untuk kejadian lebih lanjut dari insiden yang sama, minta dia menerapkan perbaikan yang Anda tunjukkan padanya.


5

Saya akan sangat berhati-hati karena beberapa alasan:

  1. Bagaimana Anda yakin tidak akan bekerja dengannya setelah rilis awal? Manajemen Anda dapat berpikir, "Tim yang luar biasa, lihat bagaimana mereka menyampaikan keangkeran ini bersama-sama!" dan ingin membuatmu tetap bersama.

  2. Jika Anda pergi ke bos Anda, seberapa teknis Anda ingin mencoba menjelaskan posisi Anda? Berapa banyak dokumentasi yang Anda miliki tentang kinerja buruk rekan kerja Anda?

Itu akan menjadi Gotcha yang saya catat dari apa yang Anda minta. Saya sarankan Anda bertanya kepadanya tentang kode dan melihat apakah dia memiliki beberapa alasan mengapa itu seperti itu. Mungkin dia berjalan berputar-putar sambil mengkodekannya yang menyebabkan beberapa masalah. Lingkaran adalah tempat Anda membuat kode sesuatu kemudian melalui serangkaian perubahan berakhir pada titik yang hampir sama persis dengan yang Anda mulai ketika daftar perubahan seseorang dibatalkan pada akhirnya. Saya pernah berada dalam situasi di mana ia berubah dan membatalkan perubahan demi perubahan yang cepat lelah.


Ya, saya memiliki pemikiran yang sama. Saya benar-benar takut pada nomor 1 jika saya tidak mengatakan apa-apa kepada bos saya karena saya sejujurnya bukan penggemar 90+ jam minggu saya telah menempatkan untuk memperbaiki hal ini. Saya tidak akan memiliki masalah untuk menunjukkan kepada bos saya apa yang saya maksud, dan dia akan mengenali masalahnya, tapi ... Saya tidak tahu bagaimana saya akan keluar jika saya melakukannya. Saya telah mencoba menyelesaikan ini dengan rekan kerja saya dengan cara yang sopan dan membantu, tetapi dia terus membuat kesalahan yang sama. Terima kasih atas masukannya.
LostInCode

5

Apa konsekuensinya jika Anda tidak mengulangi semua pekerjaannya dan membiarkan proyek itu gagal? Konsekuensi bagi Anda yang saya maksud.

Tentunya seseorang dari tingkat pengalaman dan kedudukannya tidak sampai ke sana secara kebetulan sehingga pekerjaannya tidak seburuk yang Anda bayangkan atau seluruh kariernya terdiri dari orang-orang seperti Anda yang membawanya.

Jika Anda bekerja lebih dari 50 jam seminggu pada proyek apa pun maka mereka adalah sesuatu yang sangat salah dan Anda merugikan diri sendiri dengan tidak memanggilnya untuk diperhatikan PM atau dengan pergi. Saya seorang pendukung kuat bekerja CERDAS bukan KERAS.

Kerjakan dengan cerdas 50 dan jika proyek tidak berhasil maka ITU BUKAN KESALAHAN ANDA. Jika gagal karena ketidakmampuannya dan mereka menyalahkan Anda maka itu mungkin bukan lingkungan yang Anda inginkan untuk bekerja.

Begitu banyak teman saya yang bekerja BAIK selama 40 / minggu pada proyek yang salah kelola karena mereka takut gagal ketika mereka tidak menyadari betapa kecilnya kegagalan ATAU keberhasilan secara langsung memengaruhi seluruh karier Anda.

Lebih dari 80% proyek gagal, tidak ada rasa malu dalam hal itu.


+1 untuk pendekatan yang bagus dan untuk 69% dari angka stat yang ditemukan
cregox

@ Cawas, LOL, saya menebak statistik itu tetapi dari memori. Saya pernah membaca di suatu tempat bahwa hampir 80% proyek dianggap gagal karena mereka 1) Berlari berlebihan 2) Di bawah disampaikan atau 3) Kehilangan tenggat waktu dan selesai terlambat.
maple_shaft

Saya telah melihat pengembang dengan pengalaman 20 tahun yang tidak dapat membuat kode sama sekali. Dan jangan bekerja dengan cerdas 50 jam seminggu kecuali Anda memiliki ekuitas yang serius atau dibayar di pasaran. Bekerja dengan cerdas dan jika itu tidak cukup bagi mereka untuk memulai pencarian pekerjaan.
kevin cline

4

Ini disebut peer review. Manajer Anda mengharapkannya dari Anda, dan harus diberi tahu di mana waktu pengembangnya yang berharga dihabiskan. Saya terkejut dia tidak tahu tentang ini - tetapi sekali lagi, saya telah melihat yang lebih buruk.

Jangan berbicara dengannya dalam hal orang lain, berbicaralah dengannya dalam hal pekerjaan sehari-hari yang Anda lakukan. Jika itu berarti membedah kodenya, biarlah. Bersenjata dengan tautan checkin dll. Untuk memberikan semacam bukti pekerjaan harian Anda. Manajer Anda mungkin menginginkan ini dari Anda - dia membawa 20 tahun UX, dan Anda mendapatkan kode yang kuat. Alih-alih melakukan wireframes, ia hanya menulis kode tingkat prototipe. Bicaralah dengan manajer Anda.

Dan harap Anda tidak dipekerjakan sebagai pengasuh bayinya. Semoga berhasil.


3

Apakah proyek akan diluncurkan lebih cepat jika Anda tidak perlu menulis ulang / mengulang pekerjaannya? Apakah ini akan membantu dalam anggaran? Anda tidak perlu bash, untuk secara pribadi menyampaikan kekhawatiran Anda. Di sinilah kebanyakan orang membuat kesalahan, mereka mengeluh tanpa menawarkan solusi.

Adakah rekomendasi spesifik yang dapat Anda tawarkan kepada bos Anda yang akan meningkatkan hasilnya. Dokumentasi yang lebih baik? Pengujian pengguna yang kuat? Tujuan Anda adalah membuat perusahaan, proyek, kolega Anda, dan diri Anda sukses. Berpura-pura bahwa tidak ada masalah memastikan kegagalan sama sekali untuk tiga dari empat --- dan Anda bukan yang beruntung.


1

Anda perlu pergi ke bos Anda secepatnya dan dengan jelas memberi tahu dia apa yang Anda katakan di sini.

Pertama, ini adalah perangkat medis. Bisakah seseorang terluka atau mati jika ada bug? Kode yang tergantung pada kehidupan atau kesehatan manusia harus sekuat mungkin secara manusiawi, bukan sampah yang ditulis oleh seorang optimis untuk skenario kasus terbaik.

Oke, mengenakan topi mantan manajer saya ... Anda tidak tahu apakah bos Anda tahu tentang ini, atau apa tanggapannya jika itu berita baru baginya. Tetapi jika dia tidak tahu, dia perlu, dan Anda tidak boleh menebaknya dengan menyembunyikan informasi ini. Jika dia baik-baik saja dengan rekan kerja Anda mengkode dengan cara ini, dia akan memberi tahu Anda.

Saya mengalami situasi seperti ini bertahun-tahun yang lalu. Seorang "guru jejaring" dan saya sedang mengerjakan pembuktian konsep sebagai kontraktor. Faktanya, dia hampir tidak menyelesaikan apa-apa, dan kebanyakan bermain-main. Suatu hari, bos kami memberi tahu kami bahwa ada demo yang akan datang. Segera, "guru jaringan" mulai menerima banyak panggilan telepon yang tidak jelas, dan dia akhirnya mengatakan kepada saya bahwa dia akan pergi sebelum demo untuk melakukan pertunjukan kontrak lagi. Begitu saya bisa mendapatkan bos kami sendiri, saya memberitahunya tentang hal itu. Dia membuang "guru jaringan" dan membawa seseorang yang saya rekomendasikan, yang membuat lebih banyak kode dalam tiga hari yang dilakukan "guru" itu dalam tiga bulan. Demo itu sukses besar - tetapi jika saya tetap diam, proyek itu akan gagal total.


1
Saya juga menyarankan agar penulis memberi tahu manajernya tentang apa yang mereka habiskan waktu.
Ramhound

0

Ya, beri tahu bos Anda. Maka Anda akan melihat apakah itu bukan Anda yang salah tempat di sana. Adalah tugas manajer untuk mengetahui bagaimana tim bekerja dan jika bos belum menyadarinya mungkin mereka hanya tidak peduli sebanyak yang Anda lakukan untuk pengkodean yang tepat - seperti banyak, banyak tempat yang pernah saya kunjungi.

Dan di antara semua tempat kerja yang berbeda itu, jika saya mendapatkan satu tangan penuh (artinya 5) teman dari semuanya, itu sudah merupakan angka yang besar. Mereka semua memiliki pria dan wanita yang baik tetapi Anda tidak akan kehilangan persahabatan karena melakukan pekerjaan Anda - jika Anda kehilangan mereka itu adalah hal yang baik. Dalam contoh Anda, dia akan menilai pekerjaan lebih dari Anda.

Memang, ini bukan upaya untuk membuatnya dipecat. Itu hanya menunjukkan kepedulian Anda pada kesejahteraan proyek, itulah sebabnya Anda semua (atau harus) ada di sana.

Anda sudah mencoba berbicara dengannya, dan jika Anda tidak melakukan apa pun, Anda sebenarnya mempertaruhkan pekerjaan Anda di sana.


2
Saya gagal menyebutkan bahwa saya telah mencoba, berkali-kali sekarang, untuk menjelaskan mengapa kodenya tidak berfungsi atau bagaimana bisa lebih baik. sayangnya dia terus mengulangi kesalahan yang sama.
LostInCode

Saya memiliki masalah yang sama dengan anggota tim lain, meskipun untungnya itu adalah proyek kelas "kecil". Saat Anda mengerjakan kode, cobalah mengajarinya dengan meminta dia memasangkan program dengan Anda. Mudah-mudahan ini akan membuat dia melihat beberapa kesalahannya sendiri daripada Anda mengatakan ini salah. Juga dia dapat melihat bagaimana seseorang dari perusahaan bekerja.
Jonathan

Berhati-hatilah untuk terlihat terlalu khawatir tentang proyek. Banyak tempat yang menderita karena manajemen yang mengakar dan sering kali mereka lebih mementingkan kesetiaan Anda terhadap diri mereka sendiri dibandingkan dengan proyek. Mereka sendiri mungkin tidak memandang proyek sama pentingnya dengan Anda, karena itulah mengapa mereka tidak pernah repot-repot menyikapi buruknya kinerja para pengembang lainnya.
maple_shaft

@LostInCode Ya, dan saran saya tidak menjadi lebih baik bahkan setelah saya mengeditnya sepenuhnya agar sesuai dengan informasi baru. Kurasa aku Chandler.
cregox
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.