Как мы улучшали коммуникацию между командой разработки и аналитиками
Как мы улучшали коммуникацию между командой разработки и аналитиками
Привет! Меня зовут Валентин Дементов, я занимаюсь системным и бизнес-анализом уже 10 лет. За это время я успел поработать в проектах в сферах госсектора, энергетики, строительства и медицины. Сейчас я развиваю инвестиционные банковские продукты в Газпромбанк.Тех.
В этой статье наш практический кейс. Расскажу, как в командах стрима «Инвестиции» мы пытались решить проблему «требования vs разработка» и что у нас получилось: как объясняли инженерам, что хочет бизнес, чтобы они действительно поняли, что от них нужно. А еще как сделать планирование прозрачным и понятным для всех, чтобы каждый находился в контексте задач.
Один из новых подходов, которые мы попробовали в команде, называется «Три карандаша». Этот метод был разработан коллегами из департамента Agile-трансформации и активно применяется во многих командах Розницы. Используя его, команда визуализирует будущее решение при обсуждении постановок и требований к разработке банковских систем.
Рисовать идеи — обычная практика. Многие начинают с набросков на бумаге, но некоторые пропускают этот шаг и сразу приступают к написанию кода. Когда команды разработки перешли на удаленную работу, исчезли и обычные обсуждения у доски.
Есть разные методы, где используются рисунки: CJM, USM [+UI], event storming, C4 и другие. Каждый прием решает конкретные задачи: показать общую картину развития продукта, описать хорошие пользовательские истории, помочь на этапе бизнес-анализа и планирования.
По методу «Три карандаша» мы рисуем клиентский путь на пользовательских интерфейсах, а поверх него добавляем бэковую часть и внешние зависимости. Дальше я расскажу вам и про сам метод, про то, как мы адаптировали его в своей команде, и приведу реальные отзывы коллег об этой практике. Покажу примеры схем, прототипов и других визуальных методов, которые мы использовали, чтобы разработчики и тестировщики лучше понимали требования от аналитиков, а аналитики четко формулировали задачи.
Почему такая коммуникация стала важна для нас
- Текущие шаблоны требований к разработке это в основном текст, хотя графика для команды при обсуждении удобнее и понятнее.
- Текст, каким бы подробным и структурированным он ни был, — это не гарантия понимания. Люди могут интерпретировать его по-разному, а иллюзия консенсуса опасна.
- Объем работы часто кажется меньше, чем есть на самом деле, особенно когда все представляют задачу по-своему.
- И главное: если потенциальные риски не выявлены в начале, их устранение позже потребует больше ресурсов.
Как сделать обсуждение понятнее? Мы решили начать рисовать. Картинки помогают выявить расхождения в восприятии. Если что-то кажется непонятным — нарисуй! Это может быть сложная часть пользовательского сценария или список условий для тестирования. Рисовать может любой член команды, не только аналитики. Даже если это займет время, оно окупится: в процессе часто возникают новые идеи или вопросы.
«Я визуал, поэтому мне так проще воспринимать информацию без длинных описаний. Потом еще и как шпаргалка пригодится»
Начали с анализа требований — бизнесовых и технических. Часто в таких случаях один специалист берет на себя обе роли: и бизнес-аналитика, и системного аналитика.
Обычно в бизнес-анализе используют схемы (например, BPMN), которые показывают последовательность действий или потоки данных. Раньше мы обходились без них, заменяя их короткими текстовыми требованиями, отфильтрованными согласующими департаментами.
Потом эти требования переходили к системному аналитику, который превращал их в форму технических заданий в Confluence и задачи в JIRA. Такой подход делал аналитика «бутылочным горлышком» — все зависели от его интерпретации.
«Хватит обмениваться документами. Начните обсуждать!»
После обучения методу «Три карандаша» мы изменили формат обсуждения задач. Прежде это были часовые встречи, где участники смотрели на макеты и пытались примерно оценить сроки анализа, разработки и тестирования.
● Неточные оценки, из-за которых срывались сроки
● Требования, которые всплывали уже на тестировании, возвращали задачу в начало
● Расхождения между тем, что описали аналитики, и тем, что сделали разработчики. Такая ситуация дополнительно снижала мотивацию тестировщиков
Первым изменением стало разделение встреч на две: для бизнеса и для технических вопросов.
Бизнес-обсуждение нужно, чтобы разбить крупные задачи (эпики) на мелкие (пользовательские истории) и спроектировать пользовательские интерфейсы. Такое обсуждение ведет бизнес-аналитик. Еще в обсуждении участвуют владелец продукта, системный аналитик, технический лидер и коллеги из смежных команд, если мы уже сейчас понимаем, что будем от них зависеть. Основной инструмент — карта пользовательских историй (USM), которая основана на карте клиентского пути (CJM).
В процессе обсуждения мы делим эпик на пользовательские истории, а если требуется, дополнительно делим их на еще более мелкие, реализуемые в один спринт. Вместе с владельцем продукта мы выбираем оптимальное бизнес-решение. Затем определяем, какие истории ценнее всего, они и ложатся в основу будущего MVP. Их мы сделаем в первую очередь. Последний шаг этого этапа — обсуждение деталей дизайна пользовательских интерфейсов.
Пример схемы небольшой задачи:
Затем наступает время инженерного груминга «Три карандаша»
Техническое обсуждение помогает определить, какие сервисы или автоматизированные системы требуют доработки. Еще оно нужно для оценки сложности задачи и согласования интеграций с другими командами разработки. Для построения диалога разработчиков с аналитиками при обсуждении реализации нового функционала или доработки метод «Три карандаша» рекомендует придерживаться трех простых принципов:
Жизненный цикл UI. Разбиваем обсуждение интерфейса на три этапа: что происходит с ним при запуске (инициализация UI), как он работает во время использования (работа пользователя на UI) и что происходит при закрытии (выход пользователя с UI). Это помогает избежать упущенных деталей и лучше понимать логику поведения пользователя и приложения.
«Три карандаша». Применяем цветовую маркировку:
● Синим отмечаем готовые решения, которые можно переиспользовать без изменений.
● Зеленым — мы знаем, как изменить решение и договорились об этом здесь и сейчас.
● Красным — непонятные моменты, требующие дополнительного исследования
Необходимость и достаточность. Придерживаемся умеренной глубины погружения в технические детали на этапе обсуждения и не даем команде утонуть в нюансах реализации раньше времени. Схемы делаем понятными, без лишней сложности. Митинги — короткие, с сохранением фокуса на сути, а не на мелочах.
Еще одно изменение: техническое обсуждение начинается с готовой карты сценариев из бизнес-встречи. Для проведения встречи с командой разработки мы готовим шаблон для технического обсуждения.
Шаблон устроен просто: в центре — путь клиента, с которым работает аналитик. Ниже — наш бэкенд, за него отвечают разработчики. А выше — внешние системы, на которые мы не влияем напрямую, так что без договоренностей с другими командами не обойтись.
Во время обсуждения участники задают вопросы, а аналитики и владелец продукта отвечают на них. Проходим по каждому шагу сценария, определяем, что нужно доработать на фронтенде и бэкенде. Разбираемся, какие данные передавать, как их обрабатывать, куда они должны попадать и какие у них должны быть форматы.
Постепенно выстраивается схема взаимодействия интерфейса с сервисами. Важные вопросы без однозначного ответа выделяем красным в соответствии с цветовой маркировкой. После проработки основного сценария добавляем проверку ошибок и исключений, можем дополнительно провести декомпозицию с учетом реализации.
Результаты
Приведу обратную связь от коллег:
Это отличное решение, которое наглядно показывает:
● Какие цели и задачи стоят перед командой
● Как будет проходить бизнес-процесс
● Какие компоненты системы затрагиваются
● Какие компоненты системы требуют доработки
Благодаря тому, что на подобной визуализации информация агрегирована из множества источников (БТ, макеты дизайна, архитектурные требования и не только) команда получает полное представление о предстоящих работах. Кроме того, подобная визуализация позволяет «припарковать» вопросы, которые возникают в ходе обсуждения, благодаря чему проработка становится более детальной, а полученная информация находится в одном месте, что упрощает процесс погружения в детали
По поводу визуализации фидбэк однозначно положительный, очень помогает при обсуждении задач, особенно запомнилось при принятии решения о внедрении процесса изменения печатных форм, когда было на схеме видно, что изначальный вариант не рабочий
Польза очевидна. Я теперь сам буду использовать эту технику. Простая и понятная. Дает возможность быстро переложить на схему верхнеуровневый процесс по новой фиче или доработке, процесс становится максимально наглядным не только для инициатора изменений, но и для команды и партнера. Дает возможность переложить в визуал то, что могло долго обсуждаться словами
Первый раз она мне помогла ориентироваться по тому, как работает сервис, без лишних вопросов к вам. У нас вообще часто возникают вопросы по тому, как все будет работать «под капотом», потому что нам так проще понимать ограничения и пространство для маневра
Трудности
Часть команды сначала не понимала, зачем тратить время на рисование схем. Но после нескольких встреч даже скептики увидели пользу. Осталось убедить коллег, что рисовать могут все.
Преимущества рисунков
● Помогают заметить пропущенные детали
● Двойная польза: пока рисуешь, находишь слабые места в постановке и требованиях, а из-за наглядности другие быстрее их понимают
Недостатки
Схемы нужно поддерживать в актуальном состоянии, и это ложится на того, кто их создал.
Инструменты для рисования
Выводы
Спустя месяц мы провели четыре задачи через новый процесс обсуждения с рисованием. Время от постановки до передачи в разработку уменьшилось за счет сокращения общей продолжительности встреч. Мы стали в три раза быстрее брать из бэклога обсужденные задачи в спринт.
Раннее включение команды разработки повлияло на то, что ни одна задача не вернулась с разработки или тестирования на уточнение аналитики. Все требования были достаточно полными и однозначными, а формулировки и термины были сразу оговорены и зафиксированы.
Для простых задач хватит бумаги и ручки. Для сложных — подойдет любой инструмент, даже Paint. Важно не качество рисунка, а ясность мысли. Чем проще — тем лучше.
Пара слов от автора метода «Три карандаша»:
Метод инженерного груминга и декомпозиции “Три карандаша” изначально создавался, как простой, интуитивно понятный и адаптируемый командами инструмент. Не существует каких-то “правильных Трёх карандашей” (если только они не синий, зелёный и красный J ), но существует магия достижения общего понимания будущего решения, незаметного прорастания в команде кроссфункциональности разработчиков, роста точности планирования и своевременного согласования планов работ со смежниками и достижения с ними договорённостей по инженерным контрактам. Всё то, без чего разработка любого продукта в крупной организации практически невозможна.
Валентин прошел обучение по курсу Каскадный грумминг и декомпозиция и Инженерный груминг “Три карандаша”, который на регулярной основе проводят Департамент Agile трансформации и Центр экспертизы бизнес-анализа Розницы. Затем он самостоятельно внедрил практику в свою команду. Ожидаемо, что практика визуально адаптировалась под команду, начала своё самостоятельное развитие. Это видно невооруженным глазом и является явным признаком обдуманного применения метода. Главный результат – предсказуемость, общее понимание и всё что я описал ранее перешло в команде на принципиально более высокий уровень, и этот уровень будет только расти.
Более подробно о каскадном груминге и инженерном груминге «Три карандаша» сейчас можно узнать на конференциях и в публикуемых тезисах. Например, здесь.
Департамент Agile трансформации Центр экспертизы бизнес-анализа Розницы активно внедряют методы каскадного груминга и декомпозиции в команды нашего банка. В процессе внедрения, проявляется много интересной специфики, связанной с особенностями продуктов и платформ. Например, сейчас активно исследуется применение метода в ETL и при строительстве хранилищ данных.
Но самое главное, что метод создавался инженером для инженеров: чтобы было просто, наглядно и экономило время. Опыт команды Валентина и других команд показывает, что так он и работает.
Департамента инженерной экспертизы и инструментов разработки