Как функциональные требования заказчика превращаются в новые функции

Разработка без четкого плана может привести к неожиданным результатам. Чаще всего – неприятным. Без него разработку и функционал одной фичи команды могут понимать по-разному.

Чтобы избежать этого, важно определить с самого начала работы над фичей следующие моменты:

• Кто будет работать над разработкой функции? 
• Какие задачи она будет решать? 
• От каких забот избавит сотрудников? 

Мы уже привыкли так смотреть на задачи – и когда мы строим мобильное приложение для клиентов, и в проектах по созданию корпоративных систем, и при проектировании внутренних сервисов для «подкапотной» обработки данных, мы первым делом определяемся с практической потребностью. А при необходимости помогаем и заказчику сформулировать таковую потребность – самому ответить на вопросы о том, зачем нужно делать ту или иную функцию.

Когда главная задача сформулирована, можно переходить к подготовке верхнеуровневых сценариев. На этом этапе команда определяется с тем, кто именно будет пользователями продукта, какие действия они будут выполнять, какие системные процессы будут этим действиям соответствовать, какие функции нужны администраторам.

Эта информация позволяет сформировать потоки данных, которые обеспечат будущие процессы. Определяется архитектура продукта, список микросервисов, которые обеспечат те или иные процессы – пока без детализации, на концептуальном уровне.

Параллельно уже на этом этапе начинаем готовиться к разработке:

• Дизайнеры отрисовывают первые макеты 
• PM заводит фичи и PBI, проводит предварительную оценку ресурсов 
• Утверждаем с заказчиком план работ 
• Разбиваем PBI на задачи, финально оцениваем ресурсы 
• Разворачиваем инфраструктуру 

На всем протяжении этого процесса мы держим в голове бизнес-ценность каждой задачи. При этом работа над фронтендом, бэкендом и так далее не выносится в отдельные PBI. Это технические детали, которые объединены одной целью – например, сделать сервис авторизации пользователей. Такой подход позволяет всей команде вместе двигаться к результату, ради которого к нам и пришел заказчик.

Что имеем в итоге

Создание продукта движется полным ходом. Все участники команды понимают, зачем каждый из них работает на своем участке – появляется общее видение задачи, понимание требований бизнеса.

Это позволяет ускорить появление осязаемых результатов. Когда команда проводит демо каждые две недели, клиент постоянно видит, как двигается разработка.

Продукт развивается быстро и энергично, time-to-market (время от начала разработки фичи до ее выпуска пользователям) сокращается. Сервис набирает очки по сравнению с конкурентами.

А самое главное – не бывает ситуаций, когда через несколько месяцев окажется, что какая-то функция не приносит пользы продукту и команда зря потратила ресурсы.

Почему мы?

Мы - за системный подход, и эта система должна работать на цели бизнеса. Опираясь на нашу экспертизу в проектировании продуктов с нуля, мы готовы провести вас «за руку» по всем этапам разработки: от идеи и формирования функциональных требований до вывода продукта в эксплуатацию в минимальные сроки (в этой статье делимся, как мы сокращаем сроки поставки ценности). Это качается как сложных систем, так и веб- и мобильных приложений. Свяжитесь с нами, и мы проведем для вас полное предпроектное обследование бизнеса 😊

Еще на эту тему

Простые и полезные метрики для эффективной продуктовой разработки