Чому бізнес-аналітики та керівники проектів отримують більші зарплати, ніж програмісти? [зачинено]


324

Треба визнати, що програмування набагато складніше, ніж створення документації або навіть створення діаграми Ганта і прохання прогресу програмістів. Тож для нас, хто є наївами, знаючи, що програмування взагалі складніше, чому бізнес-аналітики та керівники проектів отримують більшу зарплату, ніж програмісти? Що це робить їх роботу високооплачуваною роботою, коли навіть у більшості випадків програмісти ті, хто пізно йдуть додому?

ОНОВЛЕННЯ

Вибачте з мого невігластва, з деяких відповідей здається, що причина, чому керівники та прем'єр-міністри отримують більшу зарплату, тому що вони, як правило, відповідають за безладдя. Але врешті-решт, програмісти забруднюють руки, щоб виправити безлад і працювати більше. Тож це все одно не має сенсу.


126
Вони вдягають кращі костюми :-)
Стівен C

234
Більша зарплата в Америці не має нічого спільного з майстерністю. Чим більше вам подобається, і чим більше ви граєте в політичну гру, тим більше вам платять. Програмісти, як правило, логічні, розумні, люди, які говорять так, як це є. Керівники ненавидять це.
MVCylon

29
"... ті, хто пізно йде додому ..." Щоб не стикатися суворо, але це звучить як особисте питання, з яким потрібно вирішити. Якщо ви віддаєте довгі години таким чином, як ви визначаєте свою цінність для компанії, тоді необхідно зробити серйозний особистий аналіз.
Аарон Маківер

14
Нагадує про теорему зарплати Ділберта: csm.ornl.gov/~frome/dilbert.html
badgerr

27
Я зазначу, що прем'єр-міністр та бізнес-аналітик головного проекту, над яким я працюю, розміщують більше годин ніж я. У Всесвіті не вистачає грошей, щоб платити мені за свою роботу.
HLGEM

Відповіді:


389

Будь менеджери проектів отримують більші зарплати, ніж програмісти та бізнес-аналітики взагалі існують як клас, прямо залежить від світу програмного забезпечення, в якому ви живете.

Проста відповідь на це питання була б "тому, що в наших суспільствах ми все ще вважаємо, що зарплата пов'язана з посадою в ієрархії". Але ця відповідь відображає той факт, що людям платять виходячи з їхньої сприйнятої цінності, не пояснює, чому PM та BA перебувають на вершині ієрархії в багатьох програмних організаціях і чому управління переходить на ієрархію насамперед як структуру вибору для команди програмного забезпечення. Це два питання, які, здається, справді гідні задати.

Загалом, існує дві категорії організацій, що виробляють програмне забезпечення. Я буду називати їх фабриками віджетів та знімальними групами.

Фабрики віджетів народжуються поза школою менеджменту думок, що обертаються навколо теорії мотивації, запропонованої Макгрегором: рангові працівники ледачі та потребують постійного контролю та нагляду, роботи проводяться в ім'я чекової оплати, менеджери завжди можуть робити своїх підлеглих ' робочі місця за вищим або, принаймні, тим же стандартом. Це мислення належить до природної ідеї, що всю команду можна легко замінити та представити лише менеджером - адже всі інші в команді або легко заміняються, або просто для підвищення здатності менеджера виконувати завдання. Звідси випливає ієрархія як структура та досить горизонтальні рольові завдання.

Керівництво Widget Factory працює за припущенням, що програмне забезпечення може бути виготовлене за специфікацією, підготовленою бізнес-аналітиком, шляхом чітко визначеного процесу, що проходить під пильним наглядом керівника проекту. Про виробництво опікується персоналом проекту достатньо кваліфікованих, але взаємозамінних ресурсів програмування та тестування. Робота керується заздалегідь узгодженим бюджетом на основі першої ділової справи, підготовленої прем’єр-міністром та BA.

Управління, яке працює заводу Widget Factory, легко помітити, лише звернувши увагу на те, як ці люди розмовляють. Вони, ймовірно, стосуються ресурсів (у тому числі, якщо йдеться про членів команди), процесів, ефективності роботи, рівномірності, повторюваності, суворого контролю за використанням ресурсів, чітко визначених ролей завдань та визначених входів та результатів процесу. Вони випадково згадують про фактичну фабричну метафору, намагаючись передати образ ідеальної операції з розробки програмного забезпечення, як вони це бачать.

Потім є знімальні групи. Вони грунтуються на уявленні, що люди розумні, самомотивовані, працюють дуже важко і насолоджуються своєю роботою стільки, скільки дітям подобається грати. Екіпажі фільму визнають, що завдяки спеціалізації здібності індивідуального учасника можуть значно перевершити здібності людей, що організовують, координують та керують роботою. Оскільки менеджер більше не може замінити всіх, ієрархічна структура просто не працює так добре - людям доводиться співпрацювати в набагато більш плавному і складному плані, щоб все зробити. Самі ролі робочих місць, як правило, набагато вертикальніше - почніть закінчувати - і включають більш широкий спектр навичок. Це мислення управління спираються на МакГрегор Теорія Y .

Режисер фільму екіпаж знає, що її бачення програмного забезпечення може здійснитися лише в тому випадку, якщо вона зможе зібрати чудовий знімальний колектив, зачарувати уяви та допомогти команді зібратися та працювати разом. Її роль - надихати, охороняти зір, надавати напрямок та зосереджувати зусилля. Кожна людина має значення, тому що "директор" вважає, що програмне забезпечення є результатом поєднання світогляду та здібностей усіх учасників та унікального способу, коли група здійснює спільну роботу. Усі з самого початку усвідомлюють важливість того, щоб зірки приєдналися до екіпажу - зіркові виконавці збільшують усі шанси на успіх. Vision управляє бюджетом та залучає фінансування.

Коли йдеться про компенсаціюФабрики віджетів вважають, що найбільшу цінність отримують від роботи менеджера проектів та бізнес-аналітика, які проживають на вершині ієрархії і повинні отримувати відповідну компенсацію, решта команди не має значення стільки, скільки вони ' Ви отримали правильну кваліфікацію для перетворення вимог у робочий код. Прем'єр-міністри та БА наполегливо працюють над тим, щоб зберегти своє становище на вершині пакету, обмежуючи вільний доступ до джерел інформації про проект для решти команди. Без формального доступу до первинних інформаційних джерел команда намагається приймати будь-які ціннісні судження або придумувати хороші рішення, програмісти відмовляються приймати замовлення зверху та працювати над проблемою, визначеною ПМ та БА.

Зрештою, контрастний фільм виступає як більш егалітарна формація; членам надається необмежений доступ до первинної інформації, заохочується формувати ціннісні судження та вільно вибирати курс дій для виконання та сприяння баченню. Структура лідерства базується на здібностях, а не на певній ролі в колективі. Компенсація відображає те, як бажано залучити конкретну людину до участі в проекті, вона часто пов'язана з уявленням про те, наскільки ціннішим буде кінцевий результат, якщо ця людина може бути переконана присвятити свою енергію на створення цього програмного забезпечення. У цьому середовищі роль керівника проекту стає менш помітною, оскільки він навряд чи буде творчим лідером; роль зводиться здебільшого до адміністративної підтримки та зовнішніх відносин.

Тепер, це не буде несподіванкою, що більшість власних команд з розробки програмного забезпечення та деякі консультації працюють як фабрики віджетів, спираючись на процес виробництва послідовно нудного програмного забезпечення; саме в таких середовищах менеджерам проектів та бізнес-аналітикам зазвичай платять більше, ніж програмістам, виходячи з припущення, що вони приносять найбільшу цінність відповідно до структуризованого середовища, що ускладнює програмістам довести неправильність управління.

Успішні програмні компанії, як правило, переймають точку зору Film Crew, будь-яка інша філософія перешкоджатиме їх здатності залучати чудових людей, на які вони так багато покладаються на виробництво чудового програмного забезпечення. Навряд чи ви коли-небудь побачили б роль бізнес-аналітика в цьому налаштуванні, а керівники проектів менш помітні і зазвичай платять менше, ніж великим програмістам.


68
нам потрібен список виробників програмного забезпечення "Film Crew" :)
Гійом

8
відмінний контур ситуації
lurscher

46
Відмінна резюме. Важливим моментом є те, що в більшості компаній розробка програмного забезпечення трактується як вартість (така сама, як, скажімо, оплата рахунків за комунальні послуги), а не як основна інвестиція.
dbkk

3
Хороша відповідь! Ви дали хорошу картину двох різних видів оргів і зобразили, як вони бачать одну і ту ж роботу. Розробнику програмного забезпечення потрібно вибрати організацію, де його внесок буде важливим і цінним у виробництві. Як звукорежисер / музичний керівник - це кіно.
Шентіл Кумаран

39
Чувак, це геніальна відповідь. Аналогія Film Crew працює так добре. Я працював у знімальному майданчику 9 років, перш ніж його придбали на заводі віджетів, після чого я протримався лише 8 місяців. Потім я розпочав власний бізнес із розробки програмного забезпечення, і ми настільки знімальна група. Я думаю, ти щойно дав мені аналогію, яку мені потрібно повідомити, як ми працюємо. Дякую!
Даніель Полл

276

Тому що в наших суспільствах ми все ще вважаємо, що зарплата пов'язана з посадою в ієрархії .

Аналітики або керівники проектів вищі за ієрархією, тому їм слід платити більше.

Дозвольте розповісти справжню історію, яка ілюструє, чому це проблема.

Хороший друг почав програмістом у великій лікарні. Завдяки його наполегливій праці та відданості він швидко став Oracle DBA, що було критичним становищем у компанії, де дані є чутливими та цінними.

Лікарня працювала з рівнями. Рівні пов'язані з вашою посадою в ієрархії, спадщині та дипломами.

Мій друг отримав пропозицію стати DBA в іншій компанії, яка не використовувала рівні зарплати. Його зарплату можна було б значно збільшити. Оскільки він любив і поважав лікарню, в якій працював, він вирішив поговорити з начальником, попросивши підвищення.

Бос відмовився. Це було неможливо, оскільки рівні та профспілки не допустили цього.

Мій друг пішов.

Зрештою, лікарня найняла зовнішнього консультанта (не прив’язаний до рівнів) та розмістила роботу на своєму веб-сайті. Консультант нічого не знав про наявну інфраструктуру, тому його крива навчання була величезною. Через це лікарня втратила багато грошей.

Лікарня втратила набагато більше. Зовнішньому консультанту було заплачено в 5 разів більше, ніж просив мій друг, і вони не змогли знайти кваліфікованого співробітника, який би його замінив.

Це було майже три роки тому. Мій друг досі на своєму новому місці і дуже швидко піднімається по сходах ієрархії, роблячи те, що любить.

Лікарня ще платить у 5 разів більше.

ІМХО, зарплата повинна бути відносно вартості, яку ви надаєте компанії .

ОНОВЛЕННЯ : Коли ви рухаєтеся вище в ієрархії, виникає ефект важеля. Тож насправді вам платять за принесену вами вартість. Але блискучим програмістам, які в 10 разів продуктивніші, слід платити на 10 разів більше, незалежно від їхньої позиції в цій ієрархії (як правило, в самому низу). Саме це я хотів виділити.


73
Який чудовий анекдот.
Алан Пірс

28
Ви маєте рацію - зарплата повинна бути відносно вартості. Часто це не так. У деяких невеликих приватних компаніях, де зарплата кожного зберігається в таємниці (і індивідуально узгоджується), тоді лише великий начальник знає, кому за що платять. І іноді в цих місцях зарплата є відносною вартості, а деяким наглядовим людям платять менше, ніж справді розумні люди, які виконують роботу. Це трапляється не часто, звичайно.
quick_now

16
П'єр, це звучить як державний сектор у Великобританії!
ozz

10
Можливо, працівник міг запропонувати працювати зовнішнім консультантом?
Thomas Stock

4
@Thomas: так, я пам’ятаю, я запропонував це, але він був не дуже зацікавлений (страх втратити свою безпеку, що є ілюзією ІМХО), і це не вирішить бюджетну проблему лікарні.

84

Вони ризикують більше, ніж програмісти. Вони повинні приймати рішення на основі будь-якої інформації, яку ми їм надали, а потім стикатися з різкою критикою зацікавлених сторін, коли їхні очікування не виправдані. Частина пакету оплати компенсує цей ризик.

Іншим фактором можуть бути багаторічний досвід, необхідний для підготовки керівника проекту, який може правильно планувати, оцінювати та пом'якшувати. У певному сенсі нюансований менеджер проекту навчається через невдачі, що робить його дорого набутим навиком . Досягнувши рівня стажу, компанія може не бажати відпускати такий цінний персонал.

Редагувати:

Існує більше видів ризиків, ніж фінансова чи фізична шкода. Наприклад, врахуйте ризик отримання догани менеджером або замовником. Хоча фактичної шкоди не завдано, все-таки досить небажано, щоб ми адаптували свою поведінку, щоб уникнути подібного результату. Однак менеджерам доводиться постійно приймати хороші рішення, і він повинен балансувати різні види ризиків в інтересах компанії, а не відповідно до особистих переваг.


42
"Вони ризикують більше, ніж програмісти." Як що? Мені ще не доводилося бачити керівника проекту чи справді будь-якого менеджера, який зазнає серйозних труднощів через неправильне рішення. (У галузі програмного забезпечення, тобто)
biziclop

83
@ 9000 Поганих менеджерів проектів з іншого боку дуже легко знайти, і вони також командують вищими зарплатами.
biziclop

10
Сувора критика зацікавлених сторін насправді не є економічним ризиком і не коштує великої додаткової винагороди, це частина притягнення до відповідальності за низку прийнятих неправильних рішень або приховування правдивої інформації про прогрес роботи від зацікавлених сторін. Програміст стикається з подібним ризиком, якщо вони будуть вміло піймані, створюючи надзвичайно поганий непрацюючий код, повідомляючи про "все зелене". У більшості організацій прем'єр-міністри не піддаються критиці за те, що вони не надали це, вважаючи неможливим.
Влад Гудим

18
Звільнення з посади за те, що ви прийняли неправильне рішення, і піти з багатомільйонним пакетом виплат, напевно, це звучить жахливо!
Wooble

3
@biziclop: Якщо бути чесними, погані програмісти, як правило, тримаються як лайно і просто заповнюють рангові посади, не маючи своїх труднощів. І їх набагато більше.
Метт Столяр

80

Програмування певною мірою може бути складніше, але це також приємніше. Ви просто сидите там і вирішуєте приємну загадку програмування, в той час як менеджери займаються всіма лайми між підлеглими, клієнтами, власними начальниками та зацікавленими сторонами. Ось чому так мало розумних людей насправді хочуть бути менеджерами, тому вам доведеться компенсувати це, заплативши більше.

Програмувати складніше, але керувати смоктаннями більше.

Один із способів подумати, яка для когось цінність компанії - це уявити, як було б, якби ця людина покинула компанію. Зазвичай менеджери виявляються в цьому сенсі більш цінними, ніж програмісти. Джеймс Гослінг , творець Java, нещодавно покинув Oracle. Можна було б подумати, що це величезна втрата, але вгадайте, що? Насправді це не має значення. Це навряд чи має вплив на Java або на Oracle. Собаки гавкають, але караван продовжується.

До речі, я (серйозно) вважаю, що смітники та прибиральники повинні платити набагато більше, ніж програмісти. Очищення сміття інших людей - це робота, яка засмоктує і є необхідною.


12
@Joonas - ".... думаю, що пиломатеріалам та прибиральницям потрібно платити набагато більше, ніж програмістам" <- Вам потрібно буде пояснити це мені! WTF?
ozz

27
Безумовно, правда, що прибирання - це важка робота фізично. Тим не менш, є набагато більше людей, здатних зробити пристойну роботу прибиральницею, ніж є гідні програмісти. Тож ринок оцінює хороших програмістів вище.
Péter Török

13
@Mayank: Ні, я просто скромний програміст, який вважає, що програмісти, як правило, оцінюють себе занадто високо :-)
Joonas Pulakka

10
@jpartogi: Програмістам не потрібно терпіти і напружувати м'язи, щоб зробити код. Як ми знаємо, це зручна робота.
Joonas Pulakka

9
Сидіти перед устареною системою з дизайном, який перетворився в жахливий безлад і намагається створити швидкий патч для наступного випуску, не порушуючи більше коду, - загрозлива, але поширена задача програміста, яка насправді відвертається. Є тисячі щасливих менеджерів і тисячі жалюгідних програмістів. Тож ваша відповідь насправді не пояснює різницю у заробітках.
Влад Гудим

71

Зведення управління до створення діаграм та написання документації - це як би сказати, що програмування набирає текст.

У кожного свої, але для мене програмування набагато простіше, ніж управління людьми.


5
Це форум з програмування, тому більшість людей тут знайдуть програмування простіше, ніж управління. В цілому, без упередженості вибору, я б підозрював, що більшість людей можуть керувати краще, ніж можуть програмувати.
Девід Торнлі

15
Я не погоджуюсь. Хороших менеджерів мало і далеко між, як і хороші програмісти.
Діма

4
@ Woo4Moo ви повинні врахувати здатність цього твердження.
Яхель

8
@ Woo4Moo насправді, якщо ти не можеш мислити логічно, ти не можеш бути хорошим програмістом. Зараз існує досить багато інвалідів-програмістів, які використовують Dragon Природно кажучи та ін.
Анонімний тип

2
Мені важко повірити, що хороших менеджерів важче знайти, ніж хороших програмістів. Я працював із сотнями програмістів і натрапив лише на 3 або 4, які б я оцінив як хороших, і все ж я можу придумати десятки хороших менеджерів, з якими я працював.
Данк

36

Усі тут зосереджені на негативі. Я ніколи не зустрічав програміста, який любить офісну політику, а хороші менеджери захищають вас від такого сміття. Поспілкувавшись із великою кількістю людей у ​​нашому головному клієнті, половина з них божевільна, і я радий, що там мій прем'єр-міністр поглинає це божевілля для мене. Якщо вони їм багато платять, це добре. Він або вона потребує цього для неминучої терапії.


Вам не потрібно подобатися офісній політиці, щоб мати можливість ефективно грати в гру.
Wayne Koorts

4
Я знаю, але я вважаю за краще, щоб хтось інший грав у гру, щоб я міг написати код.
MattC

1
Я люблю грати в ігри, але не з іншими людьми.
Анонімний тип

3
Найскладніше в тому, щоб стати бакалавром, має сенс суперечливих вимог. Кожен із зацікавлених сторін має інше уявлення про те, що потрібно. Тоді великі начальники - найблудніші і божевільніші. Витяг вимог, які програмісти можуть мирити і виробляти щось корисне, достатньо, щоб змусити бакалавра пити і дорогі рекреаційні лікарські засоби.
CyberFonic

8
Так, але погані менеджери просто підштовхують офісну політику від клієнта прямо до розробника, що ніби не заперечує сенсу.
sevenseacat

20

Звичайно, це суперечить, але суттєвою причиною цього є те, що вони несуть відповідальність за проект, якщо він провалюється, а не програмісти. Вони можуть дати вам серйозний замах на щось, але вони стикаються з критикою навіть вищих сил. Вони відповідають за планування та оцінку .

Управління вимагає дуже багатогранного набору навичок: вміння людей, лідерство, вміння оцінювати витрати та час. Для цього їм також потрібно підтримувати зв'язок із вашою стороною речей (тобто мати певну думку про те, що ви робите, технічно кажучи) або бути дуже хорошими суддями характеру.

Якщо вимоги не були визначені правильно, це їхня вина.

Якщо плани випробувань не були визначені правильно, це їхня вина.

Якщо ви відправляєтесь у відпустку або зламаєте ногу, або збиваєтесь у суботу ввечері або виїжджаєте, не повідомляючи про це достатньо, і їм доведеться знайти заміну або <чомусь тут>, і ви не можете зробити свою роботу, і продукт не отримує доставлені (вчасно або взагалі), це все ще їх вина .

Також зауважте, що коли я маю на увазі, що вони несуть відповідальність, це впливає на людей, що знаходяться над ними та нижче . Якщо вони накрутять речі, то, можливо, завдання вашої команди стоять на черзі. Це теж тиск, за який ви платите.

PS: Плюс, я не знаю, чи сказав би я, що програмування складніше, ніж робити діаграми Ганта (щоб повторно використовувати приклад, який ви згадуєте). Я не знаю про вас, але я вважаю, що програмування (загалом, для 80% речей, які потрібно робити в галузі), досить легко. Якщо щось накрутили, ви можете це виправити. Якщо ваш бос мружить діаграми Ганта або оцінки його вартості, тепер буде набагато більш серйозною проблемою , ніж инвертирования != nullдля == null. Невеликі помилки мають значення в ширшому масштабі для них. Здебільшого, звичайно, якщо ви накрутили такий тест у вбудованому медичному додатку, який вийшов наживо, це теж велика проблема. Але вони матимуть більше проблем, ніж ви!


Вони можуть нести більшу частину відповідальності (більшість, не всю), але більшу частину провини вони не несуть.
sevenseacat

@Karpie: Звичайно, програмісти можуть притягнути до відповідальності за помилки, але менеджери понесуть більшу частину вини. Можливо, не за Вашим "так", але перед керівництвом компанії (або її зацікавленими сторонами) програмісти не винні. Це люди, якими керують. Звичайно, я можу зрозуміти вашу думку (і того, хто говорить, що "зарплати пов'язані з посадою в ієрархії"), і є деякі компанії, які відводяться від ідіотів, що керують командами і покладають провину на інших. Це не те, що повинно бути, і на мій досвід, це не загальний випадок.
haylem

@Karpie: І я знаю, що в очах деяких людей я можу бути захисником диявола тут, але, хоч я хотів би, щоб зарплата винагороджувала додану вартість, яку людина приносить компанії, я не знаю, що багато компаній, які б вміти працювати лише з програмістами. Деякий персонал приносить непряму цінність, і їх важче оцінити. І часто дуже просто вважати, що вони просто лежать, не роблячи нічого, вказуючи пальцями і граючи у гру з вини, коли вони, можливо, піддаються набагато більшому тиску, ніж ви могли подумати.
haylem

19

Попит і пропозиція - це економічна модель визначення ціни на ринку. Він робить висновок, що на конкурентному ринку одинична ціна для конкретного товару буде змінюватися до тих пір, поки вона не оправиться в той момент, коли потреба споживачів (за поточною ціною) кількість буде дорівнює кількості, що постачається виробниками (за поточною ціною), в результаті чого економічна рівновага ціни і кількості. Чотири основні закони попиту та пропозиції:

  • Якщо попит зростає, а пропозиція залишається незмінною, то вища рівноважна ціна та кількість.
  • Якщо попит зменшується, а пропозиція залишається незмінною, тоді нижча рівноважна ціна та кількість.
  • Якщо пропозиція зростає, а попит залишається незмінним, тоді нижча рівноважна ціна і більша кількість.
  • Якщо пропозиція зменшується, а попит залишається незмінним, то вища ціна і менша кількість.

У цьому випадку одна причина полягає в тому, що розробників занадто багато.


3
Є багато розробників низького рівня, але грамотні програмісти - це голки в копиці сіна
Foo Bah

10
Це звичайно теорія того, як зарплати повинні працювати в умовах ринкової економіки. Ваша зарплата не визначається вартістю, яку ви приносите компанії, а граничними витратами на заміну. Біда в тому, що справді вільних ринків немає. Непотізм, кронізм, пошук ренти та асиметрія знань є ендемічними. Теоретично організації, які потрапляють у цю неефективність, повинні припиняти свою діяльність ті, хто цього не робить, але коли майже всі це роблять ...
Чарльз Е. Грант

4
А може - важко визначити якість програміста, і тому ринок видається затопленим, але більшість постачальників фактично непридатні. Це пояснило б багато коду, який я бачив ...
Алекс Фейнман

Це справжня відповідь, незважаючи на всі приємні відповіді вище.
Нік Ходжес

1
Зауважте, що ринок не симетричний. У роботодавця є вибір тисяч програмістів. Програміст має вибір лише декількох роботодавців. Втрати роботодавця через одного програміста незначні порівняно із загальною капіталізацією чи доходом компанії. Втрати програміста величезні - зазвичай потрібно кілька місяців, щоб змінити роботу, тому це як відсоток або кілька відсотків єдиного ресурсу програміста - його життя. Ви бачите, що менеджери мають більше влади тут, оскільки вони в змозі зробити їх заміну дорожчою.
Антон Назаров

17

Я переходив між розробниками та керівниками ролей протягом своєї кар’єри. У мене розробники на моєму проекті роблять удвічі більше, ніж у мене, та інші, хто заробляє наполовину. Заробітчанам з високою заробітною платою виплачують те, що вони є: А) Вони - розробники "рок-зірки". Б) Вони взаємодіють із замовниками, пояснюють товар таким чином, щоб його легко зрозуміли клієнти та були персональними. В) Вони спрямовують команди розробників, які працюють над кількома проектами. Г) Вони завжди доступні і охоче радують.

Вони виконують ролі розробника, прем'єр-міністра та бакалавра в різних можливостях. Як правило, якщо ви витрачаєте 90% часу на голову вниз, скорочуючи код, ви не є надзвичайно цінними, і, швидше за все, їх легко замінити. Якщо ви хочете заробити більше грошей, то вам потрібно взяти на себе більше відповідальності ... і, ймовірно, доведеться знайти іншу компанію, яка заплатить вам більше.


11

Обґрунтування полягає в тому, що сфера відповідальності керівника проекту (часто) полягає в тому, щоб весь проект вчасно та з прийнятною якістю здійснити в межах запланованого бюджету. Загрожує багато грошей, тому, звичайно, хороші менеджери проектів часто отримують більшу компенсацію, ніж програмісти.

Однак я не відчуваю, що бізнес-аналітики в середньому заробляють значно більшу зарплату, ніж програмісти. І я відчуваю, що стає все рідше, що рівень зарплати в компанії визначається ієрархією, а не вартістю працівника.


Я думаю, що причиною цього є те, що багато бакалаврів пропонують рекламодавці. У багатьох компаніях просування не означає більше грошей.
IAdapter

10

Мій досвід може відрізнятися (або я живу в іншій всесвіту з перекрученими законами фізики), але більшість бізнес - аналітиками і менеджерами проектів (НЕ програма менеджерів, але проект менеджери або PMPs) позиція , які я бачив в або трохи нижче середня зарплата програмістів.

Різниця в заробітній платі починає більше розширюватися в порівнянні із середньою зарплатою інженерів програмного забезпечення (на користь інженера-програміста). Розрив ще більший у порівнянні зі старшими інженерами з програмного забезпечення або старшими програмними розробниками. Майже жоден старший бізнес-аналітик чи старший PMP не зроблять так само, як старший EE або старший / головний програмний інженер.

Однак, менеджер програми (який не є тим самим, як PMP), ця людина зробить набагато більше, ніж хто-небудь інший (і причини повинні бути очевидними.)


Найбільше, що мене найбільше клопоче, коли я бачу ці скарги на зарплату, - це те, що ми, як програмісти (особливо як молодші / початкові програмісти на підприємстві), не такі особливі. Немає насправді нічого, що є у програміста початкового рівня, поза школою, що заслуговує на зарплату вченого. Ні .

Усі ми, хто працює над програмним забезпеченням, починали з нуля. Ми всі робили.

І якщо ми справді чесні, ми добре знаємо, що не знали лайна. Можливість скласти наш курс з нижчого рівня CS - це лише вихідна точка. Це не робить нас такими особливими чи ЗОМГ !!!! убер-ейнштенський. Дійсно, НІ!

І все-таки (і завдяки нещасному періоду дот-ком бульбашки) ми очікуємо, що ми зробимо не просто більше, а набагато більше, ніж інша людина, здобута університетською освітою, лише тому, що О, як ми, програмісти, і вони просто бізнес аналітики та ПМП.

Чи можете ви вимовити зарозумілість? Newsflash - для більшості завдань програмування на підприємстві вам навіть не потрібна 4-річна ступінь. Дійсно, це серйозно.

Покладіть час на меліруйте і накопичіть досвід для переходу від програмування до інженерії програмного забезпечення (або інженерії з цього питання) на старший рівень. Тоді ви можете вимагати зробити багато, багато, перо мучо мучо набагато більше, ніж бізнес-аналітик та ПМП.

Займіться цим - дехто з нас (або був) переплачений. Період.


Не відмовляйтеся: причини бізнес-аналітику та / або PMP зробити зарплату близькою або подібною програмістам, які ще не накопичили необхідний час та досвід для того, щоб бути середнім / старшим інженером програмного забезпечення (або які досі не розвинули експертизу у надзвичайно затребуваній ніші область):

Бізнес - аналітик є сполучною ланкою між програмним забезпеченням і системами людей і ділових людей / бізнес - процесів (які є ті , які виправдовують існування вашої зарплати, а не навпаки.) Вони відповідальні за руйнування бізнес - процесів в методичної, аналітичні манери, як вхідні дані для формування вимог, речі, над якими ви працюєте. Вони гарантують, що ви витрачаєте більшу частину свого часу на програмування, а не займаючись дрібницями бізнесу.

Багато хто з вас думає, що бізнес - це лайно. Якщо ви справді думаєте, що це правда, Бог вам допоможе.

Керівник проекту - це людина, відповідальна за проведення жонглювання декількома проектами (тоді як вам потрібно маніпулювати лише одним або двома в будь-який момент часу.) Він ваш парасолька, і він повинен виконувати брудну роботу більшу частину Залишилися немиті маси не хочуть робити - переслідувати людей, переконуючись, що вони виконують свою роботу, або усуваючи перешкоди на вашій роботі.

Він запитає вас: "над чим ви працюєте? Це над тим, як ви працюєте над тим, щоб допомагати рухати проект? Чи є у вас проблеми з вашою роботою? Які ваші перешкоди, що вам потрібно? Хто може вам це дати?" "...

а потім він піде до інших, задаючи ті ж важкі запитання, переконавшись, що перешкоди усунені, і переконавшись, що ви тягнете свою вагу за проектом (якщо потрібно).

Проблема номер один, яку я бачив у багатьох невдалих проектах, - це відсутність ПМП або неповага до ПМП (особливо від розробників.) Рідко я бачу, що проекти провалюються через некомпетентні ПМП, і все ж виникає питання, чому багато програмістів є більш ніж прагнуть сказати, що це так.


За винятком того, що програмісти не вимагають великих зарплат лише тому, що ми спеціальні (не більше, ніж хто-небудь інший), а тому, що ми можемо їх отримати. Це не справжній загальний талант, і тут дуже багато попиту.
Девід Торнлі

@David - дійсно, це не є загальним талантом ... навіть серед програмістів. І це моя думка. На підприємстві є надмірна кількість програмістів (спасибі dot-com та університетам java / .net). І багато програмних робіт на підприємстві недостатньо складні, щоб вимагати зарплати за ракетну науку. Попит і попит у поєднанні з більш простими вимогами (і той факт, що ми досі не вдосконалили способів написання програмного забезпечення) говорить про те, що багато хто з нас такі особливі (оскільки багато хто не має або не розвинув ще цього рідкісного таланту), і є, ерго, переплачені.
luis.espinal

3
@ luis.espinal: Більшість людей вимагають найвищої зарплати, яку вони можуть отримати. Питання полягає не в тому, чи мають вони моральне право на це (чи хтось має моральне право на виплату більше, ніж хто-небудь інший?), А в тому, чи ринок такий, щоб вони могли їх отримати.
Девід Торнлі

1
ваша публікація занадто довга, я перестав читати після першої сторінки.
Анонімний тип

2
@ Анонімний тип - я спробую придушити його наступного разу.
luis.espinal

9

Я фінансуюсь, і думаю, менталітет схожий у більшості нетехнологічних нарядів:

Оплата пропорційна ризику кар’єри

Забороняючи повне звільнення групи або команди, програмісти низького рівня завжди зберігають свою роботу. Це природа роботи, і програмісти вступають у неї, добре розуміючи, що вони беруть нульовий ризик. Якщо є помилка, це не їх голови на рубаючий блок.

На більш високих рівнях, якщо щось накручується, ви першими йдете. У мене було багато досвіду з підлеглим, який допустив невелику друкарську помилку, яка призвела до того, що ми втратили гроші, і я взяв за це тепло (а не власне програміст, який допустив помилку).

Простіше кажучи, оплата пропорційна ризику. Програмісти, з іншого боку, не обов'язково мають будь-яку шкіру в грі, так би мовити.


5

Якщо ваше запитання було "чому X і Y отримують більші зарплати, ніж програмісти в моїй компанії ", я можу відповісти "ви можете працювати в неправильній компанії".

Успіх компанії в бізнесі програмного забезпечення залежить більше від здібностей його програмістів, ніж будь-хто інший. Компанії, які не визнають цього, автоматично перебувають у невигідному стані порівняно з тими, хто отримує це. Найняти найкращих програмістів і добре піклуватися про них - це найкраща ставка. Різниця у роботі великих програмістів проти решти величезна; набагато більша за різницю в зарплаті, яку вони отримують. Але якщо ви будете наполягати на недоплаті своїх програмістів, ви отримаєте те, за що платите.

Однак, кожна інша роль у бізнесі важлива. Великий вплив мають великі менеджери. Багато чого - це отримання чудових програмістів та підтримка їх щастя. Щось подібне можна сказати про бізнес-аналіз, маркетинг, продажі, тестування та підтримку.

Якщо ви чудовий програміст і не отримуєте гарної винагороди, вирушайте кудись ще. Знову ж таки, ви, можливо, не чудовий програміст. На жаль, якщо ти не великий, важко зрозуміти, чому. Якби ти знав чому, ти міг би змінитися і стати чудовим, правда?

Я був програмістом і був менеджером по роботі з людьми. Я працював з великою кількістю чудових програмістів, але лише з кількома чудовими менеджерами. Коли я був менеджером, я не був чудовим, але, принаймні, це знав. Мої люди отримали більше підвищення, ніж я, чого вони заслужили.


5

Це не має нічого спільного з навичками та роботою, я маю на увазі мало що в економіці пов'язане з тим, скільки люди заслуговують на заробіток.

Заслуговуючи на те, щоб заробити більше грошей, це ефемерна ідея, всі вважають, що вони заслуговують на те, щоб заробити більше грошей.

Хоча це може бути не справедливо, менеджери заробляють більше грошей просто тому, що власники бізнесу більше їм довіряють. Менеджери часто отримують більші зарплати, просто, щоб вони не сприймали нову роботу в неприємний час.


4

Я думаю, що вся ваша основа для цього питання є хибною.

Управління повинно платити більше, ніж їх підлеглі. Стаж у компанії, як правило, ґрунтується на зарплаті, і молодший працівник не може мати кошти командувати своїх старших.

Провідні люди - це навичка спеціаліста. Не кожен може бути керівником проекту (ПМ). Завдання стає все складніше, оскільки кількість персоналу збільшується. У технічній ролі прем'єр-міністра потрібно добре розуміти технологію для ефективного керівництва - інакше вони не матимуть поваги та підтримки своїх підлеглих.


6
Думаю, що справа в ОП полягає в тому, що не тільки справді кваліфіковані та хороші керівники отримують більш високу зарплату, ніж їхні підлеглі, але (майже) всі вони, навіть справді нездатні.
Péter Török

1
Інше питання: управління - це навичка людей. Я не думаю, що хороший прем'єр-міністр дійсно потрібен, щоб бути дуже підкованим для того, щоб мати повагу та підтримку членів його команди (навіть не думаю, що ці члени команди дійсно повинні бути підлеглими прем'єр-міністра). Я повністю погоджуюся з Peopleware тим, що хороший менеджер працює над усуненням усіх перешкод перед командою, а потім дозволяє їм виконувати свою роботу.
Péter Török

11
Управління повинно платити більше, ніж їх підлеглі. Не обов'язково. І, безумовно, я не хочу працювати в компанії з цим правилом "обов'язок".
Микита Барсуков

1
Я ніколи не знаходив і не чув про компанію чи організацію, де це було не так. Хоча, правда, мій досвід є у двох дуже старих галузях (банківська та державна).
TZHX

4
@tzhx: Я працював для пари серйозних компаній, де моїм менеджерам платили приблизно стільки ж, скільки мені, і менше, ніж за деяких моїх колег, які були кращими спеціалістами, ніж я. Ні, це нікого з нас не турбувало, і не змушувало нас дивитися на менеджерів як на неповноцінних. Кожен з нас робив свою власну роботу, поважаючи роботу інших людей - наші менеджери робили очевидно розумну роботу. Командний дух повинен козиряти ієрархією, імхо.
9000

4

У багатьох професіях основна майстерність - це вміння щось продати. А щоб продати щось буде, потрібно продати себе. Покупець вам повинен довіряти і цінувати наданий вами товар чи послугу стільки, скільки ви плануєте. Ця навичка повністю переноситься на переговори про зарплату.


4

Я переглядав кожен пост, і смію сказати, що більшість із них намагаються порівняти яблука та банани.

Перш за все, я вважаю, що той, хто каже, що "керувати шматочком пирога", ніколи не повинен був керувати чим-небудь далі, ніж його власний графік. З іншого боку, сказати, що «кожен може кодувати що завгодно» - нерозумно (і на форумі неправильний, ради бога!).

Мені особливо сподобалися rwong та luis.espinal asnwers, хоча я вважаю, що є й інші факти, які також слід помітити.

Я не вважаю ієрархію як відповідь - не сьогодні - хоча вона ідеально підходила за останні 10 000 років. Ми століттями жили в суспільстві, де чим більший ваш прибуток, тим вища ваша сила (і навпаки). Я не вірю, що це стосується нашого світу, таким, яким він є (особливо в нашій місцевості).

Повертаючись до головного питання, я вважаю, що менеджери зазвичай заробляють більше, тому що вони цінніші для компанії не тому, що він вищий за ієрархією, але він вищий через

  • всі знання, які він вже набрав з попереднього досвіду (зазвичай програмісти мають менше досвіду, ніж менеджери загалом)
  • за вміння керувати кількома речами одночасно (програмісти мають одне завдання - або список завдань -), а менеджери повинні керувати своїми завданнями
  • вони є головним контактом проекту, яким вони керують, і саме тому вони є першою «ціллю» у випадку, якщо щось піде не так. Простіше втратити роботу, якщо ти менеджер; будучи розробником, у вас є "ліцензія, щоб щось переробляти". Це фактор "ризику", про який говорили всі.
  • розробники є частиною цілого життєвого циклу проекту. Я вважаю, що коли ми говоримо тут про «програмістів», ми також думаємо про тестерів, технічних авторів та всіх інших людей, які дуже важливі для успіху проекту.
  • і є щось, що я бачив лише в парі публікацій на цю тему: лідерство. Бути менеджером - це знати, як налагодити контакт з людьми, вести переговори, мотивувати всіх, створювати синергію, коли настрій у кожного знижується.

На мою думку, фактор лідерства є основною причиною підвищення зарплат, оскільки він генерує величезний довгостроковий результат для компанії та для всіх, хто навколо лідера.

До речі, я мав лише декілька досвіду як керівника команди (далеко не керівника проекту!), І скільки я знаю, що робить лідер, стільки роботи, яку я усвідомлюю, що треба зробити.

Редагувати: Забув підкреслити: навички спілкування не є сильною стороною для більшості з нас, але це обов'язково для керівника. Крім того, я хотів би поділитися дуже хорошим повідомленням у програмі Coding Horror, пов’язаним з хорошими програмістами та комунікаційними навичками -> http://www.codinghorror.com/blog/2011/02/how-to-write-without-writing .html


3

Подумайте про це таким чином, кількість кваліфікованих менеджерів менша за кількість кваліфікованих програмістів, тому менеджери є більш «цінними» для компаній.


Саме так. Ціна праці не застрахована від закону попиту та пропозиції.
Нік Ходжес

За винятком того, що є багато більш кваліфікованих менеджерів, ніж кваліфіковані розробники, що визнає ваш аргумент недійсним.
Данк

3

Це залежить від того, як ви визначаєте "складність". Хоча мені цікаво, чи ти знаєш, про що йдеться в управлінні проектами і що слід робити бізнес-аналітикам. Я з великим розчаруванням прочитав ваше запитання, тому я думаю, що у вас є поганий досвід. Тим більше я хочу спробувати відповісти на ваше запитання.

Керівники проектів та бізнес-аналітики, як правило, «старші», коли виконують ці посади. Там, де розробники починають свою кар’єру дуже молодими (близько 20-х років), більшість керівників проектів та аналітики мають близько 30 років (що вже створює різницю в оплаті лише за віком). Вони також ті, хто стикається з викриттям замовника, а це означає, що їм доводиться подорожувати на місці, проводити години катувань, щоб слухати клієнта (особливо, коли проект іде не так) і залучати його побажання / потреби. Вони повинні бути обережними, що вони обіцяють, і особливо в тому, в якому обсязі (час доставки). Незважаючи на те, що те, що вони роблять, це лише документування, бізнес-аналітики навчаються аналізувати потреби бізнесу, а керівники проектів охороняють планування проектів.

Вони виконують роль брандмауера між замовником та розробниками. Технічна перспектива - це щось інше, ніж перспектива продажу. Більшість бізнес-аналітиків та керівників проектів також стикаються з великою кількістю клієнтів - вони піддаються впливу, і тому вони мають «привід». Їх мережа складається з осіб, які приймають рішення, і тому компанії вважають за краще тримати людей з такими мережами в межах досяжності; адже продаж - це продаж.

Щодо складності? Створіть компанію, майте десять розробників і спробуйте керувати проектом. Головний біль приходить з цим безкоштовно. Робіть це протягом року, а потім знову подивіться на свою відповідь. Для бакалаврів? Ідіть на таку можливість. Сідайте з клієнтами, у яких AIX-машина з 1974 року, і дизайнер цієї системи мертвий / пенсіонер / вмирає / альцгеймінг, і розробник повинен знати, чи генерується певне значення чи має якусь містичну формулу. Постарайтеся переконати 20 людей з власною точкою щодо вашого рішення протягом 3 днів. Якби документування було таким "простим", Linux уже в 1997 році заграв би світ. Дійсно, спробуйте щомісяця писати технічну документацію для людей, які не є технічними (ті, хто вважає, що Facebook - це революція в обчислювальній техніці).

Я інженер з продажу. Що означає, я розробляю, але мій спеціалізм - для прототипів та демонстрацій. І я заробляю більше, ніж бізнес-аналітик чи керівник проекту. Не тому, що у мене є мережа (я хоч і є), а тому, що я покинув своє ставлення та більше зосередився на перспективі бізнесу, отримав сертифікацію та навчив себе деяким м'яким навичкам. І досвід дізнатися, що «ні» - це також відповідь, коли мова йде про понаднормовий час.


Уся ваша відповідь є хибною. Програмістів, які перебувають у тому ж віці, як BA та PM, все одно буде менше.
Джошуа Партогі

Офіціантка також стикається з клієнтами і отримує багато лайно в їх обличчі, але саме шеф-кухар забруднить руки і зробить те, що хоче клієнт, і отримає більше в кінці дня.
Джошуа Партогі

2
Тепер кажучи, що вся моя відповідь є хибною, в основному кажу людям, що ваша думка та досвід - це єдине, що є правдою / фактом. Я вказую, що ваш факт не завжди є правдою, як я переживаю інші речі.
Шям

3

Проста відповідь: Вони цінніші для компанії, ніж програмісти.

Чому? Тому що вони забезпечують завершення проектів, навіть якщо вони самі не займаються програмуванням. Це означає, що їх цінність (суто в грошовому вираженні для компанії) більше, ніж для індивідуального програміста. Компанія не вірить, що некеровані програмісти є продуктивними, а тому цінними ... Це робить лише менеджер.

Відстій, і нам це може не сподобатися, але саме тому компанія платить їм більше.

Їх позиція (як уже вказували інші) має свої недоліки: якщо вони не зможуть завершити проект до певного часу, це їх вина, а не програмісти. Вони беруть на себе більшу відповідальність, і велика ймовірність звільнити їх за невдачу (якщо тільки не працює якийсь BS компанія nepotiism).

Тож насправді їм не дозволяють робити помилки, чинять більший тиск на них та мають набагато більш мінливу роботу ... але не плутайтесь: за це їм не платять більше - компанія не дає дупі щура, під яким тиском ти знаходишся, наскільки нестабільна твоя позиція, щось подібне. Їм цікаво лише те, яку цінність ви приносите компанії. Період.

Це капіталізм, люди.


2

Я не знаю, скільки разів потрібно оновлювати знання діаграми Ганта за рік. Але займаючись програмуванням, потрібно оновлювати себе новими технологіями, що буде не так просто з вашим віком.

Для вивчення нової технології потрібні години поту, які, якщо ви досить розумні, щоб поглинути.

Навичка, здобута за роки занять програмуванням, не цінується в сучасній культурі компанії.

Порівнювати заробітну плату новоспечених програмістів із тією, що має понад 10-річний стаж, є трохи сумною історією.

Порівнювати нового прем’єр-міністра з 10-річним прем'єр - це чудова історія, прем'єр-міністр може стати директором після 10-річного досвіду.

То чому все ще так багато людей хочуть вивчати ІТ в університеті? Я не розумію. Чи правильно вони проінформовані?

Я не розумію, як люди цінують майстерність у наш час.



2

Управління не завжди заробляє більше, ніж інженерний персонал. Старший інженерний персонал повинен брати активну участь у аналізі бізнес-рівня та прийнятті рішень та складенні технічної дорожньої карти для компанії. У цьому випадку старший технічний персонал може зробити трохи більше, ніж керівники бізнесу, з якими працюють щодня.

Один з популярних міфів бізнесу полягає в тому, що менеджеру слід платити більше, ніж людям, яким він / вона управляє. ІМО, ви вважаєте, що це поняття більш глибоко закріпилося в бураці, ніж у функціональних, спритних командах.

Інакше кажучи: компенсація повинна відображати значення внеску людини в компанію. Є менеджери зоряного бізнесу та середні менеджери, а також є зоряні інженери та середні інженери. Якщо у вас є зоряний інженер, який розкручує технологію отримання грошей і має глибокі знання технологій компанії, чи не в інтересах компанії компенсувати цю людину більш агресивно, ніж середній бізнес-менеджер, який, як правило, керує цим зоряним інженером? Яка альтернативна ціна втратити цей інженерний досвід та навички, оскільки ви нехтували цим цінним ресурсом?


"компенсація повинна відображати вартість внеску людини в компанію". Це визначає верхню межу можливої ​​зарплати. Що стосується нижньої межі, я вважаю, що пояснення в programmers.stackexchange.com/questions/45776//45963#45963 справді чудово, як і те, що в програмі.stackexchange.com/questions/45776//45879#45879 .
Сума

2

Я почав місяць тому зі свого першого проекту як прем'єр-міністра. До того, як я працював програмістом. (до речі, я отримую ті ж гроші, що і раніше.)

Я з’ясував, що бути хорошим прем’єр-міністром означає бути хорошим програмістом із широким досвідом. Ви повинні мати можливість переходити від одного члена до іншого та обговорювати проблеми, які вони мають, використовуючи ваш практичний досвід, щоб допомогти їм зрозуміти проблеми, надавши іншу точку зору. Ваше завдання, крім іншого, керувати інтерфейсами. ПМ - це як провідник. Ви можете мати найкращих музикантів, але якщо у вас немає хорошого диригента, який би вмів добре грати на оркестрі на мета-інструментах, ви отримуєте лише безлад.

Контрагентом є фахівець. Це програміст, який здатний вирішити складні проблеми, оскільки він глибоко знає проблематичну область. Ці досвідчені люди часто також отримують високу оплату, якщо вони досить добрі в переговорах. На жаль, фахівці часто є дурнями і не так зацікавлені в грошах чи хорошій справі, щоб зробити добру справу ...


1

Програмісти не вважають зарплату найвищим пріоритетом (якщо припустити, що це за розумною ставкою). Уявіть дві пропозиції для роботи, де одна має більшу зарплату, одночасне зобов’язання, але вимагає технічної підтримки, суворого робочого часу, дрес-коду, написання користувацької документації, роботи зі застарілим кодом старовинною мовою, яку ви сподівалися, що вам більше не доведеться використовувати більше, як набагато більше зарплати ви потребуєте?


1

Якщо ви працюєте в компанії, яка поважає програмування, математику, вирішення проблем, будь-які навички, то ви можете заробити більше за дві речі:

  • Робити складнішу роботу
  • Взяти на себе більше відповідальності

Тільки тому, що лікарня не платить своїх кваліфікованих клієнтів з великою вагою (див. Приклад у першій відповіді), не означає, що це однаково у кожної компанії.


-1: Лікарня не платить висококваліфікованому DBA? Скажи мені, до якого я знаю, що не їхати. Я не хочу, щоб медична документація моєї родини була порушена або втрачена.
Джим Г.

1

Гаразд, я злегка здивований відповідями, так ось що. Але перед цим я просто хотів би уточнити, що я програміст, і немає нічого, що мені подобається більше, ніж програмування. Це сказало, що я здорово поважаю та поважаю компетентних прем’єр-міністрів та керівників органів влади. Я усвідомлюю, що багато хто з нас обурюються прем'єр-міністрами та бакалаврами, оскільки на відміну від програмування, в них можна досягти успіху без необхідного рівня компетенції (офісна політика, гарні костюми тощо).

Однак і управління проектами, і бізнес-аналіз є важливими компонентами розробки програмного забезпечення.

Щоразу, коли ми думаємо про розробку програмного забезпечення, багато хто з нас мають тенденцію зосереджуватися лише на програмуванні, щоб виключити все інше. Але в цьому є більше, ніж кодування.

Перша мета розробки - створити програмне забезпечення, яке фактично вирішує та вирішує проблеми клієнта. Це означає, що спочатку з'ясувати вимоги замовника (оскільки клієнт може бути не дуже впевнений, чого він хоче), це можливо лише шляхом детального аналізу домену, в якому працює замовник та структури різних артефактів (будь то люди, технічна інфраструктура або обробляти), а потім розробити відповідне бізнес-рішення (та його інтеграцію з технологією) для задоволення цих вимог.

Так само будь-який проект значного розміру абсолютно не може працювати без ефективного управління. Зараз я не знаю, як це в інших місцях, але поки що мій досвід був таким, що прем'єр-міністри зазвичай отримують з ряду програмістів, тому вони мають певне уявлення про те, що потрібно для організації та виконання проекту.

Підводячи підсумок, і БА, і ПМ є абстракційним шаром для розвитку .


1

Тут багато людей говорили, що програмування складніше і саме тому на ньому слід більше заробляти. Це дуже романтичний погляд. Правда полягає в тому, що в звичайній здоровій компанії оплата відповідає відповідальності , що означає додаткову вартість цієї людини, а також ризик .

Про ризик часто забудуть. Як правило, якщо програміст не справляється зі своєю складною роботою, можливо, збільшаться витрати, але нічого більше. Не так, як 10% працівників втратять роботу чи щось подібне. Ризик досить низький.

Також я хочу не погодитися з думкою, що більшість ділових людей заробляють більше. Надіюсь, звичайний бізнесмен заробляє менше, ніж більшість бакалаврів наук / техніки зароблять. Наприклад , як старшокурсники свято кодером я заробив майже такий же , як деякі повний робочий день бізнес StuFF працівників в одній і тій же компанії.

І останнє, але не менш важливо, чому керівник проекту не інженер? Зазвичай менеджер проекту - це хлопець, який багато років передує в темі проекту, яким він керує, тобто в програмуванні роботи це буде досвідчений програміст, який є керівником проекту.


1

Існують корпоративні середовища, в яких домінує або схема команд та управління, або схема зв'язку між центрами та розмовами. У цих організаціях менеджер та головний комунікатор часто одна і та сама людина. Це робить менеджера єдиним пунктом відмови - посилюються будь-які похмурі ефекти неправильних комунікацій або втрачених перекладів. Отже, такі середовища вимагають від менеджерів людей з великим технічним досвідом, щоб забезпечити точність.

Краще організовані команди зазвичай призначають головного комунікатора, щоб зняти цю відповідальність. Організації, які практикують управління знаннями , не мають жодної точки збою в спілкуванні. У цих організаціях менеджери та головні комунікатори просять інформацію та сприяють обговоренню. Ця інформація буде захоплена та оброблена для внутрішнього обміну. Необхідний інший набір соціальних навичок.

Крім того, бізнес-аналітики часто є єдиною точкою контакту між клієнтами та технічним персоналом компанії.


1

Це не завжди так. Коли я працював у корпорації Computer Science Corporation (CSC), більшість менеджерів зробили менше, ніж "люди, які виробили щось корисне". Що стосується CSC, я думаю, що це було так, тому що компанію створила група програмістів.

У той час (1970 р.) В Лос-Анджелесі була ще одна компанія з програмним забезпеченням, ім'я якої я забуваю з цікавим графіком зарплат. Програмістам виплачується 25 000 доларів на рік, а обслуговуючому персоналу - 15 000 доларів на рік. Ідея полягала в тому, що якщо ти там гірший програміст, тебе не здивують, щоб його замінили.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.