30 кастдевов сэкономили мне месяцы разработки… (и похоронили первоначальную идею)

Работая в сфере R&D, мы регулярно сталкиваемся с доработкой старых проектов или повторным использованием предыдущих инженерных решений. В какой‑то момент мне пришла в голову идея продукта, который мог бы упростить этот процесс и облегчить жизнь разработчикам. Это должен был быть инструмент, позволяющий быстро находить прошлые наработки по текстовому описанию функционала и отвечать на вопросы по внутренним данным компании — некая «База знаний с ИИ».

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

От эйфории к реальности

Обычно на волне вдохновения я моментально начинаю писать код, накидывать архитектуру и пытаться как можно скорее реализовать идею в жизнь. Особенно сейчас, с Claude Code и Codex, когда рабочий прототип можно собрать за пару вечеров.

К счастью, в этот раз до этого дело не дошло.

Я решил немного притормозить с самой реализацией и начать с теста идеи рынком. Мне хотелось разобраться, существует ли такая проблема в том виде, в котором я её себе представляю, и главное — готовы ли люди платить за её решение. Звучало довольно просто…

Начав с матчасти, я довольно быстро вышел на такой инструмент, как кастдев. Углубившись в тему, наткнулся на книгу «Спроси маму» Роба Фитцпатрика (абсолютный мастхэв для новичка). Один из её главных выводов (помимо того, как и какие вопросы задавать):

Задача кастдева — не получить подтверждение своей идеи.

Задача кастдева — понять, как люди прямо сейчас решают эту проблему (или не решают), с какими трудностями они сталкиваются и готовы ли они что‑то менять.

Немного «излишних» подробностей

Поначалу я пытался идти стандартным путем — предлагал потенциальным собеседникам созвониться или встретиться лично. В реальности этот подход почти не работал(

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

В качестве основного канала для поиска и проведения интервью я выбрал соцсети и мессенджеры — в частности, Telegram и VK.

Почему именно такой формат?

Во‑первых, звонки/встречи на старте это слишком затратное по времени и энергии удовольствие, хоть и более эффективны с точки зрения ^[1] полезной информации.

Во‑вторых, такой подход банально легче масштабировать. Можно одновременно вести несколько диалогов и быстрее набирать статистику (если позволяет совесть, можно и автоматизировать поиск и общение с людьми) + отказы в переписке не так дизморалят, что критически важно в начале, чтобы раньше времени не опустить руки.

Под этот формат я составил небольшой скрипт из 6 основных вопросов.

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

Драматический поворот сюжета

После 10–15 интервью начали появляться первые паттерны. Я выписал себе повторяющиеся проблемы и подкорректировал изначальные вопросы, так как некоторые из них потеряли актуальность или оказались слишком общими. Анализируя массив данных, я начал замечать явные противоречия, которые никак не соответствовали моей первоначальной гипотезе.

Я пришел делать кастдевы с целью — проверить, действительно ли инженеры тратят много времени на поиск старых проектов и технических решений. Но все чаще начал сталкиваться с тем, что сам поиск занимал от силы 30 мин.

После 30 кастдевов я понял, что на самом деле реальная проблема возникала немного позже…

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

Почему было принято именно такое решение? Какие ограничения существовали на тот момент? Что уже пробовали до этого и почему отказались от альтернатив? Какие важные нюансы остались только в головах разработчиков?

И мне осталось ответить на один вопрос.

Если основная проблема в потере контекста, то можно ли решить её с помощью LLM?