Пройден "экватор" моего обучения на COO в Stratoplan и я все чаще ловлю себя на мысли:

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

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

Главный внутренний конфликт

За эти месяцы стало ясно, что внутри меня работают два режима мышления:

  1. CTO режим (привычный): нырнуть в проблему, разобраться глубже всех, сделать технически правильно.

  2. COO режим (формирующийся): не решать самому, смотреть на систему целиком, оценивать через ограничения и финансовый результат.

Эти два режима постоянно конфликтуют. И это нормально. Разница не в знаниях, а в уровне, на котором ставится вопрос.

Почему "сделать хорошо" уже недостаточно

Раньше мой фильтр был простой:

это технически корректно и быстро реализуется?

Сейчас он звучит так:

это устойчиво?
это масштабируется?
это предсказуемо?
это финансово оправдано?

И здесь появляется разница:

  • хорошее техническое решение может снижать margin

  • быстрое решение может увеличивать операционный шум

  • идеальная архитектура может не давать нужного бизнес-результата

Стратегия: момент, когда иллюзии заканчиваются

Построение стратегии, пожалуй, самый важный блок . Он разрушает удобное представление "стратегия = roadmap".

На практике стратегический цикл выглядит так:

Замкнутый контур - ключевое отличие стратегического мышления от операционного.

PESTEL анализ, который раньше казался теоретическим упражнением, стал рабочим инструментом. Регуляторика (EU AI Act), рыночное давление, ресурсные ограничения конкурентов. Всё это становится частью повседневного контекста принятия решений. Ты начинаешь видеть:

решения принимаются не внутри компании, а внутри среды

Финансы: точка, где ломается мышление

Финансовый модуль оказался самым трансформирующим. Раньше я оценивал решения по технической целесообразности. Теперь автоматически смотрю:

  • влияние на cost structure

  • место в P&L

  • ROI и срок окупаемости

  • точку безубыточности

Половина решений, которые раньше казались "очевидно правильными", перестают быть таковыми после финансовой оценки.

Каждый уровень добавляется поверх предыдущего: не заменяет, а расширяет.

Стейкхолдер-менеджмент и недирективное управление

Два блока, которые изменили коммуникацию:

  • Стейкхолдер-менеджмент дал чек-листы сверки ожиданий и правила регулярной синхронизации. "Вроде договорились" больше не работает. Нужны явные договорённости и контрольные точки.

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

Самое важное открытие

Оказалось, что многие операционные проблемы заключаются не в технологиях. А в том, что система не управляется как система.

Например:

  • backlog растёт быстрее, чем throughput

  • задачи копятся без оценки value

  • никто не знает, где создаётся ценность, а где формируется долг

Это не баг процесса.
Это отсутствие операционной модели управления.

Где это начинает бить по реальности

После этого ты возвращаешься в рабочий контекст и видишь вещи, которые раньше не замечал:

  • backlog как "свалка задач"

  • отсутствие приоритизации через value

  • отсутствие связи между задачами и финансами

  • рост операционного шума

И главный вопрос: если это система, то почему мы ей не управляем как системой?

Маленький инсайт, который всё переворачивает

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

  • перекосы

  • неэффективность

  • "мёртвые активы"

И здесь начинается самое интересное

Когда ты начинаешь мыслить backlog как портфель:

  • тебе нужны метрики

  • тебе нужна сегментация

  • тебе нужен governance

  • тебе нужна автоматизация

Время - скрытая переменная в большинстве случаях. Чем старше задача, тем дороже её последствия. И тут неожиданно появляется вопрос:

а почему это до сих пор делается руками?

Немного спойлера следующей статьи

Я начал строить систему, которая:

  • сегментирует backlog

  • считает метрики (value, debt, SLA)

  • применяет governance-политику

  • автоматизирует решения

И делает это через:

  • policy-driven модель

  • интеграцию с YouTrack

  • и использование AI (в том числе Codex)

Замкнутый пайплайн с обратной связью реализует переход от ручного управления к policy-driven системе. В результате:

backlog перестаёт быть хаосом и становится управляемым портфелем

(подробно разберу это в следующей статье)

Что я уже начал тестировать

  1. Приоритизацию через value и финансовый impact

  2. Коммуникацию в формате Observation -> Impact на систему и деньги -> Действие

  3. Оценку решений через текущие ограничения, а не через "что технически лучше"

Где пока не идеально

И это важно:

  • внутренний CTO всё ещё хочет “сделать самому”

  • не всегда удается преодолеть ограничения доступа к финансам, для подсчета и анализа

  • иногда проще "быстро решить", чем строить систему

Но теперь это видно и это уже половина изменения.

Главный вывод

Обучение на COO в Stratoplan это не только про:

  • новые инструменты

  • новые знания

  • новые фреймворки

Это про:

смену системы координат

С локальной оптимизации на управления системой

Вопрос

А вы уже смотрите на свои задачи как на портфель?
Или пока ещё как на список «надо сделать»?