августа 18, 2017

Роли на типовом проекте

Роли на типовом проекте

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


Список ролей


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

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

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

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

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


Аналитик

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

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

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

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


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

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

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

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


Архитектор

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

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

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


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

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

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

Разработчик

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

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

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


Тестировщик

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

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

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


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

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


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

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

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

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

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


Продавец

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

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

Аккаунт

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

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

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


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

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


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

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


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

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