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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Какие итоги?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• дизайнер

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

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

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

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