sadmanager

Эту статью я решил написать после очередного раунда общения с поддержкой одного крупного поставщика ИТ услуг. Я пришёл с конкретной проблемой: симптомы, версии, логи, репро-кейс — всё на месте. В ответ получил аккуратное, холодное: «Это не на нашей стороне. Обратитесь к вашим местным сетевым инженерам». Иными словами — отфутболили.

Такое случается повсеместно, и всё же именно в тот момент я поймал себя на мысли, что уже видел эту картину раньше — только с другой стороны. Я вспомнил свой путь: от «эникейщика» на госслужбе до Service Delivery Manager в международной компании. Я помню время, когда один человек чинил всё — от розетки до кода. И помню, как в больших организациях между командами вырастают стены: обращения ходят по кругу, метрики выглядят прилично, а сервис по-прежнему стоит.

С тех пор у меня простое убеждение: поддержка XXI века обязана измеряться не количеством уровней поддержки, а скоростью и качеством восстановления, не говоря уже о постоянном улучшении сервиса (Continuous Service Improvement, CSI). Не «чей запрос», а «кто взял на себя ответственность довести до результата». Это и есть главная тема этой статьи — как вернуть поддержке цельность и скорость, не потеряв безопасность и зрелость процессов.

Дальше — о том, что мы потеряли на пути от «человека-оркестра» к узкой специализации, и как вернулась назад универсальность, но уже в версии 2.0.

Когда «айтишник» чинил всё

Конец 90-х, начало 2000-х — время, когда ИТ было ближе к ремеслу, чем к выстроенному процессу. В небольших компаниях от одного человека ждали целиком «закрыть контур»: протянуть витую пару и обжать коннектор, переустановить Windows и поднять домен, настроить бэкап и написать скрипт, починить принтер и выправить отчёт в базе. «Человек-оркестр» — не фигура речи, а способ выживания: меньше согласований, выше скорость, ниже стоимость.

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

Разумеется, у этой модели были издержки. Надёжность держалась на индивидуальном героизме, знания передавались из рук в руки, а документация жила в голове и в папке с утилитами на флешке (если вообще была). Но именно тогда я приобрёл опыт, которым дорожу до сих пор: если можно вернуть систему к жизни за пять минут — это надо делать; а потом уже разбираться, как оформить решение так, чтобы оно стало штатным. Не зная, что такое Agile, я жил по Agile 😅.

Большая машина и толстые стены специализаций

Затем мне повезло поработать в большой федеральной компании. Там не было отдела ИТ — там был целый ИТ-департамент, около 500 человек. Предсказуемость, роли, процессы, регламенты — всё по рельсам. И вместе с этим выросли толстые стены специализаций на стыках команд. Мне пришлось выбрать специализацию, и я выбрал быть DBA — администратором баз данных, хотя очень любил программировать; но тогда DBA платили больше 💸: бэкапы и восстановление, производительность, HA/DR, патчи, соответствие требованиям — моё новое всё.

Я видел это много раз. Ночью падает производительность, прилетает тикет — у пользователей «висит» форма. Мониторинг БД показывает рост ожиданий ввода-вывода. Я подозреваю диски и переназначаю тикет администраторам систем хранения — через час он возвращается с отпиской «проблем не видим». Кидаю тикет сетевикам — ещё через час он возвращается обратно. Пинг-понг повторяется, а проблема не решается. В итоге SLA «протухает», и виноватым становится тот, на чьих руках тикет застал дедлайн. А через сутки выясняется, что причина — просто крошечная настройка на одном из узлов ERP-системы (за эти серверы я вообще не отвечал).

Специализация — не враг. Она дает глубокую экспертизу и качество. Проблема в другом: нет сквозного владения и прочных «мостов» между командами — кто ведёт запрос до конца и отвечает за результат. Именно здесь я впервые по-настоящему почувствовал, что «правильно» — не всегда «полезно» для сервиса.

«Правильно» — не всегда «полезно»

Я хорошо помню это чувство: ты всё делаешь «по правилам», а сервис стоит. Передаёшь дальше, ждёшь ответа, согласовываешь — а людям нужно, чтобы заработало сейчас.

Однажды ночью встал склад: отгрузка уперлась в баг печатной формы. Формально это не моя зона. Я нашёл форму, реверс-инжинирингом в дамп-редакторе нашёл баг, поправил его — что называется, «херак-херак — и в продакшн». Через пять минут конвейер ожил, и компания не потеряла сотни тысяч долларов. Формально это зона ответственности разработчиков; в ту ночь они спали, и даже разбуди их — решение бы затянулось до утра, ведь они играют только по правилам.

И в этот раз я ещё раз убедился — как и в случае с «человеком-оркестром» — что в поддержке действует принцип «сначала восстановить, потом нормализовать»: правильная последовательность — сначала вернуть работу в строй как можно скорее, параллельно фиксируя сделанные шаги и уведомляя владельцев; а уже утром — оформить изменение, поправить код и документацию, коротко разобрать причины. Так эпизод героизма превращается в улучшение процесса — и в следующий раз решает уже не смелость, а система.

Команда «универсалов 2.0»

Став тимлидом, я сделал ставку на управляемую широту. Не «все делают всё», но каждый способен протащить задачу через стык, не роняя мяч. Разработчик — не DevOps-инженер, но умеет собрать простой пайплайн для новой фичи на Jenkins; позже этот пайплайн перепишет профессиональный DevOps, зато работа не стоит и появляется необходимая взаимозаменяемость. Сотрудник поддержки — не бэкендер, но открывает git-репозиторий, читает логи и на языке кода объясняет разработчику, в чём проблема; а в несложных случаях — сам правит код и формирует аккуратный pull request. DBA — не владелец продукта, но может предложить безопасный обходной путь, чтобы бизнес не стоял.

Чтобы это работало, широту пришлось «закрыть рамками». Любая правка идёт через короткий pull request и review; выкладки — маленькими порциями с возможностью отката (а-ля release management и change management); доступы — по принципу наименьших привилегий. Продукт активно обсуждается всей командой на регулярных встречах — поднимаем и кроссфункциональные темы. Так вся команда в курсе, как устроен продукт целиком.

Главный эффект — исчез лишний бег по кругу. Там, где раньше запрос кочевал между очередями, сегодня он движется по прямой: один человек берёт его в работу, зовёт тех, кто нужен, фиксирует шаги — и доводит до результата. Скорость выросла не за счёт героизма, а за счёт реальной командной работы и привычки смотреть на систему целиком. При этом сохраняется ownership: независимо от того, кто решает проблему в данный момент, всегда есть тот, кто знает полную картину.

Круг замкнулся — но на новом витке

Мы и правда вернулись к широте — только осознанной. «Универсал 2.0» — это не человек, который делает всё один, а тот, кто доводит задачу до результата, понимает соседние части системы и вовремя подключает нужных людей.

Краткий манифест современной поддержки

1. Владение до результата. Запрос имеет владельца до финала.

2. Скорость решения, но с контролем качества.

3. Широта — управляемая. T-shape навыки, guardrails, парные дежурства, кросс-обучение.

4. Прозрачность и учёба. Blameless RCA, чистые runbook’и, обновления после каждого случая.

5. Метрики по делу. Оцениваем не «сколько перераспределили», а как быстро и стабильно восстановили сервис.

Читайте мою серию: Усталый Босс

Прошлые статьи:

• Когнитивные искажения в ИТ: коротко, по-человечески и с примерами

• Вариант ретроспективы для ИТ команд (postmortem)

• Andon Cord (вторая серия) Как Andon Cord помогает даже там, где никто об этом не думал

• CMM (Capability Maturity Model) Модель зрелости потенциала компании и как по кредитному рейтингу понять с кем имеем дело

• Andon cord

• Люди которые сделали современный менеджмент

Поучаствовал в рубрике #УмХорошоДваЛучше владельца Телеграмм канала «Лайфхаки управленца» Сергея Вепренцева

Со своей стороны хотел бы предложить расширенный вариант Ошибок работодателей и кандидатов. и дать больше рекомендаций обеим сторонам
Собеседование — процесс взаимный 🤝. Работодатель ищет компетенции под реальные задачи, кандидат — возможность продать релевантный опыт. При этом кандидат в более уязвимой позиции, значит, задача руководителя — снизить стресс и создать условия, в которых человек раскроется. Когда обе стороны готовятся и ведут честный диалог, собеседование превращается из «экзамена на выживание» в точную проверку совместимости.

Рекомендации руководителю 👔

1. Требования позиции 🎯
   Требования должны соответствовать на 100% тому, чем кандидат будет заниматься в ближайшие 6 месяцев.

2. Подготовка к собеседованию 📝
   Читать CV на собеседовании — red flag для кандидата. С ним следует ознакомиться заранее, провести сопоставление с описанием позиции. Приоритизируйте навыки от «наиболее нужных» к «наименее нужным» и ведите интервью по этому порядку. Так за 60 минут можно обсудить действительно важные вещи, а если на что-то не хватит времени — это не будет критично. Обратите внимание на наличие сертификатов: не стоит тратить много времени на уже «подтверждённые» навыки.

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

4. Практика важнее теории 🛠️
   Интересуйтесь, как кандидат решал/будет решать практические кейсы, а не только знанием теории 📚.

5. Сортируем core- и развиваемые навыки 🧩
   Core-навыки намного ценнее прочих развиваемых навыков, которые приходят с практикой.

6. Эмпатия и кооперация 🤝
   Снижайте напряжение.
   «Понимаю, кейс сложный — я и сам не смог бы решить его идеально, но давай порассуждаем».
   «Мы недавно столкнулись с проблемой — мог бы ты посоветовать решение?»
   Допустимы и небольшие подсказки: как в работе, так и на интервью «бриллиант» может раскрыться позже.

7. Без предвзятости ⚖️
   Во время интервью собирайте данные, уважайте мотивированную позицию кандидата (даже если вы не согласны). Решение — после де-брифа, по единым критериям роли.

Рекомендации кандидату 🧑‍💼

1. Изучить информацию о компании 🔎
   Понять в интернете, что за компания: что производит, что продаёт. Миссия/видение — если доступны.

2. Сопоставить описание позиции и собственные навыки 📌
   Разделите требования на core и развиваемые и честно соотнесите их со своими скиллами.

3. Подготовить короткую речь о себе 🎙️
   Не пересказывайте всю карьеру и список компаний — говорите только релевантное роли:
   — кто вы для этой роли (2–3 сильных core-навыка) 💪;
   — 2 кейса по STAR с метриками ⭐📈;
   — почему это соответствует задачам команды 🎯.

4. Освежить забытые навыки 🧠
   Перед интервью допустимо «размять память» (конспекты, песочница, ИИ) — но без вранья на встрече. Широкая осведомлённость помогает связать понятия:
   «Blue/Green на практике не делал, но понимаю: два прод-окружения (blue/green), переключение трафика балансировщиком, быстрый rollback без даунтайма».

5. Mock-интервью с помощью ИИ 🤖 Загрузите описание позиции и своё резюме в ИИ и попросите провести mock-интервью: с поведенческими и практическими вопросами, таймингом и обратной связью. Это помогает потренироваться, вычленить слабые места и подготовить ясные ответы по ключевым темам.

Читайте мою серию: Усталый Босс

Прошлые статьи:

• Когнитивные искажения в ИТ: коротко, по-человечески и с примерами

• Вариант ретроспективы для ИТ команд (postmortem)

• Andon Cord (вторая серия) Как Andon Cord помогает даже там, где никто об этом не думал

• CMM (Capability Maturity Model) Модель зрелости потенциала компании и как по кредитному рейтингу понять с кем имеем дело

• Andon cord

• Люди которые сделали современный менеджмент

Иногда решения в ИТ принимаются не головой, а… мозгом. А мозг любит экономить батарейку и ошибается по шаблону. Эти «шаблонные ошибки» и называются когнитивными искажениями. Ниже — 10 самых частых ловушек для ИТ менеджеров и команд

🧠 Подтверждающее искажение (Confirmation Bias)

Что это:

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

Пример:

Приложение «тормозит» — application support сразу винит DBA: месяц назад после оптимизации базы данных «всё висело», значит и сейчас наверняка виноваты снова они, симптомы похожи на те что были месяц назад. Варианты то что проблемы могут быть в прочих компонентах  приложения (инфраструктура, сеть и пр.) даже не рассматриваются.

Что делать:

Точнее проверяйте факты: Неподтверждённое обвинение может обидеть другую сторону и испортить отношения надолго. Предъявляйте не предположение, а проблему, доказанную конкретными метриками. Используйте корпоративные системы мониторинга, которые охватывают весь стек (приложение, база данных, сетевой слой, инфраструктура) и доступны для анализа широкому кругу участников.

⚓ Эффект привязки (Anchoring)

Что это:

Первое число/факт которое попадает в наше поле зрения задаёт «якорь» для дальнейших решений — всё остальное подгоняем к нему.

Пример:

Выбирая вендора для новой системы мониторинга, берём первого из выдачи Google — остальные варианты уже не воспринимаются всерьёз.

Что делать:

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

💸 Ошибка невозвратных затрат (Sunk Cost Fallacy)

Что это:

Тянем проект/технологию «потому что уже столько вложили», вместо того чтобы смотреть на будущие выгоды.

Пример:

Есть дорогие Enterprise-perpetual-лицензии на Oracle Database — держимся за неё, хотя можно перейти на бесплатную open-source-альтернативу или более экономичный managed-сервис. Решение диктуют прошлые траты.

Что делать:

Делаем новый расчёт с учётом перехода на свежие технологии — вероятные выгоды могут перекрыть потери. Считаем не только деньги, но и будущие «возможности»: скорость вывода фич, гибкость архитектуры, снижение vendor lock-in. Улучшение климата в коллективе и мотивации — тоже бенефит.

📅 Ошибка планирования (Planning Fallacy)

Что это:

Систематически недооцениваем сроки и усилия: в голове — «идеальный мир», в жизни — зависимости, очереди и внезапные «а сертификат то истёк».

Пример:

Задачу планировали сделать за 5 часов, но по ходу всплыли неучтённые сложности — в итоге ушло 10 часов, а ещё пришлось завести пару тикетов в technical debt.

Что делать:

Человек, который окончательно решит задачу точного планирования, получит Нобелевскую премию. А пока используем базовые стратегии: трёхточечные (или шеститочечные) оценки/PERT, «покер планирования» для независимых прикидок и буферы как на уровне задач, так и на уровне проекта.

🧑‍💼Эффект авторитета (Authority Bias)

Что это:

Мнение «большого начальника» автоматически кажется верным: даже если кто-то в команде не согласен, спорить «не принято», и точку зрения руководителя принимают — пусть и с сомнениями.

Пример:

Большой босс говорит: «В прошлой компании мы внедряли этот продукт — выгоды не получили, значит и здесь внедрять не будем». Детали того внедрения (цели, масштаб, настройки, метрики) не раскрываются, но решение фактически принимается «по весу» спикера.

Что делать:

Конструктивно спорить с боссами и «звёздными» коллегами — нормально: опирайтесь на метрики, результаты пилота, TCO/ROI и чёткие критерии. Если убедить руководителя не удалось, заранее зафиксируйте риски и последствия выбранного курса (краткий one-pager/decision record), договоритесь о метриках успеха и триггерах для пересмотра решения.

🐑 Эффект стадности (Bandwagon Effect)

Что это:

«Все так делают — и мы сделаем»: популярность решения подменяет его пригодность именно для нас.

Пример:

Внедряем Prometheus + Grafana для time-series-мониторинга, потому что «это у всех». Хотя у нас монолит на ~200 пользователей, нужен мониторинг здесь и сейчас, и текущий вендорский мониторинг уже закрывает потребности. В итоге получаем лишнюю инфраструктуру и лишнюю точку сбоя — без реальной выгоды.

Что делать:

Когда тянет идти за трендом, сначала выписываем свои use cases и критерии успеха: зачем нам это и какие метрики улучшатся.  Отвечаем на вопросы, кто будет это поддерживать? Не превратится ли это через год в кладбище ненужных технологий? Сравниваем с базовой альтернативой («оставить как есть»/вендорское решение) и принимаем решение по пользе, а не по моде.

🔢 Закон малых чисел (Law of Small Numbers)

Что это:

В малых выборках велик шанс случайных «крайностей» в нетипичных местах: разброс высок, закономерности ещё не проявились — поэтому мы склонны делать большие выводы по маленьким данным.

Примеры:

• Фидбэк. Получили три отзыва: два нейтрально-негативных и один сильно позитивный. По двум «минусам» делаем вывод, что «всё плохо», хотя выборка слишком мала и легко искажена.

• Интервью. Пять бесед с «любимыми» клиентами → «фича нужна всем», а реальное использование потом — всего 7%.

Что делать:

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

💀Ошибка выжившего (Survivorship Bias)

Что это:

Видим истории успеха, а «кладбище неудач» — нет. Делаем выводы по тем, кто выжил, а не по полной картине.

Пример:

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

Что делать:

Требуем «знаменатель»: сколько компаний пробовало и каков процент успеха/отказов для нашего масштаба и домена. Запрашиваем негативные кейсы и контакты референсов; запускаем короткий пилот с чёткими метриками успеха/остановки и сравниваем с базовой альтернативой (status quo) — решаем по данным, а не по красивым историям.

🎓 Эффект Даннинга–Крюгера (Dunning–Kruger Effect)

Что это:

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

Пример:

Молодой менеджер после 2–3 удачных внедрений воодушевляется, берёт завышенные обязательства на следующий крупный проект — и проваливается. Параллельно мнение опытного менеджера, который трезво оценивал сроки и риски, игнорируется: уверенный новичок «кажется опытнее».

Что делать:

Отделяйте уверенность от компетенций: оценивайте аргументы и данные, а не тон. Учитывайте мнение обеих сторон, просчитывайте риски (допущения, зависимости, план B). Следуйте проверенным процессам и критериям, а не личной симпатии.

🔍 Знание задним числом (Hindsight Bias)

Что это:

После события кажется, что «и так было ясно» — и мы переоцениваем предсказуемость прошлого.

Пример:

На ретро: «Очевидно было, что интеграция сложная!» — хотя в рисках этого не было, а тесты не ловили. Память дорисовала причинность.

Что делать:

Ведите лог предположений до релиза (какие риски и ожидания были), на ретро сравнивайте с записью, а не с памятью. Фиксируйте решения и их основания (decision record), чтобы отличать «тогдашние знания» от «сегодняшней мудрости». Также не скрывайте своих сомнений - активно пишите в почту и в рабочие чаты. В дальнейшем когда все пойдет не так как планировалось - вам будет легче доказать, что конкретно вы это предвидели.

Читайте мою серию: Усталый Босс

Прошлые статьи:

• Вариант ретроспективы для ИТ команд (postmortem)

• Andon Cord (вторая серия) Как Andon Cord помогает даже там, где никто об этом не думал

• CMM (Capability Maturity Model) Модель зрелости потенциала компании и как по кредитному рейтингу понять с кем имеем дело

• Andon cord

• Люди которые сделали современный менеджмент

В прошлых статьях я уже рассказывал о Andon Cord, который реализует Continuous Service Improvement (CSI) почти в реальном времени: если что-то идёт не так, мы можем остановить процесс и исправить проблему на месте. Но не всегда это возможно. Поэтому я применяю CSI в ретроспективе — через так называемые Postmortem сессии.

Считаю этот подход своим: он родился из практики RCA (Root Cause Analysis) в рамках Problem Management по ITIL. Возможно, в учебниках есть похожие идеи, но к этому формату я пришёл сам — через реальные кейсы, эксперименты и внедрения под конкретные ограничения команды и продукта.

Когда и как мы это делаем📅

Каждую пятницу, в конце рабочего дня, команда кратко разбирает только закрытые кейсы недели: инциденты, запросы, задачи. Формат — спокойная беседа без поиска виноватых (blameless postmortem), с акцентом на ощущения людей, которые делали работу.

Как проходит сессия🕵️‍♂️

• 🗣️ Кейс рассказывает тот, кто делал. Узнаём, в чём была задача и что было фактически сделано.

• 💬 Свободный обмен ощущениями. Делимся, где было неудобно/долго/дублировалось и что вызывало сомнения или напряжение.

• 📝 Фиксируем наблюдения и маленькие улучшения. Записываем 1–3 конкретные идеи в CSI-бэклог — что убрать, объединить, автоматизировать.

• 🛠️ Архитектурные сигналы. Отмечаем признаки проблем на уровне архитектуры (узкие места, масштабирование, и пр)

• 🔄 Границы ответственности. Понимаем, что можно делегировать/передать заказчику и где стоит мягко обновить RACI.

CSI-бэклог: фиксируем идеи сразу💡

Важный результат постмортема — оперативное формирование CSI-бэклога прямо на встрече. Даже в сыром виде, любая идея фиксируется в JIRA — от «галочки» в конфиге до архитектурного рефакторинга.

Принципы:

• 📝 Записываем всё: Нет «слишком мелких» идей.

• 📂 Отдельный бэклог: CSI живёт в стороне (отдельный проект/доска), чтобы не портить продуктовые/проектные бэклоги — «не отсвечивает».

Что дальше происходит с CSI-бэклогом 🔄

• 🔄 Обычный Agile-ритм: Идёт бесконечный refining: уточняем формулировки, укрупняем/дробим, переоцениваем.

• 📊 Capacity под улучшения: В каждый спринт закладываем 20–30% ёмкости под CSI-задачи. Это дисциплина, а не «по остаточному принципу».

• 🔁 Многоразовое возвращение: Одни и те же сторис могут обсуждаться на нескольких postmortem и refining сессиях подряд — мы спокойно расширяем, сужаем и шлифуем решение.

• 🔗 Объединения: Родственные карточки склеиваем в один тикет, чтобы не плодить сущности.

• ♟️«Ход конём» через проекты: Когда стартует крупная инициатива (например, миграция с on-prem в облако), часть CSI-бэклога можно перенести в проектный бэклог как фичи — если это вписывается в бюджет и расписание. Так технический долг уходит «пакетом», а не годами висит в стороне.

Завершение 🎯

Postmortem-сессии дополняют Andon Cord: первый даёт реакцию «здесь и сейчас», второй — спокойный разбор по горячим следам и системные улучшения. Вместе они замыкают цикл CSI: наблюдаем → обсуждаем без обвинений → фиксируем идеи → превращаем их в работу через отдельный CSI-бэклог и обычный Agile-ритм.

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

Если хотите начать просто: уже в эту пятницу разберите 2–3 закрытых кейса, зафиксируйте 1–3 идеи в CSI-бэклог и заложите 20–30% capacity следующего спринта под эти улучшения. Всё остальное приложится.

Читайте мою серию: Усталый Босс

Прошлые статьи:

• Andon Cord (вторая серия) Как Andon Cord помогает даже там, где никто об этом не думал

• CMM (Capability Maturity Model) Модель зрелости потенциала компании и как по кредитному рейтингу понять с кем имеем дело

• Andon cord

• Люди которые сделали современный менеджмент

Все мы знаем, что в ИТ-сфере работают Джуниоры, Миддлы, Сеньоры и Лиды. А если мы выйдем из IT, там найдутся свои "уровни": Ведущие специалисты, Главные инженеры, Замы и другие. Если эти звания или должности назначаются не просто "от балды", как это иногда бывает на госслужбе, мы примерно понимаем, с кем имеем дело. Например, Сеньор в IT может руководить направлением и обладает более широкой экспертизой, чем Миддл. А Главный инженер на заводе знает всё о заводском хозяйстве.

Но что насчёт самих предприятий? Можем ли мы оценивать зрелость и организованность компаний по похожей системе? Оказывается, можем. Для этого есть специальная методология под названием "Capability Maturity Model" (CMM), которую можно назвать "Моделью зрелости потенциала". С её помощью можно оценить как всё предприятие целиком, так и отдельные департаменты или отделы.

В основе этой модели лежат 5 уровней зрелости. Таким образом, компании можно оценивать по пятибалльной шкале, как в школе. Есть компании на "троечку", которые с трудом выполняют свою работу. Есть те, кто тянут на "четвёрочку" с более-менее налаженными процессами. А компании на "пятёрочку" — наверное, тоже где-то существуют, но, по опыту, встретить такие — большая удача.

Для того чтобы точно определить уровень зрелости компании, нужно знать её внутренние процессы: стандарты, методологии, способы коммуникации и многое другое. Разумеется, нам никто ничего такого просто так не покажет. Но есть один лайфхак, который позволяет примерно это понять на основе публичной информации. О нём мы расскажем в конце статьи.

На этом уровне компания живёт по принципу "как пойдёт". Здесь практически всё происходит в режиме хаоса и импровизации. Никаких чётких процессов, правил или стандартов — зато много суеты, нерешённых вопросов и "тушения пожаров".

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

Такие компании могут даже показывать успехи, но, как правило, надолго этого не хватает. Всё держится на энтузиазме и хаотичных усилиях. Если вдруг ключевые сотрудники уходят, бизнес моментально оказывается в кризисе.

Примерные признаки компании на уровне 1:

• Нет понятия о чётком планировании или регулярных процессах.

• Большая зависимость от "звёздных" сотрудников — тех самых, которые могут делать всё и сразу.

• Результат достигается скорее случайно, чем системно.

• Много дедлайнов пропущено, но "главное, что доделали".

Можно сказать, что такие компании похожи на корабль без руля. Если ветер дует в нужную сторону, они счастливы, но попробуй только поменяй направление ветра — и всё пойдёт ко дну.

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

Уровень "Повторяемый" означает, что в компании появились базовые процессы, которые можно повторять. Например, вместо того чтобы каждый раз бегать в панике перед запуском маркетинговой кампании, тут уже может быть готовый чек-лист: "Сделайте раз, два, три". И это действительно помогает!

Что характерно для второго уровня:

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

• Стабильные задачи. Если раньше каждый проект был "новым экспонатом в музее хаоса", то теперь задачи становятся предсказуемыми: компания научилась одинаково решать похожие проблемы.

• На кого опираться? Уровень 2 всё ещё зависит от опытных сотрудников, но теперь новички "не тонут" с первого дня — ведь у них хотя бы есть инструкция!

Пример:
Представьте маленькую турфирму. На уровне 1 каждый тур организовывался с нуля, сотрудники импровизировали, как открыть визу или забронировать номера. На уровне 2 у них появляется базовый процесс: "Шаг 1 — спросите клиента про даты, шаг 2 — проверьте стоимость билетов, шаг 3 — забронируйте отель из базы". Это уже похоже на систему — но не без своих слабостей.

Основные риски уровня 2:

• Процессы зависят от "локальных героев". Если опытный сотрудник уходит, процессы могут начаться "с чистого листа".

• Шаблоны есть, но не всегда их используют. Бывает, что всем лень открыть инструкцию или все просто уверены, что "и так знаем, как это сделать".

• Нет единого подхода: разные отделы могут работать по-разному, а то и вовсе "по настроению".

Итог:
Компании на этом уровне немного окрепли, и у них есть хоть какой-то порядок. Верхушка хаоса осталась позади, но это только начало — без более сильной систематизации дальше не получится двигаться. Уровень 2 — важный шаг на пути компании, но он выглядит как детская стабилизация: они могут повторить прошлый успех, но ещё не готовы к постоянному росту.

По сути, уровень "Повторяемый" — это как подросток, который только научился организовывать свою жизнь: он знает, как делать уроки вовремя, но большие планы составить ещё не может. Двигаемся дальше? 😊

Добро пожаловать на уровень, где компания наконец осознаёт: если не записать всё как надо, то многие будут работать "у кого как". На этом этапе процессы становятся не только формальными, но и унифицированными по всей организации. Например, теперь отдел продаж и отдел логистики наконец договариваются, как правильно взаимодействовать, чтобы не терять заказы.

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

Простыми словами:
Если на втором уровне каждый писал инструкции как мог (или не писал вовсе), то на уровне "Установленный" кто-то умный в компании говорит: "Стоп. Давайте мы всё это структурируем и превратим в единый стандарт". Появляются инструкции, процедуры, политики — их понимают все, ими пользуются все.

Примеры признаков:

• Есть чёткая документация. Всё, что было в голове опытных сотрудников или в куче разных шаблонов, превратилось в официальные процедуры. Причём этими процедурами пользуются не только авторы, но и все остальные.

• Процессы стали едиными. Например, если компания участвует в тендерах, то у неё не пять хаотичных способов отправить заявку, а один понятный процесс.

• Корпоративная культура. На этом уровне уже есть определённое "ДНК" компании: принципы, ценности и подходы, которые её сотрудники разделяют и понимают.

• Работа сквозь отделы. Например, HR теперь не просто закрывает вакансии, а нанимает людей, которые впишутся в строгие регламенты компании. А департамент разработки, в свою очередь, докладывает их по единому стандарту.

Пример:
Представьте фабрику, которая производит шоколад. Если на 1 и 2 уровнях рецепты хранились в голове у кондитера Васи, то на уровне 3 всё прописано в документации: сколько граммов сахара, сколько молока, сколько времени должна крутиться мешалка. А если Вася уходит, фабрика продолжает работать идеально, потому что рецепты и процессы уже "встроены в систему".

Основные риски уровня 3:

• Слишком много бюрократии. Иногда компании на этом уровне могут увлечься описанием процессов настолько, что сотрудники начинают тратить больше времени на отчёты, чем на реальную работу.

• Переход через "формализм ради формализма". Если сотрудники не понимают, зачем эти процессы нужны, они начинают их выполнять "для галочки".

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

Можно сказать, что компании на уровне 3 — это как взрослый человек, который научился управлять своим временем, но иногда всё ещё задаётся вопросом: "А зачем я вообще это делаю?". На этом уровне путь к совершенству только начинается.

Добро пожаловать на уровень компании, которая начала реально управлять своими процессами, а не просто следовать им. Здесь больше не приходится гадать, что сработает, а что нет — всё уже измерено, проанализировано и доработано. Компании на уровне "Управляемый" буквально держат руку на пульсе своих операций.

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

Простыми словами:
На этом уровне компания не просто работает по инструкциям. Она анализирует, насколько хорошо работают её стандарты и процедуры, а затем улучшает их по результатам анализа. Ключевое слово здесь — управление данными.

Признаки уровня "Управляемый":

• Мониторинг и измерения: Все важные процессы компании измеряются. Например, в IT фиксируют время разработки фичи, количество багов и процент завершённых задач.

• Прогнозы: Компания уже понимает, сколько она может сделать и как быстро. Например, если это производство, то она знает: один станок производит 100 деталей в час, а в месяц её общий объём продукции — 3000 деталей.

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

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

Основные риски уровня 4:

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

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

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

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

Вот он, олимп бизнес-зрелости — уровень "Оптимизированный". Это не просто компания с эффективными процессами, строгим контролем и продуманной системой управления. Это организация, которая вкладывает своё время и ресурсы в постоянное улучшение и инновации.

Компании на этом уровне не боятся задавать себе главный вопрос: "Как сделать лучше, чем мы делаем сейчас?" Они не просто оптимизируют свои процессы раз в год — они вносят улучшения постоянно, на каждом этапе, и превращают это в неотъемлемую часть своей культуры.

Что отличает компании уровня 5?
Компания на этом уровне уже умеет не просто управлять процессами, но и… изобретать что-то новое. Её процессы настолько отточены, что позволяют экспериментировать, внедрять идеи и сразу их тестировать.

Простыми словами:
Если на уровне 4 компания контролировала каждый шаг, то на уровне 5 она начинает задавать вопросы вроде: "А зачем мы вообще этот шаг делаем? Может, можно по-другому?" или "Какие новые технологии помогут нам улучшить результат?".

Признаки "Оптимизированного" уровня:

• Фокус на инновациях. Компания не боится экспериментов и тестирует новшества, чтобы стать лучше.

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

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

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

Основные риски уровня 5:

• Чрезмерная ставка на инновации. Иногда эксперименты могут стать слишком смелыми, и это приводит к потерям, если идея "не взлетает".

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

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

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

А вот и нет, уровня 6 не существует (по крайней мере, официально). Но ведь и у "идеального" пятого уровня есть свои недостатки: слишком сильная ставка на инновации может иногда приводить к ошибкам, а чрезмерное внимание к постоянным улучшениям может мешать удерживать фокус на ключевых задачах.

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

Ну, как говорится, подумаем об этом в комментариях. У кого есть идеи уровня 6 — не держите их в себе! 😊

Лайфхак: Как оценить уровень зрелости публичной компании?

Вы хотите понять, насколько зрелая какая-то публичная компания, но совершенно очевидно, что вас не пустят в её процессы с блокнотом и вопросами? Не беда! Есть способ оценить это приблизительно — использовать информацию, которая и так доступна.

Секрет в кредитном рейтинге.

Кредитные агентства, такие как Standard & Poor’s (S&P), Moody’s или Fitch, дают компаниям кредитные рейтинги на основе их надёжности, устойчивости, управления финансами и общей зрелости. Сами кредиторы крайне не любят связываться с беспорядком, поэтому высокий рейтинг почти всегда говорит о хорошей системе управления и отлаженных процессах.

Вот как это может выглядеть в разрезе уровней CMM:

• BB и ниже: Это уровень 1 (Начальный). Такая компания ещё "качается" — управленческий хаос, постоянные риски и нестабильность. Большая вероятность, что они потратят последний рубль на ликвидацию очередной проблемы.

• BBB: Уровень 2 (Повторяемый). Компания вроде бы на ногах, но ещё далека от настоящей зрелости. Основные процессы стабилизировались, но многое держится на ключевых фигурах. Их успех часто зависит от удачи.

• A - AA: Уровень 3 (Установленный). Это компании, в которых процессы уже чётко описаны и относительно хорошо работают. Они знают, как решать свои задачи, и делают это стабильно.

• AAA: Уровень 4 (Управляемый) или даже 5 (Оптимизированный). Высшая оценка практически всегда означает, что бизнес настроен как "идеальные часы". Прозрачные процессы, строгий контроль качества, управление на основе данных, и инновации идут параллельно с надёжностью.

Почему это работает?

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

Дополнение:
Рейтинг, конечно, не даёт идеальной картины. Кредитным агентствам мало интересны нюансы внутренней работы, фокус у них узкий. Но для "поверхностной оценки" это отличный инструмент. Так что загляните на сайт кредитного агентства, найдите рейтинги компании, и вы получите неплохую идею о том, насколько она зрелая!

Примеры: Оценка зрелости известных компаний по кредитным рейтингам

Чтобы показать, как работает связь между кредитным рейтингом и уровнем зрелости, возьмём несколько публичных компаний с их официальными рейтингами от известных агентств — таких как Standard & Poor’s (S&P), Moody’s и Fitch.

1. Газпром

   • Кредитный рейтинг (S&P, 2021): BBB

   • Предположительный уровень зрелости: 2 - Повторяемый

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

2. Tesla

   • Кредитный рейтинг (Moody’s, 2023): Baa3

   • Предположительный уровень зрелости: 2 - Повторяемый

   • Tesla сильно зависит от своих инновационных продуктов и рынков сбыта. Компания быстро растёт, но её процессы ещё не настолько стабильны, как у зрелых корпораций уровня 4 или 5. Это типичный пример быстро масштабируемой компании.

3. Coca-Cola

   • Кредитный рейтинг (Fitch, 2023): A+

   • Предположительный уровень зрелости: 3-4 — Установленный/Управляемый
     Coca-Cola — это компания с глубокими корнями в своей отрасли, стабильными процессами и чётким подходом к глобальному рынку. Они контролируют каждый аспект производства, маркетинга и продаж.

4. Amazon

   • Кредитный рейтинг (S&P, 2023): AA-

   • Предположительный уровень зрелости: 4 — Управляемый
     Amazon — это идеальный пример компании на четвёртом уровне: чёткая цепочка поставок, контроль качества, аналитика данных. Компания умеет управлять процессами на глобальном уровне, а её стабильно высокий рейтинг это подтверждает.

А есть ли компании с рейтингом AAA?

1. Microsoft

   • Кредитный рейтинг (S&P, 2023): AAA

   • Почему?
     Microsoft — одна из самых стабильных технологических компаний в мире. Её огромные финансовые резервы, регулярная прибыль от облачных сервисов (Azure), стабильный рост и доминирующая доля на рынке программного обеспечения делают её практически неприкасаемой в плане финансовых рисков.

2. Johnson & Johnson

   • Кредитный рейтинг (S&P, 2023): AAA

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

3. Apple

• Примечание: У Apple нет официального AAA-рейтинга, она чаще держится на уровне AA+, потому что компания сильно зависит от продаж устройств и конкуренций. Но иногда её называют "неофициальным AAA", учитывая её огромный запас наличности.

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