Saya seorang manajer. Bagaimana saya bisa meningkatkan hubungan kerja dan komunikasi dengan programmer? [Tutup]

Sedikit latar belakang dulu. Saya seorang manajer proyek di perusahaan menengah. Saya mulai sebagai jurusan CS dan memiliki sedikit paparan pemrograman, tetapi setelah beberapa bulan saya tahu itu bukan jalan saya, jadi saya beralih ke manajemen. Itu terbukti menjadi keputusan yang baik, dan setelah lulus saya telah bekerja dalam manajemen perangkat lunak di berbagai perusahaan (selama 5 tahun sekarang).

Baru-baru ini, kami memiliki proyek yang sangat menyakitkan. Itu adalah yang terburuk dari yang terburuk, dengan banyak kesalahan baik di pihak kami dan di sisi pelanggan dan baru saja mengakhiri tanpa kerugian. Ini telah menyebabkan banyak situasi yang membuat frustrasi, salah satunya meningkat ke titik di mana salah satu pengembang senior kami meninggalkan perusahaan setelah argumen vokal bersama kami (manajemen). Ini adalah bendera merah bagi saya: Saya melakukan sesuatu yang sangat salah. (sebagai catatan, argumennya adalah tentang beberapa perkiraan waktu yang salah)

Saya mencari banyak tempat untuk jawaban dan seorang teman menunjuk saya ke situs ini. Ada banyak pertanyaan di sini tentang frustrasi dengan manajemen. Saya bisa mengerti bahwa pengalaman buruk umum menyebabkan keengganan umum terhadap "orang-orang berjas".

Saya pria yang mengenakan setelan itu. Ini mungkin tidak terlihat seperti itu, tetapi yang saya inginkan adalah proyek yang sukses, dan dengan sumber daya yang terbatas itu mengambil keputusan yang menyakitkan. Itu pekerjaan saya. Salah satu hal yang dikeluhkan oleh pengembang senior tersebut adalah peralatan kerja. Terus terang, saya tidak tahu bahwa komputer yang kami miliki tidak cocok untuk bekerja. Setelah ini, saya bertanya kepada banyak programmer dan konsensus umum adalah bahwa kita membutuhkan mesin yang lebih baik. Saya memperbaikinya sejak itu, tetapi jelas ada kesenjangan komunikasi yang besar antara saya dan programmer. Beberapa pengembang paling cemerlang adalah orang yang paling pemalu dan pendiam. Saya tahu itu, dan itu tidak pernah menjadi masalah selama wawancara. Orang berbeda, dan memiliki kekuatan di berbagai bidang.

Kasus PC yang kurang bertenaga hanyalah satu dari sekian banyak yang membuat saya berpikir bahwa ada masalah komunikasi. Bagaimana saya bisa meningkatkan komunikasi dengan programmer tanpa menjadi mengintimidasi dan berulang?

Yang saya harapkan adalah orang tidak mengeluh tentang hal-hal baik. Jika Anda menyukai tempat kerja dan mencintai (atau paling tidak suka :)) manajer Anda, tolong beri tahu saya tentang mereka. Apa yang mereka lakukan dengan benar? Demikian pula, jika Anda membencinya, mohon jelaskan mengapa. Saya mencari jawaban tentang meningkatkan komunikasi karena saya pikir itu masalah saya, tetapi saya mungkin salah.

Wow! Terima kasih untuk bertanya. Secara teknis, seperti Anda, saya kira saya adalah manajemen, karena saya menghabiskan lebih banyak waktu berkomunikasi dan memimpin tim daripada saya menulis kode .... tapi inilah pendapat saya dari kedua ujung cakrawala manajemen. Apakah saya seorang pengembang atau manajer yang bekerja untuk manajer lain, berikut adalah beberapa hal yang membantu dalam komunikasi saya dengan manajemen saya:

• Mengapa? adalah pertanyaan yang sangat penting - hampir semua jawaban faktual memiliki "mengapa" di belakangnya dan bahwa "mengapa" mungkin lebih penting daripada pertanyaan yang sebenarnya. Ada beberapa garis singgung tentang ini:
  • Alasan Pengembang - Pengembang akan memiliki banyak jawaban yang sama sekali tidak masuk akal bagi manajemen. Tentu saja saya lakukan, dan salah satu cara saya masuk ke manajemen adalah sangat baik dalam menjelaskan tim "mengapa" dalam hal manajemen bisa mengerti. Jika Anda tidak memiliki "pembicara untuk geek" di tangan, Anda dapat belajar berbicara geek dengan menyatakan kembali jawaban mereka atas pertanyaan mengapa dalam metafora yang lebih umum dipahami. Tetap lakukan sampai Anda berdua mengerti dan menyetujui apa yang terjadi.
  • Manajemen Mengapa- "mengapa" Anda sama pentingnya. Mengapa Anda membutuhkan perkiraan waktu? Untuk apa Anda menggunakannya? Bagaimana kita akan menjadi kacau jika mereka terlalu tinggi atau terlalu rendah? Ini adalah hal-hal yang Anda sebagai manajer mungkin memiliki wawasan yang tajam, tetapi ini semua adalah voodoo untuk pengembang. Caranya adalah, pengembang mungkin tidak bertanya. Manajemen telah memintanya untuk sesuatu, dan dia akan melakukan yang terbaik yang dia bisa untuk menjadi akurat, tepat waktu, dan bijaksana - tetapi jika dia tidak tahu "mengapa" dia dapat mengoptimalkan dengan cara yang Anda lebih suka dia tidak melakukannya. Tawarkan alasan Anda, dan mintalah dia untuk melakukan hal yang sama - nyatakan kembali jawabannya dengan caranya sendiri.

Tentang perkiraan waktu secara khusus - Saya harus melakukan banyak hal, dan saya benar-benar mendapat untung dari memberi tahu tim pengembangan saya "Saya membutuhkan ini karena saya akan meminta lebih banyak uang untuk membayar gaji kami, saya akan percaya pada apa yang Anda katakan dan Saya akan menggunakan nomor Anda ... itu berarti bahwa jika Anda rendah hati, kami semua kacau karena saya tidak akan dapat meminta uang untuk kedua kalinya - kami harus hidup dengan apa yang kami usulkan ". Dengan konteks itu, pengembang berubah dari taksiran rendah yang berusaha menunjukkan kepada saya betapa percaya diri dan briliannya mereka terhadap taksiran tinggi yang jauh lebih mendekati pengaturan harapan nyata.

• Tidak ada yang salah - Pertanyaan "mengapa" berjalan lama dengan akibat wajar - menanyakan "mengapa" alih-alih mengatakan "itu keterlaluan! Tidak mungkin!" membuat percakapan terus mengalir. Kadang-kadang ada keterputusan yang parah antara apa yang ditanyakan seseorang dengan apa yang ditanyakan. Manajemen terbaik saya sangat terkejut dengan jawaban saya, dan ketika terkejut, mereka berkedip dengan heran dan kemudian bertanya "mengapa Anda mengatakan itu?". Mereka tidak mengatakan (segera) - "Anda harus mengubahnya". Saya telah mengurangi jumlah proposal untuk memenuhi tujuan kompetitif, tetapi hanya setelah berbicara secara intens tentang bagaimana kita dapat mengubah suasana dan menciptakan konteks yang berbeda untuk pertanyaan itu.

• dengarkan suara bising, pilihan kata, dan jarak di antara kata-kata - Inilah banyak hal yang saya sukai dan curi untuk digunakan sendiri:

  • nongkrong di area kerja, lakukan sesuatu yang produktif dari Anda sendiri (jangan mencoba untuk masuk dalam pekerjaan pengembang, mereka tahu Anda bukan pengembang) dan hanya mendengarkan. Bagaimana tim memecahkan masalah? Apa masalah besar mereka? Anda tidak akan pernah mendengar skinny nyata pada penilaian langsung Anda tentang Anda atau manajemen pada umumnya, tetapi Anda mungkin benar-benar tahu di mana masalah berada. Pastikan Anda melakukan sesuatu sendiri yang produktif. Tidak ada yang suka memata-matai, tetapi kecuali semangat kerja sangat rendah sehingga Anda tidak bisa berada di dekat mereka tanpa semua orang mengungsi, produktivitas dalam jarak dekat harus ditoleransi.
  • mencari pilihan kata - mereka sering sama pentingnya dengan kata-kata itu sendiri. Ketika saya menggunakan kata-kata positif atau negatif, manajemen saya sering bertanya mengapa saya memilih kata-kata itu ketika itu adalah situasi yang tidak mereka kenal.
  • mencari jeda, kesenjangan, dan bahasa tubuh. Jika ada jarak kekuatan antara Anda dan pengembang (dan sepertinya ada), mereka mungkin tidak ingin bertentangan atau menghadapi Anda. Tetapi naluri dasar untuk mengatakan "hei, kamu salah" biasanya memanifestasikan dirinya di suatu tempat.

• buka sebanyak mungkin media komunikasi - siap mengobrol langsung, melalui telepon, melalui email, melalui IM - apa saja dan segalanya untuk membangun aliran komunikasi. Orang-orang sangat beragam sehingga hanya satu trik tidak akan berhasil. Dan saya melihatnya sebagai tugas manajer untuk menjadi komunikator multi-format, bukan pengembang.

• membuatnya layak untuk berbicara dengan Anda Jika seseorang memberi tahu Anda tentang masalah dan mungkin solusi yang mungkin, ia harus dan mungkin menerima bahwa Anda adalah manajer dan karenanya dapat memutuskan untuk memilih solusi yang berbeda, atau tidak ada solusi sama sekali karena Anda tidak pikir itu sepadan dengan masalahnya. Tetapi setelah ketiga kalinya ini terjadi, terutama jika itu terjadi tanpa penjelasan tentang 99% orang akan berhenti memberi tahu Anda apa pun.

Dan inilah salah satu yang sangat sulit bagi saya, tetapi telah bekerja dengan baik ketika saya bisa melakukannya - sadar akan perbedaan antara introvert dan ekstrovert . Kemungkinannya adalah Anda orang yang ekstrovert - itu sebabnya pekerjaan Anda tampak bagus dan posisi pengembangan tidak. Pengembang sebagian besar adalah introvert. "Introvert" tidak berarti "tidak bisa berkomunikasi", tetapi itu berarti bahwa pola, proses, dan kecepatannya sangat berbeda dan keinginan untuk berkomunikasi tanpa henti sebenarnya tidak ada. Rencanakan dalam waktu dan ruang yang sunyi (tetapi dilokasikan) untuk membiarkan pikiran-pikiran yang berdasarkan introvert keluar. Banyak teman introvert saya mengatakan kepada mereka bahwa mereka hanya menunggu saya untuk "tutup mulut seperti 5 menit" sehingga mereka dapat mengumpulkan pemikiran dan menanggapi. Sini'5 hal yang harus diketahui oleh ekstrovert tentang introvert dan Rands dalam Repose on the Nerd Cave - contoh khusus pengembang-tastik tentang apa yang bagus untuk introvert . Ngomong-ngomong, rands cukup fantastis. Dia seorang geek sendiri, jadi dia datang dari fokus pengembang, yang bisa jadi bukan gaya Anda, tapi dia lucu dan memiliki wawasan yang sangat bagus tentang pengembangan tim.

Saya pikir hal # 1 yang saya sukai dari manajer favorit saya adalah:

• mereka sangat berkomitmen dan bersemangat tentang proyek seperti saya (jika tidak lebih)

• Saya tidak pernah ragu bahwa mereka memiliki punggung saya - saya tahu dengan pasti bahwa ketika mereka berada di depan otoritas tingkat selanjutnya bahwa saya (atau teman sebaya saya) tidak akan pernah menjadi kambing hitam. Itu akan selalu menjadi kegagalan kelompok, jika ada kegagalan.

• Saya diberi kepemilikan atas sesuatu yang signifikan dan sesuai untuk keterampilan saya pada saat itu, tetapi dengan sumber daya yang cukup untuk mengembangkan keterampilan saya dan menyelesaikan pekerjaan.

• mereka melihat saya sebagai individu dan sebagai bagian dari tim - mereka secara aktif terlibat dalam mengetahui kekuatan dan kelemahan saya dan bekerja untuk membantu saya bermain pada kekuatan saya dan menambah kelemahan saya.

• mereka sadar akan tujuan pribadi saya dan tertarik untuk memasukkannya sebanyak mungkin

• mereka di depan ketika membuatku bahagia tidak bisa dan tidak akan menjadi prioritas. Ada nilai nyata dalam mendengar "Saya tahu Anda membenci jenis pekerjaan ini, tetapi saya ingin Anda melakukannya - begini caranya tidak akan selamanya ...".

• selalu ada waktu dalam seminggu (mungkin tidak secara instan) untuk menjelaskan gambaran besarnya

• ada hampir umpan balik dan status konstan tanpa jari menunjuk tetapi banyak pengakuan untuk pekerjaan individu.

• selalu ada kebenaran. Jika ada sesuatu yang sensitif dan tidak bisa didiskusikan, kata mereka begitu kosong. Jika ada sesuatu yang tidak pasti, mereka memberikan tingkat kepercayaan diri.

Bagian yang mudah pertama: ada tanda bahaya teknis di pos Anda: Saya ngeri mendengar Anda menyebut "perkiraan yang salah" - ini adalah perkiraan, itu TIDAK BISA DIKELUARKAN , itu sebabnya itu disebut taksiran. Bisa sedikit mati, bisa banyak mati, itu sebabnya itu disebut taksiran. Jika Anda mengambil taksiran sebagai Injil, itu akan menjadi salah satu masalah utama yang dialami pengembang "Anda" dengan gaya Anda.

Namun, saya 100% setuju dengan Anda tentang kesulitan berkomunikasi dengan pengembang. Saya mendapat wahyu beberapa tahun yang lalu, sebagai pengembang dalam pelatihan manajemen proyek. Saya melihat beberapa rekan pengembang saya benar-benar menentang manajemen setelah suasana diskusi terbuka dibuat (manajemen hadir di sini). Segala sesuatu yang salah adalah kesalahan para manajer di mata para pengembang. Kicker adalah bahwa manajemen tidak tahu tentang hampir semua masalah besar yang diangkat hari itu. Pengembang berasumsi bahwa semuanya sangat jelas sehingga manajemen tidak mungkin melewatkannya, dan manajemen berasumsi bahwa pengembang akan memberi tahu mereka apa yang mereka butuhkan.

Oleh karena itu, IMHO bagian pertama dari jawabannya adalah untuk memberi tahu pengembang Anda bahwa Anda bukan peramal, dan pada kenyataannya mungkin benar-benar bodoh ketika datang ke sisi teknis. Anda mengandalkan, mengandalkan dan memercayai mereka untuk datang kepada Anda secara tepat waktu. Anda ada di sana untuk membuat hidup mereka lebih mudah, bukan lebih keras.

Dan apa pun yang Anda lakukan, JANGAN ajukan pertanyaan yang sebenarnya tidak ingin Anda ketahui jawabannya - merujuk pada "perkiraan salah" di atas ;-). Itu kryptonite pengembang.

Ada banyak hal bagus di sini, tetapi saya merasa hal-hal berikut harus diucapkan ... Maafkan untuk menjadi keras ... Tapi ini perlu dikatakan:

• 5 Tahun sebagai PM, dan tidak tahu PC seperti apa yang dibutuhkan pengembang, keterlaluan.
• Agar pengembang berhenti karena kondisi kerja yang buruk sebagai bendera merah pertama Anda, adalah gila.

Apa yang saya pikir Anda miliki adalah masalah Kepercayaan , lebih dari masalah komunikasi. Tidak ada yang mengatakan apa yang salah karena mereka tidak percaya apa yang akan Anda lakukan dengan info itu, dan bahkan mungkin khawatir itu akan digunakan untuk melawan mereka. Dev yang memberi tahu Anda tentang semua masalah ini melakukannya karena tidak ada konsekuensi dalam melakukannya, ia berhenti.

Secara pribadi saya tidak akan pernah menyewa seorang PM yang tidak memiliki pengalaman pengembangan di latar belakangnya. Saya pikir pada proyek Anda berikutnya, Anda harus mendedikasikan sebagian kecil dari waktu Anda sebagai bagian dari Dev. tim . Katakan 8 jam seminggu, bekerja sebagai pengembang Jr di bawah pimpinan tim.

Ini benar-benar akan membuka mata Anda terhadap dinamika tim pengembangan, karena saat ini, Anda bahkan bukan bagian dari tim itu, Anda adalah orang luar. Fakta bahwa dev Anda berhenti, mengejutkan Anda, membuktikannya. Semua orang di tim tahu dia tidak bahagia. Dan tidak satu pun dari mereka memberi tahu Anda:

"Kita akan kehilangan orang terbaik kita jika kamu tidak melakukan sesuatu"

Itu seharusnya bendera merah # 2.

Sebagai seorang manajer saya yakin Anda pernah mendengar tentang kaizen , salah satu prinsip Sistem Produksi Toyota yang berarti perbaikan terus-menerus .

Anda mengaku punya masalah, jadi, itu awal yang bagus.

Kaizen memiliki lima elemen utama:

• Lingkaran Kualitas : Grup yang bertemu untuk membahas tingkat kualitas mengenai semua aspek dari menjalankan perusahaan.

• Peningkatan Moral : Moral yang kuat di antara tenaga kerja adalah langkah penting untuk mencapai efisiensi dan produktivitas jangka panjang, dan kaizen menetapkannya sebagai tugas mendasar untuk menjaga hubungan yang konstan dengan moral karyawan.

• Kerja Tim : Perusahaan yang kuat adalah perusahaan yang menyatukan setiap langkah. Kaizen bertujuan untuk membantu karyawan dan manajemen memandang diri mereka sebagai anggota tim, bukan pesaing.

• Disiplin Pribadi : Sebuah tim tidak dapat berhasil tanpa setiap anggota tim menjadi kuat dalam diri mereka sendiri. Komitmen terhadap disiplin pribadi oleh setiap karyawan memastikan bahwa tim akan tetap kuat.

• Saran untuk Peningkatan : Dengan meminta umpan balik dari masing-masing anggota tim, manajemen memastikan bahwa semua masalah dilihat dan diatasi sebelum menjadi signifikan.

( Sumber )

Jika Anda memperhatikan hal ini dengan konstan pada elemen-elemen tersebut adalah penekanan pada kerja tim dan umpan balik.

Sebagai contoh, Anda mengatakan Anda memiliki argumen tentang perkiraan waktu. Apakah Anda yang bertanggung jawab atas perkiraan waktu tersebut? Apakah Anda berbicara dengan tim tentang hal itu? Maaf, saya melihat manajer baru saja mengeluarkan nomor dari mereka. Satu hal penting: jangan pernah tawar - menawar perkiraan waktu yang diberikan tim Anda kepada Anda. Banyak manajer membayangkan bahwa jika mereka dapat memenuhi tenggat waktu yang lebih pendek jika tim mereka bekerja lebih keras. Ini bohong. Sembilan wanita tidak bisa punya bayi dalam satu bulan, ingat itu.

Jadi, saran pertama saya:

Dengarkan : mulailah dengan email sederhana kepada tim: "Apa cara terbaik bagi tim pengembangan untuk memberikan umpan balik kepada manajemen tentang kinerja manajemen?". Iterate dengan tim dan terapkan konsensus. Tugas Anda adalah memungkinkan tim mengembangkan perangkat lunak yang hebat, bukan menggiringnya. Ingatlah ini.

Kejujuran dan Loyalitas : Jika tidak ada yang menjawab ketika Anda menanyakan sesuatu, itu karena mereka tidak percaya Anda akan mendengarkan atau, yang terburuk, mereka percaya Anda akan menghukum mereka untuk itu. Jadi jujur ​​saja. Jika seseorang mengatakan Anda payah, anggap ini sebagai umpan balik dan jangan membalas dendam. Pahami alasan mereka, perbaiki.

Dan, akhirnya, meskipun saya telah melihat beberapa kritik tentang hal itu di sini, saya ingin merekomendasikan Anda untuk membaca buku berjudul The Mythical Man-Month: Esai tentang Rekayasa Perangkat Lunak . Buku ini tentang pengalaman Fred Brooks di IBM sambil mengelola pengembangan OS / 360. Sementara beberapa hal di sana-sini mungkin tanggal, itu adalah langkah awal untuk memahami bagaimana proses pengembangan perangkat lunak yang kompleks bekerja. S.Lott mengutip Agile Manifesto , yang tidak terlalu saya sukai, tetapi juga layak dibaca.

Baca ini:

http://agilemanifesto.org/

• Individu dan interaksi atas proses dan alat

• Bekerja dengan perangkat lunak melalui dokumentasi yang komprehensif

• Kolaborasi pelanggan atas negosiasi kontrak

• Menanggapi perubahan setelah mengikuti rencana

Dalam banyak kasus, organisasi (yaitu bos Anda) menuntut Anda

• ikuti proses yang jelas rusak untuk kesimpulan logis yang mengarah ke "mars kematian". Ini pada gilirannya mengarah pada argumen dan pengunduran diri.

• buat dokumentasi yang berlebihan, bernilai rendah, dan tidak digunakan.

• terlibat dalam kontrol perubahan kompleks a / k / negosiasi kontrak. Setiap perubahan pengguna membutuhkan ritual rumit untuk "kualitas" dan "memprioritaskan" perubahan. Sungguh, ini semua tentang "beku" - mencegah perubahan.

• ikuti rencana terlepas dari konsekuensinya. Beberapa organisasi menghargai pengiriman tepat waktu dari perangkat lunak yang rusak (atau bahkan tidak berguna). Itu adalah rencana yang dihargai, bukan solusi dari masalah bisnis.

Mungkin masalahnya bukan keahlian komunikasi pribadi Anda.

Mungkin seluruh "lingkungan" atau "metodologi" pembangunan itu rusak parah, dan perasaan buruk hanyalah gejala dari praktik buruk umum.

Bagi saya ini terdengar seperti Anda tidak pernah berbicara dengan para devs dalam suasana yang mudah. Pembicaraan Anda dengan mereka hanya bersifat resmi? Sayang sekali.

Mengapa Anda tidak mengenal mereka secara pribadi dan dengan demikian mengenal apa yang baik dan apa yang buruk tentang perusahaan, tempat kerja mereka dan proyek-proyek mereka? Hormati mereka dan dapatkan rasa hormat mereka, dengan menunjukkan minat dan penghargaan yang tulus untuk pekerjaan mereka.

Jika mereka memercayai Anda dan tidak perlu takut menjadi bidak penawaran, mereka kemungkinan besar bahkan akan memberi tahu Anda kebenaran yang tidak menarik.

Saya seorang Pemimpin Tim dan tim saya mempercayai saya. Saya melindungi mereka. Saya mengambil semua kesalahan dan saya berbagi ketenaran dengan mereka. Manajemen kami melindungi saya. Itu meningkatkan moral. Kami memiliki proyek yang sangat sulit dan pelanggan yang hampir jahat, hampir tidak mungkin untuk diselesaikan tetapi kami akhirnya melakukannya, karena kami berbicara tentang segala sesuatu dengan sangat jujur ​​dan terbuka.

Tepuk! Tepuk! Tepuk! Anda tentu harus menjadi orang yang baik, karena Anda telah keluar secara terbuka untuk melihat apa yang dapat dilakukan untuk menjadi lebih baik di pekerjaan Anda.

Silakan temukan di bawah ini apa yang saya saksikan di seorang manajer hebat, dan secara pribadi telah mengadopsi ketika saya memimpin tim sebagai anggota senior.

• M entor lebih dari mengelola.
• Sebuah anggota tim llow untuk menyuarakan pikiran dan keprihatinan mereka. Bersiaplah untuk itu. Ambil yang konstruktif.
• Dan tidak pernah mengkhianati anggota tim dengan bermain politik yang memecah belah. Serangan balik ini lebih cepat dan diam-diam.
• Seorang nger tidak. Tidak pernah menyeringai di wajah Anda ketika Anda bersama tim Anda, apa pun yang terjadi. Yang ini sangat sulit.
• G menghargai dan menghargai secara terbuka pemenang atas pekerjaannya yang baik. Dalam cakupan yang sama, dengan sangat lembut dan taktis membuat pekerjaan menjadi tidak menyenangkan, untuk orang yang bertanggung jawab, secara terpisah dan tidak terbuka.
• E kepemilikan ncourage dan kepemimpinan dalam setiap individu. Ini meningkatkan moral dan komitmen orang tersebut, karena ia akan merasa dihargai.
• R OAM sekitar dengan tim Anda sekali-sekali. Yang ini menginduksi / meningkatkan ikatan dalam anggota tim.

Semoga Anda beruntung dalam usaha tulus Anda :)

Secara umum, orang-orang di parit mulai merasa pemberontak ketika mereka merasa keluhan mereka tidak didengar oleh orang-orang yang dapat dan akan memperbaiki situasi. Ketika mereka bahkan tidak merasa dapat mengeluh tanpa mempertaruhkan posisi mereka di perusahaan, itu bahkan lebih buruk.

Saya orang yang agak Teori-Y, dan kebanyakan "pekerja pengetahuan" cenderung; Diberi kesempatan, kami menyukai pekerjaan kami, dan ingin melakukannya dengan baik. Namun, sisi negatif dari tempat kerja Teori-Y adalah bahwa mungkin tidak segera jelas ada masalah, karena orang-orang, yang ingin bekerja dengan baik dan dengan demikian tidak ingin membuat gelombang, akan menemukan cara mengatasi masalah itu, atau hanya mengabaikannya. Hal ini menyebabkan frustrasi yang terpendam, yang akhirnya meledak di wajah seluruh tim. Sebuah toko yang dikelola oleh manajer Theory-X mungkin akan memiliki orang-orang yang mengeluh jauh lebih awal; karyawan hanya di dalamnya untuk uang, jadi jika pekerjaan itu lebih dari biasanya mereka akan mengeluh.

Adapun apa yang dapat Anda lakukan, dalam lingkungan dengan senior dan pemimpin di ruangan melakukan pekerjaan, mereka adalah aset terbaik Anda. Bicaralah pada mereka. Anda dapat menjadwalkan 30 menit seminggu untuk "dua arah", di mana prospek memberi Anda pembaruan dan menyuarakan keprihatinan tentang proyek sehari-hari, dan Anda memberi mereka pembaruan di sisi bisnis dan merencanakan dengan mereka untuk menyelesaikan masalah sebelum mereka menjadi masalah yang serius mempengaruhi tim.

Di Agile, pada akhir setiap "sprint" atau "iterasi" (yang merupakan unit pekerjaan pengembangan yang biasanya berlangsung antara satu dan tiga minggu), seluruh tim, dari anggota paling junior hingga PM, memiliki "retrospektif" ". Mereka melihat kembali apa yang mereka lakukan, apa yang berjalan dengan benar, apa yang tidak, dan mengidentifikasi hal-hal yang harus dilakukan dan hal-hal yang harus diubah. Ada beberapa format, dan Anda dapat membuat sendiri, tetapi hasil dari retro seharusnya orang merasa suara mereka didengar, dan bahwa hal-hal akan berubah sebagai hasilnya.

Berbicara tentang Agile; pekerjaan pertama saya adalah untuk sebuah perusahaan kecil, dan "kecil" yang saya maksud adalah seluruh perusahaan tidak dapat menurunkan tim softball. Ada empat programmer ketika saya mulai, dan itu berkurang menjadi dua sebelum saya pergi. Pendiri, Presiden, CEO, dan 95% pemegang saham di perusahaan mengatasinya dengan tangan besi, dan dia adalah satu-satunya sumber perencanaan dalam organisasi, yang berarti tidak banyak. Bos itu gila kerja dan berharap semua orang juga; Semua yang harus Anda berikan tidak lebih atau kurang dari harapannya, dan untuk ini ia membayar gaji entry-level kepada orang-orang yang telah bekerja untuknya selama satu dekade.

Saya meninggalkan perusahaan itu dan mulai bekerja untuk perusahaan lain yang melakukan hal-hal yang SANGAT berbeda; mereka mempraktikkan metodologi dasar Agile SCRUM, dengan standup harian, pemrograman pasangan, tim sprint dan retrospektif. Untuk satu hari setiap dua minggu di awal setiap sprint, kami tidak melakukan apa-apa selain merencanakan pekerjaan dua minggu ke depan. Untuk sebagian besar hari lain, kami tidak melakukan apa-apa selain melihat kembali apa yang telah kami lakukan dan menemukan cara untuk meningkatkan diri sebagai tim. Ada pengembang yang duduk di sebelah saya yang merupakan Microsoft MVP, menyelesaikan pekerjaan, dan mendorong serta melengkapi apa yang saya lakukan.

Malam. Dan. Hari. Perbedaan utama? Pertama, saya tidak merasa seperti saya diharapkan bunuh diri untuk proyek; prinsip fundamental Agile adalah langkah pembangunan berkelanjutan. Kedua, saya memiliki suara dalam memutuskan bagaimana saya diharapkan untuk melakukan pekerjaan saya. Saya harus melakukan pekerjaan, tetapi jika saya memiliki "mulas" atas apa yang saya harapkan untuk dilakukan dalam sprint berikutnya, saya bisa menyuarakan pendapat itu dan itu akan didengar dan diberi bobot. Jika saya merasa ada cara yang lebih baik, saya bisa mengatakannya dan itu akan menghibur.

Sejauh menemukan solusi dan menyelesaikan masalah, Anda harus berhati-hati agar tidak terlihat bekerja dari atas ke bawah. Untuk komputer; katakanlah RMR Anda (pendapatan bulanan berulang) hanya memungkinkan perusahaan untuk memutakhirkan empat komputer setiap dua minggu. Empat komputer pertama seharusnya tidak semuanya mengarah ke lead dan senior; mereka harus pergi ke orang-orang dengan komputer paling lambat. Jika Anda memberikan bonus kepada tim, jangan hanya memberikannya kepada "senior dan pemimpin kita yang berharga, yang tanpanya ini tidak mungkin terjadi"; SEMUA ORANG di tim dev Anda mewujudkannya. Jika seorang junior memiliki keluhan, dengarkan dia; hanya karena dia seorang junior bukan berarti dia tidak tahu apa-apa.

Meningkatkan hubungan:
Baru saja punya proyek keras? Beri mereka istirahat sesudahnya. Waktu liburan untuk bersantai, dapatkan napas.
Coders bill of rights Hal-hal ini diberikan. Hal-hal dasar yang harus dilakukan tanpa mengatakan. Jika Anda melanggar ini, Anda menyalahgunakan kodemon Anda.
Tes Joel saya setuju dengan sebagian besar dari mereka. Tetapi beberapa benar-benar bergantung. Jika Anda kehilangan beberapa, Anda mungkin membuat hidup untuk programmer Anda lebih sulit maka perlu.
Utang teknis . Jadi, Anda dapat mendorong penyelesaian, tetapi Anda harus menyadari bahwa dengan memotong sudut, Anda harus membayar hutang teknis yang akan membutuhkan waktu lebih lama untuk diperbaiki. Jika tanggal tersebut muncul SEBELUM akhir proyek, Anda benar-benar mengacau.
RSA animate: MotivasiIni sedikit fantastis yang benar-benar menunjukkan bagaimana memotivasi pekerja berpengetahuan.
Gratis hari untuk kode apa yang mereka inginkan. Dari video RSA. Tidak ingat namanya, tetapi perusahaan yang disebutkannya memiliki penjelasan singkat tentang itu di situs mereka. Sepertinya ide yang bagus untuk saya. Di sebagian besar toko ada hal-hal yang diketahui semua orang rusak, tetapi tidak ada yang punya waktu untuk memperbaikinya, dan itu bukan prioritas tinggi. Ini memungkinkan mereka mengatasi hutang teknis. Itu juga memungkinkan mereka memamerkan ide-ide cemerlang mereka.

Dan untuk cinta tuhan, cobalah untuk tetap bekerja selama 40 jam seminggu. Juga, flextime. Flextime dapat menggantikan seluruh dunia omong kosong. Setidaknya bagi saya.

Meningkatkan komunikasi antara programmer dan bos
Itu lebih sulit bagi saya. Keseluruhan hal itu lebih merupakan keterampilan atasan daripada fokus programmer. Saya bisa mengatakan beberapa hal mendasar seperti perkiraan waktu hanya perkiraan. Berjalan di atas air dan memenuhi persyaratan mudah jika dibekukan. Mungkin meminta pemrogram pemalu untuk memberikan presentasi tentang proyek mereka di ulasan kode atau sesuatu. Latihan jadi sempurna, ya? Tapi saya akan tunduk pada saran orang lain tentang ini.

"Demikian pula, jika kamu membencinya, tolong jelaskan secara rinci alasannya."
Nah itu akan membuka pintu air di sini. Dan jika saya tidak menggunakan openID yang jelas-jelas dapat dikaitkan dengan saya, saya mungkin akan curhat juga. Jika Anda benar-benar menginginkan daftar raksasa tentang apa yang tidak boleh dilakukan, tanyakan di forum yang lebih bersahabat dengan posting anonim.

Saya selalu menemukan bahwa orang pada umumnya tidak akan memperlakukan Anda lebih baik daripada Anda memperlakukan mereka (meskipun mereka mungkin memperlakukan Anda lebih buruk). Saya pribadi (saya seorang pengembang) menanggapi kejujuran dengan kejujuran, untuk menghormati dengan hormat, untuk percaya dengan kepercayaan, dan sebagainya. Anda harus melakukan obrolan informal dengan tim Anda dalam suasana netral, dan memberi tahu mereka apa yang baru saja Anda katakan kepada kami. Titik yang akan dilupakan dalam beracun "kita versus mereka" lingkungan adalah bahwa hal itu harus semua menjadi "kita". Baik manajemen dan pekerja perlu mengetahui hal itu, dan perusahaan harus mendukungnya.

Semoga berhasil.

Anda sekarang memiliki catatan yang terbukti tidak hanya menerima umpan balik, tetapi juga menindaklanjutinya. Anda telah menunjukkan bahwa Anda memiliki pengaruh dengan pembuat keputusan yang lebih tinggi dan Anda dapat menyelesaikan sesuatu untuk tim Anda. Itu membuat perbedaan besar. Pemrogram saya menjadi lebih introvert, tetapi kami suka berbicara tentang pemrograman. Lingkungan informal itu baik, tetapi semua orang masih harus profesional. Izinkan orang untuk curhat, tapi pastikan diskusi itu produktif dan bukan hanya sesi menyebalkan.

Dari pengalaman saya, faktor paling penting bagi saya untuk suka atau tidak suka manajer saya adalah jika dia memahami perkembangan secara umum dan memahami pekerjaan yang saya lakukan. Beberapa hasil positif tercantum di sini:

• Saya tidak perlu membuang terlalu banyak waktu untuk membenarkan mengapa perubahan begitu lama atau tidak dapat dilaksanakan. Secara teknis, setiap perubahan dapat diimplementasikan dan manajemen tingkat atas biasanya menuntut implementasi dengan cara apa pun. Tetapi setidaknya dalam situasi seperti itu, manajer langsung Anda ada di pihak Anda, meminta lebih banyak waktu (bukannya mendorong Anda atau membuat Anda kelelahan).
• Saya tahu saya memiliki peluang yang lebih baik untuk didukung jika terjadi situasi yang buruk (peretasan WTF, masalah produksi, dll.). Biasanya, orang non-teknis cenderung menyalahkan pengembang untuk situasi seperti itu sementara manajer yang baik MEMAHAMI apa yang sebenarnya terjadi dan mendukung pengembangnya (tidak hanya tahu atau mau mengambil jalan seperti itu untuk bersikap baik).
• Saya tahu pekerjaan dan kinerja saya harus dievaluasi oleh orang yang tepat.

Menurut pendapat saya, jika Anda tidak melakukan pemrograman lagi dan biasanya dalam jadwal proyek yang ketat atau anggaran, kesempatan bagi pengembang Anda untuk menyukai sangat rendah. Jika itu masalahnya, Anda sebaiknya naik dengan cepat dan memiliki orang lain untuk menjadi manajer langsung. Maaf saya terdengar buruk di paragraf ini, tetapi hanya itu yang saya lihat. Anda tampaknya menjadi orang yang baik dan pantas mendapatkan kebenaran.

Saya juga salah satu dari orang-orang yang mengenakan jas, dan telah lebih dari 15 tahun. Saya adalah seorang pengembang perangkat lunak ketika saya mulai, dan saya masih menulis kode ketika saya mendapat kesempatan. Jadi saya pikir saya dapat berbicara untuk kedua belah pihak dan saya memiliki sedikit pengalaman dalam situasi ini. Saya juga memiliki kredensial, seperti "Karyawan tahun ini", yang dipilih oleh staf, yang membuat saya percaya diri dalam menangani situasi ini.

Apa yang saya saksikan sangat sering adalah bahwa ada perbedaan substansial dalam sistem nilai dan metode / pendekatan operasional yang diambil antara manajemen dan pengembang.

Bagi banyak pengembang, ketulusan, kejujuran, dan sebaliknya lingkungan kerja yang fleksibel sangat tinggi dalam daftar. Sayangnya nilai yang sama tidak terlalu tinggi dalam daftar manajemen puncak. Dan ini mengarah pada bentrokan besar, terutama jika manajemen menengah (Anda dan saya) memutuskan untuk sepenuhnya mengambil sisi manajemen puncak. Satu-satunya jalan keluar dari ini (dari sudut pandang saya) adalah dengan berdiri teguh di depan tim Anda, mendukung mereka sepenuhnya, dan membangun hubungan saling percaya melalui komunikasi terbuka dan, yang paling penting, dengan melakukan apa yang Anda katakan (yang seringkali berlawanan dengan apa yang Anda dapatkan dari manajemen puncak, di mana politik sepenuhnya mengalahkan ketulusan).

Pada saat yang sama Anda sendiri harus tetap operasional, jadi Anda harus menemukan cara untuk berkomunikasi dengan manajemen puncak dalam bahasa yang mereka pahami dan mainkan permainan mereka. Itulah tantangan sebenarnya dari manajemen menengah.

Saya percaya bahwa dengan kebahagiaan pengembang, produktivitas semua bermuara pada hal-hal kecil. Matematika bekerja dengan cukup baik untuk manajemen. Beri saya donat (-25 sen) di pagi hari dan saya akan bekerja dua kali lebih keras sepanjang hari (+ banyak dolar). Bukannya kita secara aktif mengatur berbagai hal dengan bekerja lambat ketika kita tidak puas, itu adalah bahwa kita bekerja pada sistem yang sangat rumit dan sangat sulit untuk fokus ketika kita frustrasi tentang sesuatu. Mungkin benar-benar lebih baik bahwa kita tidak membuat kode sebanyak ketika kita marah.

Perkiraan, bagaimanapun, harus ditangani sendiri. Setiap masalah yang saya miliki dapat diselesaikan dengan memberikan saya donat, dengan pengecualian kecuali perkiraan yang tidak realistis . Benar atau salah inilah yang dilihat pengembang: Manajemen memiliki segalanya untuk diraih (seperti kapal baru) dengan perkiraan yang lebih pendek, sementara pengembang kehilangan segalanya (seperti tidur selama sebulan). Manajemen bertanggung jawab, sehingga mereka memenangkan perang estimasi setiap saat. Saya pikir sistem estimasi bekerja paling baik ketika pengembang memutuskan tenggat waktu (cukup sulit bagi kami untuk memberikan perkiraan yang akurat, jadi bagaimana seorang manajer?), Tetapi manajemen secara positif memotivasi mereka untuk menjadi ambisius, dengan pemahaman bahwa tidak ada pengembang yang mendapatkan kereta api untuk menjadi sedikit off.

Pertimbangkan reaksi macam apa yang Anda berikan kepada seorang programmer yang mungkin memiliki pertanyaan, komentar, atau masalah. Apakah ada, "Apa yang kamu inginkan sekarang ?" atau "Mengapa kamu menggangguku dengan ini ?" semacam tanggapan? Seberapa baik Anda mendorong pengembang untuk menyuarakan keprihatinan dan komentar? Itu hanyalah titik awal.

Kedua, berhati-hatilah di mana Anda mencoba melakukan diskusi ini. Saya ragu saya akan sangat terbuka mendiskusikan mesin kerja saya dengan seseorang di kubus berikutnya jika saya tahu manajer saya berada dalam jangkauan pendengaran mendengar semuanya. Jika Anda ingin orang memberikan umpan balik yang jujur ​​dan terbuka, harus ada privasi yang diberikan untuk mengetahui jawaban mereka tidak akan disiarkan secara publik atau digunakan untuk menentang mereka.

Ketiga, pertimbangkan keterampilan Kecerdasan Emosional seperti apa yang Anda miliki. Kecerdasan Emosional untuk Manajer Proyek: Keterampilan Orang yang Anda Perlukan untuk Mencapai Hasil Luar Biasa oleh Anthony Mersino akan menjadi rekomendasi buku yang saya dapatkan kemarin dari Makan Siang dan Belajar tentang EQ. Jika Anda benar-benar ingin mempelajari psikologi di sini, ada berbagai alat profil kepribadian yang dapat digunakan, misalnya Enneagram, gaya sosial, dan MBTI.

Terakhir, pertimbangkan budaya di perusahaan Anda. Apakah ada kesalahan yang terjadi di bawah karpet? Apakah keluhan adalah hal yang tidak boleh dilakukan yang dapat membuat seseorang dalam masalah benar-benar mudah? Perilaku apa yang dihargai atau didorong dan yang ditoleransi dan diterima? Meskipun beberapa di antaranya adalah observasi, beberapa di antaranya mungkin juga memerlukan beberapa percakapan yang harus dilakukan baik di luar kantor atau di ruangan di mana tidak ada kemungkinan untuk menguping. Anda mungkin akan berulang kali mencoba menggunakannya di awal. Itu bukan hal yang buruk jika Anda mencoba untuk membangun praktik baru dan membuat orang-orang di papan dengan berbicara jika budaya itu terutama di mana semua orang tahu untuk "menyedotnya." Ini mungkin lebih sensitif daripada jawaban lain tetapi ini adalah apa yang saya '

Apakah para pengembang merasa bahwa Anda adalah penasihat mereka? Maksud saya bahwa mereka tahu mereka bebas untuk berbagi dengan Anda keprihatinan / frustrasi mereka tanpa dihajar? Apakah mereka merasa Anda memperjuangkan mereka? Apakah mereka merasa Anda menghargai pekerjaan mereka? Apakah mereka merasa bahwa Anda benar-benar ingin mereka berhasil dalam karier mereka?

Jika mereka merasa dihargai, Anda mungkin akan memiliki komunikasi yang lebih baik.

Sebagai pengembang saya adalah kutu buku besar dan kurang keterampilan sosial dan saya tidak meminta maaf tentang hal itu. Lagi pula, saya adalah talenta, dan Anda telah mempekerjakan saya untuk talenta saya. Jika Anda membutuhkan kupu-kupu sosial untuk melakukan pekerjaan itu, Anda akan memiliki ruangan yang penuh dengan manajer proyek, bukan pengembang.

Saya tahu bahwa beberapa pengembang sangat cerdik secara sosial, tetapi saya pikir median condong ke kutu buku introvert.

Ketika seseorang meminta saya untuk melakukan sesuatu, saya sama sekali tidak membuat kesimpulan dan melakukan apa yang diminta. Sepertinya dengan beberapa manajer proyek saya selalu berakhir dengan masalah karena mereka mengharapkan saya untuk membuat kesimpulan tentang proyek mereka yang saya benar-benar tidak akan lakukan, jadi kadang-kadang hal-hal tidak berubah seperti yang mereka harapkan walaupun mereka ternyata persis seperti apa mereka telah meminta. Saya pikir alasan bahwa hal ini terjadi pada beberapa manajer proyek adalah karena mereka tidak memberikan HLD, BRD berkualitas tinggi dan menempatkan terlalu banyak nilai dalam aspek sosial manajemen proyek daripada apa yang hitam putih.

Saya pikir di sinilah dunia bertabrakan. Saya pikir dalam dunia manajemen proyek, keterampilan sosial dan kualitas keterbukaan pribadi adalah faktor penting, tetapi bagi pengembang seperti saya sama sekali tidak ada artinya. Itu tidak mengesankan saya untuk mengoceh tentang betapa pentingnya tugas ini atau itu. Saya bahkan tidak ingin keluar untuk makan siang atau bir seperti yang disarankan beberapa orang di sini.

Yang benar-benar saya inginkan adalah HLD dan BRD berkualitas tinggi dan bagus. Saya ingin jadwal dan tenggat waktu dapat dicapai, dan jika desain atau rencana baru diperkenalkan, saya ingin jadwal dan tenggat waktu disesuaikan kembali. Saya telah bekerja pada proyek-proyek di mana persyaratannya tampaknya berubah dengan cepat - bagi saya ini adalah bendera merah saya yang saya hadapi dengan kepemimpinan proyek yang berkualitas buruk. Sebagai pengembang, hal terburuk yang dapat Anda lakukan adalah membawa saya persyaratan proyek baru setiap hari, terutama setelah kami memiliki jadwal atau membuat komitmen jadwal. Tidak dapat ditoleransi ketika persyaratan baru dimasukkan, tanpa kompensasi tenggat waktu. Bekerja lebih lama, bekerja lembur, saya tidak punya masalah dengan itu, tapi itu bukan sesuatu yang selalu kuantitatif dengan pengembangan. Beberapa perubahan dapat memakan waktu beberapa jam, beberapa perubahan bisa memakan waktu berminggu-minggu untuk R&D yang tepat, pengujian, QA dll ... Ini tidak selalu seperti memanggang kue, kadang-kadang satu perubahan pada persyaratan bisa seperti mengubah seluruh resep. Saya telah menyaksikan manajer proyek mencair dan marah pada panggilan konferensi karena tenggat waktu mereka tidak mengizinkan pengembangan tambahan, namun mereka meminta pengembangan yang tidak dalam persyaratan proyek awal mereka.

Saya hanya bisa memberikan bias dan pengalaman pribadi saya sebagai contoh, jadi jangan simpulkan bahwa saya berbicara atas nama semua pengembang. Saya hanya melihat hal-hal ini melalui mikrokosmos karir saya sendiri tetapi posting ini menggambarkan kondisi yang tepat yang menyebabkan saya menyerah.

Seberapa sering Anda berbicara dengan pengembang Anda? Maksud saya bukan pertemuan status proyek, pertanyaan tentang kiriman atau topik lain yang Anda bawa - seberapa sering Anda duduk dengan salah satu programmer Anda, tanyakan kepada mereka bagaimana keadaannya, dan dengarkan saja .

Banyak jawaban lain benar-benar baik - Anda harus melihat ke perkembangan tangkas. Anda perlu pengembang Anda untuk belajar dan tumbuh dalam peran mereka. Tetapi jika Anda tidak benar-benar mendengarkan apa yang dikatakan pengembang Anda (atau tidak!), Maka Anda harus mengatasinya terlebih dahulu.

Referensi bagus untuk satu-satu - http://www.randsinrepose.com/archives/2010/09/22/the_update_the_vent_and_the_disaster.html

Pendek dan manis. Unggulkan apa yang Anda lakukan - ini akan menimbulkan komunikasi.

Apa arti unggul bagi pengembang Anda? .. Baca, baca kembali, ya bahkan belajar PeopleWare

Semua ide dan komentar hebat di posting di atas!

Berikut ini sebuah ide: kirim staf TI Anda ke bengkel komunikasi di perguruan tinggi setempat - tentu saja, dibayar oleh perusahaan.

Pastikan a) bengkel memiliki reputasi yang baik, dan b) tidak mengirim karyawan Anda bersama. Mereka akan cenderung untuk tetap bersatu dan tidak bergaul dengan anggota kelas lainnya, tidak hanya mengurangi nilai lokakarya, tetapi menyebabkan gangguan pada yang lain.

Komunikasi berorientasi tim yang produktif adalah keterampilan yang dapat dipelajari siapa pun, tetapi merupakan subjek yang saya rasa kurang dalam sebagian besar jalur skolastik.

Gagasan ini sama sekali bukan peluru ajaib, tetapi itu adalah dasar yang bagus dari teka-teki. Karyawan Anda tidak hanya akan belajar berkomunikasi lebih baik satu sama lain, tetapi juga bonusnya, bahwa mereka akan mulai memahami dan menghargai pekerjaan ANDA dengan lebih baik juga (komunikasi menjadi inti dari PM).

Hanya 2 bit saya :)

Hanya untuk membuat jawaban dari rekomendasi yang telah muncul dalam beberapa jawaban . Michael Lopp (alias rands ) telah menulis tentang mengelola pengembang dan "mendapatkan di kepala mereka" di blog-nya, Rands in Repose , dan dalam sebuah buku, Mengelola Manusia ( sumber buku ). Buku ini sebagian besar berisi konten yang diedit dari pos-posnya sebelum 2007, dan menyediakan cara yang baik untuk mengejar ketinggalan dengan bagian-bagian yang berhubungan dengan manajemen dari blog-nya (dia juga berbicara tentang misalnya perjudian, dan apakah Anda ingin membaca itu masalah lain). Tulisannya umumnya bagus & sering lucu, sehingga ada sedikit risiko dalam membacanya.

Keluarkan tim untuk bir (dan Anda membeli).

Saya terlambat ke pesta, tetapi hanya melihat pertanyaan ini.

Satu hal yang saya lihat tidak ditangani dengan baik adalah ini:

Grunts tidak pernah mengatakan yang sebenarnya pada jas itu. Rands mengatakan ini dalam DNA tetapi tidak membahasnya langsung, dia berada di topik yang berbeda.

Anda mengenakan jas, dan Anda menandatangani cek. Anda mewakili kepentingan perusahaan. Anda tidak mewakili insinyur. Jika Anda melakukannya, Anda tidak akan menandatangani cek mereka , mereka akan menandatangani cek Anda.

Ini tentu saja bukan berita untuk Anda atau para insinyur. Tetapi ketika seorang insinyur tahu bahwa mengemukakan masalah tertentu - masalah - dengan tempat kerjanya akan menyebabkan konflik yang signifikan - risiko / imbalan tradeoff tidak menguntungkan insinyur. Insinyur dibayar untuk menghasilkan produk, bukan memulai perkelahian budaya di tempat kerja. Terlibat dalam hal itu adalah jalur cepat untuk melakukan pekerjaan yang salah.

Jadi bagian dari tugas manajemen adalah memberikan jalan bagi para insinyur untuk bersikap terbuka tentang masalah, tanpa menimbulkan politik perusahaan & serangan karir. Sangat menyenangkan untuk memiliki kenaikan gaji, setelah semua, dan ada yang perusahaan lain, jika yang satu ini tidak merasa menyenangkan.

Saya terkejut tidak ada seorang pun yang menyebutkan buku hebat ini yang persis berhubungan dengan pertanyaan dan subjek Anda - "Peopleware: Proyek dan Tim Produktif" oleh DeMarco dan Lister . Dari editorial: masalah utama pengembangan perangkat lunak adalah manusia, bukan teknis . Tiga ulasan pertama di amazon dengan mudah akan cukup meyakinkan saya untuk membeli buku ini jika saya berada dalam situasi Anda.

Banyak jawaban di sini memiliki poin yang sangat bagus, tetapi saya hanya ingin memberikan beberapa sumber yang dapat membantu. Saya telah berada dalam beberapa situasi yang baik hancur menjadi berantakan besar atau diselesaikan dengan sangat efisien karena komunikasi antara orang-orang yang terlibat. Tiga buku telah membantu saya secara pribadi meningkatkan keterampilan komunikasi saya, terutama dalam situasi stres tinggi di mana ada banyak hal yang perlu diperhatikan:

• Percakapan Sulit: Bagaimana Mendiskusikan Apa yang Paling Penting
• Percakapan Penting: Alat untuk Berbicara Ketika Taruhannya Tinggi
• Konfrontasi Krusial: Alat untuk Menyelesaikan janji yang dilanggar, harapan yang dilanggar, dan perilaku buruk

Dari membaca pertanyaan Anda, saya pikir Anda melihat nilai komunikasi. Saya pribadi merasa bahwa komunikasi lebih penting bagi manajer atau pemimpin daripada keterampilan bisnis atau teknis. Orang-orang yang Anda pimpin harus memiliki keterampilan keras yang Anda butuhkan untuk menyelesaikan sebagian besar proyek. Seorang pemimpin teknis atau manajer proyek yang baik harus dapat fokus pada komunikasi, apakah itu di dalam tim atau antara tim dan pelanggan atau tim dan entitas bisnis (atau bahkan kombinasi dari ketiganya).

Baca beberapa novel hebat yang memberi wawasan tentang perspektif tenaga kerja teknis:

• Peretas, Steven Levy - http://en.wikipedia.org/wiki/Steven_Levy
• Microserfs, Douglas Coupland - http://en.wikipedia.org/wiki/Douglas_Coupland
• Cathedral and the Bazaar, Eric Raymond - http://en.wikipedia.org/wiki/Cathedral_and_the_Bazaar

Ini sama pentingnya dengan memoar khas pada manajemen (Drucker et al).

Saya telah melakukan berbagai peran selama bertahun-tahun - pengembang, pengembang senior, pemimpin teknis, dll.

Dari pertanyaan Anda - cukup jelas bahwa pengembang Anda tidak memberi tahu Anda hal-hal karena mereka tidak berpikir Anda dapat membantu.

Ini mungkin karena 2 alasan.

1. Mereka tidak berpikir Anda memiliki kekuatan untuk memperbaiki keadaan. Namun, saya pikir ini tidak mungkin karena Anda mungkin akan mengetahuinya & juga para pengembang akan merengek tentang hal itu kepada Anda.
2. Anda adalah tipe orang yang ketika seorang pengembang menemui Anda dengan masalah, melakukan satu atau lebih hal-hal berikut
   • Ketika mereka menemui Anda dengan masalah, Anda memberi tahu mereka - Saya suka solusi, bukan masalah.
   • Anda mendengarkan mereka dengan baik & tugas mereka dengan memperbaiki masalah. Anda memberi mereka sedikit bicara tentang kehormatan bagi mereka diberi tanggung jawab untuk memperbaiki masalah. Seiring waktu, orang-orang Anda mengerti bahwa ketika mereka mendatangi Anda dengan masalah, mereka akan berakhir dengan pekerjaan ekstra, sehingga mereka tidak mendatangi Anda dengan masalah.
   • Anda menyangkal itu masalah. Anda memberikan alasan meyakinkan untuk ini. Tetapi karena hal ini terus terjadi, lama kelamaan teman-teman Anda mengetahui bahwa tidak ada gunanya mendekati Anda dengan masalah.
   • Anda mengatakan "Ya, saya mengerti". Anda mengatakan hal semacam ini terjadi sesekali & tidak ada yang bisa dilakukan. Jika ini sebuah pola, maka sekali lagi kalian mengerti.

Jika salah satu atau semua hal di atas, maka Anda perlu memperbaikinya.

Hal yang paling saya benci adalah orang-orang mendapatkan di antara saya, pengembang, dan pengguna akhir. Manajer terbaik membiarkan saya melakukan ini dan mengubah solusi kami agar sesuai dengan apa yang menurut saya diinginkan atau dapat dilakukan pengguna.

Praktik terburuk bagi saya sering berpakaian sebagai "baik" - biasanya manajer memiliki diri mereka sendiri, atau BA atau seseorang menulis spesifikasi yang harus ditafsirkan dan diterapkan oleh para pengembang, dengan rentang waktu yang disepakati sebelumnya.

Jika ini adalah solusi khusus yang sering kali bahkan pengembang tidak akan tahu berapa lama dan biasanya pelanggan tidak tahu apa yang terbaik untuk mereka. Itulah sebabnya pengembangan itereatif sangat bagus. Bukankah cara sebagian besar transaksi dilakukan sehingga manajer yang baik akan berjuang untuk bekerja seperti di atas.

Akhirnya beberapa pengembang tidak pandai berkomunikasi dan tidak bisa berhubungan dengan pelanggan. Mereka mungkin paling cocok untuk masalah dengan persyaratan yang jelas, terutama persyaratan teknis yang jelas. Mungkin Anda membutuhkan pengembang yang merupakan komunikator yang lebih baik dan ingin bekerja untuk menyelesaikan masalah bisnis bukan masalah teknis murni.

Sangat mudah untuk membuat tim senang

Cobalah untuk mendengarkan mereka berkali-kali pertanyaan mereka memiliki jawaban juga di dalamnya. saya akan mendorong anggota tim untuk datang dengan masalah dan solusi yang mungkin.

Tamasya tim adalah ide yang bagus (mungkin beberapa rencana permainan)

jika proyek Anda membutuhkan kerja larut malam dan akhir pekan dan Anda berpikir bahwa Anda sebenarnya tidak menambahkan banyak nilai pada tim, tetap merupakan ide yang baik untuk menghabiskan waktu dengan sesuatu untuk dimakan dan menghargai tim tentang upaya mereka dan jika mungkin mengatur beberapa PTO mereka

lakukan dua bulan sekali 1: 1 dengan setiap anggota tim untuk memastikan bahwa mereka merasa nyaman.

Terakhir, namun mungkin juga merupakan ide bagus bagi Anda untuk memahami proyek secara fungsional dan agak teknis juga.

Tolong beri tahu saya jika Anda memiliki pertanyaan lain

Saya juga manajer perangkat lunak (Perancis jadi maafkan bahasa Inggris saya) yang memiliki latar belakang teknik ilmiah tetapi tidak secara khusus latar belakang perangkat lunak TI. Jadi saya tidak memiliki kedekatan khusus dengan pengkodean pada awalnya, tetapi saya sudah menjadi insinyur kualitas statistik dari sekolah Deming yang memiliki pengajaran yang sangat berbeda untuk setiap sekolah "modern" yang diikuti meskipun mereka berpura-pura mewarisi dari Deming. Yang terburuk adalah 6 sigma, lean lebih baik tetapi sayangnya yang terjadi adalah ini http://leanandkanban.wordpress.com/2011/05/13/what-did-deming-really-say :

“Awalnya Six Sigma berasal dari Toyota Quality Management (TQM) oleh Motorola untuk mencapai tingkat kualitas enam sigma, dan kemudian melalui Allied Signal dan GE, perusahaan ini berubah menjadi proyek oleh Black Belt berdasarkan statistik untuk menjadi program pengurangan biaya — setiap proyek membutuhkan ROI yang jelas. Dengan kata lain, kami merendahkan program dari filosofi kepemimpinan menjadi banyak sekali proyek untuk memangkas biaya. Itu adalah bastardisasi lengkap dari yang asli, dan jarang menyebabkan perubahan yang berkelanjutan dan berkelanjutan karena kepemimpinan dan budaya hilang.

“Hal serupa terjadi pada lean ketika dikurangi menjadi toolkit (misalnya, pemetaan aliran nilai, papan KPI, sel, kanban).

"Lean dan Six Sigma sama sekali tidak mencerminkan pemikiran asli perusahaan-perusahaan Jepang yang sangat baik atau guru-guru mereka seperti Deming."

Hari ini gerakan Agile seperti lean (lihat kursus Jeff Sutherland dan penghargaannya atas Deming http://blogs.forbes.com/stevedenning/2011/05/27/jeff-sutherland-the-21st-century-will-be-the- -century-of-scrum / ), ini lebih baik daripada Waterfall tetapi masih sangat jauh dari pengajaran asli Deming karena alih-alih membaca Deming dalam teks aslinya, guru hanya mengemas ulang dia kira-kira tidak pernah mengutip seluruh 14 prinsip Manajemennya, dan menjual alat dan seminar yang memiliki nilai kecil sendiri.

Sekarang ketika datang ke bidang perangkat lunak, masalahnya adalah ada orang-orang di satu sisi yang mengetahui prinsip-prinsip umum tetapi tidak memiliki ide nyata bagaimana benar-benar menerapkannya dan di sisi lain orang-orang yang menulis perangkat lunak tetapi mengabaikan prinsip-prinsip karena mereka hanya mendengarkan guru palsu yang menjual alat kepada mereka tanpa memberi tahu mereka prinsip yang sebenarnya dan mereka sebenarnya harus membangun alat manajemen mereka sendiri.

Jadi bagi saya manajer proyek perangkat lunak harus melakukan upaya untuk masuk lebih dalam ke operasionalitas sehari-hari pengkodean perangkat lunak, tidak hanya melakukan perencanaan di Proyek Microsoft (atau grafik luruh dengan Agile) atau presentasi yang bagus di Powerpoint ke manajemen atas tetapi memiliki beberapa nilai juga untuk tim pengembang. Ketika tim pengembang memiliki masalah bahkan jika itu adalah masalah teknis, manajer proyek dapat membantu untuk mengarahkan diagnostik dengan mata eksternal. Dia dapat melihat kode, bahkan jika dia tidak memahami detail kecil, dia dapat mengajukan beberapa pertanyaan naif yang dapat memicu pengembang untuk menyadari mereka tidak memikirkan petunjuk itu (saya punya banyak contoh pribadi tetapi terlalu panjang sehingga saya akan lebih baik menulis artikel di blog saya).

Hal lain adalah bahwa saya mencoba untuk memiliki kesadaran umum tentang evolusi di lapangan seperti kerangka kerja baru, paradigma arsitektur baru dengan membaca artikel teknis. Saya akan berpartisipasi dalam beberapa tes integrasi, menulis beberapa dokumentasi sendiri (programmer hal-hal benci jadi saya lakukan untuk mereka, mereka tentu saja memberi saya inti), apa pun yang saya bisa lakukan secara praktis untuk membantu tim.

Secara umum pengembang merasa mereka melakukan kerja keras, dan memang benar, sering saya mengatakan kepada mereka bahwa saya melakukan bagian yang mudah dengan tetap dalam abstraksi, namun saya mencoba membantu secara konkrit ketika dibutuhkan - karena manajemen mikro juga tidak baik karena dapat menimbulkan gangguan perasaan.

Sebagai kesimpulan: hilangkan slogan-slogan dengan pengembang (itu sebenarnya salah satu dari 14 prinsip Deming), tunjukkan pada mereka bahwa Anda peduli dengan perangkat lunak proyek beton, bukan tentang dokumen atau pertemuan Anda dengan manajemen tingkat atas saja.