Transcription
Моя задача сегодня будет вам примерно показать, как думают те, кто мыслит системно, как они смотрят на мир.
Хотели как лучше, получилось [музыка] как всегда. На самом деле это лучшее описание ситуации, которая называется: "Мы сделали какое-то изменение, не подумали о положительных свойствах, никакие положительные свойства, ну, как бы ничем не компенсировали. И система сама начинает сопротивляться. Строя больше жилплощади в городе, мы не решаем, а усугубляем проблему жилплощади в городе.
[музыка] Кейс, когда происходит миграция узкого места и думая чуть-чуть наперёд, видя, [музыка] каким образом а все навалились на одно узкое место и его расширят за определённый период времени, это узкое место сдвинется в другую часть и наперёд думать, а какая это будет часть, [музыка] что следующее будет ограничивать выпуск и скорость строительства дата-центров.
Любая система - это комбинация, [музыка] а, усиливающих и балансирующих, а, петель обратной связи. И в определённый момент времени преобладает одна или другая.
[музыка] Сегодня у нас цель м немножко такая. А мы на самом деле мои, наверное, последние, не знаю, 15 выступлений вот в режиме такого открытого вебинара были в той или иной мере про AI. И, э, кажется, что темп изменений, темп того, что нам приходится делать, он очень сильно а взлетел. И иногда кажется, что непонятно вообще, что делать и куда двигаться. А, и в этом плане меня моей опорой с 2000, наверное, где-то шестого, четвёртого или шестого года, вот примерно там, а моей опорой вообще в жизни является системное мышление как способ, э, не только, наверное, мыслить, но и изучать, познавать мир вокруг и системы. Это не единственная точка зрения и взгляд, перспектива на этот, на жизнь вокруг, но мне кажется, что эта перспектива суперэффективная и суперполезная и м помогающая нам двигаться и понимать, что происходит вокруг. Поэтому моя задача сегодня будет вам примерно показать, как думают, э, те, кто мыслит системно, как они смотрят на мир и, э, на какие вещи они обращают внимание. Вот в этом моя цель.
Мы начнём с кейса, который случился у меня очень-очень давно, как раз когда я ещё не совсем знал системное мышление, что было, ээ, скажем так, со мной в 2004 году, когда я писал дипломы, ещё не совсем понимал, что такое системное мышление. В общем, мой диплом был про то, как автоматизировать процесс приёма карточек в а в банке. Ну 2004 год как раз карточки а в России начинают а активно скажем так станови развиваться. И поэтому многие банки, а у меня была такая специальность автоматизированно банковковские системы. То есть мы должны были знать и компьютеры, и банковское дело. Поэтому стажировку мы проходили в банке, и я там наблюдал процесс, который потом в своей бакалаврской работе решил автоматизировать. И, э, этот процесс подаздание кредит на выпуск кредитной карточки. И там очень интересный момент, что в рамках своей дипломной работы я написал софт, который оптимизировал этот процесс, по сути, с помощью сканирования карточки, ну, ну, не карточки, анкеты. Он некоторые аспекты работы, а, этого процесса автоматизирую. Ну, по моим ощущениям, а, 15-20% этой этого процесса мы автоматизировали. Но и в целом, ну, я получил пять за этот за эту бакалаврскую сделал полезную и экономически выгодную инновацию.
Unless только чтобы понять через некоторое время, что на самом деле сам себе, наверное, я бы поставил за это решение двойку. И почему это так? Потому что на самом деле процесс, который, если посмотреть на весь процесс выпуски выпуска карточки, то а обработка а анкеты по приёму, ну, по на выпуск кредитной карточки это была лишь очень маленькая часть всего бизнес-процесса. И несмотря на то, что я как бы оптимизировал какую-то эту часть в, что называется в Grand Sim of Things, то есть на большом уровне, я на самом деле не сделал, ну, сделал очень микроскопическое улучшение по сравнению с тем, что происходило в других частях системы. И из-за этого получается вроде улучшение есть, а вроде бы на 15-20% мы быстрее можем делать какую-то какой-то бизнес-процесс, но в целом бизнес-процесс практически не ускорился. И поэтому я бы себе поставил два, но когда бы понимал, а что такое системное мышление.
И вот этот момент, когда мы видим только часть системы, как я её видел здесь, и в какой-то момент мы расширяем и делаем шаг назад и говорим: "О'кей, э а может быть, я оптимизирую не самое важное, может быть, на самом деле а есть более важные этапы этого процесса, и мы, скажем так, должны их оптимизировать, потому что Там основные основные проблемы и там основные рычаги для изменения системы. Вот эти вопросы я тогда себе не задавал, но после того, как познакомился с системным мышлением, понял, насколько был неправ. И поэтому вот этот взгляд, который ты получаешь, э, и когда говорят, что увидеть лес за деревьями, да, вот любят такое выражение, ну, что такое вообще увидеть лес за деревьями? Видеть лес за деревьями - это когда ты немножко приподнимаешься над той задачей или частью а мира, которую ты привык видеть, и смотришь, что вокруг этого. Потому что обычно системы и процессы, которые существуют вокруг него, сильно ограничивают твои возможности с точки зрения, а изменения системы. То есть, если я смотрю на процесс только с позиции одного из подшагов, который не является а основным ключевым, с точки зрения объёма, а, времени, который тратится на весь процесс, то, оптимизируя вот ту часть, я на самом деле практически не меняю а систему. И главный, наверное, урок того, а времени был - это смотреть, как системы, которые существуют вокруг, а, а это, ну, если, например, люди связаные, то это, а, процессы когнитивные и физиологические, которые есть у людей. или если с этим связаны, например, регулирования, то это процессы регулирования и так далее и тому подобное, которые могут, как бы ты не пытался улучшить свою часть системы, ту часть, за которую ты отвечаешь, они не дадут этой системе стать лучше. Они её как бы, ну, то, что называется constст, да, то есть они её ограничивают, не дают ей, а возможности. Иногда это на самом деле супер хорошо. То есть, а, иногда системы, которые у нас есть, саморегулирующиеся, ну, например, климат, да, или, а, природа, они на самом деле, ну, например, там популяцию одних животных, на самом деле до определённого времени, пока человек сильно не стал в это вмешиваться, а, контролировала популяция других животных, да, то, что, а, по сути, чем больше становить например пищи, ну, например, это птички какие-нибудь, тем больше становилось хищников, которые за этими птичками охотятся. И поэтому получается, что система хищников контролирует и ограничивает систему а птиц, а, птичек. И вот этот взгляд на это, это, наверное, то самое важное, что я вынес.
Когда мы сегодня будем рассматривать сейчас один кейс, то я вам рекомендую, а помнить и вообще обращать внимание, когда мы будем говорить про этот кейс, о том, а насколько вообще м мы понимаем, что ограничивает и что существует не только в той части, которой мы решаем. Ну, допустим, мы бы могли вот сейчас многие компании аа покупают всем курсор илид-код, а, и, по сути, мм, дают возможность оптимизировать часть процесса разработки продукта. И, соответственно, благодаря этому рапортуют, например, Open AI и Anтроopic очень любят в последнее время рапортовать про своих клиентов и про своих разработчиков такую метрику, как количество пулреквестов, да, что в два раза там 70 тире 90% увеличилось количество полреквестов, которые создаются, а, ну, на улучшение продукта. И в целом это действительно так, и это увеличивает производительность разработчиков. Но почему-то, например, исследование МЕТР а показывает, что да, а производительность разработчиков увеличивается, но выхлоп компании не увеличивается. И вот этот нонсенс, который есть, что количество полуреквестов вроде бы там в два раза почти увеличилось, а при этом а выпуск нет, корень его лежит в той же проблеме или в том же аспекте взгляда на систему, про которой вот я делал, а, ну, скажем так, неправильно глядел на этот процесс, когда делал диплом по автоматизации приёма кредитных карточек.
Это первая, а, штука, которую я хотела рассказать. И вторая, потом мы возьмём прямо кейс, и вся наша встреча - это будет рассмотрение одного кейса связанного с системой мышления.
Вторая моя, скажем так, любимая история - это как Ford Foundation пытался реализовать контроль рождаемости в Индии. их задача была, ну, как бы понятно, контроль рождаемости. И они делали ряд активностей, как образовательных, так и раздавали противозачаточные средства, а так и делали дополнительно много разных м вещей, чтобы попробовать вот всё-таки индийские семьи в в деревнях убедить. что им не нужно, а столько детей рожать, что можно это этот процесс контролировать. И, соответственно, а проводили целую программу, в которой были вложены миллионы, а, десятки миллионов долларов. Но, к сожалению, как выяснилось на конференции, на которую они все собрались, а вот как раз представителей, которые работали в Индии, стали рассказывать, насколько не получается решить эту проблему, что вот, что бы они ни делали, уже какой год они пытаются индийские семьи, а индийских матерей убедить не рожать столько детей. И в среднем получается, что а на на мать, на женщину приходилось где-то три, а с половиной ребёнка. Это достаточно много. Всё, что больше два - это рост населения. А, ну, соответственно, с этим ряд проблем. И вот что бы они ни делали, не получалось никак эту цифру снизить. И вот представитель Ford Foundation конференции как раз рассказывал и жаловался, что вот никак не получается. И в этот момент представитель, который работал в Мексике, встаёт и задаёт вопрос: "Э, говорит, почему женщины останавливаются?" Тот такой: "В смысле, ну, почему они останавливаются на 3 с поно? То есть почему они не делают 5, 7, 12? Вот, например, у нас в одной в одном из мексиканских городов у нас была женщина, которая родила 12 детей. Почему они не Почему они останавливаются на 3 с половино? И этот вопрос, почему они делают так, как они делают? Это вопрос, который а системные мыслящие очень любят задавать. И он не знал ответа на этот вопрос. Они стали вернулись в индийство, провели, а, скажем так, реч, исследование, интервьюирование и выяснили, на самом деле, почему женщины делают так. Так получалось, что в среднем а чтобы появился мальчик, может быть 2 с половиной. Я сейчас детали сколько именно не так важны, сколько а суть, что а они это делали до тех пор, пока хотя бы один ребёнок не будет мальчиком. Потому что в их как бы системе размышления, в их традициях, вот как раз Геннадий написал про нацкультуру, но вот это так принято, надо глубже понять, а что мальчик - это кормилец семьи, и пока мальчика не будет, они как бы тем самым не могут себе обеспечить хорошую старость, да? То есть, то есть для них мальчик в семье, сын в семье - это способ, м, обеспечить себе, если хотите, а пенсию, обеспечить себе э уход и, ну, как бы хорошую старость ввиду отсутствия других способов, а, ну, социальной поддержки пожилого населения. И поэтому они делали это и останавливались.
Самый важный поинт, что когда мы изучаем системы, нам интересно не просто сказать, что и хотим на них влиять. Нам интересно не просто сказать, что, ну, а типа они, э, делают неправильно, поэтому мы исправим это поведение. Чтобы понять, как исправить, нам надо сначала понять, почему они делают так или иначе. Потому что в их парадигме, скорее всего, это супер, а рациональное поведение. А пока не будет у меня мальчика, который обеспечит нам старость, я буду продолжать сражаться. И вот этот вот это рациональное поведение другим, ну, в данном случае Ford Foundation, кажущеся ирциональным, оно на самом деле имеет полную смыс. И пока мы не поймём суть его, мы не можем э реализовать никакие изменения. И вот этот принцип, что любая система, у неё есть какие-то свойства, ну, например, поведение какое-то 3 с поно а ребёнка и, наверное, 2 с поно всё-таки. А, и второе - это что это делается из-за нехватки, а, ну, или из-за неуверенности в том, какая будет старость, то в итоге получается, что, а, про Ford Foundation чувакам это кажется проблемой, а на самом деле это м естественное поведение. И если они уберут эту проблему, если они её пофиксят, то они уберут полезные свойства этой проблемы. В данном случае это то, что тем самым а женщины обеспечивают себе старость. И если я хочу в какой-то системе убрать какую-то проблему, я должен подумать, а какие полезные свойства есть у этой проблемы. А потому что, скорее всего, когда я уберу эту проблему, полезные свойства этой проблемы тоже уйдут. И поэтому вам вопрос на миллион долларов. Вот многие, а когда, по крайней мере, я был в университете, а говорили, что вот проблема образования в России, а это то, что м есть взятки. А и давайте, а, собственно, искореним взятки в учебном, ну, там при поступлении и при обучении. Давайте искореним эту проблему, и тогда нам всем станет хорошо. И качество образования повысится, и качество специалистов, которые выходят, повысятся и так далее и тому подобное. И действительно, в этом есть достаточно прямая логика. Вместе с этим с есть полезные свойства у проблемы, э, у проблемы решаемой с то с помощью взятки. И давайте накидайте, вот посмотрите на эту проблему именно как на полезное свойство, что у этой проблемы есть полезные функции. И накидайте в чатик, какие полезные функции у взяток, у взяток в университете, например. Почему это классно? Почему круто, что студент может дать взятку, а-а, чтобы, например, не знаю, получить, э, приемлемую оценку за какой-то предмет, а, преподаватель взять её, да? А, во-первых, Марат прав, что это на самом деле, ну, может быть, не пенсия, но точно, а дополнительный источник дохода, который компенсирует проблему, например, низких зарплат, которые получают преподаватели. Отлично. А, Андрей, полностью согласен. Вообще, а, это развивает навык коммуникации. Нужно уметь договориться, нужно уметь, а объяснить этот процесс, передать, может быть, найти людей, через которых это сделать. Действительно так. И поскольку, ну там, не будем скрывать многих во многих странах мира, не не это не про Россию или СНГ, это про во многих странах мира м понятие взяток как элемента, скажем так, социального а масла, да, который сглаживает углы бюрократии и так далее. Это достаточно распространённый способ это делать. В некоторых странах просто это законодательно можно в виде лобби, а в некоторых странах это запрещается, но делается, скажем так, из-под полы. А, да, смягчает зарпла, то есть компенсирует доход, мотивирует студента заработать. Да, вот таким очень тоже интересный поинт говорит, что смотрите, если а я как бы могу какие-то предметы, которые, ну, мне не хочется, мне не нужны, закрывать таким образом просто потому, что программа не успевает за потребностями спецов, да? То есть я там условно, я сейчас скажу, учу ассемблер, а я на самом деле бухгалтер, я условно а всё говорю. то если я могу через взятку закрыть какой-то зачёт, который мне не нужен, по моему мнению, то есть я принимаю это решение, то тем самым я как бы могу, во-первых, ну м лучше, скажем так, получать то образование или брать те предметы, которые мне интересны, и решить проблему вот жёсткой программы обучения, которая есть там в ряде вузов. Но в это же время, чтобы это делать, мне нужно где-то для этого брать деньги. И поэтому я иду работать. А когда я иду работать, я начинаю получать опыт, который в итоге помогает мне трудоустроиться. Потому что, ну, я думаю, многие подтвердят, что чем раньше ты начинаешь, пока ты в вузе работать, тем выше вероятность, что, а, ну, у тебя будут соответствующие скилы к моменту закончишь вуз, и, соответственно, ты сможешь а получить хорошие хорошую позицию и иметь главное скилы, соответствующие этой позиции, да, высвобождает марта, полностью поддерживаю, что это высвобождает время для других занятий. А, то есть можно сфокусироваться на чём-то. Вот в некоторых образовательных системах они более, а, гибкие. Я сам могу выбирать, какие предметы брать. И единственное, я там должен выполнять определённый минимум в зависимости от программы, которую я делаю. Но в целом подход такой, что я могу приоритизировать. И, конечно, здесь взятка, у неё есть вот такое неожиданное, а, полезное свойство. А, да, собственно, что там спецы и так далее, гибкость системы, да, можно делать ошибки, можно делать более важные дела и так далее. А, доп деньги в экономику. В общем, в целом, да, вы совершенно верно это говорите.
Мой основной поинт, заметьте, вот какой. Что если я не понял, а этот положительный эффект? Если я о нём не подумал, если я его не исследовал, то что может быть? Может быть то, что я пофиксил эту проблему, но вместе с фиксом этой проблемы все эти положительные свойства тоже ушли. И я должен подготовиться к тому, если я настроен решить эту проблему, то я должен готовиться к тому, чтобы как-то реализовать компенсацию этих положительных свойств. Вот а Сергей задаёт вопрос: "О'кей, а если у проблемы есть положительный эффект, как взветить, что перевешивают?" Во-первых, про это вообще там системное мышление. Но сейчас мы даже Сергей чуть раньше остаёмся. Мы говорим: "Давайте сначала узнаем, какие положительные эффекты, и зададим себе вопрос: "А мы обеспечили мероприятия, которые компенсируют исчезновение этого положительного эффекта?" Вот какой вопрос я ещё задаю. Я не Я пока ещё даже не задаю вопрос, какой что перевешивает. Задаю вопрос. Если я хочу, чтобы перевесил, а, ну, решение проблемы, то я должен посмотреть, как я обеспечу. Ну, например, а, допустим, допустим, э, ставка, а, преподавателя регулируется государством. Допустим, это так, допустим, и изменение этой ставки - это, допустим, среднее время, средняя задержка на этот процесс. Допустим, 3 года. Я должен учитывать, что только через 3 года, если я начну сейчас жёстко рубить, я получу, а результат, я получу ту компенсацию тех положительных эффектов, которые изменится, чтобы начать проводить эти изменения. Вот я про что, да? И, безусловно, это правильный вопрос, что перевешивать, но до него вопрос: а какие вообще положительные эффекты существуют? Ведь почему происходит обычно такое, что мы изменили систему? Вот как Черномырдинга, ну, ему любят напоминать это эту циту, что хотели как лучше, получилось как всегда. На самом деле это лучшее описание ситуации, которая называется мы сделали какое-то изменение, не подумали о положительных свойствах. никакие положительные свойства, ну, как бы ничем не компенсировали. И система сама начинает сопротивляться. Она начинает всё равно, даже если это м как бы законодательством у как бы, ну, скажем так, не не допускается. Ну, например, аборты в Румынии, да, там очень есть такой известный кейс, когда, а, собственно, ну, изменение политики, связанное с абортами при Чеушеску, привело к ряду, а, негативных эффектов, которые были в в связи с этим, потому что, да, закон приняли, и действительно в моменте сильно упала рождаемость и ой повысилась рождаемость, то, что и хотела государства. Но при этом через некоторое время она начала падать из-за того, что не решив вот те положительные эффекты, компенсиро не компенсировав те положительные эффекты, а мы в принципе ну женщины стали прибегать к неофициальному аборту, что приводило к тому, что они или умирали, а или просто не могли иметь детей а вообще. Плюс повысилась нагрузка на, а, на детдомы, потому что у тех, у кого а рождались, а их просто подкладывали в детдом и так далее и тому подобное. Поэтому вот эти два поинта я предлагаю запомнить.
А и мы возьмём а кейс. То есть первый поинт, что когда я оптимизирую систему, а я должен посмотреть, какие а надсистемы а ограничивают поведение этой системы. И может быть, что бы я ни пытался сделать из-за того, что надсистемы существуют и они ограничивают мои тре мои усилия будут тщетны. И второе, что если мы смотрим на систему, в которой есть люди, и у людей есть, во-первых, вот это свойство, что инсентивы дравят поведение людей, и у них есть своё понимание, что такое хорошо и что такое плохо, своё индивидуальное понимание. И они ведут себя то, что называется, ограничено рационально, то есть в своём мире они делают всё правильно, но мы, не изучив вот этот мир, не поняв его, а мы начинаем менять эту систему через обычно через силу. А мы приводим к тому, что все наши усилия тщетны, и мы не учитываем, какие позитивные свойства есть у этого процесса, а и не подготавливаемся к тому, чтобы эти позитивные свойства компенсировать, чтобы повысить вероятность, что наши изменения а случится.
О'кей. Собственно, после вот этого вот этой вводной, давайте сначала в системном мышлении все, э, скажем так, стараются любую ситуацию, которую они увидели в одном месте, переложить на ситуацию в другом месте и попробовать увидеть параллели между разными ситуациями, потому что на абстрактном уровне это одно и то же. И вот давайте, может быть, сейчас в течение там 3-5 минут подумайте об этих двух аспектах. А рациональное поведение, проблема - это у проблемы есть положительные свойства или надсистема ограничивает, а производительность или поведение подсистемы и поэтому а не позволяет ей например выходить за определённые рамки. И если мы её не понимаем, то мы наши усилия по её изменению тчетные. Приведите мне примеры в чатике. Вот можете взять то, что все считают проблемой и говорят, что нам надо исправить эту проблему. А в итоге получается, что у этой проблемы есть куча положительных свойств, которые вы видите. Если мы устраним проблему, то нам надо подумать, а как компенсировать эти свойства.
Поворот рек в СССР. Да. Ну, я в родился в Топменистане. Кто там помнит уроки географии, а там как раз, э, ну, канал вот имени Ленина, который каракумский канал, а это по сути канал, который ну там не совсем поворот, просто мне этот кейс близок, но я знаю, конечно, что были и другие кейсы, когда, собственно, ну, пустили э канал от ключевых рек, которые питали Оральское море. И в итоге мы, во-первых, получили, что мы лишились де-факто Оральского моря. А с другой стороны, это привело ещё к очень большим, а изменениям в почве и в то, что происходило там в а тех землях, через которые пустили этот эрокумский канал.
Проституция, да, на самом деле у проституции есть полезные свойства, и там, где она запрещена, скажем так, нужно, во-первых, она в той или иной мере, скорее всего, где-то а проявляется и существует. А с другой стороны, э, ну, если мы запрещаем, то нам надо придумать, каким образом мы это компенсируем.
Вот наркотики на самом деле очень интересный кейс, потому что до сих пор, а в мире системного мышления идёт этот спор. В общем, определённая часть учёных считает, что наркотики должны быть э доступны для покупки, ну, с учётом, понятно, правил, ну, там, по возрасту и так далее. А по пред, вот я живу в Сиетле, как бы тут вы знаете, что можно, в принципе, купить не сильные наркотики легко в специальных магазинах. И, э, есть одна позиция, суть её примерно такая, что, а, если мы запрещаем, то мы снижаем аэп наркотиков. Из-за этого мы обеспечиваем, ну, по сути, дефицит. А из-за этого дефицита превышается цена. Из-за повышенной цены в это входят, скажем так, преступные структуры. А потому что риск, ну, как бы оправдывает, скажем так, высокая цена оправдывает риск, с которым им надо сталкиваться и брать на себя. И поэтому некоторые считают, что надо отпустить и как бы дать возможность покупать наркотики. А, ну другие считают, что из-за определённых свойств вот наркотиков, как то сильное привыкание и негативное влияние на здоровье человека, мы не должны это делать. И это действительно спор. Вот, кстати, это примерно спор про то, что Сергей выше спросил. компенсацию позитивных слшнегативных свойств. И действительно, там я скорее в, скажем так, ближе к запрету этого из-за как раз определённых свойств или обеспечению контроля а за а этой продажей, ну, адекватного контроля. Ну, а в целом мы видим, что как только это разрешается, то происходит, в зависимости от культуры страны происходят совершенно разные свойства. Там толерант, вот нулевая толерантность к насилию между детьми. В общем, да, отлично легализация, да, допуск частных инвесторов к торговле. Отлично про это целый фильм. свободное оружие. Да, вот на самом деле, а, живя в США и видя, что это один из ключевых пунктов разлада между, мм, ну, по сути, демократической Республиканской партией, действительно это наблюдаешь воочию, а, да, цензура и так далее, в общем, а, поэтому в следующий раз, когда вы захотите какую-то или сейчас, может быть, вы пытаетесь изменить какую-то систему, ну, допустим, а навязать всем AI, допустим, своей организации, чтобы повысить производительность, то подумайте, э, ну, то есть какую функцию вы полезную тем самым а убираете и как вы будете её компенсировать. Про одну из этих функций мы сейчас поговорим.
В общем, как будет строиться наше размышление в рамках этого кейса. Я хочу вам показать три ключевые концепции, которые, ну, фундаментальны, когда ты смотришь на что-то с позиции системного мышления. И вот как раз AI
Здесь я использую, чтобы вам, а, лучше донести, а, это. И посмотрим, насколько у меня получится.
У нас есть команда разработки продукта. Собственно, в ней есть, по сути, три больших этапа. Это разработка. Сюда входит дизайн, написание кода, код review. А дальше тестирование. А это делают тестеры. И дальше, соответственно, фича выходит в продакш.
И сейчас состояние у нас такое, что у нас есть 10 разработчиков, а, и они делают каждый по одной фиче в неделю. А, то есть 10 фич в неделю. А у нас есть два тестировщика. Они успевает тестировать пять, а, фичей, то есть в среднем получается 2 с половиной фичи на одну эту. И дальше, соответственно, шипят в продакш.
Собственно, CEO недоволен тем, что что-то у нас скорость не очень. И вам говорит: "Давайте, в общем, улучшим наш как бы а велосити, давайте шипить больше". Вот я вот читаю там, что а страйк с тысячами, десятками тысяч миньонов, что-то там кучу пиар-реквестов делает, что два разработчика из Open AI написали миллион строк и так далее. И я говорю: "Так, короче, мой сеть, давай, мы тоже так хотим. Вот у тебя есть бюджет а нами людей. Я хочу, чтобы мы больше, а, выдавали результаты".
И по сути у вас есть три, а, решения. Это, а, нанять больше разработчиков, больше разработчиков, больше фичей. Второе, нанять больше QA, а, чтобы не упало качество, и разбить. То есть, например, взять двух разработчиков и трёх QA. Давайте разберём.
Третье решение. Мы, а, делаем, а, нанимаем двух, э, разработчиков и трёх QA. А почему мы это а делаем? А, ну, идея заключается в том, что если мы посмотрим на наш как бы процесс, то видно, что QA являются узким местом. А сейчас система не сбалансирована, и по сути производительность QA определяет производительность или выпуск всей системы. В данном случае пять фичей. Если мы хотим расширить э выпуск системы, то мы должны это узкое место QA расшить. И поэтому в целом вы абсолютно правильно сказали, что это или второе, или третье решение, потому что и там, и там у нас есть, ну, в решении заложено увеличение количества тестировщиков.
А если посмотреть на решение три, то оно увеличивает наш выхлопно до 12 фич в недель. То есть мы почти, а, в 2 с половиной раза увеличили выпуск системы, а, наняв в сбалансированном виде а разработчиков EQA. Если посмотреть на два других решения, если бы мы взяли, а, 5Q инженеров, то, да, мы бы решили проблему узкого места, а, с QA, и, если честно, этих QA стало бы даже с излишком. И в итоге получается, что производительность QA стала 17. Но поскольку, а, разработчиков осталось столько же, и они шипят по 10 фечей в неделю, то узкое место сдвинулось в ту сторону, и теперь узким местом стали разработчики ANQA. И, соответственно, поэтому решив узкое место, а мы увеличили производительность, но есть ещё возможность эту производительность увеличить дальше, если бы мы сделали с балансинг.
Ну и, конечно, а никто из вас не выбрал первый. И совершенно правильно сделали, потому что, а, при том, что вся система ограничивается выхлопом QA на тот момент, на который я задал вопрос, не, если вы принимаете решение, не связанное с узким местом, то все ваши, а, действия тщетны.
И, соответственно, Сергей хорошо говорит про что K генерирует больше работы для разработки. Мы сейчас чуть попозже й Сергей это посмотрим про вот эти обратные эффекты. Это просто будет другой концепт из трёх, который я хочу рассказать. Но в целом, забегая вперёд, конечно, Сергей говорит правильно. И Максим даёт интересный, а, поинт, что, в принципе, как бы, если бы мы автоматизировали QA, ведь что такое автоматизация, например, в том числе с помощью AI, это попытка на ну дать больше людей. То есть мы, а, автоматизируя что-то, мы увеличиваем пропускную способность. И если мы автоматизируем, например, с браузер Automation lмкой или просто а плейрайтом без лмки какие-то аспекты, если это frontend heavy а продукт, то действительно мы при те при том же количестве QA можем увеличить пропускную способность нашей системы.
Но ключевой здесь поинт, что глобально наша задача понять один простой факт, что выпуск системы - это он ограничивается выпуском самого узкого места. И у любой системы это узкое место есть. Его правда надо найти. И есть, ну, целая теория, теория ограничений, в которой рассказывают, каким образом искать узкие места, особенно в процессах, которые, а, ну, скажем так, физического свойства. Ну, там, например, книга Цель, которую я очень рекомендую, она, по сути, показывает, как, идя по производству, да, по заводу, можно увидеть, где, скорее всего у вас узкое а место. Но в целом вывод тот же. И самое главное следствие из этого, что любое изменение не в узком месте - это иллюзия изменения, что мы не обеспечиваем тем самым а повышение производительности а или выпуска системы.
А что происходит вокруг нас? Которая очень хорошо поддаётся объяснению с точки зрения вот позиции, что а у каждой системы есть узкое место и изменения вне этого узкого места не меняют систему. А помните, когда мы смотрели последствия решений разных и смотрели последствия решения просто, а, добавить 5 QA, что узкое место обычно, а, как только мы расшили его одно узкое место, оно мигрирует, оно как бы перебегает в другую часть системы и и та часть системы начинает уже ограничивать всю систему. Может быть, кто-то видит параллели, которые происходят, и может привести такие кейсы.
Пробка на выезде из ВКАТ сместилась после раше. Да, отличный кейс, Сергей. Вообще, а про пробки и про то, что а сузив ой расшив одно узкое место, оно просто сдвигается. И ваш вопрос просто: до какого момента вам о'кей? То есть, если вы сдвинете дальше того, куда вам ехать, то всё классно. Но в целом пробки - это вообще классический пример. Спасибо за такой а ну живой пример. И действительно, а этот, кстати, основатель системной динамики, это там способ исследовать системы и, а, дизайнить их. Он, на самом деле, занимался задачкой, связанной с городами. Вот кто знает игру Sims, а в основе этой игры системно-динамическая модель, то есть модель, а, созданная людьми вот с системным, а, взглядом на происходящее. И вот он долгое время доказывал одну простую мысль про города. У него есть целая книжка про это. А мысль звучит примерно так: строя больше жилплощади в городе, мы не решаем, а усугубляем проблему жилплощади в городе. И если кто-то объяснит мне, почему он прав, а в чате будет очень здорово.
А, ну да, Максим, про ширину как бы залива Хармузского, да, ну, постараемся чуть-чуть, да, этот сейчас без этой части политики. Хотя на самом деле вот когда ты учишься системного мышления, мы будем с вами вот а я в середине апреля курс стартую на эту тему. мы будем, ну, я буду просить приносить articles, да, то есть новости из газет, из, а, с телевидения и так далее, где, по сути демонстрируется непонимание, а, вот, вот этих аспектов работы систем. И поэтому там прямо постоянно кейсы из политики, потому что очень часто политики путают некоторые аспекты и связанные с системами и, соответственно, не учитывают. Ну или осознанно не учитывают, или не осознанно, это уж я а не знаю.
А, да, Аким предлагает объяснение вот этой, почему прав Форестер, когда говорит, что больше строительство, больше, ну, жил пплощади усугубляет, потому что при поскольку все стремятся в город, снижение зарплат ой, фу, снижение цен на недвижимость в городе приводит к увеличению желания, ну, доступности этой жилплощади. Ещё больше людей въезжает в город, ещё больше усугубляет проблему, ещё больше приходится решать проблему а жилплощади. А в некоторых городах, таких как Сан-Франциско или вот Сиетл, а на самом деле это приводит ещё к ряду негативных последствий, как то многос людей на улице, которые, а, ну, там создают определённую обратную связь. Мы сейчас дойдём до этого, а, на, а, стоимость коммерческой или жилой площади в городе. Да, чем шире хайвей, тем больше авто. А, да, Дмитрий как раз объясняет через спрос. Льготная ипотека. Совершенно верно, Василий. Да.
То есть Давайте я просто дам два кейса, которые я хотел, ну, подумал, вдруг вы а как раз вспомните. Во-первых, вот жилой фонд, да, Виталий, отличен. Там ещё, поскольку государство хочет презервировать, да, сохранять вот этот старинный, а, жилой фонд, который есть во многих таких ну старинных городах Европы, это ещё больше усложняет, и при этом нужны локанты, чтобы повысить экономику. Да, совершенно верно.
А, но вот два кейса, которые я имел в виду. А, во-первых, сейчас, когда, а, мы прямо видим, а, как с мигрирует узкое место из одной части системы, которая обеспечивает развитие AI в другую часть. Вот я знаю на, ну, я видел, что на звонке есть мой товарищ. А мне очень нравится, как он, мы недавно ехали в куда в машине, и он задаёт мне такой вопрос ну там без деталей, потому что это может быть коммерческая информация. Но вопрос был примерно такой: аа знаю ли я что-то или кто-то эксперт, который знает что-то про определённую часть, а, цепочки поставок в дата-центры, в которых ну крутятся все наши AI-модельки, потому что он видит, как сдвигается узкое место, а, связанное с по строительством дата-центров от одного, а, компонента к другому и как расширив, например, проблему, допустим, чипов, сдвинулась в память, как расширив проблему памяти, сейчас сдвинулось электриков не хватает в Техасе и платят там зарплаты, сопоставимые с AI-ресерчерами в Сан-Франциско и так далее и тому подобное. Это как раз вот кейс, когда происходит миграция узкого места. И думая чуть-чуть наперёд, видя, каким образом а все навалились на одно узкое место и его расширят за определённый период времени, это узкое место сдвинется в другую часть и наперёд думать, а какая это будет часть, что следующее будет ограничивать выпуск и скорость строительства дата-центров. Поэтому вот, если вы, а, будет время, послушайте, как Маск и почему, не как, наверное, а почему Маск говорит про и не только он, про дата-центры в космосе. То есть как он объясняет э с позиции теории ограничений на самом деле о том, почему ему проще выйти в космос и там пытаться делать дата-центры, чем, это делать на Земле. И потом где-то на прошлой неделе, послушайте тоже у Дваркеша у него встреча с забыл потель, забыл как его сейчас полное имя. А они, ээ, обсуждают там как раз тоже узкие места в дата-центрах, которые, а, появляются, и, соответственно, как это влияет на всю систему и как Open AI, который заключал много сделок в режиме "Ты живёшь только один раз в день", а, определяет стоимость, себестоимость обслуживания моделей и почему более осторожное поведение антропика на самом деле играет им сейчас не на руку. В общем, очень рекомендую а этот посмотреть.
Первый концепт, который я имел в виду - это что мы ищем э ограничения в системе. А мы пытаемся в первую очередь расшивать узкое место. Если мы не расшиваем его, мы не увеличиваем пропускную способность. Основная сложность заключается в том, что люди видят только то, что видят. Ну, грубо говоря, а что, э, люди м считают, что узкое место там, где они видят это узкое место. М в той части системы, с которой они связаны, с той частью системы, с которой они взаимодействуют постоянно. Поэтому они видят узкое место на своём а уровне. Но зачастую, как я сказал, надсистемы или другие части процесса гораздо сильнее ограничивают наше, а, наше поведение. И поэтому наша задача определить границы вот этой системы и посмотреть, где узкое место в них.
Концепт номер два. О'кей. А, ну мы с вами поняли, что, а, типа у нас этот проблема в QA, поэтому как бы у нас есть, скажем так, это ограничивает нашу проблему. Допустим, мы как бы наняли людей и сбалансировали систему таким образом, что они там выпускают 10 фичей, всё, а, хорошо. А давайте посмотрим, что происходит дальше, и как раз поговорим про некоторые, а, дополнительные свойства и обратные связи, которые получаются. То есть мы тот же кейс смотрим на него дальше. Итак, а мы устранили систему ограничения, сбалансировали, шипим чётко 10 фич в неделю. А все довольны? А, но а давайте добавим одну, скажем так, реальность, которая вот, кстати, знаете, когда в системном мышлении обсуждают какую-то систему, говорят, что любая модель, а я вам сейчас показываю модель - это некоторое упрощение системы упрощение реальности. Ну, как карта, например, упрощает, она не показывает, например, определённая карта не показывает определённые свойства. Ну, например, не топографическая карта, простая карта, она не показывает, например, какие-то топографические свойства, потому что не нужно, э, для той задачи, для которой мы эту карту рисовали. И поэтому, а, когда система мыслящие смотрят на модели, они любят задавать вопрос: "О'кей, где упрощение реальности в этой модели?" И давайте, а, поговорим о том, а где мы её упростили? И, собственно, а, потихонечку будем добавлять этой реальности, чтобы модель приближалась к реальности.
А поэтому, что мы добавляем, это что, ну, каждую фичу, которую мы разработали, надо поддерживать. Очевидно, что каждую фичу, которую мы выкатываем, а мы обеспечиваем то, что а люди начинают ею пользоваться. Они про эту, э, фичу начинают писать бакфиксы, э, бакрепорты. Эти QA тоже, кстати, а нужно и эту фичу поддерживать. Нужно поддерживать код, который поддерживает много фичей. И давайте представим, что каждая новая фича нам добавляет 1 час в неделю на её поддержку. Собственно, у нас есть 400 часов работы девелоперов, которые шипят по 10 фичей в неделю. Вопрос, собственно, такой: как вы думаете, а какой output сейчас? Outputт 10 фичей в неделю. А что будет с аутпутом, а системы, если вот мы добавим такую а вводную о системе, что есть обратная связь, заключающаяся в том, что нам надо поддерживать эту систему, а значит, прилетают баг-репорты, а и разработчикам надо фиксить эти баги, которые никак не связаны с новыми фичами. Чем больше фичей мы шипим, тем больше фичей у нас в продукте. Чем больше фичей у нас в продукте, тем больше мы получаем бакрепортов про него. Значит, чем больше бакрепортов, тем больше надо тратить времени разработчика на а поддержку системы. И а соответственно, чем больше а мы это тратим на поддержку, тем меньше у нас остаётся времени на то, чтобы шипить новые фичи.
И, а, действительно, что если мы посмотрим во времени, то происходит следующее. А, во-первых, мы видим, как начинает расти, а, расти наши затраты на а maintenance, а, и из-за этого падать аупут системы с точки зрения, а, ну, с точки зрения, а, аутпута системы. И на где-то седьмую восьмую седьмую неделю у нас уже на 20 на 15% упало а производитель. При этом мы ничего не делали. То есть как бы можно сказать, что разработчики м ленивые. А, и вот они, короче, меньше стали шипить, и поэтому CO или CO говорит: "Так, давай, короче, мы им купим клод-код, давай наймём ещё разработчиков, давай мы, э, там, не знаю, как бы, что ещё сделаем, а будем прививать культуру работы до поздней ночи и так далее и тому подобное. Соответственно, этот самое интересное, что оно продолжает вести себя таким образом. И как вы, собственно, это сказали, что примерно к к тридцатой неделе, где-то двадцать седьмой-двать восьмой, у нас выпуск, то есть количество новых вещей, которые мы делаем, становится меньше, чем мы занимаемся а поддержкой этой. И Катя правильно добавляет, что это мы ещё не учли, что фичи между собой могут, а, коррелировать. И условно вот эта константа 1 час в фечу на неделю, она на самом деле тоже может быть не не константой, а иметь ээ на самом деле свойство такой экспоненциального роста. И действительно этот Сергей прав, что возможно не все фичи, не каждая феча требует мейнтеннеса вот навеки тоже. Правда из этого, на самом деле, Сергей говорит один важный, а, важное изменение, которое каждый продукт-менеджер должен делать в каждом продукте. Выпиливать нахрен фичи. Да, совершенно верно. То есть, э, он должен сансетить фич, которые не заходят. И это часть его работы. Помним, да, что сейчас вот есть целый лагерь продуктов, которые говорят: "Да, AI кучу позволяет нам кучу нового шипити". Иногда, если честно, то, что клодко выпускает, мы как бы даже не успеваем понимать. Вот из последнего, когда они добавили возможность а внутрь скила описать, чтобы я мог контекст этого как бы скила запускать в отдельном субагенте. Вот, если честно, это такой эдж-кейс, по крайней мере, в моей парадигме, что я сломался, я такой: "Блин, нахера?" И вот это, что мы умеем, мы теперь можем пилить фичие пирожки, имея, если мы не будем выпиливать их, мы увидим вот эту а динамику, которую мы сейчас видим. Ну а Максим, можем поговорить для кого эта фича. Мой, э, поинт остаётся, а, тот же, что если, а, нам нужно поддерживать эту фичу, то во времени нам, разработчикам, пусть даже K AI пишет код, но нам нужно, а, ревьюить этот код, потому что они все пишут, что люди ревьют код, то мы себе снижаем, ну, отнимаем у себя будущее время, если хоти хотите, и поэтому нам нужно их резать.
И действительно, а как бы вы абсолютно правы, но что сделает некоторый руководитель из-за, допустим, нежелания нежелание как бы выпиливать фичи, когда он видит что CEO видит, что падает выпуск, хотя вроде недавно наняли EQA и разработчиков и говорили, что и действительно опилили по 10, а не пять, а сейчас стало меньше даже пяти. Мы там, понятно, добавили новые обратную связь, но как бы м такой: "Так, надо ещё добавить, давайте ещё возьмём девелопера, пусть пусть шипят ещё больше". И действительно, а как бы подумаете, а какое свойство будет, какие следствия будут у вот этой это что дайте нам больше бюджета, потому что у нас в тот раз же помогло, вот это важно, да, что в тот раз мы, когда добавили пять разработчиков новых, мы же увеличили производительность в два раза, и это решение сработало. Поэтому я сейчас говорю: "Давайте ещё сделаем". И у меня уже есть звёздочки на погонах. Я в прошлый раз сказал, что, вернее, доказал дело. И поэтому из-за нашего свойства, из-за нашего как бы преференсов в сторону, а, в сторону предпочтения решений, которые работали в прошлом, мы начинаем, собственно, а, гравитировать к решениям, которые работали в прошлом. И, как правильно, а, вы написали, система деградирует ещё а больше.
А давайте посмотрим с точки зрения того, как описывает это там любой системномыслящий, как это а происходит, как эта обратная связь а работает. Что чем больше разработчиков, тем больше у нас аупут фичей. Чем больше аупут фичей, а тем больше фичей мы выпускаем в итоге. Чем больше фичей мы в итоге выпускаем, тем больше нагрузка на maintenance. Чем больше нагрузка на maintenance, тем меньше возможность разработчикам делать новые фечи. И, соответственно, из-за этой нехватки мы начинаем на добавлять ещё разработчиков и тем самым усугубляем ситуацию. Вот когда такие системы, а, ну, петли обратной связи, то в системном мышлении рисуют их при помощи вот таких диаграмм. Они называются козл а loop диаграммы CLD. И вот эти, а, значения, плюсики и минусики - это как раз они показывают направление эффекта. То есть, если плюсик, то изменение причины приводит к изменению следствия в ту же сторону. То есть, что чем больше девелоперов, тем больше фичей. Поэтому плюсик. Если минус, то изменение в одну сторону приводит к обратному эффекту. То есть увеличе вот здесь минус мы читаем так. Увеличение, а затрат на maintenance, а снижает, поэтому минус, а, а, доступную для разработки новых фичей Capacity у разработчиков. Самое важное, что обратная верно, тоже. Поэтому в системном мышлении не рекомендуется писать, что увеличивается, уменьшается. Рекомендуется использовать нейтральные термины output, фичи, maintenance, capacity. head count, а направление влияния уже описывают собственно вот этим этот. И я сейчас не буду глубоко уходить, но бывает по сути два типа а вот таких петель обратной связи. Петли, которые усиливают динамику системы и балансируют её. И суть в том, что люб любая система - это комбинация, а усиливающих и балансирующих петелей обратной связи. И в определённый момент времени преобладает одна или другая. Если преобладает усиливающая петля обратной связи, то система обычно растёт или изменяется. Если а преобладает балансирующая система, то, э, петля обратной связи, то система стабилизируется. И вот когда мы говорили про, Сергей задал вопрос по поводу, а как понять, что как компенсируются одни верс другие эффекты, позитивные свойства, негативные? Вот как раз задача системного мышления сначала описать эти вот, то есть вообще подумать про эти свойства, описать их на качественном уровне в виде вот таких а диаграмм обратной связи, а потом уже эти диаграммы переводятся в компьютерны, ну, оценивается, то есть каждая из стрелочек оценивается и каким-то коэффициентом и моделируется, а, в специальном софте. кто был на моём выступлении много-много лет назад на Mobile Grows, я показывал, как вот эти какие ключевые петли обратной связи есть в разработке мобильных, а, и продвижении мобильных, а, в росте мобильных приложений. Вот там, а, та же логика. И я, если помните, на последнем слайде показал, что, в принципе, каждый коэффициент мы можем оценить, если настроить аналитику, и тем самым управлять этими, а, петлями, понимать, что будет происходить.
О'кей. Собственно, концепт номер два, который я хотел рассказать, что и помните цитату CEO Shopify Тоби Лутки, которую я привёл, когда анонсировал, а, когда писал пост, что, э, многие люди считают, что мир линей, на самом деле мир циркулярен, то есть в нём есть вот такие лупы. И как раз это второй концепт ключевой, который мы должны понять. И эти лупы нам надо вскрывать, нам надо их учитывать, нам надо понимать, какой из них преобладает, при каких условиях, и тем самым мы можем как бы уже а вносить. Там есть примерно 12 рычагов изменения систем, которые, а, можно применить в разные части системы, и они дают разные эффекты, но при этом требуют разных ресурсов. Очевидно.
Ну и третий концепт, который я хотел рассказать, а мы давайте разберём таким образом. О'кей. У нас из-за вот этой обратной связи с мейнтеннесом у нас падает выпуск, и это неприемлемо для CEO. Поэтому, а, как бы есть два две стратегии, как я могу с этим работать. Первою, когда я вижу, что вот у меня есть цель 10, например, а нам поставили цель 10 фичей шипить в в неделю, допустим, я вижу, что текущая цель, текущее значение этой метрики четыре, то есть -6. Я понимаю, что, ну, один разработчик шипит по одной фиче в неделю, поэтому, чтобы шипить, вернуться к шипыванию десяти фичей в неделю, мне надо плюсшесть разработчиков. И я их сразу нанимаю. То есть я, а, даю объявление или прошу, а, HR- отдел нанять мне ещё шесть разработчиков. И каждый раз, когда я вижу вот эту разницу, а, между желаемой значением, то есть целью, и реальным значением, вот этот гэп, я делаю корректирующее действие, а, вида нанять больше, а, разработчиков.
А второй вариант - это если я буду а не так быстро, не каждую неделю сравнивать, а, значение желаемое, реальное, а чуть помедленней. Каждый квартал я буду оценивать и нанимать людей. Какую выбираете стратегию, чтобы, а, с минимальными затратами, а, внимательно я задаю вопрос, с минимальными затратами, а, увеличить пропускную способность системы.
А, Константин, чем чаще, тем лучше. Mak sense, потому что мы быстрее реагируем на систему. И самое главное, что наш CEO видит, что мы реагируем. То есть он видит, что мы отрабатываем задачку, мы как бы реализуем задачи, которые перед нами ставят начальство. Минимальные затраты. Давайте. А на самом деле и Permons и Per year не отличается. Slow при слишком частке частой проверке можем оптимизировать локально. Slow 1Д разработчики для подже новых фич высвоботь имещикся. Это Влад как раз этот Марианна дау. Окей. А чем сахариув на make sense? А первый раз мощно выстрелить, дальше замедлится. О'кей, хорошо. А без выпиления фичей оба варианта потона, да? Олег на самом деле как бы этот, но выбрать надо Олег из этих двух как бы этот, то есть в целом как бы, как мы поняли из предыдущего, а, ну надо как бы, ну, всё равно система будет деградировать, если мы не будем, а, м, скажем так, удалять фичи. Но здесь, а, я пойду просто в интересах времени.
А дальше давайте посмотрим на две стратегии. Единственное, что а я как бы вам, ну, не дал на вход, а специально, это просто так, скажем так, педагогический приём. А, собственно, что когда мы нанимаем разработчиков, у нас есть от момента, когда мы приняли решение нанять, к моменту, когда они вышли на, а, полную пропускную способность, проходит время. Ну, нужно, во-первых, их найти, а, во-вторых, добучить, а, этих джинов, например, как предлагает Максим, добучить, чтобы они могли фиксить баги, которые, а, это и, а, собственно, а, действительно этот процесс онбординга может занимать там 6-9 месяцев.
В некоторых кейсах. И что тогда получается? Получается, что если а 6-9 месяцев ходит на онбординг, то до этого момента добавление новых разработчиков на самом деле а больше всего отнимает времени у а синиразработчиков, которые помогают джунам входить в проект. И это забирает у них время на, а, шиппинг новых фичей и добавление людей в разработку на самом деле ещё делает ещё медленней а системой.
Поэтому, а вы видите, что сначала как бы такое ощущение, что, ну, как бы сначала, во-первых, а, ну, продолжает падать, потому что пока не прошла вот это, а, время, которое нужно, чтобы ввести людей в проект, чтобы эти джуны начали давать отдачу. Потом прыжок, ну, если, допустим, мы каждую неделю нанимаем. Потом опять деградация, потом опять прыжок, потому что мы посмотрели вот в этой точке, что-то у нас как бы не улучшается ситуация. Вроде наняли джинов, вон они там что-то там отвлекают наших синеров, а выхлоп-то не меняется, он даже ещё больше падает, в том числе из-за maтенс Брdдена, о который мы поговорили. И в итоге мы делаем ещё решение, а ещё нанять, потому что думаем, что недостаточно наняли, ведь раньше в первой кейсе сразу был результат.
И, конечно же, ну, здесь как бы основная мысль заключается в том, что между, э, нашим действием в виде нанятия разработка и эффектом выход разработчика на полноценную а производительность проходит, есть временная задержка. И эта временная задержка может быть достаточно большой. И если не учитывать эту временную задержку, то можно переусердствовать с наймом. Так же, как мы иногда, заходя в душ, а в новом месте каком-то, открываем кран, вроде бы тёпленькая, заходим, а, намываемся, вдруг она становится слишком горячей, мы начинаем быстренько крутить, а, холодную воду, становится нормальная, через минутку становится слишком холодная. И не дай бог кто-то спустил воду в унитазе в этот момент или начал мыть посуду в друго на кухне. Это ещё больше увеличивает задержку между я повернул вентиль крана и температура воды изменилась и тем самым ведёт к тому, что мы переусердствуем, а или недоусердствуем с изменениями. И а про это как раз этот феномен.
И третий концепт, который я хотел как бы донести, заключается в том, что а ээ не всегда быстрая реакция - это хорошо. Вообще почему-то принято думать, что быстрая реакция - это хорошо. Во-первых, потому что мы эволюционно, мы как люди примировали тех, кто быстро думает, быстро решает, что надо сматываться к чёрту от хищника эволюционно. А вот та часть нашей, ну, то, что называется мозгом рептилий, а она эволюционно, ну, как бы улучшалась благодаря тому, что мы быстро связывали причину иследствия и ожидали эффект. И благодаря этому мы выжили. Поэтому у нас есть большое preference, да, большой баяс в сторону того, чтобы думать, что между действием и результатом проходит мало времени, особенно если у нас нету опыта с этой системой, особенно если мы её не изучили. И в итоге, если а есть такая задержка, мы можем переусервать результатом, но это свойство наш нас как людей, и нам очень сложно соотносить. Но есть вторая штука, что вокруг все начинают говорить, что ты ничего не делаешь или ты реагируешь недостаточно много. А и Миша хороший поинт пишет, что быстрая реакция хорошо. Плохо, когда размер реакции несопоставим. Да, но а Миш, тут есть ещё другой поинт, что если я не мой ключевой поинт здесь такой, если я не учитываю время, которое проходит, то есть задержка времени, которая проходит между я повернул руль и машина изменила своё направление, в в случае машины и вообще в случае 99% а вещей, ситуаций, с которыми мы сталкиваемся каждый день, всё у нас быстро. Я нажал кнопку, появилось, а-э, м, сообщение в чатике и так далее и тому подобное. Но вот именно поэтому у нас баяс в сторону ошибки, что мы как бы м недооцениваем вот эту реакцию, вот эту временную задержку между действием и результатом. И из-за недооценки оцениваем ситуацию неполно. И ещё раз реагируем.
Вот Максим правильно говорит, что когда происходи Вот если посмотреть на этот график, то посмотрите, он как бы асциллирует. он как бы вообще, если а какая-то система асцилирует, то есть она себя ведёт вот такими как бы прыжками, да, а здесь она асцилирует в одну сторону, на самом деле как бы есть вот, допустим, классический, так называемый, а из в логистике а эффект кнута, а и он как раз э вот классическая вообще а этот отсляция И даже там амплитуда колебаний увеличивается, а, по мере движения по цепочке поставок. Мы будем играть вот в пивную игру на курсе. Вот там это как раз про это. И суть в том, что вот эти, сорри, вот эти осцилляции, они, если вы видите, что какой-то процесс асцилирует, то, скорее всего, там есть временные задержки, которые не учитываются в принятии решений по измененисти. То есть, если вы видите, что тото что-то вот так прыгает, скорее всего, там есть какие-то, а, временные задержки, которые не учитываете, и люди overreact или under react из-за вот этого неучёта. Я им просто так помните, в начале сказал, что подумайте, как бы как переносить одну одну идею в другую, потому что в система мышления думает, что все ситуации похожи.
Я даже скажу больше. Вы уже заметили в моём разговоре, что я примерно сказал следующее. Если я смотрю поведение системы во времени, то я могу предположить, какие обратные связи и задержки в ней есть или преобладают. Вот, вдумайтесь, я могу посмотреть на поведение системы во времени и спланировать, вернее, предсказать структуру или правильнее не предсказать, а поставить гипотезу. Потому что обычно просто ставят гипотезу, говорят: "Так, она асциллирует, скорее всего, здесь временные издержки". Ищем временные издержки, задаём вопрос, а вот, собственно, а как бы какие временные издержки есть при принятии решений? Потому что ведь временная издержка при принятии решений, она может быть из-за проблем или особенностей учёта. Вот, знаете, например, что, а, куча скандалов в США в прошлые несколько лет, а, про то, когда репортится инфляция и, собственно, насколько она правильная правильно репортится или нет. У каждой метрики, собираемой на большом объёме, а сущностей, а домохозяйства, бизнесы и так далее, у неё есть естественная временная задержка на измерение. Это чуть-чуть похоже на парадокс наблюдения, что чем ближе к наблюдению, тем больше мы влияем на наблюдение, да? А, но это парадокс. Короче, есть термин этому, но и иде и иде, да, и конто. Идея как бы именно в этом, что у любого измерения есть задержка и неточность. И наше принятие решений, а на основе этой метрики на самом деле ачень, э важно понимать, какие временные издержки и потери есть у этой метрики. А вот, например, а, да, Гезмберг, конечно. А, спасибо, Юс. Что нам нужно? исследовать информационные потоки, а обычные информационные потоки самые невидимые потоки. То есть легко видеть, что на производстве много незаконченной продукции у станка, который является узким местом. Но очень сложно увидеть, что человек, который всю жизнь принимал решение на основе количества кэша в кассе, а ценовые решения, я сейчас расскажу этот кейс, что он на самом деле не учёл изменения в окружающей среде и принимает решение по неправильной метрике. А, соответственно, вот нам надо исследовать вот эти информационные потоки и ментальные модели, на основе которых люди принимают решение.
Вот то самое про индийские индийских женщин, которые хотят сына. А вот этот кейс, давайте я вам расскажу. И с одной стороны, он меня поразил в тот момент, насколько а ну люди, которые понимают системы, их видят по-другому. То есть это а был такой, а туроператор и CEO этого туроператора, а, ну, как бы мы вот те, кто вырос, получил образование, а, м, ну, вот там я пошёл в университет в 2000 году, нас часто называют технократы, что вот мы, а, типа берём науку, приводим её в в бизнес, в общество, в то, как управлять а системами, организациями. И вот это поколение называли технократами. А вот поколение предпринимателей там, которые сделали бизнес в девяностых, оно немножко по-другому с этим работает. И вот этот владелец туроператора говорит: "Барам, типа, вот всё классно, вы там супернаучно всё это делаете, это действительно работает". Но говорит: "Хочешь, я тебе скажу, как я понимаю, что кто-то на рынке демпингует?" Я такой: "Да, давайте". Он говорит: "Я в 12:00 дня захожу в нашу кассу, а у них офис, и прямо на входе в офис у них касса. Туроператор, когда не были распространены карточки, а там как бы деньги турагенты приносили. Вот турагент берёт деньги у а этого туриста, приносит туроператору в кассу, сдаёт и получает ваучеры. А, ну там на, а, на отель, билеты и так далее. И он говорит: "Я захожу в этот в 1200 и если количество денег примерно вот, а, ниже вот такого уровня, значит, кто-то количество кэша в кассе, ниже такое, значит, кто-то на рынке демпингует. Я такой, я просто завиз." То есть, понимаете, да, он нашёл индикатор, который, поскольку он, этот турооператор делает, не знаю, на тот момент, наверное, лет 10 минимум, он как бы чувствует эту систему и видит, как внешние действия на рынке отображаются а на его как бы поведении, на поведении вот этого индикатора. И он может судить об этом. Это его ментальная модель, что если коша в кассе меньше X, значит кто-то домпигует, а значит мы тоже будем домговать. Ценовая война.
Но в чём проблема этой ментальной модели? В чём вот почему я заговорил про то, что нам надо изучить, каким образом метрика собирается, какие информационные потоки создают эту метрику, на основе которой люди, а это CEO, принимают решение? Почему это важно, да? Что казуальные связи у нас в голове, их сложно поэтому отслеживать, сложно вытащить систему принятия решения. Но я вот вытащил эту систему, а, принятия решения. Вдруг деньги будут вечером. А почему они могут быть вечером? То есть, а, почему может как бы так случиться, что деньги будут вечером? Или вообще, почему может произойти, я что-то рассказывал вам в этом, а, семинаре уже, э, что может изменить, э, реальность, а, его ментальная модель, оставшаяся в прошлой реальности, она это не учитывает. И поэтому он принимает неверное решение и заводит весь рынок. Там было всего три примерно туроператора, которые определяли определённое направление в Ну, во-первых, конкурентов больше стало о'кей. А не всех. Он не по приговорам идёт, а исходя из прошлого это да, но у него прибор просто это кэш, да. Что смотрите, если основная основной поток денег уходит в безнал, ну, например, в кредитные карточки, а у них, кстати, есть определённые временные задержки, чтобы а вы знали, с точки зрения выплаты, то он, если при ну принимает решение на основе вот litally, я захожу в кассу и смотрю, сколько КШ в 12:00 дня. Он, не учитывая, что структура потока платежей изменилась, может принимать решение, не основывающееся на изменённой структуре системы, изменённой структуре, а, потоков денег. Понимаете, да? Какая какая, э, ну, какой риск здесь лежит. И это вы скажете: "Не, ну он же не дурак", да? Вот в этой суперузкой ситуации я вам её рассказал, и в моём рассказе как бы всё прозрачно и понятно. Но подумайте о тех руководителей и о тех возможных изменениях структурных, которые они не учитывают. И те приборы, по которым они летят, они просто не отражают изменения структурного. И поэтому решения, которые принимаются, совершенно неадекватны внешней среде, но они принимаются, потому что внутри ментальная модель, как Максим написал, она настолько сильная, вот эти казуальные связи, к которым я привык, что очень сложно от них отказываться.
Вот, допустим, часто у меня с аналитиками, а, был такой, когда у меня была целая команда в предыдущем бизнесе, а там был такой разговор, что, а, они мне, например, приносят какой-то стейтмент, и поскольку я знаю бизнес с нуля, у меня появилась а вот такая ментальная модель бизнеса. А потому что я каждый день смотрю все метрики там и так далее и тому подобное. И они мне приносят какой-то стейтмент, который совершенно не бьётся с моей ментальной моделей. И я им сразу всегда говорил, а если есть там мои бывшие коллеги, могут подтвердить, я говорил такую фразу: "Смотри, или здесь ошибка, или здесь суперважный инсайт, который поменяет полностью мою систему мышления, мою модель бизнеса, которая у меня есть. И мы начинаем сначала с ними проверять, что все выводы, все выкладки, все показатели были посчитаны верно. И когда мы убедимся в этом, вот тогда я такой: "Блин, вот это круто". То есть я смог понять, я смог ощутить, где моя ментальная модель не соответствует внешней среде, и я её должен адаптировать. Это очень сложно вообще. любой человек, э, вот психологи психо, э, психологически он противится изменениям своих, ну, ментальных моделей. Он ну это даже иногда физически может проявляться. Люди повышают голос, а люди там, ну, много физических движений начинает выходить, когда происходит вот этот когнитивный диссонанс. Да, спасибо, кстати. То есть вы должны его прямо искать. Вот. То есть я получаю удовольствие в хорошем смысле, когда испытываю вот такой когнитивный диссонанс, потому что я чувствую, как моя ментальная модель адаптируется к изменённой реальности или к тому, что я недооценивал. Потому что когда компания растёт, а я остался с ментальной моделью маленькой компании, я не учитываю какие-то аспекты этой, а, изменённой реальности, этой новой структуры и пытаюсь как бы старыми решениями решать проблему, а, новые проблемы. И это приводит к, аа, к вот таким, как бы хотели как лучше. Получилось, как всегда.
Третий концепт - это что? Мы в систем в системномыслящий, мы ищем задержки, мы пытаемся понять, где они есть, и согласовать свои решения с задержками, которые есть в системе. Вот, например, очень часто политиков ругают за какие-то ситуации или наоборот за какие-то ситуации, которые случились благодаря или благодаря в кавычках или на самом деле а действия, сделаны предыдущими политиками. То есть, смотрите, а условно кто-то сделал изменение, которое занимает больше, чем срок, а, ну, эффект от которого проявляется, а, дольше, чем срок пребывания этого политика или этого руководителя в этой организации, государстве. В итоге к моменту, когда эффекты доходят, приходит другой этот. Если это были правильные решения, то они в в шоколаде. Если неправильные, то они Да. Максим, да, Обама очень классный пример. Вот в Германии я считаю, что это вот Коль, Шрёдер и Меркель. очень интересная череда решений, которые они принимали, которые по которым мы сейчас видим эффекты, которые происходят в Европе. Ну и не сейчас, а вот каждый из них наблюдал а эффекты решений предыдущих. И это происходит с этим ничего на самом деле не сделать. Мой основной поинт, что когда мы судим системы, когда мы принимаем решения, нам надо эти задержки времени учитывать.
Собственно, резюмируя, что есть три, есть больше концепции, сегодня я хотел вам сказать всего три. Это что у каждой системы есть ограничения. И если мы хотим увеличить выпуск системы, мы должны должны повлиять именно на ограничение. Б, что у системы есть обратные связи. Иногда может так получиться, что изменение системы -э приведёт к усугублению. Изменение системы в нужном направлении, намём больше разработчиков приводит к усугублению или к более быстрой деградации а системы. То, что мы видели, а, с maintenance. И третье, что, а, иногда не учитывая, не сопоставляя ожидания эффекта с, э, реальным временем, которое нужно, чтобы действие пропагировалось по всей системе и осуществило какое-то на неё влияние, если мы этого не учитываем, то мы можем overreact или underreact, что приводит к осцилляциям. А, ну вот я видел здесь пере пере переписку, что действительно осциляции иногда это хорошо, но иногда это очень плохо. Вот, например, в бизнесе зачастую осциляции - это очень плохо, но если вы посмотрите, то наша вся экономика постоянно асциллирует, но по возрастающей аэ траектории. То есть она асциллирует. Посмотрите на как бы а там на экономику во времени. Она асциллирует, но по возрастающей, то есть она всё равно растёт. И поэтому многие говорят, что проще всего вкладывать в индекс. Индекс всё равно растёт. Но в моменте действительно вот в этих там даже средний, э, средний период осцилляции, по-моему, если меня память не изменяет, около 12, что ли, лет можно посмотреть экономические исследования. А Шумпетер, например, или Кондратьев, цикл Кондратьева, кто исследовали вот эти свойства, осциллирующие свойства экономик на высоком уровне. А вот нам надо их учитывать.
Собственно, это мы пропустим. У нас просто не не осталось времени. Это вы сможете дома сделать. Я поширю а презентацию, конечно же. А, но как бы, если хотите, подумайте. А, финтех бизнес или не финтех, неважно, а, делает и чатбота в custom. Классно. Снижается, а, время обработки тикета с 4 часов до 45 минут, а он берёт на себя 80% самых простых. Ну, как обычно, с чатботом. Чатбот обычно 80-90% простых повторяющихся тикетов берёт на себя и высвобождает вре Может кто-то даже скажет, что за финтех. Вот. А высвобождает время, снижает, вернее, время на резолюцию. Быстрые тикеты быстро решаются. Люди работают только со сложными тикетами, но через некоторое время, а, удовлетворённость тем, как закрываются тикеты, а, стремительно начинает падать. Средняя оценка кастомерсервиса а падает вниз, хотя тип запросов не изменился. А и а время время по-прежнему осталось на 45 минутах. То есть попрежнему всё хорошо, быстро закрываем, 80% закрывает AI. Если кто-то применя все вот эти линзы три, которые я сказал, может даже догадается, что за финтех. Поверьте, а про него были, э, газетные заголовки, и я писал в канале: "А, здорово". пишите в комменты в а канал.
А вот то, что я бы хотел, чтобы вы подумали про свою компанию, про свой бизнес, про свою жизнь, про а общество в и экономику, в которой вы живёте, это я хотел бы, чтобы вы подумали вот на вот этом об этом эффекте, когда деньги, время, внимание, которое тратится на поддержку системы настолько вырастает, что увеличи превосходит время на, собственно, развитие этой системы. И вот этот момент, когда оранжевая становится больше, чем, ну, циановая, синенькая, я у меня плохо с а цветами, это очень важный момент, который происходит во многих системах. И попробуйте дома, а подумать, а где где в моей компании оранжевая съедает циановая, и из-за этого а система деградирует каждый день? И может быть, что я мог бы про это а сделать. Это всё, что я хотел сегодня рассказать. Надеюсь, что было там достаточно, чтобы понять, что такое, по крайней мере, почувствовать, что такое системное мышление. И три ключевых концепта, которые я хотел сегодня рассказать. Конечно, там система мышления - это гораздо больше и welcome на курс, если вам интересно. А, но в целом, вот если вы хотите в понедельник, да, а уже получить какой-то результат от того, что вы сегодня потратили 2 часа со мной, это подумаете, где в моей компании, где в бизнесе, где в обществе, в котором я нахожусь, оранжевая естновая. Сегодня будете тусить с семьёй, с друзьями. Задайте вопрос: "А где наша, где у нас оранжевое естное? Где поддержка системы съедает нашу возможность улучшаться и развиваться? Подумайте про себя самого, про себя вот как человека, как индивидуума и личность, где может быть это происходит. И я не говорю, что это плохо. Я говорю, что про это надо задуматься и этому надо отдавать отчёт. м отчёт как бы самому себе, что это происходит, и искать это и не обижаться на себя, на систему вокруг.
Что потом делать с этой информацией? Дмитрий, правильный вопрос. Про это курс. Если бы я был селс-человеком, я бы сказал. Но а одну книгу, которую я бы а рекомендовал, и можете прочитать, собственно, этот раздел. А вот если взять оглавление, а то видите вот этот цель, фу, часть три, creating change, вот это как раз про что с этим делать. И вот, собственно, в третьей части, какая там страничка? 145 где-то. А тут, наверное, есть этот. Давайте я покажу. Если кому-то проще на русском, то на русский перевели это как азбука системного мышления. Я участвовал в, а, редакторс, ну, не редактор, а когда человек, который понимает, э, ну, как бы эту область, э, просматривает перевод, я при, скажем так, руку свою приложил к тому процесу, поэтому, э, в целом перевод good, а, но вот вот эта третья часть, здесь вы увидите, что Данеella - это лучшие, А, преподаватель системного мышления. Второй, наверное, - это Бари Ричмунд. К сожалению, оба уже ушли из жизни. Вот она выводит 12 рычагов систем. И вы можете, она начинает с самых простых рычагов, вот с двенадцатого. Константы и параметры, а, субсидии, налоги, стандарты. И двигается к самому сложному. Самый сложный, вы там увидите - это изменить парадигму. изменить а устойчивую ментальную модель всего общества по поводу а какого-то вопроса, в общем, копать туда. Там вы сможете ответить на вопрос, что это Да, Максим, правильно.
Вот, собственно, почему я назвал курс Системное мышление плюс AI. Я хочу многие штуки, которые, а, вот как вытаскивать ээ козол диаграммы, как их быстро, удобно рисовать, как визуализировать. Видите, я построил симуляцию целую благодаря кодингту и так далее. Вот это вот всё, а на а надо дистиллировать в скилы, в агенты, клодкод, AI, вот это вот всё. И действительно в рамках этого курса мы это сделаем. Но важно скилами сначала понять ручками, да, вот как я люблю говорить, сначала мышцу на вот по Энгельбарту, да? А сначала мышцу надо накачать, а потом можно пользоваться вспомогательными инструментами. Нельзя, чтобы у вас атрофировались мышцы, которые, а, понимают, э, движение системы.
Ответ на задачу Cтоom. Да, Марта. А, в общем, во-первых, вы правильно сказали про то, что, а-э, expectations, не только вы, ещё несколько там, а, два ещё обратных обратные связи. Первое - это то, что, э, люди выгорают. В общем, смотрите, а простые задачки, а, которые прилетали в саппорт, они для людей были таким как бы передышкой. То есть, они как бы благодаря, ну, там просто, знаете, там нужно одну не нужно включать мозг, можно одну штучку просто сет какой-то поменять где-то в админке и всё хорошо. Или там скопировать из нож бейза и отправить. И это давало им когнитивную перерыв, когнитивную разгрузку. И это снижалоут, снижало выгорание. Когда же мы убрали все вот эти мелкие задачи, на которых люди органично отдыхали, перезагружались, делали такой когнитивный флаш, да, мы засунули их в супер, э, стресс с точки зрения когнитивной нагрузки в стрессовые условия, и тем самым они начинают выгорать, ходят из компании или их увольняют, потому что а там, ну, говорят: "А у нас 80% закрывает робот, можно уволить 4.000 человек". И, э, соответственно, а уходят более опытные, а менее опытные остаются, потому что AI вроде за них всё делает. И тем самым, а, возникает вот ещё эта обратная связь, то есть, а, невозможность передыхать приводит к брнауту, приводит к уходу, приводит к потере институционального знания, приводит к это к а снижению качества обработки вот тех сложных именно кейсов. То есть простые ика отлично закрывает. Но вот именно сложные кейсы они начинают ломаться.
Супер. Спасибо, коллеги, и хороших вам а выходных. Надеюсь, кого-то из вас увижу, а в середине апреля на курсе. Пока. M.