Есть тезис, который команды произносят с гордостью: стратегию не пишем, вместо этого быстро проверяем гипотезы. То есть между стратегией и скоростью выбрали скорость, потому что стратегия в этой картине мира что-то долгое и тяжёлое, что мешает бежать. Выбор мнимый. Хорошая стратегия вообще не про то, сколько её строили и сколько нужно строить. Она про то, понимаешь ли ты систему, в которой работаешь: какие в ней причинно-следственные связи, где узкие места, в какой точке небольшое усилие даёт непропорционально большой эффект. Такое понимание можно собрать за неделю, если знаешь, куда смотреть. Можно не собрать и за год. Я уже писал, что гипотеза в научном смысле описывает наблюдаемый феномен и требует экспериментальной проверки, а «сделаем X, получим Y» — это идея. В бэклоге команд, гордящихся скоростью, чаще лежит именно второе. Поэтому если этого самого понимания системы нет, быстрая проверка гипотез превращается в брутфорс идей в надежде, что какая-то стрельнёт. Скорость тут не спасает, ибо пространство вариантов огромное, а выигрышных в нём единицы. И даже когда идея стреляет, на следующем шаге это почти ничего не даёт. Гипотеза в стратегии живёт внутри связанного плана, где несколько линий бьют в один рычаг, поэтому её проверка даёт больше, чем ответ на один вопрос. Подтвердилась или нет, картина системы обновилась целиком. Соседние гипотезы стали сильнее или потеряли смысл. Появились новые данные, которые теперь надо объяснять, и следующий шаг выбирается уже из обновленный картины мира. Идея же ничего не объясняет. Проверил, получил плюс два процента к метрике, порадовался и пошёл к следующему, никак не связанному пункту бэклога. Почему сработало и куда копать дальше, непонятно. Знание не накапливается, и даже десяток удачных идей даёт десять локальных улучшений, которые не складываются в одно большое. Проверять нужно, но без понимания системы проверять нечего, остаётся перебирать идеи и гордо называть это «культурой экспериментов».

Басня: система и ее части Одна автобусная компания решила создать «лучший в мире автобус». Они разобрали лучшие машины конкурентов, взяли самый надежный двигатель от одной марки, лучшую подвеску от другой, идеальную коробку передач от третьей. Когда они попытались собрать всё вместе, детали даже не подошли друг к другу. Система - это не сумма её частей, а продукт их взаимодействия. Пример в IT У вас четыре продукта. Если вы наймете лучшего UX-дизайнера для Продукта А, лучшего data-инженера для Продукта Б и лучшего маркетолога для Продукта В, но заставите их работать изолированно, ваш портфель не станет лидером рынка. Или другой пример: попытка взять «лучшие практики» из разных фреймворков (Scrum, SAFe, Basecamp Shape Up) и слепо объединить их в один процесс без учета культурного контекста компании приведет к коллапсу разработки. Вывод Улучшение отдельных частей системы может ухудшить систему в целом. Фокусируйтесь на интерфейсах взаимодействия между вашими продуктами и командами, а не на локальной эффективности каждого из них. P.S. Кайфую от системной логики. Божечки, почему я так долго откладывал это обучение😍 #продуктовыйпуть

Незабываемый опыт Две недели был в отпуске. Устроил себе полный ретрит на даче: косил газон, втыкал в природу. Фото пруфов прилагаю. Для меня это новый формат, обычно мы семьей куда-то едем, гоняем по всяким экскурсиям и местам, а тут заземление. Первое время внутренний "чёс" по задачкам, потом начало отпускать. Батарейка начала восполнятся, бешеные потоки мыслей в голове затихать. Бывало вожусь на участке, какая-то мыслишка придет, запишу в заметочки и дальше пошел болтаться. Хорошо. Честно признаюсь немного грешил с обучением Добивал блок по системному мышлению. Готовил финальный проект на проверку своему искусственному учителю Gemini: всякие там схемы потоков, петель обратных связей и прочего. Сдал, доволен как слон. Первый опыт с обучением чему-либо с помощью ИИ считаю успешным. Из рекомендаций - при составлении промпта на программу обучения не скупитесь с вводными. Конкретизируйте кто вы, за что отвечаете и зачем вам обучение. Как делал я: - описал свою роль в компании, где работаю и зоны ответственности в стартовом промпте - накинул проблематики - обозначил цели на обучение - попросил задать мне вопросы для более глубокой проработки программы - получил оглавление программы по блокам с теорией и практикой - дальше по каждому блоку отдельно копал инфу все там же в ветке с Gemini, выполнял задания и просил проверить меня - грубо за месяц в спокойном режиме получил базу знаний и собрал несколько живых кейсов, которые буду пробовать уже на бою Есть, конечно, небольшой разлет общей структуры знаний. Изучаешь кусками, а потом в голове собираешь для себя целостную картину. Но с учетом скорости/доступности информации это доп.налог, который того стоит. Хочешь лучше, бери готовые курсы. В общем и целом Прикольно менять форматы отпуска: режим тюлень vs режим олень. Ну и учиться немножко. Возвращаюсь в строй, буду подгружать вас конентом, а то заскучаете совсем💪🔥

Где возникают ошибки Можно предложить следующую модель получения результата: цель → намерение → действие → система → результат Все это находится в окружении, которое влияет на наши действия. 1. Намерение Насколько намерение помогает достичь цели, или насколько у меня правильный образ действия, того, что я хочу сделать. Дон Норман называл эту стадию понимание «концептуальной модели системы». В ряде случаев концептуальная модель простая: если нажать на педаль тормоза, то машина остановиться. Но в ряде случаев концептуальная модель может быть запутанной: чтобы открыть дверь — её надо толкнуть или потянуть на себя? Я уже не говорю про более сложные системы. Насколько система представляет собой ясную схему, что и как надо сделать, чтобы получить желаемый результат? 2. Действие Несовпадение намерения и действия — действительно ошибка человека. Я хотел повернуть налево, но повернул направо. Я хотел нажать на тормоз, а нажал на газ. Насколько система позволяет сделать неправильное действие. Кроме этого важную роль начинают играть другие факторы: усталость исполнителя, отвлекали ли исполнителя во время важных действий и т.д. 3. Система или черный ящик. Сама система может работать с ошибками. Люди могут неправильно понять, то что мы им говорим, информация передается с ошибками. Механизмы могут быть спроектированы с ошибками, софт ошибается. 4. Окружение Это та обстановка, в которой мы действуем. Либо это культура организации, это социоэкономические факторы и т.д. Окружение может влиять на ошибки, которые возникают в процессе. Есть ли давление, чтобы добиться хороших результатов. Насколько система требует не ошибаться или система требует достичь цели любой ценой. Это культура компании, тон сверху, психологическая безопасность и все подобные вещи. Сюда же относятся ошибки, которые можно называть «внешними событиями». Мы ехали по правилам, в нас врезалась машина. Но мы же все сделали правильно. ;) Как видно, отклонения или ошибки могут возникать на любом уровне в этой модели. Но на каждом уровне ошибки возникают по разными причинами и требуют разных методов для предотвращения. #ЧФ #ошибки

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

Неудачи и ошибки Общение определение ошибки — это не достижение целевого состояния, когда результат не равен цели. Давайте разберем на простом примере: мы хотим сварить кофе в кофе-машине. Что может пойти не так? Мы можем не сварить кофе, сварить не то кофе: не того объема, не того вкуса, неправильной температуры, не поставить чашку и т.д. Самый печальный результат будет если мы сломаем кофе-машину. Почему не получилось сварить кофе, как хотелось? Ошибка может быть на разных уровнях: 1. Мы можем не знать, как пользоваться машиной, не понимать как с ней работать. Надписи могут быть запутанными, множество кнопок. 2. Мы можем ошибиться в действиях: случайно нажать не на ту кнопку, поставить чашку не туда и так далее. 3. Сама кофе-машина может не работать или не работать плохо: не залили воду, просто сломана, необходимо засыпать кофе, засорилась и т.д. 4. Окружение может повлиять на задачу: в здании отключилось электричество, перед кофе-машиной стояла большая очередь, ко мне подошел начальник и попросил зайти в кабинет к нему. То есть, ошибки могут быть двух видов: ошибка результата и ошибка различного рода в процессах. Чтобы разграничить их дальше, ошибки результата дальше мы будем назвать неудачей. Не получилось сварить чашку кофе. Чтобы дальше было яснее, нужно разграничить 2 типа ошибок: 1. финальная ошибка, состояние когда результат не равен цели. Этот тип ошибок будем называть неудачи. Не получилось. 2. ошибка или отклонение самом процессе. Вот как раз тот набор отклонений от нормального процесса сварить кофе. Сама по себе ошибка процесса может быть неприятной, но не фатальной. Мы нажали на не ту кнопку, потом нажали на правильную. В машине нет воды — налили ее. Ошибка в процессе не всегда приводит к неудаче — не достижению цели. Да и сама неудача может различаться по своим параметрам: одно дело мы вообще не сварили кофе, другое — когда сварили кофе не того объема. Мы хотели сварить большую чашку, а сварили маленькую. В ряде случаев мы даже не посчитаем это как неудачу. Если брать цель как построение безошибочных систем, то это не значит, мы не должны не допускать ошибок вообще. Нам нужно сделать, чтобы все ошибки не превращались в значительные неудачи. #ЧФ #ошибки

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

Продукт это то, как совершенные части собраны в полезное целое

Системное мышление означает оптимизацию связей-линий между частями-точками. Оптимизация части всегда идёт за счёт целого. Части Системы, оптимизируемые независимо(!) по локальным метрикам, стремятся к своим локальным максимумам, которые являются провалом для целого (прямое следствие декомпозиции цели/фичи/продукта/рынка). Истина 2. Структура, правила и потоки информации обладают большей силой, чем её параметры Точки вмешательства в оптимизацию Системы имеют разную силу. Настройка параметров обладает слабейшей силой, в то время как изменение структуры, правил и информационных потоков большую, а изменение всей парадигмы Системы – максимальную. Эксперименты с версиями фичи это лишь уровень параметров Проектирование базиса механики/архитектуры/сценария, на/по/благодаря которому смогут строить и создавать другие пользователи/команды — правило. Систему можно опознать как ту же самую даже после того, как заменены все её физические носители: люди и код, главное – всё будет работать в новых версиях и компиляциях, если сохранился паттерн связей между ними. Истина 3. Граница Системы очерчена наблюдателем, а не продуктом/рынком Где проводится граница продукта, там же заканчивается его рост и оптимизация, а всё, что снаружи границы, воспринимается как внешняя среда, а не как часть целого. Не бывает объективной границы Системы — есть только граница, которую "выгодно" не видеть. Истина 4. Когда в Систему добавляются что-то "новое" как новый актор, новая ценность переходит к интерфейсу, через который это "новое" взаимодействует с частями Системы. Интерфейс – слой парадигмы. Истина 5. Управлять Системой может только То, что содержит не меньше разнообразия, чем сама Система Регулятор должен обладать вариативностью реакций, равной или превышающей вариативность возмущений, иначе часть возмущений пройдёт через него неотрегулированной (математическое ограничение управления как такового). Истина 6. Иерархия — это замороженная на момент времени искусственная сеть, а формализация и живость Системы это её взаимоисключающие состояния. Система 7. Система не может познать себя изнутри, ибо любое её самоописание есть модель низшего порядка сил. Система существует не ради цели, а ради собственного воспроизводства. Её цель это то, что она рассказывает себе про себя Истина 8. Достигнутая Системой цель — её же новое ограничение. Система, истребившая все ошибки, истребила собственную способность эволюционировать. Значит ли это, что она эволюционировала в Абсолют?

Граф: циклы, наблюдающие за циклами (часть 2) Если присмотреться к тому, как Системы на практике реализуют процессы совершенствования, вырисовывается определенная закономерность: они никогда не сводятся к одному циклу.

Системы — это сети циклов, соединённые с другими циклами

Так, грамотно управляемая компания представляет собой граф циклов: быстрые операционные циклы (ежедневный/еженедельные совещания/анализ метрик) встроены в более медленные управленческие циклы (квартальное планирование), те – в циклы аудита (ежегодные и, что важно, независимые, которые проверяют, соответствуют ли реальности цифры, выдаваемые операционными циклами), а все они — в самый медленный цикл уровеня совета директоров, который задаётся вопросом верны ли сами цели. Технологии ИИ пришли к такой архитектуре аналогичным путём. Грамотный конвейер обучения ИИ – это цикл типа «чемпион = претендент», когда модель-кандидат должна превзойти текущую модель, прежде чем заменить её, а также циклы мониторинга дрейфа, отслеживающие, соответствуют ли поступающие данные тем, на которых модель обучалась и механизмы отката (автоматический возврат к предыдущей версии, если показатели после развертывания выходят за допустимые пределы). Сюда же входят отложенные оценочные выборки, недоступные для цикла обучения, своего рода "слепой" цикл, чья единственная задача выявлять случаи, когда оптимизирующий цикл пытается обхитрить свои собственные тесты. Каждый элемент здесь — это цикл. Надёжность системы кроется в связях между ними: какой цикл передает данные другому, какой наблюдает за каким и какой может наложить вето на действия другого. Проблема Гудхарта решается методом парных показателей: каждому оптимизирующему циклу сопоставляется цикл, отслеживающий контрметрику и выявляющий способы "дешёвого" достижения KPI. Проблема "слепоты" по отношению к вышестоящим уровням решается иерархией, в которой более медленный цикл определяет целевые показатели для быстрого, а пересмотр целей сам по себе является регламентированным циклом, а не случайным решением того, кто установил их изначально. Конфликты разрешаются через явный арбитраж: над конфликтующими циклами стоит ещё один цикл, который принимает решение по поводу возникающих компромиссов. Проблему деградации показателей решают с помощью аудиторских контуров, единственная функция которых – периодически проверять, сохраняют ли данные других контуров связь с реальностью.

Иными словами, меняется структура процессов цикла. Цикл больше не изолирован в Системе

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

От циклов к графам (часть 1) TLDR: цикл = отправная точка, а граф циклов = сеть циклов улучшения, которые наблюдают, подпитывают, ограничивают и корректируют друг друга.

Циклы – это процесс. Граф – их структура

Всё дело в том, что ИИ-циклы дают сбои. Сбои не случайны и есть 4 основных когнитивных ИИ-искажения и сбоя, которые кроются в природе самого ИИ-цикла. Первое искажение ИИ: закон Гудхарта ИИ-цикл видит только свою метрику и именно поэтому он будет искать все способы изменить эту метрику, включая способы, которые противоречат её назначению (привет, хакнутые "кем-то" KPI) ИИ просто не понимает, что в цикле создаётся сбой (часто, это не понимает и человек), когда он манипулирует собственной метрикой. ИИ(-цикл) считает, что делает именно то, для чего был создан на основе числа, которое незаметно оторвалось от реальности, которую оно представляло. Второе искажение ИИ: слепота к восходящему направлению Цикл направляет свою переменную к эталонному значению, но ничто внутри цикла не может проверить правильность самого эталона. Это как термостат в чайнике, который не может задаться вопросом, является ли 100° правильной температурой кипения воды (и должна ли вода вообще кипеть). И ровно также цикл ИИ-отдела продаж не может спросить сам себя, была ли предложенная им цена и оффер разумными для клиента и бизнеса. Цикл оценки просто не может усомниться в том, измеряют ли эталонные показатели что-либо, что чувствуют клиенты. И чем усерднее работает цикл, тем тщательнее достигается неверная цель, возвращая и усиливая ошибку №1. Третье искажение ИИ: внутренний ИИ-конфликт Реальные системы содержат множество циклов, и циклы, построенные независимо друг от друга, начинают бороться между собой. Цикл, оптимизирующий скорость отклика, подрывает цикл, оптимизирующий рассудительность, а цикл найма, отвечающий за рост базы знаний, создает нагрузку на цикл культуры, сохраняющий их качество ☯ Четвертый вид сбоя незаметный: система измерений внутри самого контура деградирует, потому что за наблюдателем никто не наблюдает Все эти показания могут плавать, каналы передачи данных ломаться, смысловое наполнение метрик меняться, цифры в одном отчёте ошибочно подтверждаться ИИ цифрой из другого и контур продолжит работать с данными, которые, по факту, уже никак не связаны с реальностью. Система, функционирующая по такому сценарию начинает напоминать фальшивый спектакль актёров-зрителей в одном лице.

Система на пределе Рядом с моделью сдвига и системной моделью находится принцип нагрузки: «система всегда работает на границе своих возможностей». Обычно у системы есть резервы и ресурсы, которые могут помочь справиться с каким-либо инцидентом, не допустить его перерастание в аварию. Однако, резервы не всегда экономически выгодны. Если станок может работать быстрее, почему бы его не запустить быстрее? Это как старая байка про соломинку: Жил да был жадный торговец. Поехал он на базар купить соломы. Купил – и давай грузить тюки с соломой верблюду на спину! Грузит, грузит, и всё ему мало. «Смотри, – говорят ему, – как бы верблюд твой не умер от такой тяжести, имей совесть!» – «Ничего, – отвечает жадина, – выдержит!» И продолжает грузить. Верблюд уже еле-еле на ногах стоит, а купец только руки потирает, подсчитывает будущие барыши. Наконец, тронулся верблюд с места, а жадина не выдержал: «Ну ещё чуть-чуть!» – и положил на спину верблюду еще одну одну соломинку. Ноги у верблюда подкосились, он упал и умер. Остался купец ни с чем – не на себе же ему солому везти? А с тех пор люди стали говорить: «Одна соломинка может сломать спину верблюду». Естественным пределом нагрузки является поломка системы. Фуры грузят пока они могут ехать или пока не поймают гаишники с превышением веса. Сотрудников оставляют после работы, пока они не начнут жаловаться. Результат работы под нагрузкой похож на теорию сдвига: постепенное ухудшение характеристик системы, сдвиг нормальной работы. Кроме этого, при отсутствии резервов взаимосвязи компонентов в системе становятся более тесными. Если у нас был резерв полуфабрикатов, то выход станка из строя не представлял проблемы. Если же резерва нет, то при поломке станка останавливается вся линия. #ЧФ #модель_сдвига #нагрузка

Сход поезда с рельс, Осака Как работает управленческая дилемма. В 2005 году недалеко от Осаки, Япония, сошёл с рельсов пригородный поезд, врезавшись в многоквартирный дом. В результате аварии погибли по меньшей мере 56 пассажиров и 440 получили ранения. Поезд опаздывал на 90 секунд , и предполагалось, что он ехал вдвое быстрее разрешенной скорости на этом участке линии, когда пять из семи вагонов сошли с рельсов. Следователи сосредоточили внимание на неопытном 23-летнем машинисте, который ранее получал выговор за проезд мимо платформы за 11 месяцев работы и, возможно, превышал скорость, чтобы компенсировать задержку. Премьер-министр Японии призвал чиновников «принять решительные меры для предотвращения будущих аварий». Однако японские поезда известны своей точностью, благодаря чему пассажиры, путешествующие по незнакомым линиям, могут планировать сложные маршруты, будучи уверенными, что не пропустят пересадки из-за задержек. Точность и скорость являются ключевыми факторами успешной работы пригородной системы в густонаселенных городских районах. Возможно, машинист чувствовал, что выражает предпочтения и ожидания всего общества. International Herald Tribune, 26 апреля 2005 г. #ЧФ #управленческая_дилемма #системная_модель