IT - Менеджмент

Вступление

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

Элияху Голдратт предложил неожиданное объяснение этой проблемы в своей Теории ограничений (Theory of Constraints, TOC). Что интересно, большинство идей TOC кажутся удивительно простыми. После знакомства с ними возникает ощущение: «Это же очевидно». Но если посмотреть на реальные проекты и организации, становится заметно, что усилия по-прежнему направлены на локальные улучшения отдельных процессов, а не на поиск ограничения, которое определяет производительность всей системы.

Очевидность идеи ещё не означает её широкого применения.

В этой статье мы разберём одну из ключевых идей Теории ограничений на нескольких простых иллюстрациях.

1. Идеальная производственная система (утопия)

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

Идеально сбалансированная система — полезная модель для понимания, но не отражение реальности.

2. Реальная производственная система

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

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

Ограничение одного процесса становится ограничением всей системы.

3. Локальные оптимизации

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

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

Локальные улучшения не устраняют причину ограничения. Они лишь ускоряют накопление работы перед ним.

Именно поэтому компании могут годами инвестировать в повышение эффективности отдельных подразделений и при этом практически не увеличивать производительность всей системы.

4. Фокус на ограничении

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

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

Улучшение ограничения может увеличить производительность всей системы.

5. Что произойдёт дальше?

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

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

Новое ограничение — не провал предыдущего улучшения. Это следующая точка роста системы.

Заключение

Теория ограничений меняет сам взгляд на улучшение системы. Нам привычно искать возможности сделать быстрее каждый отдельный процесс. Но, как мы увидели, такие локальные улучшения могут вообще не увеличить Throughput системы — и даже привести к ещё большему накоплению незавершённой работы.  Вместо вопроса «Что ещё мы можем улучшить?» TOC предлагает сначала задать другой:

«Что сейчас ограничивает производительность всей системы?»

И только после этого решать, куда направлять усилия. Когда ограничение улучшено, Throughput растёт, а ограничение перемещается в другое место. Мы находим его — и цикл начинается снова.  Не нужно улучшать всё. Нужно улучшать то, что ограничивает систему сейчас.

Читайте мою серию: Усталый Босс

Прошлые статьи:

• Agile 2.0 Где заканчивается перфекционизм и начинаются итерации

• Agile без ритуалов — эволюция после бюрократии

• От PoC к масштабу — как превратить пилот в повседневную реальность

• Виды логики и их влияние на мышление

• Эволюция современной службы поддержки

• Когнитивные искажения в ИТ: коротко, по-человечески и с примерами

• Вариант ретроспективы для ИТ команд (postmortem)

• Andon Cord (вторая серия) Как Andon Cord помогает даже там, где никто об этом не думал

• CMM (Capability Maturity Model) Модель зрелости потенциала компании и как по кредитному рейтингу понять с кем имеем дело

• Andon cord

• Люди которые сделали современный менеджмент

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

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

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

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

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

Сверхинтеллект не может относиться к обратимому и необратимому одинаково - цена ошибки структурно разная.

Ты можешь удалить ветку. Можешь удалить коммит через reset. Можешь удалить файл. Всё это обратимо - есть reflog, есть история, есть пушы на remote. Пять минут, восстанавливается.

А можешь удалить репозиторий. Force push в main. Revoke ключа, которым шифровался backup. Удалить S3-бакет с production-данными без версионирования. Эти действия - другого класса. Не «сложнее восстановить» - а структурно невосстановимы или восстановимы только через признание катастрофы.

Любой инженер, у которого был хоть один инцидент, знает эту разницу нутром. Есть rm file и есть rm -rf /. Они оба - команда rm. Но это разные действия, требующие разной процедуры.

В управленческих решениях - то же. Но управленческой практики, отделяющей rm file от rm -rf /, почти нигде нет. Все решения идут через одно и то же ревью, с одними и теми же сроками, в одной и той же очереди. И раз в полгода кто-то делает rm -rf / в карьере или в команде.

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

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

В середине квартала приходит руководитель на уровень выше: «Эту фичу нужно выкатить к понедельнику. Тестов сделать не успеваем. Это исключение, один раз».

Вы уступаете. Правильно ли? На эту конкретную фичу - возможно, да. В конкретном квартале - может быть, оправдано. Но посмотрите, что происходит с правилом.

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

Вы не отменили правило. Вы просто показали, что оно отменяемое. В нашей среде это - одно и то же.

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

Распожаризация невозможна, пока работают поджигатели

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

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

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

Тогда я этого не понял. Если у вас всё горит, то может быть стоит потратить силы на то, чтобы не допускать пожаров? Но теперь я осознал, что руководство по распожаризации отвечает на 1 и 3 теоремы выше, нащупав часть математического оптимума.

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

Мы читаем умные книги. Смотрим крутых практиков. Внедряем сложные системы управления проектами. Настраиваем учет задач и времени. И при этом работаем в организациях, которые требует от нас нарушения всех трёх ограничений одновременно.

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

Симптом: «всё срочно».

Нарушение 2. Вы принимаете решение о найме/увольнении и решение о цвете кнопки с одинаковой скоростью — потому что они идут в одной очереди.

Симптом: «я за пятницу согласовал переход на новый фреймворк, увольнение сотрудника и название релиза».

Нарушение 3. Вы 10 раз решаете один и тот же вопрос - потому что в организации нет правил, есть только прецеденты.

Симптом: «в понедельник то же самое, что было в прошлый понедельник, но решаем с нуля».

Вот почему тайм-менеджмент не помогает. Он не трогает корень.

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

Если ты такой умный, то как не работать на износ?

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

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

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

Как говорит мой знакомый безопасник: когда от меня требуют принять решение, то думать о нём я начну не раньше завтрашнего дня.

Заведите вторую очередь - для необратимых решений. Они не идут в общем потоке. Они ждут отдельного окна. Пятница, 10:00–12:00, только необратимые. Что делать, если там уже новые пожары? Горели вчера, будут гореть завтра. А в это окно вы занимаетесь важным. Каждую неделю. Защищайте свое право на подумать.

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

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

Честно - это не спасет, но даст 20–30% облегчения. Корень проблемы в “чайка менеджменте” и бесконечном тушении кризисов. Но обозначить настоящую проблему - не половина решения, но начало пути к реальным изменениям.

Сверхинтеллект тоже будет перерабатывать в среднем менеджменте средней российской организации

В прошлую пятницу я утвердил ещё один MVP в Figma. На выходных отдыхал. Даже не заглядывал в рабочие чаты. Никто не сгорел и не умер.

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

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

Коллеги и начальство знают, что если я сказал, что решение будет принято в четверг вечером, то бессмысленно требовать от меня ответа раньше, чем в четверг 17 часов. Это мое окно особо важных решений - четверг с 14 до 17. Даже под угрозой увольнения я сохранил правило. Работать продолжил. Это отдельная история.

Потому что даже сверхинтеллект выгорит в среднем менеджменте средней российской организации. Не потому, что он не имеет степени MBA или не успел овладеть практиками PMBOK 8. Потому что такая среда. Потому что он эффективен и на нём будут ездить, пока не сломают. Потому что учитывать ограничения заинтересован сотрудник (мы с вами), а не организация.

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

• Сколько вообще напоминаний приходит в неделю и в день.

• Насколько важно в напоминании человеческое присутствие.

Ответственный за задачу

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

Когда задачи — не задачи

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

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

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

Тактика пустого инбокса

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

1. Отключите все уведомления

2. Составьте себе расписание дня. Заложите туда, что вы раз в X часов заходите в каждое место с уведомлениями и разбираете их

3. Включите только критичные уведомления — о предстоящих встречах, сообщения от начальника.

Когда настанет время проверки инбоксов — заходите и разбирайте их под ноль. И следующие пару часов снова спокойно работайте.

Итоги

• Сделайте коллектор задач, чтобы было минимум мест куда надо ходить и их проверять. Чат-бот или таск-трекер вам в помощь

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

• Проверьте, является ли задача частью процесса, который где-то описан

• Используйте и обучайте других тактике пустого инбокса

Что-то забыл? Возможно. Подсказывайте и делитесь своим опытом организации рабочего процесса в комментариях здесь или под постом в моём ТГ-канале: https://t.me/the_young_manager/16

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

Пример страницы бронирования сервиса, которым я пользуюсь сам:

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

Также, приглашаю вас в свой телеграм-канал, где я рассказываю и о других сервисах, кейсах, подходах для менеджмента. А сегодня написал статью про экономику проекта для Пикабу Игры: https://t.me/the_young_manager/72

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

В итоге вместо этой статьи я написал две другие. Первая была посвящена стадиям развития проектов — от идеи до GA. Вторая — о эволюции Agile, объясняющая, откуда он взялся и почему, по всей видимости, он с нами теперь надолго. Эти тексты помогли мне навести порядок в базовых понятиях и выстроить контекст, который, как оказалось, был необходим.

Сейчас, когда эта база сформирована, я могу вернуться к изначальной теме. Но прежде важно объяснить, что именно стало отправной точкой для этой статьи и всей трилогии.

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

И именно поэтому на одном из недавних проектов я неожиданно столкнулся с жёстким сопротивлением. Моё руководство довольно прямо пушило меня назад. Моё желание «есть слона по частям» воспринималось как недостаток серьёзности подхода и вызывало предвзятое отношение.

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

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

В результате вместо движения и проверки гипотез мы снова и снова возвращались к обсуждениям того, как всё должно выглядеть в идеале.

Именно в этот момент вопрос перестал быть про Agile как методологию. Он стал вопросом о границе: где заканчивается стремление всё продумать заранее — и где начинается необходимость двигаться через итерации.

Иллюзия правильного решения

Всегда ли выверенное решение оказывается правильным?

Принимая решения, мы всегда несем за плечами прошлый опыт — местами успешный, местами нет — и он напрямую влияет на то, какие решения мы считаем правильными.

Помимо этого, у нас есть текущее состояние «здесь и сейчас», а также прогноз и видение будущего, которое ещё не наступило и по определению неопределённо.

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

Но у этого подхода есть фундаментальный недостаток: будущее плохо поддаётся предсказанию.

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

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

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

Во многих организациях до сих пор живо солдафонское отношение к планированию: «мужик сказал — мужик сделал». Неважно как, неважно какой ценой — хоть об стену разбейся, но уложись в срок и выполни обещанное. В такой картине мира неопределённости просто не существует.

В результате образ будущего, вокруг которого мы строим «правильное» решение, часто оказывается гораздо менее надёжным, чем нам кажется.

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

Именно здесь возникает иллюзия. Мы начинаем искать не просто жизнеспособный вариант, а единственно верное решение, как будто оно объективно существует и может быть вычислено заранее.

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

Именно здесь и становится видно, в чём состоит иллюзия: правильность не обнаруживается заранее — она формируется в процессе.

Итерации как способ получения знания

Так что же нам делать в такой ситуации?

Пытаться сразу сделать всё хорошо и правильно — или всё-таки идти по итерациям?

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

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

Здесь важно понимать ещё одну вещь: каждое решение — это ставка.

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

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

В этом смысле итерации — это не способ ускориться. Это способ дешевле ошибаться.

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

Заключение

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

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

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

Ценность смещается с уверенных ответов к умению задавать правильные вопросы, с жёстких обещаний — к способности корректировать курс, с демонстрации контроля — к реальной работе с неопределённостью.

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

Читайте мою серию: Усталый Босс

Прошлые статьи:

• Agile без ритуалов — эволюция после бюрократии

• От PoC к масштабу — как превратить пилот в повседневную реальность

• Виды логики и их влияние на мышление

• Эволюция современной службы поддержки

• Когнитивные искажения в ИТ: коротко, по-человечески и с примерами

• Вариант ретроспективы для ИТ команд (postmortem)

• Andon Cord (вторая серия) Как Andon Cord помогает даже там, где никто об этом не думал

• CMM (Capability Maturity Model) Модель зрелости потенциала компании и как по кредитному рейтингу понять с кем имеем дело

• Andon cord

• Люди которые сделали современный менеджмент