Привет, я Виталий, и я управляю проектами в KTS. Это должна была быть третья завершающая статья, где я делюсь своим опытом об обучении в Стратоплане на курсе CTO.
Дисклеймер
Мы договорились со Стратопланом: я бесплатно прохожу их курс, а взамен пишу три статьи на Хабр. Всего курс длился 9 месяцев и включал 3 модуля, каждый модуль состоял из трех трехдневных сессий, а каждая сессия выглядела как групповой интерактивный Zoom-звонок, состоящий из трех подтем. Каждая подтема состояла из трех частей: теория, практика в подгруппе, q&a. Звонок начинался утром и завершался в 3 часа дня. Чувствуется некоторая закономерность, но не совсем пойму, какая именно… Оставляйте свои гипотезы в комментариях.
В предыдущих статьях я пересказал структуру первых двух модулей и поделился собственными выводами. Обязательно прочтите, мне было важно поделиться опытом, создав добавленную ценность, чтобы статьи были не просто пересказом или рекламой :-)
Теперь все иначе
В этот раз я пишу статью уже спустя несколько месяцев после завершения курса, и в моей памяти смешались лекции и сессионные дни, поэтому я решил немного изменить структуру рассказа. Хотя статья все еще посвящена третьему по хронологии модулю, с момента завершения курса в моей работе очень многое изменилось:
изменилась экономическая ситуация;
как следствие, изменились ожидания заказчиков — теперь от аутсорса ожидается не просто накодить коды вовремя и качественно. Новый объект поставки — оптимальное решение едва сформулированной потребности бизнеса в кратчайшие сроки;
экономическая стагнация, новые ИИ-инструменты и обновленный объект поставки значительно повлияли на производственный процесс. Делаете MVP дольше пары месяцев? Добро пожаловать на свалку истории. Самые бодрые релизят полноценные сервисы спустя несколько дней после появления гипотезы;
все это повлияло на рынок труда и требования к кандидату. Нам больше не нужны конвейерные программисты, которые круто делают свои таски. Мы ищем продуктовых инженеров, которые могут в условиях высокой неопределенности точно определить границы MVP и в кратчайшие сроки подготовить решение в любой технической специализации от аналитики и дизайна до деплоя в прод. Такие инженеры, конечно, не могут уметь вообще все, поэтому они по потребности привлекают специалистов узких компетенций;
пытаясь не утонуть в этом шторме, поменялся и я.
В этом новом контексте я чувствую особенную важность нескольких тем из курса, поэтому я сфокусируюсь именно на них.
Оглавление
Стратегический барьер
Модуль «Стратегия» рассказывал о разных ее вариантах: бизнесовых, технологических, инженерных. Мы рассмотрели возможные пути развития компаний от корпораций до стартапов, как их проанализировать и выбрать (SWOT, PESTEL, GOSPA и прочие аббревиатуры, которые может загуглить каждый из вас).
Однако тема, которая зацепила меня больше всего — стратегический барьер.
Картинка выше иллюстрирует 3 варианта карьерного трека CTO. Вертикальная ось отображает влияние на бизнес — чем выше, тем сильнее. Горизонтальная инвертированная ось показывает количество операционных задач. Чем левее, тем больше на вас операционки; чем правее, тем свободнее вы от нее.
🔥 Первый вариант — молодой горящий специалист, который очень важен, он много на себя берет, и многое делает своими руками. Какое-то время он супер быстро растет, принимает важные решения и перегружает себя. Часто такая карьера завершается выгоранием и переквалификацией в пасечники.
🛌 Второй вариант — пенсионер, который смог разделегировать примерно все, в том числе принятие ключевых решений. С одной стороны, этот человек вряд ли подвержен выгоранию. При этом, отстраняясь от производства, он не обогащает свой опыт и не принимает ключевые решения, его ценность для компании стремится к нулю, и в какой-то момент с ним могут попрощаться.
🏃♂️➡️ Третий вариант подразумевает сохранение баланса операционки и влияния. Такой специалист со временем делегирует все больше задач и ответственности, при этом он не отстраняется и наращивает опыт и, как следствие, ценность его решений продолжает расти.
Полгода назад, слушая эту лекцию, я обнаружил себя в состоянии, которое ближе всего к первому варианту: я был супер заряжен своей работой и чувствовал рост. Хоть головой я и понимал, как важны делегирование и баланс, фактические обстоятельства и объем задач, лежащих на мне, приводили к бесконечным переработкам — 60 часов в неделю без выходных на протяжении многих месяцев. Работа с 9 утра и до 3-4 часов ночи в тот момент для меня была скорее правилом, чем исключением. Одной ногой я уже был готов покрасить волосы, проколоть соски и пойти в бариста заваривать V60 где-нибудь на Китай-городе.
В тот момент для себя я решил, что мой главный фокус в ближайшие месяцы будет на снижении нагрузки. Я управлял несколькими проектами, развивал отношения с заказчиками, и от взятых мной обязательств зависело наличие работы как таковой для нескольких команд. Проще говоря, моя работа — добывать работу для других. Поэтому вариант закрыть ноут в 18:00, настроить ворк-лайф бэлэнс и просто не перерабатывать не был возможен.
С тех пор все решения, которые я принимал, были направлены на то, чтобы максимально снять с себя часть задач. Для этого мне пришлось местами измениться:
быть более требовательным;
четче формулировать ожидания и строже контролировать соответствие им;
более трепетно относиться к договоренностям (не только к тем, что я взял на себя, но и к ожиданиям от других);
стать менее толерантным к косякам команды;
научиться открыто просить о помощи и чаще признавать, что я где-то не справляюсь.
По состоянию на конец февраля 2026 могу сказать, что я значительно приблизился к цели. Я почти не перерабатываю, при этом мне удалось нарастить ответственность и расширить зону влияния, но я все равно уверен, что до «идеального» баланса операционки и ответственности мне все еще очень и очень далеко.
Промежуточный вывод. Конечно, и до лекции про стратегический барьер я чувствовал, что так дальше нельзя, и что мне нужно срочно что-то менять, но именно курс стал триггером изменений и маяком, подсказывающим направление усилий.
Команда и ответственность
Эта тема органично продолжает предыдущую. Ключевое ограничение, которое мешало мне делегировать и разгружаться — нехватка доверия. Конечно, здесь под доверием я имею в виду не отсутствие сомнений в порядочности, она подразумевается априори. В текущем контексте слово «доверие» я определяю как внутреннюю уверенность в том, что при делегировании ответственности человеку я доверяю, что он обеспечит ожидаемый результат.
Уровень абстракции может варьироваться. Идеально, если мне не придется формулировать даже образ ожидаемого результата, а достаточно лишь озвучить проблему или потребность, и человек предлагает решение, которое попадает в цель — это кайф и синергия.
Одна из лекций третьего модуля Стратоплана была посвящена именно ответственности. Здесь мы рассмотрели, как транслировать ответственность и как формулировать договоренности, варианты поощрения и санкционирования сотрудников.
За последние полгода я ощутил важность следующих тезисов, часть из которых была озвучена на курсе:
в основе ответственности лежит свобода;
нельзя вечно сейвить команду — нужно давать возможность ошибаться и обучать принимать последствия своих действий;
качественные изменения возможны только после рефлексии опыта.
Пример из опыта
В какой-то момент на своем проекте я столкнулся с растягиванием сроков: цели, которые можно было закрыть за несколько дней, стали тянуться по 2-3 недели. Причинами были расфокус приоритетов, нехватка проактивности и отсутствие последствий за бездействие. Я ощущал это так: многие треки застревали на 80-90% готовности и там, где можно было просто сделать последний шаг и довести дело до конца, процесс буксовал, пока не произойдет «волшебный пинок» сверху.
При этом у меня не было сомнений в компетенциях коллег — я знал, что каждый участник достаточно шарит, чтобы добить свою задачу. Я видел, что каждый действительно старался «сделать хорошо», но что-то мешало. Осложняло ситуацию отсутствие на проекте выделенного деливери-менеджера и аналитика. Эти роли были размазаны по команде (и по мне тоже).
Изменения: мы ввели с командой концепцию стори-лидинга. Это как фича-лидинг, только более атомарный. Конечно, если фича делится на несколько сценариев (stories), скорее всего, за реализацию всех сценариев будет отвечать один человек. Но мы решили все же дробить на стори-, а не фича-лидинг, чтобы точнее планировать работы.
Ниже я описал перечень установок, которые валидны для стори-лида.
Распределение ответственности. Во время еженедельного планирования для каждого трека фиксируется ответственный. Важно, что ответственный активно подтверждает, что он готов взять на себя трек в текущем объеме, либо предлагает альтернативы и указывает на риски.
Уточнение образа результата. Задача стори-лида — сформулировать образ ожидаемого результата и провалидировать его со стейкхолдером, внести корректировки.
Контроль исполнения. Иногда в разработке сценария участвует сразу несколько специалистов. В нашем случае это мог быть дизайнер, фронтендер, бэкендер, AI-специалист. Стори-лид отвечает за декомпозицию, распределение задач, координацию и трекинг прогресса.
Договоренности. Стори-лид подтверждает ожидаемый объем поставки перед началом спринта.
Отчетность. Самое важное — стори-лид самостоятельно проводит демо, где показывает инкремент и рассказывает о дальнейших планах по своему скоупу.
Бонус-усложнение — все это происходит на английском языке)) Тут уважение команде, ребята за время работы на проекте подтянули язык.
Для нас недостающей деталью пазла оказалась именно отчетность. Раньше регулярные демо заказчику проводил я, и, соответственно, за все «не успели» или «так вышло» отчитывался я. После распределения ответственности — фича-лиды.
Первое время фича-лиды ощущали острое жжение в некоторых участках тела, но оно, по всей видимости, было целебным. Личная ответственность за принятые обязательства привела к тому, что спустя несколько спринтов мы стали работать бодрее, треки стали быстрее закрываться. Сейчас некоторые фичи выкатываются вообще без моего вмешательства, я лишь слушаю прогресс на дейли и смотрю финальное демо. Конечно, не все идеально, по-прежнему бывают блокеры и застревания, иногда приходится глубоко вмешиваться, однако прогресс значительный.
Помимо изменений в процессе, я расширил круг коллег, с которыми провожу 1-1. Теперь я веду индивидуальный трекинг не только со своими менти, но и на уровне skip-level, т.е. с менти своих менти, а также со специалистами смежных компетенций в команде — с разработчиками, QA и менеджерами.
При этом я немного изменил подход в общении. Я стараюсь выстраивать коммуникацию, в которой коучинг преобладает над менторингом (что особенно важно, если человек склонен ссылаться на внешние факторы и избегать собственного влияния). Отличие в том, что менторинг «учит», как правильно, а коучинг нацелен на то, чтобы заставить человека задуматься и прийти к выводам самостоятельно. Упрощенный пример:
Менторинг:
Ментор: «Мы не сделали это вовремя, поэтому в следующий раз нужно делать так и так».
Менти: «Ага-угу».
Коучинг:
— Как ты думаешь, почему мы не сделали это вовремя?
— Команда Х отвечала с задержками и не выполняла обязательства, поэтому … — переводит фокус на внешние факторы
— Что мог бы сделать ты, чтобы уменьшить влияние этого риска и обеспечить ожидаемый результат? — важно перевести фокус на самого человека, чтобы запустить рефлексию о собственных действиях и решениях.
Это очень грубая и простая зарисовка, но она иллюстрирует идею: не рассказываем решение, а заставляем рассуждать. Не даем перекладывать ответственность на других.
Связь разработки и бизнеса
Начну с базовой установки: не существует разделения на «разработку» и «бизнес». Разработка — это неотъемлемая часть бизнеса, и каждый участник команды, вне зависимости от компетенции и вектора интереса — стейкхолдер / инженер / деливери-менеджер / дизайнер / кто угодно, — может и должен валидировать ценность того, что мы делаем, предлагать идеи, делиться своим мнением.
Этой теме была посвящена целая лекция в курсе. Помимо всего, мне понравился этот слайд. Он точно иллюстрирует мысль, которую я хочу донести:
На мой взгляд, в идеальной картине мира продакт-менеджер обрабатывает входящие запросы на изменения, помогает их структурировать и приоритизировать. Эти изменения в том числе могут инициироваться в команде, но тогда и команда должна быть соответствующей:
Единственное — понятие «крутые разработчики» я бы заменил на «продуктовые инженеры». На мой взгляд, образ продуктового инженера точно описывает эта статья от PostHog:
What is a product engineer (and why they're awesome)
Коротко ожидания от продуктового инженера я перечислял в начале статьи. Повторю:
Продуктовый инженер в условиях высокой неопределенности точно определяет границы MVP и в кратчайшие сроки может подготовить решение в любой технической специализации от аналитики и дизайна до разработки и деплоя в прод, привлекая профильных специалистов по потребности.
Чтобы связка «команда-бизнес» заработала эффективно, вам нужна такая команда продуктовых инженеров: активные, смелые, компетентные и с широким кругозором.
К вопросу о том, где их найти или как их вырастить. Могу поделиться инсайдом: мы в KTS недавно начали масштабный трек по трансформации команд в этом направлении, чтобы уйти от конвейера и узкой специализации к широкому профилю специалиста с фокусом на бизнес-результаты и обновленный объект поставки.
Моя задача в рамках этого трека — сформировать маленькие вовлеченные команды. Сейчас у меня нет идеального рецепта, как достичь этих изменений наиболее эффективно, но есть несколько действий, позитивные результаты которых уже видны.
Внедрение фича-лидинга и определение ответственности, о которых я писал выше.
Включение разработчиков в этап дискавери и ответственность за демонстрацию результатов заказчику.
Подключение разработчиков на этапы пресейла, подготовку сметы и формирование коммерческого предложения.
Погружение в экономику производства: я объясняю инженерам, как формируются ставки специалистов, как считается маржинальность и т.д.
Внедрение baseline на использование ИИ-инструментов и практик:
наличие cursor / claude, уметь им пользоваться в разных режимах, а не только табать;
следование spec-driven-подходу;
запуск проектов в монорепе и т.д.
Самостоятельная реализация фичи сразу во всех компонентах: фронт / бэк / ai (с обязательным код-ревью профильного инженера). Конечно, бывают сложные кейсы, которые требуют узких компетенций, но для 70 % типовых задач это работает отлично и позволяет делать задачи значительно быстрее, избегая задержек формата «я завел тебе задачку / когда будет задачка / напоминаю про задачку / нужно ревью». Инженер просто взял и сделал в соло все под ключ, консультируясь при необходимости с коллегами.
Такие изменения поддерживает большая часть команды, но они подходят не каждому, и я вынужден принимать тот факт, что некоторые программисты не готовы перестроиться и могут уйти. Sorry not sorry, мы живем в 2к26, и нужно соответствовать времени.
Больше всего меня здесь драйвит, что значительная часть команды действительно вдохновлена такими изменениями, и я максимально заинтересован в том, чтобы их поощрять и поддерживать. (Кстати, если вы считаете себя продуктовым инженером, который разделяет ценности, описанные выше, и вам интересно поработать с нами, пишите мне в ТГ — ссылка в профиле).
Итоги
На удивление, эти три темы — стратегический барьер, ответственность и связь бизнеса с разработкой — дали мне больше всего пользы за полгода после окончания курса. Они совпали с вектором изменений, которых потребовало от меня наступающее новое время.
Я чувствую, что еще нигде не достиг идеальных результатов и все еще не нашел волшебную таблетку, которая решает все проблемы. В то же время я чувствую, что чем объемнее сфера моих компетенций, тем шире площадь соприкосновения с неизвестным.
Я благодарен курсу Стратоплана за то, что он оказался для меня настолько своевременным и актуальным. Честно говоря, иногда даже мне самому трудно вспомнить, узнал ли я эту информацию из курса или меня привели к ней изменения в работе — так все совпало. Обязательно как-нибудь расскажу о результатах изменений: что именно мы внедрили, как это перетрясло команду, и как это повлияло на нашу бизнес-составляющую. Stay tuned.
А о том, как все начиналось, вы можете узнать из моих прошлых публикаций. Первые две статьи цикла о Стратоплане тут:
А материалы из моего далекого тимлидского прошлого тут:
