Чомусь склалося враження що пропонується підхід вже з кінця. Хтось вже переконав budget owner-ів, описав цілі проекту і бенефіти — отримав політичне «добро» на запуск — а тоді вже починається набивання проекту смисловими цілями, заміна одних іншими і т.д. В житті частіше інший підхід працює — описав, переконав, запустив, зробили — а що вже виявилося дійсно корисним узнаємо по факту використання. Напевно все-таки — практика — критерій істини, а не гіпотетичні розмірковування про цінності.
Привіт Сергій! Дуже хороший результат, мої вітання! Реально верхній перцентиль
Хороший опис методу оцінки по трьох точках. Хороший тим що досить просто написано. Є багато теорії за ним, і нові наукові праці пропонують інші коефіцієнти, але то вже деталі. В нашій компанії всі менеджери проектів мусять знати цей метод, і використовувати його (у трохи іншій варіації) де можливо — оскільки він самий точний, хоч і не швидкий.
Самий швидкий — метод аналогії і експертна оцінка.
Стаття коротка, а тема дуже широка і складна. Очевидно що тут багато спрощень, а багато відступів в тексті взагалі не про проекти. Людям які тільки починають свій шлях у проектному менеджменті я би радив не шукати «спрощень», а все таки глибоко розібратися в темі. Ось наприклад тема мотивації — теорій багато (тут тільки деякі — uk.wikipedia.org/wiki/Мотивація) і всі вони можуть бути використані і принести результат за певних обставин. Але мотивація в людей різна, більше того вона ще й міняється в часі — тому не все так просто.
Або наприклад визначення цілей проекту. Це дуже проста і хороша ситуація, коли вам потрібно розмовляти тільки з одією людиною на стороні замовника. А коли там багато учасників які впливають на проект, і часто їх інтереси просто не співпадають — тут вже без хорошої підготовки (в тому числі знання різних методів) і попереднього досвіду буде дуже важко.
По темі підводних каменів — всі вони починають з’являтися в результаті поганої перед-проектної підготовки, недостатнього планування, самонадіності і недисциплінованості ПМа. Часто це відбувається під гаслами Agile методологій — начебто «будемо уточнювати плани і специфікації по ходу». Тільки у випадку проекту це частіше не працює, ніж дає хороші результати. Тому Agile це гарно, але для проектів потрібен саме проектний менеджмент.
Що ж робити — ну я би сказав читати стандарти (www.pmi.org/...ndards/foundational/pmbok), глибоко розібратися в кожній темі окремо, і не забувати про дисципліну. Тоді все буде виходити.
Податкова шкала прогресивна — це правда. Вища ставка застосовується тільки до суми, яка вище порогової. Тому чиста виплата ніколи не зменшується при рості грос-зарплати. Проте існують всякі додаткові пільги — які можуть бути відмінені при певному рівні доходу. Або ж наприклад можуть заставити платити аліменти чи виплачувати кредит, які при низьких доходах можна абсолютно легально не оплачувати. Тому дійсно трапляються дивні ситуації, коли людина не хоче підвищення зарплати — але це, як правило, стосується всяких маргіналів і мігрантів, а не програмістів.
Я би радив не вигадувати свою термінологію, якісь особливі описи стандартних ролей і незрозумілі варіації управлінських практик — а просто почитати спеціалізовану літературу і вивчити те, що в проектному менеджменті (як в ІТ індустрії так і в інших) вже давно є загальноприйнятим. Почати можна звідси — www.pmi.org/...
Тот факт что они набирают людей ещё может означать, что оттуда уходит человек, решавший все проблемы.
За 12 лет своей карьеры я слышал эту песню множество раз, менялась только сумма с 400 долларов вДа, действительно, за это время зарплаты в стране вообще и в IT в частности выросли в десяток раз. И в каждый момент времени есть своё распредение, рамки в которые попадает большинство зарплат. И у большинства известных мне зарубежных заказчиков есть примерная «планка отказа» — цена за которую они человека в аутсорсинговой компании уже не купят, ибо в сочетании с рисками, менее эффективной коммуникацией на растоянии, и непрямыми затратами — получается уже дорого, и альтернатив появляется на удивление много.2000-02 до 5к в 2013.
Давайте без перехода на личности. Скажите, скольких Тех Лидов или Архитекторов вы лично знаете, у которых зарплата 5 тыс долларов и больше? Только не вакансии, а именно живых людей, ибо с трюки с указанием завышеной зарплаты чтобы получить кучу резюме, а потом стебаться на собеседовании и по году-два искать идеально-сферического-коня-в-вакууме — это не считается.
Только скорбный умом менеджмент...
Откровенная ложь...
...откровенная бравада и не умение грамонтно оценивать риски...
...не очень грамотный блеф...
IMHO — Зарплаты 5000 и более это исключительные случаи. Такое иногда бывает, но обусловлено это случайным стечением обстоятельств и слабой (или отсутствующей) кадровой политикой. Например, когда в небольшую компанию попадает проект, который она по сути выполнить не способна, людей с нужной квалификацией нет, но есть давнее знакомство между руководством заказчика и компании исполнителя и т.п. Тогда начинается лихорадочный поиск людей за любые деньги, работа на грани или за гранью рентабельности. Когда проект заканчивается, либо набирается опытная команда и налаживается процес работы, переоценённый тех.лид обычно становится ненужным. В больших компаниях такого почти не бывает — там с кадровой политикой порядок, найти замену из более молодых тех лидов или опытных senior developer-ов (которые давно уже ждут продвижения) труда не составит.
Есть и другие примеры высоких зарплат (продуктовая компания, аутстаффинг), но смысл примерно тот же — случайное стечение обстоятельств и неопределённое будущее такой позиции.
Данные зарплатного опроса достаточно достоверно указывают на то, что достижимо — jobs.dou.ua/...1=5&exp2=10 — не принимая во внимание несколько «лотерейных» вариантов.
Поставьте фильтр по типу жилья — квартиры. (ejerlejligheder). Получаем 25497 DKK. Около 4400 USD.
Вцелом, адекватно описанны причины почему доверие важно (скажем я с причинами согласен). А вот некоторые советы выглядят весьма спорными.
Уважаемый автор, вы лично пробовали проводить эти упражнения?
Например с командой более
1) Упражнение «расскажи о себе». ...
2) Упражнение «эффективность команды». ...
3) Упражнение «Обратная связь». ...
Давайте немного определимся.
Под словом менеджер чаще всего подразумевают позицию (место в орг. структуре), область ответственности в производственном процессе и право принимать решения по ресурсам компании (такие как деньги и время сотрудников — на что их тратить).
Менеджер Проекта — это обычно РОЛЬ, и для небольшого проекта времени на исполнение обязанностей по этой роли надо совсем немного (от часа в неделю до пары часов в день). Для полной загрузки ПМа нужно где-то
Судя по вашим комментариям — роль ПМ-а у вас выполняет ТехЛид (молодец, что тут скажешь), а ПМ у вас просто недозагружен работой (ну или вам так кажется :-)
Не принимайте близко к сердцу — проекты бывают большие, а менеджеры (ПМы?) бывают хорошие :-)
А зачем оркестру дирижёр? Ведь скрам шагает по планете... У музыкантов что, нот нету? Договориться не могут?
А взять вас на работу кто решил? С кем вы зарплату и условия обсудили? Кто обосновал, что ваш проект вообще нужно делать и [о Боже!] тратить деньги на вашу зарплату? Кто расписал цели, бюджет, и финансовую отдачу — бухгалтер, программисты?
Пока вы работаете один, вам точно нахлебников не надо. Когда людей становится несколько, их усилия уже нужно координировать (а для начала обосновать, что этот труд вообще кому нибудь нужен и определить откуда деньги возьмутся).
Цікаво, все-таки, людей взяли на роботу напряму у компанію-власника продукту і дали частку власності (акції, опціони), чи все так і залишилося на рівні мотиваційних ритуалів (презентації, опитування, дискусії, бонуси за досягнення), але той самий контракт на надання консультаційних ІТ послуг?