Как требования заказчика превращаются в новые функции
Перевести пожелания бизнеса в рабочие возможности приложения – это непростой и очень важный процесс. За годы работы мы выработали алгоритм, который позволяет делать это быстро и эффективно.
В статье про продуктовый подход мы рассуждали о важности бизнес-ценности. Чтобы все участники процесса понимали, к какому результату нужно прийти, с первых шагов нужно начинать работу над фичей с бизнес-цели.
Что важно определить с самого начала:
- Кто будет работать с функцией?
- Какие задачи она будет решать?
- От каких забот избавит сотрудников?
Мы уже привыкли так смотреть на задачи – и когда строим мобильное приложение для клиентов, и в проектах по созданию корпоративных систем, и при проектировании внутренних сервисов для «подкапотной» обработки данных, команда первым делом определяется с практической потребностью. А при необходимости помогает и заказчику сформулировать таковую потребность – самому ответить на вопросы о том, зачем нужно делать ту или иную функцию.
Когда главная задача сформулирована, можно переходить к подготовке верхнеуровневых сценариев. На этом этапе команда определяется с тем, кто именно будет пользователями продукта, какие действия они будут выполнять, какие системные процессы будут этим действиям соответствовать, какие функции нужны администраторам.
Эта информация позволяет сформировать потоки данных, которые обеспечат будущие процессы. Определяется архитектура продукта, список рабочих микросервисов – пока без детализации, на концептуальном уровне.
Параллельно уже на этом этапе начинаем готовиться к разработке:
- Дизайнеры отрисовывают первые макеты
- PM заводит в трекере фичи и PBI, проводит предварительную оценку ресурсов
- Утверждаем с заказчиком план работ
- Разбиваем PBI на задачи, финально оцениваем ресурсы
- Разворачиваем инфраструктуру
На всем протяжении этого процесса мы держим в голове бизнес-ценность каждой задачи. При этом работа над фронтом, бэком и так далее не выносится в отдельные PBI. Это технические детали, которые объединены одной целью – например, сделать сервис авторизации пользователей. Такой подход позволяет всей команде вместе двигаться к результату, ради которого к нам пришел заказчик.
Что имеем в итоге
Все участники команды понимают, зачем каждый из них работает на своем участке – появляется общее видение задачи.
Это позволяет ускорить появление осязаемых результатов. Когда команда проводит демо каждые две недели, клиент постоянно видит все новые функции.
Продукт развивается быстро и энергично, time-to-market (время от начала работы над фичей до ее выпуска пользователям) сокращается. Сервис набирает очки по сравнению с конкурентами.
А самое главное – не бывает ситуаций, когда через несколько месяцев окажется, что какая-то функция не приносит пользы продукту и команда зря потратила ресурсы.
Еще на эту тему