Привет! Меня зовут Мария Аркуша, я продакт‑менеджер в Точка Банк. Сегодня хочу рассказать, как нам удалось ускорить и упростить процесс разработки и выкатывания новых фич в продукте.
Как мы работаем над фичами
Наша команда разрабатывает продукты для рекламы в Telegram. В разработке есть тимлид, два бэка и фронта, тестировщик. Периодически привлекаем дизайнера из других команд, а системного или бизнес‑аналитика нет.
Структура разработки у нас следующая:
Есть эпик, в котором мы описываем задачу, цель этапа разработки или MVP.
В юзер‑стори описываем конкретный функционал, который будет доступен клиенту. Чаще всего в эпике их несколько, может быть и около 10.
Задачи на бэкенд и фронтенд — они формируются внутри юзер‑стори.
Продукт относительно новый — мы начали его делать в 2024 году, релизы выкатывали нечасто. Обычно тратили 3–4 месяца на новую юзер‑стори.
Работа изначально строилась следующим образом: я с готовой и очень объёмной юзер‑стори приходила к команде разработки, объясняла, как именно хочу её реализовать, и мы вместе делили её на задачи, закидывали в эпик и пилили релиз.
В таком подходе было много сложностей, из‑за которых нам пришлось изменить подход к работе над релизами:
Юзер‑стори была большая и неповоротливая, работать над ней приходилось по 3–4 месяца.
Ребята на дейликах рассказывали о статусах задач на чисто техническом языке, который для меня был совершенно непонятен. Когда я смотрела на конкретную задачу и её статус, я не могла понять, насколько её выполнение приближает меня к цели — реализации полезной для пользователя фичи и выпуску релиза.
Из‑за того, что системного аналитика не было, логику работы новой фичи и формат реализации я продумывала сама. Единственное, что делали ребята — расписывали, как технически реализуются мои хотелки. Это сильно ограничивало идеи, лишало нас возможности найти какие‑то более простые и эффективные пути решения.
Задачи бэка и фронта шли вперемешку и не были выстроены относительно конкретной функциональности. Ребята набирали задачи в спринт, не ориентируясь на бизнес‑задачу и не синхронизируясь между собой. В результате часто случалось так, что в одной фиче сделан только бэк без фронта, или наоборот.
Какие цели изменений мы поставили перед собой
Быстрые релизы и прозрачность
Хотелось быстрее отдавать полезный функционал клиенту и понимать, на какой стадии находится разработка. А ещё получать эту информацию в разрезе клиентской пользы, а не технических фич.
Погружение всей команды в проработку идей
Мне было важно, чтобы члены команды активно принимали участие в грумингах, в том числе и разработка делилась своей точкой зрения и знаниями. Не хотелось быть «говорящей головой», которая рассказывает, что делать, без учёта мнения остальных.
Обсуждение деталей на одном языке
У меня нет крутых технических скиллов, и мне нужно было научиться говорить с разработчиками на понятном для нас всех языке.
Первый подход: бизнес-цель вместо готовой юзер-стори
Первая попытка что‑то изменить была следующей: я приходила на встречи сразу с бизнес‑целью, чтобы вовлечь ребят в обсуждение. Например, цель — предоставить возможность маркировать рекламу: такой запрос у рынка есть, если мы его обеспечиваем, сможем претендовать на X% рынка.
Суть подхода была такой: мы обсуждаем цель, тимлид (а не я) готовит юзер‑стори в технической логике. Саму цель заношу как эпик, а юзер‑стори делаем мелкими техническими задачами, которыми управляет тимлид.
Новый подход немного улучшил ситуацию:
Работа над фичами между бэком и фронтом синхронизировалась, потому что в одну юзер‑стори тимлид добавлял задачи и бэка, и фронта. Появилась возможность выкатить новую функциональность до полного релиза.
Команда стала более вовлечённой: я приходила не с готовыми решениями, а с идеями, которые нужно было развить, придумать, как их реализовать. А это как раз зона ответственности тимлида и разработчиков.
Тимлиду стало удобнее управлять процессом, так как реализацию юзер‑стори он продумывал и со мной, и с командой.
Но сложности оставались: задачи по‑прежнему формулировались на техническом языке, сходу мне было сложно понять, что сделано, а что нет. Я могла понять продвижение к пользе для клиента, только считая процент сделанных юзер‑стори.
Второй подход: учимся делать лучше
Нужно было совершенствоваться дальше. Для этого мы пошли к нашему Scrum‑мастеру Андрею Котову и прошли его воркшоп, чтобы научиться работать по модели «гамбургера».
Если кратко, суть модели в том, чтобы разбить юзер‑стори на понятные технические задачки‑слои, не потеряв связь этих задач с реализацией конкретной фичи.
Вверху — обязательные шаги, которые должен совершить пользователь, чтобы прийти к цели. В процессе обсуждения задачи сама последовательность шагов не важна.
Следующий слой — варианты реализации этих шагов. От самых простых до самых сложных, костыльных и так далее. Цель — брейнштормить идею и понять, какой вариант реализации нам удобнее.
Следующий слой — конкретные задачи. Решаем, как именно мы будем реализовывать нужные нам фичи и шаги.
Как работаем сейчас
Опираясь на модель «гамбургера» мы изменили наш подход к разработке.
Теперь я прихожу к команде со скелетом по шагам пользователя — CJM — который помогает понять, что именно получает клиент в рамках новой функциональности. Эти шаги уже становятся отдельными юзер‑стори, внутри которых мы накидываем варианты их реализации. На этом этапе в процесс вовлечена вся команда.
Затем мы выбираем реализацию, соблюдая баланс между ценностью и скоростью. Если мы хотим выпустится быстрее, придётся отказаться от какой‑то сложной реализации. И пусть релиз будет слегка «костыльным» — мы к этому готовы, так как расставили приоритеты. На эта же этапе формируем ожидания по срокам релиза.
Технические задачи — как именно сделать фичу разработка решает уже без меня. Я не мешаю им бесконечными вопросами, им не приходится «переводить» для меня технические термины. Так получается быстрее обо всём договориться.
Если есть вопросы, то обсуждаем их на встречах и фиксируем договорённости.
Тимлид возвращается ко мне, когда уже приняты решения, есть конкретные вопросы или расхождения по срокам.
Итоги
Сейчас вся команда задействована в генерации идей, а не я одна. Это помогает нам находить решения, к которому один человек точно бы не пришёл. Они, как правило, более креативные, порой более простые и быстрые.
Мы обсуждаем функционал, шаги пользователя, варианты реализации на понятном всем языке, его хватает для всех и мы отлично понимаем друг друга. На дейликах я вижу доску с юзер‑стори, которые понятны и мне, и членам команды. Я как менеджер понимаю, как идут дела и как продвигается реализация. И я вижу большую ценность в том, что и ребята из разработки активно подключатся к процессу: они видят, что их идеи становятся основной для нового релиза. В результате они больше проникаются продуктом, его судьбой и успехами.
Ну и сроки значительно сократились: сейчас мы можем собрать релиз за 1–2 месяца.
В то же время остались задачи, над которыми ещё нужно работать:
Интеграции. Мы молодая команда со стартап‑продуктом. Раньше сервис работал был сам по себе, с минимальными интеграциями внутри Точки. Сейчас мы активно интегрируемся разными сервисами для рекламы. Точно ещё съедим свой пуд соли и придём об этом рассказать.
Улучшения описания технических требований. В какой‑то момент мы столкнулись с последствиями недостаточного описания технических требований. Например, в описании указано, что нужно реализовать определённую логику, но подробностей — какие пути и сценарии это будет затрагивать — нет. В результате страдает качество разработки: количество багов растёт, решения принимаются по ходу разработки, что ухудшает структуру кода и усложняет поддержку. Сроки тоже растягиваются: разработчики тратят время на анализ и уточнение деталей, растут затраты на коммуникацию. Прорабатываем и этот момент.
-
Переход на Scrumban. Раньше Scrum работал хорошо, так как продукт был молодым: не было сложных интеграций, блокировок и частых пивотов на основе фидбека. Но были процессные сложности: снижение точности в оценке задач, нарушение планирования спринтов.
А ещё со временем появилась необходимость в исследованиях ML‑составляющей, где результат и сроки заранее не известны, что плохо совместимо с жёсткими спринтами. Из‑за этого мы решили отойти от классического Scrum и перешли к гибридной методологии — сочетание Kanban и Scrum («Scrumban»). Теперь мы используем гибкий подход: ежедневные синки, ретроспективы, демо; постоянная обратная связь от продукта и клиентов; возможность быстро менять контекст при блокировках.
Важное, что хочется сказать: не существует волшебной методологии «на все случаи жизни». Главное не бояться экспериментировать и искать тот способ работы, который подходит именно вашей команде и продукту. Мы начали с монолитных юзер‑стори и пришли к гибкой модели «гамбургера», которая дала нам главное — общий язык и фокус на ценности для клиента.