Главная / Словарь
Словарь продуктового инженера
Слова, которые встречаются в курсе и в работе продуктового инженера, — простым языком и без англицизмов там, где без них можно обойтись.
- Продуктовый инженер
- Человек, который ведёт задачу целиком: от проблемы пользователя до работающей функции и цифры по ней. Главное в роли — ответственность за результат для пользователя.
- Команда из двух-трёх
- Небольшая группа, которая ведёт одно направление целиком. Работает лучше одиночки: есть кому спорить с вами и с ответами модели.
- Здравое решение
- Умение выбрать, что вообще стоит делать, и честно оценить, достаточно ли хорошо получилось. Главный навык роли.
- Кастдев
- Разговор с человеком о том, как он решает свою задачу сейчас. Цель — узнать факты из прошлого. Похвала вашей идее ничего не доказывает.
- Кусок (узкий срез)
- Самая маленькая часть решения, которая уже проверяет вашу идею. Обычно делается за два-три дня.
- Идея под проверкой
- Предположение, что определённое изменение поможет людям. У неё есть срок, цифра и три возможных исхода: развивать, переделать, закрыть.
- Результат вместо поставки
- Выпустили функцию — это поставка. Изменилось поведение человека — это результат. Оценивают по второму.
- Job story
- Описание задачи от жизни человека: «Когда [ситуация], я хочу [что сделать], чтобы [какой исход]». Решение внутрь не вписывают.
- Дерево возможностей
- Схема: чего хотим добиться → какие проблемы мешают → какие решения возможны → чем проверим. Помогает сравнивать варианты по фактам.
- Событие в аналитике
- Запись о действии человека: создал, оплатил, отменил. Не факт того, что экран отрисовался.
- Признаки готовности
- Список проверяемых условий, при которых задача считается сделанной. Если условие нельзя проверить, это пожелание.
- Промпт
- Текст запроса к модели. Хороший промпт содержит задачу, границы, формат ответа и признак «сделано».
- Контекст модели
- Всё, что модель видит при ответе: ваш запрос, открытые файлы, правила проекта, история переписки.
- Виртуальное окружение
- Отдельная папка с библиотеками для одного проекта. Не даёт проектам мешать друг другу версиями.
- Список изменений (diff)
- То, что именно поменялось в коде. Основной предмет проверки, когда код пишет модель.
- Pull request
- Предложение влить изменения из своей ветки в основную. Здесь изменения читают люди и проверяют автопроверки.
- Автопроверки (CI)
- Тесты и проверки стиля, которые запускаются сами и не дают влить плохой код. Заменяют очередь из людей, но не решают, нужен ли продукт.
- Выкладка (деплой)
- Запуск новой версии сервиса на сервере с постоянным адресом, куда могут прийти пользователи.
- Переменные окружения
- Настройки и секреты (пароли, ключи), которые передают программе снаружи. В коде их не хранят.
- Выключатель функции
- Настройка, которая включает и выключает функцию без нового выпуска. Позволяет выложить код заранее и включить, когда готовы.
- Долг понимания
- Код работает, но никто в команде не понимает, как. Опаснее обычного техдолга: чинить некому.
- Код по вайбу
- Работа по схеме «попросил модель — вставил ответ — не читал». Быстро на старте, дорого через месяц.
- Зависимость от одного человека
- Ситуация, когда без конкретного сотрудника направление встаёт. Лечится парной работой и записанными правилами.
Доведите первую идею до прода 🎯
Первый блок занимает пару вечеров. После него станет понятно, чем работа продуктового инженера отличается от «попросить нейросеть написать код и надеяться на лучшее».
Чтобы открыть уроки, войдите через Telegram.
Войти через Telegram