Входящий запрос в IT почти никогда не выглядит как бриф.
Он выглядит так:
«Хотим что-то как X, но проще / дешевле / быстрее»
Иногда к этому добавляют пару ссылок референсов и список функций.
Проблема в том, что:
- клиент мыслит результатом
- команда — процессом
И между этим почти всегда есть разрыв.
Клиент видит:
«готовый продукт»
Команда должна понять:
что именно нужно сделать, в каком порядке и с какими ограничениями
Без этого любая разработка превращается в перебор вариантов.
Что такое бриф в реальности
Бриф — это способ зафиксировать четыре вещи:
— какую задачу решаем;
— для кого;
— в каких ограничениях;
— и что считаем результатом.
Если хотя бы один пункт размыт — вся система начинает плыть.
Как мы это собираем в MIC
Мы не ждём, что клиент принесёт готовый бриф.
Мы собираем его сами.
Процесс обычно выглядит так:
- Убираем всё лишнее, оставляем только одну ключевую задачу
- Фиксируем ограничения
- Определяем первый рабочий сценарий
После этого появляется базовая структура, с которой можно работать.
Почему это критично
Без брифа команда не может:
- оценить сроки
- выбрать архитектуру
- нормально расставить приоритеты
Все решения становятся временными. И проект начинает жить от созвона к созвону.
Дальше разберём, как на основе брифа принимаются архитектурные решения — и почему «выбрать стек» на самом деле не самая сложная часть.