Читая Нассима Талеба. Часть 2

Эта статья, продолжение серии статей по мотивам прочтения книги Нассима Талеба “Статистические последствия жирных хвостов”

Cсылка на Часть 1

Я переписывал эту статью раз пять, прежде чем решился ее опубликовать. Первые версии статьи были полны графиков, сложных доказательств на основе Закона Больших Чисел и Центральной Предельной Теоремы, перечисления особенностей субэкспоненциального, экспоненциального и степенного распределений и прочей зауми в которую меня начала затягивать книга Талеба.

Большое спасибо Максу Фролову, Лиле Алексеевой и моему коллеге Артемию Анцупову за то, что вовремя вернули меня в реальную жизнь, и убедили меня переписать статью, упростив изложение.

Допустим, вы руководитель IT-департамента, и у вас есть статистика по времени выполнения (Lead Time) всех задач за длительный период (от 6 месяцев и больше).

Имея такую статистику вы можете построить диаграмму Lead Time Distribution используя все имеющиеся данные, разделить ее на типы работ, на классы обслуживания, увидеть сезонность, учесть моменты качественных изменений в оргструктуре, структуре нагрузки и так далее.

В общем, вы можете проанализировать имеющийся у вас на руках огромный пласт статистики и - как учит нас Канбан-метод - в результате, вы сможете делать прогнозы времени выполнения задач с вероятностью 80-90%.

Это похоже на то, как если бы вы пошли к врачу, сделали ЭКГ, и на основе получившегося графика врач сказал бы вам, чего стоит ждать от вашего организма - способны ли вы пробежать стометровку за 15 секунд, или надо расчитывать на менее оптимистичное время?

График Lead Time Distribution является некой “кардиограммой” нашего рабочего процесса, на основе которого мы можем делать выводы о том, чего можно ожидать от нашего “производственного организма” - сможет он поставить новую фичу за неделю, или не стоит от него этого ждать?

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

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

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

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

Получается, что исторические данные плохо подходят для прогнозирования будущих аномалий.

Талеб приводит пример, когда при проектировании дамбы, ее высота определялась на основе максимального наблюдаемого в истории уровня поднятия воды в реке, и говорит о том, что этот исторический максимум был принят за точку отсчета именно потому, что его появление опровергло предыдущий исторический максимум. А дальше Талеб задет вопрос: если предыдущий максимум был опровергнут, то что мешает в будущем появиться новому максимуму, который опровергнет нынешний?

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

Но такой возможности нет, и все что нам остается - лишь наблюдать за уровнем воды в реке, и надеяться, что новых исторически максимумов не наступит. Однако сам факт появления новых, редких исторических максимумов делает распределение уровня воды “длиннохвостным”, а это увеличивает вероятность появления новых исторических максимумов в будущем.Точно так же как наличие тахикардии на ЭКГ является предвестником ещё больших проблем со здоровьем в будущем.

Этот пример с дамбой, ставит под удар весь аппарат прогнозирования Lead Time в Канбан-методе. Ведь при анализе Lead Time Distribution, мы берем максимальное значение Lead Time из исторических данных и утверждаем, что это значение можно принять за SLA = 98-100% который уже не будет превзойден. Но что мешает в будущем появиться новому максимуму, который опровергнет текущий SLA?

На что вообще тогда можно опираться, при прогнозировании Lead Time?

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

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

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

Когда я писал эту статью, я вспомнил, что в авиации, при обеспечении безопасности полетов, говорят так: “для того, чтобы предотвратить катастрофы, нужно работать с инцидентами”.

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

А вот если самолет выкатился за пределы взлетной полосы при посадке - это уже гарантированная катастрофа с человеческими жертвами.

Так вот, чтобы не допускать катастроф, надо анализировать причины инцидентов и устранять саму возможность будущих катастроф.

Этот принцип характерен не только для авиации, но и в целом для промышленной безопасности на производстве.

Когда мы анализируем статистику распределения времени выполнения (Lead Time Distribution) по задачам интеллектуального труда, одним из важных аспектов этого анализа являются так называемые “аномалии” - чрезвычайно длинные значения Lead Time, которые видны на графике, и формируют "хвост" распределения.

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

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

Регулярно анализируя причины появления аномалий, и устраняя причины их появления, мы тем самым не позволяем распределению стать более “длиннохвостным”, что повышает достоверность прогнозов. Кроме того, устраняя корневые причины аномалий, мы тем самым устраняем и причины, способные привести к катастрофе.

Если этого не делать, то мы “огребем” все те неприятные последствия "хвостов" распределения, о которых пишет Талеб и будем постоянно под риском “чёрного лебедя” и новых аномалий.

Перечислим возможности, которые есть в Канбан-методе для работы с аномалиями и “обрезания хвоста”.

• Графики Lead Time Distribution и Lead Time Scatterplot укажут нам на аномалии.
• Диаграмма Cumulative Flow Diagram - покажет изменения средних значений в результате работы над аномалиями.
• Kanban Team Meeting позволяет регулярно проявлять возникшие риски, работать с блокерами и накапливать статистику по инцидентам.
• Каденция Kanban Delivery Review - позволяет проанализировать собранную статистику и принять управленческие решения для того, чтобы устранить причины инцидентов, и не допустить катастроф и “чёрных лебедей” в будущем.
• Risk Review и Operation Review позволяют работать с рисками за пределами нашей зоны ответственности, и принимать меры для оптимизации всего сервиса (Value Stream)

Допустим, вы решили проанализировать причины исторического максимума Lead Time из той статистики работы IT-департамента, о которой мы упоминали в начале статьи.

Скорее всего в результате вы обнаружите что-то из нижеперечисленного:

• либо это была задача про которую забыли (или “забили”) - и поэтому она долго висела не закрытая;
• либо это был “плавающий” дефект, который было очень трудно повторить, и поэтому задачу долго не могли закрыть;
• либо исходные требования были так плохо сформулированы, что мы потратили много времени на то, чтобы понять, что на самом деле надо сделать, а потом долго переделывали, потому что в требованиях было что-то упущено, или при реализации что-то было неверно понято;
• либо одновременно сыграла куча рисков, все пошло не так и мы долго разбирались с последствиями.

Что из вышеперечисленного можно считать “черным лебедем” в терминах Талеба?

Ведь “черный лебедь”, это непредвиденное событие с разрушительными последствиями.

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

По отдельности, эти риски не так страшны. А вместе - приводят к катастрофе. Предсказать, когда они совпадут вместе - невозможно, а работать с каждый по отдельности - вполне возможно.

Не претендуя на полноту списка, попробую перечислить факторы, инциденты с которыми должны быть обязательно исследованы для предотвращения таких “черных лебедей”:

• Точки отказа - технологические и информационные. За первые отвечают системные администраторы, за второе - программисты.
• Точки принятия решений. Это включает в себя болезнь или недоступность заказчика, владельца продукта и других людей, без решений которых невозможна дальнейшая разработка IT-продукта.
• Дефицит экспертизы. Пресловутый bus factor. Если у вас лишь один специалист обладает знаниями по системе, то даже если вы об этом знаете - это рано или поздно это сыграет свою негативную роль, выстрелив как чеховское ружье.
• Информационная безопасность. Если у вас дырки в сервисе, рано или поздно кто-то ими воспользуется.
• Актуальность версий серверного ПО. Чтобы не было сюрпризов из-за устаревшего ПО
• Своевременная оплата лицензий, техподдержки, необходимых сервисов и так далее.

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

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

Какие последствия может иметь долгий Lead TIme для рядового разработчика? Да почти никаких. Ну поскандалит бизнес-заказчик, ну лишат премии, ну заставят работать сверхурочно. Катастрофическими эти последствия никак назвать нельзя.

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

Можно сказать, что разработчики ПО живут в мире Lead Time, а бизнес-заказчики живут в мире последствий от этого Lead Time

Поэтому в мире заказчика долгий Lead Time вполне может являться “черным лебедем”, хотя для разработчиков тот же самый Lead Time может не являться “черным лебедем”, а быть рутинным элементом работы. Такой вот парадокс.

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

И тут крайне важно, чтобы была отстроена прозрачная и всеми однозначно понимаемая система оценки последствий не-выполнения задачи в срок. В терминах Канбан-метода это называется “Стоимость задержки”, Cost Of Delay, который лежит в основе классов обслуживания - он должен быть понятен всем, от заказчика до рядового разработчика.

И конечно же не должно быть ситуации когда “важно все” - это дезориентирует, и заставляет брать любую задачу из очереди, не взирая на последствия.

Короче говоря, все это лежит в области менеджмента, и вполне поддается управлению, если уделять этому достаточно времени.

Итак - следите за инцидентами, и сможете избежать “длинных хвостов” и неожиданных катастроф.

До встречи в следующих статьях!

Следите за анонсами в Телеграм-канале "Данные в действии", чтобы не пропустить новый материал!

Материалы ниже дадут вам инструменты для уверенного прогнозирования времени выполнения задач:

Как Scrum-команде за 5 минут понять время выполнения задач, не заморачиваясь на Story Points

Чеклист: как менеджеру узнать срок выполнения задачи, не отвлекая подчиненных

Как выстрелить себе в ногу, анализируя данные о рабочем процессе

Upstream и Downstream - как их балансировать между собой, чтобы получить максимум бизнес-эффекта?