Pull to refresh

Comments 37

Хм, статья интересная безусловно, спасибо.
Принципы звучат отлично, но надо понимать их применение к реальности. Например, пример про собственные KPI — показателен. Например, компания нанимает менеджера на фикс и бонусы от KPI, при этом бонусы от проектов — могут быть 50% и выше, и будут только при условии соблюдения KPI. Надо думать, что разумный человек вряд ли пойдет на встречу команде — он играет по другим правилам, которые ему навязала компания. А внутри компании от него разрабы бегут как от огня — зная, что он всех принуждает к переработкам и людей держит за расходный материал.
Другой вариант — KPI менеджера зависит от процента проектов. Есть проекты и заказчики — менеджер получает деньги, нет (или мало) проектов и заказчиков — денег (почти) нет. Надо понимать, что в этом случае задницы заказчиков будут вылизаны до блеска, а команда опять останется с носом? В итоге — косяки менеджмента компании выдаются за косяки ПМов.

С менеджерами из разработки тоже не все так просто. Я сам люблю писать пример о Королеве, но есть и другой пример.
Канал Эри.
В конце 17 века город Нью-Йорк представлял из себя небольшой городок, и говорить о том, что этот поселок городского типа будет известен на весь мир, было бы все равно что говорить о том, что Сызрань через 100 лет станет самой развитой столицей.
Дело в том, что экономика обмена в тот момент была такова, что перевозить товары было выгодно по реке, спуская их на юг, а не через Нью-Йорк — сухопутный путь был долог и дорог. От постройки канала федеральное правительство отказалось, президент и множество известных в то время людей не верило в возможность постройки, и казалось бы на этом все должно было закончиться — но история распорядилась иначе. Город использовал собственные деньги на строительство, а во главе проекта стояли… два судьи и школьный учитель. Двое из них, на тот момент, не имели никакого представления о строительстве каналов, третий же имел небольшой опыт инжинеринга. В результате — канал построен (на тот момент второй по величине в мире), стоимость перевозки товаров к Атлантике была снижена примерно в три раза, население Нью-Йорка выросло вдвое за десять лет. По ходу проекта, все трое прокачали инженерные навыки, доработали гидроцемент и поставили на ноги сферу строительства подобных объектов в США. Всю эту эпичную историю можно прочитать в Wiki.

В общем, ПМ должен понимать боли разработки (и тестирования, и внедрения, и аналитиков, и заказчиков/спонсоров, и руководства, и государства и т.д.), понимать как делаются оценки, тестирование и рефакторинг и еще очень много всего. Но, это не значит что ПМ всегда разработчик — ПМ выстраивает отношения между собой и командой, а хороший ПМ выстраивает отношения еще и внутри команды, а как высший пилотаж — еще и между командой и руководством (хороший показатель, когда тиммемберы начинают разговор об увольнении с ПМа — это значит между ними есть доверие). Про отношения с заказчиком даже говорить не буду — просто нормальный ПМ не допустит общения заказчика с участниками вида «хочу так, делайте, я же деньги плачу», да и вообще управление заказчиком позволяет избежать такого подхода.
Отличное дополнение, спасибо!
нормальный ПМ не допустит общения заказчика с участниками вида «хочу так, делайте, я же деньги плачу», да и вообще управление заказчиком позволяет избежать такого подхода
Распространённая ситуация, да. Особенно неприятно, когда заказчика по своим соображениям чуть ли не в команду внедряют, а он пользуется этой ситуацией и продавливает требования, например, сверх оплаты. Это очень сложный пункт взаимодействия. Тема не одной статьи.
Хороший ПМ на проекте — хозяин. И с Заказчиком ему общаться интересно, и команду он не пускает к нему — не только потому, что З умеет давить, но и потому, что команда тоже может наобещать с три короба (ой, мы сейчас верификацию номера телефона сделаем, там на полчаса, а потом выясняется что надо архитектуру БД перекраивать, а заказчик сидит и ждет — ему же представитель исполнителя обещал).
Просто именно ПМство как искусство управления стейкхолдерами у нас слабо развито. Либо технические люди, кто не привык быстро ответственность брать в условиях неопределенности на себя, либо функциональные менеджеры, привыкшие к системе «я начальник, ты дурак» и не умеющие договариваться и искать win-win. Статью пилите, интересно будет почитать )
Насчет учебы — могу даже отдельный коммент написать.
Найти наставника — хорошо, если в компании есть сильный менеджмент — для ПМа это проектный офис, с среднесрочным и долгосрочным планированием ресурсов и проектов, с хорошей методологией. Я таких видел немного, но видел. В разработке — это самый грамотный способ, в менеджменте (особенно в ПМстве) надо будет скорее всего не одну компанию обойти.
Книги — вариант наверное для людей, способных прокрутить проект от начала до конца в голове во всех деталях. Обычным людям лучше сломать грабли на 2-3 проектах. Ну и смотрите материалы (и порталы) на английском (и немецком) — они как правило годные. Группы в телеграме тоже в помощь — насоветуют митапов на тему, будет что обсудить.
3. ВВ — по менеджменту — зверь редкий, магистратура — тоже мало что дает, шанс найти что то стоящее за пределами Москвы стремиться к нулю. Про фишечку ВУЗов — отмечено совершенно правильно, руководству ВУЗа надо по программе, преподаватели очень часто не видят дальше собственного носа, считая себя экспертами без единого дня опыта работы в сфере (да, у меня преподавали экономику те, кто работал после вуза преподавателем сразу, и разработку те, кто не работал ни над одним боевым проектом в группе). Опять же про курсы — мало людей умеет хорошо делать дорогие проекты, но предпочитает вместо этого тратить деньги на курсы. Встречал одни, достойные курсы после которых можно выпускать ПМа в поле под внимательным присмотром, но не более того.
4. MBA — сам думаю, но пока мысли следующие — для работодателей это не принципиально, самостоятельно можно несколько сотен часов потратить на обучение гораздо более эффективно.

И напоследок — о бедной зарплате замолвите слово. Хороший разработчик (синьор или лид) получает выше менеджера проекта, с гораздо меньшим геммороем (обычно нет командировок, оплачиваемые переработки, нет перманентных стрессов от давящих дедлайнов и заказчиков) и гораздо более светлым будущим — таков спрос на рынке. Так что всем, кто думает перейти из SD в менеджмент — с точки зрения поднятия доходов это плохая идея. Только по велению сердца.
С последним абзацем я бы поспорил.
В нашей стране традиционно сложилась ситуация, что самый захудалый начальник получает больше чем самый сильный разработчик. Я видел только одно такое исключение из этого правила, но там один разработчик фактически держал в заложниках отдел.
Не знаю как в стране, но во всем мире наблюдаю одну и ту же ситуацию — как заплачено, так и сделано.
Если к тебе пришел хороший разраб, даже не важно джун или миддл или синьор и ты его взял к себе в команду, будь добр — мотивируй его работать. Если не можешь сделать это без денег (а в 95% случаев так и есть) — плати. Не будешь платить — человек будет шастать по собеседованиям, учить не относящиеся к работе фреймворки, в лучшем случае — сделает тебе фичу на том стеке, который интересен лично ему. Будешь платить — человек будет фигачить, что бы не потерять хорошее место.
С менеджерами ситуация еще хуже — мало того, что они знают ЗП команды, они еще часто знают ЗП в других командах. Однако очень часто руководство компаний думает что достаточно мотивировать только команду, а менеджер и так мотивирован. Ага, если бы.
Конечно, менеджеры и команды есть разные. Есть команды типа звезды разработки и обычный ПМ, есть звезды разработки и менеджмента (редко встречал), есть обычные разработчики и сияющий на их фоне ПМ (самый фиговый вариант).
Самый лучший вариант — нормально оплачиваемый ПМ, выбивающий у руководств ставки своей команде, взамен дающих руководству проекты в срок и в бюджете. Это мечта всех, но такой ПМ дорогого стоит, да и найти еще его надо.
UFO just landed and posted this here
Грустно, это когда мешки из СТ живут в центре в трехкомнатной квартире, а ты с двумя детьми в однушке из Жуковского каждый день по 2 часа туда и 2 обратно ездишь.
Когда я слышу фразу «в нашей стране...», всегда хочется спросить — а вы в какой-нибудь ещё стране работали? Хотя всегда очевидно, что нет.
Кстати, насколько велика ваша статистическая база, чтобы утверждать — вы много ли знаете зарплат началтьников и разработчиков, чтобы делать такие обобщения?
Ну и вообще-то это достаточно логично, что руководитель оплачивается выше, чем люди им управляемые. Довольно глупо ставить пустышку на управление ценными кадрами. Как руководитель проектов с 20летним опытом — да, я знаю стоимость своих ресурсов и руководителей в том числе — да, я всегда на управление ставлю более дорогих и опытных. И все мои коллеги поступают также.
а вы в какой-нибудь ещё стране работали?

Я не очень понимаю смысл вашего выпада. Это было бы объяснимо, если исходная фраза содержала бы посыл что я бы утверждал о чем то, о чем я не могу иметь понятия, к примеру «В Буркино-Фасо дела обстоят следующим образом».
Но так как фраза «в нашей стране» очевидно относиться к стране которую я считаю своей домашней, и могу с уверенностью делать утверждения основываясь на собственном опыте, то ваши слова мимо цели.

насколько велика ваша статистическая база

Достаточна для того что бы я мог позволить себе делать подобные выводы основываясь на своем опыте. Если у вас есть другие примеры, то не стесняйтесь, расскажите, будет интересно послушать.
Я к тому, что это вполне логичная практика на управление ставить более дорогие ресурсы, чем на исполнение. И она не зависит от страны. По тому не понятен акцент на нашей стране.
Про статистическую базу был вопрос в сторону, т.к. выводы правильные.
«Я видел только одно такое исключение из этого правила, но там один разработчик фактически держал в заложниках отдел.» — кстати, вы подтведждаете мои слова :-) Если руководитель допускает, что один человек держит в заложниках весь отдел — это очень плохой руководитель. И логично, что он дешёвый. Надо было взять нормального. Эта ситуация недопустима с точни зрения управления и обходится сильно дороже зарплаты начальника. Гнать его надо.
«Гнать» — сильно сказано, но исправлять ситуацию необходимо.
а может это сам руководитель навалил на сотрудника две-три должности сразу, а тот вместо того, что выгореть и требовать саббатикал — всё тянет и тянет 16 часов в день без выходных за одну зарплату?
Он не дешевый, он нормальный. И попытки изменить ситуацию были, вот только безуспешно. Там был очень сложный клубок политических игр, и непосредственный начальник мало что мог сделать. А генеральный как то отказывался выгнать сам себя.
Я сам был в ситуации, когда мой архитектор меня шантажировал тем, что у него в руках все ключи от решения. Это очень плохо со всех сторон. В итоге мы с ним расстались. Не уволил и не обидел, а просто я его больше не брал в свои проекты. Работает команда, а не одинокие светила. Ничего, все проекты делались и без него и успешно и веселее атмосфера в команде. Он тоже не в обиде — нашёл себе занятие.
Если менеджера больше ответственности и он управляет ресурсами то и получать он должен больше подчиненных.
Так то оно так, но вот людей, способных взять на себя ответственность и управлять ресурсами — много. А людей, способных спроектировать и реализовать ядро сложного и современного, конкурентоспособного приложения — мало, ой как мало. Это рынок.
Моё ощущение рынка другое. Я в разных проектах выступал и архитектором и руклем. Архитекторить интереснее. Но спрос на РП выше. Нет проектов без руководителя. А без архитектора вполне достаточно.
Хм, проектов без архитектора нет, но вот продукты есть (а ПМы так вообще там не нужны). Если именно как software architect — очень странно, что спроса нет, казалось бы любой банк и интегратор забирают за любые деньги (особенно, Java). А вот РП не так нужны в разработке — работать без них можно, например по scrum, и в банках они почти не нужны. С Head of PMO ситуация еще хуже — если проекты разные, команды большие и ПМы самостоятельные — хэда им не берут.

Я не сказал что спроса нет. Спрос есть и на тех и на этих. Вообще спор ни о чём. По моим СУБЪЕКТИВНЫМ ощущениям В МОЁМ СЕГМЕНТЕ рынка ищут пиэмов постоянно, а архитекторов периодически. То есть, если я сейчас встану со стула, то сразу могу выбирать куда я завтра пойду пиэмить, а архитекторской позиции надо будет подождать месяца два. Но в других сегментах рынка всё может быть иначе. В скраме нет пиэма, но есть скрам-мастер, что тоже управленческая позиция, аналогичная пиэму.

Понятно, у меня, увы, наоборот — ПМить идти на реально хорошие условия — надо поискать, зато звонят с предложениями поархитекторить, хотя я не архитектор ни разу.
Про скрам-мастера — вопрос сильно спорный, в правильной скрам команде мастер близко на ПМа не похож, роли у него совсем другие — коучить команду фреймворку, следить за временем. Но не указывать что делать, и точно — не брать ответственность на себя, это явно прописано в scrum guide. Но в плохих командах, да, СМ и жнец, и чтец, и пофронтендить может, и протестить, и на скраме, и на уотерфолл, и еще и полы помоет после работы.
никогда не понимал — в чём состоит мифическая «ответственность менеджера»? Он что, зарплаты и премии лишится в случае провала проекта? Нет, нисколько, штрафуют только рядовых сотрудников. Может, его в должности понизят? Нет, только повысят, провал — это же опыт и все такое. Или его невнятное блеяние на отчётном совещании в духе «это мои плохие сотрудники не справились» — это ответственность?
Ну по опыту могу сказать, что менеджера меряют закрытыми проектами. Много хорошо сделанных, закрытых проектов, которые ты можешь подтвердить — платить будут хорошо (много и часто). Проектов закрытых и хороших нет — блеять менеджер будет уже на собеседовании.
Как правило, референсы может дать не только заказчик (пусть мы ему все вылизали в ущерб собственной компании), но и текущий работодатель — если менеджер нормально делал проекты, а потом ушел и теперь просит референс-колл — почему бы и нет? Серьезные западные компании при найме обязательно просят контакты бывших работодателей (не обязательно директора, это может быть и Head of PMO) и заказчиков (менеджер проекта со стороны очень даже ок).
Даже скучно. Каждый свою работу считает важнее других. Такие фразы я слышу каждый день. Искусство менеджера состоит в том, что из 20 человек, от которых он в любой момент готов услышать подобное, он должен выстроить работоспособную команду и достичь результата в срок и в бюджет и с должным качеством. А так фигня, больше ничего делать не нужно.
При этом надо учесть, что управляет он не землекопами, каждого из которых можно заменить за полчаса, а высококвалифицированными индивидуалами, замена каждого из которых займёт минимум полгода и стоит много денег и сроки будут «просрачены». И каждый норовит делать то, что он считает интересным и ему скучно учитывать общие сроки и цели. А чтобы понять что он делает и убедить делать то, что нужно, а не то, что интересно, нужно обладать квалификацией сопоставимой с ним. И если это 20 человек разного профиля, то руководителю нужно иметь ого-го какую квалификацию.
Насчет команды, и замены ее участников — это верно. Выше, я писал, что ПМ — это в идеальном мире, тот человек к которому люди приходят поговорить об увольнении. И не писал, подразумевая, что это должен быть тот человек к которому приходят за прибавкой, с косяками, за отгулами и т.д. И, да, в СД не работает — иди и реши задачу. Работает — давайте сядем и разберемся, что НАМ нужно сделать, что бы мы завершили проект и что мы получим с этого (бонусы, экспириенс, повышения и т.д.). Менеджеров, которые просто говорят иди и делай — я в приличных местах не встречал давно даже не в ИТ. Но и разрабов, которые бы делали только то, что интересно им я встречал нечасто (хотя да, смузихлебов, занимающихся изучением нового фреймворка, вместо скучного багофикса и работы с легаси за деньги заказчиков хватает).
Конечно, все эти качества редко сочетаются в одном менеджере, но каждое из них уже способно пошатнуть проект на пути к цели.

мне иногда видится, что в любом реальном «типичном менеджере» можно найти одновременно десяток из этих моментов.
Мы смягчили формулировки :-) Всякое встречается. Но если человек настроен на развитие в ИТ, осваивает новое, вникает во всё, то дело пойдёт и многие негативные стороны могут довольно быстро «искорениться».
Первый раз слышу, что для управления ИТ проектами нужно МВА. Хотя я сам имею квази-МВА и руковожу проектами 20 лет. Если вы руководите внедрениями серьёзных ERP систем, где требуется предметно спорить с главбухом, главным экономистом, главным финансистом крупной компании — то знания, входящие в МВА будут полезны, но и то не будут определяющими. А уж если вы управляете разработкой софта для микроконтроллера дрона — простите, зачам вам МВА? Максимум РМВоК проштудировать — и вперёд!
Мы живых MBA в команде не держим :-) Но опыт обучения есть (брошено вовремя). Почему это оказалось дурной затеей, если не сказать хуже:

  • слабый преподавательский состав: дешёвые бизнес-тренеры (и дорогие тоже так себе), практики, неспособные связять три слова, вузовские преподы с книжками 1997 года в 2017
  • ненужные предметы в программе
  • непрофильность программы
  • очень слабые кейсы и практические работы
  • много болтовни
  • кос-ми-чес-кие цены.

Может, международное MBA и круче, и толковее, и все карты в руки даёт, но тратить на это время и деньги — сюрреализм какой-то.
Про МВА — напишите, битте, в личку куда ходили — сейчас как раз думаю пойти. Не рекламы для, а продолжения разговора ради — интересовался управлением проектами в вышке
Скажу что у меня фид положительный, учат не только планы-графики в проджекте делать и диаграммы рисовать (но и этому учат, курсы ведут PMP/CSM /PMI-ACP etc), но и полезным для руководителя скиллам — конфликтологии, управлению ожиданиями, и т.д. Приятный плюс — приглашенные с реально крупных и известных компаний эксперты и экзотика типа lean'a. Никаких книжек 97 года нет, матан так же присутствует в необходимой концентрации. С кейсами — полный порядок, живые и разнообразные, из практики, они в общем то и являются критерием приемки работ.
Объективный минус — деньги, 600к — организация, наверное, может это вычесть из налогов, а вот частное лицо не способно потратиться.
По деньгам в НН меньше. Подробности в личке.
Сейчас есть прекрасные он-лайн курсы от лучших универов мира на той же курсере, зачем протирать штаны на лекциях? Выбираете что вам нужно и не тратите время на прочее бла-бла. И стоит копейки.
Тот случай, когда не хватает Мегамозга.
Вам-то? Сочувствую, трудно без мозга. А уж без мега…
Так, коллеги, стоп флейм. Ирония по поводу Мегамозга полностью неуместна, поскольку статья касается непосредственно карьеры в ИТ-сфере. На этом весёлую дискуссию закрываем.
Перечетал статью еще раз, признаю свою ошибку.
Я думаю на не негативный настрой меня настроило первое предложение в статье:

Мир IT сегодня не похож ни на одну из других отраслей — над кодом приложений, игр, корпоративных решений, сервисов работают увлечённые, грамотные ребята.

Я долго пытался понять смысл этого предложения.
Если имелось ввиду, что только в IT работают увлеченные, грамотные ребята, то здесь очевидное противоречие. Есть и другие отрасли, где работают в основном грамотные ребята (строительство, инженерия и т.д).
Если имелось ввиду, что наличие кода отличает эту индустрию от других, то это и так очевидно. Таким образом любые другие отрасли не похожи друг на друга (в каждой отрасли есть свои уникальные характеристики).
Принято. Вероятно, мы не дожали мысль — имелась ввиду не отстройка от остальных отраслей, а именно акцент на том, что в ИТ сейчас работают буквально фанаты, готовые и к вызовам, и к самообразованию, и добровольно ночами кодить :-) Всё же мы не филологи, красивый текст — не наша фишка, мы больше по красивому коду.
Sign up to leave a comment.