惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

有赞技术团队
有赞技术团队
美团技术团队
博客园 - 司徒正美
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
阮一峰的网络日志
阮一峰的网络日志
S
SegmentFault 最新的问题
博客园_首页
雷峰网
雷峰网
V
V2EX
The Cloudflare Blog
博客园 - 三生石上(FineUI控件)
量子位
Last Week in AI
Last Week in AI
人人都是产品经理
人人都是产品经理
爱范儿
爱范儿
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 聂微东
V
Visual Studio Blog
Hugging Face - Blog
Hugging Face - Blog
博客园 - 【当耐特】
Jina AI
Jina AI
月光博客
月光博客
L
LangChain Blog

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания
Чему меня научили пол года на программе COO
Andrei · 2026-06-02 · via Все публикации подряд на Хабре

Простой

4 мин

6.3K

Недавно я завершил программу COO в Stratoplan.

Пол года назад, когда я принимал решение идти на обучение, у меня уже был опыт разработчика, Team Lead, CTO и Program Manager. За плечами были десятки проектов, процессы, организационные изменения, инциденты, трансформации команд и продуктовых направлений.

Честно говоря, я шел не за сертификатом. Мне казалось, что основные принципы управления я уже понимаю. Хотелось скорее проверить собственные взгляды и систематизировать накопленный опыт. Сегодня, оглядываясь назад, понимаю, что главным результатом программы стал не сертификат и не новые инструменты. Изменился способ смотреть на компанию и принимать управленческие решения.

Во многом именно ради этого и стоило пройти этот путь.

Когда перестаешь управлять командами

Большую часть карьеры я смотрел на компанию через призму технологий и delivery.

  • Как ускорить разработку?

  • Как повысить качество?

  • Как сделать процессы предсказуемыми?

  • Как сократить количество инцидентов?

Это важные вопросы, но они находятся внутри одной функции компании. Во время обучения я все чаще ловил себя на мысли, что компании редко проигрывают из-за плохого кода. Гораздо чаще они проигрывают из-за плохой координации. Маркетинг движется в одну сторону, а продажи в другую. Продукт живет своей жизнью. Разработка занята собственным бэклогом. Финансы решают свои задачи. Каждая функция отдельно может работать хорошо, но компания целиком упускает прибыль.

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

Процессы не создают ценность

За последние годы я видел много компаний, которые считали себя зрелыми.

У них были:

  • регламенты;

  • KPI;

  • планирования;

  • отчеты;

  • комитеты;

  • десятки встреч.

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

Я несколько раз сталкивался с ситуациями, когда команды производили огромное количество активности.

  • Задачи закрывались.

  • Отчеты публиковались.

  • Метрики улучшались.

  • Руководство было довольно.

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

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

На одном из проектов команда стабильно демонстрировала высокий throughput и хорошие показатели delivery. Однако после анализа выяснилось, что большая часть ресурсов уходила на задачи с минимальным влиянием на бизнес-метрики. Формально команда была эффективна, а компания — нет.

Бэклог как инвестиционный портфель

Наверное, сильнее всего программа помогла мне сформулировать то, что раньше существовало скорее на уровне интуиции. Во многих компаниях бэклог воспринимается как список задач, однако по своей сути это инвестиционный портфель. У компании всегда ограничены люди, время, бюджет и внимание руководителей. Каждая задача конкурирует за эти ресурсы. Поэтому вопрос никогда не звучит как: "Что мы можем сделать?". Настоящий вопрос звучит иначе: "Во что мы готовы инвестировать ограниченный ресурс компании?".

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

Компания получает тот результат, под который она спроектирована

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

Мы любим искать проблему в людях, недостаточно сильном менеджере, слабом руководителе или в неэффективной команде. Но на практике причина часто находится выше. В самой конструкции системы.

  • Если подразделения измеряются конфликтующими KPI, они будут конфликтовать.

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

  • Если выгодно оптимизировать локальный результат, люди будут оптимизировать локальный результат.

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

Сначала приходится менять систему.

Что я забираю с собой

Самый неожиданный вывод после завершения программы оказался очень простым.

Ценность была не в инструментах. Инструменты можно изучить самостоятельно. Настоящая ценность оказалась в смене точки обзора. Я начал значительно чаще задавать себе другие вопросы.

  • Где находится главное ограничение системы?

  • Какие функции компании работают друг против друга?

  • Какие процессы создают ценность, а какие только имитируют ее создание?

  • Какие решения действительно влияют на экономику бизнеса?

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

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

Благодарности

Хочу отдельно поблагодарить команду Stratoplan и тренеров программы.

  • За большое количество практических дискуссий.

  • За возможность посмотреть на привычные управленческие задачи с другой стороны.

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

  • И за среду, в которой собрались сильные руководители из самых разных отраслей.

Иногда одно правильно заданное вопросом ограничение меняет мышление сильнее, чем десяток новых инструментов.

Для меня период обучения оказался именно таким опытом.

Спасибо всем, кто был частью этого пути.

Email: school@stratoplan-school.com