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

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 yang lebih tinggi daripada programmer? Apa yang membuat pekerjaan mereka menjadi pekerjaan bergaji tinggi padahal programmer paling sering pulang terlambat?

MEMPERBARUI

Maafkan ketidaktahuan saya, dari beberapa tanggapan tampaknya alasan mengapa BAs dan PMs mendapatkan 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 tetap tidak masuk akal.

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

Jawaban sederhana untuk pertanyaan ini adalah "karena dalam masyarakat kita, kita masih berpikir bahwa gaji terikat pada posisi dalam hierarki." Tetapi jawaban ini sambil 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 sebagai struktur pilihan untuk tim proyek perangkat lunak. Ini adalah dua pertanyaan yang tampaknya sangat layak ditanyakan.

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

Widget Widget lahir dari sekolah manajemen pemikiran yang berputar di sekitar motivasi. Teori X diusulkan oleh McGregor: karyawan peringkat malas dan membutuhkan kontrol dan pengawasan konstan, pekerjaan diadakan atas nama cek gaji, manajer selalu mampu melakukan bawahan mereka ' pekerjaan 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 sumber daya. Pekerjaan didorong oleh anggaran yang sudah diatur sebelumnya berdasarkan pada 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 citra 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 McGregor Teori 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 mengakui sejak awal pentingnya mendapatkan bintang untuk bergabung dengan kru - pemain bintang meningkatkan setiap peluang untuk sukses. Visi mendorong anggaran dan menarik dana.

Ketika datang ke kompensasiWidget Factories menganggap bahwa sebagian besar nilai 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 selama mereka masih ' Saya telah mendapatkan 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-sumber info utama tim berjuang untuk membuat penilaian nilai apa pun atau memberikan solusi yang baik, para programmer diturunkan untuk menerima pesanan dari atas dan mengerjakan masalah yang ditentukan oleh PM dan BA.

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.

Sekarang, tidak akan mengherankan bahwa sebagian besar tim pengembangan perangkat lunak di-rumah 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 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. Tidak mungkin Anda akan pernah melihat peran analis bisnis dalam pengaturan itu dan manajer proyek kurang menonjol dan secara rutin dibayar kurang dari programmer yang hebat.

Karena dalam masyarakat kita, kita masih berpikir bahwa gaji 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 sebuah rumah sakit besar. Berkat kerja keras dan dedikasinya, ia dengan cepat menjadi Oracle DBA, yang merupakan posisi penting di sebuah 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 .

UPDATE : 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.

Mereka mengambil lebih banyak risiko daripada 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 diperlukan untuk mempersiapkan manajer proyek yang dapat merencanakan, memperkirakan, dan memitigasi dengan baik. Dalam beberapa hal, seorang manajer proyek yang bernuansa dilatih melalui kegagalan, menjadikannya keterampilan yang mahal untuk diperoleh . Begitu mencapai tingkat senioritas, sebuah perusahaan mungkin tidak mau melepaskan personil yang begitu berharga.

Sunting:

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.

Pemrograman mungkin lebih sulit dengan ukuran tertentu, tetapi juga lebih menyenangkan. Anda hanya duduk di sana dan memecahkan teka-teki pemrograman yang bagus sementara para 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 banyak menyebalkan.

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 memiliki efek pada Java atau Oracle. Anjing menggonggong, tetapi karavannya berlanjut.

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.

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.

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 saya di sana untuk menyerap kegilaan bagi saya. Jika mereka membayar banyak, itu tidak masalah. Ia membutuhkannya untuk terapi yang tak terhindarkan.

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

Mengelola membutuhkan keterampilan yang sangat beragam : keterampilan orang, kepemimpinan, kemampuan 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, secara teknis) atau menjadi penilai 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 kesalahan 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 semacam tekanan yang Anda terima.

PS: Plus, saya tidak tahu apakah saya akan mengatakan bahwa pemrograman lebih sulit daripada melakukan bagan 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 != nulluntuk a == 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!

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 harga dan kuantitas keseimbangan lebih rendah.
• 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.

Saya telah bergeser antara peran pengembang dan PM sepanjang karier saya. Saya memiliki pengembang di proyek saya membuat dua kali lebih banyak daripada yang saya lakukan dan orang lain yang membuat setengah. Mereka yang berpenghasilan tinggi dibayar apa adanya karena: A) Mereka adalah pengembang "rockstar". B) Mereka berinteraksi dengan pelanggan, menjelaskan produk dengan cara yang mudah dipahami pelanggan, dan ramah. C) Mereka mengarahkan tim pengembang yang bekerja pada banyak proyek. D) Mereka selalu tersedia dan ingin menyenangkan.

Mereka melakukan peran pengembang, PM, dan BA dalam berbagai kapasitas. Secara umum, jika Anda menghabiskan 90% dari waktu Anda menekan, 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.

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, mendapatkan 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.

Pengalaman saya mungkin berbeda (atau saya hidup di alam semesta yang berbeda dengan hukum fisika yang terdistorsi), tetapi sebagian besar analis bisnis dan manajer proyek (bukan manajer program , tetapi manajer proyek 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.

Namun, seorang manajer program (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 ada .

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

Dan JIKA kita benar-benar jujur, kita tahu benar bahwa kita 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 untuk membuat tidak hanya lebih, tetapi lebih banyak dari orang berpendidikan universitas hanya karena OH WOW, kami adalah programmer dan mereka hanya bisnis analis 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 untuk membangun dan membangun pengalaman untuk transisi dari pemrograman ke rekayasa perangkat lunak (atau teknik dalam hal ini) di tingkat senior. Kemudian Anda dapat menuntut untuk membuat banyak, banyak, pero mucho mucho lebih dari seorang analis bisnis dan PMP.

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

Mengesampingkan kata-kata: alasan analis bisnis dan / atau PMP membuat gaji dekat 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):

Seorang analis bisnis adalah penghubung antara perangkat lunak dan sistem, orang-orang bisnis / proses bisnis (yang merupakan pembenaran atas keberadaan gaji Anda, bukan sebaliknya). Mereka adalah orang-orang yang bertanggung jawab untuk 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.

Seorang 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 melakukan pekerjaan kotor sebagian besar sisa massa yang tidak dicuci tidak ingin melakukan - mengejar orang untuk memastikan mereka melakukan pekerjaan mereka atau menghilangkan hambatan untuk pekerjaan Anda.

Dialah yang akan bertanya kepada Anda "apa yang sedang Anda kerjakan? Apa yang Anda kerjakan untuk 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 hambatan 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 bersemangat untuk mengatakan itu yang terjadi.

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

Gaji sebanding dengan risiko karier

Kecuali pemecatan total terhadap suatu kelompok atau tim, programmer 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.

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

Keberhasilan sebuah perusahaan dalam bisnis perangkat lunak lebih tergantung pada kemampuan pemrogramnya daripada orang lain. Perusahaan yang tidak mengenali 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.

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

Layak untuk menghasilkan lebih banyak uang adalah gagasan singkat, semua orang percaya bahwa mereka layak mendapatkan 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, hanya agar mereka tidak mengambil pekerjaan baru secara tiba-tiba pada waktu yang tidak nyaman.

Saya pikir seluruh dasar Anda untuk pertanyaan ini cacat.

Manajemen harus dibayar lebih dari bawahannya. Senioritas dalam sebuah 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 PM teknis, PM perlu memiliki pemahaman yang baik tentang teknologi untuk memimpin secara efektif - atau mereka tidak akan memiliki rasa hormat dan dukungan dari bawahan mereka.

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 benar-benar dapat ditransfer ke negosiasi gaji.

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 penjawab 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 ia kumpulkan dari pengalaman sebelumnya (biasanya programmer memiliki lebih sedikit pengalaman daripada 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; sebagai pengembang, Anda memiliki 'lisensi untuk mengulang sesuatu'. Itulah faktor 'risiko' yang disebutkan semua orang.
• pengembang adalah bagian dari seluruh 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 untuk gaji yang lebih tinggi, karena itu menghasilkan hasil jangka panjang yang sangat 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 baik di Coding Horror, terkait dengan programmer yang baik dan keterampilan komunikasi -> http://www.codinghorror.com/blog/2011/02/how-to-write-without-writing .html

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

Itu tergantung bagaimana Anda mendefinisikan 'kesulitan'. Meskipun begitu, saya bertanya-tanya apakah Anda 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 sejak masih sangat muda (sekitar 20-an), sebagian besar manajer proyek dan analis sudah mendekati 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 beragam pelanggan - mereka terbuka dan karenanya memiliki 'petunjuk'. Jaringan mereka terdiri dari para pembuat keputusan dan karenanya perusahaan lebih memilih untuk membuat orang-orang dengan jaringan seperti itu dalam jangkauan; 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 menghasilkan lebih dari analis bisnis atau manajer proyek. Bukan karena saya memiliki jaringan (saya punya,), 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.

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 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 mungkin 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 ... tetapi jangan bingung: Ini bukan alasan mereka dibayar lebih tinggi - sebuah perusahaan tidak peduli berapa banyak tekanan yang Anda hadapi, seberapa volatile posisi Anda, seperti itu. Mereka hanya peduli nilai apa yang Anda bawa ke perusahaan. Titik.

Itu kapitalisme, kawan.

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.

Keahlian 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 baru dengan PM 10 tahun adalah kisah yang hebat, PM tersebut dapat 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.

Untuk alasan yang sama persis bahwa CEO dapat menghasilkan 263 kali lipat dari rata-rata pekerja mereka.

Manajemen tidak selalu menghasilkan lebih dari staf teknik. Staf teknik tingkat senior harus dilibatkan secara aktif dengan analisis dan pengambilan keputusan di tingkat bisnis dan memetakan 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?

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 PM yang baik berarti menjadi programmer yang baik dengan pengalaman yang luas. Anda harus dapat beralih dari satu anggota tim ke anggota tim lainnya dan mendiskusikan masalah yang mereka miliki menggunakan pengalaman praktis Anda untuk membantu mereka memahami masalah dengan memberikan sudut pandang yang berbeda. Tugas Anda adalah, selain yang lain, untuk mengelola antarmuka. 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 akan 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 ...

Programmer tidak menempatkan gaji sebagai prioritas tertinggi (Dengan asumsi itu 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?

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.

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 dan hormat yang sehat untuk PM dan BA yang kompeten . Saya menyadari bahwa banyak dari kita membenci PM dan BA karena tidak seperti pemrograman adalah mungkin untuk unggul di dalamnya tanpa tingkat kompetensi yang disyaratkan (politik kantor, pakaian bagus dll).

Namun baik Manajemen Proyek dan Analisis Bisnis merupakan 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 menyelesaikan 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 sama sekali 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 baik BAs dan PMs adalah lapisan abstraksi untuk pengembangan .

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 di perusahaan normal dan sehat pembayarannya sesuai dengan tanggung jawab , itu berarti nilai tambah orang tersebut dan juga risikonya .

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 sesuatu seperti itu. Risikonya cukup rendah.

Saya juga tidak setuju dengan ide itu, bahwa kebanyakan pebisnis mendapatkan lebih banyak. 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 pekerja barang bisnis penuh waktu 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.

Ada lingkungan perusahaan di mana baik pola perintah dan kontrol atau pola komunikasi hub-and-spoke mendominasi. Dalam organisasi-organisasi ini, manajer dan kepala komunikator seringkali orang yang sama. Hal ini membuat manajer menjadi 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 mempraktikkan 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.

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 saat 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.