Привет, Хабр. Я Саша, системный аналитик в команде разработки мобильного приложения для банка. В этой статье расскажу, как мы вычисляли слабые места в работе команды аналитиков и как исправляли их, чтобы всё работало эффективнее.

Сначала немного контекста

В нашей команде 30+ человек, включая разработчиков, тестировщиков, аналитиков и дизайнеров.

Причины трудностей

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

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

Так взаимодействие внутри команды стало уязвимостью, которая стопорила работу.

Вот проблемы, с которыми мы столкнулись:

  • Отсутствие коммуникации внутри отдела аналитики. Это мешало распределять задачи в зависимости от нагрузки коллег. У кого-то завал, у кого-то несколько небольших задач.

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

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

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

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

Вот что мы решили после обсуждения

  1. Разработали шаблон написания и ведения документации

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

  1. Начали перекрестное ревью артефактов коллег

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

  1. Сделали коммуникацию постоянной

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

Какие итоги?

Мы пожили в новой реальности и почувствовали плюсы. Погрузились в задачи друг друга и смогли без труда заменять коллег во время отпуска или болезни. Знали точки пересечения задач и наконец равномерно распределили нагрузку среди команды. 

А что, если проблемы были не только у нас?

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

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

  • разный уровень детализации документации

  • одинаковые элементы могут быть расписаны по-разному разными аналитиками

  • недостаточная коммуникация между подразделениями

Минимизируем противоречия между командами

Хотя у нас уже был шаблон, в зависимости от сложности процесса аналитик сам принимал решение, насколько детально расписывать документацию. 

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

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

Нет инструкции или золотого правила, как построить идеальные процессы. В зависимости от проекта, объемов работы, команды и других факторов процессы будут отличаться, и это нормально. В разработке один из ключевых критериев, влияющих на качество продукта, – это взаимодействие внутри команды. Если оно отлажено, команде работает продуктивно. Если еще не отлажено – нужно искать того, кто этим займется.

Бонус. Идеальный состав команды разработки по нашему опыту

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

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

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

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

  • дизайнер

  • менеджер проекта

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

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


Это был рецепт эффективности от команды Clevertec. Сталкивались с трудностями взаимодействия в команде? Поделитесь, как решали их.

Комментарии (2)


  1. vowender
    13.09.2024 05:05

    Добрый день! Тоже сейчас столкнулся с похожими препятствиями в команде. Каждый работает по-своему и не в курсе изменений в общих процессах, которые касаются всех. Прочитав ваш материал, понимаю, что мы встаем на верный путь. Осталось это довести до привычки. Благодарю за материал!


    1. Clevertec_dev Автор
      13.09.2024 05:05

      Добрый) В статье это не описано, но нам конечно тоже понадобилось время, чтобы привыкнуть жить по-новому. Не скажу, что было легко. Но получилось, и у вас получится.