Обычная история: человек умеет писать код, задачи закрывает, а дальше движения нет. Интересные задачи достаются кому-то другому, а когда заходит разговор о более сильной роли, выясняется, что не хватает архитектуры и понимания того, как устроены системы целиком. И непонятно, чего именно недостаёт — потому что «учить всё» невозможно, а что учить, никто не говорит.
Проблема почти никогда не в способностях. Она в том, что знания собирались случайно: статья тут, видео там, задача на работе третья. Получается решето — где-то глубоко, а рядом дыра, о которой сам не знаешь.
Но есть и вторая причина, и она новее. Земля под профессией поехала, и то, что было ценным пять лет назад, ценно уже не так.
Куда меняется профессия
Ещё недавно путь задачи выглядел как эстафета. Продакт придумал, аналитик описал, дизайнер нарисовал, backend сделал, frontend прикрутил, тестировщик проверил, кто-то выкатил. Семь передач, и на каждой теряется контекст — поэтому так часто получается ровно то, что написано, и ровно не то, что было нужно.
Эстафету придумали не от хорошей жизни. Просто ручной работы было столько, что один человек физически не мог держать весь путь: писать код, разбираться в чужом модуле, настраивать выкат, проверять руками.
Именно этот объём и схлопнулся. Черновик функции, тест, миграция, разбор незнакомого сервиса — то, на что уходили дни, теперь занимает часы. Написание кода перестало быть узким местом.
Узким местом стало другое: понять, что именно нужно сделать, и убедиться, что сделано верно. И тут выяснилась неприятная вещь — скорость появления дефектов выросла вместе со скоростью написания кода. Плохо сформулированная задача раньше стоила недели работы одного человека, а теперь — мегабайта кода, который выглядит правильным и проходит ревью.
Отсюда сдвиг ценности. Она ушла в то, что модель сделать за вас не может: сформулировать задачу от проблемы пользователя, провести границы, назвать вещи однозначно, задать критерии приёмки, увидеть цену решения и проверить результат в работающей системе. Это всё инженерные навыки — просто не те, которые тренирует ежедневное закрытие тикетов.
Кто такой продукт-инженер
Так и появилась роль, вокруг которой собран этот сайт.
Продукт-инженер ведёт задачу целиком — от вопроса «какую проблему человека мы решаем» до цифры в метрике после выката. Он не отдаёт результат на стыках: не «я свою часть сделал», а «работает ли это у людей».
Важно, чем это не является. Это не «фулстек» в смысле «пишет и фронт, и бэк» — ширина стека тут вторична. И это не продакт, который немного кодит: инженерная глубина никуда не девается, без неё нечем оценить цену решения и нечего проверять.
Практически роль складывается из четырёх вещей: понимать задачу бизнеса и пользователя; проектировать систему и обосновывать выбор; довести до продакшена и увидеть, что там происходит; и использовать ИИ так, чтобы он ускорял, а не размножал ошибки.
Подробнее про саму роль — в статье «Кто такой продукт-инженер»; здесь достаточно понимать, куда ведёт дорога.
Что это за программа
Эта программа — путь в эту роль и одновременно попытка закрыть то самое решето. Не курс «сделай приложение за две недели», а разложенный по порядку маршрут: от языка через данные и инфраструктуру к архитектуре и методологии, где каждая тема стоит там, где она нужна, и опирается на предыдущие.
Кому она подойдёт
Разработчику, который умеет писать код и застрял. Год-два опыта, задачи выполняются, но нет ощущения системы. Программа даёт ту самую систему: становится видно, из чего складывается взрослый сервис и почему решения принимаются так, а не иначе.
Тому, кто пришёл из другой части стека. Фронтенд, тестирование, аналитика. Здесь не нужно начинать с нуля: можно взять фазы, которых не хватает, и пройти только их.
Тому, кто собирается менять работу. Темы здесь те, о которых в сильных командах спрашивают в первую очередь, — но говорит программа не «как отвечать», а «как это работает». Разница принципиальная: заученная формулировка рассыпается на первом уточняющем вопросе, понимание — нет.
Тому, кто уже работает и хочет закрыть дыры. Не обязательно проходить всё подряд. Откройте список фаз и посмотрите, где вам неуютно, — обычно это очевидно с первого взгляда.
Кому она не подойдёт
Честно про границы, чтобы не тратить ваше время.
Тому, кто пишет первую строчку кода. Программа начинается с языка, но предполагает, что вы уже понимаете, что такое переменная, цикл и функция. Совсем с нуля лучше сначала пройти любой вводный курс по языку, а потом возвращаться.
Тому, кто хочет быстрый результат. Это не «войти в айти за месяц». Полный путь — это месяцы чтения и практики, и никакая программа этого не сокращает.
Тому, кто ищет шпаргалку с готовыми ответами. Списки формулировок есть в других местах и работают ровно до первого «а почему?».
Что вы будете уметь в конце
Не «знать список технологий», а несколько конкретных вещей.
Читать чужую систему: открыть незнакомый сервис и за час понять, из чего он состоит, где данные, что сломается первым. Принимать решения с обоснованием: не «возьмём брокер, потому что модно», а «здесь очередь, потому что вот эти требования, и вот цена такого выбора». Проектировать сервис от задачи бизнеса до схемы данных и контракта. Понимать, что происходит с работающей системой, и находить причину, когда ей плохо. И работать с ИИ-агентом так, чтобы он ускорял, а не размножал ошибки.
Как устроена программа
Фазы идут по порядку. Каждая — это законченный блок: язык, алгоритмы, Spring, данные, инфраструктура, архитектура, методология. Порядок не случайный: следующая фаза опирается на предыдущую, поэтому прыгать вперёд обычно больно.
Статьи внутри фазы тоже упорядочены. Часть помечена как обязательные — это скелет, без которого дальше будет непонятно. Остальные добавляют глубину, и их можно читать выборочно.
После каждой фазы — опрос. Это не экзамен, а способ поймать себя: вопрос формулируется, вы отвечаете своими словами, потом раскрываете ответ и сверяетесь. Расхождение и есть та дыра, ради которой всё затевалось.
Тесты с зачётом — уже проверка. Они строже опросов и показывают, можно ли двигаться дальше.
Тренажёры — практика: писать запросы к живой базе, решать задачи по алгоритмам, разбирать производственные аварии, проектировать системы на доске и работать с собственным резюме. Читать про индексы и написать запрос, который их использует, — очень разные умения.
Как проходить, чтобы дошло до конца
Несколько вещей, которые отличают тех, кто доходит, от тех, кто бросает на третьей фазе.
Не читайте подряд без практики. После фазы про базы данных откройте тренажёр и напишите десяток запросов. Прочитанное без применения выветривается за неделю — это не про дисциплину, это про то, как устроена память.
Не гонитесь за полнотой. Соблазн прочитать все статьи фазы, включая необязательные, приводит к тому, что до архитектуры человек не доходит. Скелет важнее деталей: пройдите обязательные, вернётесь за остальным, когда упрётесь.
Идите регулярно, а не рывками. Час в день лучше, чем восемь часов в воскресенье. Через месяц рывков программа встанет, через месяц регулярности пройдут три-четыре фазы.
Возвращайтесь к пройденному. Фаза про архитектуру заиграет иначе после того, как вы увидите, как устроены данные. Это нормально и правильно.
Коротко
- Написание кода перестало быть узким местом; узким стало понять, что нужно сделать, и проверить, что сделано верно.
- Эстафету из семи передач придумали от объёма ручной работы — этот объём схлопнулся, и один человек снова может держать весь путь.
- Продукт-инженер ведёт задачу от проблемы человека до цифры в метрике и не отдаёт результат на стыках. Это не «фулстек» и не продакт, который немного кодит.
- Программа решает проблему случайно собранных знаний: не «учить всё», а идти по порядку, где каждая тема опирается на предыдущую.
- Подойдёт тому, кто уже пишет код и застрял; пришёл из другой части стека; готовится к смене работы; хочет закрыть конкретные дыры.
- Не подойдёт тому, кто пишет первую строчку кода, ищет быстрый результат или шпаргалку с готовыми формулировками.
- Внутри фазы есть обязательные статьи — скелет; остальное добавляет глубину.
- Опрос после фазы ловит расхождение между «понял» и «могу объяснить»; тест проверяет, можно ли идти дальше; тренажёры дают практику.
- Доходят те, кто практикуется по ходу, не гонится за полнотой и идёт регулярно.
Что почитать дальше
- Программа целиком — список фаз, с которого стоит начать выбирать.
- Все программы — если backend не ваша специализация: есть фронтенд, тестирование, DevOps, мобильная разработка и управление командой.
- Кто такой продукт-инженер — куда ведёт этот путь в итоге.