В этой статье попробую рассказать, почему для специалиста и компании важно понимать проектные роли и разделять зоны ответственности между ними. И, будучи руководителем команды аналитики, расскажу как мы в ADV/web-engineering co. выстраиваем работу тех самых аналитиков.
Как разделить ответственность
Вообще для определения ролей и зон ответственности умные люди придумали специальную модель, назвав её RACI по четырём первым буквам четырёх же ролей:
- Responsible / Исполнитель
- Accountable / Ответственный
- Consulted / Эксперт
- Informed / Информирующий
Однако дальше предлагаю использовать модель попроще:
- Зона ответственности — та часть деятельности, за которую ответственен именно аналитик.
- Зона влияния — область, которая находится рядом с зоной ответственности аналитика. Здесь аналитик может советовать как эксперт или просто о чём-то информировать, но финальная ответственность не на нём. Аналитик может прийти, задать любой вопрос и предложить любой новый подход по любой проблеме. Но если это изменить то, что он считает проблемой, не получилось, то остаётся действовать также, как и в зоне смирения.
- Зона смирения — область, в которой нет рычагов влияния. Здесь есть две опции — "понять, принять и смириться" или "уйти" из проекта или из компании. Мы делаем все возможное, чтобы решать внутренние такие конфликты миром. Для этого мы активно используем обратную связь, и к любому из руководителей можно прийти с любым вопросом. Но может быть всякое.
Итак, мы в ADV/web-engineering co. выделяем следующие основные роли, связанные с аналитикой:
- Сама аналитика
- UX/UI специалист / дизайнер
- Разработка (back и front)
- Тестирование
- Менеджер проекта
- Заказчик или руководитель продукта
Дальше наша внутренняя политика, несущая скорее рекомендательный характер. Иногда на проектах возникает нехватка людей какой-то роли. Тогда порой приходится заниматься делами, которые формально в зону ответственности аналитика не входят.
Это не значит, что ими заниматься не нужно. Работа над проектом в первую очередь направлена на результат.
Моя личная цель — сделать так, чтобы аналитики в моей команде понимали занимаются ли они своими задачами, или нет. И насколько исполняемые обязанности корректны, соответствуют роли в проекте. За всем уследить невозможно, поэтому обратная связь от специалистов для нас очень важна.
Аналитика
Начнём с основных обязанностей и зон ответственности аналитики. И да, сейчас я осмысленно опущу все сопроводительные процессы внутри компании.
Это тема отдельной статьи, главное — у нас в ADV на проектах не принято выделять отдельных бизнес и системных аналитиков.
Если сильно упростить, то основная зона ответственности проектного аналитика — формирование артефактов по проекту. Например, написание всяких документов, проектирование бизнес-процессов, ER-диаграмм, постановок задач и прочих проектных артефактов.
В проектах, где несколько аналитиков, обычно ещё существует отдельная роль — лид аналитики. Они несут ответственность за всю аналитику на проекте, в их зону ответственности также входит валидация и внутренняя приёмка артефактов.
UX/UI специалист / дизайнер
Аналитики самостоятельно и в рабочее время не занимаются отрисовкой макетов. Аналитик должен определить и передать в дизайн все требования к пользовательским интерфейсам.
UX/UI-специалисты в свою очередь ответственны за то, чтобы сделать из этих требований качественные макеты. При этом не просто "красивые и удобные", но и соответствующие прочим сопроводительным требованиям, например стандартам платформы или дизайн-киту решения.
В рамках зоны влияния аналитика предлагать варианты, настаивать и уговаривать дизайнера сделать что-то так или иначе. Но в любом случае финальное решение остаётся за дизайнером.
Разработка
Конкретные границы зон ответственности между разработкой и аналитикой могут делиться каждый раз, в зависимости от особенностей проекта или знаний, компетенций и амбиций участников команды. Однако в среднем по больнице аналитик при взаимодействии с разработкой:
- Отвечает за алгоритмы и внутреннюю логику работы решения
- Отвечает за детальное описание интеграционных взаимодействий
- Не отвечает за проектирование конкретной БД (но отвечает за проектирование модели предметной области)
В зоне влияния аналитика предлагать различные механизмы реализации, если аналитик достаточно компетентен технически, но принятие финального решения остаётся зоной ответственности команды разработки.
При этом в зону ответственности аналитика также входит сопровождение разработки и фиксация всех нюансов и ответов на вопросы, возникающих у разработки, в документации.
Тестирование
Аналитики пересекаются с тестированием, обычно, нечасто. Как правило, тестирование приходит с какими-то уточняющими вопросами, и в зоне ответственности аналитика отвечать на эти вопросы и фиксировать эти ответы в документации.
И да, в нашей компании написание тест-кейсов в зону ответственности аналитика не входит.
Менеджер проекта
Типичные менеджерские вопросы, находящиеся в зоне ответственности менеджера:
- Формирование проектной команды
- Предоставление информации о заказчике и различных контактных лицах
- Организация процессов взаимодействия
- Фиксация скоупа проекта
- Управление приоритетами задач
- Фиксация и отслеживание сроков
- Организация входа новых людей в проект
- Организация доступа членов команды ко всем необходимым рабочим инструментам
- Разрешение конфликтных ситуаций
Повторюсь, за всё это несёт ответственность менеджер. Но в зоне влияния аналитика пытаться что-то в проекте изменить. Он может предложить новые приоритеты задач или процессы, но финальное решение за менеджером.
Мы жёстко разделяем роли аналитики и менеджера. На наш взгляд, занимаясь менеджерской работой аналитик не будет успевать делать свою работу, которую никто, кроме него, хорошо сделать не сможет.
Так и зачем всё это
Понимание различных ролей и их задач — важный шаг к становлению сильного специалиста, независимо от его роли.
Если распределение зон ответственности соблюдается, то это несёт кучу профита:
- Разные проекты могут работать по одному шаблону, что очень упрощает их запуск
- Расширение проектной команды происходит легко
- Ротация сотрудников между проектами работает проще, как для компании, так для сотрудников
- Нервы экономятся