Однажды к нам в Surf пришла задача: заказчик хотел получить мобильное приложение, сайт, ERP-систему и CMS за полгода. После детального планирования менеджеры сообщили: если на проект подключить троих аналитиков на полную ставку, все работы сдадим в срок.

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

Меня зовут Анна Цветкова, я бизнес-аналитик в Surf. Расскажу, как нам удалось на лету исправить ситуацию и выстроить работу команды аналитиков на проекте. 

Почему чуть не случился фейл

Мы подключили трёх аналитиков на один проект. Разрабатывали по гибкой методологии: спроектировали спринт -> отдали в работу -> приступили к проектированию следующего. После нескольких спринтов на ретро всплыли проблемы: 

• Несколько фич зависают в проектировании и стопятся.

• Артефакты не стандартизированы. 

• Кто-то из аналитиков проводит груминги фичи, кто-то — нет. 

• Появился высокий бас-фактор: аналитик знает только свои фичи, остальные на вопросы по ним ответить не могут.

Мы провели аналитическое ретро и выяснили, что аналитики:

• Не общаются. Прям совсем. Встречаются на ежедневных дейликах — и всё.

• Не находятся в контексте задач друг друга и не в курсе целых кусков проекта.

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

• Не помогают друг другу, не прорабатывают точки пересечения задач, потому что непонятно, кто за что отвечает.

Нужно было понять, что с этими проблемами делать. В ходе обсуждения выяснили, что в рамках текущего процесса мы не сможем их пофиксить. Какие были варианты:

1. Поменять аналитиков в команде. Но нет: всё-таки дело не в людях, потому что все специалисты — профессионалы своего дела.

2. Поменять подход к организации работы аналитика. А значит, поменять процесс. На этом варианте и остановились.

Это был вызов, но новый процесс родился довольно быстро. Опробовали его на текущей команде и поняли, что сработало! Поэтому хотим поделиться практическими рекомендациями: как определить количество аналитиков в команде, по каким принципам их объединять и как предотвращать проблемы.

На каких проектах нужно несколько аналитиков

Это зависит от размера команды, объёма работ и сроков.

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

• по два разработчика на платформе (если говорим про мобильную разработку),

• тестировщик,

• дизайнер,

• менеджер проектов,

• опционально — продакт. 

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

Объём работ на проекте. Размер команды аналитиков напрямую зависит от объёма работ на проекте. Иногда приходят заказчики, которые хотят разработать сразу несколько продуктов: мобильные приложения под iOS и Android, админ-панель для управления приложениями, сайт, бэкенд — и сделать интеграции. Одному аналитику придётся разрываться между контекстами: это снизит качество работы.

Сроки. Горящие сроки влекут за собой увеличение команды разработки — а значит, нужно усиливать команду аналитиков. И мы возвращаемся к пункту про размер команды.

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

По каким принципам составлять команду аналитиков

Состав команды аналитиков обычно неоднородный и зависит от:

• Целей подключения нескольких аналитиков.

• Скорости, с которой аналитикам необходимо проектировать фичи.

• Сложности проекта.

• Экономики проекта: например, не все проекты могут финансово потянуть работу двух сеньоров.

Распространены такие сочетания: 

• Senior + Junior,

• Analyst + Analyst,

• BA + SA.

Бывают проекты, на которых изначально непонятно, сколько аналитиков понадобится. В таком случае можно поставить на проект лида — аналитика уровня middle и выше, который играет роль «менеджера-аналитика». Лид исследует артефакты проекта, работает на нём какое-то время и мониторит ситуацию. Если видит триггерные ситуации, сразу сигнализирует об этом, и на проект подключают дополнительных аналитиков. 

Senior + Junior: опытный и начинающий аналитики

Когда использовать: если проект небольшой и без горящих дедлайнов.

Плюсы: 

• Начинающий аналитик учится у старшего коллеги и быстрее набирается опыта.

• У более опытного аналитика появляется время на глубокое проектирование фич и пополнение бэклога: руки освобождаются от рутинной работы.

Минусы: 

• Проектирование может занять больше времени: опытный аналитик тратит время на ревью и помощь начинающему.

• Повышается вероятность ошибки: начинающий аналитик набивает шишки — и это нормально.

Analyst + Analyst. Несколько аналитиков примерно одинакового уровня: middle + middle или senior + senior

Когда использовать: на больших проектах, в которых необходимо разделение зон ответственности по фичам, сервисам и так далее. Или для проектов с очень сжатыми сроками и обширным бэклогом.

Плюсы:

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

• Обмен опытом и контекстом — как следствие, личное развитие аналитиков.

Минусы:

• Если процессы не выстроены корректно, возникают пробелы в проектировании разных фич или одной и той же фичи с разных сторон.

BA + SA: разделение на уровни проработки 

Такой вариант в Surf не используется: у нас аналитики гибридные и могут работать на разных этапах. 

Во многих компаниях есть разделение на бизнес- и системных аналитиков. Расскажите в комментариях, какие плюсы и минусы вы видите в таком разделении?

Как организовать работу команды аналитиков

Распределять задачи между аналитиками

Распределение задач — это совместная работа менеджера проектов и лида аналитиков. Есть несколько подходов: они зависят от специфики проекта.

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

Распределение бэклога. Каждый аналитик отвечает за определённый набор фич из бэклога: проектирует; презентует; следит, чтобы все артефакты были согласованы; поддерживает на этапе разработки.

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

Выбирать лида команды аналитиков для каждого проекта

Даже если над проектом работают всего два человека, один из них должен быть лидом. Лид аналитиков нужен, чтобы:

• контролировать ставки сотрудников,

• следить за эмоциональным фоном в команде,

• фасилитировать общие встречи.

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

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

Также лид следит за бэклогом проекта и не забывает напоминать аналитикам его пополнять.

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

Главный принцип, которого полезно придерживаться: лид — часть команды. Члены команды не обвиняют друг друга и не перекладывают ответственность, а помогают решить проблемы. Когда люди понимают, что могут быть честными и за это не последуют санкции и осуждение, атмосфера в команде становится доверительной.

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

Собеседник может поделиться проблемами, а лид — предложить решение. Например, аналитик выгорает и не чувствует интереса к работе. Лид может перераспределить задачи, чтобы снизить нагрузку, или дать больше интересных задач.

Фасилитировать общие митинги, планирования, обсуждения. Да, лид в команде — это «менеджер» аналитиков. Может возникнуть закономерный вопрос: а что тогда делает проектный менеджер? У менеджеров на крупном проекте часто не хватает времени, чтобы следить за процессами во всей команде. Придётся погружаться в детали работы аналитика, вникать в процесс. Мы хотим и можем делать это сами, поэтому стараемся помочь нашим менеджерам организовать процесс. 

Выстроить процесс перекрестного ревью

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

Например, на одном из проектов вместе работали сеньор-аналитик и джун. Естественно, джун во всём ориентировался на сеньора: писал документацию в таком же формате, пытался вести созвоны в той же манере, скидывал на ревью все артефакты, советовался по любому поводу. Они вместе приступили к проектированию фичи по интеграции с платежным эквайрингом. 

Сеньор не проработал кейс с обработкой статуса платежа, который «зависает» в воздухе — когда запрос от платёжного сервиса упал по таймауту. При ревью решения джун заметил и подсветил этот момент. Все остались в плюсе: разработке передано полное описание, джун стал больше верить в свои силы, а сеньор получил ещё один кейс в копилку.

Перекрестное ревью помогает сразу по нескольким направлениям:

1. Ревьюер помогает найти неочевидные проблемы: у исполнителя часто замыливается взгляд на собственную фичу.

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

3. Аналитики в команде находятся в контексте задач и продукта в целом. Это помогает избежать бас-фактора и позволяет не зарываться в собственную рутину. При ревью артефакта неизбежно погружаешься в бизнесовый контекст: это помогает в поиске решений в будущем.

4. Аналитики обмениваются опытом, видением и вместе приходят к лучшему решению. Понятно, что ревью — это субъективный процесс, но сторонний взгляд позволяет посмотреть на свою работу под другим углом.

Поддерживать постоянную коммуникацию

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

Вести прозрачный бэклог 

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

Риски при работе нескольких аналитиков на проекте

Риск 1: противоречия в требованиях

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

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

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

На другой встрече говорят про процесс оформления заказа: клиент говорит, что не стоит снижать конверсию, поэтому оформить заказ могут только авторизованные пользователи, а вот пользоваться приложением — и авторизанты, и неавторизанты.

Возникло противоречие, о котором аналитики узнали только во время проектирования решения.

Как не допустить:

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

• Постоянно обмениваться контекстом. Показывать команде аналитиков митинг ноутсы, обсуждать изменения.

Риск 2: отсутствие проработки фичи «на стыке» с другой, потому что непонятна зона ответственности

В проекте по доставке еды есть возможность выбрать и изменить адрес доставки. Точек входа для выбора адреса несколько:

• после онбординга,

• на главном экране,

• при оформлении заказа.

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

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

Как не допустить: 

• При распределении задач обращать внимание на пересечения и «стыки». В явном виде проговаривать ответственных за их проработку.

Риск 4: недостаточная или волнообразная нагрузка аналитиков в команде

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

Как не допустить:

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

• Провести долгосрочное планирование задач для аналитиков, дать верхнеуровневую оценку.

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

Вопросы, которые помогут выстроить работу нескольких аналитиков на проекте

Работа в команде из нескольких аналитиков — интересный опыт. Чтобы эффективно организовать работу, нужно помнить о:

1. Целях командной работы. Зачем на проекте несколько аналитиков? Точно ли это необходимо? Какой результат получится в итоге?

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

3. Важности обмена опытом и погружения в контекст задач друг друга. Аналитики могут ответить на вопросы: кто отвечает за связанную с моей задачу? Выбранный способ решения моей задачи не требует доработки другой фичи? Не усложнит ли он другую фичу? Будет ли пользователям удобно использовать спроектированное решение в рамках всего продукта?

4. Важности ревью артефактов друг друга. Соблюдается ли стиль ведения документации? Описаны ли основные и корнер-кейсы? Достаточно ли детализирована документация? Необходимо ли дополнить документацию схемами или этого не требуется?

5. Важности грамотного менеджмента: команде аналитиков нужен лид, который настроит процессы. Есть ли человек, который следит за нагрузкой аналитиков? Распределяет задачи, помогает с планированием, настраивает процессы в команде аналитиков? 

Расскажите, с какими проблемами вы сталкивались при организации работы нескольких аналитиков? Каких принципов придерживались?