Данную статью написали Александр Чекунков, Android-разработчик, и Антон Ушаков, аналитик. Мы работаем в СБЕРе и ежедневно взаимодействуем, чтобы превращать бизнес-требования в понятные, логичные и реализуемые решения. В своей работе мы ежедневно сталкиваемся с процессами формирования требований, их обсуждения, реализации и доставки фичи до промышленных стендов. От того, насколько правильно выстроена наша работа, напрямую зависит скорость и качество разработки продукта.
В этой статье мы рассмотрим зоны ответственности обеих ролей и покажем, как, по нашему мнению, должен выглядеть идеальный процесс взаимодействия. Наша цель — помочь командам выстроить прозрачное и продуктивное взаимодействие, избежать типичных ошибок и сделать совместную работу более эффективной.
Зоны ответственности аналитика и разработчика
В нашей команде эффективное взаимодействие аналитика и разработчика начинается с чёткого понимания их зон ответственности. Границы между этими ролями не всегда очевидны, что может приводить к недопониманию и задержкам, поэтому разделим зоны ответственности и выделим ключевые этапы работы.
Начнём с аналитика.
Точно определить зоны ответственности аналитика достаточно сложно, так как это зависит от множества факторов: его специализации (бизнес-аналитик или системный аналитик), набора навыков, сложности проекта и принятых в компании критериев.
В нашей практике встречались случаи, когда в одном проекте аналитик занимался только сбором и обсуждением требований, а на другом — прорабатывал архитектуру модулей, методы A/B-тестирования, интеграции и т. д.
Поэтому ответственность обычно определяется установленными правилами для данной роли в текущей команде. Если говорить про набор пунктов ответственности аналитика в нашей команде, то это:
Согласование, уточнение и сбор бизнес-требований. Любая фича начинается с идеи (требования), которая проходит несколько этапов фильтрации. Один из этих этапов — сбор, уточнение и согласование деталей, которыми у нас занимается аналитик. Например, если требование сформулировано неполно или неоднозначно, либо планируемые затраты времени команды кажутся чрезмерными, то аналитик уточняет все детали, задавая вопросы. Он проводит дополнительное исследование, оценивает возможные варианты реализации и определяет потенциальные риски.
Проработка визуального решения совместно с дизайнером. Если реализуемая фича затрагивает пользовательский интерфейс, то аналитик участвует в создании макетов и согласовании UI/UX-решений. Аналитик согласовывает с внутренним или внешним дизайнером работу и передаёт собранные требования. Если дизайнера нет, то аналитик самостоятельно готовит макеты в удобном формате — будь то блок-схемы, наброски или прототип в Figma или Pixso, — чтобы разработчики получили понятное представление о будущей фиче.
Подготовка всей проектной документации. Набор проектной документации зависит от конкретного проекта и его масштаба. Аналитик должен понимать, какая документация необходима на каждом этапе релизного процесса. Он может подготовить её заранее перед началом разработки или оформить постепенно, адаптируя к изменяющимся требованиям. Важно, чтобы к моменту реализации у команды был доступ ко всей необходимой информации.
Постановка задач разработчикам. После завершения проектирования аналитик определяет, кто из разработчиков будет реализовывать задачу, и готовит всю необходимую информацию. Он прописывает чёткие критерии готовности, прикрепляет макеты, технические спецификации и примеры данных, чтобы исключить неоднозначность и ускорить процесс разработки.
Участие в приемо-сдаточных испытаниях. Если в рамках релизного процесса есть пункт о проведении испытаний или показ бизнес-заказчику, то при отсутствии выделенной роли delivery-менеджера организацией этой встречи занимается аналитик и также принимает участие в показе. После завершения разработки и тестирования он организует презентацию для заинтересованных сторон. Показывает ключевые сценарии работы и объясняет, какие бизнес-проблемы решает новый функционал. Если требуется демонстрация технических аспектов (журналирования, рубильников, механизмов защиты данных), то аналитик координирует эти показы, привлекая соответствующих специалистов.
Теперь разберем круг обязанностей мобильного разработчика.
В Сбере мобильный разработчик — это не просто исполнитель, превращающий требования в код. Его работа начинается задолго до первой строчки кода и состоит из нескольких ключевых этапов:
Разбор требований и выявление скрытых нюансов. Прежде чем приступить к реализации, разработчик внимательно изучает документацию и задает вопросы аналитику. Например, если в ТЗ указано «добавить кастомную анимацию переключения экранов», то разработчик уточняет: должна ли она быть платформенной (стандартная API-анимация) или кастомной (разработка с нуля), какие есть требования по времени выполнения, и влияет ли это на навигацию приложения.
Техническое проектирование. Разработчик выбирает архитектурный подход, продумывает, как новая фича впишется в текущий код и какие модули придется изменить. Например, если в приложении реализуется сложный экран с зависимыми состояниями, то разработчик анализирует, какой лучше архитектурный подход выбрать.
Исследование технологий и инструментов. Перед началом реализации разработчик проверяет существующие решения, ищет лучшие практики, оценивает, нет ли готовых библиотек, которые упростят задачу. Например, если бизнес хочет добавить поддержку считывания QR-кодов, разработчик анализирует, можно ли использовать ZXing или ML Kit от Google, и выбирает оптимальный вариант.
Реализация и оптимизация. Код должен быть не только рабочим, но и поддерживаемым. Разработчик думает о будущем: как код будет масштабироваться, как его упростить и сделать удобным для других членов команды. Например, при добавлении поддержки тёмной темы разработчик учитывает, какие цвета из дизайн-системы уже доступны, какие придётся кастомизировать, и может предложить ограничить палитру, чтобы избежать проблем с контрастностью.
Тестирование и проверка решений. Разработчик проверяет, соответствуют ли реализованные сценарии требованиям, пишет unit и UI тесты. Например, если приложение поддерживает работу в офлайне, то разработчик проверяет, корректно ли кэшируются данные, что происходит при восстановлении соединения, и нет ли ситуаций, когда пользователю показывается устаревшая информация без попытки обновления.
Обратная связь и улучшение требований. В процессе работы разработчик оценивает реализуемость требований и даёт аналитику обратную связь. Если что-то можно сделать проще, быстрее или стабильнее, то предлагает альтернативные варианты. Например, если аналитик предлагает загружать список товаров одним запросом, но в системе 100 000 позиций, то разработчик предлагает использовать пагинацию и кэширование, чтобы избежать долгой загрузки и проблем с потреблением памяти.
Для нас каждый из этих этапов критически важен: от тщательной подготовки зависит скорость и качество разработки, а грамотное взаимодействие с аналитиком помогает избежать проблем и доработок.
Где разработчик может помочь аналитику
Любая разработка ПО предполагает командное взаимодействие, и без коммуникаций почти невозможно вывести качественный продукт. В нашей команде разработчик всегда приходит на помощь аналитику. В основном в этих случаях:
Документация. На своём профессиональном пути мы сталкивались с проблемой отсутствия необходимой документации (или её неактуальности). В этом случае, разработчик как никто другой может помочь восстановить понимание актуального состояния системы или функционала, просто изучив код.
Консультация. При проектировании систем со сложной логикой, интеграциями и высокой нагрузкой, где важна каждая доля секунды отклика, аналитику часто приходится консультироваться с разработчиком при проектировании решений и архитектуры, чтобы выбрать оптимальное, которое будет удовлетворять всем условиям и требованиям.
Инциденты. Часто аналитик участвует в разборе инцидентов и помогает пользователям в решении возникших проблем. В таком случае разработчик может помочь разобраться в уникальных ситуациях и определить, относятся ли проблемы к разрабатываемой системе или это ошибки на стороне других команд.
Где аналитик может помочь разработчику
Как уже говорили выше, чтобы создать надежное решение необходимо постоянно коммуницировать. Если разработчик помогает аналитику разобраться в технических нюансах, то и аналитик, в свою очередь, упрощает работу разработчика, обеспечивая его всей необходимой информацией. Вот несколько ключевых ситуаций, когда помощь аналитика становится особенно ценной:
Бизнес-логика и пользовательские сценарии. Иногда требования могут казаться очевидными, но без понимания всей бизнес-логики разработчик может упустить важные детали. В нашей практике принято, чтобы аналитик помогал увидеть картину целиком и объяснял, почему фича реализуется именно так.
Гайдлайны. Зачастую у компании есть внутренние руководства или cookbook’и (инструкции по настройке, интеграции, тестированию и развертыванию). Аналитик находит и передает их разработчику, сокращая время на поиски.
Доступы. Разработчику часто требуются доступы к различным средам, тестовым данным или API, и получение этих доступов может занять значительное время. Аналитик помогает ускорить процесс, взаимодействуя с соответствующими командами и оформляя запросы.
Обратная связь. Разработчик должен понимать, как его решения влияют на пользователей, но часто у него нет прямого доступа к отзывам, поэтому аналитик собирает и анализирует обратную связь, чтобы команда могла адаптировать продукт под реальные нужды.
Как выглядит наш процесс взаимодействия
Разобравшись с зонами ответственности аналитика и разработчика, логично перейти к тому, как на практике должно строиться их взаимодействие. Мы хотим поделиться своим опытом и показать, как у нас в команде выстроено взаимодействие на примере реальной задачи: внедрения в приложение СБОЛ новой фичи под названием «Матричный тип вопроса».
Немного о фиче. Мы разрабатываем CSI-опросы в мобильном приложении «СберБанк Онлайн» и отвечаем за функциональность, которая помогает бизнес-командам собирать обратную связь от клиентов. «Матричный тип вопроса» позволяет клиенту отвечать сразу на несколько вопросов в рамках одного экрана, выбирая из одинакового набора вариантов по одной шкале. Пример:
Формирование требований
Перед началом работы мы изучили материалы предыдущих попыток реализации этой задачи: ознакомились с протоколами встреч и эскизами требований.
Основные сложности возникли на этапе проектирования макетов. Не было очевидного решения, как компактно разместить несколько вопросов на небольших экранах мобильных устройств, сохранив удобство взаимодействия и читабельность. Проработка затянулась и в итоге была приостановлена из-за нехватки времени у дизайнера, который на тот момент уже покинул команду. В результате решили пересмотреть подход и начать с нуля.
Нужно было реализовать матричный тип вопроса таким образом, чтобы он корректно отображался даже на устройствах с небольшой диагональю экрана, обеспечивая удобство заполнения и восприятия информации. Мы изучили существующие решения на рынке и взяли за основу подходы, используемые в Google, Яндекс и Webim. Опираясь на их опыт, сформировали референсные макеты и согласовали финальное решение с командой СберБанк Онлайн.
Обсуждение ТЗ
После появления первых версий аналитики мы провели серию обсуждений, чтобы детально проработать все нюансы реализации.
Одним из ключевых вопросов стало взаимодействие мобильного приложения с бэкендом. Мы согласовывали контракт данных: какие поля будут передаваться, в каком формате, какие значения могут быть обязательными или опциональными. Нам важно было убедиться, что бэкенд корректно передаст структуру вопросов и возможные варианты ответов, а мобильное приложение сможет без проблем их обработать и отобразить.
Отдельное внимание мы уделили дизайну и пользовательскому опыту. Вместе с дизайнером проработали, как должен выглядеть UI, чтобы оставаться интуитивно понятным и удобным. Обсуждали, как оформить заголовки вопросов, каким должен быть окрас чипсов (вариантов ответов) и как их визуально выделять при выборе. Важно было сделать так, чтобы пользователи сразу понимали, какие элементы интерактивны, а какие — просто информативны.
Ещё одним важным аспектом стал UX поведения экрана. Мы обсуждали, как должен работать скролл, если пользователь забыл ответить на вопрос. По умолчанию экран не должен автоматически прокручиваться, но если человек попытается нажать «Продолжить» без ответа, то система должна подсветить незаполненные поля и направить пользователя к первому пропущенному вопросу. Это помогает избежать путаницы и делает заполнение опроса более удобным.
После всех обсуждений и доработок ТЗ, появилось чёткое понимание того, как должна работать и выглядеть новая фича. Согласовав все детали, можно было перейти к реализации.
Разработка
Первым шагом стало проектирование UI-части. Определяли, в каком именно месте будем добавлять новую Compose-функцию, чтобы она корректно встраивалась в существующую систему экранов опросов.
На уровне бизнес-логики прорабатывали алгоритмы разделения вопросов и ответов, чтобы presentation-слой мог удобно работать с этой структурой. Реализовали механизмы хранения данных. Также учли обработку незаполненных вопросов, чтобы корректно управлять состоянием экрана и пользовательским взаимодействием.
Разработка UI-компонента в Jetpack Compose потребовала особого внимания к производительности. Писали Compose-функцию, включающую в себя заголовки, чипcы выбора и механизм пролистывания. Чтобы избежать ненужной нагрузки на устройство, оптимизировали экран. Дополнительно провели тесты, чтобы убедиться, что даже при большом количестве вопросов и вариантов ответов экран остаётся отзывчивым.
Параллельно с разработкой писали unit-тесты, проверяющие основные сценарии работы бизнес-логики: корректность обработки ответов, изменение состояния вопросов, восстановление данных и отправку ответов на сервер.
В процессе работы регулярно возникали небольшие вопросы, поэтому мы взаимодействовали с аналитиком для уточнения деталей. Это помогало быстрее принимать решения и оперативно корректировать логику, если в ходе реализации выявлялись потенциальные проблемы.
Изменения в требованиях
В ходе разработки обнаружилось, что цвет блокировки варианта ответа, используемый в платформе, значительно отличается от того, что было заложено в макетах, и сливается с общим фоном экрана, делая его малозаметным. Проблема требовала срочного решения, так как могла поставить под угрозу сроки разработки.
Для оперативного выхода из ситуации организовали встречу всех ключевых участников проекта. Аналитик и разработчик совместно пришли к самому дешевому решению: добавить кастомный цвет в инструментарий. Изменения оперативно внесли в документацию аналитики, согласовали их с сопровождающими ролями и экспертом по безопасности, после чего уже через два дня обновлённая версия появилась на тестовых стендах.
Такая скорость и слаженность работы в крупных корпорациях возможна только при глубоком понимании всех процессов аналитиком и разработчиком. В противном случае процесс мог бы быть надолго заблокирован из-за отсутствия формализованных путей решения проблемы.
Проверка, испытания и выпуск
На финальном этапе провели полный регрессионный тест всего модуля опросов. При выявлении ошибок требовалась оперативная синхронизация сразу трёх ролей: тестировщика, аналитика и разработчика.
Поскольку изменения затрагивали существующую функциональность, приходилось обращаться к документации предыдущих фич и сверять её с актуальным кодом. Благодаря слаженной работе всех участников процесса удалось быстро выявить и устранить проблемы, обеспечив стабильность и корректную работу новой функциональности.
Вывод
Этот пример наглядно показывает, насколько важны слаженная работа команды, чёткое распределение зон ответственности и готовность быстро адаптироваться к изменениям. Гибкость в принятии решений, постоянная синхронизация аналитиков и разработчиков, а также общая нацеленность на конечный результат позволили нам эффективно реализовать сложную и нетиповую фичу без критических задержек.
Благодаря взаимопониманию и оперативному взаимодействию на всех этапах — от проработки требований до релиза — мы не только успешно внедрили новую функциональность, но и сделали это с учётом всех технических и UX-ограничений. Это ещё раз доказывает, что идеальный процесс взаимодействия строится на ответственности, доверии и общем стремлении сделать продукт лучше.
