Мир IT сегодня не похож ни на одну из других отраслей — над кодом приложений, игр, корпоративных решений, сервисов работают увлечённые, грамотные ребята. Программисты и инженеры, дизайнеры и тестировщики, системные администраторы и новомодные DevOps превращают идеи в программное обеспечение, которым пользуются миллионы людей. Они вдохновенно пишут код, разрабатывают алгоритмы, готовят макеты и соединяют это в работоспособные полезные механизмы. Мы, пользователи Хабра, часто говорим о разработке, администрировании, новых технологиях и языках программирования, зарубаемся в жарких спорах о преимуществах одного стека над другим, но забываем о важном звене в любой IT-компании — менеджерах проектов и продуктов. А между тем не факт, что завтра именно вам не предложат отойти от дел программерских и стать менеджером. Мотивация? Стоит ли? Потолок? Карьерный тупик? Новый горизонт? Давайте разбираться.
Мы внедряем свою CRM-систему и поэтому имеем не только опыт развития своих собственных менеджеров (это, в основном, гибриды с програмистами — ближе к тимлидам) в RegionSoft Developer Studio, но и встречаемся с чужими менеджерами ИТ-проектов (и не ИТ тоже, но это другая история). За много лет нам удалось выявить ряд типичных признаков менеджеров «с плохим характером».
Увы, часто случается так, что в менеджеры ИТ-компаний попадают люди с неплохим экономическим, юридическим, управленческим образованием, но без знания технического бэкграунда. Они могут стараться, применять психологические приёмы, посещать тренинги и проводить ультра длинные совещания, но получать не только нулевой результат, но и зарабатывать ненависть в компании. Программисты считают менеджера бездельником, менеджер опасается озлобленных технарей. И на то есть основательные причины.
Конечно, все эти качества редко сочетаются в одном менеджере, но каждое из них уже способно пошатнуть проект на пути к цели. Тем не менее, это не утопия — такие управленцы встречались в работе практически каждому из нас. Какой выход? Вырастить Бабу-Ягу в своём коллективе и перевести в менеджеры лучшего программиста, знающего проект до каждого символа кода? Вариант! Но так ли это просто — пересесть из кресла программиста или инженера в кресло менеджера?
Если говорить о карьерных сдвигах хорошего, очень хорошего и талантливого программиста, то нельзя сказать об однозначном преимуществе роста в менеджеры. Есть несколько путей развития для программиста, который вырос в проекте до профессионального максимума.
Переход из разработчиков в менеджеры разработки — это карьерный рост с точки зрения и общества, и руководителя, и коллектива. Это повышение заработной платы, новые задачи и новая ответственность. Но разработчик не всегда готов забросить код и приступить к новым обязанностям — хотя бы просто потому что программировать ему нравится гораздо больше. Эта позиция заслуживает огромного уважения (и повышения зарплаты — да-да, господа руководители, это свидетельство почти что патологической лояльности продукту и оно дорого стоит!), но мы всё же остановимся на более распространённой ситуации: зарплата манит, новые задачи будоражат и вы почти согласны стать менеджером, но с чего начать? Как встать на этот путь и стать на нём эффективным, а не попасть в ловушку принципа Питера?
Менеджер в ИТ — это почти всегда человек-оркестр. Но всегда ли слаженно он играет?
Любая смена деятельности как внутри компании, так и вне её — это определённый стресс, сопряженный с множеством вопросов и сомнений. Даже если вы знаете проект много лет, всё равно вам предстоит посмотреть и на него, и на команду с другой стороны, обратиться к новым сторонам взаимодействия, стать руководителем своих коллег, стать лидером. Важно сразу осознать несколько моментов, которые помогут собраться и приступить к работе «с той ноги».
Как по мне, нет причин для беспокойства
С автоматизацией можно перестараться. В теории. На практике ощущается вечная недоавтоматизация.
И да, вам придётся столкнуться с этой картинкой в жизни :-)
Главное — очень-очень любить свой продукт. Иногда, конечно, вопреки :-)
Итак, вы менеджер. Долгое время вы были разработчиком, инженером, многому научились в проекте. Теперь вы получаете новый опыт, ответственность и деньги в обмен на огромный объём работы, много давления и необходимость принимать сложные решения. Вы видите возможности и можете влиять на развитие бизнеса.
Есть несколько вещей, которые нужно принять в роли менеджера: риски, умение прислушиваться к критике и реагировать на неё, новая мера ответственности, умение принимать жёсткие и иногда непопулярные решения. Придётся стать лидером своей же команды. Впрочем, если вы доросли до менеджера разработки, скорее всего, вы уже были неформальным лидером.
Главный страх менеджера, бывшего в недавнем прошлом разработчиком, — это потерять квалификацию, технические навыки, отстать от нововведений в стеке. Этот страх оправдан, но зависит всецело от вас. Менеджер должен быть на острие технологий и максимально разбираться во всех инструментах. Благо сейчас информации очень много и она легко доступна.
Но каким бы крутым программистом вы бы ни были, заступая на работу менеджером, необходимо много учиться нюансам и тонкостям работы. Есть несколько способов получить квинтэссенцию чужого опыта и стартовать быстро.
Можно выбрать наставника, можно углубиться в учебники и книги, и это правильные решения. Но это и потеря времени. Поэтому лучше поучиться — но вопрос, где. MBA — это долго, дорого и, увы, далеко не всегда то, что нужно. Поэтому стоит обратиться к другим возможностям получить квинтэссенцию чужого опыта.
Но в целом все способы хороши, особенно если их смешивать с толковыми книгами и блогами реальных практиков ИТ-менеджмента. Главное, помнить, что вы должны стать лидером, а не
«айти-бюрократом».
Наш пока живой Телеграм-канал BizBreeze. Всякое про CRM и бизнес, по уму, без копипаста и на 90% без рекламы. Подписывайтесь.
Менеджер в айти, бэклог его ити…
Мы внедряем свою CRM-систему и поэтому имеем не только опыт развития своих собственных менеджеров (это, в основном, гибриды с програмистами — ближе к тимлидам) в RegionSoft Developer Studio, но и встречаемся с чужими менеджерами ИТ-проектов (и не ИТ тоже, но это другая история). За много лет нам удалось выявить ряд типичных признаков менеджеров «с плохим характером».
Увы, часто случается так, что в менеджеры ИТ-компаний попадают люди с неплохим экономическим, юридическим, управленческим образованием, но без знания технического бэкграунда. Они могут стараться, применять психологические приёмы, посещать тренинги и проводить ультра длинные совещания, но получать не только нулевой результат, но и зарабатывать ненависть в компании. Программисты считают менеджера бездельником, менеджер опасается озлобленных технарей. И на то есть основательные причины.
- Работа без цели, плана и этапов проекта. Такая ситуация может возникнуть, если менеджер плохо представляет себе этапы разработки и вообще процесс создания программного обеспечения, то есть фактически ему просто трудно адекватно планировать. Сумбурная работа, метание от задачи к задаче, постоянно изменяющиеся требования выматывают всех членов команды, приводят к увольнениями и профессиональному выгоранию.
- Изменение проекта на лету — ещё одна ненавистная черта менеджера. Вы легко узнаете этот тип работника: услышав на конференции или очередном митапе о новой технологии или модных моделях управления, он возвращается в компанию с горящими глазами и начинает активно продавливать новинку на старом проекте. Причём это не эксперимент с лучшими практиками, а именно тотальное и безоглядное погружение во что-то новое. По ощущениям — больше макание. Приводит к срывам срока проекта и резкому падению качества и скорости разработки. Если горе-новатор умудряется заручиться поддержкой топ-менеджмента — пиши пропало.
- Стратегия любой ценой — девиз менеджеров ИТ-проектов, работающих на свой собственный бонус, но не на благо команды. Такие ребята готовы на всё ради KPI и ROI и исключают любые риски, лишь бы не потерять заветные значения коэффициентов. Самый опасный вариант, когда менеджер лоббирует внедрение в матрицы показателей коэффициенты, связанные с «нетрудовыми» достижениями — такие как коэффициент лояльности, показатель внутренней мотивированности и оценочный уровень взаимодействия с коллегами. Как правило, профессионалы-интроверты сквозь это решето не проходят и остаются без премий. А там и без мотивации, и… без работы.
- Непонимание принципов разработки — бич менеджеров-нетехнарей. Не зная особенности создания кода, скорость работы программистов, принципы тестирования, сроки выведения продукта в продакшен, крайне трудно прийти к общему знаменателю с R&D и стать настоящим связующим звеном внутри проекта. Именно такие менеджеры любят заучить несколько словечек ИТ-тематики и говорить: «Успеешь фичу до пятницы?», «Отрефакторь код, чтобы быстрее работало», «Да там всего две строчки поменять. Зачем весь билд тестировать?».
Некоторые менеджеры так и думают, что на входе какая-то идея, на выходе величайшее в мире ПО, а посередине — магия. Не-а, обычно великая идея, долгая-нудная-сложная разработка и продукт, который ещё и конкуренты опередили. И вот как раз классный менеджер и толковые разработчики этот продукт ведут к GREAT :-) - Совещания без конца — отличный способ имитировать деятельность, не достигая при этом результата. Главное, чтобы был календарь резервирования переговорок (желательно, публичный), а сам менеджер с важным видом заслушивал состояние дел на проекте и давал комментарии. Если постараться, то можно назвать эту имитацию Scrum или Agile. Но тогда обязательно должна быть доска с цветными бумажками. Это менеджер-совещанец усвоил.
- Клиент всегда прав, даже когда точно не прав. Почему-то волшебная формула «клиент всегда прав» из ритейла и сервиса перекочевала в том числе в разработку. Менеджер, призванный работать в том числе на стороне клиента, превращается не в адвоката клиентских интересов, а в кивающего божка, таскающего самые бредовые задачи от клиента с пометкой срочно-важно. И, конечно же, без составленного и подписанного ТЗ.
- Игнорирование личностных аспектов — ошибка, которую может допустить любой менеджер, в том числе технарь. Ни в коем случае не стоит игнорировать тот факт, что вы работаете в окружении людей — а значит, в окружении личности, характера, настроения, мотивации. И если не учитывать эти особенности внутри команды, можно получить эффект ядерной мини-бомбы внутри коллектива. Заденет всех.
- Неумение расставлять приоритеты приводит к однозначным срывам сроков проекта, сумбурности в разработке, брошенным делам, неразобранному бэклогу и переполненному багтрекеру. Разработка как любое инженерное дело не терпит хаоса.
- Тотальный контроль и микроменеджмент — болезни управления, которые могут напасть на каждого. Нет ничего хуже, чем менеджер. стремящийся заменить каждого на рабочем месте и готовый влезть в каждый этап разработки.
- Отсутствие ретроспектив — отличный способ снизить мотивацию команды и качество разработки. Если менеджер по какой-то причине избегает анализа ошибок, проделанной работы, боится похвалить или призвать к качественным изменениям, он неизбежно получит команду, не знающую, каким курсом она движется.
- Игнорирование лучших практик. Чужие успехи, находки и преимущества порой трудно признать. Однако в работе подобное поведение фатально — если не принимать во внимание лучшие практики, можно отстать от конкурентов и по сути потерять все преимущества. Если менеджер боится признать лучшее и активно внедрять это, проект обречён.
- Есть ещё один аспект работы менеджера, приводящий к негативным последствиям, — стремление создать дружную команду даже в ущерб эффективности и продуктивности. В погоне за комфортным психологическим климатом в коллективе и полной неконфликтности менеджер загоняет проект в ранг «дружеской посиделки», на которой всем хорошо, но работа не делается. Рано или поздно это обязательно приводит к конфликтам и глубокому управленческому кризису.
Конечно, все эти качества редко сочетаются в одном менеджере, но каждое из них уже способно пошатнуть проект на пути к цели. Тем не менее, это не утопия — такие управленцы встречались в работе практически каждому из нас. Какой выход? Вырастить Бабу-Ягу в своём коллективе и перевести в менеджеры лучшего программиста, знающего проект до каждого символа кода? Вариант! Но так ли это просто — пересесть из кресла программиста или инженера в кресло менеджера?
Из программистов в менеджеры — путь самурая
Если говорить о карьерных сдвигах хорошего, очень хорошего и талантливого программиста, то нельзя сказать об однозначном преимуществе роста в менеджеры. Есть несколько путей развития для программиста, который вырос в проекте до профессионального максимума.
- Сменить компанию и получить новые задачи в рамках нового проекта — самы простой, но часто самый нежелательный для всех исход. Давайте забудем о нём до других постов.
- Сменить проект внутри своей компании и развивать новое направление — отличный вариант, выгодный компании и мотивирующий разработчика. Но не в каждой компании ведётся параллельная разработка нескольких проектов, такой возможности может просто не быть.
- Продолжать расти на своём месте, углубляясь в оптимизацию разработки, наращивая функциональность продукта, совершенствуя его через рефакторинг и использование новых алгоритмов и технологий. Отличный вариант, который чаще всего и выбирают лучшие программисты.
- Стать менеджером — в том случае, если программист проявляет управленческие черты и очевидно готов взвалить на себя груз проектной работы, а разработку доверить своей же команде.
- Стать технологическим евангелистом — для очень крупных компаний или для очень редких и ультра популярных продуктов.
Особое мнение — главный разработчик RegionSoft Developer Studio рассказывает о своём опыте работы с менеджерами и программистами.
На мой взгляд, программисты и менеджеры — это совершенно разные сущности, которые практически противоположны друг другу. Я не знаю ни одного программера, который стал бы хорошим менеджером. Руководителем отдела разработки, тимлидом — да, а чтобы работать в том числе на продвижение и работу с клиентами — не знаю таких. Программисты действительно достаточно пассивны в плане общения — нередко молчаливые, упёртые, суровые интроверты, немногословные, не любят, когда их дергают и сами дергаться тоже не любят. Менеджер должен быть экстравертом, любить общаться, решать задачи, планировать и проявлять инициативу — конечно, рядом с психотипом большинства программистов, это категорически разные типы.
Но есть одна важная фишка. Если в человеке сочетаются черты и программиста, и менеджера — то из такого сотрудника получается идеальный руководитель проектов или даже менеджер экспертного уровня. Но такое встречается крайне редко.
Менеджер экспертного уровня — это всегда звезда в любой команде, потому что он и умеет работать «продвиженцем» и знает предмет вопроса изнутри. Это как Королев, когда он возглавил КБ для разработки ракеты. Если бы он сам эти детские ракетки и самолёты не запускал и не конструировал, он бы никогда не смог управлять целым КБ и не создал бы ракету, способную покорить космос.
От менеджера нужны лидерские качества, чтобы сплотить вокруг себя команду и суметь ей управлять, ставить задачи, планировать достижение промежуточных результатов и т.д. И, безусловно, в разработке ПО, в технической сфере это особенно важно.
Так что, если программирование — ваше всё и душа не лежит к менеджерской работе, не переходите. Хороший, талантливый разработчик всегда найдёт точки роста внутри любимого дела и своего проекта.
Переход из разработчиков в менеджеры разработки — это карьерный рост с точки зрения и общества, и руководителя, и коллектива. Это повышение заработной платы, новые задачи и новая ответственность. Но разработчик не всегда готов забросить код и приступить к новым обязанностям — хотя бы просто потому что программировать ему нравится гораздо больше. Эта позиция заслуживает огромного уважения (и повышения зарплаты — да-да, господа руководители, это свидетельство почти что патологической лояльности продукту и оно дорого стоит!), но мы всё же остановимся на более распространённой ситуации: зарплата манит, новые задачи будоражат и вы почти согласны стать менеджером, но с чего начать? Как встать на этот путь и стать на нём эффективным, а не попасть в ловушку принципа Питера?
Менеджер в ИТ — это почти всегда человек-оркестр. Но всегда ли слаженно он играет?
Что нужно осознать?
Любая смена деятельности как внутри компании, так и вне её — это определённый стресс, сопряженный с множеством вопросов и сомнений. Даже если вы знаете проект много лет, всё равно вам предстоит посмотреть и на него, и на команду с другой стороны, обратиться к новым сторонам взаимодействия, стать руководителем своих коллег, стать лидером. Важно сразу осознать несколько моментов, которые помогут собраться и приступить к работе «с той ноги».
- Должность менеджера — это рост для программиста, новый виток развития в сфере управления. Когда разработчик достиг практически всего в коде, ему стоит шагнуть дальше и управлять именно так, как того проект требует. Когда знаешь процессы разработки и особенности продукта изнутри, ты способен изменить многое в управлении, сделать команду по-настоящему сильной. Бонус за все риски — новые задачи и материальная сторона.
- Переход в менеджеры — способ преодолеть достигнутый карьерный потолок. Особенно это важно для тех специалистов, которые хотят развиваться внутри своей компании, а не менять работу. Это способ применить накопленные знания в новом качестве.
- Менеджеру проще перейти на высокооплачиваемую работу в другую компанию, поскольку программист должен вникать в код, стиль разработки, разбираться с не всегда лучшим «наследством» от предшественника, а менеджер приходит со способностью грамотно управлять проектом, понимая разработку, но тратя время на разгребание кучи кода. Он изначально эффективен (хотя не факт, что разборки с кучей отменяются!).
- Став менеджером, следует избежать микроменеджмента и перестать вникать в мельчайшие особенности разработки, в каждую строчку кода, — нужно дать возможность команде решать задачи разработки. Однако часто менеджер, выросший из программиста, продолжает просматривать билды и отдельные коммиты, нередко даже сам продолжает писать код. однако рано или поздно объём серьёзных менеджерских задач вытеснит такую возможность, поэтому важно правильно выстроить делегирование в команде.
- Менеджер — это не айтишный бюрократ и не боец на тёмной стороне. Это человек, который способен применить свой опыт для того, чтобы сделать живой идею продукта, создать ПО, которым можно пользоваться и которое способно приносить пользу.
- Менеджер — это человек, работающий с людьми, и это не стоит сбрасывать со счетов. Ваша новая работа — это непрерывный процесс взаимодействия с руководством, клиентами и, конечно, командой. Важно обеспечить благоприятную рабочую обстановку, научиться управлять совершенно разными людьми и при этом не скатиться в развесёлую компашку или, наоборот, в запруженное болотце только «нужных и спокойных» людей. Помните Высоцкого «настоящих буйных мало, вот и нету вожаков»? Нужно оставаться по-хорошему буйным.
- Менеджер должен быть в движении, но ни в коем случае не двигаться от стека к стеку, от технологии к технологии. Должны создаваться технические условия для успешной работы — в частности, внедряться автоматизация там, где она нужна.
И да, вам придётся столкнуться с этой картинкой в жизни :-)
Итак, вы менеджер. Долгое время вы были разработчиком, инженером, многому научились в проекте. Теперь вы получаете новый опыт, ответственность и деньги в обмен на огромный объём работы, много давления и необходимость принимать сложные решения. Вы видите возможности и можете влиять на развитие бизнеса.
Что придётся принять?
Есть несколько вещей, которые нужно принять в роли менеджера: риски, умение прислушиваться к критике и реагировать на неё, новая мера ответственности, умение принимать жёсткие и иногда непопулярные решения. Придётся стать лидером своей же команды. Впрочем, если вы доросли до менеджера разработки, скорее всего, вы уже были неформальным лидером.
Самый большой страх
Главный страх менеджера, бывшего в недавнем прошлом разработчиком, — это потерять квалификацию, технические навыки, отстать от нововведений в стеке. Этот страх оправдан, но зависит всецело от вас. Менеджер должен быть на острие технологий и максимально разбираться во всех инструментах. Благо сейчас информации очень много и она легко доступна.
Как научиться быстро
Но каким бы крутым программистом вы бы ни были, заступая на работу менеджером, необходимо много учиться нюансам и тонкостям работы. Есть несколько способов получить квинтэссенцию чужого опыта и стартовать быстро.
Можно выбрать наставника, можно углубиться в учебники и книги, и это правильные решения. Но это и потеря времени. Поэтому лучше поучиться — но вопрос, где. MBA — это долго, дорого и, увы, далеко не всегда то, что нужно. Поэтому стоит обратиться к другим возможностям получить квинтэссенцию чужого опыта.
- Самая дешёвая и вполне адекватная возможность — найти наставника в компании, который позволит вам войти в новую колею. Это может быть глава департамента, опытный менеджер или даже генеральный директор, особенно в небольшой компании. Сотрудник, зная свою сторону работы, быстро освоится и изначально будет знать о проблемных точках проекта.
- Углубиться в книги, блоги, материалы, заняться самообразованием. Отличное решение, но оно займёт много времени и будет иметь теоретическую основу. Скорее, это обязательное дополнение к любому из перечисленных способов.
- Пойти на второе высшее, в магистратуру, на сложные курсы. Ну, если у вас есть время и деньги… На самом деле, это довольно затратно и не всегда эффективно — фишечка вузов, понимаете ли: есть учебный план и неприкаянные преподаватели, поэтому кроме нужных вещей вы будете изучать разную -логию. Впрочем, если вы студент последних курсов или хотите войти в ИТ уже не просто джуниором, но и подающим надежды молодцом, можете попробовать свои силы.
- Получить степень МВА. Дорого, сложно, жрёт много времени, региональных работодателей не впечатляет. К тому же, хороших программ в России мало. Обычно на MBA решаются топы или почти готовые топы крупных корпораций, в которых это добавляет веса. Но, по нашему опыту, в ИТ-сфере ценятся несколько иные навыки: мозги, опыт, умение работат.
Но в целом все способы хороши, особенно если их смешивать с толковыми книгами и блогами реальных практиков ИТ-менеджмента. Главное, помнить, что вы должны стать лидером, а не
«айти-бюрократом».
Внимание, Нижний Новгород, мы ищем менеджера!
Нижний Новгород, мы ищем таланты! Мы разрабатываем и внедряем RegionSoft CRM. Порой это очень (ОЧЕНЬ) сложные и длинные внедрения и интеграционные проекты. Нам нужен менеджер с навыками программирования. Проще говоря, ищем толкового парня, который сечёт в разработке, умеет выбивать из людей требования, составлять ТЗ, убеждать, что для облёта поля пшеницы 4 кв. км нужен кукурузник, а не «Боинг», даже если есть деньги на этот Боинг :-) Возраст значения не имеет, опыт — имеет, и огромное. Записывайтесь на собеседование по адресу contact@regionsoft.ru и приходите поговорить. Территориально Сормово, удалёнка невозможна. Работа суровая, не говорите, что не предупреждали. Люди хорошие, руководитель адекватный.
Наш пока живой Телеграм-канал BizBreeze. Всякое про CRM и бизнес, по уму, без копипаста и на 90% без рекламы. Подписывайтесь.
PMVyatkin
Хм, статья интересная безусловно, спасибо.
Принципы звучат отлично, но надо понимать их применение к реальности. Например, пример про собственные KPI — показателен. Например, компания нанимает менеджера на фикс и бонусы от KPI, при этом бонусы от проектов — могут быть 50% и выше, и будут только при условии соблюдения KPI. Надо думать, что разумный человек вряд ли пойдет на встречу команде — он играет по другим правилам, которые ему навязала компания. А внутри компании от него разрабы бегут как от огня — зная, что он всех принуждает к переработкам и людей держит за расходный материал.
Другой вариант — KPI менеджера зависит от процента проектов. Есть проекты и заказчики — менеджер получает деньги, нет (или мало) проектов и заказчиков — денег (почти) нет. Надо понимать, что в этом случае задницы заказчиков будут вылизаны до блеска, а команда опять останется с носом? В итоге — косяки менеджмента компании выдаются за косяки ПМов.
С менеджерами из разработки тоже не все так просто. Я сам люблю писать пример о Королеве, но есть и другой пример.
Дело в том, что экономика обмена в тот момент была такова, что перевозить товары было выгодно по реке, спуская их на юг, а не через Нью-Йорк — сухопутный путь был долог и дорог. От постройки канала федеральное правительство отказалось, президент и множество известных в то время людей не верило в возможность постройки, и казалось бы на этом все должно было закончиться — но история распорядилась иначе. Город использовал собственные деньги на строительство, а во главе проекта стояли… два судьи и школьный учитель. Двое из них, на тот момент, не имели никакого представления о строительстве каналов, третий же имел небольшой опыт инжинеринга. В результате — канал построен (на тот момент второй по величине в мире), стоимость перевозки товаров к Атлантике была снижена примерно в три раза, население Нью-Йорка выросло вдвое за десять лет. По ходу проекта, все трое прокачали инженерные навыки, доработали гидроцемент и поставили на ноги сферу строительства подобных объектов в США. Всю эту эпичную историю можно прочитать в Wiki.
RegionSoft Автор
Отличное дополнение, спасибо!
Распространённая ситуация, да. Особенно неприятно, когда заказчика по своим соображениям чуть ли не в команду внедряют, а он пользуется этой ситуацией и продавливает требования, например, сверх оплаты. Это очень сложный пункт взаимодействия. Тема не одной статьи.PMVyatkin
Хороший ПМ на проекте — хозяин. И с Заказчиком ему общаться интересно, и команду он не пускает к нему — не только потому, что З умеет давить, но и потому, что команда тоже может наобещать с три короба (ой, мы сейчас верификацию номера телефона сделаем, там на полчаса, а потом выясняется что надо архитектуру БД перекраивать, а заказчик сидит и ждет — ему же представитель исполнителя обещал).
Просто именно ПМство как искусство управления стейкхолдерами у нас слабо развито. Либо технические люди, кто не привык быстро ответственность брать в условиях неопределенности на себя, либо функциональные менеджеры, привыкшие к системе «я начальник, ты дурак» и не умеющие договариваться и искать win-win. Статью пилите, интересно будет почитать )
PMVyatkin
Насчет учебы — могу даже отдельный коммент написать.
Найти наставника — хорошо, если в компании есть сильный менеджмент — для ПМа это проектный офис, с среднесрочным и долгосрочным планированием ресурсов и проектов, с хорошей методологией. Я таких видел немного, но видел. В разработке — это самый грамотный способ, в менеджменте (особенно в ПМстве) надо будет скорее всего не одну компанию обойти.
Книги — вариант наверное для людей, способных прокрутить проект от начала до конца в голове во всех деталях. Обычным людям лучше сломать грабли на 2-3 проектах. Ну и смотрите материалы (и порталы) на английском (и немецком) — они как правило годные. Группы в телеграме тоже в помощь — насоветуют митапов на тему, будет что обсудить.
3. ВВ — по менеджменту — зверь редкий, магистратура — тоже мало что дает, шанс найти что то стоящее за пределами Москвы стремиться к нулю. Про фишечку ВУЗов — отмечено совершенно правильно, руководству ВУЗа надо по программе, преподаватели очень часто не видят дальше собственного носа, считая себя экспертами без единого дня опыта работы в сфере (да, у меня преподавали экономику те, кто работал после вуза преподавателем сразу, и разработку те, кто не работал ни над одним боевым проектом в группе). Опять же про курсы — мало людей умеет хорошо делать дорогие проекты, но предпочитает вместо этого тратить деньги на курсы. Встречал одни, достойные курсы после которых можно выпускать ПМа в поле под внимательным присмотром, но не более того.
4. MBA — сам думаю, но пока мысли следующие — для работодателей это не принципиально, самостоятельно можно несколько сотен часов потратить на обучение гораздо более эффективно.
И напоследок — о бедной зарплате замолвите слово. Хороший разработчик (синьор или лид) получает выше менеджера проекта, с гораздо меньшим геммороем (обычно нет командировок, оплачиваемые переработки, нет перманентных стрессов от давящих дедлайнов и заказчиков) и гораздо более светлым будущим — таков спрос на рынке. Так что всем, кто думает перейти из SD в менеджмент — с точки зрения поднятия доходов это плохая идея. Только по велению сердца.
aunoor
С последним абзацем я бы поспорил.
В нашей стране традиционно сложилась ситуация, что самый захудалый начальник получает больше чем самый сильный разработчик. Я видел только одно такое исключение из этого правила, но там один разработчик фактически держал в заложниках отдел.
PMVyatkin
Не знаю как в стране, но во всем мире наблюдаю одну и ту же ситуацию — как заплачено, так и сделано.
Если к тебе пришел хороший разраб, даже не важно джун или миддл или синьор и ты его взял к себе в команду, будь добр — мотивируй его работать. Если не можешь сделать это без денег (а в 95% случаев так и есть) — плати. Не будешь платить — человек будет шастать по собеседованиям, учить не относящиеся к работе фреймворки, в лучшем случае — сделает тебе фичу на том стеке, который интересен лично ему. Будешь платить — человек будет фигачить, что бы не потерять хорошее место.
С менеджерами ситуация еще хуже — мало того, что они знают ЗП команды, они еще часто знают ЗП в других командах. Однако очень часто руководство компаний думает что достаточно мотивировать только команду, а менеджер и так мотивирован. Ага, если бы.
Конечно, менеджеры и команды есть разные. Есть команды типа звезды разработки и обычный ПМ, есть звезды разработки и менеджмента (редко встречал), есть обычные разработчики и сияющий на их фоне ПМ (самый фиговый вариант).
Самый лучший вариант — нормально оплачиваемый ПМ, выбивающий у руководств ставки своей команде, взамен дающих руководству проекты в срок и в бюджете. Это мечта всех, но такой ПМ дорогого стоит, да и найти еще его надо.
0xd34df00d
Проблема с чисто материальной мотивацией в том, что платить хорошо могут и в другом месте.
Да и грустно это, за лишнее бабло лучшие часы своей жизни профукивать на неинтересные таски, неинтересные стеки и неинтересные проекты.
PMVyatkin
Грустно, это когда мешки из СТ живут в центре в трехкомнатной квартире, а ты с двумя детьми в однушке из Жуковского каждый день по 2 часа туда и 2 обратно ездишь.
KiloLeo
Когда я слышу фразу «в нашей стране...», всегда хочется спросить — а вы в какой-нибудь ещё стране работали? Хотя всегда очевидно, что нет.
Кстати, насколько велика ваша статистическая база, чтобы утверждать — вы много ли знаете зарплат началтьников и разработчиков, чтобы делать такие обобщения?
Ну и вообще-то это достаточно логично, что руководитель оплачивается выше, чем люди им управляемые. Довольно глупо ставить пустышку на управление ценными кадрами. Как руководитель проектов с 20летним опытом — да, я знаю стоимость своих ресурсов и руководителей в том числе — да, я всегда на управление ставлю более дорогих и опытных. И все мои коллеги поступают также.
aunoor
Я не очень понимаю смысл вашего выпада. Это было бы объяснимо, если исходная фраза содержала бы посыл что я бы утверждал о чем то, о чем я не могу иметь понятия, к примеру «В Буркино-Фасо дела обстоят следующим образом».
Но так как фраза «в нашей стране» очевидно относиться к стране которую я считаю своей домашней, и могу с уверенностью делать утверждения основываясь на собственном опыте, то ваши слова мимо цели.
Достаточна для того что бы я мог позволить себе делать подобные выводы основываясь на своем опыте. Если у вас есть другие примеры, то не стесняйтесь, расскажите, будет интересно послушать.
KiloLeo
Я к тому, что это вполне логичная практика на управление ставить более дорогие ресурсы, чем на исполнение. И она не зависит от страны. По тому не понятен акцент на нашей стране.
Про статистическую базу был вопрос в сторону, т.к. выводы правильные.
«Я видел только одно такое исключение из этого правила, но там один разработчик фактически держал в заложниках отдел.» — кстати, вы подтведждаете мои слова :-) Если руководитель допускает, что один человек держит в заложниках весь отдел — это очень плохой руководитель. И логично, что он дешёвый. Надо было взять нормального. Эта ситуация недопустима с точни зрения управления и обходится сильно дороже зарплаты начальника. Гнать его надо.
KiloLeo
«Гнать» — сильно сказано, но исправлять ситуацию необходимо.
zxweed
а может это сам руководитель навалил на сотрудника две-три должности сразу, а тот вместо того, что выгореть и требовать саббатикал — всё тянет и тянет 16 часов в день без выходных за одну зарплату?
aunoor
Он не дешевый, он нормальный. И попытки изменить ситуацию были, вот только безуспешно. Там был очень сложный клубок политических игр, и непосредственный начальник мало что мог сделать. А генеральный как то отказывался выгнать сам себя.
KiloLeo
Я сам был в ситуации, когда мой архитектор меня шантажировал тем, что у него в руках все ключи от решения. Это очень плохо со всех сторон. В итоге мы с ним расстались. Не уволил и не обидел, а просто я его больше не брал в свои проекты. Работает команда, а не одинокие светила. Ничего, все проекты делались и без него и успешно и веселее атмосфера в команде. Он тоже не в обиде — нашёл себе занятие.
ilyalazarev
Если менеджера больше ответственности и он управляет ресурсами то и получать он должен больше подчиненных.
PMVyatkin
Так то оно так, но вот людей, способных взять на себя ответственность и управлять ресурсами — много. А людей, способных спроектировать и реализовать ядро сложного и современного, конкурентоспособного приложения — мало, ой как мало. Это рынок.
KiloLeo
Моё ощущение рынка другое. Я в разных проектах выступал и архитектором и руклем. Архитекторить интереснее. Но спрос на РП выше. Нет проектов без руководителя. А без архитектора вполне достаточно.
PMVyatkin
Хм, проектов без архитектора нет, но вот продукты есть (а ПМы так вообще там не нужны). Если именно как software architect — очень странно, что спроса нет, казалось бы любой банк и интегратор забирают за любые деньги (особенно, Java). А вот РП не так нужны в разработке — работать без них можно, например по scrum, и в банках они почти не нужны. С Head of PMO ситуация еще хуже — если проекты разные, команды большие и ПМы самостоятельные — хэда им не берут.
KiloLeo
Я не сказал что спроса нет. Спрос есть и на тех и на этих. Вообще спор ни о чём. По моим СУБЪЕКТИВНЫМ ощущениям В МОЁМ СЕГМЕНТЕ рынка ищут пиэмов постоянно, а архитекторов периодически. То есть, если я сейчас встану со стула, то сразу могу выбирать куда я завтра пойду пиэмить, а архитекторской позиции надо будет подождать месяца два. Но в других сегментах рынка всё может быть иначе. В скраме нет пиэма, но есть скрам-мастер, что тоже управленческая позиция, аналогичная пиэму.
PMVyatkin
Понятно, у меня, увы, наоборот — ПМить идти на реально хорошие условия — надо поискать, зато звонят с предложениями поархитекторить, хотя я не архитектор ни разу.
Про скрам-мастера — вопрос сильно спорный, в правильной скрам команде мастер близко на ПМа не похож, роли у него совсем другие — коучить команду фреймворку, следить за временем. Но не указывать что делать, и точно — не брать ответственность на себя, это явно прописано в scrum guide. Но в плохих командах, да, СМ и жнец, и чтец, и пофронтендить может, и протестить, и на скраме, и на уотерфолл, и еще и полы помоет после работы.
zxweed
никогда не понимал — в чём состоит мифическая «ответственность менеджера»? Он что, зарплаты и премии лишится в случае провала проекта? Нет, нисколько, штрафуют только рядовых сотрудников. Может, его в должности понизят? Нет, только повысят, провал — это же опыт и все такое. Или его невнятное блеяние на отчётном совещании в духе «это мои плохие сотрудники не справились» — это ответственность?
PMVyatkin
Ну по опыту могу сказать, что менеджера меряют закрытыми проектами. Много хорошо сделанных, закрытых проектов, которые ты можешь подтвердить — платить будут хорошо (много и часто). Проектов закрытых и хороших нет — блеять менеджер будет уже на собеседовании.
Как правило, референсы может дать не только заказчик (пусть мы ему все вылизали в ущерб собственной компании), но и текущий работодатель — если менеджер нормально делал проекты, а потом ушел и теперь просит референс-колл — почему бы и нет? Серьезные западные компании при найме обязательно просят контакты бывших работодателей (не обязательно директора, это может быть и Head of PMO) и заказчиков (менеджер проекта со стороны очень даже ок).
KiloLeo
Даже скучно. Каждый свою работу считает важнее других. Такие фразы я слышу каждый день. Искусство менеджера состоит в том, что из 20 человек, от которых он в любой момент готов услышать подобное, он должен выстроить работоспособную команду и достичь результата в срок и в бюджет и с должным качеством. А так фигня, больше ничего делать не нужно.
При этом надо учесть, что управляет он не землекопами, каждого из которых можно заменить за полчаса, а высококвалифицированными индивидуалами, замена каждого из которых займёт минимум полгода и стоит много денег и сроки будут «просрачены». И каждый норовит делать то, что он считает интересным и ему скучно учитывать общие сроки и цели. А чтобы понять что он делает и убедить делать то, что нужно, а не то, что интересно, нужно обладать квалификацией сопоставимой с ним. И если это 20 человек разного профиля, то руководителю нужно иметь ого-го какую квалификацию.
PMVyatkin
Насчет команды, и замены ее участников — это верно. Выше, я писал, что ПМ — это в идеальном мире, тот человек к которому люди приходят поговорить об увольнении. И не писал, подразумевая, что это должен быть тот человек к которому приходят за прибавкой, с косяками, за отгулами и т.д. И, да, в СД не работает — иди и реши задачу. Работает — давайте сядем и разберемся, что НАМ нужно сделать, что бы мы завершили проект и что мы получим с этого (бонусы, экспириенс, повышения и т.д.). Менеджеров, которые просто говорят иди и делай — я в приличных местах не встречал давно даже не в ИТ. Но и разрабов, которые бы делали только то, что интересно им я встречал нечасто (хотя да, смузихлебов, занимающихся изучением нового фреймворка, вместо скучного багофикса и работы с легаси за деньги заказчиков хватает).
zxweed
мне иногда видится, что в любом реальном «типичном менеджере» можно найти одновременно десяток из этих моментов.
RegionSoft Автор
Мы смягчили формулировки :-) Всякое встречается. Но если человек настроен на развитие в ИТ, осваивает новое, вникает во всё, то дело пойдёт и многие негативные стороны могут довольно быстро «искорениться».
KiloLeo
Первый раз слышу, что для управления ИТ проектами нужно МВА. Хотя я сам имею квази-МВА и руковожу проектами 20 лет. Если вы руководите внедрениями серьёзных ERP систем, где требуется предметно спорить с главбухом, главным экономистом, главным финансистом крупной компании — то знания, входящие в МВА будут полезны, но и то не будут определяющими. А уж если вы управляете разработкой софта для микроконтроллера дрона — простите, зачам вам МВА? Максимум РМВоК проштудировать — и вперёд!
RegionSoft Автор
Мы живых MBA в команде не держим :-) Но опыт обучения есть (брошено вовремя). Почему это оказалось дурной затеей, если не сказать хуже:
Может, международное MBA и круче, и толковее, и все карты в руки даёт, но тратить на это время и деньги — сюрреализм какой-то.
PMVyatkin
Про МВА — напишите, битте, в личку куда ходили — сейчас как раз думаю пойти. Не рекламы для, а продолжения разговора ради — интересовался управлением проектами в вышке
Скажу что у меня фид положительный, учат не только планы-графики в проджекте делать и диаграммы рисовать (но и этому учат, курсы ведут PMP/CSM /PMI-ACP etc), но и полезным для руководителя скиллам — конфликтологии, управлению ожиданиями, и т.д. Приятный плюс — приглашенные с реально крупных и известных компаний эксперты и экзотика типа lean'a. Никаких книжек 97 года нет, матан так же присутствует в необходимой концентрации. С кейсами — полный порядок, живые и разнообразные, из практики, они в общем то и являются критерием приемки работ.
Объективный минус — деньги, 600к — организация, наверное, может это вычесть из налогов, а вот частное лицо не способно потратиться.
RegionSoft Автор
По деньгам в НН меньше. Подробности в личке.
KiloLeo
Сейчас есть прекрасные он-лайн курсы от лучших универов мира на той же курсере, зачем протирать штаны на лекциях? Выбираете что вам нужно и не тратите время на прочее бла-бла. И стоит копейки.
visput
Тот случай, когда не хватает Мегамозга.
Analitik_Telecom
Вам-то? Сочувствую, трудно без мозга. А уж без мега…
RegionSoft Автор
Так, коллеги, стоп флейм. Ирония по поводу Мегамозга полностью неуместна, поскольку статья касается непосредственно карьеры в ИТ-сфере. На этом весёлую дискуссию закрываем.
visput
Перечетал статью еще раз, признаю свою ошибку.
Я думаю на не негативный настрой меня настроило первое предложение в статье:
Я долго пытался понять смысл этого предложения.
Если имелось ввиду, что только в IT работают увлеченные, грамотные ребята, то здесь очевидное противоречие. Есть и другие отрасли, где работают в основном грамотные ребята (строительство, инженерия и т.д).
Если имелось ввиду, что наличие кода отличает эту индустрию от других, то это и так очевидно. Таким образом любые другие отрасли не похожи друг на друга (в каждой отрасли есть свои уникальные характеристики).
RegionSoft Автор
Принято. Вероятно, мы не дожали мысль — имелась ввиду не отстройка от остальных отраслей, а именно акцент на том, что в ИТ сейчас работают буквально фанаты, готовые и к вызовам, и к самообразованию, и добровольно ночами кодить :-) Всё же мы не филологи, красивый текст — не наша фишка, мы больше по красивому коду.