Как за час разобрать техзадание и понять, что делать в первую очередь

Кто обратился: основатели нового проекта в сфере торговли

Запрос: разобраться с техзаданием на бота-помощника и понять, что из этого действительно нужно на старте

Ситуация

Ребята пришли с готовым техзаданием на 40+ пунктов. Хотели сделать бота, который помогает покупателям подбирать товар: человек пишет запрос, бот его понимает, ищет в каталоге и выдаёт результат.

Документ был проработан серьёзно: разные каналы связи, сценарии диалогов, подключения к внешним сервисам, обработка ошибок. Видно, что люди потратили время и силы.

Но при разборе стало понятно: в одном документе смешались три разных продукта. Первый — минимальная версия для проверки идеи. Второй — полноценная система на год вперёд. Третий — функции, которые уже есть в готовых бесплатных инструментах.

Что сделали за час

Рассортировали функции. Каждый пункт техзадания разложили по трём кучкам: «нужно сейчас», «нужно потом», «не нужно вообще». Часть отправилась в список на будущее, часть — на удаление.

Прошли путь покупателя от начала до конца. От первого сообщения до результата. Нашли несколько развилок, которые не были продуманы: что делать, если товар не нашёлся, как понимать неточные запросы, куда вести человека после выдачи ответа.

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

Посмотрели на смежные процессы. Заказчик хотел собирать данные о поведении посетителей на сайте. Выяснилось, что у них не настроена даже базовая аналитика — ни целей в Метрике, ни системы учёта заявок. Рекомендовал сначала закрыть эти дыры, а потом уже строить сложные системы.

Результат

Из 40+ пунктов техзадания в первую версию вошли 5 ключевых функций. Устройство системы упростилось: вместо обучаемой нейросети — решение на готовых подключениях, которое можно собрать за неделю.

Что получили:

• Понятный список того, что делать в первую очередь
• Путь покупателя со всеми развилками — что и когда показывать
• Перечень того, что можно не делать и не платить за это
• Рекомендации по базовым инструментам, без которых нет смысла запускать бота

Вывод

Основатели новых проектов часто приходят с техзаданием, где описан конечный продукт, а не первая версия для проверки идеи. Это нормально — они видят картинку целиком.

Но первая версия — это не уменьшенная копия большого продукта. Это проверка одной гипотезы с минимальными затратами. Задача консультации — отделить проверку идеи от строительства космического корабля.

Иногда самая полезная работа — помочь не сделать лишнего.

Хотите разобрать своё техзадание перед запуском?

Записаться на консультацию или напишите в Telegram