Айсберг системного мышления. Как с его помощью растить продукт и команду?
Айсберг системного мышления — это модель, помогающая глубже понимать, почему происходят те или иные события, как ими управлять, исправлять или избегать в будущем.
По сути, эта модель делит происходящее в компании или команде на уровни — от видимых симптомов (события) до глубоких причин (структура и ментальная модель), как айсберг, большая часть которого скрыта под водой.
Вот недавно у меня произошло событие. Пришёл разработчик и сказал, что хочет увольняться. Без предпосылок. Всё было ОК. И тут — как гром среди ясного неба.
Что чаще всего происходит после этого? Идём искать нового! Но, как по мне, этого недостаточно. В 99% случаев все просто «тушат пожар», крайне редко проводя какой-то анализ: А почему он уволился? Что стало причиной? Можно ли было избежать этого увольнения? Не уволится ли за ним ещё кто-то? И так далее.
В моём кейсе я просто не отследил выгорание. Человек давно не был в отпуске и просто заебался до такой степени, что даже задумывается на неопределённый срок уйти из ИТ.
Таких примеров можно привести массу:
- Массовые жалобы на баги в проде;
- Провал по retention (или подставь любую другую метрику);
- Сорвали сроки в третий раз подряд;
- 10 последних гипотез не подтвердились после их тестирования.
Как с этим быть? Как работать на опережение? Об этом ниже.
Нижний уровень. Ментальная модель.
Это самая глубокая часть, из которой выстраивается структура компании или команды. Это то, как люди воспринимают реальность: что они считают «нормой», что — «хорошим», как «должно быть».
Если фаундер или топ-менеджеры верят, что жёсткая иерархия — это классно, то в компании будут уровни, замы, менеджеры -1 и так далее.
Вот ещё частые установки, которые я вижу:
- Скорость важнее качества → релизы без тестов;
- «Менеджер так сказал — я так и сделал» → разработчики молчат о проблемах;
- Ошибки — это плохо → затягивание сроков, излишний перфекционизм, низкая скорость команды;
- Микроменеджмент → выгорание и текучка.
Как по мне, менять ментальную модель фаундера или топ-менеджмента — это как пытаться вытащить фуру из песка в одиночку. Смысла мало, сил потратишь кучу, вероятность на успех стремится к нулю.
Поэтому, если я хочу что-то поменять, то спускаюсь на уровень структуры, паттернов — и ковыряю уже там.
Средний уровень. Структура компании.
Этот уровень отвечает на вопрос: какие процессы, роли, правила создают паттерны?
Именно на этом уровне можно найти «системные баги», которые приводят к провалам.
Моё видение такое: именно структура компании формирует её культуру. А культура — это и есть те самые паттерны поведения сотрудников и то, как они реагируют на события.
Уровень «структура» — это рычаг реальных изменений, потому что он определяет, как работает система и почему возникают проблемы на поверхности.
Что входит в структуру:
- Процессы (планирование, приоритизация, разработка, тестирование, поддержка и так далее);
- Роли, ответственности (кто за что отвечает и принимает решения);
- Коммуникационные паттерны (кто, когда и как общается в команде);
- Метрики, способы принятия решений (что замеряем, как, какие выводы делаем, как используем эти выводы);
- Корпоративная культура, правила внутри компании и команды (тот самый вайб).
Как раз чтобы пофиксить «системные баги», внедряются скрамбаны, применяются фреймворки приоритизации, дорожные карты, ретроспективы, демо и так далее.
Примеры, которые многим знакомы:
- Не налажен процесс в QA → баги попадают на прод;
- Нет системного ревью → код нестабилен, нечитабелен, не масштабируется;
- Roadmap продукта просто спускают сверху → низкая мотивация у команды;
- Оценка задач «пальцем в небо» → частые срывы сроков.
Верхний уровень. Паттерновое поведение.
На этом уровне я ищу и анализирую повторы, циклы и тренды в команде, продукте. Стараюсь понять, что событие — не случайность, а часть повторяющейся истории.
Цель — выйти из режима постоянного тушения пожаров и научиться видеть тренды, а не только единичные события.
За примерами далеко ходить не надо. Поднимай руку, у кого такое было:
- Хотфиксы после каждого релиза;
- Текучка в целом или новые члены команды не остаются надолго;
- Стабильные косяки с оценкой сроков;
- На демо постоянно что-то идёт не так.
Есть несколько инструментов, которые я чаще всего использую на этом уровне:
- Метод «5 почему?» (помогает дойти до первопричины повторяющегося факапа);
- Регулярные ретроспективы и демо (команда сама начинает видеть, что делает неправильно из спринта в спринт);
- Отслеживание метрик (частота релизов, количество багов в проде, сроки закрытия задач, продуктовые и финансовые метрики).
Особое внимание в рамках команды стоит уделить ретроспективам. Нам они очень сильно помогали и помогают. Обращайте внимание на повторяющиеся темы, которые из раза в раз поднимаются на ретроспективе.
У меня есть табличка, которую я заполняю по итогам ретры. Мы заносим туда топ-проблемы, назначаем ответственных и сроки по их урегулированию. (Если будет интерес — подробнее об этом подходе могу рассказать в будущем.)
Самое главное: если я замечаю или от кого-то из команды слышу «это у нас постоянно» — это сигнал. Значит, пора перестать тушить, а начать менять паттерны. А может, и структуру.
На поверхности. События.
Ну тут всё супер просто. Это конкретные инциденты или факты, которые можно зафиксировать: увольнение сотрудника, падение выручки, рост метрики, баги на проде и т. д.
Как мне видится, большинство проблем в продуктах и командах — не случайность, а следствие системных причин, которые часто скрыты под поверхностью.
Если начать копать глубже — до повторяющихся паттернов, структурных багов и ментальных моделей — появляется шанс построить устойчивую, продуктивную и живую систему.
Понравился пост?
👉 Подпишись на мой Telegram-канал Dovzhenko Vision, где я делюсь практическим опытами, инсайтами и полезными материалами!