Во многих компаниях разработка существует без менеджеров или руководителей проектов, без аналитиков и тестировщиков. Запросы бизнеса решают разработчики напрямую. Когда же появляется необходимость в отдельной роли РП?
Я пришла в профессию 13 лет назад в небольшой IT отдел, состоящий из 6 человек, и стала первым менеджером проектов в отделе. Меня наняли как "PR-щика it-отдела" - это буквально формулировка моего руководителя. По его словам никто в компании не понимал, чем занимается IT отдел. Хотя при этом вся деятельность разработчиков сводилась к решению запросов от бизнеса. Новая роль прижилась и после этого РП-шники в компании только множились, а роль их усложнялась.
Почему появление РП в отделе помогло с внутренним PR?
В моем случае я как Руководитель проектов взяла на себя коммуникации с заказчиками и решила проблему непрозрачности работы отдела. Делала я это целенаправленно, системно и регулярно. Это в отличии от разработчиков и была моя основная обязанность. Помимо коммуникаций с заказчиками, я проводила первичный анализ запросов в поддержку и собирала требования по новым запросам в разработку, освободив разработчиков от этих функций. В итоге, мы вместе стали решать задачи наиболее приоритетные для бизнеса и делали это быстрее, чем раньше, и об этом теперь знала вся компания.
В зависимости от того, какие задачи вы хотите решить появлением РП в команде, необходимо и определять компетенции будущего коллеги. Чуть позже в отдельном посте более подробно распишу матрицу компетенций руководителя проектов. А здесь опишу, что может делать единственный РП в небольшой внутренней команде.
Задачи, которые может решить руководитель проекта во внутренней команде разработки:
- Коммуникации с заказчиком. Руководитель проекта будет во время информировать о ходе проекта и сроках - это освободит время команды, и сформирует правильные ожидания у заказчиков.
- Коммуникации с командой. Руководитель проекта будет приносить в команду приоритет задач и первичные требования - в разработку будут попадать наиболее важные задачи бизнеса.
- Первичная обработка запросов ошибок или новых требований к системам. Руководитель проекта будет качественней общаться с пользователями, формируя положительное отношение к IT внутри компании. Первичная обработка сэкономит время команды разработки и ускорит решение запросов.
- Тестирование функционала. Руководитель проекта даже без особенных навыков тестирования будет находить ошибки, которые сам создатель кода не заметит.
- Презентация новых решений и обучение пользователей. Руководитель проекта покажет и расскажет о системе на бизнес языке и языке пользователей.
- Планирование будущих задач совместно с бизнесом. Руководитель проекта будет вести план реализации задач на несколько недель или месяцев вперед, что сделает работу отдела еще более предсказуемой для бизнеса.
- Управление подрядчиками. Руководитель проекта будет контролировать привлечение и работу подрядчиков в тех случаях, когда роль подрядчика новая и временная для команды - например дизайнер для каких-то важных интерфейсов или переводчик для специфических проектов.
Это не классический набор задач менеджера проекта, это сборная солянка разных ролей. Вам нужен этакий универсальный солдат. Но так как вы его наделите властью постановки задач, валидации результата и ответственности за общий результат, то он ближе к РП, чем к кому-то другому. В случае такого набора задач, будут иметь первостепенное значение не профессиональные навыки управления проектом, а умение РП хорошо общаться с бизнесом, быстро учиться новому и небольшой технический бэкграунд, чтобы общаться с командой и собирать требования, а так же анализировать ошибки.
Список задач руководителя проекта внутренней разработки довольно большой, при этом он не конечный и будет зависеть от ваших потребностей. В случае увеличения объема задач или постановки других целей стоит подумать и о ролях тестировщика, аналитика, отдельной службы поддержки. Но это, кажется, уже следующий этап развития вашего отдела.
P.s.: руководителю отдела важно подготовить команду и убедиться, что все хотят и одинаково понимают новую роль в команде. В моей практике однажды случился саботаж. Разработчику нравилось общаться с бизнесом, и он не был готов отказаться от этой функции. Напрямую он это не говорил, но всячески саботировал новый процесс, ссылаясь на разные факторы, а чаще всего на некомпетентность РП. После смены РП претензии от разработчика продолжали поступать, и так как претензий от других разработчиков не было, стало очевидным, что дело вовсе не в конкретном РП, а в самом разработчике. К сожалению, на это потребовалось несколько месяцев неэффективной работы и постоянного внимания руководителя к каждому инциденту. Чтобы сохранить свои нервы советую руководителю не отодвигать проблему и в случае сопротивления новому процессу, останавливаться до полного разбирательства. Если вы внедряете роль руководителя проектов, надеюсь, у вас классические интроверты-разработчики, которые выдохнут с появлением новой роли для общения с бизнесом 😊
