Bagaimana mengelola pengembang yang memiliki keterampilan komunikasi yang buruk

Kedengarannya seperti anda menempatkan terlalu banyak usaha untuk memiliki baik bulat individu dan tidak cukup upaya untuk memiliki berpengetahuan luas tim.

Tidak ada yang salah dengan menjadi orang baik-pada kenyataannya, itu mungkin mengapa ia disewa! Anda harus bersyukur memiliki seseorang yang lebih baik pada pemrograman untuk mulai dengan.

Anda menyatakan:

... itu bertentangan dengan prinsip-prinsip saya, dan mempromosikan ide bahwa anda dapat mengukir "nyaman niche" untuk diri sendiri hanya dengan menjadi buruk di tugas-tugas anda don't seperti.

Jika dia adalah seorang yang biasa-biasa saja programmer, maka saya'd setuju. Tapi anda tidak't mengatakan bahwa. Anda mengatakan dia adalah seorang programmer yang baik. Dia's tidak menjadi buruk pada tugas-tugas lain untuk keluar dari mereka-ia's hanya terfokus pada upaya untuk menjadi programmer yang lebih baik. Tidak ada yang salah dengan itu.

Sebagai seorang manajer, itu bukan pekerjaan anda untuk memastikan bahwa setiap orang "nah bulat". Itu adalah tugas anda untuk memastikan bahwa s** akan dilakukan. Dan anda're tidak melakukan hal itu. Pada kenyataannya, anda'kembali membuat keputusan yang berhenti* hal-hal mendapatkan selesai.

Apapun masalah yang anda miliki, anda perlu untuk mendapatkan lebih dari itu-anda membuat tim anda kurang produktif.

Anda adalah menangkap beberapa panas di sini, di lain jawaban untuk keputusan anda untuk "melakukan sesuatu" tentang orang ini, tapi aku benar-benar mendapatkan apa yang anda katakan. Jika anggota tim lainnya "semua akan lebih memilih untuk menjadi coding, daripada melakukan lebih banyak tugas-tugas duniawi" maka mereka akan menjadi kesal karena anda bermanfaat kinerja buruk dari yang buruk komunikator dengan memberikan dia hanya tugas-tugas yang semua orang ingin.

Bayangkan anda adalah salah satu dari "komunikator yang baik" pada tim yang's keterampilan yang sebanding dengan dev bersangkutan. Anda menangani panggilan, bekerja dengan non-IT yang hampir tidak mengenal mouse dari keyboard, menulis rencana untuk pengguna sign-off, dan banyak lagi, semua karena bos anda mengatakan untuk melakukannya. Marah-marah dev, sementara itu, karena ia telah "miskin keterampilan komunikasi", akan kembali duduk di cube semua hari mengabaikan pengguna yang bekerja pada "fun" barang-barang saja.

Sekarang anda mengatakan bahwa marah-marah dev telah "di atas rata-rata" keterampilan, tetapi anda tidak't mengatakan dia adalah yang terbaik. Ini berarti bahwa mungkin 1/3 dari tim anda, mereka komunikator yang baik devs yang marah-marah dev's tingkat keterampilan atau di atas, semua perasaan marah.

Apakah itu layak kehilangan produktivitas beberapa dari anda kinerja TERBAIK STAF karena mereka kesal dengan marah-marah-dev? Anda'll harus memutuskan.

Kecuali jika anda ingin memecat orang itu, saya sarankan anda mengambil salah satu dari pendekatan ini:

1. membimbingnya untuk menjadi seorang komunikator yang lebih baik. Hanya anda yang dapat memberitahu jika ini adalah layak. Anda mungkin menemukan hanya memegang tangannya sedikit lebih mungkin bisa membantu. Beberapa orang hanya takut formal interaksi bisnis dan mengungkapkannya dengan menjadi marah ketika diminta untuk melakukannya.

2. Insentif "komunikasi yang baik", baik dengan uang atau manfaat lain. Membuat jelas bahwa anda benar-benar nilai yang baik komunikator dan kemudian anda devs tidak't menjadi begitu kesal, tapi pahala telah menjadi nyata & bermakna. "makan Siang dengan kabupaten manager" tidak't memotongnya. Tidak akan sebuah "pemain bintang/pujian/attaboy" penghargaan yang's hanya selembar kertas. Yang pasti uang ekstra, ekstra pergi, beberapa waktu fleksibel, beberapa serius pengakuan dengan lebih tinggi-up yang mengendalikan kenaikan gaji, dll.

Pertama-tama, menempatkan menyalahkan pada anggota tim anda... menunjukkan miskin keterampilan manajerial.

Maksudku, jika dia benar-benar memiliki keterampilan komunikasi yang buruk, aku'm sangat menyesal untuk kehidupan sosial, tapi benar-benar, di pekerjaan ini isn't seperti banyak nya masalah seperti itu adalah milik anda*. Dan let's wajah itu, dia benar-benar bisa hanya menjadi bosan oleh kusam kerja pengaturan, atau memiliki masalah pribadi yang mempengaruhi kinerja, atau sedang diam-diam merencanakan untuk membunuh kalian semua.*

Komunikasi membutuhkan setidaknya dua, dan setelah semua, satu-satu dengan orang-orang miskin keterampilan yang bisa anda. Nevermind seluruh anggota tim bergaul cukup baik, mereka semua bisa menjadi kompensasi (bahkan tidak sadar) untuk beberapa komunikasi kekurangan yang anda miliki dan bahagia mengabaikan.

Dan lagi pula, don't pergi berkeliling meminta internet tentang orang-orang yang's duduk tiga meja dari anda, pergi ke chap dan bertanya apakah benar-benar ada sesuatu yang salah dan jika itu dapat bekerja. (atau sesuatu yang membosankan yang dapat dioptimalkan atau yang ditingkatkan)

Mungkin dia hanya membenci mejanya posisi (dia menghadap ke wc?) dan ini menetapkan dia dalam suasana hati yang buruk.

Petunjuk: dengarkan jawabannya, seperti yang dia's hidup manusia, bukan sumber daya manusia.

(misalnya: mencoba menjelaskan kepadanya secara detail perlu dari praktek-praktek tertentu dan makna keputusan tertentu, beberapa orang menggali rincian, karena mereka memberi mereka rasa memiliki seorang kapten yang isn't mengemudi kapal ke tebing)

Orang-orang yang berbeda. Sebagai seorang manajer, anda perlu untuk memperlakukan orang secara berbeda (tapi cukup!) untuk mendapatkan hasil maksimal dari tim anda.

Yang mengatakan, itu's mungkin baik untuk pengembang miskin dengan soft skill untuk bekerja pada mereka. Aku akan mencari tahu apa yang non-coding hal ini pengembang yang menawarkan (atau ingin melakukan) yang melibatkan lebih dari itu soft skill. Mendapatkan mereka terlibat pada tugas itu, dan idealnya mereka'll meningkatkan soft skill sebagai efek samping.

Orang-orang sering tidak't buruk pada sesuatu untuk keluar dari pekerjaan; mereka're buruk itu karena mereka don't menikmati atau memiliki bakat untuk itu. Anda dapat't membantu yang terakhir, sehingga bekerja pada mantan.

30/70 split mungkin di mana semua masalah anda mulai. I've pernah melihat pengusaha yang senang dengan perpecahan seperti itu.

I've melihat pengusaha yang nyaman dengan 10, 15% other work (dan bahagia diriku karena itu's menyenangkan ketika dose adalah benar), tetapi 30% adalah terlalu banyak. I'd agak berpikir anggota tim lainnya memilih untuk tidak berbicara pikiran mereka dari hanya ada satu yang tidak suka "30% pekerjaan lain".

Saya juga pikir itu adalah penting untuk menyesuaikan "produktivitas matematika" angka yang lebih realistis. Itu tidak akan pernah menambahkan hingga 100% karena kerugian yang tak terelakkan di "context switch".

• ^{30+70, menyimpulkan 100% produktivitas bila beralih di antara pemrograman dan other work, tidak akan pernah terjadi di kehidupan nyata, itu lebih mungkin sekitar 20+50 atau bahkan 20+40. Context switch sangat menyakitkan bagi pengembang perangkat lunak - jika anda're tertarik, cek artikel ini untuk penjelasan mengapa adalah bahwa: DON'T BANGUN PROGRAMMER! Programmer yang nilai produktivitas mereka secara alami akan menjadi bahagia tentang kerugian seperti itu.}

Adapun running tests bagian dari pekerjaan, apakah anda mempertimbangkan lewat itu untuk penguji? Fakta bahwa programmer can melakukannya (saya pikir setiap programmer berpengalaman harus mampu) tidak berarti mereka should. Penguji dapat juga melakukannya, dan mereka melakukannya dengan baik, dan mereka tidak't menderita kerugian produktivitas di "context switch".

Hal lain yang membuat saya bertanya-tanya bagaimana anda memanfaatkan QA sumber daya anda menyebutkan Support / Investigation. Penguji profesional saya digunakan untuk bekerja dengan cenderung memiliki "pertama mengatakan" dalam hal-hal seperti itu.

• ^{Sebagai seorang mantan tester sendiri, saya memahami mereka cukup baik - masalah produksi telah ke saya (sebagai tester) yang tak ternilai sumber data untuk belajar tentang pengujian cakupan ("memiliki masalah ini telah ditutup dengan baik dengan tes saya?") dan untuk cacat prioritas ("oke itu's telah ditutupi oleh tes dan dilaporkan sebelum rilis, tapi saya set sesuai prioritas / tingkat keparahan kembali kemudian?").}

It's cukup mudah untuk tester untuk mengetahui kapan harus melewati masalah dukungan penyelidikan untuk pengembang, dan ini tidak terjadi sangat sering. Alasan membebani pengembang ini hanya melarikan diri pikiran saya. Seperti yang saya sudah menulis, mereka yakin can melakukan itu (saya'a umumnya mengharapkan senior developer untuk tahu bagaimana melakukan apa-apa QA tidak) tapi itu tidak berarti mereka should.

Saya memiliki 2 hal untuk mengatakan ini

1. Anda telah direkrut a coder atau pengembang perangkat lunak? Ketika anda sedang mempertimbangkan sebuah pengembang perangkat lunak semua hal yang anda sebutkan adalah bagian tak terpisahkan dari pengembangan perangkat lunak.Anda hanya tidak bisa mengabaikan ini kecuali anda telah direkrut untuk tugas tertentu. IMO 50% dari total pengembangan perangkat lunak adalah coding sisanya semua adalah desain,analisis,pengujian,dokumentasi,dll.

2. Tidak ada yang lahir sempurna. Itu hanya bisa menjadi yang kau dapat menemukan orang yang lebih baik dalam segala hal. Anda harus membuat mereka berjuang dan membuat mereka belajar hal-hal.

Sebagai manajer anda harus mendapatkan yang terbaik dari mereka saya setuju, tapi dalam jangka panjang menjalankan anda mungkin menghadapi masalah.Menetapkan mereka tugas-tugas ringan sehingga mereka cenderung untuk mendapatkan suatu pegangan dari itu. Keluar mereka merasa bahwa saya tidak pandai dalam hal ini/ aku tidak mampu untuk melakukan hal ini. Kebanyakan dari semua memperlakukan semua orang sama yaitu akan mendapatkan output yang paling efisien dari tim anda.

Jika semua orang di staf anda memiliki judul yang sama/job description dan job deskripsi yang mencakup segala sesuatu yang anda terdaftar maka ini programmer perlu memiliki keterampilan diasah dengan mendapatkan ditugaskan lebih dari orang lain non-programmer tugas. Demikian juga para staf lain tidak akan memiliki keterampilan pemrograman diasah jika mereka terus-menerus harus bekerja pada non-pemrograman tugas (menggunakannya atau kehilangan itu).

Tapi saya masih berpikir bahwa prioritas utama anda mungkin harus memenuhi tenggat waktu anda (yang anda mungkin masih dapat dilakukan saat mendistribusikan pekerjaan merata).

EDIT: Jika anda memiliki sebuah tim kecil itu mungkin masuk akal untuk memiliki semua anggota dapat memakai beberapa topi. Jika anda memiliki tim yang cukup besar, itu mungkin masuk akal untuk memiliki kelompok yang mengkhususkan diri di daerah yang berbeda. Dari posting anda terlihat seperti anda don't memiliki tim yang cukup besar untuk memiliki kelompok spesialis.

It's tidak jelas dari posting asli anda apa sebenarnya yang kurang tentang hal ini dev's keterampilan komunikasi. Kurangnya minat dalam pergi ke pertemuan-pertemuan atau melakukan perencanaan/koordinasi jenis pekerjaan (misalnya) doesn't selalu menunjukkan keterampilan komunikasi yang buruk. Mungkin dev hanya merasa bahwa jenis pekerjaan manager bekerja dan memotong ke dalam produktivitas sebagai dev? Atau mungkin ia merasa bahwa ada terlalu banyak organisasi overhead dan ini adalah bentuk protes terhadap apa yang dia rasakan adalah keseluruhan waktu yang terbuang? Setelah semua, masalah yang berlawanan di mana orang berbicara sepanjang hari dan tidak pernah mendapatkan apa-apa dilakukan juga cukup umum di kantor.

It's penting bahwa anda berbicara dengan dev ini di non-konfrontatif jalan dan mencoba untuk mencari tahu mengapa ia menghindari non-pemrograman tugas. It's mungkin tidak satu alasan, dia mungkin memiliki banyak alasan yang berbeda karena ada berbagai jenis tugas. Pastikan dia mengerti bahwa tujuan dari pembicaraan adalah agar anda dapat belajar bagaimana untuk secara efektif meningkatkan produktivitas tim dan kepuasan kerja bagi semua anggota tim (anda're tidak keluar untuk mendapatkan dia). Ini adalah waktu bagi anda untuk mendengarkan, dan untuk tidak berdebat atau mencoba untuk mengatasi masalah dengan reaksi spontan. Anda mungkin harus juga bertemu dengan anggota tim lainnya, mungkin mereka benar-benar baik-baik saja dengan membiarkan orang ini melakukan berat dev bekerja sementara mereka fokus pada chattier sisi profesi.

Setelah pertemuan ini, luangkan waktu untuk berpikir tentang percakapan anda miliki dan cobalah untuk mempertimbangkan karyawan ini's perspektif dengan pikiran terbuka. Mungkin anda perasaan awal yang benar dan ia kurang beberapa keterampilan penting yang anda harus mendorong dia untuk berkembang. Atau mungkin dia membuat valid tantangan untuk asumsi anda. Mungkin anda dapat bekerja dengan tim lain untuk meresmikan beberapa proses dan mengurangi kebutuhan untuk berlebihan komunikasi. Mungkin tim lain aren't menarik berat badan mereka dan anda perlu untuk mengobrol dengan mereka manajemen. Ada banyak kemungkinan yang anda mungkin tidak dipertimbangkan.

Akhirnya, dan yang paling penting, telah menindaklanjuti pembicaraan dengan individu, atau rapat tim, jika sudah sesuai. Jika anda've diidentifikasi nyata masalah organisasi yang berada dalam kekuasaan anda untuk mempengaruhi, memberitahu karyawan anda tentang tindakan yang akan anda ambil untuk meningkatkan situasi kerja. Jika anda masih percaya bahwa individu karyawan adalah salah, duduk dengan dia dan menjelaskan perubahan apa yang anda butuhkan dari dia dan mengapa. Devs cenderung untuk merespon dengan baik untuk logis/praktis penjelasan. "Itu's tidak adil kepada rekan-rekan anda untuk memberikan anda semua yang senang bekerja. Kami'd seperti untuk kalian semua untuk menjadi murni devs tapi yang's tidak realitas situasi sehingga kita perlu untuk berbagi beban pekerjaan jelek."

Tentu saja, jika orang ini marah-marah brengsek, menolak untuk memberitahu anda mengapa dia tidak bahagia, tidak akan menanggapi alasan, dan tidak dihormati oleh rekan-rekannya...nah...itu's waktu untuk Perbaikan Kinerja Rencana.

I'm marah-marah linux admin yang banyak scripting, dan telah menyadari bahwa saya memiliki keterampilan komunikasi yang buruk. Aku terdengar seperti pria anda. Pada kenyataannya, bahwa's satu-satunya daerah yang saya dapatkan berbunyi di dalam tinjauan kinerja. Kembali pada sisi lain, saya'm terus memimpin tim saya dalam inovasi dan pemecahan masalah, dan telah menciptakan dan memimpin jalan ke platform baru yang kita'kembali bergulir dan telah menyelamatkan tim saya banyak waktu dan banyak uang dengan yang diizinkan untuk menjadi diriku sendiri. Mantan bos saya itu bertanya kepada keluarga/istri DAN perusahaan kami's manajemen senior untuk meninggalkan posisinya .... secara bersamaan. Dia bekerja tanpa lelah untuk menyeimbangkan tanggung jawab yang cukup dan menanggung banyak beban dirinya sendiri. Selama interaksi dengan siapa pun di luar dinas, jika ada kesalahpahaman komunikasi yang kembali kepada-nya, dia cepat, ah, punitively benar itu. Ia miskin di "mengelola ke atas," jadi tim kami adalah yang terakhir untuk mendapatkan sumber daya sampai itu darurat, dan kemudian perusahaan kelebihan pembayaran vendor dengan apik pitches penjualan untuk yang belum teruji hardware tanpa konsultasi tim yang akan menggunakan alat tersebut. Dalam upaya untuk menciptakan "seimbang" tim, dia micromanaged kami daftar tugas dan mencoba untuk menyeimbangkan tugas-tugas sehingga anggota tim dapat meningkatkan keahlian mereka di daerah di mana mereka weren't besar, yang mengakibatkan BANYAK kode yang rusak atau buruk architected implementasi. Sementara orang-orang lain dari penulis yang secara khusus ditugaskan mendukung tugas-tugas yang rusak kode sehingga mereka bisa "belajar" -- buruk architected implementasi, kode, dan tes yang dibuat banyak yang miskin goodwill antara anggota tim dan benar-benar peningkatan kejadian "permainan menyalahkan", yang merupakan rute cepat ke beracun tim negara. Saya saat ini bos tenang, dikumpulkan individu yang datang dari junior admin peran dan telah bekerja dengan cara ke atas. Dia membuat keputusan yang baik dan sangat bergantung pada anggota tim untuk menentukan prioritas mereka sendiri. Dia adalah seorang komunikator yang sangat baik dan bereaksi dengan tenang dan dalam konser dengan dosen pembimbing untuk setiap masalah komunikasi, ide-ide atau kebutuhan yang diungkapkan oleh tim saya. Dia "karya ke atas" tanpa kenal lelah. Dia's lambat untuk membuat besar perubahan arsitektur, dan berkonsultasi secara menyeluruh dengan seluruh tim sebelum membuat perubahan untuk lingkungan kita dan lebih nyaman dengan mengandalkan keahlian dari anggota tim kami. Di bawah manajer baru, kami downtime telah turun menjadi hampir nol (yang juga telah menjatuhkan persentase waktu yang kita habiskan pada tugas-tugas dukungan dari sekitar 40% menjadi sekitar 10%), tim kami's kepuasan telah pergi melalui atap, dan kami'kembali pada jalur yang telah pindah dari 'istirahat bank pada hardware baru setiap tiga sampai lima tahun' untuk terus menerus rencana akuisisi yang harus menyelamatkan perusahaan tentang keren juta per tahun selama lima tahun. Rencana itu akar rumput program yang tidak pernah akan've terjadi di bawah manajer sebelumnya tetapi secara aktif didorong untuk manajemen senior oleh manajer baru dan tergantung pada menemukan BANYAK sinergi dalam tim's keahlian. Kami've telah diberitahu secara informal oleh CIO bahwa kita're sekarang satu-satunya tim di perusahaan yang benar-benar "telah kotoran mereka bersama-sama" dan bahwa ia's akan mengganggu lingkungan kerja kita sesedikit mungkin dan shuffle banyak sumber daya menuju area masalah yang kita identifikasi sebagai mungkin. Ini telah diadakan benar, dan itu's mengemudi dukungan kami "biaya" bahkan lebih rendah, meskipun telah mengganggu beberapa tim lain' beban kerja-tapi itu's didorong tim-tim' mendukung "biaya" lebih rendah juga. Terlihat, tempat bagi pengembang untuk meningkatkan keahlian mereka di sekolah atau pada waktu mereka sendiri. Tempat bagi mereka untuk menghasilkan hal-hal yang ada di perusahaan anda's waktu. Cara terbaik untuk menghasilkan hal-hal ini dengan memproduksi apa yang mereka tahu yang terbaik. Ketika bekerja di daerah di mana salah satu pengembang tidak nyaman, mereka harus menarik kedua pengembang yang khusus dan bekerja sebagai sebuah tim, atau berupa pengembang harus menulis kode dan menghasilkan dokumentasi dan diagram. Rute mendukung tugas-tugas kepada orang-orang yang menulis kode. Ya, hal ini meningkatkan apa yang kita sebut "bus faktor" -- kemungkinan dari departemen anda memukul speed bump jika spesialis harus tertabrak bus. (Atau di-phk, atau beralih pekerjaan, atau ...) kebenaran itu adalah bahwa anda kehilangan produktivitas dari rasa takut itu adalah perintah besarnya lebih tinggi dari kerugian aktual ketika "bus event" terjadi. Apa yang umumnya terjadi selama "bus event" adalah bahwa pewaris spesialis's bekerja remake itu menurut gambar-nya sendiri sehingga dia dapat paling efektif mendukung itu, umumnya memecahkan banyak masalah dan menurunkan waktu yang dihabiskan untuk dukungan lebih jauh, dan hidup terus berjalan. Menetapkan hal-hal untuk orang-orang yang dapat mereka lakukan yang terbaik. Membuat mereka mendukung dan dokumen pekerjaan mereka. Menumbuhkan kreativitas mereka dan memungkinkan mereka untuk fokus tanpa gangguan atau micromanagement. Segala sesuatu yang lain adalah manajemen-sekolah B, yang sayangnya terdengar seperti anda adalah perusahaan yang berenang di. Itu doesn't berarti bahwa dibutuhkan tim anda untuk berenang di dalamnya, juga. Dari perusahaan's point of view, seorang manajer yang baik mempromosikan nilai-nilai perusahaan sementara menjalankan tugas-tugas sesuai dengan nilai-nilai tersebut. Dari ITU karyawan's point of view, seorang manajer yang baik memungkinkan tim melakukan apa yang's hak untuk melakukan dengan cepat dan bersih sebanyak mungkin dan bertindak sebagai tinja penghalang terhadap manajemen senior mendorong nilai-nilai yang mereka pelajari di akhir pekan MBA kelas ke tenggorokan bawahan. Anda'kembali menjadi manusia perusahaan, dan yang tidak mungkin menjadi yang terbaik untuk tim anda. Orang-orang dengan "baik" keterampilan komunikasi yang terlalu sopan untuk mengatakan itu.

Meskipun anda mencoba untuk mengelola sebuah tim dan ingin menjaga semua orang yang termotivasi (memiliki rasa keadilan membantu), tetapi apakah anda mengorbankan proyek dengan tidak memiliki yang terbaik programmer pemrograman? Maksud saya, ini adalah titik isn't itu.

Aren't anda takut underutilizing dan/atau risiko kehilangan pengembang terbaik? Tugas anda adalah untuk mencoba dan menghilangkan jenis tugas dari semua orang.

Diperlakukan sama doesn't berarti anda memperlakukan semua orang sama. Jika orang lain ingin mengendur non-pemrograman tugas untuk dapat ditetapkan lebih lanjut tugas-tugas pemrograman, ya't mereka menjalankan risiko yang baik bukan?

EDIT: Lain dari perasaan pribadi anda, anda belum't mengidentifikasi masalah. Di beberapa titik kurangnya komunikasi menghalangi seorang programmer. Orang lain akan menunjukkan kebencian dan pekerjaan mereka mungkin menderita. Sejauh ini, anda tampaknya menjadi satu-satunya yang memiliki masalah. Kecuali ada sesuatu yang lain anda're tidak berbagi?

EDIT 2 Akhirnya, semua orang akan meminta bantuan khusus. Orang ini tidak kurang berkomunikasi dan lebih banyak coding (yang dia harus oleh semua account). Orang lain ingin datang sedikit kemudian. Yang lain akan perlu untuk melewatkan pertemuan untuk memenuhi tenggat waktu. Grafis orang yang mendapat lebih besar monitor. Ketika anda menempatkan terlalu banyak penekanan pada menjaga skor, anda lupa apa yang penting.

• Pastikan karyawan tahu bagaimana kemampuan komunikasi yang penting adalah untuk deskripsi pekerjaannya. Bekerja dengan dia/nya untuk meningkatkan.
• Don't bersikeras bahwa mereka akan sebagai baik sebagai anggota tim lainnya pada tugas-tugas tersebut.
• Menetapkan tugas-tugas sesuai dengan prinsip-prinsip yang anda yakini. Menemukan keseimbangan antara efisien tugas tugas ke keterampilan, dan keadilan/menyenangkan.

Ini adalah hanya ringkasan ide-ide, mudah-mudahan seseorang akan mencuri poin ini dan lipat mereka ke salah satu jawaban yang lain. ;-)

Kinerja adalah segalanya. Beri dia tugas-tugas pemrograman. Jangan bicara hal ini dengan seluruh departemen. Opsional membawa seseorang dalam hubungannya com tugas atau tugas seseorang di com tugas-tugas saja. Don't pikir dari pemrograman bersenang-senang. Semuanya adalah "fun" dari sudut pandang pertama anda.

Jika anda don't anda akan menciptakan situasi yang's sangat sulit untuk mengelola dan kurang efektif daripada itu bisa.

Apa pertanyaan yang bagus, itu adalah hal-hal yang semua pemimpin tim, supervisor, manajer, teknisi harus berpikir tentang. Saya suka pendekatan anda, semua orang harus mendapatkan 'fun' tugas. Mengambil lebih memiliki tim yang dapat pickup tugas-tugas yang berbeda dan lintas dilatih mencegah Peterbilt Prinsip dari menyebabkan malapetaka 'indesipensible anggota tim meninggalkan tim atau bahkan mengambil terkesiap liburan'.

Sekarang, seperti yang ditunjukkan oleh banyak posting, bekerja adalah tidak adil dan tidak't akan. Manajer diukur pada seberapa banyak kerja yang berharga akan dilakukan.

• Manajer sesuai tugas individu berdasarkan keterampilan.
• Manajer yang baik sesuai tugas berdasarkan keahlian, pertumbuhan, bunga dan bangunan produktivitas tim.
• Manajer besar mendapatkan tim mereka untuk melakukan hal ini dengan sedikit bantuan dan bimbingan. Yaitu tanpa manajer menghabiskan sepanjang hari itu.

Berbicara dengan programmer yang baik, bertanya jika ada hal-hal yang dia ingin belajar. Apa tugas-tugas lain yang akan dia terima... bahkan apa yang paling pantas untuk dia. Dia dapat membantu anggota tim lainnya dengan pemrograman... mentor mereka. Ya aku tahu komunikasi adalah masalah, jadi mungkin dia harus bekerja di itu.

Cara lain untuk paket ini adalah memiliki daftar tugas dan biarkan masing-masing anggota staf memilih sesuatu. Biarkan anda programmer yang baik memilih yang pertama. Jika anda memperingatkan dia di muka dan menunjukkan kepadanya daftar tugas-tugas yang lebih baik.

Jika anda mendapatkan perlawanan, yang hampir selalu dilakukan dengan mengubah, menemukan titik penjualan, sesuatu yang berharga baginya, mengapa dia akan manfaat. Akhirnya anda hanya dapat memberitahu dia untuk melakukannya untuk tim.

Juga mengharapkan kesalahan dan produktivitas yang lebih rendah untuk memulai, itu tanda orang yang belajar. Proyek ini mungkin menderita, tapi ke depan akan lebih baik.

Di penutupan, itu adalah tugas anda untuk memastikan hal-hal yang akan dilakukan, tapi jadi tumbuh staf anda dan jika anda dapat melibatkan mereka dalam proses yang lebih baik. Beberapa mungkin mengatakan cara terbaik untuk memastikan hal-hal yang akan dilakukan adalah sebuah tim yang tahu apa yang perlu untuk dilakukan dan memiliki hasil.

Edit: Oh dan terus mencoba, saran di atas berasal dari tahun membuat kesalahan, tapi saya selalu tahu saya ingin membantu tim saya tumbuh, dan aku tahu produktivitas adalah raja, jadi saya terus mencoba hal-hal baru ketika upaya terakhir gagal.

Jawaban terbaik sudah diterima, tapi saya'm terkejut tidak ada yang menunjukkan bahwa "tugas tugas" bukan't satu-satunya hal yang manajer dapat bekerja dengan. Memiliki "di atas avg programmer" yang "di atas avg keterampilan komunikasi" harus (semua hal lain dianggap sama) akan dibayar lebih tinggi/lebih senior developer dari seseorang yang mirip dengan keterampilan pemrograman dan lemah keterampilan komunikasi. Hal ini dapat membantu mengimbangi dirasakan "kasih" dari tim. (Dalam beberapa orgs, setelah di atas avg keterampilan dalam "Analisis Kebutuhan" dan di bawah avg keterampilan di bidang lain mungkin jauh lebih berharga bagi perusahaan karena jenis pekerjaan yang dilakukan. Sebagai seorang manajer, anda harus memutuskan bagaimana untuk menangani hal ini.)

Satu hal lain yang harus diperhatikan: memberikan orang tersebut tidak ada, tetapi tugas-tugas pemrograman yang akan menyebabkan isolasi jangka panjang. Pastikan untuk tetap memberikan mereka beberapa tugas-tugas lain (tetapi orang-orang yang dapat mereka lakukan dengan baik, don't mengatur mereka untuk umpan balik negatif!!) jadi mereka berdua terlihat dan memiliki visibilitas dengan departemen lain/tim.

Akhirnya... check in dengan anggota tim lain jika mereka melihat any ketimpangan dalam tim tugas secara berkala. Hal ini dapat menjadi masalah besar untuk anda, tapi #15 pada orang lain's daftar.

Karena dengan anda sendiri evaluasi ini salah satu programmer yang terbaik di tim, di satu sisi itu adalah "adil" untuk memberikan orang itu pekerjaan yang diinginkan (sebagai akibat dari telah menunjukkan yang terbaik yang mampu melakukannya). Setelah semua, mungkin ada orang-orang yang berkeinginan untuk bekerja di perusahaan ini tetapi tidak't disewa di semua - tapi tidak ada yang's akan mengatakan itu isn't "adil" kepada mereka bahwa mereka don't mendapatkan untuk melakukan coding ini.

Saya pikir pendekatan yang adil akan memberitahu yang lain, kurang terampil anggota tim yang ingin berbuat lebih banyak coding: "kami're membiarkan (jadi-dan-jadi) memimpin satu ini. Mungkin anda dapat mengambil memimpin pada hal berikutnya yang datang, jika anda dapat menunjukkan setelah belajar x dan y keterampilan."

Seperti beberapa orang lain yang menjawab, saya memahami posisi anda, dan saya akan memiliki ambisi serupa.

Sedangkan kasus untuk mengatakan bahwa itu akal untuk memberikan tugas-tugas kepada orang-orang terbaik dilengkapi untuk membawa mereka keluar, ada juga rasa dalam memperluas kemampuan masyarakat dalam rangka untuk memberikan yang dinamis dan fleksibel tim.

Jika orang ini diperlukan untuk melakukan non-coding unsur-unsur dalam perannya, tapi keterampilan komunikasi yang lebih miskin dari yang benar-benar dibutuhkan, dia perlu meningkatkan. Pada asumsi bahwa anda memiliki beberapa jenis pengembangan review/sistem penilaian, ini adalah waktu untuk mengangkat masalah ini.

Masalah utama adalah untuk memetakan dengan jelas apa yang anda butuhkan dari dia, menilai apakah ia memiliki keterampilan untuk mematuhi, dan bekerja di luar rencana pelatihan untuk memungkinkan untuk melakukannya. Pelatihan doesn't perlu menjadi formal, tetapi anda perlu untuk membantu dia mendapatkan keterampilan yang diperlukan.

Jika ia hanya bisa't diganggu, maka pada akhirnya akan datang ke sebuah disiplin masalah. Jika ia doesn't memiliki kemampuan, meskipun telah mencoba dan telah didukung oleh anda, maka mungkin ada tindakan disipliner yang tersedia (yang saya akan berpendapat akan menjadi keras dan kontra-produktif) tapi sama anda hanya bisa menerima bahwa dia isn't dipotong untuk tugas-tugas tertentu.

Berbicara dengan orang yang akan menjadi salah satu pertama anda ports of call. Anda mungkin menemukan bahwa ia tidak memiliki kepercayaan diri atau insight. Anda mungkin juga menemukan bahwa dia sangat responsif dan akan menghargai kesempatan untuk memperbaiki dirinya sendiri.

Anda harus menyewa seorang junior untuk melakukan semua pekerjaan kasar, dan biarkan semua orang tahu bahwa mereka perlu untuk membantu dia dengan apa yang dia/dia meminta bantuan dengan.

Mereka akan lebih cenderung untuk mengganggu "di atas rata-rata" coder karena kemampuan mereka dan seluruh tim mendapat baru pesuruh. Junior akan belajar dari bawah ke atas dan perusahaan berakhir dengan baik bulat karyawan di akhir.

Mengharapkan bahwa setiap orang akan memiliki yang sama keterampilan komunikasi adalah sebagai rasional mengharapkan anda'll mengajarkan orang lumpuh berjalan cepat sebagai sisa dari tim.

Orang-orang yang berbeda, mereka memiliki keahlian yang berbeda dan kelemahan yang berbeda. Menembak seorang programmer yang besar hanya karena dia dapat't mengejar ketinggalan dengan orang lain dalam keterampilan komunikasi akan menjadi seperti menembak seorang pria lumpuh karena dia bisa't berjalan secepat orang lain. Itu akan menjadi tidak adil dari sudut pandang budi pekerti dan akan melawan anda sendiri ekonomis kepentingan - untuk mendapatkan pekerjaan yang dilakukan.

Anda harus pada awalnya, jika anda've gagal untuk melakukan itu di masa lalu, membaca tentang sindrom Asperger. Keterampilan sosial yang buruk adalah indikator utama dari sindrom itu.

Kedua, anda dapat mempekerjakan dan memecat siapa pun yang anda inginkan, tetapi jika anda gagal untuk mengatasi dengan kekuatan dan kelemahan karyawan anda, anda'll berakhir dengan sekelompok rata-rata programmer, karena yang terbaik akan meninggalkan (jika tidak dipecat pertama).

Ada sebuah film, Adam, di mana ramah programmer dipecat hanya karena dia telah menulis sesuatu yang dia wasn't diharapkan. Idenya bisa membawa banyak uang kepada majikan, tetapi ia tidak't menggunakan kesempatan karena dia berkonsentrasi pada-nya "prinsip".