Сайт для одного фестиваля кажется лишним — пока организаторы не начинают отвечать на один вопрос 500 раз

Пять лет назад такую задачу почти наверняка отправили бы в папку «когда-нибудь». Сейчас интереснее сначала посчитать первую проверку. Возьмём сайт небольшого события.

У такого подхода есть граница: актуальность информации. После неё дешевле остановиться и позвать человека на ревью, чем продолжать уговаривать генератор. В задаче «сайт небольшого события» прототип стоит отделять от продакшена не словом «MVP», а набором тестов и ограничений: что разрешено делать, какие данные можно использовать и какой сбой считается критичным.

Информация о расписании, карте и изменениях живёт в соцсетях. На уровне ощущений это просто неудобство. На уровне процесса - повторяющаяся потеря времени, информации или денег. Для развлечения главный KPI смешной, но честный: люди захотели повторить или нет.

Перед разработкой я бы неделю просто собирал три типа данных: повторные вопросы и посещения страницы. Иногда после этого становится ясно, что код вообще не нужен. Первая версия здесь должна уметь только одно: программу, FAQ, карту и обновления. Если хочется добавить ещё семь функций, их лучше записать в отдельный список и не трогать.

Для задачи «сайт небольшого события» я бы запускал два спринта. В первом делается только программу, FAQ, карту и обновления и проверяется, двигаются ли показатели: повторные вопросы и посещения страницы. Если ценность подтверждается, второй спринт уже посвящается качеству - данным, архитектуре, интеграциям, журналированию и поддержке. Такой порядок не заставляет оплачивать инженерный запас до того, как стало понятно, нужен ли продукт вообще.

Если отдавать эту работу внешнему исполнителю, я бы не писал ТЗ в стиле «сделайте современно и удобно». На одной странице достаточно указать исходную боль - информация о расписании, карте и изменениях живёт в соцсетях; первую поставку - программу, FAQ, карту и обновления; метрики проверки - повторные вопросы и посещения страницы; и отдельным пунктом риск - актуальность информации. Тогда исполнитель оценивает не абстрактную идею, а ограниченный результат, который можно принять или отклонить.

Самая частая ошибка - оценивать проект по количеству экранов. В задаче «сайт небольшого события» ценность создаёт не интерфейс как таковой, а то, что пользователь быстрее и надёжнее получает нужный результат. Поэтому даже один экран с правильной логикой может быть полезнее пяти разделов, которые никто не открывает.

Для сценария «сайт небольшого события» это особенно заметно. Сравнивать нужно не «AI или человек». Сильный исполнитель сам использует AI. Реальный выбор - кто несёт стоимость уточнений, проверки и переделок.

Что я бы сознательно не делал на первом круге для «сайт небольшого события»: сложные роли пользователей, универсальную админку, десятки интеграций и AI-рекомендации просто потому, что

они звучат современно. Первая версия должна ответить на один вопрос: исчезла ли проблема хотя бы частично? Если нет, дополнительные функции только делают отрицательный ответ дороже.

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

Новая возможность не в том, чтобы «сделать всё без программистов». Она в том, чтобы перестать тратить месяцы на гипотезы, которые можно проверить за несколько дней. В этой конкретной теме хороший следующий шаг - проверить программу, FAQ, карту и обновления, прежде чем расширять проект.

· Уберите из описания слова AI, приложение и платформа - какая боль останется?

· Назовите одного первого пользователя.

· Ограничьте сценарий одним действием.

· Запишите три теста на поломку.

· После теста примите решение, а не добавляйте фичи автоматически.