Привет, я Виталий, и я управляю проектами в KTS. Это должна была быть третья завершающая статья, где я делюсь своим опытом об обучении в Стратоплане на курсе CTO.

Дисклеймер

Мы договорились со Стратопланом: я бесплатно прохожу их курс, а взамен пишу три статьи на Хабр. Всего курс длился 9 месяцев и включал 3 модуля, каждый модуль состоял из трех трехдневных сессий, а каждая сессия выглядела как групповой интерактивный Zoom-звонок, состоящий из трех подтем. Каждая подтема состояла из трех частей: теория, практика в подгруппе, q&a. Звонок начинался утром и завершался в 3 часа дня. Чувствуется некоторая закономерность, но не совсем пойму, какая именно… Оставляйте свои гипотезы в комментариях.

В предыдущих статьях я пересказал структуру первых двух модулей и поделился собственными выводами. Обязательно прочтите, мне было важно поделиться опытом, создав добавленную ценность, чтобы статьи были не просто пересказом или рекламой :-)   

Теперь все иначе

В этот раз я пишу статью уже спустя несколько месяцев после завершения курса, и в моей памяти смешались лекции и сессионные дни, поэтому я решил немного изменить структуру рассказа. Хотя статья все еще посвящена третьему по хронологии модулю, с момента завершения курса в моей работе очень многое изменилось:

• изменилась экономическая ситуация;

• как следствие, изменились ожидания заказчиков — теперь от аутсорса ожидается не просто накодить коды вовремя и качественно. Новый объект поставки — оптимальное решение едва сформулированной потребности бизнеса в кратчайшие сроки;

• экономическая стагнация, новые ИИ-инструменты и обновленный объект поставки значительно повлияли на производственный процесс. Делаете MVP дольше пары месяцев? Добро пожаловать на свалку истории. Самые бодрые релизят полноценные сервисы спустя несколько дней после появления гипотезы;

• все это повлияло на рынок труда и требования к кандидату. Нам больше не нужны конвейерные программисты, которые круто делают свои таски. Мы ищем продуктовых инженеров, которые могут в условиях высокой неопределенности точно определить границы MVP и в кратчайшие сроки подготовить решение в любой технической специализации от аналитики и дизайна до деплоя в прод. Такие инженеры, конечно, не могут уметь вообще все, поэтому они по потребности привлекают специалистов узких компетенций;

• пытаясь не утонуть в этом шторме, поменялся и я.

В этом новом контексте я чувствую особенную важность нескольких тем из курса, поэтому я сфокусируюсь именно на них.

Оглавление

• Стратегический барьер

• Команда и ответственность

• Связь разработки и бизнеса

• Итоги

Стратегический барьер

Модуль «Стратегия» рассказывал о разных ее вариантах: бизнесовых, технологических, инженерных. Мы рассмотрели возможные пути развития компаний от корпораций до стартапов, как их проанализировать и выбрать (SWOT, PESTEL, GOSPA и прочие аббревиатуры, которые может загуглить каждый из вас).

Однако тема, которая зацепила меня больше всего — стратегический барьер.

Картинка выше иллюстрирует 3 варианта карьерного трека CTO. Вертикальная ось отображает влияние на бизнес — чем выше, тем сильнее. Горизонтальная инвертированная ось показывает количество операционных задач. Чем левее, тем больше на вас операционки; чем правее, тем свободнее вы от нее.

• ? Первый вариант — молодой горящий специалист, который очень важен, он много на себя берет, и многое делает своими ру��ами. Какое-то время он супер быстро растет, принимает важные решения и перегружает себя. Часто такая карьера завершается выгоранием и переквалификацией в пасечники.

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

• ?‍♂️‍➡️ Третий вариант подразумевает сохранение баланса операционки и влияния. Такой специалист со временем делегирует все больше задач и ответственности, при этом он не отстраняется и наращивает опыт и, как следствие, ценность его решений продолжает расти.

Полгода назад, слушая эту лекцию, я обнаружил себя в состоянии, которое ближе всего к первому варианту: я был супер заряжен своей работой и чувствовал рост. Хоть головой я и понимал, как важны делегирование и баланс, фактические обстоятельства и объем задач, лежащих на мне, приводили к бесконечным переработкам — 60 часов в неделю без выходных на протяжении многих месяцев. Работа с 9 утра и до 3-4 часов ночи в тот момент для меня была скорее правилом, чем исключением. Одной ногой я уже был готов покрасить волосы, проколоть соски и пойти в бариста заваривать V60 где-нибудь на Китай-городе.

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

С тех пор все решения, которые я принимал, были направлены на то, чтобы максимально снять с себя часть задач. Для этого мне пришлось местами измениться:

• быть более требовательным;

• четче формулировать ожидания и строже контролировать соответствие им;

• более трепетно относиться к договоренностям (не только к тем, что я взял на себя, но и к ожиданиям от других);

• стать менее толерантным к косякам команды;

• научиться открыто просить о помощи и чаще признавать, что я где-то не справляюсь.

По состоянию на конец февраля 2026 могу сказать, что я значительно приблизился к цели. Я почти не перерабатываю, при этом мне удалось нарастить ответственность и расширить зону влияния, но я все равно уверен, что до «идеального» баланса операционки и ответственности мне все еще очень и очень далеко.

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

Команда и ответственность

Эта тема органично продолжает предыдущую. Ключевое ограничение, которое мешало мне делегировать и разгружаться — нехватка доверия. Конечно, здесь под доверием я имею в виду не отсутствие сомнений в порядочности, она подразумевается априори. В текущем контексте слово «доверие» я определяю как внутреннюю уверенность в том, что при делегировании ответственности человеку я доверяю, что он обеспечит ожидаемый результат.

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

Одна из лекций третьего модуля Стратоплана была посвящена именно ответственности. Здесь мы рассмотрели, как транслировать ответственность и как формулировать договоренности, варианты поощрения и санкционирования сотрудников.

За последние полгода я ощутил важность следующих тезисов, часть из которых была озвучена на курсе:

1. в основе ответственности лежит свобода;

2. нельзя вечно сейвить команду — нужно давать возможность ошибаться и обучать принимать последствия своих действий;

3. качественные изменения возможны только после рефлексии опыта.

Пример из опыта

В какой-то момент на своем проекте я столкнулся с растягиванием сроков: цели, которые можно было закрыть за несколько дней, стали тянуться по 2-3 недели. Причинами были расфокус приоритетов, нехватка проактивности и отсутствие последствий за бездействие. Я ощущал это так: многие треки застревали на 80-90% готовности и там, где можно было просто сделать последний шаг и довести дело до конца, процесс буксовал, пока не произойдет «волшебный пинок» сверху.

При этом у меня не было сомнений в компетенциях коллег — я знал, что каждый участник достаточно шарит, чтобы добить свою задачу. Я видел, что каждый действительно старался «сделать хорошо», но что-то мешало. Осложняло ситуацию отсутствие на проекте выделенного деливери-менеджера и аналитика. Эти роли были размазаны по команде (и по мне тоже).

Изменения: мы ввели с командой концепцию стори-лидинга. Это как фича-лидинг, только более атомарный. Конечно, если фича делится на несколько сценариев (stories), скорее всего, за реализацию всех сценариев будет отвечать один человек. Но мы решили все же дробить на стори-, а не фича-лидинг, чтобы точнее планировать работы.

Ниже я описал перечень установок, которые валидны для стори-лида.

• Распределение ответственности. Во время еженедельного планирования для каждого трека фиксируется ответственный. Важно, что ответственный активно подтверждает, что он готов взять на себя трек в текущем объеме, либо предлагает альтернативы и указывает на риски.

• Уточнение образа результата. Задача стори-лида — сформулировать образ ожидаемого результата и провалидировать его со стейкхолдером, внести корректировки.

• Контроль исполнения. Иногда в разработке сценария участвует сразу несколько специалистов. В нашем случае это мог быть дизайнер, фронтендер, бэкендер, AI-специалист. Стори-лид отвечает за декомпозицию, распределение задач, координацию и трекинг прогресса.

• Договоренности. Стори-лид подтверждает ожидаемый объем поставки перед началом спринта.

• Отчетность. Самое важное — стори-лид самостоятельно проводит демо, где показывает инкремент и рассказывает о дальнейших планах по своему скоупу.

• Бонус-усложнение — все это происходит на английском языке)) Тут уважение команде, ребята за время работы на проекте подтянули язык.

Для нас недостающей деталью пазла оказалась именно отчетность. Раньше регулярные демо заказчику пр��водил я, и, соответственно, за все «не успели» или «так вышло» отчитывался я. После распределения ответственности — фича-лиды.

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

Помимо изменений в процессе, я расширил круг коллег, с которыми провожу 1-1. Теперь я веду индивидуальный трекинг не только со своими менти, но и на уровне skip-level, т.е. с менти своих менти, а также со специалистами смежных компетенций в команде — с разработчиками, QA и менеджерами.

При этом я немного изменил подход в общении. Я стараюсь выстраивать коммуникацию, в которой коучинг преобладает над менторингом (что особенно важно, если человек склонен ссылаться на внешние факторы и избегать собственного влияния). Отличие в том, что менторинг «учит», как правильно, а коучинг нацелен на то, чтобы заставить человека задуматься и прийти к выводам самостоятельно. Упрощенный пример:

Менторинг:

Ментор: «Мы не сделали это вовремя, поэтому в следующий раз нужно делать так и так».

Менти: «Ага-угу».

Коучинг:

— Как ты думаешь, почему мы не сделали это вовремя?

— Команда Х отвечала с задержками и не выполняла обязательства, поэтому … — переводит фокус на внешние факторы

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

Это очень грубая и простая зарисовка, но она иллюстрирует идею: не рассказываем решение, а заставляем рассуждать. Не даем перекладывать ответственность на других.

Связь разработки и бизнеса

Начну с базовой установки: не существует разделения на «разработку» и «бизнес». Разработка — это неотъемлемая часть бизнеса, и каждый участник команды, вне зависимости от компетенции и вектора интереса — стейкхолдер / инженер / деливери-менеджер / дизайнер / кто угодно, — может и должен валидировать ценность того, что мы делаем, предлагать идеи, делиться своим мнением.

Этой теме была посвящена целая лекция в курсе. Помимо всего, мне понравился этот слайд. Он точно иллюстрирует мысль, которую я хочу донести:

На мой взгляд, в идеальной картине мира продакт-менеджер обрабатывает входящие запросы на изменения, помогает их структурировать и приоритизировать. Эти изменения в том числе могут инициироваться в команде, но тогда и команда должна быть соответствующей:

Единственное — понятие «крутые разработчики» я бы заменил на «продуктовые инженеры». На мой взгляд, образ продуктового инженера точно описывает эта статья от PostHog:

What is a product engineer (and why they're awesome)

Коротко ожидания от продуктового инженера я перечислял в начале статьи. Повторю:

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

Чтобы связка «команда-бизнес» заработала эффективно, вам нужна такая команда продуктовых инженеров: активные, смелые, компетентные и с широким кругозором.

К вопросу о том, где их найти или как их вырастить. Могу поделиться инсайдом: мы в KTS недавно начали масштабный трек по трансформации команд в этом направлении, чтобы уйти от конвейера и узкой специализации к широкому профилю специалиста с фокусом на бизнес-результаты и обновленный объект поставки.

Моя задача в рамках этого трека — сформировать маленькие вовлеченные команды. Сейчас у меня нет идеального рецепта, как достичь этих изменений наиболее эффективно, но есть несколько действий, позитивные результаты которых уже видны. 

1. Внедрение фича-лидинга и определение ответственности, о которых я писал выше.

2. Включение разработчиков в этап дискавери и ответственность за демонстрацию результатов заказчику.

3. Подключение разработчиков на этапы пресейла, подготовку сметы и формирование коммерческого предложения.

4. Погружение в экономику производства: я объясняю инженерам, как формируются ставки специалистов, как считается маржинальность и т.д.

5. Внедрение baseline на использование ИИ-инструментов и практик:

   1. наличие cursor / claude, уметь им пользоваться в разных режимах, а не только табать;

   2. следование spec-driven-подходу;

   3. запуск проектов в монорепе и т.д.

6. Самостоятельная реализация фичи сразу во всех компонентах: фронт / бэк / ai (с обязательным код-ревью профильного инженера). Конечно, бывают сложные кейсы, которые требуют узких компетенций, но для 70 % типовых задач это работает отлично и позволяет делать задачи значительно быстрее, избегая задержек формата «я завел тебе задачку / когда будет задачка / напоминаю про задачку / нужно ревью». Инженер просто взял и сделал в соло все под ключ, консультируясь при необходимости с коллегами.

Такие изменения поддерживает большая часть команды, но они подходят не каждому, и я вынужден принимать тот факт, что некоторые программисты не готовы перестроиться и могут уйти. Sorry not sorry, мы живем в 2к26, и нужно соответствовать времени.

Больше всего меня здесь драйвит, что значительная часть команды действительно вдохновлена такими изменениями, и я максимально заинтересован в том, чтобы их поощрять и поддерживать. (Кстати, если вы считаете себя продуктовым инженером, который разделяет ценности, описанные выше, и вам интересно поработать с нами, пишите мне в ТГ — ссылка в профиле).

Итоги

На удивление, эти три темы — стратегический барьер, ответственность и связь бизнеса с разработкой — дали мне больше всего пользы за полгода после окончания курса. Они совпали с вектором изменений, которых потребовало от меня наступающее новое время.

Я чувствую, что еще нигде не достиг идеальных результатов и все еще не нашел волшебную таблетку, которая решает все проблемы. В то же время я чувствую, что чем объемнее сфера моих компетенций, тем шире площадь соприкосновения с неизвестным.

Я благодарен курсу Стратоплана за то, что он оказался для меня настолько своевременным и актуальным. Честно говоря, иногда даже мне самому трудно вспомнить, узнал ли я эту информацию из курса или меня привели к ней изменения в работе — так все совпало. Обязательно как-нибудь расскажу о результатах изменений: что именно мы внедрили, как это перетрясло команду, и как это повлияло на нашу бизнес-составляющую. Stay tuned.

А о том, как все начиналось, вы можете узнать из моих прошлых публикаций. Первые две статьи цикла о Стратоплане тут:

• Кто такой этот ваш CTO?! Мой опыт обучения в Стратоплане

• Стать CTO непросто, но я попробую

А материалы из моего далекого тимлидского прошлого тут:

• Не JavaScript’ом единым: как фронтенд-разработчику затащить на собесе

• Матрица soft skills: как вырасти от стажера до синьора