Apakah manajer proyek yang baik membutuhkan latar belakang pemrograman? [Tutup]

Kadang-kadang saya tidak tahan ketika manajer proyek meminta saya untuk memperkirakan waktu untuk menyelesaikan berbagai tugas. Estimasi adalah tebakan, dan tebakan bisa salah. Secara umum, persyaratan dan dokumentasi yang buruk akan menyebabkan dugaan buruk.

Jadi saya sering bertanya-tanya apakah manajer proyek pernah mencoba untuk menebak berapa lama tugas X dan Y akan berlangsung, dan seberapa sulit untuk menetapkan nomor berdasarkan apa yang sedikit diketahui dan dikumpulkan dari klien.

Pertanyaan saya kemudian adalah: Apakah manajer proyek yang baik perlu memiliki latar belakang pemrograman?

Atau mungkin pertanyaannya seharusnya, apakah manajer proyek yang baik perlu menjadi programmer yang baik sebelumnya? Apakah ada korelasi?

Mengelola proyek TI jelas tidak sama dengan mengelola jenis proyek lainnya. Saya pernah mendengar tentang seorang manajer proyek tanpa pengalaman IT. Dia akhirnya membuat frustrasi para programmer dan pada dasarnya membuat mereka takut.

Di sisi lain, seorang programmer yang menjadi Project Manager dapat menjadi orang yang suka mengontrol, berpikir dia dapat memperbaiki hal-hal jika dia tidak dapat membuat programmer melakukannya dengan benar (yang telah menjadi masalah saya dalam situasi yang sama)

Seorang manajer dengan latar belakang teknis yang kuat biasanya lebih memahami bagaimana tim mereka "berpikir". Itu selalu lebih baik untuk memiliki manajer yang mengerti Anda, bukan?

Tidak. Dua keterampilan yang sangat berbeda. Manajer proyek yang buruk belum tentu seseorang yang tidak mengerti IT, dan sebaliknya.

Menjadi masuk akal, rasional, terorganisir, memahami tujuan proyek dan bisnis terkait , dan motivator yang baik sama sekali tidak bergantung pada kemampuan untuk memprogram.

Semuanya setara, saya lebih suka manajer proyek dengan pengalaman teknis yang kuat dan terkini . Namun di dunia nyata, programmer yang lulus ke manajemen proyek penuh waktu lebih mungkin untuk membiarkan keahlian mereka menjadi basi dan ketinggalan zaman, yang tidak jauh lebih baik daripada mereka yang tidak memiliki latar belakang teknis.

Saya telah bekerja dengan manajer proyek yang baik dan beberapa manajer yang buruk, dan saya dapat dengan jujur ​​mengatakan bahwa saya telah melihat sedikit korelasi antara kemampuan manajemen mereka dan latar belakang teknis mereka. Faktor yang paling penting bukanlah latar belakang teknis, tetapi seberapa banyak pengalaman mereka dalam mengelola proyek perangkat lunak . Jika Anda memiliki dua orang yang mengelola proyek pertama mereka, programmer yang lulus dalam manajemen proyek akan sama buruknya dengan manajer proyek tanpa latar belakang TI. Keduanya akan melalui proses pembelajaran yang curam.

Argumen atas kemampuan manajer proyek tanpa latar belakang teknis mengingatkan saya sedikit tentang ini:

Jujur saya pikir jawabannya adalah tidak. Ada banyak kompetensi yang diperlukan untuk menjadi manajer proyek yang baik dan menjadi programmer bukan salah satunya. Seorang manajer proyek yang baik dapat mengelola proyek apa pun jenis apa pun mengingat bahwa ada orang-orang baik di tim proyek yang tahu apa yang mereka lakukan. Kualitas utama yang harus dimiliki manajer proyek adalah keterampilan komunikasi . Tugas manajer proyek adalah mengoordinasikan tugas-tugas proyek dan menjaga komunikasi tetap mengalir antara pelanggan, tim proyek, dan pemangku kepentingan lainnya. Ia harus selalu mengetahui kemajuan tim dan jika mereka mengalami hambatan, tetapi tidak perlu tahu apa masalahnya atau apa yang Anda butuhkan untuk memperbaikinya, kecuali jika itu melibatkan orang lain dalam tim yang waktunya akan perlu disesuaikan untuk membantu memperbaiki masalah.

Sedangkan untuk memberikan perkiraan, itulah kenyataan hidup dalam pekerjaan apa pun. Anda tidak akan pernah bisa membangun rumah tepat waktu jika tukang listrik tidak bisa memberi tahu Anda berapa lama waktu yang dibutuhkan untuk melakukan pemasangan kabel - kapan Anda tahu memesan tukang dinding? Saya setuju bahwa IT sangat sulit untuk memberikan perkiraan karena tingginya angka yang tidak dapat ditebak. Pelanggan tidak selalu tahu apa yang mereka inginkan dan mereka cenderung lupa memberi tahu Anda banyak hal. Yang biasa saya lakukan adalah memperkirakan kira-kira berapa lama saya pikir akan butuh waktu, lalu kalikan dengan 2! Dan seorang manajer program yang baik tidak seharusnya menyalibkan Anda ketika perkiraan Anda terbukti salah, itu akan membuatnya sakit kepala untuk mengatur kembali jadwal, berbicara dengan pelanggan, menjelaskan kepada bos bahwa itu akan lebih mahal, dll ... Tapi itu bagian dari pekerjaan mereka - sekali lagi, sebagian besar yang dibutuhkan.

Dan saya bahkan akan mengatakan bahwa tidak memiliki keterampilan pemrograman lebih baik - seorang mantan programmer mungkin mencoba melakukan estimasi sendiri atau menebak perkiraan Anda. Dan kita semua tahu bahwa keterampilan TI menjadi sangat cepat ketinggalan jaman. Anda perlu mulai mengajukan pertanyaan ketika manajer proyek Anda lebih tertarik pada bagaimana Anda akan melakukan tugas daripada pada berapa lama waktu yang dibutuhkan dan kapan Anda akan selesai. Mereka dapat meminta Anda untuk mengevaluasi alternatif dan membiarkan Anda mengetahui detailnya tetapi poin utamanya adalah untuk mengetahui bagaimana Anda akan memengaruhi jadwal proyek.

Akhirnya, saya tidak mengatakan bahwa tidak ada keterampilan TI yang diperlukan untuk mengelola proyek TI - orang-orang TI adalah tipe yang sepertinya tidak bisa memvariasikan apa yang mereka katakan untuk masyarakat umum (!), Itu membantu untuk mengetahui jargon dasar untuk dapat berkomunikasi dengan mereka! Juga mengetahui langkah-langkah dasar sangat penting - Anda perlu mengatur server sebelum menjalankan situs web di atasnya. Saya tidak bisa mengelola proyek konstruksi jika saya tidak tahu bahwa tukang listrik harus menyelesaikan kabel sebelum saya menutup dinding !!

Seorang PM benar-benar perlu tahu apa yang akan dilakukan proyek, yang kemungkinan membutuhkan latar belakang teknis tetapi tidak berkembang.

Selain itu, ini soal menghormati bidang dan pengembang, lebih dari pengetahuan yang sebenarnya. Seorang PM perlu menganggap serius para pengembang, apa yang mereka butuhkan, apa yang bisa mereka lakukan, apa yang tidak bisa mereka lakukan, berapa lama waktu yang dibutuhkan. Seorang PM yang memiliki gagasan tentang apa yang tidak dia ketahui bisa sangat efektif. Seorang PM yang berpikir dia memiliki semua jawaban itu buruk. Ini bisa menjadi mantan pengembang yang percaya dia tahu segalanya dan tidak, atau orang yang tidak pernah berkembang dan tidak berpikir dia membutuhkan pengetahuan teknis khusus untuk dikelola.

Saya tidak berpikir seorang manajer proyek proyek TI memerlukan latar belakang TI. Tetapi dia harus benar-benar memahami IT, dan harus tahu bagaimana proyek IT bekerja.

Meskipun latar belakang TI adalah keuntungan tambahan, kekurangannya tidak menjadikannya manajer proyek TI yang tidak terlalu baik. Juga memiliki latar belakang TI bukanlah faktor penentu.

Saya telah bekerja dengan kedua tipe ini, dan masing-masing memiliki serangkaian kualitas dan masalah yang unik.

Dengan IT backround:
- Akan mengerti ketika kita mengatakan kesalahan kinerja karena kode tidak multi-threaded
- Tetapi, dalam beberapa situasi, akan mengatakan "hei ayolah, itu hanya menambahkan 4 baris kode, Anda dapat melakukannya dalam 10 hari"

Tanpa latar belakang TI:
- Akan sangat nyaman untuk bernegosiasi untuk mengubah tenggat waktu yang nyaman
- Untuk proyek tanpa persyaratan (sama sekali, belum), kadang-kadang akan mengatakan "dapatkah kita memberikan perkiraan kasar 100 hari dan menyebutkan buffer 30%.

Saya percaya mereka membutuhkan latar belakang pemrograman. Jika tidak maka mereka akan selalu menekan para programmer untuk melakukan tugas mereka dengan cepat dan berharap itu akan selesai dalam beberapa jam ketika sebenarnya tugas tersebut membutuhkan banyak pemikiran dan dedikasi. Kualitas-kualitas ini diketahui dan dipahami oleh para programmer sehingga jika manajer proyek memiliki latar belakang pemrograman maka dia akan mengerti berapa lama tugas spesifik akan berlangsung dan tidak akan ada argumen di dalam departemen dan dengan demikian pada akhirnya proyek yang baik akan berkembang.

@NimChimpsky Saya setuju.

Ini masalah apa , bukan bagaimana (Mendengarkan Aktif adalah alat yang bagus).

Estimasi bekerja untuk tugas teknis kecil, tetapi untuk perencanaan Anda perlu bekerja sama untuk melihat keseluruhan kerumitan. Dan Anda bukan saingan.

Pasti akan membantu terutama jika mereka bukan manajer proyek yang baik. Untuk seorang manajer proyek yang baik itu sangat penting.

Tidak.

Manajer proyek yang baik adalah seseorang yang dapat berempati dan memahami apa kebutuhan, preferensi, dan kemampuan timnya, baik di lokasi konstruksi, lantai pabrik, atau rumah pengembangan perangkat lunak.

Manajer proyek yang baik atau buruk dapat memiliki latar belakang:

Manajer yang buruk dengan latar belakang teknis bisa saja seorang programmer yang tidak menghargai kesulitan yang dihadapi pemula ketika berhadapan dengan duniawi, konsep "mudah" seperti pointer.

Seorang manajer yang baik bisa jadi programmer biasa yang tidak secemerlang atau sepintar rekan-rekannya tetapi memiliki pemahaman yang mendalam tentang struktur proyek, persyaratan, dan memahami pelajaran dari The Mythical Man Month dengan hati karena dia hidup dengan kode yang buruk sendiri dan dikunyah karena tidak menyelesaikan kiriman tepat waktu.

Manajer yang baik bisa jadi orang penjualan perangkat lunak yang mengetahui bahwa teman-teman pembuat kodenya tidak bisa pergi bersamanya pada akhir pekan karena janji-janji tidak realistis yang dia berikan kepada klien.

Pengetahuan teknis tidak menentukan kualifikasi programmer sebagai manajer, karena keterampilan yang diperlukan dalam kedua pekerjaan sama sekali berbeda. Jadi tidak.

Saya belum pernah melihat manajer proyek tanpa pengalaman IT yang dapat mengelola proyek pengembangan perangkat lunak non-sepele sepele. Saya telah melihat sangat sedikit manajer proyek dengan pengalaman TI yang bisa melakukan itu, tetapi mereka tampaknya kurang mengacaukannya.

Dalam pengalaman saya, manajemen adalah tentang komunikasi yang efektif dan pengambilan keputusan. Dengan pemikiran itu, masuk akal bahwa seseorang yang memahami kerajinan tangan (setidaknya konsep inti dan terminologi) yang digunakan oleh orang yang mereka kelola, lebih cocok untuk menjadi manajer daripada seseorang yang kurang memiliki pemahaman, tetapi pasti ada tidak ada korelasi. Saya telah melihat manajer dengan pengalaman pemrograman berhasil dan gagal, sama seperti manajer tanpa pengalaman pemrograman.

Baik ekstrim itu buruk, menurut saya; Orang-orang dengan pengalaman pemrograman yang terlalu sedikit dapat secara membabi buta mempercayai programmer mereka (Shepard mengikuti domba); Orang-orang dengan terlalu banyak pengalaman dapat terus mempertanyakan upaya tim mereka (pengelolaan mikro).

Secara pribadi, saya pikir seseorang yang memiliki pemahaman yang baik tentang konsep pemrograman inti, tetapi menyadari bahwa mereka bukan "hot shot," adalah jenis manajer yang ideal.

Pastinya.

Saya harus berhati-hati dengan yang satu ini karena didasarkan pada kisah nyata tetapi saya akan mencoba menjelaskan rasa sakit saya.

Saya bekerja sebagai insinyur perangkat lunak dan kami memiliki manajer proyek dengan siapa saya banyak bekerja akhir-akhir ini. Dia tidak memiliki latar belakang teknis dan tampaknya itu tidak menarik sama sekali tetapi itu bukan masalah (semua orang memiliki minat sendiri). Jika Anda tidak suka memiliki pengetahuan teknis yang menyebabkannya agak "aneh" daripada milik Anda, TAPI jika itu adalah pekerjaan Anda untuk berbicara dengan pelanggan pada tingkat teknis, penting untuk memiliki pengetahuan teknis yang tidak dimiliki olehnya. memiliki.

Lagi pula ada orang ini dia tidak mengerti apa-apa tentang bagaimana server bekerja, bagaimana halaman web bekerja, bagaimana pemrograman bekerja dan sebagainya. Terkadang aku merasa dia tidak tahu APA SAJA. Jadi, setiap kali saya mencoba membuatnya jelas apa yang harus kita lakukan sekarang atau apa masalahnya adalah apa yang kita miliki saat ini dia tidak mengerti apa-apa. DAN dia bukan tipe pria yang akan berkata, "Tunggu sebentar. Bisakah Anda ulangi bahwa saya benar-benar tidak mengerti." Tidak, dia adalah tipe pria yang tidak ingin menunjukkan bahwa dia tidak mengerti apa pun di seluruh percakapan.

Tapi itu tidak berakhir di sini karena dia kemudian memanggil pelanggan dan berbicara sesuatu yang pada dasarnya tidak benar. Dan akhirnya kami harus memanggil pelanggan bersama untuk menjelaskannya kembali.

Itu sebabnya saya mengatakan itu sangat penting untuk memiliki beberapa latar belakang teknis dasar dan pengetahuan teknis. Dia seharusnya tidak dapat menulis kode tetapi dia harus dapat memahami apa yang sedang terjadi dan proses apa yang harus dilakukan.

BTW karena saya bekerja dengannya, pekerjaan saya tidak lagi menyenangkan.

Saya akan mengatakan ya, dia harus memiliki latar belakang pemrograman. Jika manajer tidak memiliki petunjuk tentang apa yang ingin diprogram, maka ia akan berakhir dengan perkiraan yang tidak realistis untuk pengembangan dan perbaikan bug. Juga, dia tidak akan memahami masalah teknis dengan cukup baik untuk membuat keputusan. Programer dalam tim bisa berbohong kepadanya dan dia mungkin tidak menyadari, juga programmer bisa memberitahunya masalah dan dia mungkin berpikir bahwa mereka omong kosong di sekitar

Keterampilan teknis tidak menjadikan manajer yang baik, tetapi keterampilan manajemen yang baik. Akan sangat membantu jika seorang manajer melakukan banyak hal dalam "parit" karena mereka dapat memiliki apresiasi terhadap proses yang tidak dapat dimiliki oleh orang awam. Namun, hal itu juga dapat mengakibatkan semacam kontrol gila yang bahkan tidak dimiliki manajer awam aneh. Mereka mungkin mencoba melakukan semua pekerjaan sendiri atau meneliti pekerjaan Anda dengan cara yang sangat tidak nyaman.

Dalam pengalaman pribadi saya, manajer terbaik yang pernah saya miliki tidak tahu apa-apa tentang teknologi, tetapi dia tahu bahwa orang-orang yang bekerja di bawahnya tahu barang-barang mereka, dan dia tahu bagaimana mendapatkan kesetiaan dan rasa hormat dari timnya. Saya bekerja di bawahnya selama empat tahun, dan hanya meninggalkan perusahaan karena dia telah pergi dan digantikan oleh manajer yang tidak sebagus itu.

Salah satu manajer terburuk yang pernah saya miliki adalah mahir dalam pengkodean (jika bukan desain perangkat lunak) dan melakukan begitu banyak pekerjaan sendiri sehingga dia meninggalkan kita semua hanya dengan memo, perbaikan bug atau proyek yang tidak dia inginkan untuk melakukan sendiri.

Tampaknya ada beberapa kebingungan:

PM bukan bos pengembang . Orang yang bertanggung jawab untuk tim dev (Ketua Tim, Manajer) dan melakukan perekrutan dan evaluasi harus memutuskan apakah Anda bekerja cukup keras.

Estimasi tidak sempurna. Saya pikir PM memahami ini lebih dari yang Anda pikirkan. Apakah Anda benar-benar berharap tidak ada yang pernah bertanya kepada Anda berapa lama untuk melakukan sesuatu? Everyboy ingin tahu kapan itu dilakukan dan itu adalah tugas PM untuk melacaknya.

Anda bisa menjadi PM adalah Anda: A) memahami cara mengelola proyek B) memahami proses pengembangan. Tidak satu pun dari ini membutuhkan pengetahuan pengkodean, tetapi itu bisa membantu.

Menentukan apakah para programmer mendapatkan cukup pekerjaan bukanlah pekerjaan PM kecuali dia merangkap sebagai pemimpin tim. Untuk mengetahui apakah seseorang "menghembuskan asap" tentang waktu untuk menyelesaikan suatu tugas, seorang manajer akan selalu mendapat keuntungan jika dia memahami apa yang terlibat.

Perkiraan menjadi lebih baik dengan programmer berpengalaman yang memiliki sejarah bekerja pada jenis proyek tertentu. Tidak ada yang mengharapkan mereka sempurna, tetapi mereka berharap Anda benar-benar dekat dan menjadi lebih baik dari waktu ke waktu.

Saya teringat pepatah lama: "Anda tidak harus gila untuk bekerja di sini, tetapi itu membantu".

Jawaban singkatnya adalah bahwa pengalaman pengkodean langsung bukanlah persyaratan PM perangkat lunak yang baik, tetapi biasanya lebih disukai. Apa yang penting untuk menjadi PM yang mampu adalah memahami proses pengembangan (metodologi apa pun yang digunakan), dan percaya bahwa para pengembang mau dan mampu melakukan pekerjaan mereka. Pengalaman pengembangan memberikan pengetahuan langsung tentang proses itu, oleh karena itu membantu. PM yang bekerja menaiki tangga di sebuah perusahaan juga mengetahui budaya perusahaan (dan basis kode), dan memiliki hubungan dengan anggota tim dev lainnya yang telah lama melayani, itulah sebabnya IMO yang terbaik dipromosikan dari dalam PM. dibawa dari luar. Jika seseorang di luar perusahaan dapat mengelola tim lebih baik daripada seseorang dari dalam, hal-hal yang SANGAT salah.

Satu hal yang saya sebutkan adalah hubungan antara PM dan tim dev. Ini baik di tingkat interpersonal dan teknis. Kuncinya di sini adalah komunikasi; para devs harus merasa bahwa mereka dapat membawa masalah, baik teknis maupun antarpribadi, kepada PM, dan PM harus memahami anggota tim dev ketika mereka menggambarkan suatu masalah.

Mengenai sifat spesifik pertanyaan Anda, perkiraannya persis seperti itu; perkiraan berpendidikan untuk kuantitas (sebagai lawan dari hipotesis, yang merupakan prediksi yang lebih umum dari hasil acara mendatang). Manajer biasanya akan secara matematis atau intuitif menerapkan beberapa pengubah, berdasarkan pada perkiraan Anda terbaru versus jadwal aktual. Agile membangun ini ke dalam proses estimasi; klien secara intuitif memperkirakan kerumitan persyaratan, kemudian devs melakukan hal yang sama, dan kemudian devs benar-benar keluar dan mengembangkan solusi, memberikan poin data manajer untuk menghitung rasio poin persyaratan ke poin dev, dan poin dev ke manusia - Persyaratan Anda.

Singkatnya, seorang manajer hanya akan mengambil estimasi Anda pada nilai nominal dalam salah satu dari tiga skenario:

• Anda sudah cukup akurat dengan perkiraan tugas serupa di masa lalu.
• Dia berada di bawah tekanan untuk memberikan, dan perkiraan Anda lebih baik dari yang dia kira.
• Dia mencari alasan untuk memecatmu.

Jika ini situasi terakhir, akan ada banyak petunjuk lain di sekitar tempat kerja yang mungkin Anda harus keluarkan.

Saya tidak tahu tetapi palungan saya memang membutuhkan pengetahuan teknis. Tidak mungkin menjelaskannya kadang-kadang.