Рецензия на книгу «Изучаем системное мышление» — книга о том, как перестать лечить симптомы в ИТ-проектах

Недавно в блоге издательства БХВ вышла статья, что в ИТ-литературе надо больше внимания уделять темам построения команд, управления людьми и разработкой продуктов (продакт‑ и тайм-менеджменту). На наш взгляд, это хорошее начинание, ведь книги по «чистому ИТ» очень быстро устаревают, а вот про ведение бизнес-процессов и личностный рост специалистов — тема почти вечная. Книга Дианы Монталион «Изучаем системное мышление» — перевод Learning Systems Thinking, вышедшей в O’Reilly, как раз в этой струе.

Сразу предупреждение. В рецензии, как и в самой книге, вам встретятся имена и понятия, которые чаще звучат на курсах MBA, чем на ИТ-совещаниях, — Донелла Медоуз, Питер Сенге, тейлоризм, концептуальная целостность. Но два самых известных правила из книги, закон Конвея и закон Брукса, сформулировали люди из разработки, наблюдая за собственными проектами. Остальные идеи пришли из теории систем и менеджмента, и автор переводит их на язык ИТ- отрасли — микросервисов, разбора кода, релизов и собеседований. Где термин может оказаться незнакомым, в этой рецензии будет короткое пояснение. 

Рецензия по традиции начинается со ссылки на страницу книги «Изучаем системное мышление» на сайте издательства БХВ. Напомним, что на все бумажные книги по компьютерным технологиям от издательств «БХВ Петербург», «Alist» и «Фолиант» доступен промокод SSPSOFT на скидку 25% как подарок читателям Хабра от нашего блога.

Об оригинале книги и ее авторе

Оригинал вышел в издательстве O’Reilly в июле 2024 года под названием Learning Systems Thinking: Essential Nonlinear Skills and Practices for Software Professionals. Русский перевод выпустило издательство «АЛИСТ» в 2026 году, в книге 304 страницы, в России она продается через сайт БХВ (скидка по промокоду только там) и на маркетплейсах.

Диана Монталион — системный архитектор с двадцатилетним стажем. Она была ведущим архитектором в The Economist и Wikimedia Foundation, позже основала консалтинговую компанию Mentrix Group. В предисловии автор рассказывает свою историю.

Когда-то у автора даже был книжный магазин в Монтане (США), потом случился переезд в Остин, работа с PHP, Drupal, она делала большие сайты и, наконец, углубилась в архитектуру распределенных платформ. Эта автобиография объясняет интонацию всей книги. Автор пришла в архитектуру через публикации, книги и коммуникацию с читателями, поэтому проектирование технологий для нее органично сочетается с исследованием рабочих коммуникаций в командах.

Заметка о названии и переводе

В русском названии немного искажен подзаголовок оригинала, который говорит о нелинейных навыках и практиках для специалистов по программному обеспечению. Подзаголовок «Essential Nonlinear Skills and Practices for Software Professionals» превратился в «Гибкую командную работу в ИТ». Без точного перевода «Изучаем системное мышление» на книжной полке или в онлайн-магазине легко принять за книгу по общему менеджменту. На деле все примеры в книге взяты из ИТ, от микросервисов и кеширования до оценки кода (код-ревью) и найма разработчиков, а аннотация прямо адресует книгу программным архитекторам и руководителям ИТ-проектов.

Перевод в целом читается ровно, хотя местами русскоязычный перевод спорен. Вот пара моментов, и потом пойдем дальше. Реплика из «Матрицы» (стр. 31) подписана как «говорит Морфеус Нео», словно Нео — фамилия героя. На самом деле, в оригинале это два персонажа: Морфеус говорит, Нео слушает. Правильный вариант: «Как говорит Морфеус, обращаясь к Нео в фильме „Матрица“».  

Или еще вот, на странице отзывов (стр.11) подпись для Джессики Керр в виде “symmathecist” осталась транслитерацией «симматецист». В русском издании слово просто транслитерировано, без сноски, и не каждый читатель поймет, что оно значит. Лучше было бы дать расширенное толкование, например: «Исследовательница симматезии, то есть взаимного обучения людей и систем».

Как книгу приняли на в англоязычном ИТ

Отзывы на оригинал заметно поляризованы. На Goodreads у книги посредственная оценка около 3,4 из 5 примерно при сотне отзывов. При этом сайт книги собрал восторженные рекомендации известных в индустрии людей — Кента Бека, Кевлина Хенни, Влада Хононова, Ника Тьюна. Рецензент британской ассоциации программистов ACCU хвалит ясный и искренний стиль автора и считает идеи книги напрямую годными в современной разработке.

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

Для кого эта книга

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

Вот как выглядит целевая аудитория читателей на наш взгляд:

•        Руководители команд (тимлиды) и ведущие разработчики, которые отвечают за решения на стыке нескольких команд;

•        Системные архитекторы, особенно на проектах миграции и модернизации унаследованных систем;

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

•        Опытные специалисты, которые готовятся к роли тимлида и хотят понять, почему одних технических навыков для этого мало;

•        Студенты и стажеры, но им лучше читать выборочно (об этом ниже).

Опыта программирования книга не требует, листингов кода в ней нет. Зато она предполагает, что читатель уже бывал на тяжелых совещаниях («Кто виноват и что делать»), видел провальные релизы и спорил в комментариях к запросам слияния кода (пул-реквестам).

Тут поясним термин пул-реквест (pull request, PR) — это запрос на слияние: предложение влить изменения из своей ветки кода в основную. Разработчик делает правки в отдельной ветке и открывает пул-реквест. Коллеги смотрят изменения, оставляют комментарии, иногда просят что-то исправить. После одобрения код вливается в основную ветку. Это обсуждение правок в т.ч. относится к код-ревью.

Обзор глав

Книга состоит из 12 глав в четырех частях. Обсуждение темы развивается от мышления одного сотрудника к менталитету команды и правилам ведения проектов в организации. Почти каждая глава заканчивается практическим упражнением и возвращением к сквозному примеру — вымышленной медиа-компании MAGO.

Сквозной кейс MAGO как основа книги

Вымышленная компания MAGO десятилетиями выпускала самый популярный журнал в мире, затем ушла в цифру и за двадцать лет обросла набором разрозненных программных продуктов, которые, по словам автора, держатся на скотче и жевательной резинке (в России бы сказали «на синей изоленте»). 

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

Часть I. Система мышления (главы 1–3)

Глава 1 «Что такое системное мышление?» определяет понятия линейного и нелинейного мышления. Автор показывает, что декомпозиция, анализ причин и итерации по-прежнему нужны, но системные проблемы управления проектами и командами линейными методами не решаются. Здесь же приведены признаки человека, который мыслит системно, и дополнительная карьерная лестница, по которой удобно сверять свой рост.

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

Закон Конвея (1968) гласит, что архитектура системы повторяет структуру коммуникаций в организации, которая ее создает. Закон Брукса (1975) напоминает, что добавление людей в опаздывающий проект отодвигает сроки еще дальше, потому что новичков надо вводить в курс дела, а каналов общения становится больше. Концептуальная целостность, по Бруксу, означает, что система выглядит так, будто ее придумал один человек. Модель Донеллы Медоуз описывает систему через запас и потоки, которые его пополняют и расходуют, поэтому изменения в ней проявляются с задержкой.

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

Часть II. Вы — как система мышления (главы 4–6)

Эта часть может вызвать скепсис, но очень важно ее дочитать, раз уж вы купили эту книгу.

Глава 4 «Самосознание как основополагающий навык» посвящена метапознанию, умению наблюдать за ходом своих мыслей и отделять сигнал от шума. Основное упражнение — ежедневное свободное письмо по 10–20 минут. Там же разобрана «дилемма подстаканника», когда обсуждение архитектуры уходит в мелочи. «Дилемма подстаканника» — это ситуация, когда на обсуждении проекта все спорят о мелких и понятных деталях, вроде подстаканников в машине вместо главного (двигателя, КПП).

В западном ИТ это явление еще называют «эффектом велосипедного сарая» (Bikeshedding), он же закон тривиальности Паркинсона — это привычка тратить больше всего времени на обсуждение мелочей, в которых разбираются все, и почти не обсуждать сложное и важное. Название пошло из примера Сирила Паркинсона 1957 года. Комитет быстро одобрил проект атомной электростанции, потому что мало кто в нем разбирался, зато долго спорил о навесе для велосипедов, где мнение было у каждого.

Глава 5 «Ответ вместо реакции» учит замечать реакцию до того, как она превратилась в резкий комментарий. Инструменты простые — прием импровизаторов «Да, и...», правило 24 часов перед ответом на неприятное письмо, дыхание, прогулка (здесь автор использует аббревиатуру HALT).

Правило HALT (Hungry, Angry, Lonely, Tired — голодный, злой, одинокий, уставший) — если вы в одном из этих состояний, отложите ответ или важное решение, пока не поедите, не успокоитесь или не отдохнете. Звучит как тренинг личностного роста, однако любой, кто хоть раз отвечал в рабочем чате на эмоциях, поймет, зачем это в книге о построении командной работы.

Глава 6 «Система обучения» различает запас знаний и поток знаний. Автор считает, что ценность разработчика или инженера все больше определяется способностью передавать и обновлять знания, и предлагает метафору, в которой информация — рецепт, знание — повар, мудрость — шеф-повар. Читателю предлагают составить личный план обучения из четырех видов деятельности, это создание артефактов, наблюдение и вопросы, синтез и опыт.

Часть III. Мы — это система мышления (главы 7–9)

Для практикующего разработчика это самая полезная и содержательная часть.

Глава 7 «Коллективное системное рассуждение» учит превращать мнение в обоснованное предложение. Это тезис, три-пять надежных, уместных и связных доводов и объяснение, почему вопрос важен именно сейчас. Там же шаблон нисходящей проработки с разделами «Резюме», «Зачем», «Что», «Кто», «Как», «Когда». Такой одностраничник можно завтра же положить в Confluence или его российский аналог рядом с записями архитектурных решений.

Глава 8 «Проектирование обратной связи» объясняет, как просить полезные отзывы и как их давать. Золотое правило автора звучит просто — берите то, что нужно, остальное оставьте и забудьте. Большой раздел отведен логическим ошибкам в технических спорах с узнаваемыми примерами вроде «нам нужен Kubernetes, сейчас все его используют» или ответа на «технический директор сказал, что микросервисы нам не подойдут».

Глава 9 «Шаблонное мышление» показывает, как одно и то же событие, например ошибка в продуктовой среде (проде) или сбой сервиса, вырастает из совершенно разных закономерностей. Автор выделяет внешние, технологические и проектные шаблоны и дает семь вопросов для их поиска, от движения информации в системе до того, как в организации устроено обсуждение.

Часть IV. Выработка системного мышления (главы 10–12)

Глава 10 «Совместное моделирование» разделяет реальное моделирование и рисование диаграмм «для презентаций». Главная мысль главы — команду объединяет совместная работа над моделью, и пользы от этого процесса больше, чем от картинки. Разобран пример, как из модели возможностей платформы вырастают требования к релизам, а в конце дан список подходов от C4 и ArchiMate до EventStorming и карт Уордли.

Вот способы моделирования систем, которые автор перечисляет в главе 10:

• C4 — схема архитектуры ПО на четырех уровнях детализации: контекст системы, контейнеры (приложения и базы данных), компоненты и код.

• ArchiMate — стандартный язык схем для архитектуры всего предприятия, который связывает бизнес-процессы, приложения и инфраструктуру.

• EventStorming — командный урок, на котором участники выкладывают на стене стикеры с событиями бизнес-процесса и так вместе выясняют, как работает система.

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

Глава 11 «Системное лидерство» отделяет лидерство от должности. Автор разбирает наследие тейлоризма с его установкой на контроль и предлагает интегративное лидерство, то есть выстраивание среды, в которой команды сами находят точки приложения усилий. Здесь же семь эвристик обучения вроде «одной точки зрения всегда недостаточно» и «есть ли это слово в глоссарии?».

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

Описание наследия тейлоризма в главе 11 — это про привычки, когда лидерство путают с контролем, и которые из правил фабричного управления перешли в ИТ:

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

• продуктивность измеряют количественно: строчками кода, отработанными часами или закрытыми тикетами;

• к удаленной работе относятся с недоверием («дома они не работают»).

Глава 12 «Переосмысление успеха» завершает книгу разговором о том, как измерять успех системы, и чек-листом качеств системно мыслящей команды. В конце развязка кейса MAGO, где цель компании переформулирована под мир, в котором контент живет на десятках платформ одновременно.

Насколько книга актуальна в 2026 году

Книга не привязана к версиям ПО, поэтому вопрос устаревания стоит мягче, чем у учебников по языкам программирования или тем более, по инструментарию ИИ. Опорные идеи автор берет у титанов бизнес-школ Медоуз, Сенге, Аккоффа, Брукса и Конвея, и самому свежему из этих источников почти двадцать лет. За два года с момента выхода оригинала книги здесь ничего не изменилось.

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

В 2026 году это, по сути, описание повседневности в ИТ-разработке. ИИ-агент напишет сервис за 1 день, а вопросы о том, как сервис встанет в систему, кто владеет данными и почему три прошлых «быстрых решения от ИИ» не сработали, остаются людям. При потоке сгенерированного кода концептуальная целостность становится дефицитом.

Что в нюансах: несколько неактуальны разве что инструменты в примерах для нашего рынка. Автор упоминает Slack, Miro, Notion, Jira и Confluence. Для российских команд часть этих сервисов после 2022 года стала недоступна, их заменили Яндекс Трекер, Kaiten и российские онлайн-доски. На содержание это никак не влияет, упражнения по моделированию одинаково работают на любой доске, хоть на той пластиковой, что висит в комнате переговоров.

Применимость для управления ИТ-командами в России

Для читателей это главный вопрос перед покупкой. Книга написана американским консультантом на американском материале — Theranos, Netflix, Фредерик Тейлор и Генри Гант, в книге используется статистика США. 

Работает ли это у нас? И да, и нет. Многое переносится почти без потерь:

•        Кейс MAGO точно ложится на российские реалии последних лет. Уход западных вендоров заставил многие компании экстренно менять SAP, Oracle, продукты Atlassian и другие системы. Реакция от директора «заменить немедленно тем же самым, только российским» знакома каждому тимлиду, кто участвовал в импортозамещении, и книга объясняет, почему такая замена часто просто переносит старые проблемы на новую платформу.

•        Критика тестов у доски актуальна для нашего рынка найма, где алгоритмические секции и кодирование в реальном времени (лайвкодинг) стали стандартом технических собеседований у крупных компаний. Модель айсберга помогает объяснить руководству, почему команда из сильных сотрудников уровня «гуру» плохо договаривается между собой.

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

•        Закон Конвея в аутсорсинге виден наглядно, структура системы повторяет границу между командой подрядчика и командой клиента. Книга помогает говорить об этом без взаимных обвинений «А вот чья это зона ответственности».

Есть и ограничения. Российская управленческая культура в среднем более иерархична, чем та, на которую рассчитывает автор. Правило обдумывания на 24 часа плохо сочетается с типичной ситуацией «проект горит, прототип нужен к вечеру». Главы о самосознании, дыхании и свободном письме многие наши айтишники воспримут с иронией, это непривычный жанр для технической литературы на русском. Зато знание об этих практиках пригодится при работе с зарубежными коллегами или в зарубежном найме.

В целом, инструменты из частей I и III (модель айсберга, шаблон предложения, TDE, семь вопросов о шаблонах) можно внедрять в российской команде сразу, начиная со своего уровня. Идеи частей II и IV лучше воспринимать как ориентир для личностного развития и как аргументы для разговора с руководством. Автор не зря пишет, что системное лидерство не зависит от должности, и в иерархичной среде этот тезис особенно пригодится.

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

Второе касается секции техинтервью по проектированию систем. На них оценивают умение рассуждать вслух, признавать компромиссы и объяснять, от чего зависит выбор архитектуры. Формат предложения из главы 7 (тезис, три-пять доводов, зачем это нужно, возможные минусы) почти совпадает с тем, что хочет услышать и российский интервьюер. Манера рассуждать, которую книга тренирует, на собеседовании вам пригодится на 100%.

Заключение

«Изучаем системное мышление» — необычная для русскоязычного читателя ИТ-книга, в которой почти нет технологий и в то же время, почти все написано про технологии. Сквозной кейс MAGO и упражнения удерживают текст от ухода в абстрактные рассуждения и философию.  

Для тимлида, архитектора или разработчика, который перерос свою первую роль, книга станет хорошим способом посмотреть на привычный хаос проекта со стороны. В 2026 году, когда код все чаще пишут ИИ-агенты, умение думать о системе целиком становится для ИТ-специалиста основной профессиональной ценностью, за которую платят на рынке труда.

Немного о нас как компании — у нас почти всегда есть вакансии, мы занимаемся заказной разработкой ПО и ИТ‑аутсорсингом (входим в Топ-50 ИТ-компаний России по рейтингу RAEX-2026). Ждем резюме специалистов, готовых работать оффлайн в Москве (ЦАО) или в Томске, а также удаленно из любой точки России. Подробности о вакансиях читайте на странице ХХ.ру, но там откликаться необязательно. Пишите напрямую в ЛС руководителю службы найма (или на почту job@ssp-soft.com). Не забудьте добавить «секретную фразу» в сопроводительное письмо: «Увидел(а) вашу вакансию на Хабре». 

Успехов в освоении системного мышления в ИТ-индустрии!

Нам будет приятно, если заглянете в наш телеграм-канал SSP SOFT, там публикуем разные полезности из мира ИТ, советы для поддержания здоровья и продуктивности, проводим конкурсы с призами.