Мне всегда была интересна тема антихру��кости и работы Нассима Талеба — особенно в контексте их применения в IT.
Книга «Антихрупкость в IT» попала в мой список рекомендаций больше года назад, после одной конференций в Казахстане. Кто-то посоветовал её, когда я в очередной раз рассказывал про идеи Талеба. Скорее всего, речь шла о Рискуя собственной шкурой — книге, которая, если честно, нравится мне даже больше. Было бы здорово, если бы кто-то когда-нибудь переложил её идеи на мир IT. Но да ладно.
Дисклеймер: рецензии на книги — дело неблагодарное. Мы всё равно видим в них разное. Но для меня это способ лучше разобраться в своем опыте, а для вас — возможно, найти зацепки и понять, стоит ли читать (или слушать) эту книгу.
Обзор книги
Книга может создать впечатление, что она написана аутсорсером для аутсорсеров. Это ложная штука, которая способна отбить желание дочитывать её. Но на самом деле многие идеи применимы в любой разработке, поэтому всё-таки стоит дать книге шанс.
Аудиоверсия (именно её я слушал) начинается с зачитывания отзывов и рецензий, и, если честно, это было ужасно. Это самые рафинированные SEO-тексты, которые я когда-либо слышал. Их настолько неприятно слушать, что сложно понять, зачем их вообще включили в аудиокнигу. Возможно, это было требование редакции — своего рода кнопочное решение, о котором позже говорит и сам автор.
Кнопочные решения
Кнопочные решения — это концепция, которая оказалась мне особенно близка. Я сам пришёл к чему-то подобному и называю это “решать решения”.
Суть кнопочного мышления проста:
Когда возникает проблема, наша первая реакция — предложить решение.
Упала конверсия? “Давайте поднимем кнопку повыше.”
Но почему? Зачем? Даже если это решение сработает, мы всё равно не поймём, в чём была настоящая проблема.
Когда заказчик приходит с готовыми решениями, он покупает только руки, а не голову команды. А значит, вероятность попасть в реальную потребность становится крайне низкой.
? Мы можем повысить шансы на успех, если каждый в команде пон��мает, что именно нужно решить, а не просто механически выполняет задачи.
Кстати, на эту тему у автора есть отдельная статья: Кнопочное мышление против целостного IT-продукта / Хабр
Pet Features
Ещё одна интересная идея, которую автор взял из Impact Mapping. Я обычно называю это “хотелками”.
Pet Features — это бесполезные хотелки, которые не решают настоящую проблему, но звучат красиво.
Когда мы пытаемся понять проблему, мозг часто сразу же предлагает решение.
От них чаще всего страдают дизайнеры и фронтендеры: такие хотелки легко увидеть, нарисовать и продать.
И, к сожалению, этим грешит не только бизнес:
Разработчики, имея доступ к коду и свободу его изменения, тоже склонны притаскивать в проект всё, что блестит — как сороки.
В целом ничего нового, но вот что зацепило — идея не бороться с хотелками.
Я раньше старался их отвергать и копать реальные потребности. А автор предложил другую точку зрения:
Не бороться. Просто спрашивать. Хотелка — это ещё один отличный источник для поиска реальных потребностей.
С такой точки зрения я никогда не думал ?
В книге описан один из приёмов, который я отметил для себя:
Мысленно перенеситесь на этап завершения проекта и представьте: если всё уже работает — как мы это поймём? Этот вопрос помогает сфокусироваться на цели, а не на решении. Но для его применения нужно заранее подготовить человека — просто так люди плохо выходят из состояния “готовых решений”.
? Хотелки и готовые решения — это не враги. Это подсказки. Просто учитесь правильно их раскапывать.
Лирическое отступление №1: Импакт-мэппинг и дерево будущей реальности
Видно, что автор вдохновляется книгой: Impact Mapping на практике
Честно говоря, сама «Антихрупкость в IT» могла бы называться именно так — Impact Mapping в IT.
Поэтому, если вам откликается эта тема, рекомендую добавить эту книгу в свой список к прочтению.
Во время чтения книги у меня появилась стойкая ассоциация:
Импакт-мэппинг на самом деле очень похож на дерево будущей реальности из теории ограничений.
В чём сходство:
И в импакт-мэппинге, и в дереве будущей реальности мы начинаем с глобальной цели и выявляем предпосылки, которые оказывают на неё серьёзное влияние.
В процессе работы находим неочевидные изменения, реально приближающие нас к результату.
И там, и там можно “накладывать патчи” — вносить небольшие коррективы, чтобы локально улучшать систему.
Это напоминает финальные лепестки импакт-мэппинга: “Что мы можем сделать прямо сейчас, чтобы приблизить выполнение условия?”
В чём различия:
В теории ограничений дерево строится как бесконечно расширяемая система.
В импакт-мэппинге структура ограничена конечными шагами и чёткими рамками.
Теория ограничений дополнительно вводит понятия необходимых и достаточных условий для достижения результата.
Гипотезы и их проверка
Ещё одна очень важная мысль: последняя колонка перед Done должна быть “Проверка достижения цели”. Я сам называю это этапом сбора обратной связи.
Ведь мало просто закончить разработку фичи — её нужно довести до реального использования и проверить, сработала ли гипотеза.
Кстати, шаблон гипотезы на удивление прост:
Если мы сделаем ___, то получим ___, потому что ___.
И это на голову выше привычных User Story — без регистрации, SMS и прочего.
Когда понимаешь, что задач в чистом виде не существует, а всё вокруг — это гипотезы, мир становится куда интереснее. Их нужно не выполнять, а проверять.
В IT это часто вызывает страх:
“А вдруг мы сделаем что-то непродуманное?”
Но если начать работать через гипотезы даже в технических вопросах, становится легче.
Мы перестаём угадывать и начинаем искать ту гипотезу, которая действительно сработает.
Подумайте об этом на досуге.
Ещё один важный инсайт от автора:
Не нужно брыкаться и докапываться до сути проблемы каждого решения. Если мы объяснили последствия проблем, а клиент всё равно хочет фичу — её стоит сделать.
Это реально важно. Иногда путь к осознанному управлению начинается именно так: клиент через несколько попыток сам поймёт, что гипотезный подход работает лучше.
В каком-то смысле это “нулевая гипотеза гипотез” — проверить пару раз неосознанные требования, чтобы убедиться, что гипотезы всё же эффективнее.
Но не скатывайтесь в “я же говорил”. Это рак нашей индустрии. Если вы так говорите, значит, внутренне вы не согласились на решение.
Оценка проектов: вероятность вероятностей
Чем больше времени мы тратим на оценку, тем меньше реальную пользу от неё получаем.
Полная определённость будет достигнута только после реализации проекта, а не на его старте.
Это эффект ретроспективного мышления:
Когда проект завершён, все ошибки кажутся очевидными, и возникает вопрос:
“Как мы вообще могли это не заметить?”
Но увидеть это заранее почти невозможно.
Одна из самых сложных концепций в разработке — это вероятность вероятностей.
Мы всегда работаем в условиях неопределённости.
Так когда стоит остановиться и прекратить уточнять требования?
— Объём планирования проекта и задач должен быть соразмерен их трудозатратам на реализацию.
? У риска тоже есть цена. Мы можем снижать вероятность ошибки, но важно не превысить разумный бюджет на это снижение.
Ещё одна идея, которая мне откликнулась:
Если хотя бы один из трёх параметров (сроки, стоимость, качество) не зафиксирован, это порождает неопределённость. Если мы знаем дату релиза и стоимость проекта, мы можем выбрать способ реализации.
И да, это классика: проектный треугольник — стоимость, время, качество.
Дедлайны работают, но не так, как принято думать.
Они помогают не “подгонять” людей, а перейти от абстрактных решений в вакууме к прикладному мышлению: какое решение действительно можно реализовать в данных условиях.
Что можно почитать по теме:
Сроки: Fixed time & budget, flexible scope — фиксируем сроки и бюджет, варьируем объём задач.
Оценки: Подход No estimates — лучше просто измерять реальность по факту, а не пытаться её предсказать.
Extreme Programming (XP)
Кстати, сложную природу проектной неопределённости заметили не только автор книги и я.
В области разработки особенно интересно читать про Extreme Programming (XP).
Рекомендую:
Scrum и XP, заметки с передовой — и большое спасибо ребятам из Agile Ukraine за перевод.
Экстремальное программирование помогает не только быстрее разрабатывать код, но и поддерживать высокое качество — даже в условиях высокой неопределённости.
Техническое задание
Если ТЗ противоречит целям проекта, глупо следовать ему буквально. Эту проблему нужно эскалировать и предложить более выгодное решение для бизнеса.
ТЗ можно написать только для простых задач, где более-менее понятно, как их решать. Все остальные задачи ближе к R&D — их нельзя забить в текст раз и навсегда.
Особенность ТЗ:
ТЗ обычно монолитное: его нужно выполнить полностью.
В нём часто замалчиваются нюансы, требующие исследований.
В итоге можно случайно “высечь в камн��” нерабочие решения вместо того, чтобы оставить белые пятна.
Как стоит подходить к планированию:
Мы принимаем, что всегда будет существовать вероятность вероятностей — абсолютной определённости нет. Но хотя бы мы будем в консенсусе с реальностью.
В любом тз неизбежно будут противоречия и баги. Избавиться от них полностью невозможно.
И хотя может показаться глупым двигаться по “недоделанному плану”, гораздо опаснее — пытаться следовать идеально проработанному (но всё равно нереалистичному) плану.
Настоящая цель планирования:
Очертить цель.
Построить процессы, которые будут работать как компас: помогать корректировать маршрут в реальности и находить кратчайший путь к цели.
? Техническое задание — это не карта. Это компас. Его задача — не заставить вас слепо следовать пути, а позволить корректировать маршрут в реальности.
Лирическое отступление №2: Waterfall — лучший друг Agile
Мне кажется, я наконец понял, почему у многих возникают проблемы с Agile и Scrum.
Когда рассказываешь кому-то о хорошо работающем Scrum-процессе, часто в ответ слышишь: “Так это же водопад!”
И вот здесь начинается основная ошибка: люди противопоставляют гибкие методологии и последовательность действий, считая, что Agile — это полная импровизация.
Но именно отказ от последовательности убивает эффективность.
Важно понять:
Нигде не сказано, что Agile — это непоследовательная работа.
Agile-подходы строятся на последовательных итерациях.
Это бесконечный цикл, а не импровизация: вместо того чтобы написать императивную функцию до конца, мы пишем её в виде цикла.
На самом деле паразитная параллельность существует даже в классическом Waterfall.
Если вы когда-нибудь видели диаграмму Ганта, вы наверняка замечали, что там тоже много параллельных этапов.
На сегодняшний день эффективно параллелить можно только разработку разных систем.
Но нельзя параллелить разработку модулей внутри одной системы.
? Agile — это не антипод Waterfall. Agile — это последовательная, но итеративная работа. И последовательность важна, даже если этапы короткие и непрерывно повторяются.
Как продать микросервисы бизнесу?
Одна из самых неожиданных глав книги — о микросервисной архитектуре.
Что особенно важно — эта тема логично встроена в общий контекст: автор связывает переход на микросервисы с ранее описанными проблемами управления изменениями.
Если у вас стоит задача поговорить с бизнесом на одном языке о переходе к микросервисам, обязательно обратите внимание на этот раздел книги.
Хотя лучше сначала прочитать всю книгу — тогда картина будет гораздо полнее.
Эти идеи могут помочь вам трансформировать архитектуру, если вы уже подошли к этапу, когда изменений не избежать, но не знаете, как на это выделить время, деньги и ресурсы.
Микросервисы — естественный ход развития компании
Автор описывает естественную эволюцию систем:
Сначала создаётся одно приложение для решения одной бизнес-задачи.
Со временем это приложение превращается в тяжеловесный монолит.
При первой попытке разделить монолит на части многие команды оказываются не готовы к возрастающей сложности.
Монолит делят на множество микросервисов, но из-за незрелости процессов получается не стройная система, а распределённый монолит с новыми проблемами.
Раньше простые задачи — вроде трассировки запроса — решались легко. Теперь каждая из них превращается в вызов.
Когда же команды справляются с этими сложностями, система обретает новую структуру: появляется стройная, масштабируемая архитектура.
Добавление новых микросервисов увеличивает сложность линейно, но даёт важное преимущество:
На последнем этапе бизнес-заказчик начинает видеть готовые строительные блоки и предлагает собирать новые продукты без полноценной разработки, просто соединяя существующие компоненты.
Микросервисы = Антихрупкость
Микросервисы — это рой, который невозможно сбить.
Они становятся ярким примером антихрупкости в IT.
Создание архитектуры, не боящейся перемен, выгодно для бизнеса.
Дешёвое масштабирование: Пользовательская нагрузка редко ложится равномерно на всю систему. Обычно нагружаются отдельные бизнес-процессы, и сервисная архитектура позволяет масштабировать их изолированно.
Горизонтальное масштабирование: Добавление мощностей на уровне конкретных сервисов упрощает масштабирование всей системы.
Гибкость бизнеса: Мы не делаем микросервисы ради микросервисов. Мы делаем их ради гибкости — там, где это действительно оправдано.
? Микросервисы — это не просто про архитектуру. Это про способность бизнеса быстро реагировать на изменения и масштабироваться без полной перестройки всех процессов.
Low-code: когда стоит, а когда не стоит
Ещё одна часть книги, которую я не ожидал увидеть, — это обсуждение low-code платформ как следующего шага после микросервисной архитектуры.
Когда вы вынесли все бизнес-юниты в отдельные сервисы, логика работы компании становится настолько прозрачной, что её можно программировать практически без кода.
Желание создать собственную low-code платф��рму звучит заманчиво, но, честно говоря, я бы в это не ввязывался.
Из таких инициатив чаще всего получаются чудовища.
Хотя, например, если технологически вы используете React, то на каком-то этапе становится странным верстать лендинги вручную — удобнее было бы иметь свою систему быстрой сборки. И тут мысль о внутреннем low-code инструменте начинает казаться логичной.
Главная проблема таких решений:
Любая серьёзная правка базовых компонентов может всё сломать.
Затраты на разработку собственной платформы неоправданно высоки.
Чтобы построить нормальный продукт, нужны очень сильные разработчики.
И самое главное: такая платформа никогда не остановится на первой версии. Команда будет поддерживать и развивать её всегда.
Вдобавок к этому:
Понадобится отдельная поддержка пользователей: обучение, ответы на вопросы, помощь с задачами.
Платформа неминуемо будет разрастаться и усложняться.
Все типичные проблемы любой крупной системы начнут проявляться.
Автор книги подчёркивает: единственный реальный способ окупить такие вложения — выйти с платформой на внешний рынок. Но большинству компаний это не нужно.
Когда применение low-code оправдано?
У low-code есть важное преимущество: визуализация алгоритмов.
То, что обычно скрыто в коде, здесь можно увидеть в виде схемы.
Это позволяет большему количеству людей в компании разговаривать на одном языке.
Рабочий подход: Использовать low-code для визуализации бизнес-процессов, а само исполнение оставлять за традиционным кодом.
Особое внимание в книге уделено BPMN-платформам вроде Camunda:
Экономия времени и денег благодаря декларативному описанию процессов.
Процессы могут создавать не программисты.
Документация всегда актуальна (как автогенерация, только наоборот).
Движок берёт на себя рутинные задачи — таймеры, переходы между состояниями.
Конечно, на BPMN нельзя построить всё. Но можно взять лучшее от двух миров: визуализация процессов + традиционная разработка там, где это действительно нужно.
? Low-code — это не магия. Использовать его стоит там, где важна скорость, визуализация и вовлечённость бизнеса, но не в качестве замены нормальной разработки.
Лирическое отступление №3: Зачем иногда лучше обойтись без кода
Я считаю, что если у нас есть возможность что-то не писать — лучше не писать.
Код — это камень: высекая в нём бизнес-правила, мы надолго их фиксируем.
Если бизнес-процесс ещё не устоялся, лучше использовать более гибкие системы.
Я думаю, что до масштабов настоящих low-code систем я пока не доходил. Но был близок, когда работал CTO в EdTech-бизнесе.
Например из моего опыта, я таким образом строил аналитику на базе metabase поверх всех систем включая данные отдела продаж.
У меня под руководством была команда по работе с AMO CRM, которая по сути является low-code платформой:
На ней действительно можно было быстро прототипировать бизнес-процессы.
Мы использовали флоу-билдеры вроде n8n и аналогичные решения.
Это позволяло:
Строить большое количество отчётов без дополнительной разработки.
Анализировать текущее состояние продукта и выявлять технические сбои.
Я даже не представляю сколько бы денег нам пришлось потратить чтобы это всё запрограммировать потому что большинство из этих отчётов были временные и нужны были лишь для анализа ситуации
Проблема качества данных
Если кто-то работал с low-code системами вроде AMO CRM, он поймёт: строить отчётность там сложно.
Базы данных часто не нормализованы.
Нет гарантий корректности данных.
Никто не понимает, что с этим делать — объём проблем пугает бизнес.
Что мы сделали: Мы придумали механизм, который называли гуардами — “плохометры” для данных.
Начали измерять отдельные проблемы: сколько плохих данных поступает в день.
Параллельно обучали пользователей, как правильно редактировать данные.
Выдавали инструкции по исправлению ошибок.
Через пару месяцев:
Стало видно, что качество данных реально улучшается.
Появилась возможность строить полноценную аналитику. За полгода мы исправили все основные проблемы.
Так что берите этот подход на заметку — он отлично работает.
А сейчас переходим к самой интересной главе — унаследование легаси
К сожалению, в этом разделе книги для меня не оказалось откровений. Впрочем, их, наверное, и не могло быть.
Автор описывает все шаги, которые нужно пройти, чтобы унаследовать чужую систему, — и делает это абсолютно верно.
Конечно, представляя себе весь объём работы, я испытал лёгкий ужас.
Когда вам передают код и несколько репозиториев, вы обычно:
Не уверены, какая версия стоит на продакшене.
Не имеете всей CI/CD.
Часто даже не понимаете, как реально работает система.
Получаете документацию, которой нельзя верить на 100%.
И у вас есть живой production, который может в любой момент сломаться — и теперь это ваша зона ответственности.
Один из первых шагов, который нужно сделать:
Аккуратно собрать всё вместе.
Начать документировать: из чего состоит система, что делает каждая её часть, какие есть интеграции.
Если задуматься, в этом всём есть парадокс и ирония.
Каждый день мы сами передаём будущим себе ужасные легаси-системы: недодокументированные, запутанные, хрупкие. Но как только попадаем в чужую легаси-систему, мы сразу видим, насколько это тяжело — и стараемся навести порядок.
? Легаси — это не только про старые системы. Это про всё, что создано без заботы о будущем пользователе и разработчике. Даже если этим пользователем будете вы сами.
Технический долг
Один из признаков того, что у команды всё хорошо и технический долг под контролем — это предсказуемый график поставки.
Если команда стабильно выдаёт примерно одно и то же количество задач или фич, значит, процессы работают.
А вот если график поставок постоянно рваный — это явный сигнал, что где-то накапливается проблема.
Интересная мысль, о которой я раньше не задумывался:
Технический долг бывает не только в коде, но и в макетах дизайна. Если макеты забывают обновлять вместе с системой, возникает несоответствие — та же самая форма долга.
Лирическое отступление №4: Экономическая модель технического долга
Мне особенно близка аналогия с инвестициями:
Плохой долг — это кредиты для латания дыр.
Хороший долг — это инвестиции для ускорения развития.
С этой точки зрения:
Технический долг — это инвестиция времени. И он должен быть осознанным и оправданным.
Кто может брать технический долг:
Команда разработки — например, когда из-за ограничений системы предметная область реализуется не совсем корректно.
Бизнес — когда осознанно принимаются риски ради ускорения выхода на рынок.
Банкротство проектов
В конце книги автор приводит мысль, что проекты могут буквально обанкротиться:
система становится настолько запутанной и непригодной к поддержке, что продолжать работу невозможно.
К счастью (или к сожалению), я лично не сталкивался с такими случаями в реальности.
Но думаю, я не один такой.
Разработка вообще похожа на D&D-игру:
Это RPG с бесконечными случайными туннелями, но по ходу можно выносить опыт и становиться лучше.
? Технический долг — это не зло. Это инвестиция в развитие. Но только тогда, когда он осознанный и управляемый.
Почему у книги такая обложка?
Писать книги сложно. Это совсем не то же самое, что написать пост в блоге — это цельное, законченное произведение, и это уже само по себе заслуживает уважения.
Как человеку, которому интересна тема самиздата, мне было особенно любопытно узнать, как создавалась эта книга.
Когда-то я наткнулся на статью об истории её издания: Как самостоятельно издать книгу? На примере книги «Антихрупкость в IT»
В статье описаны забавные моменты — например, эпопея с выбором обложки и неудачный опыт работы с подрядчиками.
Но честно говоря, тогда обложка книги показалась мне странной.
Но после прочтения книги я понял, почему автор выбрал именно такой вариант — и, да, он идеально иллюстрирует основную идею книги.
Микросервисы — это как рой.
Даже если в систему что-то “влетает”, она не разрушается полностью, а адаптируется и продолжает работать.
Это прекрасная метафора для всей идеи книги.
Больше чем итог
Автор утверждает, что использует термин антихрупкость именно в смысле Талеба.
Но, строго говоря, полной антихрупкости в книге нет:
Антихрупкость подразумевает, что система становится сильнее через сложности. А не только как способность системы подстраиваться под изменения.
А этой части — роста за счёт ударов судьбы — почти нет.
Возможно, автор раскроет её в следующей версии книги.
Тем не менее: Книга действительно рассказывает, как строить гибкие системы, адаптирующиеся к изменениям.
Это важный и ценный материал.
Как я бы описал книгу кратко:
Это книга о гибкой методологии разработки, рассказанная через призму микросервисной архитектуры.
И хотя, строго говоря, это не совсем антихрупкость, читать было интересно.
Походу прочтения я периодически вспоминал, что у автора есть собственное бюро аутсорс-разработки.
Наверное, отчасти книга — способ рассказать о себе и своих услугах.
Есть ли в этом конфликт интересов?
Технически — да.
Фактически — нет.
В книге почти нет открытой рекламы.
Иногда, признаюсь, мне самому хотелось обратиться к автору за консультацией — но я быстро отогнал эти мысли.
Заключение
Плохая ли это книга из-за не антихпупкости и странных отзывов в начале?
Ни в коем случае.
Кстати автор планирует выпустить новую версию книги в 2027 году:
Блог Александра Бындю: Новая книга про антихрупкость в ИТ в 2027 году
Очень надеюсь, что там он раскроет тему ещё глубже, и поработает над отзывами.
Портит ли её то, что автор — аутсорсер?
Наоборот.
Я сам не сторонник аутсорса, но благодарен тем, кто его делает, потому что аутсорсеры накапливают колоссальный опыт.
И эта книга — лучшее тому подтверждение.
Конфликт интересов?
Даже если он и есть, он не влияет на суть.
В книге много интересных идей.
В итоге:
Эта книга — хорошая попытка собрать разрозненные D&D-забеги по проектам в более стройную систему.
И у автора, на мой взгляд, это получилось.
Особенно сильная глава — о масштабировании систем и о продаже микросервисной архитектуры бизнесу.
Спасибо за прочтение! У меня получилось достаточно самостоятельное произведение.
Но я всё равно рекомендую познакомиться с оригинальной книгой — ведь каждый увидит в ней что-то своё.
Если после прочтения этой статьи вам что-то особенно откликнулось — это отличный повод добавить книгу в список прочтения.
А на этом у меня всё.
Больше моих материалов можно найти в Telegram или Twitter, где я, как и автор книги, пытаюсь структурировать свой опыт в мире продуктовой разработки.
Буду рад видеть вас в обсуждениях здесь и там