Процесс Завалишина - роли
Роли
Список типовых ролей проекта
Этот текст - часть микропроекта под кодовым названием “Процесс Завалишина”. В рамках этого микропроекта я пишу краткие описания элементов процесса разработки ПО так, как я себе его представляю. Тексты пишутся навскидку и из головы. Все тексты можно найти здесь: http://dz.livejournal.com/tag/ПроцессЗавалишина
В этот раз я перечислю роли, которые могут принимать участие в типовом проекте.
Надо чётко отделять роль от человека. Один человек может исполнять в проекте несколько ролей, и даже может участвовать в одном проекте в роли А, а в другом - в роли Б. Совершая действие на проекте надо чётко понимать, от имени какой роли оно совершается.
Список ролей
Менеджер проекта, PM
Создаёт и поддерживает план проекта, отвечает за его выполнение.
Получает от разработчиков, аналитиков, тестеров, devops и других подразделений их части планов проекта, сводит план, убеждается в его непротиворечивости.
Проводит регулярное (еженедельное) ревью плана с клиентом и проектной командой.
Корректирует план в соответствии с запросами на изменение.
Пишет еженедельный проектный отчёт: что сделано, что запланировано, какие проблемы.
Ведёт реестр рисков и эскалаций.
В случае появления проблем на проекте информирует клиента и проектную команду, и либо решает проблему в рамках бюджета, либо эскалирует проблему.
Отвечает за заполнение сотрудниками отчётов по spent time и попадание проекта в срок и бюджет.
По итогу проекта делает итоговую презентацию - успехи и lessons learned.
Принимает решения по премированию героев.
KPI - маржинальность проекта.
В целом здесь не рассматривается ситуация, когда на проекте требуется более одного менеджера. Я рекомендую бить такой проект на самостоятельные подпроекты. Тем не менее, у нас был случай, когда мы вели 15 (пятнадцать) параллельных проектов в рамках одного заказчика и одной целевой системы, и в этом случае потребовалось построить иерархию менеджеров проектов.
Аналитик
Отвечает за написание и поддержание в актуальном состоянии требований. Проводит интервью со стейкхолдерами, пишет требования, проводит ревью требований со стейкхолдерами, архитектором и ведущими разработчиками, участвует как ревьюер в проектировании верхнего уровня, устно или письменно поясняет сотрудникам сложные места в требованиях (и по ходу обновляет непонятные места, да-да), проводит ревью тест-планов, поясняет тестерам сложные места и может принимать участие в тестировании критических мест проекта.
Верифицирует ошибки, которые зарепортил заказчик, и помечает их как “это новое требование, а не ошибка”. :)
В целом является носителем эзотерических знаний о проекте и является главным коммуникатором между командой и клиентом в части сути проекта.
KPI - нулевой объём устной коммуникации на проекте типа “объясни мне, что ты тут написал”, степень удовлетворённости заказчика реализованным проектом.
Ведущий аналитик
В сложном проекте может быть группа аналитиков, тогда один из группы назначается ведущим аналитиком проекта и отвечает, в том числе, и за документы линейных аналитиков. Выполняет ревью документов и принимает участие в эскалациях и трудных местах.
Выявляет (вместе с аккаунтом и менеджером проекта) стейкхолдеров.
Если проект структурирован по направлениям или подсистемам, могут быть назначены ведущие аналитики подсистем. В этом случае должен быть главный аналитик проекта,
Архитектор
Может присутствовать в проекте частично, при проработке архитектуры в начале проекта и в режиме аудита архитектуры во время разработки. На большом проекте должен быть выделен на проект полностью. Отвечает за проектные документы верхнего уровня (HLD), согласование архитектуры с ландшафтом и техническими требованиями заказчика. Структурирует проект, распределяет задачи между ведущими разработчиками, помогает им в тяжёлых моментах.
KPI - соответствие системы нефункциональным (нагрузочным) требованиям, лёгкость расширения и развития системы, отсутствие проблем при интеграции (мне тоже смешно, да).
Ведущий разработчик, Тимлид
На малом проекте (нет выделенного архитектора) ведущий разработчик отвечает за все задачи по разработке.
Планирует работы, назначает разработчиков, проводит с ними ревью плана и получает от них коммитмент по реальности запланированных объёмов работ.
Принимает работы, выполняет ревью кода.
Производит слияния веток в репозитории, отвечает за то, что в главную ветку попадает только оттестированный и соответствующий требованиям код.
Принимает решения по технологиям, пишет проектные документы (HLD, LLD).
Обучает линейных сотрудников и помогает им в трудных местах.
По ночам пишет код. Шутка. Почти.
Собственно разрабатывает код проекта. Читает требования, разбирает сложные участки с аналитиком, принимает от лида или архитектора письменные или устные проектные решения, при необходимости даёт обратную связь по их разумности (ну и фигню вы тут придумали, парни), разрабатывает код компонент и юнит-тесты, прогоняет тесты, убеждается в соответствии реализованной функциональности требованиям. Принимает от тестировщиков и кого попало тикеты в баг-трекере, помечает их как “это не ошибка, так и должно быть”, исправляет ошибки, в случае сложных ошибок принимает участие в тестировании.
KPI - нулевое количество ошибок в коде.
Тестировщик
Планирует работы по тестированию.
Пишет тест-планы на основании требований, проводит ручное и автоматическое функциональное тестирование (нагрузочное тестирование, как правило, делает devops), формирует задачи в баг-трекере.
KPI - нулевое количество репортов об ошибках от клиента.
Ведущий тестировщик
Аналогично аналитикам, тестировщики могут быть сформированы в группы по подсистемам проекта или методам тестирования. Если тестировщиков более одного, должен быть назначен ведущий.
Системный администратор / сотрудник devops
Отвечает за ту часть архитектуры, которая относится к физическому распределению систем по серверам, организацию взаимодействия систем, деплоймент, выявление проблем на боевой и тестовой средах.
Пишет руководство по развёртыванию и администрированию системы. Взаимодействует с соответствующими службами заказчика.
На этапе продажи и расширения системы отвечает за требования к составу и структуре аппаратных средств системы (sizing).
Принимает участие в планировании и работах по миграции и, не дай бог, синхронизации данных.
Часто обеспечивает нагрузочное тестирование системы и анализирует его результаты.
Дырявит отверстия в файрволлах и прокладывает VPN-ы, носит свитер и бороду, матерится тихо, но весомо.
Должен быть способен без программистов развернуть систему.
KPI - попадание в план по задачам разворачивания системы.
Продавец
Создаёт у покупателя ощущение, что неподписание контракта прямо здесь и сейчас может привести к катастрофе планетарного масштаба.
Выявляет основные бизнес-потребности клиента, проводит с производством (архитектор, ведущий аналитик) работу по очерчиванию силуэта системы, формирует скоуп проекта, вытрясает из производства вменяемую оценку стоимости работ по проекту и списки рисков, доносит до клиента, что клиент тоже будет МНОГО работать на проекте и за часть рисков отвечает сам. Формирует контракт, согласует его с клиентом, производством и подразделением гарантийной и постгарантийной поддержки.
Эккаунт
Отвечает за отношения с клиентом за рамками контракта. Любит его больше себя, живёт его болью и радостью, и обеспечивает глубокое проникновение боли клиента (по идее и радости тоже, но руки у него до этого редко доходят) до проектной команды.
Если цель менеджера проекта - исполнить контракт в срок и деньги, то есть после подписания акта - трава не расти, то аккаунт как раз видит и строит отношения к с клиентом вообще, с расчётом на дальнейшее контрактование и новые работы.
KPI аккаунта - рост оборота контрактов по его клиенту и общая маржинальность вне границ контрактов. В силу этого аккаунт может принимать решения о перебалансировке объёма работ между несколькими проектами для одного клиента.
Начальник отдела разработки/аналитики.
Принимает участие в формировании проектных команд, отвечает за квалификацию сотрудников, проводит самостоятельно или организует обучение, следит за карьерным ростом сотрудников, принимает участие в бюджетировании и общем плане компании по количеству сотрудников с теми или иными компетенциями, работает руками на авралах, если не умеет - привозит бойцам пиццу и наливает кофе. Отвечает за комфорт на рабочем месте.
Директор, Генеральный директор, Директор группы компаний, Президент и Заместитель Бога на Земле.
Во время аврала должен уметь погреть пиццу и сварить кофе вот этому чуваку, который по локоть в крови разбирается в глюках Того Кода, Который Не Мы Написали. Потому что наш-то код точно работает правильно. Смотрит на клиента укоризненно, когда клиент пытается в этом усомниться.
Типовые совмещения ролей
Менеджер+ведущий разработчик - грешновато.
Менеджер+аналитик - приемлемо на микропроекте.
Менеджер+ведущий разработчик+аналитик - не делайте так.
Аналитик+тестер - нормально, даже хорошо, но дороговато.
Архитектор+ведущий разработчик - норма на небольших проектах.
Разработчик+тестировщик - нельзя.
Продавец+эккаунт - зависит, но вообще так бывает часто.
Продавец+иное - не делайте так. Хотя... был случай, когда продавец отработал проджектом, и никого не убил.
Архитектор+аналитик - кажется приемлемым, но в целом плохо. Эти две роли должны быть немного антагонистичны, а в одном человеке это плохо сочетается.