Почему классическое техническое задание терпит неудачу
У традиционного технического задания есть структурный изъян: оно описывает воображаемый инструмент, а не реальную работу. В нём перечисляют экраны, кнопки и требования («система должна позволять…»), так и не задав единственно важный вопрос: какие данные существуют, как они связаны, кто их ведёт.
Результат, знакомый всем ИТ-проектам: поставленный инструмент соответствует документу и не подходит для практики — потому что сам документ был вымыслом. А его составление стоило недель, не давших никакого программного обеспечения.
Структура на одной странице: четыре блока
Управленческое приложение полностью описывается четырьмя блоками. Это структура, которой пользуются опытные проектировщики — и именно её Blueprint Maker извлекает из вашего описания, чтобы построить план приложения.
- ВЕЩИ (сущности): то, что вы отслеживаете — клиенты, объекты, товары, работы. Список из 3–8 наименований, каждое со своей ключевой информацией (полями).
- СВЯЗИ (отношения): как вещи соединяются — «объект принадлежит клиенту», «работа касается оборудования». Одно предложение на связь.
- СОСТОЯНИЯ (статусы): жизненный цикл ваших объектов — «смета, подписано, в работе, завершено, выставлен счёт». Ваши собственные слова, в реальном порядке.
- ЦИФРЫ (показатели): то, что вы хотите видеть каждое утро — суммы к выставлению счёта, просроченные дела, запас ниже порога. От трёх до шести показателей.
Полный пример: одной страницы достаточно
«Компания по установке ограждений, 4 человека. ВЕЩИ: клиенты (имя, адрес, телефон), объекты (адрес, тип ограждения, метраж, сумма сметы, планируемая дата), работы (дата, затраченные часы, бригада), материалы (артикул, запас). СВЯЗИ: объект принадлежит клиенту; работа выполняется на объекте; материалы расходуются по объекту. СОСТОЯНИЯ объекта: смета отправлена, подписано, запланировано, в работе, завершено, выставлен счёт, оплачено. ЦИФРЫ: текущие объекты, установленный метраж за месяц, сумма к выставлению счёта, материалы ниже порога.»
Эта страница содержит всё необходимое для создания приложения — как разработчиком, так и генератором. То, чего в ней нет, столь же показательно: ни описания экранов, ни технических решений, ни пронумерованных требований. Экраны ВЫТЕКАЮТ из структуры.
Три ловушки при написании
Ловушка 1 — описывать текущий инструмент: «мне нужны столбцы с A по R из моей таблицы». Таблица — это источник информации, а не цель: извлеките из неё вещи и связи, а не расположение.
Ловушка 2 — чрезмерный охват: желание охватить и выставление счетов по всем правилам, и расчёт зарплаты, и бухгалтерию. У этих регулируемых областей есть свои инструменты; ваше приложение останавливается там, где они начинаются, и превосходно справляется с вашим оперативным учётом.
Ловушка 3 — частные случаи в первую очередь: «а если клиент одновременно и поставщик?». Опишите сначала обычный поток, покрывающий 90 % дней; частные случаи добавляются потом, на здоровой структуре.
От страницы к приложению: два пути
Классический путь: страница служит брифом для разработчика или агентства — она резко снижает риск недопонимания и оплачиваемое время постановки задачи.
Прямой путь: страница И ЕСТЬ промпт. Переданная Blueprint Maker, она становится структурированным планом приложения — сущности, связи, статусы, показатели — который вы утверждаете перед генерацией. Приложение приходит развёрнутым, с демонстрационными данными: ваше техническое задание проверяется на реальных экранах, а не на приёмочных совещаниях. А если позже подключается разработчик, он отталкивается от сгенерированного кода (экспорт ZIP, push в GitHub), а не от чистого листа.
Шаблон для копирования
Возьмите эти четыре строки и заполните их своими словами: «Моя деятельность: … Отслеживаемые ВЕЩИ (с их ключевой информацией): … СВЯЗИ между ними: … Проходимые СОСТОЯНИЯ: … ЦИФРЫ, которые видеть каждое утро: …» Десяти строк достаточно; план Discovery (0 €) позволяет сразу проверить, какое приложение производит ваша страница.