Дело в том, что многие IT компании возникли как группа разработчиков, возглавляемых каким-нибудь молодым предпринимателем. Предпринимательский склад ума отличается от менеджерского, и разработческий менталитет тоже далёк от менеджерского. В результате компании живут фактически без проектного менеджмента до тех пор, пока не вырастут до размера 30-50 человек. На этом этапе уже появляется желание работать над проектами хотя бы среднего, а не мелкого размера. Владелец компании начинает понимать, что он не может выполнять функции менеджера проектов, так как у него не хватает времени. А ключевые разработчики начинают жаловаться, что 99% их времени занимают задачи, не имеющие отношения к разработке: написание писем, проведение совещаний, отчётность и т.д. Тогда решают “завести” менеджеров проектов.
Но раз компания выросла без менеджеров, то и обязанности менеджеров определяются из соображения “то, чем разработчику не хочется заниматься”, забывая, что менеджеру для эффективной работы нужно иметь возможность влиять на принятие решений. В результате менеджеру приходится добиваться результата очень косвенными методами: переговорами с владельцем компании, начальниками отделов и лидами, манипуляциями с отчётностью и отточенной риторикой.
Любому менеджеру нужно иметь продвинутые навыки работы с отчётностью и умение вести корреспонденцию. Но если вы видите, что эти навыки являются целью вашей работы, а не средством, то, возможно, чтобы заниматься настоящим менеджментом, работу вам стоит сменить.
2. Предпродажа/продажа. Интересный подвид проектного менеджмента, когда бойкий руководитель проекта с хорошо сработавшейся командой создаёт новый бизнес. Он общается с новым для компании заказчиком, а его команда быстро облекает все хотелки заказчика в работающий код. Начало бизнеса выглядит как череда мелких проектов и прототипов, которые быстро вырастают в большие проекты.
Такой менеджер имеет продвинутые навыки оценки проектов и ведения переговоров. А, например, нанимать junior-ов и выращивать из них senior-ов он запросто может не уметь или не любить. В его работе это не нужно. Когда бизнес из стадии зарождения переходит в более стабильную фазу, такому менеджеру становится скучно, а сам он становится неэффективным. Он передаёт подготовленную площадку другому менеджеру, а сам идёт стартовать новый бизнес с новыми заказчиками.
3. Менеджер процессов. Умение определять процессы разработки важно для любого руководителя проектов, но есть проекты, где нужны прямо гении такого управления. В больших проектах, где работает сотня и больше людей, и где есть большой заказчик со своими заморочками, процессы могут стать очень сложными. Я не говорю про бюрократию, которая мешает работать. Я говорю про сложные бизнес-требования, когда конкретный функционал должен определяться разными группами людей.
Если написанный большой кусок кода внезапно оказался не соответствующим европейским требованиям GDPR по защите персональных данных, то это катастрофа. Если требования, которые бизнес создавал полгода, оказалось невозможно реализовать ни в каком виде, то это тоже катастрофа. Чем больше проект, тем выше вероятность таких катастроф, и тем важнее роль процессов.
Но и в небольшом проекте, где работают 5 человек, очень здорово, когда разработчики не мешают тестировать, а заказчик может видеть нужную ему отчётность напрямую, без менеджера.
4. People management4. В компаниях с проектной организацией менеджеры проектов отвечают за найм, развитие и увольнение сотрудников. Даже, если менеджеры за это не отвечают, то они могут быть ключевыми людьми в деле мотивации и карьерного развития членов своих команд.
Это очень интересная тема, по которой откровенно мало информации. Компании понимают, что важно уметь из разрозненных людей создавать мотивированную команду, которая останется с вами много лет. Но компании абсолютно не знают, как этого добиваться, и даже просто как оценивать успех менеджера в этой области. Поэтому в этой книге я посвящу довольно много глав этой, любимой мной теме.
5. Антикризисный менеджмент. Тоже любимый мной и очень интересный вид менеджмента, о котором существует крайне мало информации. Периодически случается, что крупный проект вдруг начинает распадаться на части и непонятно, отчего это происходит.
В IT у антикризисного управления есть особенности, которые сильно отличают его от антикризисного управления в других областях:
a. Невозможно сменить команду. Традиционный антикризисный подход – это начать работу “с чистого листа”. Вся команда меняется на новых людей, все процессы перезапускаются заново. В IT это сделать невозможно, так как люди слишком ценный ресурс и найти 20-30 незанятых человек просто невозможно. К тому же в “кризисных” проектах знания распределены по ключевым людям и без них нельзя продолжить работу. Да и заказчик не может терпеть задержку из-за “перезапуска” проектов.
Конечно, всё равно необходимо делать перестановки в команде, но делать их нужно очень осторожно и точечно. Это гораздо сложнее для руководителя, чем всех выгнать и нанять новых людей.
b. Сложно диагностировать проблемы. “Нормальный” проект тоже имеет кучу сработавших рисков и рисков, которые могут сработать в любой момент. Тяжело отличить проект в кризисе от обычного, поэтому часто проекты заканчиваются провалом, а никто не успевает заметить, что они проваливаются, и ввести антикризисное управление.
Антикризисному менеджеру нужно очень хорошо понимать механизмы функционирования IT проекта, чтобы понять, на чём сконцентрировать изменения, а что можно оставить, как есть.
c. Демотивация команды серьёзно влияет на работу. Когда приходит антикризисный менеджер, люди уже сильно измучены неудачами, нелогичным менеджментом и пониманием, что проект далёк от нормального. А менеджеру требуется, чтобы они сделали трудовой подвиг и вывели проект из пике.
d. Обычным для кризисного управления, но от этого не менее сложным, является то, что менеджер окружён потоком проблем, каждая из которых выглядит приоритетной. Причём попытка решить любую из этих проблем приводит скорее к возникновению новых трудностей, чем к улучшению ситуации. Так работать очень тяжело психологически.
Если брать какого-то усреднённого менеджера, то он сочетает немного от каждого из перечисленных типов. Он ведёт переписку, он организует процесс разработки, он занимается командообразованием и решением конфликтов внутри команды, он немного занимается продажами, расширяя свой проект и предлагая заказчику новые возможности, он отрабатывает кризисные ситуации, не позволяя проекту скатиться в хаос.
