it-swarm-id.com

Mengapa analis bisnis dan manajer proyek mendapatkan gaji lebih tinggi daripada programmer?

Kita harus mengakui bahwa pemrograman jauh lebih sulit daripada membuat dokumentasi atau bahkan membuat bagan Gantt dan meminta kemajuan kepada programmer. Jadi bagi kami yang naif, mengetahui bahwa pemrograman umumnya lebih sulit, mengapa analis bisnis dan manajer proyek mendapatkan gaji lebih tinggi daripada programmer? Apa yang membuat pekerjaan mereka menjadi pekerjaan bergaji tinggi padahal programmer paling sering pulang terlambat?

PEMBARUAN

Maafkan ketidaktahuan saya, dari beberapa tanggapan tampaknya alasan mengapa BAs dan PM mendapat gaji yang lebih tinggi karena merekalah yang biasanya bertanggung jawab atas kekacauan yang dibuat oleh programmer. Tetapi pada akhirnya, programmerlah yang membuat tangan mereka kotor untuk memperbaiki kekacauan dan bekerja lebih keras. Jadi itu masih tidak masuk akal.

324
Joshua Partogi

Apakah manajer proyek mendapatkan gaji lebih tinggi daripada programmer dan analis bisnis sama sekali ada sebagai kelas tergantung pada dunia perangkat lunak tempat Anda tinggal.

Jawaban sederhana untuk pertanyaan ini adalah "karena dalam masyarakat kita, kita masih berpikir gaji terikat pada posisi dalam hierarki." Tetapi jawaban ini mencerminkan fakta bahwa orang dibayar berdasarkan nilai yang dipersepsikan tidak menjelaskan mengapa PM dan BA berada di puncak hierarki dalam banyak organisasi perangkat lunak dan mengapa manajemen memilih hierarki pertama-tama sebagai struktur pilihan untuk tim proyek perangkat lunak. Ini adalah dua pertanyaan yang tampaknya benar-benar layak diajukan.

Secara garis besar ada dua kategori organisasi pembuat perangkat lunak. Saya akan memanggil mereka Widget Factory dan Kru Film.

Pabrik Widget lahir dari sekolah manajemen pemikiran berputar motivasi Teori X diusulkan oleh McGregor: karyawan peringkat malas dan membutuhkan kontrol dan pengawasan konstan, pekerjaan diadakan atas nama gaji, manajer dibayar selalu dapat melakukan pekerjaan bawahan mereka ke standar yang lebih tinggi atau, setidaknya, sama. Pemikiran ini berasal dari ide alami bahwa seluruh tim dapat dengan mudah diganti dan diwakili oleh manajer sendiri - setelah semua orang di tim dapat diganti dengan mudah atau hanya untuk meningkatkan kemampuan manajer untuk menyelesaikan tugas. Karenanya hierarki sebagai struktur dan peran pekerjaan agak horizontal.

Manajemen pabrik Widget beroperasi dengan asumsi bahwa perangkat lunak dapat dibuat dari spesifikasi yang disiapkan oleh analis bisnis melalui proses yang jelas dijalankan di bawah pengawasan ketat seorang manajer proyek. Pabrikan diurus oleh staf proyek dengan cukup sumber daya pemrograman dan pengujian dipertukarkan. Pekerjaan didorong oleh anggaran yang sudah diatur sebelumnya berdasarkan kasus bisnis awal yang disiapkan oleh PM dan BA.

Manajemen yang menjalankan Pabrik Widget mudah dikenali hanya dengan memperhatikan cara orang-orang ini berbicara. Mereka cenderung membahas tentang sumber daya (termasuk ketika merujuk pada anggota tim), proses, efisiensi operasi, keseragaman, pengulangan, kontrol ketat atas penggunaan sumber daya, peran pekerjaan yang jelas dan input dan output proses yang jelas. Mereka dengan santai menyebutkan metafora pabrik yang sebenarnya ketika mencoba menyampaikan gambar operasi pengembangan perangkat lunak yang ideal seperti yang mereka lihat.

Lalu ada Film Crews. Mereka didasarkan pada gagasan bahwa orang cerdas, motivasi diri, bekerja sangat keras dan menikmati pekerjaan mereka seperti anak-anak menikmati bermain. Film Crews mengakui bahwa karena spesialisasi kemampuan kontributor individu mungkin jauh melebihi kemampuan orang mengorganisir, mengoordinasi dan mengarahkan pekerjaan. Karena manajer tidak dapat lagi menggantikan semua orang, struktur hierarkisnya tidak berfungsi dengan baik - orang harus bekerja sama dalam formasi yang lebih datar dan kompleks untuk menyelesaikan sesuatu. Peran pekerjaan itu sendiri cenderung jauh lebih vertikal - mulai dari selesai - dan melibatkan beragam keterampilan yang lebih luas. Pemikiran manajemen ini didukung oleh Teori McGregor Y .

Seorang sutradara Kru Film tahu bahwa visinya untuk sebuah perangkat lunak hanya dapat menjadi kenyataan seandainya ia dapat mengumpulkan kru yang hebat, memesona imajinasi dan membantu tim untuk gel dan bekerja bersama. Perannya adalah untuk menginspirasi, menjaga visi, memberikan arahan dan memfokuskan upaya. Setiap orang penting karena "sutradara" percaya bahwa hasil perangkat lunak dari kombinasi pandangan dunia dan kemampuan semua peserta dan cara unik kelompok melakukan pekerjaan bersama. Semua orang sejak awal mengakui pentingnya mendapatkan bintang untuk bergabung dengan kru - pemain bintang meningkatkan setiap peluang untuk sukses. Visi mendorong anggaran dan menarik dana.

Ketika datang ke kompensasi Widget Pabrik menganggap bahwa nilai paling banyak berasal dari pekerjaan yang dilakukan oleh manajer proyek dan analis bisnis yang berada di puncak hierarki dan harus diberi kompensasi yang sesuai, anggota tim lainnya tidak masalah asalkan mereka memiliki kualifikasi yang tepat untuk mengubah persyaratan menjadi kode kerja. PM dan BA bekerja keras untuk mempertahankan posisi mereka di atas paket dengan membatasi akses gratis ke sumber informasi proyek ke seluruh tim. Tanpa akses formal ke sumber info utama tim berjuang untuk membuat penilaian nilai apa pun atau menghasilkan solusi yang baik, pemrogram diturunkan untuk menerima pesanan dari atas dan mengerjakan masalah seperti yang didefinisikan oleh PM dan BA. Situasi ini semakin memperkuat gagasan Pabrik Widget) bahwa programmer mirip dengan pekerja lantai pabrik hanya mampu melakukan secara mekanis meskipun secara teknis rumit, tetapi tugas standar tetap.

Berbeda sekali, Kru Film bertindak sebagai formasi yang lebih egaliter; anggota diberikan akses tidak terbatas ke informasi primer, didorong untuk membentuk penilaian nilai dan bebas untuk memilih tindakan untuk memenuhi dan berkontribusi pada visi. Struktur kepemimpinan didasarkan pada kemampuan daripada peran khusus dalam tim. Kompensasi mencerminkan betapa diinginkannya mendapatkan orang tertentu untuk mengambil bagian dalam proyek, sering kali dikaitkan dengan persepsi tentang seberapa besar nilai hasil akhirnya jika orang tersebut dapat diyakinkan untuk mencurahkan energi mereka untuk menciptakan perangkat lunak tersebut. Dalam lingkungan ini peran seorang manajer proyek menjadi kurang menonjol karena ia tidak mungkin menjadi pemimpin kreatif; perannya turun sebagian besar ke dukungan administrasi dan hubungan eksternal. Tugas analis bisnis sebagian digantikan oleh peran Visionary (saya memanggilnya sebelumnya "direktur") dan sebagian diserap oleh anggota tim lainnya.

Sekarang, tidak mengherankan bahwa sebagian besar tim pengembangan perangkat lunak in-house dan beberapa konsultan dijalankan karena Pabrik Widget mengandalkan proses untuk menghasilkan perangkat lunak yang membosankan secara konsisten; lingkungan inilah di mana manajer proyek dan analis bisnis secara rutin dibayar lebih dari programmer berdasarkan pada asumsi bahwa mereka membawa nilai paling besar dengan lingkungan yang terstruktur sehingga mempersulit programmer untuk membuktikan kesalahan manajemen.

Perusahaan perangkat lunak yang sukses cenderung mengadopsi sudut pandang Kru Film, filosofi lain apa pun akan menghalangi kemampuan mereka untuk menarik orang-orang hebat yang sangat mereka andalkan untuk menghasilkan perangkat lunak yang hebat. Kecil kemungkinan Anda akan pernah melihat peran analis bisnis dalam pengaturan dan manajer proyek yang kurang menonjol dan secara rutin dibayar kurang dari programmer yang hebat.

389
Vlad Gudim

Karena dalam masyarakat kita, kita masih berpikir bahwa gajinya adalah terikat pada posisi dalam hierarki.

Analis atau manajer proyek lebih tinggi dalam hierarki, sehingga mereka harus dibayar lebih.

Izinkan saya menceritakan kisah nyata yang menggambarkan mengapa ini merupakan masalah.

Seorang teman baik mulai sebagai programmer di rumah sakit besar. Berkat kerja keras dan dedikasinya, ia dengan cepat menjadi Oracle DBA, yang merupakan posisi penting di perusahaan di mana data sensitif dan berharga.

Rumah sakit bekerja dengan level. Level terikat pada posisi Anda dalam hierarki, warisan, dan diploma.

Teman saya mendapat proposal untuk menjadi DBA di perusahaan lain yang tidak menggunakan tingkat gaji. Gajinya bisa meningkat banyak. Karena dia menyukai dan menghormati rumah sakit tempat dia bekerja, dia memutuskan untuk berbicara dengan bos, meminta kenaikan.

Bos menolak. Itu tidak mungkin karena level dan serikat tidak akan membiarkan itu terjadi.

Teman saya pergi.

Rumah sakit akhirnya menyewa konsultan eksternal (tidak terikat ke level) dan memposting pekerjaan di situs web mereka. Konsultan tidak tahu apa-apa tentang infrastruktur yang ada, jadi kurva belajarnya sangat besar. Rumah sakit kehilangan banyak uang karena itu.

Rumah sakit memang kehilangan lebih banyak. Konsultan eksternal dibayar sebanyak 5 kali dari yang diminta teman saya, dan mereka tidak dapat menemukan karyawan yang memenuhi syarat untuk menggantikannya.

Itu hampir tiga tahun lalu. Teman saya masih di tempat barunya dan memanjat tangga hierarki dengan sangat cepat melakukan apa yang dia sukai.

Rumah sakit masih membayar 5 kali lebih banyak.

IMHO, gaji harus relatif terhadap nilai yang Anda berikan kepada perusahaan.

PEMBARUAN : Ketika Anda bergerak lebih tinggi dalam hierarki, ada efek leverage yang terjadi. Jadi sebenarnya, Anda dibayar untuk nilai yang Anda bawa. Tetapi programmer brilian yang 10x lebih produktif harus dibayar 10x lebih banyak, terlepas dari posisi mereka dalam hierarki itu (biasanya di bagian paling bawah). Itulah yang ingin saya soroti.

276
user2567

Mereka mengambil lebih banyak risiko daripada yang dilakukan programmer. Mereka harus membuat keputusan berdasarkan informasi apa pun yang kami berikan kepada mereka, dan kemudian menghadapi kritik keras dari pemangku kepentingan ketika harapan mereka tidak terpenuhi. Bagian dari paket pembayaran mengimbangi risiko ini.

Faktor lain mungkin adalah pengalaman bertahun-tahun yang dibutuhkan untuk mempersiapkan manajer proyek yang dapat merencanakan, memperkirakan, dan memitigasi dengan baik. Dalam beberapa hal, manajer proyek yang bernuansa adalah dilatih melalui kegagalan, menjadikannya keterampilan yang mahal untuk diperoleh. Setelah mencapai tingkat senioritas, sebuah perusahaan mungkin tidak mau melepaskan personil yang berharga tersebut.

Edit:

Ada lebih banyak jenis risiko daripada kerugian finansial atau fisik. Misalnya, pertimbangkan risiko ditegur oleh manajer atau pelanggan. Meskipun tidak ada kerusakan yang sebenarnya dilakukan, masih cukup tidak diinginkan bahwa kita menyesuaikan perilaku kita untuk menghindari hasil seperti ini. Namun, manajer harus membuat keputusan yang baik setiap saat, dan harus menyeimbangkan berbagai jenis risiko untuk kepentingan perusahaan, tidak sesuai dengan preferensi pribadi.

84
rwong

Pemrograman mungkin lebih sulit dengan ukuran tertentu, tetapi juga lebih menyenangkan. Anda hanya duduk di sana dan memecahkan teka-teki pemrograman Nice sementara manajer menangani semua jenis omong kosong antara bawahan mereka, klien mereka, bos mereka sendiri dan para pemangku kepentingan. Itu sebabnya sangat sedikit orang waras yang benar-benar ingin menjadi manajer, jadi Anda harus mengimbanginya dengan membayar lebih.

Pemrograman lebih sulit, tetapi mengelola lebih buruk.

Salah satu cara untuk memikirkan apa nilai seseorang bagi perusahaan adalah dengan membayangkan seperti apa jadinya jika orang itu meninggalkan perusahaan. Biasanya manajer ternyata lebih berharga dalam hal itu daripada programmer. James Gosling , pencipta Java, baru-baru ini meninggalkan Oracle. Orang bisa berpikir itu kerugian besar, tapi coba tebak? Sebenarnya itu tidak masalah. Ini hampir tidak berpengaruh pada Java atau pada Oracle. Anjing menggonggong, tetapi karavan terus berjalan.

By the way, saya (serius) berpikir bahwa tukang debu dan pembersih harus dibayar lebih dari programmer. Membersihkan sampah orang lain adalah pekerjaan yang menyebalkan dan sangat diperlukan.

80
Joonas Pulakka

Mengurangi manajemen untuk membuat bagan dan menulis dokumentasi seperti mengatakan bahwa pemrograman sedang mengetik.

Untuk masing-masing mereka sendiri, tetapi bagi saya pemrograman jauh lebih mudah daripada mengelola orang.

71

Semua orang di sini fokus pada yang negatif. Saya belum pernah bertemu seorang programmer yang menyukai politik kantor dan manajer yang baik melindungi Anda dari sampah semacam itu. Setelah berinteraksi dengan banyak orang di klien utama kami, setengah dari mereka gila dan saya senang memiliki PM di sana untuk menyerap kegilaan bagi saya. Jika mereka membayar mereka banyak Tidak apa-apa, dia membutuhkannya untuk terapi yang tak terhindarkan.

36
MattC

Tentu saja ini bisa diperdebatkan, tetapi alasan signifikan di balik ini adalah mereka memikul tanggung jawab proyek jika gagal, bukan programmer. Mereka mungkin memberi Anda cukup banyak untuk menaikkan sesuatu, tapi mereka menghadapi kritik dari kekuatan yang lebih tinggi. Merekalah yang bertanggung jawab atas perencanaan dan estimasi.

Mengelola membutuhkan sangat keahlian multi-faceted: keterampilan orang, kepemimpinan, kemampuan untuk memperkirakan biaya dan waktu. Untuk melakukan semua ini mereka juga harus tetap berhubungan dengan sisi Anda dari hal-hal (yaitu memiliki beberapa petunjuk tentang apa yang Anda lakukan, berbicara secara teknis) atau menjadi juri karakter yang sangat baik.

Jika persyaratan tidak didefinisikan dengan benar, itu adalah kesalahan mereka.

Jika rencana pengujian tidak didefinisikan dengan benar, itu adalah kesalahan mereka.

Jika Anda pergi berlibur atau patah kaki atau terbuang sia-sia pada Sabtu malam atau pergi tanpa memberikan pemberitahuan yang cukup dan mereka harus mencari pengganti atau <beberapa alasan di sini> dan Anda tidak dapat melakukan pekerjaan Anda dan produk tidak mendapatkan dikirim (tepat waktu atau sama sekali), itu masih salah mereka.

Juga perhatikan bahwa ketika saya maksudkan, mereka memikul tanggung jawab, itu berdampak pada orang di atas dan di bawah mereka. Jika mereka mengacaukan segalanya, mungkin pekerjaan tim Anda yang ada di telepon. Itu juga jenis tekanan Anda dibayar.

PS: Plus, saya tidak tahu apakah saya akan mengatakan bahwa pemrograman lebih sulit daripada melakukan grafik Gantt (untuk menggunakan kembali contoh yang Anda sebutkan). Saya tidak tahu tentang Anda, tetapi saya menemukan pemrograman (secara umum, untuk 80% dari hal-hal yang perlu Anda lakukan di industri) cukup mudah. Jika Anda mengacaukan sesuatu, Anda dapat memperbaikinya. Jika bos Anda mengacaukan bagan gantt atau estimasi biayanya, sekarang itu akan menjadi masalah yang jauh lebih besar daripada membalikkan != null untuk sebuah == null. Kesalahan kecil penting dalam skala yang lebih luas bagi mereka. Sebagian besar waktu, tentu saja jika Anda mengacaukan tes seperti ini di aplikasi medis tertanam yang ditayangkan, itu juga masalah besar. Tetapi mereka akan mendapatkan lebih banyak masalah daripada Anda!

20
haylem

Penawaran dan permintaan adalah model ekonomi penentuan harga di pasar. Ini menyimpulkan bahwa dalam pasar yang kompetitif, harga satuan untuk barang tertentu akan bervariasi sampai ia menetap pada titik di mana jumlah yang diminta oleh konsumen (pada harga saat ini) akan sama dengan jumlah yang dipasok oleh produsen (pada harga saat ini), menghasilkan keseimbangan ekonomi harga dan kuantitas. Empat hukum dasar penawaran dan permintaan adalah:

  • Jika permintaan meningkat dan penawaran tetap tidak berubah maka harga dan kuantitas keseimbangan lebih tinggi.
  • Jika permintaan menurun dan penawaran tetap tidak berubah, maka turunkan harga dan kuantitas ekuilibrium.
  • Jika pasokan meningkat dan permintaan tetap tidak berubah maka harga keseimbangan lebih rendah dan kuantitas lebih tinggi.
  • Jika pasokan menurun dan permintaan tetap tidak berubah maka harga lebih tinggi dan kuantitas lebih rendah.

Dalam hal ini, salah satu alasannya adalah terlalu banyak pengembang.

19
Amir Rezaei

Saya telah bergeser di antara pengembang dan PM peran sepanjang karier saya. Saya memiliki pengembang di proyek saya yang menghasilkan dua kali lipat dari yang saya lakukan dan yang lainnya berpenghasilan setengah. Para penerima upah tinggi dibayar berapa mereka adalah karena: A) Mereka adalah pengembang "rockstar". B) Mereka berinteraksi dengan pelanggan, menjelaskan produk dengan cara yang mudah dimengerti oleh pelanggan, dan ramah. C) Mereka mengarahkan tim pengembang yang bekerja pada banyak proyek. D) Mereka selalu tersedia dan ingin menyenangkan.

Mereka melakukan peran sebagai pengembang, PM, dan BA dalam berbagai kapasitas. Secara umum, jika Anda menghabiskan 90% dari waktu Anda, memotong kode maka Anda tidak terlalu berharga dan kemungkinan mudah diganti. Jika Anda ingin menghasilkan lebih banyak uang maka Anda harus mengambil lebih banyak tanggung jawab ... dan mungkin harus mencari perusahaan lain yang akan membayar Anda lebih banyak.

17
Shane-o

Alasannya adalah bahwa area tanggung jawab manajer proyek (sering) adalah untuk mengantarkan seluruh proyek tepat waktu, dengan kualitas yang dapat diterima, dalam anggaran yang direncanakan. Seringkali ada banyak uang yang dipertaruhkan, jadi manajer proyek yang baik sering kali memiliki kompensasi yang lebih tinggi daripada programmer.

Namun saya tidak merasa bahwa analis bisnis, rata-rata, memperoleh gaji yang jauh lebih tinggi daripada programmer. Dan menurut perasaan saya, semakin tidak umum bahwa tingkat gaji dalam suatu perusahaan ditentukan oleh hierarki dan bukan oleh nilai seorang karyawan.

11
Nikita Barsukov

Pengalaman saya mungkin berbeda (atau saya hidup di alam semesta yang berbeda dengan hukum fisika yang terdistorsi), tetapi kebanyakan analis bisnis dan manajer proyek (tidak program manajer, tetapi proyek manajer atau PMP) posisi yang saya lihat berada pada atau sedikit di bawah gaji rata-rata programmer.

Kesenjangan gaji mulai melebar lebih banyak jika dibandingkan dengan gaji rata-rata insinyur perangkat lunak (atas dukungan insinyur perangkat lunak). Kesenjangan bahkan lebih jika dibandingkan dengan EE senior atau insinyur perangkat lunak senior. Hampir tidak ada analis bisnis senior atau PMP senior yang akan melakukan hal yang sama dengan EE senior atau insinyur perangkat lunak senior/utama.

Seorang manajer program, bagaimanapun (yang tidak sama dengan PMP), orang itu akan menghasilkan lebih banyak daripada orang lain (dan alasannya harus jelas.)


Hal yang paling mengganggu saya ketika saya melihat keluhan tentang gaji ini adalah sebagai programmer (khususnya programmer junior/entry level di perusahaan), kami (atau tidak) spesial. Tidak ada yang benar-benar ada dalam program entry level keluar dari sekolah yang layak mendapat gaji ilmuwan roket. Tidak.

Kita semua yang bekerja pada perangkat lunak mulai dari nol. Kita semua melakukannya.

Dan JIKA kami benar-benar jujur, kami tahu benar bahwa kami tidak tahu apa-apa. Mampu menyelesaikan beban program sarjana CS kami hanyalah titik awal. Itu tidak membuat kita istimewa atau ZOMG !!!! uber-Einstenian. Sungguh, TIDAK!

Namun (dan terima kasih kepada periode buruk dot-com bubble), kami berharap dapat membuat tidak hanya lebih banyak, tetapi lebih banyak dari orang berpendidikan universitas hanya karena OH WOW, kami adalah programmer dan mereka - hanya analis bisnis dan PMP.

Bisakah Anda mengeja kesombongan? Newsflash - untuk sebagian besar tugas pemrograman di perusahaan, Anda bahkan tidak memerlukan gelar 4 tahun. Sungguh, ini serius.

Luangkan waktu di Grind dan bangun pengalaman untuk transisi dari pemrograman ke rekayasa perangkat lunak (atau rekayasa dalam hal ini) di tingkat senior. Maka Anda dapat meminta untuk menghasilkan banyak, banyak, pero mucho mucho lebih dari sekadar analis bisnis dan PMP.

Selesaikan dengan - sebagian dari kita (atau) dibayar lebih tinggi. Titik.


Mengabaikan kata-kata: alasan analis bisnis dan/atau PMP menutup gaji atau mirip dengan programmer yang belum menambah waktu dan keahlian yang diperlukan untuk menjadi insinyur perangkat lunak menengah/senior (atau yang masih belum mengembangkan keahlian dalam ceruk yang sangat dituntut) daerah):

A analis bisnis adalah penghubung antara perangkat lunak dan sistem, orang-orang bisnis/proses bisnis (yang merupakan pembenaran atas keberadaan gaji Anda, bukan sebaliknya). Merekalah yang bertanggung jawab atas memecah proses bisnis secara metodis, perilaku analitis, sebagai input yang dapat diterima untuk membentuk persyaratan, hal-hal yang Anda kerjakan. Mereka memastikan bahwa Anda menghabiskan sebagian besar waktu pemrograman Anda dan tidak berurusan dengan hal-hal kecil dalam bisnis.

Banyak dari Anda berpikir bisnis itu mudah. Jika Anda benar-benar berpikir itu benar, Tuhan membantu Anda.

A manajer proyek adalah orang yang bertanggung jawab untuk menyulap beberapa proyek (sedangkan Anda hanya perlu menyulap satu atau dua paling banyak pada waktu tertentu). Dia adalah payung Anda, dan dialah yang harus lakukan pekerjaan kotor yang tidak ingin dilakukan sebagian besar massa yang belum dicuci - untuk mengejar orang-orang untuk memastikan mereka melakukan pekerjaan mereka atau menghilangkan halangan untuk pekerjaan Anda.

Dialah yang akan bertanya kepada Anda "apa yang sedang Anda kerjakan? Apa yang Anda kerjakan membantu memindahkan proyek? Apakah Anda memiliki masalah dengan pekerjaan Anda? Apa kendala Anda, apa yang Anda butuhkan? Siapa yang bisa memberikannya kepada Anda? "...

dan kemudian dia akan pergi ke orang lain mengajukan pertanyaan-pertanyaan sulit yang sama, memastikan bahwa rintangan dihilangkan, dan memastikan bahwa Anda menarik beban Anda pada proyek (jika perlu.)

Masalah nomor satu yang saya lihat di banyak proyek gagal adalah kurangnya PMPs atau rasa tidak hormat terhadap PMPs (khususnya dari pengembang.) Jarang saya melihat proyek gagal karena PMPs tidak kompeten, namun kita harus bertanya-tanya mengapa banyak programmer lebih dari ingin mengatakan it demikian.

10
luis.espinal

Saya di bidang keuangan, dan saya pikir mentalitasnya serupa di sebagian besar pakaian non-teknologi:

Pembayaran sebanding dengan risiko karier

Kecuali pemecatan total terhadap suatu kelompok atau tim, pemrogram tingkat rendah selalu mempertahankan pekerjaan mereka. Ini adalah sifat dari pekerjaan, dan programmer masuk dengan mengetahui sepenuhnya bahwa mereka mengambil risiko nol. Jika ada bug, itu bukan kepala mereka di blok memotong.

Pada level yang lebih tinggi, jika sesuatu kacau, Anda adalah orang pertama yang pergi. Saya punya banyak pengalaman dengan bawahan yang membuat kesalahan tipografi kecil yang menyebabkan kami kehilangan uang, dan saya mengambil panas untuk itu (bukan programmer sebenarnya yang membuat kesalahan).

Sederhananya, bayarannya sepadan dengan risikonya. Pemrogram, di sisi lain, tidak perlu memiliki kulit dalam permainan, sehingga untuk berbicara.

9
Foo Bah

Jika pertanyaan Anda adalah "mengapa X dan Y mendapatkan gaji lebih tinggi daripada programmer di perusahaan saya" Saya mungkin telah menjawab "Anda mungkin bekerja di perusahaan yang salah."

Keberhasilan suatu perusahaan dalam bisnis perangkat lunak lebih tergantung pada kemampuan pemrogramnya daripada orang lain. Perusahaan yang tidak mengenali hal ini secara otomatis berada pada posisi yang kurang menguntungkan vs perusahaan yang mendapatkannya. Mempekerjakan programmer terbaik dan merawat mereka dengan baik adalah taruhan terbaik Anda. Perbedaan dalam pekerjaan programmer besar vs yang lain sangat besar; jauh lebih besar dari perbedaan gaji yang mereka perintahkan. Tetapi jika Anda bersikeras membayar kurang programmer Anda, Anda akan mendapatkan apa yang Anda bayar.

Yang mengatakan, setiap peran lain dalam bisnis itu penting. Manajer besar memiliki dampak besar. Banyak dari itu adalah dengan mendapatkan programmer yang hebat dan membuat mereka senang. Hal serupa dapat dikatakan tentang analisis bisnis, pemasaran, penjualan, pengujian, dan dukungan.

Jika Anda seorang programmer yang hebat dan Anda tidak mendapatkan imbalan besar, pergi ke tempat lain. Kemudian lagi, Anda mungkin bukan programmer yang hebat. Sayangnya, jika Anda tidak hebat, sulit untuk melihat alasannya. Jika Anda tahu mengapa, Anda bisa berubah dan menjadi hebat, bukan?

Saya telah menjadi seorang programmer dan saya telah menjadi manajer orang. Saya bekerja dengan banyak programmer hebat, tetapi hanya beberapa manajer hebat. Ketika saya seorang manajer, saya tidak hebat, tetapi setidaknya saya tahu itu. Orang-orang saya mendapat kenaikan gaji lebih banyak daripada saya, yang mereka layak dapatkan.

5
Jay Bazuzi

Ini tidak ada hubungannya dengan keterampilan dan pekerjaan, maksud saya sedikit dalam perekonomian terkait dengan berapa banyak orang layak untuk membuat.

Layak untuk menghasilkan lebih banyak uang adalah ide singkat, semua orang percaya mereka pantas menghasilkan lebih banyak uang.

Meskipun mungkin tidak adil, manajer menghasilkan lebih banyak uang hanya karena pemilik bisnis lebih mempercayai mereka. Manajer sering mendapatkan gaji yang lebih tinggi, supaya mereka tidak mengambil pekerjaan baru secara tiba-tiba pada waktu yang tidak nyaman.

5
Mark Rogers

Saya telah memeriksa setiap pos, dan saya berani mengatakan bahwa kebanyakan dari mereka mencoba membandingkan apel dan pisang.

Pertama-tama, saya percaya bahwa seseorang yang mengatakan bahwa 'mengelola adalah sepotong kue' tidak pernah harus mengelola apa pun lebih dari jadwalnya sendiri. Di sisi lain, katakan bahwa 'siapa pun bisa kode apa pun' konyol (dan ada di forum yang salah, demi Tuhan!).

Saya secara khusus menyukai jawaban rwong dan luis.espinal, meskipun saya percaya ada fakta lain yang perlu diperhatikan juga.

Saya tidak percaya hierarki sebagai jawaban - tidak sekarang - meskipun cocok untuk 10.000 tahun terakhir. Kami hidup selama berabad-abad dalam masyarakat di mana semakin tinggi keuntungan Anda, semakin tinggi kekuatan Anda (dan sebaliknya). Saya tidak percaya itu berlaku untuk dunia kita, sebagaimana adanya (khususnya di wilayah kita).

Kembali ke pertanyaan utama, saya percaya bahwa manajer biasanya menghasilkan lebih banyak karena mereka lebih berharga bagi perusahaan bukan karena dia lebih tinggi dalam hierarki, tetapi dia lebih tinggi karena

  • semua pengetahuan yang telah dia kumpulkan dari pengalaman sebelumnya (biasanya programmer memiliki pengalaman lebih sedikit dari manajer pada umumnya)
  • untuk dapat mengelola beberapa hal sekaligus (programmer memiliki satu tugas - atau daftar tugas - untuk menyelesaikan, sementara manajer harus mengelola tugas mereka sendiri
  • mereka adalah kontak utama untuk proyek yang mereka kelola, dan karena alasan inilah mereka menjadi 'target' pertama jika terjadi kesalahan. Lebih mudah kehilangan pekerjaan Anda jika Anda seorang manajer; menjadi pengembang, Anda memiliki 'lisensi untuk mengulang sesuatu'. Itulah faktor 'risiko' yang disebutkan semua orang.
  • pengembang adalah bagian dari keseluruhan siklus hidup proyek. Saya percaya ketika kita berbicara di sini tentang 'programmer' kita juga memikirkan para penguji, penulis teknis dan semua orang lain yang sangat penting untuk keberhasilan proyek.
  • dan ada sesuatu yang saya lihat hanya dalam beberapa posting di topik ini: kepemimpinan. Menjadi seorang manajer adalah untuk mengetahui bagaimana berhubungan dengan orang lain, untuk bernegosiasi, untuk membuat semua orang termotivasi, untuk menciptakan sinergi ketika suasana hati semua orang turun.

Menurut pendapat saya, faktor kepemimpinan adalah alasan utama kenaikan gaji, karena menghasilkan hasil jangka panjang yang besar bagi perusahaan dan bagi semua orang yang ada di sekitar pemimpin.

BTW, saya hanya memiliki sedikit pengalaman sebagai pemimpin tim (jauh dari menjadi pemimpin proyek!) Dan sebanyak yang saya tahu apa yang dilakukan seorang pemimpin, sebanyak pekerjaan yang saya sadari harus saya lakukan.

Sunting: Lupa untuk menyoroti: keterampilan komunikasi bukan poin kuat bagi kebanyakan dari kita, tetapi merupakan keharusan bagi seorang pemimpin. Selain itu, saya ingin berbagi posting yang sangat bagus di Coding Horror, terkait dengan programmer yang baik dan keterampilan komunikasi -> http://www.codinghorror.com/blog/2011/02/how-to-write -without-writing.html

4
Tiago Cardoso

Dalam banyak profesi, keterampilan inti adalah kemampuan untuk menjual sesuatu. Dan untuk menjual sesuatu, Anda harus menjual diri Anda sendiri. Anda membutuhkan pembeli untuk mempercayai Anda dan menghargai produk atau layanan yang Anda berikan sebanyak yang Anda inginkan. Keahlian ini sepenuhnya dapat ditransfer ke negosiasi gaji.

4
back2dos

Saya pikir seluruh dasar Anda untuk pertanyaan ini cacat.

Manajemen harus dibayar lebih dari bawahannya. Senioritas dalam suatu perusahaan umumnya didasarkan pada gaji, dan tidak mungkin seorang karyawan junior dapat memiliki sarana untuk memerintah senior mereka.

Memimpin orang adalah keahlian khusus. Tidak semua orang bisa menjadi manajer proyek (PM). Tugas ini semakin sulit karena jumlah staf meningkat. Dalam peran teknis PM, PM perlu memiliki pemahaman yang baik tentang teknologi untuk memimpin secara efektif - atau mereka tidak akan memiliki rasa hormat dan dukungan dari mereka). bawahan.

4
TZHX

Pikirkan seperti ini, jumlah manajer terampil kurang dari jumlah programmer terampil, oleh karena itu manajer lebih "berharga" bagi perusahaan.

3
user16556

Itu tergantung bagaimana Anda mendefinisikan 'kesulitan'. Meskipun begitu, saya ingin tahu apakah Anda benar-benar tahu tentang Manajemen Proyek dan apa yang harus dilakukan oleh Analis Bisnis. Saya membaca banyak frustrasi dari pertanyaan Anda, jadi saya pikir Anda memiliki beberapa pengalaman buruk. Meskipun demikian, saya ingin mencoba menjawab pertanyaan Anda.

Manajer Proyek dan Analis Bisnis biasanya 'lebih tua' ketika mereka memenuhi posisi tersebut. Di mana pengembang memulai karir mereka sangat muda (sekitar 20-an), sebagian besar manajer proyek dan analis berada di dekat usia 30 (yang sudah membuat perbedaan dalam pembayaran hanya berdasarkan usia saja). Mereka juga orang-orang yang menghadapi paparan pelanggan, yang berarti mereka harus melakukan perjalanan di tempat, menghabiskan berjam-jam penyiksaan untuk mendengarkan pelanggan (terutama ketika sebuah proyek salah jalan) dan meminta keinginan/kebutuhan mereka. Mereka harus berhati-hati dengan apa yang mereka janjikan dan terutama dalam lingkup apa (waktu-untuk-memberikan). Meskipun dari sudut pandang Anda bahwa apa yang mereka lakukan hanya mendokumentasikan, analis bisnis dididik untuk menganalisis kebutuhan bisnis, dan manajer proyek menjaga perencanaan proyek.

Mereka bertindak sebagai firewall antara pelanggan dan pengembang. Perspektif teknis adalah sesuatu yang berbeda dari perspektif penjualan. Sebagian besar analis bisnis dan manajer proyek juga menghadapi berbagai macam pelanggan - mereka terbuka dan karenanya memiliki 'petunjuk'. Jaringan mereka terdiri dari para pembuat keputusan dan karenanya perusahaan lebih memilih untuk menjaga orang-orang dengan jangkauan jaringan tersebut; setelah semua penjualan adalah penjualan.

Mengenai kesulitannya? Mulai sebuah perusahaan, miliki sepuluh pengembang dan coba kelola sebuah proyek. Sakit kepala datang dengan itu gratis. Lakukan ini selama satu tahun dan kemudian lihat kembali jawaban Anda. Untuk BA? Pergi untuk kesempatan seperti itu. Duduk bersama pelanggan yang memiliki mesin AIX dari 1974 dan perancang sistem itu mati/pensiun/sekarat/alzeheiming dan pengembang perlu tahu apakah nilai tertentu dihasilkan atau memiliki beberapa formula mistik. Cobalah meyakinkan 20 orang dengan PowerPoint tentang solusi Anda dalam waktu 3 hari. Jika mendokumentasikan itu semudah itu, Linux pasti sudah menguasai dunia pada tahun 1997. Sungguh, cobalah menulis kertas putih teknis setiap bulan untuk orang-orang non-teknis (orang-orang yang berpikir bahwa Facebook adalah revolusi dalam komputasi).

Saya seorang insinyur penjualan. Yang berarti, saya mengembangkan tetapi spesialisasi saya adalah untuk prototipe dan demonstrasi. Dan saya mendapat lebih dari analis bisnis atau manajer proyek. Bukan karena saya memiliki jaringan (saya punya jaringan), tetapi karena saya meninggalkan sikap dan lebih fokus pada perspektif bisnis, membuat saya disertifikasi dan mengajari diri saya beberapa soft skill. Dan pengalaman belajar bahwa 'tidak' juga merupakan jawaban, ketika tiba saatnya lembur.

3
Shyam

Jawaban sederhana: Mereka lebih berharga bagi perusahaan daripada programmer.

Mengapa? Karena mereka memastikan bahwa proyek diselesaikan, bahkan jika mereka tidak melakukan pemrograman sendiri. Itu berarti nilai mereka (murni dalam hal moneter untuk perusahaan) lebih dari seorang programmer. Perusahaan tidak percaya bahwa programmer yang tidak terkelola itu produktif, dan karenanya berharga ... Hanya manajer yang membuatnya.

Menyebalkan, dan kita mungkin tidak menyukainya, tetapi itu sebabnya perusahaan membayar mereka lebih banyak.

Posisi mereka (seperti yang telah ditunjukkan orang lain) datang dengan kelemahan, meskipun: Jika mereka gagal menyelesaikan proyek pada waktu tertentu, itu kesalahan mereka, bukan programmer. Mereka memikul lebih banyak tanggung jawab, dan sangat kemungkinan akan dipecat karena gagal (kecuali jika ada beberapa nepotisme perusahaan BS yang terjadi).

Jadi, sungguh, mereka tidak diizinkan untuk melakukan kesalahan, memiliki lebih banyak tekanan pada mereka, dan memiliki pekerjaan yang jauh lebih tidak stabil ... tapi jangan bingung: Ini bukan mengapa mereka dibayar lebih - sebuah perusahaan tidak peduli seberapa besar tekanan yang Anda hadapi, seberapa volatile posisi Anda, hal-hal seperti itu. Mereka hanya peduli nilai apa yang Anda bawa ke perusahaan. Titik.

Itu kapitalisme, kawan.

3
Django Reinhardt

Saya tidak tahu berapa kali pengetahuan Gantt Chart perlu diperbarui dalam setahun. Tetapi melakukan pemrograman Anda perlu memperbarui diri dengan teknologi baru yang tidak akan semudah usia Anda.

Mempelajari teknologi baru membutuhkan berjam-jam keringat, jika Anda cukup pintar untuk menyerap.

Keterampilan yang diperoleh selama bertahun-tahun melakukan pemrograman tidak banyak dihargai dalam budaya perusahaan saat ini.

Membandingkan gaji programmer yang baru lulus dengan satu dengan lebih dari 10 tahun pengalaman adalah kisah yang agak menyedihkan.

Membandingkan PM dengan 10 tahun PM adalah kisah yang hebat, PM mungkin menjadi Direktur setelah 10 tahun pengalaman.

Jadi mengapa masih banyak orang yang ingin belajar IT di universitas? Saya tidak mengerti. Apakah mereka mendapat informasi yang benar?

Saya tidak mengerti bagaimana orang menghargai keterampilan saat ini.

2
user16507

Manajemen tidak selalu menghasilkan lebih dari staf teknik. Staf teknik tingkat senior harus dilibatkan secara aktif dengan analisis dan pengambilan keputusan tingkat bisnis dan membuat bagan peta jalan teknis untuk perusahaan. Ketika hal ini terjadi, staf teknis senior dapat menghasilkan sedikit lebih banyak daripada manajer bisnis yang bekerja bersama mereka setiap hari.

Salah satu mitos bisnis yang populer adalah bahwa manajer harus dibayar lebih dari orang yang dia kelola. IMO, Anda menemukan gagasan ini lebih tertanam dalam di buracracies daripada di tim fungsional, tangkas.

Dengan kata lain: kompensasi seharusnya mencerminkan nilai kontribusi seseorang kepada perusahaan. Ada manajer bisnis bintang dan manajer rata-rata, dan ada insinyur bintang dan insinyur rata-rata. Jika Anda memiliki insinyur bintang yang menghasilkan teknologi menghasilkan uang dan memiliki pengetahuan mendalam tentang teknologi perusahaan, bukankah itu demi kepentingan terbaik perusahaan untuk memberikan kompensasi kepada orang ini secara lebih agresif daripada manajer bisnis biasa yang kebetulan mengelola insinyur bintang ini? Berapa biaya peluang untuk kehilangan keahlian dan ketrampilan rekayasa itu karena Anda mengabaikan sumber daya yang berharga ini?

2
dthorpe

Saya memulai satu bulan lalu dengan proyek pertama saya sebagai PM. Sebelum saya bekerja sebagai programmer. (Ngomong-ngomong, saya mendapatkan uang yang sama seperti sebelumnya.)

Saya menemukan bahwa menjadi seorang yang baik PM berarti menjadi seorang programmer yang baik dengan pengalaman yang luas. Anda harus dapat berpindah dari satu anggota tim ke anggota yang lain dan mendiskusikan masalah yang mereka miliki dengan menggunakan pengalaman praktis Anda untuk bantu mereka untuk memahami masalah dengan memberikan sudut pandang yang berbeda. Tugas Anda adalah, selain yang lain, untuk mengelola antarmuka. A PM seperti konduktor. Anda dapat memiliki musisi terbaik tetapi jika Anda tidak memiliki konduktor yang baik yang tahu cara memainkan orkestra meta-instrument dengan baik, Anda hanya mendapatkan kekacauan.

Mitra adalah spesialis. Ini adalah programmer yang mampu memecahkan masalah yang sulit karena ia memiliki pengetahuan yang mendalam tentang domain masalah. Orang-orang yang berpengalaman ini sering juga dibayar tinggi jika mereka cukup baik dalam negosiasi. Sayangnya spesialis sering kutu buku dan tidak begitu tertarik pada uang atau bagus dalam membuat kesepakatan yang baik ...

2
user16673

Untuk alasan yang sama persis yang dapat dibuat oleh seorang CEO 263 kali sebanyak rata-rata pekerja mereka.

2
Jeff Swensen

Ini tidak selalu terjadi. Ketika saya bekerja untuk Computer Sciences Corporation (CSC), sebagian besar manajer menghasilkan kurang dari "orang yang menghasilkan sesuatu yang bermanfaat". Dalam kasus CSC, saya pikir inilah masalahnya karena perusahaan telah dimulai oleh sekelompok programmer.

Pada waktu itu (1970) ada perusahaan perangkat lunak lain di LA yang namanya saya lupa dengan jadwal gaji yang menarik. Programmer dibayar $ 25.000/tahun dan staf pendukung dibayar $ 15.000/tahun. Idenya adalah bahwa jika Anda adalah programmer yang lebih buruk di sana Anda tidak perlu terkejut untuk diganti.

1
user16762

Saya memiliki perusahaan perangkat lunak kecil saya sendiri dan saya adalah programmer dan manajer proyek, jadi saya bisa memberikan Anda kedua sudut pandang.

Asumsi awal Anda tidak benar. Biarkan saya menuliskannya:

Manajemen Proyek & Analisis Perangkat Lunak =

Membuat dokumentasi atau bahkan membuat bagan Gantt dan menanyakan perkembangan kepada programmer.

Jika Anda benar-benar mengira hanya Manajemen Proyek dan Analisis Perangkat Lunak, tidak heran Anda berpikir bahwa pemrograman lebih sulit.

Tapi itu cara yang humoris, tidak adil dan tidak realistis untuk mendefinisikan profesi itu. Ini berkonsentrasi hanya pada aspek visual, seolah-olah mereka tidak memberi nilai.

Bagaimana perasaan Anda tentang definisi lain ini?

Pemrograman =

Duduk di depan komputer dan meninju kunci.

Jika pemrograman didefinisikan seperti itu, PM & SA terlihat jauh lebih sulit, bahkan oleh definisi Anda (yang tidak benar).

Profesi-profesi itu dibayar lebih baik karena, memang, lebih sulit daripada pemrograman.

  1. Mereka melibatkan berurusan dengan orang , bukan mesin. Orang-orang jauh lebih sulit untuk diajak bekerja sama, mengingat sifat mereka yang tidak deterministik. Subset yang disebut klien secara khusus merepotkan.
  2. Orang lain mengatakannya, tetapi saya ulangi: tanggung jawab. Jika seorang programmer gagal, itu tergantung pada PM untuk menyelesaikan masalah. Tidak hanya melaporkannya, untuk memecahkan mungkin melibatkan penundaan peluncuran selama 2 minggu atau melewatkan satu fitur.
  3. Jumlah multi-tasking satu PM harus dilakukan biasanya mengejutkan. Ini adalah latihan yang konstan dalam keseimbangan antara tim, manajemen, klien, dan anggaran. Ini adalah tidak mudah.
  4. Ini juga melibatkan komunikasi "sebaliknya" - Tidak hanya programmer harus melapor ke PM pada status; the PM bertanggung jawab untuk berkomunikasi dengan benar harapan, risiko, dan tujuan, jika beberapa kasus mereka juga bertanggung jawab atas pelatihan.
  5. Sudahkah saya menyebutkan berurusan dengan klien?

Jika manajer proyek yang bekerja dengan Anda hanya melakukan powerpoint, mereka tidak melakukan pekerjaan mereka dengan benar. Dan itu menyedihkan.

Saya pikir Anda tidak akan benar-benar mengerti mengapa manajer proyek mendapatkan lebih dari programmer sampai Anda bertemu manajer proyek yang baik.

1
egarcia

Baiklah saya sedikit terkejut dengan jawabannya, jadi begini saja. Tetapi sebelum itu, saya hanya ingin mengklarifikasi bahwa saya seorang Programmer dan tidak ada yang lebih saya sukai dari pada Programming. Yang mengatakan saya memiliki rasa hormat yang sehat dan menghormati kompeten PM dan BAs. Saya menyadari bahwa banyak dari kita membenci PM dan BA karena tidak seperti pemrograman itu mungkin untuk Excel di dalamnya tanpa diperlukan tingkat kompetensi (politik kantor, pakaian bagus, dll).

Namun baik Manajemen Proyek dan Analisis Bisnis adalah komponen penting dari pengembangan perangkat lunak.

Setiap kali kita memikirkan pengembangan perangkat lunak, banyak dari kita memiliki kecenderungan untuk fokus hanya pada pemrograman untuk mengesampingkan segala sesuatu yang lain. Namun ada lebih dari itu daripada coding.

Tujuan pertama pengembangan, yaitu menciptakan perangkat lunak yang benar-benar mengatasi dan memecahkan masalah pelanggan. Ini menyiratkan pertama benar-benar mencari tahu kebutuhan pelanggan (karena pelanggan mungkin tidak benar-benar yakin apa yang dia inginkan), ini hanya mungkin dengan analisis rinci dari domain di mana pelanggan beroperasi dan struktur berbagai artefak (apakah itu orang, infrastruktur teknis atau proses), dan kemudian mengembangkan solusi bisnis yang sesuai (dan integrasinya dengan teknologi) untuk memenuhi persyaratan tersebut.

Demikian pula setiap proyek dengan ukuran signifikan benar-benar tidak dapat bekerja tanpa manajemen yang efektif. Sekarang saya tidak tahu bagaimana keadaannya di tempat lain, tetapi sejauh ini pengalaman saya adalah bahwa PMs biasanya dipromosikan dari jajaran pemrogram, sehingga mereka memiliki beberapa gagasan tentang apa yang diperlukan untuk mengatur dan melaksanakan proyek.

Untuk meringkas BAs dan PM adalah lapisan abstraksi untuk pengembangan .

1
Gaurav

Programmer tidak menempatkan gaji sebagai prioritas tertinggi (Anggap saja pada tingkat yang masuk akal.). Bayangkan dua tawaran pekerjaan di mana seseorang memiliki gaji yang lebih tinggi, komitmen waktu yang sama, tetapi membutuhkan dukungan teknis, jam kerja yang ketat, kode berpakaian, menulis dokumentasi pengguna, berurusan dengan kode warisan dalam bahasa kuno yang Anda harap tidak akan pernah Anda gunakan lagi, bagaimana lebih banyak gaji yang akan Anda butuhkan?

1
JeffO

Jika Anda bekerja untuk perusahaan yang menghargai pemrograman, matematika, pemecahan masalah, keterampilan apa pun, maka Anda dapat memperoleh lebih banyak untuk dua hal:

  • Melakukan pekerjaan yang lebih sulit
  • Mengambil lebih banyak tanggung jawab

Hanya karena Rumah Sakit tidak banyak membayar DBA terampil mereka (lihat contoh di jawaban pertama) tidak berarti bahwa ini sama di setiap perusahaan.

1
Nils

Banyak orang mengatakan di sini, bahwa pemrograman lebih sulit dan itulah sebabnya ia harus mendapatkan lebih banyak. Itu pemandangan yang sangat romantis. Yang benar adalah, bahwa dalam perusahaan normal dan sehat pembayaran sesuai dengan tanggung jawab, itu berarti nilai tambah orang itu dan juga risiko).

Risiko akan sering dilupakan. Biasanya jika programmer gagal dalam pekerjaannya yang sulit, mungkin ada beberapa peningkatan biaya, tetapi tidak lebih. Tidak seperti 10% dari pekerja akan kehilangan pekerjaan mereka atau semacamnya. Risikonya cukup rendah.

Saya juga tidak setuju dengan ide itu, bahwa kebanyakan pebisnis mendapat lebih banyak uang. Saya yakin orang bisnis normal berpenghasilan kurang dari kebanyakan Sarjana Ilmu/Teknik akan mendapatkan. Sebagai contoh sebagai coder liburan sarjana saya mendapatkan hampir sama dengan beberapa waktu penuh barang bisnis pekerja di perusahaan yang sama.

Dan yang tak kalah pentingnya, mengapa manajer proyek bukan seorang insinyur? Biasanya manajer proyek adalah seorang pria dengan bertahun-tahun di depan dalam topik proyek yang ia kelola, artinya dalam pemrograman pekerjaan itu akan menjadi programmer berpengalaman yang adalah manajer proyek.

1
erikbwork

Ada lingkungan perusahaan tempat pola perintah dan kontrol atau hub- dan-berbicara pola komunikasi mendominasi. Dalam organisasi-organisasi ini, manajer dan kepala komunikator seringkali orang yang sama. Ini membuat manajer satu titik kegagalan - efek buruk dari miskomunikasi atau terjemahan yang hilang diperbesar. Karenanya lingkungan ini membutuhkan orang-orang dengan latar belakang teknis yang luas sebagai manajer untuk memastikan akurasi.

Tim yang lebih terorganisir biasanya menunjuk ketua komunikator untuk melepaskan tanggung jawab ini. Organisasi yang berlatih manajemen pengetahuan tidak memiliki satu titik pun kegagalan dalam komunikasi. Dalam organisasi-organisasi ini, para manajer dan ketua komunikator meminta informasi dan memfasilitasi diskusi. Informasi ini akan ditangkap dan diproses untuk dibagikan secara internal. Dibutuhkan serangkaian keterampilan sosial yang berbeda.

Demikian juga, analis bisnis seringkali merupakan satu-satunya titik kontak antara pelanggan dan staf teknis perusahaan.

1
rwong

Anda pikir bahasa/kompiler Anda rewel? Manajer berurusan dengan kompiler state-sadar diri yang disebut pemrogram, dan manajer yang baik bahkan membuat mereka untuk memproduksi perangkat lunak.

Serius, saya suka jawaban widget pabrik vs sekolah film, yang menurut saya mungkin merupakan jawaban terbaik, tetapi ada diskusi tingkat meta yang tidak benar-benar diatasi: tidak peduli organisasi apa yang Anda bangun, Anda sedang membangun organisasi dari bahan yang berubah-ubah seperti orang, dan itu pekerjaan yang sering sulit dilakukan dengan baik. Anda dapat membuat argumen yang kuat bahwa ini aneh bahwa posisi sering membayar lebih baik daripada programmer ketika sejumlah besar analis dan PM dan PHB sebenarnya tidak melakukan pekerjaan dengan baik, tetapi kenyataannya adalah bahwa ada adalah pekerjaan di luar sana yang melibatkan pembangunan organisasi yang menyelesaikan sesuatu, dan itu adalah keahlian yang lebih sulit dikuasai daripada membangun sistem perangkat lunak yang menyelesaikan pekerjaan.

0
Weston C

Analis Bisnis dan Manajer Proyek memiliki lebih banyak akses ke manajer di rantai. Itulah alasan utama mengapa mereka dapat dibayar lebih. Tidak semuanya. Ada juga organisasi yang membayar sangat buruk untuk analis bisnis tetapi mereka berisiko tingkat kegagalan yang sangat tinggi karena bentuk bug yang paling mahal - bug persyaratan.

Programmer yang menunjukkan kapasitas untuk secara efektif mengumpulkan persyaratan bisnis dan atau mengelola proyek, dibayar lebih dari ketiga pilihan yang telah Anda daftarkan. Penting untuk diingat bahwa layanan teknis melayani kebutuhan bisnis di sebagian besar organisasi dan orang cenderung mempercayai dan menghargai orang yang mereka pahami memahami kebutuhan mereka.

0
user16805

Mengelola orang lebih sulit daripada mengelola kode. Dan manajer yang baik memiliki kemampuan unik untuk menemukan programmer yang baik.

0
Halil Özgür

secara umum manajer proyek harus melihat gambaran umum sementara programmer hanya melakukan tugas spesifik mereka sendiri,

anda dapat menjalankan bisnis web yang sukses dengan programmer rata-rata tetapi jarang dengan manajer rata-rata

jika Anda seorang manajer yang perlu Anda lakukan matematika keuangan, Anda perlu bekerja pada masalah personel dan masalah kepercayaan, katakanlah dalam masalah perekrutan dll.

0
user16727