Мы продолжаем цикл статей об управлении проектами. Предыдущие материалы можно прочитать тут:
Методологии управления IT-проектами: как сделать выбор в условиях неопределенности
От концепции до правок: этапы управления IT-проектом
Сегодняшняя статья посвящена тому, какими качествами должен обладать проджект-менеджер и может ли им стать разработчик.
Есть два способа назначить руководителя — нанять со стороны или выбрать из числа участников технической команды. Часто считается, что второй способ эффективнее: человек «изнутри» уже погружен в процессы компании, знаком с корпоративной культурой, у него выстроены отношения с сотрудниками.
Все это справедливо, но только не тогда, когда речь идет о поиске менеджера по управлению ИТ-проектами. Да, иногда из разработчиков вырастают хорошие проджекты, но это случается довольно редко. Более вероятный карьерный путь для программиста — тимлид. Разберемся, почему так.
Сплошная неопределенность
Перед тем, как решить ту или иную задачу, разработчику нужно мысленно разбить ее на элементы, составить в голове и «на бумаге» структуру и алгоритм решения, которого он будет придерживаться.
Управление проектами в IT — это работа в условиях хаоса. Проджекту с самого начала приходится работать в ситуации неопределенности, когда на старте сложно предугадать, что будет на финише. В процессе работы может меняться все: сроки, бюджет, требования — которые приходится корректировать по ходу дела. И человеку, который всю жизнь занимался задачами, требующими системности, сложно ориентироваться этом хаосе. В принципе, почти любая управленческая работа — это всегда неопределенность, и хорошим руководителем может стать тот, кто чувствует себя комфортно в таких условиях.
Перевод с клиентского
Несмотря на клише про айтишников-интровертов, коммуникативные навыки все-таки желательны для ИТ-специалистов, поскольку в рамках проекта им нужно постоянно общаться с другими сотрудниками. Для тимлида умение взаимодействовать с техническими специалистами — обязательное требование. У проджекта самая сложная задача: ему нужно вести коммуникацию не только с командой, но и с заказчиком, который не разбирается в ИТ глубоко и мыслит другими категориями. Проджект-менеджер, которому приходится общаться как с клиентом, так и с сотрудниками, становится своего рода переводчиком между обеими сторонами. Умение переключаться между стилями коммуникации и отличает хорошего проджекта.
У разработчика же, как правило, нет опыта коммуникации с клиентами: он привык общаться с теми, кто говорит с ним на одном языке — а перестроиться на другой формат довольно сложно. Именно поэтому ИТ-специалисту проще стать тимлидом: на этой позиции он будет отвечать за руководство конкретно разработкой и коммуникацию внутри команды. Требования клиента ему будет передавать менеджер проекта, а сам тимлид — решать, как реализовать задачу.
Кого искать?
Нет правил без исключений, и иногда из разработчиков все-таки получаются хорошие проджект-менеджеры. Но для этого кандидат должен соответствовать ряду требований — помимо умения работать в условиях неопределенности и способности понять язык клиента.
- Навыки переговоров. Задача проджекта — не только переконвертировать запрос с языка клиента на язык команды. Он должен уметь сам видеть оптимальные решения, предлагать их заказчику и аргументировать свое мнение. А значит, он должен быть хорошим переговорщиком.
- Организационные навыки. Тут все понятно: проджект должен уметь делегировать задачи, грамотно распределять нагрузку и рассчитывать время, контролировать выполнение работ и выстраивать процессы по принятой в компании методологии.
- Умение мотивировать команду. Как и любой руководитель, менеджер проекта должен создавать в команде комфортную атмосферу, где люди будут хотеть выполнять свою работу. А для этого нужно уметь выстраивать доверительные отношения, заинтересовывать, понимать сильные и слабые стороны каждого и проявлять эмпатию.
- Понимание ИТ. Разумеется, менеджер ИТ-проекта должен разбираться в ИТ: знать, как строится процесс работы над продуктом, из каких задач он состоит и какова их последовательность, кто из сотрудников отвечает за ту или иную часть проекта и так далее.
Намного больше шансов, что все эти навыки будут у проджекта с рынка, чем у разработчика — поскольку у последнего нет опыта руководства. Но с другой стороны, если у специалиста хороший потенциал, его можно обучить — в конце концов, плох тот солдат, который не мечтает стать генералом.