Чем опытнее становится проектный менеджер, тем меньше времени ему нужно на непосредственно планирование — оно становится более рутинным и проходит быстрее, так как что-то уже удалось автоматизировать, шаблоны для документов остались с прошлых проектов, во всех трекерах задач сохранены оптимальные настройки и так далее.
Команда — то, что делает проект уникальным для проджекта и способно полностью изменить подход к планированию и организации работы.
Сейчас (приблизительно) более 80% времени у меня уходит на коммуникации внутри и вне команды. Остальное время занято планированием, необходимыми отчётами, внесением корректировок в процессы по результатам обратной связи.
Роль менеджера проекта в том числе заключается в том, чтобы стать проводником между двумя мирами — общение заказчика/руководства/подрядчиков с командой должно выстраиваться и проходить под чутким контролем. Иначе появляются неучтeнные требования, хаотичная смена приоритетов, незафиксированные договорённости, смена целей проекта, неконтролируемые изменения. Оно нам не надо.
С кем общаемся вовне
Непосредственный руководитель, который хочет от нас проекты в срок, фидбек по команде, а ещё план найма, отчёты по занятости и множество других полезных вещей.
Финансовый отдел, который требует рассчитанный P&L, обоснование бизнес-кейса и бюджета проекта, аналитику по финансовым метрикам.
HR, который проводит собеседования на незакрытые позиции в команде проекта, занимается обсуждением условий найма и увольнениями.
Руководители смежных команд, у которых мы забираем сотрудников в команду на время проекта (при матричной структуре организации).
Заказчик, который приходит с требованиями и интересуется статусом проекта. Иногда заказчик интегрирован в команду проекта — появляется на встречах по статусу, обсуждении требований, к нему можно прийти с вопросами в любой момент. Чем он ближе к проекту, тем лучше.
Подрядчики, которые ждут одобренные договоры, оплату в срок, предоставляют отчёты по работе и выполненные задачи.
Аналитики, которые дают нам данные о рынке и положении продукта на нём.
Кто угодно ещё, кто оказывается заинтересованным или затронутым проектом, список может варьироваться в зависимости от специфики отрасли и внутренней структуры организации.
Общение со всеми этими группами точечное, происходит в заранее оговоренные периоды времени. Потому что всё остальное время менеджеру проекта нужно для общения со своей командой.
Из кого состоит команда проекта
Предлагаю рассмотреть стандартную структуру ИТ-проекта, но сразу хочу добавить, что могут быть специфические роли. Всё зависит от проекта и требуемых компетенций. Про несколько таких ролей я тоже упомяну.
Продакты, ключевые пользователи или заказчики. С ними нужно проработать требования, оформить в понятном для остальной команды виде. Общаться с ними просто, они наиболее заинтересованы в успешности проекта. Важно уметь договариваться и предлагать альтернативы, не давать бесконечно разрастаться списку требований, проговаривать рамки проекта (что входит и не входит в границы проекта), встречаться на приёмках готовой функциональности.
С продактами проще, они знают специфику ИТ-продуктов. С остальными типами заказчиков придётся взять на себя часть продуктовых обязанностей по оформлению требований, проведений встреч по их обсуждению, приоритизации.
UX/UI-дизайнеры. Определяют то, как будет использоваться и как будет выглядеть продукт. Результаты работы чаще всего представляют в Figma или аналогах — и лучше заранее ознакомиться с их интерфейсом. Зачастую требуются промежуточные ревью их работы совместно с заказчиками, чтобы утвердить логику переходов в экранах, расположение элементов и стилистику. Роль UX и UI может быть совмещённой.
Художники, аниматоры, саунд-дизайнеры. Могут появиться в контентно-ориентированных проектах, например, в играх. В своей работе опираются на UX-макет. Аниматоры зависят от арта, звук зависит от анимаций. Чаще всего в командах, в которых присутствуют такие специалисты, есть арт-директор, который утверждает результаты их работы. Коммуникация нужна по срокам, напоминайте арт-директору о фидбеке.
Архитекторы и системные аналитики. Определяют, как ваш продукт будет взаимодействовать с другими системами и ИТ-продуктами компании. Чаще всего появляются в сложных интеграционных проектах. Архитектура должна утверждаться до начала разработки и может меняться в ходе проекта только в исключительных случаях.
Разработчики. Они бывают клиентские и серверные. Могут делиться по платформам (web/app/desktop/консоли) и по используемым языкам. Опираются на архитектуру и документацию от аналитиков, UX- и UI-макеты.
Чаще всего проджект не разбирается в терминах, которыми оперирует разработка. Это усложняет коммуникацию.
При общении с разработчиками учтите, что все договорённости надо фиксировать в таске, потому что будет сделано ровно то, что написано. По правилам хорошего тона, менеджер НЕ должен говорить разработчику, как должна быть выполнена задача, так как разработчик может придумать решение лучше (это правило работает для каждого специалиста в команде).
Обязательно проговаривайте или прописывайте, для чего нужна задача, чтобы можно было опираться на контекст. Если вы работаете с прототипами, пропишите, что вы ждёте на выходе, какие функции должны работать, а какие нет. В идеале стоит прописывать Definition of Done (критерии завершения задачи), на которые при проверке и приёмке функциональности будут опираться тестировщики и заказчики.
Тестировщики. Чаще всего привлекаются в конце проекта, но это плохая практика. Обязательно ознакомьте тестировщиков с UX-макетами, архитектурой и всей документацией по требованиям, и пусть они в параллель с разработкой начинают писать тест-кейсы. Кейсы лучше утвердить у заказчика/продакта до старта проверки. При любом изменении начальной документации оповещайте своих тестировщиков, чтобы тест-кейсы были в актуальном состоянии.
Что можно узнать от своей команды
Именно от команды проджект может получить самую ценную информацию:
- Какие есть риски, угрожающие целям, срокам и бюджету проекта.
- Какие появляются возможности по сокращению сроков и бюджета.
- Есть ли ограничения или блокеры для работы.
- Фидбек по процессам, взаимодействию внутри и вне команды.
- Всё важное для планирования: декомпозированный список задач с оценками, порядок выполнения тасков.
- Документация по этапам проекта: требования, макеты, расчёты нагрузки, архитектурные решения, технические дизайны и так далее.
Вы должны быть доступны для команды, оперативно отвечать на сообщения и решать возникающие проблемы — письменно, устно или с помощью привлечения других специалистов и эскалации вопроса лидам/заказчику/etc.
О ком важно не забыть
Инфраструктура. Зачастую это проблемная часть любого проекта, так как находится в сфере ответственности техлида или ИТ-директора. Сроки по инфраструктурным задачам зависят от особенностей закупки и финансирования в вашей компании. И да, их придётся убедить, что вам нужен именно этот сервер с именно такими характеристиками. Подготовьте документацию по ожидаемой нагрузке и не откладывайте заказ нужного вам оборудования на потом.
Безопасность. Это внешняя команда, но она может значительно повлиять на проект. Озаботьтесь доступами для команды заранее, держите при себе документацию по сетевой архитектуре (доступ к внешней сети для инфраструктуры). И следите, чтобы срок доступов не истёк раньше времени. Особенно если запрашиваете доступы к внутренним ресурсам и системам для подрядчиков.
Пара советов вместо заключения
Если вы новенький в компании и плохо знаете, кто из команды за что отвечает, составьте себе шпаргалку. Самый простой вариант — табличка с именем, ролью и столбцом для комментариев.
Так будет проще сориентироваться, кто к вам пришёл и что с этим делать. Эта табличка исключительно для вашего пользования, поэтому адаптируйте её для собственного удобства, дополняя необходимой информацией. По мере более тесного знакомства с командой станет рудиментом.
Узнайте, кто является лидом члена команды. У него можно будет запросить обратную связь по новому для вас человеку, узнать о возможных проблемах заранее. В дальнейшем именно с ним вы будете эти проблемы решать.
Не забывайте спрашивать у команды фидбек по своей работе, это поможет расти и становиться профессиональнее.
Мария Родина