Технологический продукт: что необходимо и достаточно для реализации кроме идеи и денег
В нескольких последних проектах — где мы участвовали как консультанты, трекеры, исследователи или менеджеры — мы снова и снова сталкивались с граблями: писать код по повествовательному описанию идеи стейкхолдеров.
Между «идеей» и «кодом» лежит целый мир требований. Это слои уточнений, которые позволяют программисту не работать в парадигме «я так чувствую», а сделать продукт востребованный на рынке.
В классике, например, у Карла Вигерса в «Разработка требований к ПО» — это целая экосистема:
- бизнес-требования,
- бизнес-правила,
- пользовательские требования,
- атрибуты качества,
- системные требования,
- функциональные требования,
- внешние сервисы и ограничения.
И только потом
- спецификация требований к ПО
которую можно отдавать разработчикам.
На практике же бывает иначе. Один из кейсов: заказчик ожидал, что разработку интерфейса и проектирование клиентского пути делает front-end разработчик, и посчитал его джунишкой, потому что тот действовал «как чувствовал» в отсутствии требований и user-flow. Результат — мимо ожиданий и стейкхолдера и рынка.
☕️ Идеи, проектного менеджера и команды разработки недостаточно.
Сегодня горизонт планирования очень короткий. Пока пишется толстое ТЗ, момент выхода на рынок может быть упущен, а сама идея устареть.
Рабочий минимум, который удалось нащупать нам и который экономит время, деньги и минимизует разрыв ожиданий с результатом:
💲 Бизнес-требования — формализация того, зачем мы делаем продукт, какую проблему решаем и какие бизнес-цели всех участников закрываем.
🖥 Экраны в Figma — мостик между замыслом и реализацией. Самый дешевый способ синхронизировать команду и получить предсказуемый результат. Не обязательно делать супердетализацию, варфреймы и мокапы тоже хороши. Даже сырые экраны фиксируют user-flow, показывают сценарии использования и помогают всем участникам разговаривать на одном языке. Для бизнеса — это визуализация того, что будет «на руках» у клиента, для команды — конкретика, что именно собрать, для пользователей — первый способ дать обратную связь.
🍔Архитектура решения — мы любим «готовить» в нотации C4. Когда экраны готовы, можно сложить архитектуру, которая превратит их в работающий сервис. Она помогает сформировать скоуп итерации, оценить бюджет довольно близко к реальности, детализировать текущее и при этом оставить возможность масштабировать решение в будущем.
🍿 Дорожная карта. то, что связывает рабочий минимум с будущим развитием. Даже на раннем этапе полезно зафиксировать гипотезы, в какой последовательности и в каких версиях продукт будет расти. Roadmap помогает команде видеть картину шире, не путать MVP с конечным продуктом и вовремя принимать решения: что войдёт в первую итерацию, а что можно отложить. Конечно, понимать сколько это стоит и какие метрики стоит загадывать в результат итерации.
⚡️ Такой быстрый путь работает только если в команде все на уровне senior+, и умеют закрывать пробелы требований своими компетенциями.
Фильтр идей
Рабочий минимум требований — это ещё и фильтр. Иногда после описания бизнес-требований и первых user-flow видно, что ценность недостаточна, появляются дополнительные вопросы к продукту и рынку на который он ориентирован. И это тоже результат: можно доисследовать, внести корректировки и усилить идею уже сейчас или вложиться в более перспективное направление.
Проектирование со смыслом - то что мы любим 💗
