Автор статьи: Дмитрий Курдюмов
Участвовал в Аджайл‑трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом
Меня зовут Курдюмов Дмитрий, я более 7 лет управляю ИТ‑командами и провожу трансформации процессов. За это время я заметил одну распространенную проблему: проектные и продуктовые команды часто формулируют задачи с точки зрения технических решений, а не реальных потребностей пользователей. Это приводит к перегруженным и дорогостоящим продуктам, которые сложно разрабатывать и поддерживать.
Если сместить фокус с функциональности на реальные потребности пользователей, можно значительно сократить объем работы, уменьшить затраты и ускорить выход продукта на рынок. Давайте разберемся, как этого добиться.
Главная ошибка перед стартом разработки
Большинство команд начинают работу с формулирования задач в формате «что нужно сделать», а не «зачем это нужно пользователю». Это приводит к избыточным требованиям, длительному процессу разработки и большим затратам.
Пример: перегруженный личный кабинет
Допустим, перед командой стоит задача создать личный кабинет пользователя с системой накопления баллов и электронным кошельком.
Ошибка: сразу формировать длинный список фич и прорабатывать их детально, не задавая вопрос: зачем пользователю это нужно?
При таком подходе разрабатываются десятки ненужных функций, и бюджет разработки резко увеличивается. Вместо этого стоит сначала определить ключевую потребность пользователя и минимально возможное решение, которое эту потребность закроет.
Как избавиться от лишнего? Подход на основе пользовательских историй
Шаг 1. Определите потребности пользователей
Прежде чем писать технические требования, разберитесь, что на самом деле важно вашим пользователям. Для этого:
Проведите интервью с пользователями или исследование их поведения.
Выявите их основные триггеры и мотивы.
Запишите ключевые инсайты о том, что для них действительно важно.
Шаг 2. Формулируйте требования в формате пользовательских историй
Одна из эффективных техник — формулировка через пользовательскую историю:
Я как [роль/сегмент пользователя] хочу [что‑то сделать], чтобы [получить конкретную ценность].
Пример:
Я как покупатель хочу получать кэшбек за покупки, чтобы экономить бюджет.
Этот подход позволяет избежать ненужных фич. Например, если пользователь хочет копить кэшбек, нужно ли ему проходить регистрацию или можно обойтись без нее?
Чем меньше требований — тем быстрее и дешевле можно создать рабочий продукт.
Шаг 3. Обсудите истории с командой
Соберите команду (разработчиков, аналитиков, дизайнеров) и обсудите, как можно проще реализовать каждую историю.
Вместе продумайте минимальную версию решения.
Обсудите возможные альтернативные подходы.
Шаг 4. Приоритизируйте фичи и выстраивайте MVP
Определите самые важные элементы, которые позволят реализовать потребность.
Используйте User Story Mapping, чтобы выделить обязательные и второстепенные фичи.
Отложите на потом то, без чего можно обойтись в первой версии продукта.
Когда команда фокусируется на ключевых задачах, бэклог сокращается в несколько раз, а разработка становится быстрее и дешевле.
Реальные выгоды подхода
1. Снижение стоимости разработки
Один из моих клиентов — сервис доставки товаров — столкнулся с проблемой перегруженного бэклога. Планировалось, что разработка новой функциональности займет 12 месяцев, что требовало огромного бюджета.
Мы применили методику пользовательских историй и проверили, какие задачи действительно решают проблемы пользователей, а какие можно убрать. В результате:
Бэклог сократился в 3 раза.
Время разработки снизилось с 12 до 4 месяцев.
Экономия бюджета составила 24 млн рублей (из расчета зарплат 7 разработчиков).
Более того, после запуска Scrum и регулярной пересборки бэклога удалось дополнительно сократить объем задач еще на 20%, что дало еще 2 спринта экономии.
Таким образом, вместо года работы и больших затрат, компания получила работающее решение за 3 месяца, которое уже начало приносить доход.
2. Быстрый старт разработки без перегруженного анализа
Частая проблема — длительный этап анализа и написания детального ТЗ. В одном из проектов только этап анализа занял 6 месяцев, а затем еще 1,5 года ушло на разработку.
В итоге, вместо запланированного года работы, продукт разрабатывали 2 года — в два раза дольше и дороже, чем ожидалось.
Как можно ускориться?
Вместо детального ТЗ — сформулировать ключевые пользовательские истории.
К каждой истории добавить критерии приемки, чтобы было понятно, когда задача считается выполненной.
Дорабатывать детали по ходу работы, а не на старте.
Этот подход позволяет сократить фазу анализа и быстрее переходить к разработке, запуская продукт в реальную работу раньше.
Выводы: как делать быстрее, дешевле и лучше
Не фиксируйте решение заранее — сначала поймите, что нужно пользователю.
Формулируйте задачи в формате пользовательских историй, а не списков технических требований.
Постоянно пересматривайте бэклог, убирая лишние задачи.
Не тратьте месяцы на документацию — фиксируйте только ключевые истории и критерии приемки.
Вовлекайте в обсуждение решений команду, а не только аналитиков.
Фокус на пользователях и отказ от ненужных фич позволяет быстрее выходить на рынок, минимизировать затраты и эффективнее использовать ресурсы. Если вы хотите сократить бюджет разработки и ускорить запуск продукта — попробуйте применить эти принципы. Это реально работает!
Больше полезных материалов по Agile, управлению командами и трансформации процессов — в моем Telegram-канале. Подписывайтесь! А также приходите на менторство.
Какие компетенции должны быть у современного продакта? Должен ли продакт выполнять функции проджекта, маркетолога и бухгалтера? Как разные компании трактуют роль продакт-менеджера? Об этом и многом другом поговорим на открытом уроке 6 февраля. Участие бесплатное, нужна только регистрация.
Список всех открытых уроков февраля можно посмотреть в календаре мероприятий.
