Проект и ограничения
Проект — [Кейс: отрасль / тип продукта]. Клиент пришёл с готовым техническим заданием: в нём уже был назван стек, и от нас ждали только срок и стоимость.
Ограничения были жёсткими: запуск через [metric], на стороне клиента — [metric] человек, интеграция с существующей системой учёта и данные, которые нельзя выносить за пределы контура.
Стек назвали раньше задачи
Технологии в задании выбрали до того, как сформулировали задачу. В нём не было ответов на главные вопросы: кто пользователь, сколько данных, что должно работать без сети, кто будет поддерживать систему после нас. Оценка по такому заданию — угадывание.
Технология, выбранная до брифа, становится ограничением, а не инструментом.
Бриф до технологий
Мы отложили выбор стека на [metric] и провели бриф. Четыре шага ниже повторяем в каждом проекте — они занимают меньше времени, чем одна переделка архитектуры.
- 01Записали задачу словами клиента — без названий технологий.
- 02Выписали ограничения: сроки, данные, интеграции, команда поддержки.
- 03Сравнили кандидатов по этим ограничениям, а не по популярности.
- 04Зафиксировали решение одним файлом в репозитории проекта.
## Задача
- пользователь: [metric]
- данные: [metric]
- ограничения: [metric]
## Кандидаты
- Next.js · SSR · экосистема
- [кандидат] · [сильная сторона]
## Решение
- TypeScript · Next.js · PostgreSQL
- почему: см. ограничения выше
- пересмотр: [DATE]Что это изменило в оценке
Из брифа выросли [metric] требований, которых не было в исходном задании, и все они вошли в оценку до старта. Первая версия вышла через [metric] — без переделок архитектуры по дороге.
- срок
- [metric]
- команда
- [metric] инженера
- стек
- TypeScript · Next.js · PostgreSQL
Честно
Бриф стоило провести раньше — до того, как клиент получил первую цифру. Мы потратили [metric] на согласование оценки, которую потом пришлось пересчитывать.
И файл stack-decision.md появился в конце первого спринта. Теперь он появляется в первый день — вместе с репозиторием.