Победа над хаосом: как мы улучшили работу системных аналитиков и настроили взаимодействие в большой команде
Привет, Хабр. Я Саша, системный аналитик в команде разработки мобильного приложения для банка. В этой статье расскажу, как мы вычисляли слабые места в работе команды аналитиков и как исправляли их, чтобы всё работало эффективнее.
Сначала немного контекста
В нашей команде 30+ человек, включая разработчиков, тестировщиков, аналитиков и дизайнеров.
Причины трудностей
Мы работаем по гибким методологиям, что позволяет проектировать и поставлять фичи в разработку итеративно, не стопоря процесс.
Команда разделена на подкоманды в зависимости от продукта, над которым они работают. При этом команда аналитиков состоит из нескольких человек. Это позволяет параллельно делать несколько фич. Но есть нюанс. Все работают в разных командах, а значит нет общего понимания, над чем работают коллеги и в каком виде ведут техническую документацию. С каждым новым аналитиком ситуация усложняется.
Так взаимодействие внутри команды стало уязвимостью, которая стопорила работу.
Вот проблемы, с которыми мы столкнулись:
Отсутствие коммуникации внутри отдела аналитики. Это мешало распределять задачи в зависимости от нагрузки коллег. У кого-то завал, у кого-то несколько небольших задач.
Ведение документации в разных форматах. Мы работаем в разных командах одного продукта, и каждый аналитик описывал документацию так, как считал правильным. Поэтому погрузиться в задачи коллег было трудно, мы тратили много времени, чтобы изменять документацию и поддерживать ее в актуальном состоянии.
Нет погружения в задачи друг друга. Как итог — команда не видит полную картину проекта. Появился высокий бас-фактор: аналитик знает только свои фичи, остальные не могут ответить на вопросы по ним.
Не прорабатываются точки пересечения задач.
Нужно было понять, как улучшить процессы и сделать работу каждого участника команды комфортной. Ничто так не пугает, как введение новых процессов. Но команда пошла навстречу.
Вот что мы решили после обсуждения
Разработали шаблон написания и ведения документации
Исходя из общего опыта коллег, мы пришли к шаблону, в котором сохранили золотую середину между техническим и пользовательским описанием поведения приложения.
Начали перекрестное ревью артефактов коллег
Его проводят все аналитики, независимо от уровня. Например, джун ревьюит сеньора и наоборот. Это полезно для всех: в том числе, для сеньора, который с высоты опыта может упускать некоторые детали.
Сделали коммуникацию постоянной
Начали регулярно синхронизироваться по статусу задач, блокерам, проблемам и статусам решения. Это позволяет постоянно обмениваться контекстом и быть в курсе дел друг друга, а также контролировать загрузку членов команды. Чтобы не перегружать команду, мы проводим созвоны раз в неделю и по необходимости изменяем частоту.
Какие итоги?
Мы пожили в новой реальности и почувствовали плюсы. Погрузились в задачи друг друга и смогли без труда заменять коллег во время отпуска или болезни. Знали точки пересечения задач и наконец равномерно распределили нагрузку среди команды.
А что, если проблемы были не только у нас?
Внедряя новые процессы у себя, задумались:, а что же происходит при взаимодействии с другими командами в процессе разработки?
Организовали встречу с разработчиками и тестированием и выяснили, что здесь тоже есть проблемные места. Большую часть вопросов мы решили, построив новые процессы. Но кое-что осталось:
разный уровень детализации документации
одинаковые элементы могут быть расписаны по-разному разными аналитиками
недостаточная коммуникация между подразделениями
Минимизируем противоречия между командами
Хотя у нас уже был шаблон, в зависимости от сложности процесса аналитик сам принимал решение, насколько детально расписывать документацию.
Для одинаковых элементов, которые используются в разных местах приложения, мы создали отдельные документы. В них описали поведение системы. Если такой компонент где-то встречается, мы больше не описываем его повторно, а даем ссылку на готовый документ. Так избегаем противоречий в работе одного и того же компонента.
Мы организовали встречи с командой разработки перед передачей задач. Это экономит время на погружение в детали, и формирует общее для всех понимание, как описанный процесс должен работать.
Нет инструкции или золотого правила, как построить идеальные процессы. В зависимости от проекта, объемов работы, команды и других факторов процессы будут отличаться, и это нормально. В разработке один из ключевых критериев, влияющих на качество продукта, — это взаимодействие внутри команды. Если оно отлажено, команде работает продуктивно. Если еще не отлажено — нужно искать того, кто этим займется.
Бонус. Идеальный состав команды разработки по нашему опыту
Размер команды зависит от разных факторов: сроков, сложности задач и т.д. Наши исходные данные вы помните: создаем мобильное приложение для банка.
Аналитик — связующее звено между всеми участниками процесса разработки. По нашему наблюдению, один аналитик без ущерба для сроков может работать в команде из восьми человек:
по два разработчика на платформе (если говорим про мобильную разработку)
тестировщик
дизайнер
менеджер проекта
опционально — продакт.
Если в команде больше дизайнеров или разработчиков, пора выделять еще одного аналитика.
Это был рецепт эффективности от команды Clevertec. Сталкивались с трудностями взаимодействия в команде? Поделитесь, как решали их.
