Блог Слёрм

Как сложность убивает IT-гигантов: почему великие компании теряют скорость и как им выжить

Статья подготовлена Кириллом Казариным, автором телеграм-канала Kazarin.online и спикером курса «Администрирование Linux».

Ловушка растущей сложности

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

Исследования показывают:

  • 67% сотрудников жалуются, что совещания мешают им работать.
  • Руководители тратят 23 часа в неделю на встречи.
  • Лишь 12% инициатив приносят реальную стратегическую ценность.

Компании сталкиваются с одними и теми же вопросами:

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

Ответ кроется не во внешних факторах, а в внутренней энтропии — накопленной организационной и технической сложности.

Почему большие системы ломаются

  • Рост компании увеличивает:
  • Количество связей между людьми и системами.
  • Число правил и процессов — многие становятся рудиментарными.
  • Технический долг — старые решения тормозят развитие.
  • Бюрократию — согласования занимают больше времени, чем сама работа.

Это объясняется фундаментальными законами:

Число Данбара: предел человеческих связей

Антрополог Робин Данбар установил, что человек может поддерживать ~150 устойчивых социальных контактов. Когда компания превышает этот размер, коммуникация усложняется:

  • Появляются формальные иерархии.
  • Команды начинают работать «каждый за себя».
  • Решения принимаются медленнее.

Закон Конвея: архитектура повторяет структуру компании

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

Эффект локальной оптимизации

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

Накопление легаси

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

Иллюзия процессов

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

Классические примеры провалов

1️⃣ Nokia

- Долго цеплялись за Symbian.

- Конкуренция между подразделениями (Symbian vs. MeeGo).

- Пропустила переход на смартфоны.

2️⃣ Yahoo!

- Десятки неинтегрированных приобретений (Flickr, Tumblr).

- Бюрократия и борьба отделов за ресурсы.

3️⃣ IBM (в 90-е)

- Раздутая структура с медленным принятием решений.

- Устаревшие продукты на фоне роста Microsoft и Apple.

4️⃣ Twitter (до Маска)

- Хаотичное управление.

- Медленные изменения из-за внутренних согласований.

Как выбраться из ловушки?

Компании, которые осознанно борются со трудностями, остаются гибкими:

1. Радикальное упрощение (как Apple)

В 1997 году Стив Джобс сократил 70% продуктовой линейки, оставив только ключевые направления.

2. Децентрализация (как Amazon)

  • Правило «two-pizza teams» — команды не больше 10 человек.
  • Микросервисы вместо монолитов.

3. Культура доверия (как Netflix)

  • Минимум процессов, максимум ответственности.
  • Поощрение экспериментов.

4. Фокус на качестве, а не количестве

  • Метрики успеха — не «число фич», а удовлетворённость пользователей.
  • Регулярный аудит и удаление устаревшего.

Итог: простота как стратегия

Сложность неизбежна, но коллапс — нет. Побеждают те, кто:

✔ Дробит монолиты на независимые модули.

✔ Удаляет лишнее, а не только добавляет новое.

✔ Измеряет реальную ценность, а не активность.

Как сказал основатель Amazon Джефф Безос:


«Компании умирают не от того, что меняются, а от того, что не меняются вовремя».

2025-07-07 18:00 Полезное