Продуктовое мышление для разработчиков

Почему в эпоху дешевого кода продуктовое мышление становится конкурентным преимуществом разработчика, откуда взялись продакт-инженеры и какие шесть вопросов задать себе до начала разработки. Я больше 18 лет в разработке и сейчас отвечаю за пять продуктов

Максим Романовский

Head of AI & Product Engineering

Max: AI, Engineering and Startups

Главное за минуту

Прежде чем строить RAG-ассистента по документам, спросите, какую проблему он решает и как вы поймете, что решил. Часто нужен не ассистент, а нормальная структура документов, классический поиск или пять хороших страниц документации.

Код дешевеет, команды сжимаются с 10–12 человек до 2–3, и продакта рядом уже нет. Преимущество получает разработчик, который сам выбирает, какие задачи решать, и отвечает за решение, а не за закрытый тикет в джире.

Цель и ценность AI не отдать: у него нет картины мира компании. Он составит опросник или письмо пользователям, но думать и решать остается человеку.

Проблему считают в цифрах: полчаса поиска в неделю на 1000 сотрудников дают 500 человеко-часов, это зарплата 12–13 человек. Первой проверяют гипотезу, которая сокращает 30 минут до 5, а не до 25.

Перед разработкой стоит оспорить задачу и спросить, что будет, если ничего не делать. Лучший код тот, что не написан: build, buy и don't build сравнивают до того, как писать свое.

Ассистент, который никому не нужен

Представим, приходит начальник: нужен ассистент для поиска по внутренним документам компании, срок такой-то, пошли пилить. Обычно разработчик дальше декомпозирует задачу технически. Выбирает LLM и подход, чаще всего RAG, настраивает базу, прикидывает evaluation, покрывает тестами и выкатывает в прод. На выходе может получиться даже работающий ассистент

Только тут есть предусловие, которое никто не проговаривает: кто-то до разработчика уже подумал, что ассистент вообще нужен. А за последние три года активной разработки таких ассистентов внезапно выяснилось, что в большинстве компаний они в чистом виде нафиг не нужны. Нужна нормальная структура документов и нормальный поиск по ним, причем классический, без всякой генерации. Иногда хватает пяти качественных страниц документации с how to и нормальной иерархии.

Продуктовый подход начинает с вопросов: какую проблему решаем, почему она возникла, как получить максимум ценности за минимум усилий и как поймем, что задача решена успешно. Без критериев успеха непонятно вообще ничего. Выкатили, а там 20 пользователей задают 30 вопросов в день. Это хорошо или плохо? Скорее не очень, но если в компании всего 30 человек и 20 из них ассистентом пользуются, то, вообще-то говоря, неплохо