Хочу поделиться небольшой историей о том, как появилась идея продукта, почему я пошёл первым делом к рынку, и что именно в ответах потенциальных пользователей заставило меня полностью пересмотреть все исходные гипотезы.
Работая в сфере R&D, мы регулярно сталкиваемся с доработкой старых проектов или повторным использованием предыдущих инженерных решений. В какой‑то момент мне пришла в голову идея продукта, который мог бы упростить этот процесс и облегчить жизнь разработчикам. Это должен был быть инструмент, позволяющий быстро находить прошлые наработки по текстовому описанию функционала и отвечать на вопросы по внутренним данным компании — некая «База знаний с ИИ».
Концепция выглядела достаточно логичной, а на фоне стремительного развития локальных языковых моделей и новой волны B2B SaaS она казалась особенно актуальной. Чем больше я обсуждал эту концепцию с коллегами и знакомыми, тем сильнее убеждался, что двигаюсь в правильном направлении.
От эйфории к реальности
Обычно на волне вдохновения я моментально начинаю писать код, накидывать архитектуру и пытаться как можно скорее реализовать идею в жизнь. Особенно сейчас, с Claude Code и Codex, когда рабочий прототип можно собрать за пару вечеров.
К счастью, в этот раз до этого дело не дошло.
Я решил немного притормозить с самой реализацией и начать с теста идеи рынком. Мне хотелось разобраться, существует ли такая проблема в том виде, в котором я её себе представляю, и главное — готовы ли люди платить за её решение. Звучало довольно просто…
Начав с матчасти, я довольно быстро вышел на такой инструмент, как кастдев. Углубившись в тему, наткнулся на книгу «Спроси маму» Роба Фитцпатрика (абсолютный мастхэв для новичка). Один из её главных выводов (помимо того, как и какие вопросы задавать):
Задача кастдева — не получить подтверждение своей идеи.
Задача кастдева — понять, как люди прямо сейчас решают эту проблему (или не решают), с какими трудностями они сталкиваются и готовы ли они что‑то менять.
Немного «излишних» подробностей
Поначалу я пытался идти стандартным путем — предлагал потенциальным собеседникам созвониться или встретиться лично. В реальности этот подход почти не работал(
Инженеры — люди занятые и зачастую интровертные, поэтому вытащить их на созвон или личную встречу с незнакомцем оказалось задачей со звездочкой. Поэтому довольно быстро я перешел на онлайн формат.
В качестве основного канала для поиска и проведения интервью я выбрал соцсети и мессенджеры — в частности, Telegram и VK.
Почему именно такой формат?
Во‑первых, звонки/встречи на старте это слишком затратное по времени и энергии удовольствие, хоть и более эффективны с точки зрения полезной информации.
Во‑вторых, такой подход банально легче масштабировать. Можно одновременно вести несколько диалогов и быстрее набирать статистику (если позволяет совесть, можно и автоматизировать поиск и общение с людьми) + отказы в переписке не так дизморалят, что критически важно в начале, чтобы раньше времени не опустить руки.
Под этот формат я составил небольшой скрипт из 6 основных вопросов.
Важный момент из вышеупомянутой книги — вопросы должны быть не про будущий продукт. Если спросить человека: «Пользовались бы вы такой системой?», скорее всего вам ответят «Да». Поэтому вопросы должны крутиться вокруг рутины разработчиков: как они ищут проекты, сколько времени это занимает и какие проблемы возникают в процессе.
Драматический поворот сюжета
После 10–15 интервью начали появляться первые паттерны. Я выписал себе повторяющиеся проблемы и подкорректировал изначальные вопросы, так как некоторые из них потеряли актуальность или оказались слишком общими. Анализируя массив данных, я начал замечать явные противоречия, которые никак не соответствовали моей первоначальной гипотезе.
Я пришел делать кастдевы с целью — проверить, действительно ли инженеры тратят много времени на поиск старых проектов и технических решений. Но все чаще начал сталкиваться с тем, что сам поиск занимал от силы 30 мин.
После 30 кастдевов я понял, что на самом деле реальная проблема возникала немного позже…
Когда проекту несколько лет или когда инженер сталкивается с «чужими» наработками, в таких случаях приходится буквально по крупицам восстанавливать цепочку событий.
Почему было принято именно такое решение? Какие ограничения существовали на тот момент? Что уже пробовали до этого и почему отказались от альтернатив? Какие важные нюансы остались только в головах разработчиков?
Получалось, что люди искали не файлы или не готовые решения. Они искали контекст.
На этом этапе стало понятно, что моя первоначальная идея была направлена не на главную боль.
Какой урок можно извлечь из всей этой ситуации? Самая очевидная проблема, как ни странно, часто оказывается не главной.
И мне осталось ответить на один вопрос.
Если основная проблема в потере контекста, то можно ли решить её с помощью LLM?