Кто есть кто в команде проекта

Чем опытнее становится проектный менеджер, тем меньше времени ему нужно на непосредственно планирование — оно становится более рутинным и проходит быстрее, так как что-то уже удалось автоматизировать, шаблоны для документов остались с прошлых проектов, во всех таск-трекерах сохранены оптимальные настройки флоу и так далее.

Команда — то, что делает проект уникальным для проджекта и способно полностью изменить подход к планированию и организации работы.

Сейчас (приблизительно) более 80% времени у меня уходит на коммуникации внутри и вне команды. Остальное время занято планированием, необходимыми отчётами, внесением корректировок в процессы по результатам фидбека.

Роль проджекта в том числе заключается в том, чтобы стать проводником между двумя мирами — общение заказчика/руководства/подрядчиков с командой должно выстраиваться и проходить под чутким контролем. Иначе появляются неучтённые требования, хаотичная смена приоритетов, незафиксированные договорённости, смена целей проекта, неконтролируемые изменения. Оно нам не надо.

Непосредственный руководитель, который хочет от нас проекты в срок, фидбек по команде, а ещё план найма, отчёты по занятости и множество других полезных вещей.

Финансовый отдел, который требует рассчитанный P&L, обоснование бизнес-кейса и бюджета проекта, аналитику по финансовым метрикам.

HR, который проводит собеседования на незакрытые позиции в команде проекта, занимается обсуждением условий найма и увольнениями.

Руководители смежных команд, у которых мы забираем сотрудников в команду на время проекта (при матричной структуре организации).

Заказчик, который приходит с требованиями и интересуется статусом проекта. Иногда заказчик интегрирован в команду проекта — появляется на встречах по статусу, обсуждении требований, к нему можно прийти с вопросами в любой момент. Чем он ближе к проекту, тем лучше.

Подрядчики, которые ждут одобренные договоры, оплату в срок, предоставляют отчёты по работе и выполненные задачи.

Аналитики, которые дают нам данные о рынке и положении продукта на нём.

Кто угодно ещё, кто оказывается заинтересованным или затронутым проектом, список может варьироваться в зависимости от специфики отрасли и внутренней структуры организации.

Общение со всеми этими группами точечное, происходит в заранее оговорённые периоды времени. Очень эффективно использовать фокусированную коммуникацию, как это рекомендуется в p3express, чтобы сократить количество времени на внешнее общение и предвосхищать вопросы, которые могут возникнуть у разных групп заинтересованных лиц.

Потому что всё остальное время проджекту нужно для общения со своей командой.

Предлагаю рассмотреть стандартную структуру ИТ-проекта, но сразу хочу добавить, что могут быть специфические роли. Всё зависит от проекта и требуемых компетенций. Про несколько таких ролей я тоже упомяну.

Продакты, ключевые пользователи или заказчики. С ними нужно проработать требования, оформить в понятном для остальной команды виде (например, в виде user stories). Общаться с ними просто, они наиболее заинтересованы в успешности проекта. Важно уметь договариваться и предлагать альтернативы, не давать бесконечно разрастаться списку требований, проговаривать рамки проекта (что входит и не входит в границы проекта), встречаться на приёмках готовой функциональности.

С продактами проще, они знают специфику ИТ-продуктов. С остальными типами заказчиков придётся взять на себя часть продуктовых обязанностей по оформлению требований, проведений встреч по их обсуждению, приоритизации.

UX/UI-дизайнеры. Определяют то, как будет использоваться и как будет выглядеть продукт. Результаты работы чаще всего представляют в Figma или аналогах — и лучше заранее ознакомиться с их интерфейсом. Зачастую требуются промежуточные ревью их работы совместно с заказчиками, чтобы утвердить логику переходов в экранах, расположение элементов и стилистику. Роль UX и UI может быть совмещённой.

Художники, аниматоры, саунд-дизайнеры. Могут появиться в контентно-ориентированных проектах, например, в играх. В своей работе опираются на UX-макет. Аниматоры зависят от арта, звук зависит от анимаций. Чаще всего в командах, в которых присутствуют такие специалисты, есть арт-директор, который утверждает результаты их работы. Коммуникация нужна по срокам, напоминайте арт-директору о фидбеке.

Архитекторы и системные аналитики. Определяют, как ваш продукт будет взаимодействовать с другими системами и ИТ-продуктами компании. Чаще всего появляются в сложных интеграционных проектах. Архитектура должна утверждаться до начала разработки и может меняться в ходе проекта только в исключительных случаях.

Разработчики. Они бывают клиентские и серверные. Могут делиться по платформам (web/app/desktop/консоли) и по используемым языкам. Опираются на архитектуру и документацию от аналитиков, UX- и UI-макеты.

Чаще всего проджект не разбирается в терминах, которыми оперирует разработка. Это усложняет коммуникацию.

При общении с разработчиками учтите, что все договорённости надо фиксировать в таске, потому что будет сделано ровно то, что написано. По правилам хорошего тона, менеджер НЕ должен говорить разработчику, как должна быть выполнена задача, так как разработчик может придумать решение лучше (это правило работает для каждого специалиста в команде).

Обязательно проговаривайте или прописывайте, для чего нужна задача, чтобы можно было опираться на контекст. Если вы работаете с прототипами, пропишите, что вы ждёте на выходе, какие функции должны работать, а какие нет. В идеале стоит прописывать Definition of Done (критерии завершения задачи), на которые при проверке и приёмке функциональности будут опираться тестировщики и заказчики.

Тестировщики. Чаще всего привлекаются в конце проекта, но это плохая практика. Обязательно ознакомьте тестировщиков с UX-макетами, архитектурой и всей документацией по требованиям, и пусть они в параллель с разработкой начинают писать тест-кейсы. Кейсы лучше утвердить у заказчика/продакта до старта проверки. При любом изменении начальной документации оповещайте своих тестировщиков, чтобы тест-кейсы были в актуальном состоянии.