Speaker A
Всем привет. Это подкаст Бреслав и Ложечкин. Меня зовут Александр Ложечкин. А я Андрей Бреслав. Всем привет.
Бреслав и Ложечкин обсуждают, почему всё так медленно: скорость принятия решений в бизнесе, регулирование, опыт релизов Kotlin и роль метрик в организациях.
Key Takeaways
- Скорость в организации — это цикл от понимания проблемы до проверки решения, а не только скорость разработки
- Регулирование имеет разную ценность: часть бесполезна, часть защищает от реальных злоупотреблений
- Жёсткие сроки релиза полезны, когда важна стабильность и обратная совместимость, но могут затянуться
- Попытки ускорить команду через микроменеджмент обычно снижают эффективность
- Оптимизировать нужно весь процесс целиком, а не отдельные этапы
What the video covers
- Ведущие обсуждают скорость не как физическую, а как скорость организаций: от осознания проблемы до принятия решения, реализации и обратной связи
- Скорость важна для бизнеса, но её можно получить ценой нарушения законов и здравого смысла
- Регулирование (например, часть GDPR, комплаенс) тормозит процессы, но часть правил защищает от коррупции, особенно в военных закупках
- Андрей Бреслав рассказывает о задержке первого релиза Kotlin: с 2010 по 2016 год, в основном из-за стремления обеспечить обратную совместимость
- Сравнение с Swift, который ломал совместимость при каждом релизе, и с консервативной Java
- Переход Kotlin на регулярные релизы раз в полгода — поступок, при котором в релиз попадает то, что успели доделать
- Желание ускорить команду часто ведёт к микроменеджменту, который контрпродуктивен
- Обсуждается модель принятия решений Amazon: сначала активный спор, затем полная поддержка решения
- Компании фрагментированы, разные уровни могут стремиться к разной скорости
- Рекомендуется книга Голдратта «Цель»: важна скорость всего процесса, а не отдельных его частей
Full Transcript — Download SRT & Markdown
Speaker A
Сегодня моя очередь быть псевдоведущим. Вопрос, который я хочу адресовать всем нам - это почему, блин, всё так медленно? И я хочу сегодня поговорить про скорость. И про скорость я хочу поговорить в первую очередь, конечно же, не как быстро мы едем ездим по
Speaker A
автобанам. До сих пор вспоминаю свою жизнь в Германии с безлимитными автобанами, а про скорость организации, про то, как мы понимаем, что у нас есть проблема, про то, как мы придумываем варианты решений быстрые или медленно, про то, как мы принимаем решение, про
Speaker A
то, как мы это решение реализуем и про то, как мы замыкаем цикл обратной связи, понимая, а ту ли проблему мы решали или не ту.
Speaker A
И первый вопрос, который я хочу Андрею адресовать - это доволен ли ты скоростью того, как всё происходит вокруг тебя?
Speaker A
Ну, тут разные процессы есть. Знаешь, одно дело скорость, с которой развивается и другое дело, там, скорость, с которой решаются международные проблемы, и третье дело, с какой скоростью у меня получается делать мои продукты. И вот немножко, значит, разные скорости.
Speaker A
Хотя всеми этими вещами я одновременно недоволен. Но некоторыми ты недоволен, потому что они слишком быстрые, а вторыми потому что они слишком медленные.
Speaker A
Да, наверное. хорошая затравка для нашего выпуска, потому что принято считать, что, типа, чем быстрее, тем лучше. И вот я помню, когда в Амазоне работал, Джефф Безос и Энди Джасси постоянно повторяли А вот вопрос, действительно ли нужно всегда стремиться к скорости? Вот это
Speaker A
тоже, я надеюсь, мы сегодня сможем пообсуждать. Ага. Ну, кстати, для бизнеса, я думаю, что значительно менее. Ну, там можно придумать, наверное, какие-то безумные ситуации, когда это снаружи всё настолько, значит, вибрирует, а у тебя настолько много денег, что тебе лучше,
Speaker A
значит, затормозить, пока оно там перестанет вибрировать, значит, туда-сюда качаться, и просто будет дешевле не дёргаться. Но это какая-то очень редкая ситуация. Я думаю, что для бизнеса, для извлечения прибыли, скорее всего, как правило, нужна скорость. Там другое дело, что понятно, скорость можно
Speaker A
получать, пожертвовав каким-нибудь там здравым смыслом. Э, очень легко, кстати, ускориться, если начать нарушать все на свете законы.
Speaker A
Потому что понятно, что очень много регулирования про то, чтобы предотвращать всякие плохие вещи, и оно тебя тормозит. Вон там у нас есть куча какого-нибудь комплаенса, там ещё какой-нибудь фигни. Это всё тормозит кошмарно. Ну и часть из этого абсолютно
Speaker A
бесполезна, как там большой кусок GDPR - нафиг никому не нужен, просто тратит деньги всех и бесит ещё людей. Те вот эти вот куки-попапы несчастные. Там есть другая часть GDPR, которая вполне разумная, но это как бы отдельный разговор.
Speaker A
Вот. Ну а какие-то полезные, то есть, ну там, чтобы очень много денег не воровали, коррупции было поменьше там, ещё чего-нибудь, каких-нибудь страшных теневых экономик не развивалось слишком много, там тоже есть какие-то полезные регулирования для этого. Вон это недавно
Speaker A
смотрел про всякую коррупцию при этих закупках во время войн всяких разных. Ну и там как бы вот в Америке, когда была, кажется, война Севера и Юга, и, значит, там украли какое-то невероятное количество всего, просто какой-то невероятный был разгул коррупции. И они
Speaker A
после этого напринимали прямо законов гигантское число, которые там, ну, в каких-то изменённых версиях по сей день существуют механизмы которые предотвращают всякую разную коррупцию при военных закупках. Всё тормозит из-за этого невероятно.
Speaker A
Думаю, что что-нибудь ещё удорожается. Тот материал, который я смотрел, он был не про удорожание, а именно про время.
Speaker A
Угу. Вот. Но но как бы ну вот потому что иначе всё украдут просто. А, ну, кстати, да, хорошая затравка для темы. Ну давай, может быть, начнём с какого-нибудь жизненного примера. У тебя есть пример какой-нибудь из жизни, где всё происходило медленнее, чем ты хотел
Speaker A
бы? Ну у меня есть два примера про одно и то же. Значит, есть есть такая, значит, притча в языцах среди всех, наверное, пользователей Котлина, которая звучит просто - Котлин тормозит.
Speaker A
Вот. Значит, на самом деле это всего было три инкарнации. Ну сейчас там чуть часть из этого уже починена.
Speaker A
Тормозит компилятор, тормозит IDE, э вот но одна, которой все уже забыли, это же тормозила как бы команда с релизом.
Speaker A
Э вот. Значит, первый релиз Котлин, но он вышел в 2016 году, а начали мы работать в 2010. Ну мы там в 2010 начали работать под конец года, в 2016 выпустили в начале, так что это там чуть-чуть больше пяти лет. Но мы могли
Speaker A
ещё притормозить, если бы там не не предприняли некоторые внутренние усилия, чтобы наконец всё-таки выпустить релиз.
Speaker A
Но это был в значительной мере мой менеджерский продолб. Я просто, ну, был молодой, неопытный, не очень понимал там, типа, что важно, что не важно, и главное, как сделать, чтобы всё-таки оно завелость.
Speaker A
Потому что уже там, я не знаю, в каком-нибудь там четырнадцатом-пятнадцатом году у нас уже была довольно большая команда, мы уже довольно много сделали. Ну там чего-то, значит, мы там что-то переделывали, что-то было много не доделано, надо было доделать, и так оно и тянулось, значит,
Speaker A
бесконечно. Ко мне в какой-то момент пришли старшие товарищи и сказали со с чувак, надо как-то это зарелизиться уже. И у нас год ушёл после этого на то, чтобы зарелизиться. Ну потому что, опять же, у нас были там какие-то
Speaker A
внутренние стандарты, в первую очередь того, чтобы обратную совместимость предоставить. То есть мы, в принципе, ну, понятно, всегда можно, типа, собрать бинарник и его отдать. Вопрос просто, что будет.
Speaker A
И мы считали, что если мы отдадим бинарник, который потом будет ломать обратную совместимость всё время, то это будет ужасно. Ну, в частности, потому что мы смотрели, как в скальском комьюнити все очень страдали от таких вещей. Вот, но параллельно с нами Swift
Speaker A
выпускался и ломал совместимость каждую версию. Вот, а мы были такие супер аккуратные. Ну мы были немножко в другом мире, мы, во-первых, не Apple, как бы мы не можем никому диктовать. Во-вторых, у нас рядом была, значит, суперконсервативная Java, в которой всё
Speaker A
было всегда совместимо. И мы такие боялись, э вот, а с другой стороны, ну вот, в Скале, действительно, люди очень плакали. Так что непонятно. И, в общем, ну, вот это тот последний год, который мы потратили, мы потратили именно на то,
Speaker A
чтобы обратная совместимость была, типа, Ну там всё равно были какие-то мелкие потом изменения, но это всё уже ерунда по сравнению с тем, сколько мы вычистили за последний год. Последний год - это пример какого-то, ну, относительно разумного компромисса между скоростью и
Speaker A
тормозами, потому что, ну, можно было сказать, да, типа, и побежали, но мы решили как бы из разумных соображений, как не просто потому, что мы не могли быстрее, а потому, что мы считали, что это важно, всё-таки доделать вот до
Speaker A
этого состояние. И вот, ну и потом надо сказать, с релизами Котлина тоже были всякие задержки, я не помню там, который из них застревал довольно сильно, один-два что ли, какой-то из них прямо долго-долго не ходил, там откладывался, что-то не сходилось, тра-та-та, но мы в
Speaker A
итоге перешли под конец моего уже руководства перешли на релизы просто регулярные. Просто стали релизы раз в полгода.
Speaker A
Ну то есть что за релиз делали, что успели написать, то и зарелизили. да, то есть это так называемые когда раньше мы пытались фичи релизиться, а тут сказали, всё, ладно, типа давайте просто каждые полгода, что попало в релиз, то попало.
Speaker A
И это хорошо для такого продукта, когда уже понятно, для кого мы релизим, юзер бейс растёт, но не супер быстро, уже уже не надо как бы, чтобы релиз был какой-то прямо новостью офигенной, уже всё понятно, все уже ждут как бы, что будет релиз. И тогда можно
Speaker A
вообще без проблем Я до сих пор не знаю, можно ли так делать типа первые три релиза, может быть можно, может быть нельзя.
Speaker A
Ну, кстати, знаешь вот на правах ведущего, я бы здесь разделил два вопроса. Первый - это способность прогнозировать, когда случится релиз. И второе - действительно, почему всё происходит быстро или медленно. И вот сегодня я может быть бы про способность
Speaker A
прогнозировать не говорил, может быть про это нужно отдельно поговорить, потому что это отдельная большая мы сейчас не про прогнозировать, я я скорее да, про быстро и медленно. Ну вот как бы на самом деле, когда появились вот эти вот регулярные релизы, с точки
Speaker A
зрения всех внешних наблюдателей всё стало быстро. Угу. Потому что, ну что ты шипишь? А если ты пытаешься дождаться той одной большой флагманской фичи, то всё остальное просто лежит на полке, оно просто не выкладывается. И в итоге пользователи не
Speaker A
получают ничего, потому что они не получают самую большую фичу. Вот, и это на самом деле, мне кажется, такой довольно разумный пример, в смысле довольно репрезентативный пример ботлнеков во всяких системах принятия решений, когда типа есть куча вещей, которые не первостепенные, вот
Speaker A
первостепенная не едет и всё остальное за ней тормозится. Угу. И там психологические эффекты есть. Если что-то важное не едет, все остальные расслабляются, потому что я не в критическом пути, что я буду торопиться.
Speaker A
А потом большая фича готова, а все остальные оказалось всё это время непонятно что делали. Ну давай вот попробуем э-э это немножко структурировать. Э-э ну, во-первых, мне кажется, можно постулат такой сделать, что чаще всего всё происходит медленнее, чем хочется. Вот если мы говорим о
Speaker A
выпуске продуктов, заскопим, не будем про прогресс AI или что-нибудь ещё такое. Редко, наверное, бывают случаи, когда мы вдруг выпускаем продукт быстрее, чем хотели бы. Возможно, тут вопрос в наших ожиданиях, что мы всегда хотим большего или вот как как ты думаешь?
Speaker A
Не, я думаю, что э-э для разных людей по-разному. В смысле, что ну, есть же вот эта вот мантра великая стартаперская, что если ты выпустил продукт и тебе за него не стыдно, то ты слишком поздно выпустил продукт.
Speaker A
Угу. Ну и много кому прям дофига стыдно, и они не выпускают. Например, вот я сейчас в Кодспике, как бы мы сейчас находимся вот на такой, значит, пограничном состоянии, когда совсем кривое, прям совсем прям вот базовые юзкейсы иногда не работают, и мы их
Speaker A
чиним, значит, прямо сейчас. Но, в принципе, может быть, можно было уже выложить, и все бы очень ругались, но тем не менее мы бы, может, как бы полезный фидбек получили. Вот.
Speaker A
Ну этот это противостояние всегда есть как бы, ну, у людей, у которых какая-то там, типа, эстетическое какое-то отношение, какая-то гордость за качество. Это важная штука с одной стороны, а с другой стороны, да, надо быстрее получить фидбек от рынка,
Speaker A
неважно, что там плохо работает, несущественно. Вот. Ну тонкий вопрос. Там ещё есть всякие тонкости, что оно может там пофиг, если оно плохо работает, но оно должно красиво выглядеть, иначе никто не попробует там и так далее. В общем, такие вещи.
Speaker A
Угу. Ну, кстати, я знаешь, исходя из того, что ты сказал, тоже задумался, поставив себя на место пользователей. Иногда ты видишь, у тебя приложение обновилось. Вот мы с тобой записываем наш подкаст в Audacity. И практически каждый раз ты запускаешь
Speaker A
Audacity, он тебе говорит, я обновился. И куча новых фич. Да мне, в принципе, Audacity ещё 18 версий назад устраивал.
Speaker A
Зачем ты обновляешься? Не надо обновляться. Минутка нативной интеграции от Саши Ложечки. А Audacity, если что, бесплатный вообще не некоммерческий, кажется, проект, так что мы их очень любим. Спасибо, ребята, вы молодцы.
Speaker A
Ну, я к тому, что может быть ситуация, когда производитель продукта думает, что он очень медленно что-то разрабатывает, а пользователи уже давно их потребность свою решили, и им не нужно, чтобы что-то делать. Но вот если вот такие тоже все
Speaker A
кейсы убрать за скобки, такой стандартный кейс взять, скорее всего, наверное, мы всё-таки недовольны скоростью, чем довольны. Мы не Да, скажи.
Speaker A
Я ещё вспомнил пример. Значит, есть прекрасный способ, значит, всё испортить, двигаясь слишком быстро, накопить слишком много технического долга.
Speaker A
М-м. Просто, значит, пожертвовать всем ради скорости, и потом там будет какое-то трухлявое основание, которое тебя будет тормозить потом. И это для для всяких вот стартапов бывает вообще очень хорошая стратегия, есть специальные люди, которые такие, значит, с лопатой ходят разгребать авгиевы конюшни потом в
Speaker A
таких стартапах. Да-да-да, да, это это тоже хорошо. вполне реальная штука, да. А-а. И вот если нам теперь как-то это декомпозировать и попытаться по деталям посмотреть. А, нет, ещё одну мысль забыл сказать. Вот мы похожий выпуск записывали, получается, два выпуска
Speaker A
назад про сложность, и мы там вроде как постулировали, что сама собой сложность только растёт, и нужно прилагать какие-то усилия для того, чтобы сложность держать на каком-то разумном уровне. Вот насколько, ты думаешь, можно было бы экстраполировать и на скорость?
Speaker A
Сама собой скорость только замедляется, и нужно прилагать какие-то экстраусилия для того, чтобы скорость росла, скорость принятия решений, скорость понимания сигналов с рынка, скорость реализации, скорость обратной связи.
Speaker A
Ну, наверное, так. Значит, есть много компаний и вообще много организаций, в которых это так. Я подозреваю, что есть организации, которые сами по себе ускоряются в плохом смысле, начинают жертвовать качеством, но сейчас не про них, значит, а про тех, которые там на
Speaker A
другом конце спектра, их очень много. Я не знаю, большинство или нет, думаю, что большинство на самом деле. Организация растёт, становится более медленной внутри себя, там информация медленнее передаётся, решения медленнее принимаются.
Speaker A
Э, как бы риски растут, если всё улучшается в принципе. Люди начинают более осторожно действовать, опять же какие-то предыдущие шишки набитые начинают создавать ощущение, что надо всё-таки лишний раз подумать, а может я переложу ответственность на соседа, ещё что-то. Короче, всё начинает
Speaker A
замедляться, да. Мне кажется, что это очень распространённый тренд. Ну, а также ещё тебя же это всё ещё не убивает. Чем дальше ты проехал, тем медленнее ты сдохнешь, как правило.
Speaker A
Угу. А, если ты там, ну, не супер рискующая какая-то организация, то, ну вот в самом начале, если ты медленно едешь, ты просто, ну, проешь все деньги и умрёшь и всё. А если ты уже как бы перешёл через вот эту вот, как бы,
Speaker A
точку бифуркации, когда ты стал каким-то там прибыльным бизнесом, то дальше ты долго будешь умирать, как правило, если вот прямо ничего не делать. И там можно себя вот завалить этой, как бы, внутренней сложностью и затормозиться, ну там на несколько лет. А потом, да,
Speaker A
всё сдохнет. Угу. Вот ещё если деньги неправильно считать, можно ещё не знать, что у тебя всё затормозилось и сдохло там. Ещё какое-то время можно, значит, уходить в минус медленно-медленно. Так что, да, там это вообще распространённая тема.
Speaker A
И вот есть на эту тему как раз цитата, её часто любят во всяких корпоративных презентациях использовать. Забыл, Марио Андретти, по-моему, звали так гонщика итальянского, который сказал, что если я не совершаю ошибок, значит я еду недостаточно быстро. А, ну, в общем,
Speaker A
очевидная достаточно вещь, что скорость - это значит, что ты допускаешь какие-то ошибки. И вот в твоей аналогии, действительно, если компания уже большая и устойчивая, ей, в общем, не хочется рисковать, ей не хочется совершать ошибки ей ей о'кей, что она будет ехать медленно.
Speaker A
Знаешь, ещё можно привести здесь, да. Да, тут тут надо тонкий момент, да. Когда мы говорим ей, да, компания - это не не единый, в смысле, не единый механизм, там он довольно сильно фрагментирован. Там люди наверху, может, хотят бежать быстро, а
Speaker A
людям внизу не хочется получить по голове например. Или все не боятся ничего, но просто медленно перерабатывается информация, слишком много этажей. Вот. То есть это вообще может быть по-разному, но может быть такое, что ну вот люди себе представляют Это Вот мне очень нравится
Speaker A
про гонщиков метафора, прекрасная абсолютно. Ну давайте применим лозунг к гонщику Формулы-1. Вот, что-нибудь такое получится. Но с другой стороны, давайте просто, значит, будем двигаться максимально быстро и просто не будет у машины педали тормоза, просто уберём её. Зачем она нужна? Не
Speaker A
надо тормозить. Ну что произойдёт? Ну произойдёт понятно невозможно повернуть. Кстати, вообще прекрасная метафора. Супер поддерживаю такую метафора. Она работает хорошо.
Speaker A
Нет педали тормоза - ты не можешь повернуть. Да, да. Это Это хорошая, кстати. При этом, кстати, как в прошлом человек, который ездил на мотоцикле, могу сказать, что это было одним из моих самых главных открытий, когда я начинал учиться ездить на мотоцикле, к вопросу о
Speaker A
педали тормоза. Вот на машине, когда ты едешь, это, в принципе, нормально, что ты нажимаешь педаль тормоза и поворачиваешь. А на мотоцикле одно из самых главных правил, которые тебе на первом занятии ещё говорят, никогда одновременно не тормози и не
Speaker A
поворачивай. Ты либо тормозишь и едешь прямо, либо, если ты поворачиваешь, ты не тормозишь. Это тоже можно в эту метафору добавить.
Speaker A
вообще. Сегодня супер познавательный подкаст. Мы узнали, что Саша ездил на мотоцикле. Да, да. И даже не разбился. Потому что я не совершал ошибок, поэтому я ездил очень медленно.
Speaker A
Да. Ну, кстати, вот мне кажется, что вообще метафора с машиной вообще прекрасная. Я Ну я неправильно сказал, что невозможно повернуть. Возможно повернуть, просто надо сбросить газ и долго тормозить по инерции, а потом повернуть.
Speaker A
Угу. И это всё То есть повернуть можно, просто будет очень неэффективно. И получается, ты в угоду скорости убрал педаль тормоза. Такой Я не хочу тормозить, потому что я хочу ехать очень быстро, но в результате ты едешь не туда.
Speaker A
И это, наверное, такая либо либо очень медленно, да. Ну либо ты очень долго тормозишь, прежде чем В смысле, естественным образом, пока ты сможешь поменять направление. И это действительно то, что, наверное, многие люди, призывающие к скорости, забывают. То есть они-то думают, что скорость - это
Speaker A
про то, что мы не только быстро ездим, но и быстро поворачиваем, а вот это получаются очень разные вещи.
Speaker A
Да, это очень хороший тейк. Я всё, у меня, простите моё занудство, меня не отпустит. Я вспомнил, что есть ещё торможение двигателем. Я не знаю, вписывается ли оно в эту метафору, мы не будем этим заниматься сейчас.
Speaker A
Ну давай уж её до конца доведём, как говорил мой инструктор. Э, ну сейчас, это ты типа переключаешься на более низкую передачу и двигатель начинает нагружать очень очень сильно, да.
Speaker A
Я я другую шутку хотел вспомнить, которую говорил мой инструктор, когда я учился на машине ездить. Когда его спрашивают, что такое торможение двигателем, он говорит, торможение двигателем наступает после того, как у тебя прошло торможение бампером, торможение капотом, а потом у тебя
Speaker A
начинается торможение двигателем. Это очень хорошо, да. Ладно, всё, значит, сейчас метафорой больше не будем копать эту метафору, потом разберёмся.
Speaker A
Э, да, значит, но но возвращаясь к этому ко всему. Действительно, чтобы быстро двигаться, ну, в реальной жизни, нужно уметь быстро поворачивать. И для этого нужно что-то уметь замедлять. И это, на самом деле, кстати, психологически я вот на себе знаю, я периодически пытаюсь,
Speaker A
значит, очень сильно как бы бороться за скорость внутри. Обычно, кстати, очень непродуктивно. Ну вот буквально на прошлой неделе обсуждали, что когда я начинаю переживать, что всё слишком медленно, я автоматически начинаю очень много микроменеджить. И это абсолютно неэффективно, вообще никакого смысла в
Speaker A
этом нет, мне становится лучше, я добавляю стресса в систему все недовольны, я недоволен, короче, всё ужасно. Вот, и это просто типа психологическая особенность, гиперконтроль называется.
Speaker A
А что делать? Ну, во-первых, в моём случае явно голову включить, во-вторых, ну, научить давай ещё в команде, что меня в этот момент послать и сказать, что ты микроменеджить пришёл, иди короче выдохни.
Speaker A
Нет, ну а вот давай вот, поставим себя на место тебя. Вот ты недоволен тем, что всё медленно.
Speaker A
А а что делать вот в этот момент? И я себя ловлю на этом, мы начали выпуск с этого вопроса, почему, блин, всё так медленно. И вот ты осознал, тебя не нравится скорость движения твоей организации. Куда бежать, что делать?
Speaker A
Ну вот я могу про себя сказать несколько вещей, я ещё как бы на этом пути нахожусь и буду долго находиться.
Speaker A
Я понимаю несколько вещей. я у себя внутри завышаю э-э, критичность, насколько всё плохо. Когда мне кажется, что всё медленно, а всем остальным не кажется, у меня очень большой разлад, как бы ощущение, что на меня никто не поддерживает, всем пофиг,
Speaker A
там что-то такое. Ну, иногда это означает, что я, например, не объяснил остальным, а почему надо быстрее. Иногда это означает, что мне просто кажется, что надо быстрее, а на самом деле всё нормально, всё довольно быстро, мы просто В смысле, у меня в голове всё
Speaker A
слишком быстро развивается, я уже всё придумал как бы дальше, но почему-то ещё не произошло.
Speaker A
Вот. То есть тут есть вот эта коррекция просто на на то, насколько надо на самом деле надо быстрее и насколько критично двигаться быстрее раз. Два, очень важно, чтобы остальные тоже думали как-то так же, что типа нам действительно надо
Speaker A
быстрее. И это то ли опять же Вот с ними надо поделиться какими-то соображениями, почему надо быстрее или там вот обратите внимание, смотрите, вот это было медленно.
Speaker A
Это раз. Во-вторых, им нужно какой-то для того, чтобы подумать про это. То есть если они там уже загнаны как бы с с головой погрузились в какую-то там другую деятельность, у них нет времени пораздумывать над тем, а почему так
Speaker A
медленно или что медленно, а что не медленно. Вот. Номер два. Ну и номер три - нужно действительно понять, э-э, типа где стоит бороться за скорость, где нужно э-э просто поднажать, а где нужно наоборот вообще остановиться, подумать, что мы
Speaker A
делаем не так. Угу. Вот. Ну вот типичная история вот с техническим долгом, особенно сейчас, когда все как бы педаль газа сейчас - это давайте добавим агентского программирования. Агентское программирование не всегда ускоряет людей. В зависимости от того, как вы им
Speaker A
пользуетесь, оно может вас в первый день ускорить, а на четвёртый день уже вас тормозить, потому что you нагенерили кучу кода, который вы не понимаете, что-то всё сыпется, непонятно, что происходит. Самая смешная ирония состоит в том Ну это как бы Я Я могу её
Speaker A
рассказать не только как иронию, но буду рассказать как иронию. Состоит в том, что Ну мы в очень старались много-много программировать с агентами, потому что это то, как наши пользователи должны жить по идее. Ну мы для них это всё делаем. Вот. Ну и мы в
Speaker A
итоге там за полгода нагенерили столько кода, который мы не понимаем, что мы уже просто не понимаем, что происходит.
Speaker A
И это как бы смешно, потому что наш продукт должен как бы с этим помогать.
Speaker A
Ну продукт-то развивается в процессе, поэтому он ещё не полностью помогает. Вот. И получилась смешная ситуация, что мы оказались ровно в том месте, в котором мы должны помогать. Вообще-то для бизнеса это прекрасно, потому что у тебя есть он как бы для этого и существует, что ты
Speaker A
находишься в такой же ситуации, как пользователь, у тебя максимальная эмпатия к пользователям. С другой стороны, ну, чувствуешь себя чуть-чуть глуповато. Ты же как бы знал, что так будет.
Speaker A
Вот. Да. Ну, в общем, когда я буду старый и буду рассказывать всем, как эта компания достигла успеха, я буду говорить, что вот, мы сознательно рулили в то место, где у нас было так же, как у пользователя. На самом деле, ну, мы
Speaker A
просто постарались побыстрее, и получилось плохо. Как у всех, собственно говоря. И это вот типичная ситуация, когда ты пытаешься просто давить на газ. Ну, это на самом деле, аналогия с машинами меня сегодня не отпустит. Это когда ты давишь на газ,
Speaker A
значит, давишь на газ, у тебя давно достигнута терминальная скорость, ты не можешь ехать быстрее, потому что сопротивление воздуха слишком большое.
Speaker A
Вот. Но ты занимаешься тем, что просто сильнее давишь на газ, а не тем, что оптимизируешь аэродинамику машины.
Speaker A
Вот. И, ну, вот мы сейчас сознательно замедлились, мы там типа 2 недели честно потратили вообще на вещи, которые никак не связаны с развитием продукта. Ну, то чнее, в смысле, не не являются не добавляют никакого там нового кода, какие-то вещи, вообще в продукте ничего
Speaker A
не меняют за это время. Ну, ну вот давай, может быть, как раз попробуем декомпозировать, откуда возникают тормоза. И я бы предложил такую декомпозицию. Первое - это, что мы долго считываем сигналы извне. То есть мы не понимаем, что у нас проблема. Мы,
Speaker A
допустим, сигнал считали, и мы сидим и думаем, а что с этим сигналом делать. То есть мы долго перевариваем информацию и вырабатываем, допустим, разные варианты решения. Третье - мы из этих разных вариантов решения долго принимаем решение, куда идти. Четвёртое - если мы
Speaker A
уже приняли решение, куда идти, мы долго его реализуем. Вот, может быть, у тебя какие-то другие ещё есть идеи, как можно было бы декомпозировать?
Speaker A
Мне кажется, есть ещё какая-то штука про то, что, ну, сама цепочка как бы вот от управляющего воздействия до результата очень большая задержка.
Speaker A
Но и это, получается, сумма всех этих четырёх штуку от сигнала до Ну, то есть, ну там там причём ну ну типа того, да. Можно так сказать.
Speaker A
Мне кажется, что это просто не очень удобно всё время туда декомпозировать. Ну да, давай большая организация там, типа кто-то в отпуске а маленький. И как бы всё застряло в этом месте, потому что никто не знает, как это сделать, а отпуск там до
Speaker A
послезавтра. И вот это всё, значит, оно Это, кстати, можно тогда ещё пятый в эту декомпозицию добавить компонент, как быстро сигналы внутри организации ходят. Вот мы с тобой когда-то выпуск про дофамин записывали. Дофамин - это штука, которая ускоряет передачу
Speaker A
сигналов по нервам. И поэтому да. Представляешь? Ты вот любишь ты вот эти вот все э ускоренные движения.
Speaker A
Ну это моё понимание, могу ошибаться. Да, в общем, забыли про дофамин. У тебя точно так же сигналы внутри организации ходят. Они могут ходить быстро, а могут внутри организации ходить медленно.
Speaker A
Да-да-да, но и тут причём много что зависит от всяких разных трейдофов, да? Внутри организации у тебя всё может быть ориентировано на то, чтобы всё было быстро, но если прямо максимально всё так ориентировать, придётся пожертвовать благополучием сотрудников очень сильно.
Speaker A
Ну смотри там всякие стрёмные практики, не знаю, в каком-нибудь там в Спейс Иксе, Тесле с одной стороны, а с другой стороны, ну вот где какие-нибудь там успешные стартапы летят и просто фаундер работает 24/7, требует от всех, чтобы они работали 24/7, люди выгорают,
Speaker A
и их просто увольняют, нанимают новых. Да, и ты потом штука. Это очень похоже на то, что ты выше сказал, когда из-за того, что ты хочешь ускориться, ты в итоге замедляешься, потому что у тебя в итоге найм новых людей, их онбординг занимает больше
Speaker A
времени, чем ты сэкономил на том, что у тебя люди выгорали. Зависит от процессов. Зависит от процессов, то есть, ну, знаю несколько стартапов, которые при этом растут гигантскими темпами, и всё у них получается. Но тут надо понимать, что это всё наверняка копит, ну, то есть
Speaker A
наверняка, а совершенно точно копит всякий долг разный. И там, когда дорастёшь до, ну, невозможно бесконечно очень быстро расти, да, начнешь расти немножко медленнее, а лояльности людей нету, организация токсичная, что-то всё стрёмно очень там. Ну, будут какие-то, какая-то цена у этого всего будет. Люди
Speaker A
в конце концов не всегда хотят бесконечно работать на износ. Там будут текучки точно больше, это там какие-то накладные расходы, с лояльностью проблемы, там много политики будет возникать странной такой совсем подковёрной. В общем, ну, у этого есть цена. Иногда это о'кей, иногда нет, но у
Speaker A
этого есть ещё просто чисто с точки зрения совести вообще вопрос это хорошо или нет Угу.
Speaker A
строить организацию, в которой люди просто у нас его выгорают. И как бы вопрос там, типа, насколько у тебя совесть позволяет тебе давить на газ вот таким способом.
Speaker A
Да? Если ты хочешь там, не знаю, ну, а в каких-то странах вообще-то законы есть, которые не позволяют так работать. Тоже там вопрос, надо ли в этих странах работать и можно ли там строить большой бизнес и почему в тех странах нету так
Speaker A
много больших компаний, как в Америке, где так можно. Ну, в общем, это факт, есть такой трейдофф и, ну, можно для себя делать какой-нибудь выбор. Можно, значит, хотеть строить компанию, в которой всем хорошо, э, точно получится очень медленная компания, всем хорошо
Speaker A
Можно строить компанию, где есть какие-то всё-таки, ну, базовые нормы, что мы там, типа, не не умираем на работе, ценим людей и всё такое. А можно строить компанию, которая людей выжигает массово и, типа, всё о'кей. Но у этого есть разные трейдоффы. Насколько у вас
Speaker A
как бы сильно болит совесть, просто как насколько фаундер может вообще спать, если он знает, что люди массово выгорают, зависит от фаундера.
Speaker A
Люди разные. Я бы э, да, я с тобой согласен, я бы тоже не хотел так работать. Но вот давай вот, э, в это тогда зацепимся. Чаще всего, когда что-то происходит медленно, э, допустим, мы берём разработку продуктов. Не будем
Speaker A
все любые процессы на свете брать, разработку продуктов. Чаще всего медленно разрабатываем, а потому что разработчики медленно пишут код.
Speaker A
Поэтому давайте они будут работать больше, давайте им ддим агентов или ещё что-то. Ну, в общем, давайте улучшим, э, лидтайм. А мне кажется, что это похоже на то, как мы ищем ключи не там, где потеряли, а под фонарём. И вот мне
Speaker A
кажется, что больше всего тормозов происходит как раз не на этом кусочке реализации принятого решения, а больше всего тормозов происходит на первом этапе, когда мы поздно считали сигнал с рынка и делаем слишком, начинаем какую-то проблему осознавать слишком поздно. Или
Speaker A
слишком долго мы этот сигнал как-то пытаемся понять и пытаемся придумать варианты решений, или слишком долго решения принимаем. Ну то есть у нас больше тормозов происходит как раз на этапе до появления джира-тикета, а не после появления джира-тикета.
Speaker A
Ну мне кажется, что это идеализация. То есть возможно, опять же, ну вот может быть там, где ты работал, было так. И и расскажи тогда про это. Там, где я работал, был не так. Было очень часто, что наверху принято решение, там это
Speaker A
заняло неделю, не знаю, ничего страшного. И потом, значит, люди крутят руль, а руль ни к чему не не прикреплён.
Speaker A
Руль крутится, а ничего не поворачивает. И это вообще не редкая ситуация, когда инерция организации такая, что ты не можешь повернуть. Просто оно прокручивается, ничего не происходит.
Speaker A
Расскажи про это. Ну инерция там, где я видел, работает очень понятным образом. Люди привыкли работать каким-то, ну, определённым способом.
Speaker A
Этот способ, например, там перенасытился уже давно. Ну там известная проблема была в ДжетБрейнсе, когда каждый человек отвечал за свою какую-то зону в продукте, и его просто, ну, когда стали там десятки, нет, 10 с чем-то миллионов пользователей, его просто завалило
Speaker A
фидбеком. Угу. есть просто чинить баги можно бесконечно. И всё это человек не может делать никакого прогресса. Никаких инноваций, ничего не происходит, потому что он просто сидит и поддерживает пользователей. Он всегда поддерживал пользователей. 10 лет назад, когда пользователей было в 10 раз меньше, он
Speaker A
тоже поддерживал пользователей, и всё было хорошо, продукт развивался. Но всё, значит, панель переполнилась. А люди, у которых очень большой авторитет в организации, которые всё знают и всё такое, они просто привыкли так работать.
Speaker A
И они не молодеют. Очень сложно заставить сотню таких людей начать жить по-другому. Это на метауровне. А вот давай вот на уровне одного такого человека. Мне кажется, это как раз в ту модель декомпозиции, которую я выше предложил, очень хорошо входит. Это про то, что мы
Speaker A
неправильно считываем сигнал с рынка. Ну в данном случае у нас просто очень много с рынка приходит шума, и мы на каждый вот этот маленький печок реагируем вместо того, чтобы, допустим, как-то это всё попытаться объять.
Speaker A
Да, но это всё верно, только ты как бы одного человека описываешь местоимением мы. Значит, на самом деле ну, компания там большая, да, там кто-то что-то давно считывал. То есть там CEO давно понял, что на рынке что-то произоло, а разработчик не поверил. А
Speaker A
всё зависит от разработчиков в конечном счёте. Угу. А система управления в компании такая, что просто приказного как бы режима у нас нет.
Speaker A
Давай про это поговорим, про приказной режим. Я вот тут столкнулся, я, по-моему, даже про это рассказывал уже, когда у нас был выпуск про типологию ёжиков, про разные способы принятия решений в компаниях, что если так очень-очень сильно упрощать, то есть два способа
Speaker A
принятия решений - top-down и consensus-based. Top-down - это когда у тебя вот руль покрутили, и он прикреплён, и он прямо вот сильно прикреплён, и куда по покрутили, туда он и повернулся. И этот руль крутит один человек. Можно поговорить про
Speaker A
ограничения этого подхода, но пока на контрасте альтернатива - это когда у тебя руль ни к чему не прикреплён, и если рулевой решил повернуть, то он должен ко всем прийти и всех убедить этот руль повернуть. И причём, пока все
Speaker A
не договарятся, руль никуда не повернутся. Ну, это, конечно, и то, и то идеализации, но примерно понятна философия, что типа нужно, чтобы много народу согласилось или мало народу согласилось да.
Speaker A
Да. При этом вот иллюзия первого способа состоит в том, что вроде бы как top-down decision making, он должен проходить очень быстро, но на практике оказывается, я это очень хорошо наблюдал, кстати, такими top-down компаниями являются и Microsoft, и Amazon, там очень чётко решение
Speaker A
принимается самым главным в комнате. Принятие решения - все могут очень долго спорить, не соглашаться, но потом встреча заканчивается, и самый главный в комнате встаёт и говорит, вот я вас всех очень внимательно послушал, спасибо большое за ваше мнение, решение такое, и
Speaker A
все идут его исполнять. Отсюда же вот рождаются вот эти все идеи амазоновские, что ребята, вы должны там, как звучит вот этот То есть пока решение не принято, все должны изо всех сил спорить и доказывать своё мнение, но после того, как решение
Speaker A
принято, корпоративная честь требует, чтобы все сказали, даже если я не согласен я это решение делать. Ну и дальше уже начинается разная степень добросовестности. Кто-то искренне, несмотря на то, что он не согласен, выполняет это решение, а кто-то делает это спустя рукава. Я же не согласен, как
Speaker A
я буду стараться это делать? Я потом наоборот, когда ничего не получится у вас, я приду и скажу, а я говорил, что нужно было делать по-другому. И поэтому вот в таких вот культурах, как правило, приходится делать разные степени контроля, что ты не просто наверху
Speaker A
где-то руль повернул, а у тебя ещё есть какие-то специальные люди, которые проверяют, что все послушались и в соответствии с этим решением руль-то повернули. А если не послушались, нужен механизм наказания, ну или мотивации, если послушались. А дальше возникает вопрос, а кто сторожит стражников, кто
Speaker A
контролирует эту систему контроля и так далее, и так далее. И в общем, это идеализированная модель, где главный рулевой повернул руль и всё повернулось, она начинает много где буксовать. А альтернатива.
Speaker A
добавить кусочек, наверное, важный, что если люди ходят строем, у них не всегда получается творческая работа какая-то.
Speaker A
То есть если надо что-то придумать, а люди не понимают, типа почему от них этого хотят, им кажется, что это какая-то чушь, то они просто будут плохо придумывать даже не потому, что они как-то там корпоративную этику не соблюдают, а просто, ну типа не
Speaker A
включается у них вот этот вот огонь, который помогает что-то придумывать. Ну просто вот так не срабатывает психологически у людей.
Speaker A
100% и более того, у тебя в такой культуре, если она вырожденная, у тебя люди хоть сколько-нибудь креативные, творческие, они просто работать не хотят, им не интересно там работать.
Speaker A
Зачем? Наймите тех, кто будет просто приказы выполнять. Да, но я замечу, что это всё так, только если нету какого-нибудь другого психологического механизма, типа культа личности руководителя.
Speaker A
А, да, да. Потому что можно так настолько хотеть угодить любимому лидеру, что придумаешь, даже если не понимаешь зачем. Как бы, ну вот есть какая-то постановка задачи, ты в неё впишешься, даже если ты не согласен, что это лучшая постановка
Speaker A
задачи. Так можно, но нужен тогда прямо вот личный какой-то очень высокий авторитет или какая-то, ну вот какая-то ещё эмоциональная привязка к лидеру.
Speaker A
100% Ну и причём это может быть даже вполне в позитив. Ну то есть типа я настолько преклоняюсь перед Илоном Маском, что он такой инженерный гений, что я искренне хочу делать всё, что он сказал, потому что жираф большой, ему
Speaker A
видней. Альтернативная модель это когда никто не может ничего приказать, все пытаются договориться. И все пытаются договориться и договариваются договариваются договариваются договариваются договариваются, договариваются до тех пор, пока все не согласятся.
Speaker A
Потому что без этого ничего не происходит, приказать нельзя. Я тоже вырожденную ситуацию и начинай сначала шило до мочало, мы заново договариваемся. А вторым минусом такого подхода является то, что в нём часто побеждают не самые лучшие идеи, а либо идеи компромиссные. Ну
Speaker A
когда мы не можем договориться, как мы будем, не знаю, экономить бюджет, поэтому давайте мы просто каждый сэкономит, поровну поделим на всех. То есть ты в такой ситуации не можешь концентрировать усилия на чём-то одном.
Speaker A
Ну или точнее это сложнее, потому что это не компромиссно. А второе, часто в таких культурах побеждают просто более упорные. То есть они берут упорством и в итоге ты уже такой ладно, проще отдаться, чем объяснить, почему ты этого делать не хочешь. Не что второй
Speaker A
способ принятия решений, он в итоге приводит к более качественным решениям, чем первый. Да и вообще, тут не про качество принятия решений, тут скорее про то, как они применяются. Плюсы и минусы есть везде. Но к плюсам очевидно второй ситуации можно отнести то, что
Speaker A
там люди более творческие, креативные, они лучше себя чувствуют - раз, а два если ты всё-таки в этой консенсус- бейс модели до чего-то договорился, тебе можно сэкономить на системах контроля, потому что у тебя люди не просто выполняют приказ, они действительно
Speaker A
вроде бы как эту идею купили. Что думаешь про это? А Думаю несколько вещей. Во-первых, кажется, что ну типа и у той, и у той модели есть всякие типа идеализированные юзкейсы, в которых всё хорошо работает.
Speaker A
Вот. В консенсусной модели всё хорошо работает, когда все очень верят в результат и когда как бы консенсус такой очень как бы он не вырабатывается очень болезненно. А вот пришёл значит лидер какой-нибудь там или что-то не знаю, просто человек с идеей пришёл, всех
Speaker A
зажёг этой идеей, все такие да, немножко там её обработали чуть-чуть и побежали. Типа всё очень круто, всё сходится, у всех всё сразу ложится как бы в красивую картинку. Это действительно оптимальная ситуация и тогда вот не надо никого контроля, все поверили, всё прекрасно.
Speaker A
Есть ситуация, в которой всё наоборот, типа какие-то фракции там что-то кто-то верит в одно, кто-то в другое, они очень долго ругаются, ничего не происходит.
Speaker A
Уже могли за столько времени, сколько потратили на принятие решений, и то, и другое сделать и посмотреть, что будет.
Speaker A
Короче, всё вот это вот очень мучительно. И то же самое в вертикальных организациях. Есть идеализированный вариант, когда есть какой-то один гениальный человек, который там не знаю всё знает, как надо сделать. И просто значит ему никто не верит, а он просто
Speaker A
всех продавливает и получается, и они в итоге просто значит начинают верить ему, потому что он был прав в предыдущий раз.
Speaker A
Вот. И соответственно там нет никаких проблем с лояльностью потом, с какими-то ещё там напрягами. Нет, все очень счастливы, что вот у нас такой офигительный значит руководитель. Ну это всё случается, особенно временно, в таких режимах организации бывают, но понятно, что в чистом виде такое не
Speaker A
существует долго обычно. Потому что прекрасные лидеры начинают заговариваться и воображать себя совсем уж слишком прекрасными, делать глупые ошибки, смотри вообще все новости последнего времени. С одной стороны, с другой стороны вот эта вся консенсусная система. Мир сложный, начинают все
Speaker A
какие-то разные варианты, риски растут, люди начинают больше бояться, у людей возникают какие-то собственные идеи, люди хотят тоже, значит, почувствовать себя тем самым человеком, который предложил идею, начинают выдвигать какие-то вещи, которые ну, может они там плохо угадали, а может они
Speaker A
некомпетентны, а может ещё чего-то. Короче, ну в любом случае возникает трение в этом месте. И то, и то идеально никогда не работает. И здесь очень важно, что есть ошибка выжившего, люди рассказывают истории про то, как вот у них такая красивая работающая система
Speaker A
только тогда, когда она красивая и работающая, а чаще всего, когда они просто так себе рассказали эту историю внутри. Рассказывают только тогда, когда есть что рассказать, а во-вторых, все врут. И это идеализация. И можно пытаться их как-то, ну, приблизиться к
Speaker A
ним, всё такое, но опять же не надо пытаться из из мыши стать ёжиком - не получится. Если у вас не такая организация, которая, по сути, может быть там вертикальной и ходить строем, как у Генри Форда или там у у Маска, то ну просто нет, вас
Speaker A
просто пошлют и разойдутся ваши люди там по другим организациям. Если у вас не такая организация, в которой там консенсус очень продуктивный, всё быстро там и так далее, ну не получится опять же. Мне кажется, что на практике большие организации, как
Speaker A
правило, вырастают всё-таки в какое-то там промежуточное состояние. Это может быть какой-то относительно быстрый, но всё-таки ну коллегиальный Amazon, то есть в Амазоне все очень стараются, чтобы было быстро, очень такая своеобразная неортодоксальная штука, много вертикальных вещей, но тем не менее там
Speaker A
есть много советов на разных уровнях, я подозреваю. Вот, но я был просто гостем на некоторых из этих советов.
Speaker A
Вот, люди вообще друг друга слушают и там решения принимаются не мгновенно, и Amazon дофига быстрый, но там что-нибудь серьёзное сделать вместе с Амазоном занимает полгода.
Speaker A
И как бы, ну, да. А вот, кстати, из твоего опыта. Ты много работал с Гуглом как партнёр и с Амазоном как партнёр. Не знаю, насколько у тебя есть ещё внешний взгляд на Microsoft. Вот если бы ты сравнивал то,
Speaker A
что можешь сравнить, быстрее ли Amazon, чем Google, например? Из того, что я помню, нет, но там понятно, мы всё-таки, ну там, в Гугле у нас люди, которые были заинтересованы в сотрудничестве с Котлином, были немножко повыше рангом, чем в Амазоне, поэтому
Speaker A
там, понятно, их решения тяжелее, чем, в смысле, больше веса имеют, чем решения тех рисков, которые с которыми мы говорили в Амазоне, с одной стороны. С другой стороны, там в разной степени натягивание самого глобус. Ну, в общем, короче, немножко разные ситуации. То
Speaker A
есть там, когда Amazon договаривался с нами там, не знаю, в каком, не помню в каком, девятнадцатом при году, там это явно им очень хотелось, но было не совсем понятно, к какому месту это приклеить и что-то там то идёт, то не
Speaker A
идёт, ну, просто было понятно, что там не такой очевидный кейс. В случае Гугла всё было очень просто, там была одна большая ставка, и как бы и дальше всё, уже её сделали и надо бежать. Вот, так что не могу сказать одинаково, но ощущение,
Speaker A
что и то, и то большая организация, там куча приоритетов. Как бы большая У большой организации же какая ситуация?
Speaker A
Много разных направлений делаются одновременно какими-то, ну, более-менее общими ресурсами. Здесь куча приоритетов, которые конфликтуют, и так и надо и типа задача управления такой большой штукой - это какое-то примирение этих приоритетов, не знаю, приоритизация внутри, значит, ранжирование этих приоритетов или там какое-то
Speaker A
распределение ресурсов между этими приоритетами. В общем, что-то там надо делать вот такое, потому что невозможно просто сказать, ну, вот это неважно, типа там инфраструктура не важна или там, не знаю, маркетинг не важен. Нет, всё важно.
Speaker A
В смысле, нельзя ничего бросить полностью, но, может быть, сейчас надо там нажать больше сюда или больше туда или там это долгосрочный эффект имеет, а это краткосрочный. Ну, короче, там какая-то сложная начинается история, нету простой как бы простого нарратива,
Speaker A
который всё объясняет и всё понятно, как решить. Нет, там всё сложно. И, кстати, вот это важно понимать, когда мы говорим про вертикальные versus консенсусные решения.
Speaker A
Есть ещё как бы кроме организации, есть ещё политические системы. И вот есть очень интересный пример Китая, да, в котором была такая типа коллегиальная сначала система управления довольно долго, вот, ну, до недавнего времени совсем, а потом вот она узурпировалась
Speaker A
там одним человеком. И коллегиальная система аргуэбли работала лучше, но она, например, меньше людей убивала внутри там и давила вообще. Но это как бы гуманистические соображения. Но если с точки зрения эффективности, там вообще есть вопросы, типа что лучше.
Speaker A
А, вот. Опять же, потому что трудно в очень маленьком количестве голов собрать типа всю информацию. И очень часто бывает вот это вот оторванный руль, он очень часто бывает потому, что наверху принимаются решения из очень упрощённых соображений. Люди наверху не понимают,
Speaker A
что на самом деле происходит, поэтому говорят, давайте сделаем вот так, у нас всё получится. А им снизу говорят, ну, типа ты ковбой, ты и прыгай как бы.
Speaker A
Непонятно, что теперь делать с вашим прекрасным решением, вы его принимали из соображений, которые не реалистичны, просто типа жизнь устроена не так. Вот, то есть, ну, очень многие вещи просто нельзя сказать, давайте сделаем и оно получится, потому что нет, ну, типа не получится,
Speaker A
реальность другая. Вот, и в этом смысле вот эти все там типа советы, согласования и так далее, они вообще как бы базово имеют очень понятную интуицию под собой. Есть человек, который в чём-то разбирается, а я не разбираюсь. Надо его спросить перед
Speaker A
тем, как принимать решение. Очень понятно. А теперь это умножить на тысячу и всё, как бы никакие решения никогда не будут приняты.
Speaker A
Абсолютно, да. И ты спрашиваешь этих экспертов, и ты находишь на любую точку зрения одинаковое количество достаточно авторитетных экспертов, которые будут друг другу противоречить. И это тебе вот наверху решение никак не помогает принять.
Speaker A
Ну, да, ну, наверное, да, ну, ну, как бы дело, наверное, не в том, что обязательно найдёшь тех экспертов, которые не согласны, а в том, что просто, ну, у каждого эксперта немножко своя узкая какая-то точка зрения, она не учитывает что-то другое, и тебе нужно
Speaker A
каждую из этих точек зрения как-то, значит, расширить и чем-то пожертвовать. Это всё равно в конечном счёте разговор про какие-то там типа компромиссы или ну, про приоритизацию между этими вещами. Тебе надо сказать, о'кей, значит, этот эксперт говорит так, наверное, так и будет, действительно, но
Speaker A
это не страшно, типа, мы, значит, этим пожертвуем, а вот этим не пожертвуем, и так далее. То есть у тебя становится очень много информации для принятия решений наверху, когда ты спросил у всех экспертов. Это заняло кучу времени и создало тебе больше работ. И кажется
Speaker A
этим бороться качество решения. Ну, как бы повысило повысило шанс принять решение лучше, то есть ты, по крайней мере, у тебя больше информации, то есть ты ты знаешь больше.
Speaker A
Это, наверное, как правило, повышает шанс принять хорошее решение, просто э-э работы, потому что чтобы всю эту информацию использовать, становится очень много.
Speaker A
Угу. И у тебя начинается там какой-то госплан, значит, наверху сидит, который пытается какие-то формулы про это писать, и, в общем, это всё очень плохо кончается обычно.
Speaker A
Но вообще очень интересно то, что ты сказал. Да, ситуации несравнимые, Amazon и Google, но то, что Google в итоге оказался быстрее Amazon, потому что им было очень сильно надо, мне кажется, чему-то это может научить.
Speaker A
Google, кстати, я не могу сказать, что оказался прямо быстрее Amazon, не знаю, просто трудно померить, но Google оказался гораздо хмм как бы гораздо определённее, в смысле, у них было чётко понятно, что вот они решили вот это и теперь они будут там 3
Speaker A
года это делать. Amazon в нашем случае менял мнение там много раз, ну просто потому что не такая серьёзная ставка была. И вообще было как бы не так очевидно, где в общем выгода.
Speaker A
Ну, и я могу сказать из своего опыта изнутри. Э-э я бы не сказал, что Microsoft и Amazon как-то радикально отличаются по скорости, хотя в Amazon это действительно постоянная мантра, и там действительно придумано какое-то количество механизмов для того, чтобы
Speaker A
решения вроде бы принимать быстрее. Но в итоге на круг у меня нет ощущения, что действительно Amazon сильно быстрее Microsoft.
Speaker A
Я могу тебе предложить метрику, по которой Amazon быстрее Microsoft - это продуктов в секунду.
Speaker A
Это правда, да. Ну, вот это, кстати, хороший момент. И действительно, вот если опять же говорить про консенсус-бейс или топ-даун, вот то, что я вижу из своего опыта, редко, когда бывает организация монолитная с этой точки зрения. Чаще всего это
Speaker A
организация, на разных уровнях которой разные системы принятия решений. Есть, допустим, какие-то вот эти маленькие тим, которые очень, допустим, консенсусные. Рядом с ними компания - такая же тим, которая очень топ-даун. Ты что смеёшься?
Speaker A
тим. А, ну да, да, звучит Ну, в общем, они могут быть на разных уровнях очень разные, и это всё получается очень какой-то такая сложная мешанина, и в итоге там, кто победит из этих подходов, никогда не понятно. Но, возможно да.
Speaker A
Тут, понимаешь, мне кажется, что как бы кто победит, там не должно быть никакой победы. То есть есть же вот этот вот как бы понятный разговор там, не знаю, в любой политической системе, в любой большой компании. Грубо говоря, централизованная власть против местного
Speaker A
самоуправления. И мне кажется, вот в этом смысле аналогия там с государствами и странами, она очень разумная. Но есть какие-то безумные ситуации, когда типа в Швейцарии 51 кантон там или сколько-то типа там 50 вот примерно.
Speaker A
Ну, что-то большое, да. Да, но значит, как правило, это всё-таки там продиктовано какой-то очень жёсткой географией. То есть просто, ну, есть там, не знаю, Российская Федерация, ей очень трудно централизованно управлять хорошо, прямо ну совсем никак. Когда попытались когда-то давно там типа на на
Speaker A
Дальнем Востоке кончился кончилось топливо сразу. Потому что просто, ну, Москва далеко. Вот. И в этом смысле ну очень трудно хорошо принимать решения в Москве про Владивосток.
Speaker A
Угу. Особенно про 50 Владивостоков. И там очень трудно принимать решения, не знаю, там в Брюсселе про какую-нибудь, значит, там деревню в Албании. Ну прямо очень трудно. И не надо. Потому что, в принципе, регионы там разберутся на своём уровне. Не надо пытаться всё
Speaker A
стащить в в один мешок, надо отдать какое-то количество всего в местное самоуправление. Ну и там дальше вопрос, а что надо, а что не надо. И вот оно начинается. Если ты общественный транспорт типа в городе в каждый район отдашь, всё будет хреново, город не
Speaker A
будет связанным. Вот. А если ты там заберёшь вообще всё из из каждого района, то районы все, значит, будут выглядеть ужасно и всё будет отвратительно. Ну и там вот есть много вопросов о том, как надо делать, типа что надо централизовать, на каком
Speaker A
уровне, да? Типа, надо ли там, не знаю, весь общественный транспорт в стране централизовать? Скорее всего, нет. А, вот железные дороги, может быть, и да, например, там, типа. Что-то надо оставить коммерческим, а что-то сделать, э, государственным. Там и, в общем,
Speaker A
никто не знает идеального решения, но какие-то есть наблюдения про то, что вот если это слишком фрагментировано, оно плохо работает, если это слишком централизовано, оно плохо работает.
Speaker A
То же самое в корпорациях, когда есть какие-то люди на земле, которые в хорошем контакте со своей, там, географией, аудиторией, со своими специалистами, там, со своими поставщиками, ещё с чем-то, в хорошем контакте. И они там на своём уровне могут хорошо разобраться, у них хороший
Speaker A
баланс между количеством информации, которая у них есть, и, типа, теми рисками, там, которые случаются от того, что у них нет какой-то информации от других.
Speaker A
И вот они отлично справляются. Особенно, если им можно поставить какие-то понятные метрики, там, ограниченное количество этих метрик, всё нормально получается.
Speaker A
Очень круто. Вот. Ну а есть вариант, когда вы там, типа, э, ну, у вас там получается максимайзер на минималках. Значит, вот вам сказали, типа, давайте оптимизировать закупки. И you просто перестали закупать качественные вещи вообще, потому что идите на фиг, типа,
Speaker A
мы оптимизируем закупки. Вот. Закупки нужны для чего-то, типа, вы не учли. Ну вот такое, короче.
Speaker A
И вот то, что ты говорил про Amazon, это как раз иллюстрация этого примера. Почему Amazon шипит так много продуктов?
Speaker A
Потому что у них, э, это право выпуска продукта, оно очень сильно опустила вниз, и у них каждая вот эта маленькая team может свои продукты шипать.
Speaker A
А Microsoft, она более централизованная организация, и там на более высоком уровне принимается решение, шипим мы продукт или нет.
Speaker A
Какая стратегия лучше, тоже учёные могут долго спорить. А, но лучше просто. С точки зрения количества продуктов понятно, какая лучше.
Speaker A
Да, да, абсолютно так. И получается, что вот точно так же, как мы с тобой в выпуске про сложность говорили что наверное сложность э можно хоть как-то пытаться адресовать, если декомпозировать большую монолитную систему на много маленьких, ну или не
Speaker A
много, ну на более маленькие и осязаемые, что они в голову одного человека помещаются компоненты, точно так же и со скоростью. Одно дело, когда у тебя скорость всей большой, большой организации монолитной, а другое дело, когда у тебя скорость маленьких вот этих
Speaker A
вот более-менее независимых компонентов. Ну, тут, кстати, есть интересные всякие штуки. То есть, ну вот есть, например, такие, грубо говоря, сервисные подразделения в любой большой компании.
Speaker A
Есть там люди, которые обслуживают в широком смысле много других подразделений. Ну там всегда этим занимается там всякая там бухгалтерия, юристы - понятно, инфраструктура любая, часто закупки централизованные, там ещё чего-нибудь такое. Ну понятно почему.
Speaker A
Потому что мы не хотим, чтобы у нас были там абсолютно разные мнения по поводу того, как нам юридически что-то делать или не делать в разных подразделениях.
Speaker A
Ну там, потому что это снаружи, во-первых, воспринимается, как будто это одна компания это делает, когда она делает противоречивые вещи - это странно. Там при переходе из одного в другое начинаются проблемы у людей и так далее. В общем, я думаю, очень много
Speaker A
всего. Это касается политики там зарплат, всяких там других бенефитов для сотрудников, касается всяких внутренних политик по конфиденциальности работе с каким-то комплаенсом и так далее, и всего остального касается, и закупок тоже. Вот. И это как бы понятная история, но известно, что если люди,
Speaker A
которые, как бы работа которых, в общем-то, помогать другим, начинают как бы работать в каком-то смысле на себя, они разводят ужасную бюрократию, которая как бы имеет смысл только с точки зрения вот этого вот сервисного подразделения. То есть им сказали, типа,
Speaker A
наведите порядок тут, и они все заставили всех помучиться, чтобы у них был порядок. Угу.
Speaker A
Вот. И это, ну, телега впереди лошади. И вот такое может случиться абсолютно легчайшим образом, потому что метрика неправильная, ну как бы не оптимальная для организации стоит. Сказали порядок наведите, но не сказали, что при этом не тормозите никого. Типа придумайте, как
Speaker A
навести порядок, не затормозив всех там больше, чем на 2 процента. И, в общем, вот эта вот распространённейшая ситуация, когда ты даёшь людям какую-то автономию, они начинают просто работать на себя, потому что им вообще не интересно, что там у других. И вот это
Speaker A
вот как бы баланс между тем, чтобы у людей была какая-то общая цель, и они понимали, как бы ради чего вообще всё это происходит, как бы какая-то big picture там у них была, и того, чтобы они могли принимать решения на
Speaker A
своём уровне и не делегировали, как бы не делегировали, не дефёрили это всё на верх, типа, скажите нам, как нам жить.
Speaker A
Вот этот баланс - это прямо работа. Там всё непросто. Ну мне кажется, вот то, что ты рассказал - это частный случай локальной оптимизации против глобальной оптимизации, когда какая-то маленькая функция локально оптимизирует себя, не думая о том, что она при этом создаёт
Speaker A
проблему для других. И возвращаясь к нашей теме скорости, мне кажется, это тоже очень хороший кейс, когда ты, ускоряя какой-то конкретный фрагмент или какой-то кусочек своей организации, в итоге замедляешь всю организацию в целом или весь процесс в целом.
Speaker A
И вот про это хорошая книжка Голдратта Цель, Гол по-английски, где нужно думать не о том, чтобы у тебя каждый кусочек процесса был быстрый, а тебе нужно думать о том, чтобы у тебя весь процесс был быстрым. И для этого тебе иногда
Speaker A
какие-то компоненты процесса нужно замедлять. И если теперь на метауровень выходить, то может быть в каких-то случаях тебе решения нужно принимать помедленнее, но от того, что ты это решение примешь помедленнее, у тебя в итоге весь цикл от получения сигнала с рынка до получения
Speaker A
обратной связи, насколько твоё корректирующее воздействие помогло или не помогло, займёт меньше времени. Ну про помедленнее - да, и там есть разные причины, почему да.
Speaker A
Ну, например, есть решения, которые, в которых просто очень дорого делать ошибки. Угу. И и там надо как бы получше подумать. Ну всякие там да, вещи, которые там нельзя отменить или дорого исправлять. На самом деле там это просто как бы экстремальный случай,
Speaker A
случай, когда типа вообще нельзя исправить. Ну очень много решений, которые дорого исправлять. И да, лучше типа потратить там, лучше день потерять, потом за 5 минут долететь, то есть потратить, не знаю, лишнюю неделю на принятие этого решения, чем с некоторой
Speaker A
вероятностью лишний год на то, чтобы его исправить. Такое может быть, но может быть и другое. Может быть как бы, что если плохо подумали, то потом придётся просто переделывать. Да, то есть дело не в том, чтобы типа каждое решение, э, как какое-то одно решение
Speaker A
очень долго исправлять. А в прочем, много решений плохо согласованны, и потом очень много трения. Просто всё дальше едет, скрипит ужасно и скрипит, и ничего не работает.
Speaker A
И да, типа надо собраться и подумать. Например, очень важная штука даже не в том, чтобы принять решение получше, а в том, чтобы объяснить всем, что за решение принято и почему, да? То есть не только как бы букву, но и дух закона.
Speaker A
Угу. Мы вот с этим сталкиваемся, кстати, даже в нашем маленьком код спике, там много сложных алгоритмов. И бывает такое, что кому-то, типа, не было понятно, почему вот так, ну и ты не задумался. И потом пошёл что-то делать связанное и делает
Speaker A
не то. И как бы оказывается, что вся проблема в том, что просто типа мало времени потратили на то, чтобы типа разобрать примеры, понять, просто убедиться, что человек реально понял, что тут происходит. Потому что, ну что ты как новый алгоритм придумывают, ну
Speaker A
типа не договорились. Но обратный кейс может быть, когда ты всем всё объясняешь, и в итоге всё время ты занимаешься тем, что понимаешь, что делают другие, при этом это у тебя не факт, что повышает сигнал-шум. И ты тоже можешь в итоге замедлиться. Поэтому мне
Speaker A
кажется, что всё-таки универсальная метрика, над которой стоит задумываться, если это можно, в принципе, измерить, это именно скорость прохождения сигнала.
Speaker A
Ну, опять же, что считать сигналом? То есть на самом деле, смотри, ты говоришь очень понятную вещь, да? Что типа надо использовать не прокси-метрики, а, значит, настоящую N to N метрику.
Speaker A
Всё известно про это, да? Значит, метрики, э, которые прямо самые хорошие, они обычно, во-первых, слишком медленные, они запаздывают.
Speaker A
Ну потому что ты пока там соберёшь, пока всё это сведёшь, во-первых. А во-вторых, они очень дорогие в сборе. То есть чтобы такую метрику собрать, нужно, чтобы уже там типа куча денег потратилась, уже типа всё случилось. Вот. А вместо них есть
Speaker A
прокси-метрики, да? Когда мы говорим, а давайте мы оптимизируем вот эти четыре участка и будем надеяться, что это приведёт нас к тому, что, значит, конечная метрика на самом деле получится хорошей. Хмм, вот. Это прокси-метрика, у неё есть какие-то зазоры там, значит,
Speaker A
можно её неправильно понять, можно её переоптимизировать, можно там неправильно понять вообще, какую метрику мы выбрали.
Speaker A
И это вот великое искусство, значит, управления с помощью метрик, которое которым никто не владеет идеально. Когда всегда прокси-метрики не идеальны.
Speaker A
Угу. Причём на любом уровне, да, в управлении организациями, в машин лернинге, где угодно, везде, где мы выбираем прокси-метрики вместо настоящей нашей функции оптимизации, функции полезности, да, ну, ну, никогда не бывает идеально. Всё всегда криво.
Speaker A
Ну и при этом, если ты попытаешься действительно, как ты сказал, выбрать функцию полезности, то это тоже будет не идеально, потому что тебе её будет долго дорого мерить, и пока ты её измеришь, она уже потеряет свою ценность.
Speaker A
не получится просто, да, буквально. То есть это как бы, ну, стандартная ситуация, что типа ты всегда хочешь мерить полезность как бы онлайн-метриками, в смысле прямо вот живыми пользователями. Но пока у тебя нет продукта, нет пользователей, мерить нечего. Значит, хороший продукт или нет,
Speaker A
ты не знаешь, поэтому ты не выпускаешь ничего. Да, да. На этой оптимистической ноте у нас прошёл час нашего выпуска. Мы очень медленно с тобой обсуждали тему скорости. Не знаю, смогли ли мы хоть что-то в ней обсудить, но знаем,
Speaker A
надеюсь, от наших слушателей. Пишите обязательно в комментариях, что вы про всё это думаете. Прежде чем завершить, хочу тебя спросить, были ли ещё какие-то у тебя мысли, которые ты хотел бы в этом выпуске сказать?
Speaker A
А, ну давай подумаем. Значит, что что мы вообще не обсуждали? Ну мы как-то поговорили вроде про многие механизмы замедления, да. Мы, наверное, совсем не поговорили про вещи, которые должны быть принципиально медленными и почему. Ну мы, на самом деле, мы
Speaker A
немножко зацепили там Да. Почему демократии осознанно хотят быть медленными и чем это кончается во время войны, например, там, или каких-то других кризисных ситуаций.
Speaker A
Не поговорили про это вообще. Что ещё мы не поговорили? Про А, ну про то, что бывают разные скорости на разных уровнях и вообще в разных частях организации, да. Бывает, что у тебя есть какая-то типа там быстрая часть, медленная часть. Это типа
Speaker A
о'кей, когда кто-то бежит как бы ему не мешают, а кто-то не бежит. Ну и там, как потом на дилемму инноватора всё это накладывается, когда мы пытаемся типа совместить ужас с ежом в одной организации и быстрых и медленных, значит, посадить, как всё плохо
Speaker A
кончается. Вот такое мы не обсудили. Что ещё не обсудили? Ну, можно было ещё на самом деле поговорить про то, что великие говорят.
Speaker A
Например, вот очень классная книжка на эту тему или Slack. Очень прикольная книжка про то, что для того, чтобы ускоряться, нужно думать о том, чтобы были зазоры какие-то в организации. Но давай, может быть, мы послушаем мнение наших слушателей, и если будет эта
Speaker A
интересная тема, дайте нам идею, куда ещё её поразвивать, помимо тех, которые мы сейчас перечислили.
Speaker A
Да, да, пишите нам комментарии. Да, я вспомнил ещё одну штуку про то, что люди могут замедляться из-за того, что они очень торопились, просто сами по себе. Типа ты становишься медленнее, потому что ты устал и не замечаешь этого.
Speaker A
Да, поэтому больше ошибок, да. Ну вот и вот и обсудим, если вдруг кто-нибудь захочет с нами об этом поговорить.
Speaker A
И и дослушай давай до этого момента. Спасибо большое, что были с нами. Пишите. Счастливо.
Speaker A
Спасибо. Всем пока.
Topics:скорость разработкиKotlinрелизырегулированиеGDPRмикроменеджментпринятие решенийAmazonподкаст PodlodkaГолдратт
