Разработка продукта
Вы знаете, какую боль закрываете, какие функции важны, как выглядит интерфейс. Осталось перевести это в то, что можно отдать в работу — человеку или ИИ-агенту.
Урок 1: Основы технической грамотности
Не чтобы писать код самому. Чтобы понимать, почему простая на вид просьба иногда означает переделать половину системы.
| Понятие | Простыми словами |
|---|---|
| Фронтенд / бэкенд | Что видит пользователь / что считает и хранит данные вне его глаз |
| База данных | Где живёт информация между сеансами — не исчезает при перезагрузке страницы |
| API | Как одна часть системы просит данные у другой — свой или чужой (Telegram, оплата) |
| Деплой | Момент, когда продукт становится доступен не только вам на компьютере, а всем по ссылке |
| Технический долг | Цена будущих доработок за скорость сейчас — не баг, а осознанный компромисс |
Типичная ошибка: просить «просто добавьте синхронизацию в реальном времени», не понимая, что это меняет всю модель данных. Звучит как одна фраза, стоит как новая архитектура.
Самопроверка: зачем продакту знать эти понятия, если код пишет не он?
Чтобы правильно оценить сложность запроса и не удивляться, почему «простая» фича заняла неделю. Без базового словаря продакт либо не спорит о сроках вообще, либо спорит не по делу.
Задание: опишите в пять предложений, что в вашем будущем продукте будет хранить данные, что будет фронтом, с какими внешними сервисами придётся общаться через API.
Урок 2: Путь одного клика — от кнопки до базы данных и обратно
Слова «фронтенд» и «бэкенд» из урока 1 становятся понятнее, если один раз проследить, что происходит между нажатием кнопки и результатом на экране — целиком, шаг за шагом.
Что делает фронтенд (то, что видит и с чем взаимодействует пользователь):
- Отрисовывает интерфейс — что где расположено
- Реагирует на действия — открывает меню, показывает индикатор загрузки
- Проверяет и форматирует данные перед отправкой — например, что в поле «Телефон» действительно похоже на телефон
- Отправляет запрос на сервер и показывает результат
Что делает бэкенд (скрытая часть, куда пользователь не заглядывает):
- Принимает запрос и проверяет его на безопасность
- Определяет, какой сервис должен обработать именно этот запрос
- Выполняет нужную логику — считает, сравнивает, решает
- Читает или записывает данные в базу
- Формирует и отправляет ответ обратно фронтенду
Путь одного клика на сайте записи Насти. Клиентка заполняет форму (дата, тип ткани) и жмёт «Записаться» — это фронтенд: проверил, что дата не в прошлом, и отправил запрос. Сервер получил запрос (бэкенд): проверил, что слот на эту дату ещё свободен, записал заявку в базу данных, сформировал ответ «Заявка принята, ждите звонка». Фронтенд получил ответ и показал клиентке зелёную галочку вместо кнопки. Если на любом из этих шагов что-то пошло не так — например, слот заняли на долю секунды раньше — ошибку должен обработать именно бэкенд (отклонить заявку с понятной причиной), а не фронтенд (он не знает, что происходит на сервере в этот момент).
Практическая польза этой цепочки для брифа агенту: фраза «добавь проверку, что слот ещё свободен» — это всегда бэкенд-логика, а не фронтенд, даже если баг заметен на экране (клиентке показали два раза одну и ту же свободную дату). Понимание, на чьей стороне на самом деле проблема, экономит раунды переписки с агентом или разработчиком.
Если ваш продукт использует ИИ — типовые задачи, которые решает модель, обычно укладываются в несколько категорий:
| Тип задачи | Что делает | Пример |
|---|---|---|
| Классификация | Относит объект к одной из заданных категорий | Спам / не спам, отзыв положительный / отрицательный |
| Регрессия | Предсказывает число | Ожидаемая цена, прогноз спроса |
| Кластеризация | Группирует похожие объекты без заданных категорий заранее | Сегменты пользователей по поведению |
| Поиск аномалий | Находит то, что выбивается из общей массы | Подозрение на мошенничество |
Зная эти категории, проще формулировать бриф для ИИ-фичи: «нужна классификация» звучит конкретнее и проверяемее, чем «пусть нейросеть разберётся».
Самопроверка: клиентка жалуется, что при записи на один и тот же день дважды показало «слот свободен», хотя место уже заняли. На чьей стороне чинить — фронтенда или бэкенда?
Бэкенда. Фронтенд просто показывает то, что ему прислал сервер — если сервер ответил «слот свободен» ошибочно, то проблема в проверке актуальности данных на бэкенде (скорее всего, два запроса пришли почти одновременно, и сервер не заблокировал слот вовремя). Чинить интерфейс здесь бессмысленно — он лишь честно отображает то, что получил.
Задание: для одной функции вашего MVP распишите путь запроса по шагам — что делает фронтенд, что делает бэкенд, куда по дороге может закрасться ошибка. Если в продукте есть ИИ-часть — определите, к какому типу задачи она ближе всего (классификация, регрессия, кластеризация, поиск аномалий).
Урок 3: Техническое задание
Разница между хорошим и плохим ТЗ — не в объёме. Хорошее ТЗ отвечает на три вопроса, плохое — только на первый.
1. Что делаем — user story: «Как [роль], я хочу [действие], чтобы [ценность]».
2. Когда это точно готово — acceptance criteria, написанные ЗАРАНЕЕ, не после. Без этого вы и разработчик (или агент) по-разному понимаете слово «готово».
3. Что точно НЕ входит — явная граница объёма. Без этой строки любая идея кажется важной в моменте и тихо растягивает сроки.
Пример: «Как фрилансер, я хочу получать сводку раз в неделю, чтобы не сверять чаты вручную. Готово, когда: бот сам присылает сводку каждое воскресенье в 20:00. Не входит: веб-интерфейс, интеграция с CRM».
Самопроверка: почему «что НЕ входит» важнее, чем кажется?
Потому что без явной границы любая дополнительная идея кажется важной в моменте. Это и есть scope creep — главная причина, почему выходных не хватает.
Задание: возьмите одну функцию из вашего MVP-скопа (модуль 1, урок 3) и напишите для неё полное ТЗ по трём пунктам выше.
Бонус: быстрый MVP с ИИ — собираем всё вместе
Всё, что было в модулях 1-7 — отдельные инструменты. Здесь они складываются в один проход от идеи до работающего продукта за выходные.
Идея → бриф для агента. Берёте ваш JTBD (модуль 6) и персону (модуль 6) — это и есть основа хорошего брифа. Хороший бриф описывает один сценарий конкретного человека от начала до конца, включает границы скопа из урока 2, а не общее «сделай приложение для X».
Стек — решённый заранее вопрос. Не выбирайте инструменты в моменте:
| Слой | Что брать | Почему |
|---|---|---|
| Бэкенд | Python: FastAPI (веб) или aiogram (Telegram-бот) | Быстро пишется агентом, меньше галлюцинаций |
| Хранение | SQLite | Ноль настройки, хватает с запасом для MVP |
| Оплата | Готовая платёжная ссылка (Tribute для РФ) | Не ваша добавленная ценность на этапе проверки гипотезы |
| Деплой | VPS + Docker Compose + Caddy | Один шаблон конфигов на все продукты, HTTPS без ручной возни |
Проверка на живом человеке, не на агенте. Агент выдал рабочий код — это не значит, что acceptance criteria из урока 2 выполнены для реального человека. Отдайте продукт тому, кто стоит за вашей персоной. Смотрите молча, где он завис.
Первое измерение — в выходные, не через месяц. Отправьте продукт людям из интервью (модуль 3) или в целевой чат. Смотрите не на просмотры, а на actionable-метрику из модуля 5, которую вы сами определили как North Star.
Если первое измерение показывает, что гипотеза не подтвердилась — это не провал выходных. Это результат цикла Build-Measure-Learn из модуля 1 — возвращайтесь к гипотезам из модуля 2 и выберите следующую по ICE.
Финальное задание модуля: соберите всё, что сделали в модулях 1-7, в один бриф для агента и соберите первую версию вашего MVP. Не ждите идеального момента — выходные уже настали.
У вас есть рабочий продукт. Следующий модуль — маркетинг: как довести его до тех, кому он нужен, без бюджета на рекламу.