Разбирая проектные роли, надо четко отделять их от самого человека: сотрудник может выступать сразу в нескольких ипостасях, а также участвовать в одной разработке в роли А, а в другой — в роли Б. Совершая любое действие в работе, надо понимать от чьего имени это происходит.

Список ролей

Менеджер проекта, PM

Создает и поддерживает план проекта, отвечает за его выполнение.

• Получает от разработчиков, аналитиков, тестеров, DevOps и других подразделений их части планов проекта, сводит и убеждается в их непротиворечивости.
• Проводит регулярное (еженедельное) ревью плана с клиентом и проектной командой.
• Корректирует план в соответствии с запросами на изменение.
• Пишет еженедельный проектный отчет.
• Ведет реестр рисков и эскалаций.
• В случае появления проблем, информирует клиента и команду; решает их в рамках бюджета или эскалирует.
• Отвечает за заполнение сотрудниками отчетов по затраченному времени и попадание проекта в срок и бюджет.
• По итогу проекта делает презентацию: успехи и вынесенный опыт.
• Принимает решения по премированию героев :)

KPI — маржинальность проекта.

В целом здесь не рассматривается ситуация, когда требуется более одного менеджера. Я рекомендую бить такие проекты на самостоятельные части. Тем не менее у нас был случай, когда мы вели 15 параллельных проектов в рамках заказчика и одной целевой системы, и в этом случае потребовалось построить иерархию менеджеров.

Аналитик

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

• Проводит интервью со стейкхолдерами.
• Пишет требования, проводит их ревью со стейкхолдерами, архитектором и ведущими разработчиками.
• Участвует как ревьюер в проектировании верхнего уровня.
• Устно или письменно поясняет сотрудникам сложные места в требованиях (и по ходу обновляет их!).
• Проводит ревью тест-планов, поясняет тестерам сложные места и может принимать участие в тестировании критических мест проекта.

Носитель эзотерических знаний и главный коммуникатор между командой и клиентом в части сути проекта.

KPI - нулевой объем устной коммуникации на проекте типа «объясни мне, что ты тут написал», степень удовлетворенности заказчика реализованным проектом.

Ведущий аналитик

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

• Выполняет ревью документов и принимает участие в эскалациях и трудных местах.
• Выявляет (вместе с аккаунтом и менеджером проекта) стейкхолдеров.

Если проект структурирован по направлениям или подсистемам, могут быть назначены ведущие аналитики подсистем.

Архитектор

Может присутствовать частично при проработке архитектуры в самом начале и в режиме аудитора во время разработки. На большой проект должен быть выделен полностью.

• Отвечает за документы верхнего уровня (HLD), согласование архитектуры с ландшафтом и техническими требованиями заказчика.
• Структурирует проект, распределяет задачи между ведущими разработчиками, помогает им в тяжелых моментах.

KPI — соответствие системы нефункциональным (нагрузочным) требованиям, легкость ее расширения и развития, отсутствие проблем при интеграции.

Ведущий разработчик, Тимлид

На малом проекте (нет выделенного архитектора) ведущий разработчик отвечает за все задачи по разработке.

• Назначает разработчиков, проводит с ними ревью плана и получает от них коммитмент по реальности выполнения объемов работ.
• Принимает работы, выполняет ревью кода.
• Производит слияния веток в репозитории, отвечает за то, что в главную ветку попадает только оттестированный и соответствующий требованиям код.
• Принимает решения по технологиям, пишет проектные документы (HLD, LLD).
• Обучает линейных сотрудников и помогает им в трудных местах.
• По ночам пишет код :)

Разработчик

Собственно разрабатывает код проекта.

• Читает требования, разбирает сложные участки с аналитиком, принимает от лида или архитектора письменные или устные проектные решения, при необходимости дает обратную связь по их разумности.
• Разрабатывает код компонент и юнит-тесты, прогоняет тесты, убеждается в соответствии реализованной функциональности требованиям.
• Получает от тестировщиков и кого попало тикеты в баг-трекере, помечает их как «это не ошибка, так и должно быть», исправляет ошибки, в сложных случаях принимает участие в тестировании.

KPI — нулевое количество ошибок в коде.

Тестировщик

Планирует работы по тестированию.

• Пишет тест-планы на основании требований.
• Проводит ручное и автоматическое функциональное тестирование (нагрузочное тестирование, как правило, делает DevOps).
• Формирует задачи в баг-трекере.

KPI — нулевое количество репортов об ошибках от клиента.

Ведущий тестировщик

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

Системный администратор / сотрудник DevOps

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

• Пишет руководство по развертыванию и администрированию системы.
• Взаимодействует с соответствующими службами заказчика.
• На этапе продажи и расширения системы отвечает за требования к составу и структуре аппаратных средств системы (sizing).
• Принимает участие в планировании и работах по миграции и синхронизации данных.
• Дырявит отверстия в файерволах и прокладывает VPN-ы, носит свитер и бороду, матерится тихо, но весомо.

Должен быть способен без программистов развернуть систему.

KPI — попадание в план по задачам разворачивания системы.

Продавец

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

• Выявляет основные бизнес-потребности клиента.
• Проводит с производством (архитектор, ведущий аналитик) работу по очерчиванию силуэта системы, формирует скоуп проекта, вытрясает из производства вменяемую оценку стоимости работ и списки рисков.
• Доносит до клиента, что клиент тоже будет много работать на проекте.
• Формирует контракт, согласует его с клиентом, производством и подразделением гарантийной и постгарантийной поддержки.

Аккаунт

Отвечает за отношения с клиентом за рамками контракта. Любит его больше себя, живет его болью и радостью, и обеспечивает глубокое проникновение боли клиента (по идее и радости тоже, но руки у него до этого редко доходят) до проектной команды.

Если цель менеджера проекта — исполнить контракт в срок и деньги, то есть после подписания акта — трава не расти, то аккаунт как раз видит и строит отношения с клиентом вообще, с расчетом на дальнейшее контрактование и новые работы.

KPI аккаунта — рост оборота контрактов по его клиенту и общая маржинальность. В силу этого аккаунт может принимать решения о перебалансировке объема работ между несколькими проектами для одного клиента.

Начальник отдела разработки/аналитики

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

Директор, Генеральный директор, Директор группы компаний, Президент и Заместитель Бога на Земле.

Во время аврала уметь погреть пиццу и сварить кофе вот этому чуваку, который по локоть в крови разбирается в глюках Того Кода, Который Не Мы Написали. Потому что наш-то код точно работает правильно. Смотреть на клиента укоризненно, когда клиент пытается в этом усомниться.

Типовые совмещения ролей

• Менеджер+ведущий разработчик — грешновато.
• Менеджер+аналитик — приемлемо на микропроекте.
• Менеджер+ведущий разработчик+аналитик — не делайте так.
• Аналитик+тестер — нормально, даже хорошо, но дороговато.
• Архитектор+ведущий разработчик — норма на небольших проектах.
• Разработчик+тестировщик — нельзя.
• Продавец+эккаунт — зависит, но вообще так бывает часто.
• Продавец+иное—- не делайте так. Хотя был случай, когда продавец отработал проджектом, и никого не убил.
• Архитектор+аналитик — кажется приемлемым, но в целом плохо. Эти две роли должны быть немного антагонистичны, а в одном человеке это плохо сочетается.