Есть, куча вопросов, которые каждый задавал себе в той или иной интерпретации, но не каждый мог на них ответить.
Почему IT — пираты XXI века?

В чём конфликт бизнеса и разработки?

Что общего у керамической чашки и IT-бизнеса?

Откуда берутся непроницаемые для опыта люди?

Чем схожи кот и плохой инженер?
Рассказал об этом Александр Бындю на встрече комьюнити Skillbox Code Experts. Я облекла наше двухчасовое общение в формат интервью, чтоб поделиться самыми интересными мыслями и тезисами нашей беседы.

Александр Бындю @AlexanderByndyu — более 17 лет в IT, основатель компании Byndyusoft, автор книги «Антихрупкость в IT» и метода «Карта гипотез». Ведёт телеграм-канал «Мыслим с Бындю». 

— С чего лучше начать внедрение принципов антихрупкости в уже существующую IT-инфраструктуру, особенно если она изначально строилась на других принципах?

— Я помню, как рассказывал на одной конференции в Питере про антихрупкость в IT и ко мне подошёл молодой человек, возглавляющий DevOps департамент в крупной корпорации. Они решили посчитать, как быстро навёрнется корпорация, если весь их отдел исчезнет. Оказалось, что всё развалится примерно за четыре часа. Антихрупкость стоит дорого, потому что это всегда человекомашинные системы.

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

И я бы начинал с людей. Искусственный интеллект кое-как отличает кошку от собаки, поэтому никакой надежды на него нет. Должны быть люди с хорошими инженерными мозгами, которые могут увидеть систему целиком и выстроить нормально и инфраструктуру, и код, и процессы, а ещё работу с бизнесом. Потому что знают, что задача IT – это прежде всего обслуживание бизнес-модели. Если они этого не понимают, то это провал.

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

— А что значит «начинать с людей»? 

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

Если он заяц — даже здоровый, крепкий, мощный — то он всё равно заяц. А если он ещё маленький акулёнок, то уже акула. Рано или поздно он дорастёт до большой акулы. Заяц, к сожалению, в акулу никогда не превратится. Поэтому это правило — «отличники нанимают отличников». Использовать его — обязательно. Вам нужен хотя бы один человек, который будет вокруг себя создавать правильную инженерную культуру. Без этого никуда не развиться. Нельзя просто нанять среднячков или джунов и надеяться, что они когда-то дорастут. Нанимайте сразу сильных. Таких я очень люблю, таких я нанимаю, на таких людях, собственно, всё и держится. 

— А как определить, что человек сильный инженер именно с той точки зрения, что ты говоришь? Есть какие-то критерии? 

— Если ты шёл устраиваться 200 лет назад башмачником, то тебе давали недоделанный башмак и просили с ним что-нибудь сделать. Если вдруг вы ожидали от меня ответ вроде задавайте открытые вопросы, устраивайте лайвкодинг и так далее, то это всё можно делать. Но это будто бы отдать выбор правильных инженеров на откуп HR. 

Загвоздка в том, что правильного инженера может выбрать только правильный инженер. Не существует, к сожалению, никаких тестов, которые бы сравнивали двух разработчиков: этот более крутой, а этот на 15% менее. В строчках кода, конечно же, мерить никто не будет — в этом нет никакого смысла. Но отсюда можно сделать вывод, что ни двух человек, ни две компании — сравнить невозможно. 

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

— Возвращаясь к вопросу насчет сильных инженеров, а есть всё-таки конкретные критерии для хорошего инженера, параметры, на которые ты опираешься?

— Я боюсь говорить конкретные параметры, давайте скажу про ощущения. Нанимая программиста, я сажусь с ним и предлагаю взять простое задание. Например, такое: на вход приходит массив, выбери из этого массива натуральных чисел самый маленький элемент. Человек садится и пишет код. И за 15 секунд становится понятно, соображает ли он в инженерном деле. Потому что есть множество нюансов, которые знает только человек с системным мышлением.

Как поступает супер-мега-джун? Он берет этот массив, ставит точку, и дальше, в зависимости от языка программирования, делает что-нибудь для упорядочивания массива в какую-нибудь сторону, пишет первый элемент, самый маленький, и его сразу возвращает. Хорошее решение, если хочешь построить мост, который упадёт как только по нему проедет первый поезд.

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

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

— На заводах есть метрика – количество дней без травм на производстве. Может, с заводов инженеров нанимать? Что ты думаешь?  

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

Попросили узнать, в чём проблема. Мы созвонились и бизнес сказал, что выделил на это много денег, а система получилась такой, что даже 50% от функций старой системы ещё не закрыта. А вся операционка стала занимать в несколько раз больше времени с новыми крутыми интерфейсами. На что айтишка говорит, что мы же спрашивали, как надо. Как нам говорили, так мы и делали. И сейчас героически с переработками, за которые вы нам, кстати, платите, доделываем систему до нужного состояния.

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

Это классический пример переговоров, на которые меня зовут. К чему я это всё рассказал? К тому, что если бы вы строили завод за 3 млрд, и через три года к вам бы приехала комиссия, а у вас только фундамент, то как минимум пару человек посадили бы. Если мы возьмем IT, то это пираты XXI века. IT разбаловали до предела — дальше падать некуда. Самое худшее последствие для айтишников от несданного проекта — это ретроспектива, на которой будет составлен экшн-план по тому, как мы будем действовать в следующий раз. 

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

Слава Богу, бизнес начал считать деньги, потому что бесплатные деньги закончились примерно в 2021 году для всего мира. Бизнес начал считать деньги. Айтишечка увольняла людей десятками тысяч, до сих пор это делает и будет делать дальше, потому что нанято много бесполезных кадров. И вот эта оздоравливающая петля негативной обратной связи в IT рано или поздно вернётся. И тогда хорошие инженеры воспрянут духом. Им будут реально много платить, они будут ценны. 

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

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

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

У меня нет точного ответа на этот вопрос. Есть разные хорошие практики. Знаете, как в ТРИЗе учат системному мышлению, связанности? Есть хороший приём, возьмите и начните писать небольшие рассказы — главное, чтобы у них был связанный между собой сюжет. Чтобы истории были без логических и сценарных провалов. Базовая идея — это сбор картинки целиком.

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

— То есть, правильно я понимаю, важна системность мышления, возможность улавливать связи прежде всего?

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

Поэтому, конечно же, мы делаем, но обязательно анализируем. А что вообще происходило? Есть такая книга — «Человек безумный» Виктора Тена — про то, как человечество ищет сознание. Откуда у человека сознание? Когда дети маленькие рождаются, у них связи в голове неправильные. Они мир ещё не знают и пытаются соединять пары событий  хаотично. И соединяя пары, они начинают делать вывод, что работает, а что нет. Например, ребенок смотрит на деревья, которые шатаются от ветра, и решает, что , поэтому дует ветер. Это его попытка соединить два события. Он делает это неправильно. Потом взрослый корректирует, либо опыт к нему поступает и он понимает: нет, дует ветер, из-за чего шатаются деревья. Так постепенно он начинает эти пары правильно соединять.

Соответственно, в идеале, нужно найти кого-нибудь, об кого вы будете думать, рефлексировать — это, наверное, самый быстрый путь. Но для этого вас какой-то сильный ментор должен взять себе, сходить с вами на месяц в поход на Эльбрус, чтобы в процессе много общаться. И тогда он вам свою матрицу передаст.

Конечно, рефлексия – наше всё. Делать обязательно надо, но при этом нельзя быть непроницаемым для опыта, иначе эти все «делания» ничем не закончатся. Если вы неправильно соединяете пары, то это просто неправильная приоритизация свойств и неправильное соединение пар. Например, вы берёте микроскоп и видите, что он твёрдый. Делаете вывод: значит, им можно забивать гвозди. Но вы не можете понять, что это не главное свойство микроскопа. Да, он твердый, это хорошо, но не для гвоздей. И я, конечно, привожу сейчас примитивные примеры, но если вы возьмёте инженерию, то вы найдете там множество других.

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

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

— У меня компании уже 12 лет. Я сейчас не буду рассказывать, какие мы проекты делаем, но вы ежедневно этим пользуетесь. У нас такая специфика, что нам дают какие-то критические узлы в бизнесе. Допустим, в крупном marketplace все ключевые решения приняты нами. Например, внедрение Inner source, тарификация заказов, управление складами, управление кассами, выбор платформы разработки или переход на GitHub с изменением процессов. Нам поручают такие задачи, от которых в бизнесе зависит — будут деньги или нет. 

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

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

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

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

— Бывает так, что в компании каждый новый руководитель приходит со своими идеями и амбициозно считает, что именно его — правильные. Тут тоже есть хрупкость, можно её как-то улучшить?

— Нам надо синхронизироваться в понятии антихрупкости, чтобы мы одинаково это понимали. Смотрите, есть хрупкость. Я на одной конференции на выступление взял кружку и просто подбрасывал её перед всеми. Она летела вверх, потом вниз, я её ловил и опять через бок подбрасывал. Если растянуть жизненный путь этой кружки, то можем сказать, что она уже разбита. Если не прямо сейчас, то через месяц или два. Потому что её внутреннее свойство — хрупкость. Оно неотделимо от кружки. Поэтому если мы говорим про что-то хрупкое, то видим узкое горлышко в процессах. Его надо устранять. Но это пока ещё не антихрупкость.

Есть понятие гибкости. Здесь хорошая метафора — дорожный знак. У него есть определённая гибкость. Когда дует ветер, он немного шатается. Ветер дует чуть сильнее и он шатается чуть сильнее. Ветер дует ещё сильнее — он ломается и падает. Потому что при внешних воздействиях у него нет такого внутреннего свойства, которое бы его усиливало из-за внешних негативных или позитивных факторов. Негативный фактор его шатает. Да, он немножко гибкий, но со временем всё равно упадёт. А вот если мы возьмем, например, деревья, то как раз деревья в целом обладают свойством антихрупкости. Потому что когда будет дуть ветер, как Нассим Талеб писал, мне понравилось, многие, конечно же, умрут. Но благодаря смерти многих в целом деревья станут гораздо сильнее, выживут устойчивые деревья. В целом, у деревьев увеличится устойчивость к ветру. Так вот, когда я писал про антихрупкость в IT, я подразумевал, что вы не просто хрупкость снижаете, а добавляете такие свойства, которые помогают усиливаться под внешним давлением.

И здесь, наверное, я опять вернусь к мысли про бизнес-модель. Почему? Потому что, когда приходит новый СТО, то говорит, что раньше всё было неправильно. Но СТО регулярно уходят, приходят новые и опять всё оказывается неправильно. Потому что это всё слабые решения. Компания работает за счёт того, что внутри неё крутится определённая бизнес-модель, причём не обязательно сложная. Если взять монополию на сахар, там бизнес-модель простая как табуретка.

IT должно обслуживать бизнес-модель. Например, нужно вам резервирование ресурсов или нет, от мнения IT никак не зависит. Оно зависит от того, насколько быстро всё меняется вокруг бизнеса, насколько критичны пики и нагрузки. Нужен ли вам действительно чистый код, нужен ли CI/CD, должен ли быть у вас кастомер-он-сайт и другие ответы кроются в бизнес-модели и стратегии компании. Бизнес-модели и стратегии компании должны быть построены так, чтобы когда подует сильный ветер, может, какие-то части и отвалились, но в целом компания стала сильнее. И IT должно в этом активно участвовать. Это моё понимание антихрупкости.

— Мы говорили про всякие измеримости. Скажи, пожалуйста, а как ты измеряешь, хрупкая система или антихрупкая? Может, у тебя какие-то метрики есть? Понятно, что чашку можно стукнуть об пол и понять, а когда это целая система? 

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

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

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

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

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

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

Мой партнер Андрей Шапиро развивает еще два метода: Карта процесса-опыта (замена CJM и Service Blueprint) и Карта реализации историй (замена USM). Эти методы рассчитаны на описание всего бизнеса или услуги целиком от рабочих процессов до конкретных инструментов. Можно шагнуть ещё выше и сразу понять, что кто сделает связку всех трёх методов как код, просто сделает, по сути, AutoCAD для проектирования бизнесов. Сейчас это стало, в принципе, возможно. Кто первый это сделает — это стартап на 100 миллиардов триллионов. Это и будет давать свойства антихрупкости, потому что система будет построена так, что при внешних воздействиях у неё будут все необходимые свойства, чтобы становиться ещё сильнее. Кто Карту гипотез и две другие карты пощупает, тот поймёт, как это происходит на практике. 

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

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

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

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

— А можно ли за счет автоматизации сделать систему менее хрупкой? 

Как-то мы с Асхатом Уразбаевым, одним из первых, кто внедрял Agile в России, в одном очень крупном банке ускоряли поставку релизов. Раньше этот большой банк мог делать релиз CRM раз в 12 месяцев, а мы хотели ускорить это аж в четыре раза. Сначала, естественно, ты читаешь некий тренинг, рассказываешь про scrum, agile, принципы, ценности, стоишь с командами у доски, перетягиваешь карточки туда-сюда. Но потом надо обязательно как тренеру нырнуть в жизнь, оказаться «по пояс в говне, по локоть в крови». Потому что издалека это всё не работает. 

Я с одним разработчиком посидел, со вторым, с тестировщиками и говорю, ребята, в чём собственно ограничение-то? Давайте просто чаще делать релизы. Они говорят, а как это возможно, если у нас регресс — полгода. Я спросил, задумывались ли они про автоматизацию тестирования. Мне говорят, «Александр, ну мы же не тупые, конечно задумывались». И что уже написали около 500 автотестов. 

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

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

Эта история была лет 15 назад, и тогда даже про DevOps никто особо ничего не слышал. Ребята сделали свою работу хорошо, но на 98%. Но вот эти 2%, которые не дали им до конца пропасть перепрыгнуть, всё-таки важны, потому что если ты метр не допрыгнул, то всё равно летишь вниз. После этого у меня было четыре раунда переговоров с безопасниками, и это был ещё тот квест — получить все согласования. Крайне сложная процедура и очень неприятная. 

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

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

— А знаешь ли ты истории, когда совершали ошибки, которые приводили к хрупкости, провалу проекта? Или, может быть, когда пытались сделать проект антихрупким из хрупкого, и делали какие-то такие типичные ошибки, которые приводили к полному фиаско? 

— Мне этот вопрос напомнил мою молодость, когда мы внедряли scrum во все щели. Типичная история была такая: решено, теперь мы будем быстро реагировать на внешние изменения и так далее, теперь у нас будет scrum. И вот идёт первый релиз, там какая-то поставка, второй – какая-то поставка, третий – какая-то поставка, а потом бизнес такой, немного меняем направление. И IT такое – блин, нам теперь всё придётся переписать, и бизнес такой – scrum не работает. 

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

Когда из-за ошибок айтишников, ломался бизнес, я думаю, у каждого найдётся даже не одна история. Я, конечно, наблюдал это очень много раз. Потому что меня на всякие постмортемы звали разбираться, собирать назад воедино бизнес во что-то работающее. Я, допустим, домен дривен-дизайн защищал перед айтишниками в то время, как за этим наблюдал бизнес. Был и по другую сторону: защищал что-нибудь от айтишников для бизнеса.

— Скажи, а кибербез и антихкрупкость как-то должны мэтчиться? Как одно на другое влияет? Как мы должны об этом думать?

— Кибербезопасность, на самом деле, ничем не отличается от бухгалтерии или от отдела юристов, которые занимаются обслуживанием бизнес-модели. Они должны делать ту же работу по тем же принципам. Ничего такого у них невероятно специфического в работе нет. Вы можете сказать, что кибербезопасность, сложная зона, инженерные знания и так далее. Да. Но я вам скажу, что хороший юрист часто стоит гораздо больше, чем хороший безопасник. Уберите из Google продажников, маркетологов и так далее, и вы с удивлением узнаете, как быстро Google потеряет свою прибыль. Не всё зависит от айтишников. Они наравне с другими крутятся вокруг бизнес-модели. 

— У тебя целый раздел книги посвящен техдолгу. Скажи, а как понять, что сейчас в приоритете нужно устранять технический долг в условиях ограниченных ресурсов и времени? Или что сейчас надо чем-то другим заниматься? За что браться, когда всё горит? 

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

Идея в том, что когда при расширении системы вы ничего не меняете в существующем коде, то можете даже говнокод этот не заметить. То есть на этом этапе говнокод заметит только эксперт. Все проблемы внутри системы начинают возникать тогда, когда надо вносить изменения. Вообще отсюда все наши проблемы в айтишке. Если бы этого не надо было делать, то вообще 90% практик в принципе были бы бесполезны. Но изменения вносить надо.

Вообще инженерная работа сложная и для человека не очень привычная. Как Георгий Щедровицкий приводил классный пример — танец лошадей. То есть лошадей можно научить танцевать, причём синхронно. Надо ли это лошадям? Точно нет. Прикольно ли это выглядит? Да, прикольно. Насколько тяжело это сделать? Драматически тяжело. Так вот, системное мышление, инженерная работа и так далее — это как танец лошадей в человеческом обществе.

В целом, людям это вообще не надо, к сожалению. Мало кто понимает, что и как устроено вокруг них или в бизнесе, в котором они работают. И вот тут недавно я читал черновик одной книги про Agile. Там сказано про то, что мир стал (!) BANI. BANI переводится примерно как «мир стал неопределённым, непредсказуемым, рискованным». Неужели кто-то думал, что мир таким не был? Если вдруг человек не понимает, что мир всегда такой, он всегда непредсказуемый, хаотичный, и вот это вот всё, это значит, что он не видит даже ближайшую к нему надсистему. Это значит, что инженером он в принципе стать не может. Учится видеть надсистемы и свое место в этих связках – это и есть танец лошадей, в котором мало кто хочет участвовать.

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

Друзья, надо принять тот факт, что мир хаотичен и непредсказуем. Познание мира — задача практически бесконечно сложная. Познание себя — происходит только через взаимодействие с этой системой. Вот этим в жизни и стоит заниматься: узнать себя и хотя бы чуть-чуть успеть до конца жизни пощупать этот мир. Это, наверное, самое достойное занятие, которому стоит уделять время. Естественно, по дороге вы станете хорошими инженерами, это будет просто следствие.