Всем здравствуйте. Финишная прямая онлайн-конференция управления 2026 школа менеджмента строгоплана. Александр Орлов, как ваш, как наш неизменный ведущий, неизменной ведущий конференции, рада вас приветствовать. Рассаживайтесь, пожалуйста, поудобней. У нас сейчас первые 5 минут, пока мы собираемся, я традиционно займу приветствием, расскажу немножко про конференцию, про наши программы, и потом мы включим чат, который сейчас отключен в рамках борьбы с зумхакерами, сможем с вами общаться и пойдём уже по содержанию сегодняшнего дня. И я передам слово нашему первому спикеру Саше Апозите. Коллеги, рада вас видеть. Управление 2026. О, да, спасибо, Дмитрий, за сердечко. Коллеги, у нас сегодня, видите, вернулась демократия. У нас можно отправлять разные эмоциональные реакции. Вот даже видите, когда чат не включен, можно какие-то показывать хорошие смайлы друг другу, вот, и ведущим. Да, спасибо, что делитесь. Ну что, управление 2026, а, конференция, которую мы задумывали для того, чтобы разобраться, что у нас будет происходить в двадцать шестом году. Э, как организаторы занимаемся работой с руководителями, с директорами уже 16 лет. Занимаемся обучением, занимаемся проведением разных эфиров, смотрим, с чем к нам люди приходят, пытаемся реагировать на их запросы меняющиеся. а в чём-то и остающийся прежними, потому что профессия руководителя за последние тысячи лет, ну, в целом имеет некий общий фундамент. А довольно много выпускников у нас, поэтому база насмотренности присутствует и позволяет собирать интересных, разнообразных спикеров, которые вот этого слона руководителя, профессию, руководителя и директора щупают с разных сторон. А что про нас важно знать, коллеги, если кто-то впервые присоединился, что помимо того, что у нас много выпускников из самых разных компаний, мы долго этим занимаемся, есть две вещи. которые мы постоянно держим в своём фокусе. Это практичность, полез полезность того, что мы делаем. Мы стараемся, чтобы оценка наших занятий с студентами не падала
ниже девятки по по десятибалльной шкале. Ну, потому что хочется делать хорошо, а плохо делать не хочется. Вот это то, за чем мы пристально следим. И второе - это доходимость до конца. Поскольку программа у нас у нас многомесячная, и мы знаем, что обучение некоторой роли новой профессиональной, оно занимает время. Это как тренажёрный зал. То есть нужно натренировать образ мыслей, нужно натренировать навыки, то, что AI пока что, особенно то, что касается социальных навыков, не очень умеет. А вот на это нужно время. И в наших программах обычно 90% студентов доходят до конца. Это не касается онлайн-конференций, но в в программах вот занятия, которых идут прямо сейчас, в том числе, там ребята ходят, занимаются и 90% доходит. Что это значит? Это значит, что если вы присоединитесь к какой-нибудь программе обучения стратоплана, с девяностопроцентной вероятностью вы её пройдёте и, скорее всего, вам понравится. Поэтому будем рады вас видеть. Присоединяйтесь. У нас в июне как раз стартуют очередные программы. Двадцать шестой год, э, ну, как и все предыдущие годы, он был не очень простым и будет, скорее всего, не очень простым, потому что такое ощущение, что мы проходим с вами череду кризисов, и их последствия, их эффект, они накладываются, и получается такая набегающая волна. У нас не так давно был ковид, как-то всё уже подзабыли, а он был вот повлиял на экономики. И до сих пор мировые экономики, мне кажется, испытывают эти последствия. У нас война, войны, точнее, которые не заканчиваются, возникают новые в связи с этим релокации компаний, сотрудников там и так далее. Спад в экономиках и искусственный интеллект, который пришёл к нам как технология. Где-то она разрушает те паттерны, которые были привычными, где-то не меняет, где-то ускоряет. Вот про влияние. И мы тоже много говорим в рамках нашей конференции. Наша задача разобраться при помощи наших спикеров, к чему себя готовить, как справляться с теми сложностями, которые есть прямо сейчас. И в целом вся конференция для того, чтобы вы думали про себя в профессии, применяли на себя, как это влияет на вашу карьеру и испытывали какие-то инсайты или, может
быть, получали какую-то новую почву для размышлений, что делать там в вашей конкретной реальности, потому что ни один из спикеров экспертом конкретно по вашей жизни не является. Но всё вместе, все вместе они создают вот эту некую инфраструктуру для того, чтобы полезно про себя подумать. А программа Стратоплана, коллеги, куда я вас хотел бы пригласить? А у нас их несколько. Мы расширили нашу линейку с этого лета. И первые три фокуса, они остаются прежними. Вот то, что мы делаем последние 16 лет, это позиция руководителей от тимледов до директоров, включая руководителей отделов. В июне у нас стартует то, что мы называем стартер. Это такие интенсивные пятинедельные курсы для того, чтобы получить фундамент своей профессии и перестать чувствовать себя неуверенно в роли вот того руководителя, которым вы являетесь или того, кем вы хотите стать. Вот мы специально с нашими экспертами посидели, собрали лучшее и сделали такие интенсивные программы. Поэтому, если хотите лето провести с пользой, не всё лето, а конкретно июнь и чуть-чуть июля, то будем рады вас видеть. Приходите, если знаете, кому порекомендовать. Может быть, вы как директора руководите этим ледами или рукоделами. Вот будет очень хорошо их туда направить. Поверьте, вам с людьми будет проще работать, и вам проще будет выдерживать то давление, которое сейчас создаёт внешняя среда. Кроме этого, у нас в конце июня запустится advanced management program в рамках пилота. У нас будет 3 дня, куда мы приглашаем тех, кто сейчас работает на Cevel, особенно на позициях SEO и команды SEO тоже. Команды C-level. А мы будем эмуровать такое своеобразное заседание совета директоров. Будем работать над одним кейсом, 3 дня над одним кейсом, но с включёнными, не включёнными наблюдателями для того, чтобы понять, заметить, что с вами происходит в ситуации давления, как отключаются наши наработанные механизмы, что включается и как это поправить, чтобы вы потом, вернувшись к себе в работу, могли принимать стратегические решения и тактические решения более ясно, опираясь на конкретные цифры,
факты и так далее, и так далее. Мы со Славой Панкратовым, с моим коллегой, со основателем школы менеджмент Стратопан вдвоём эту программу разрабатываем, привлекаем наших экспертов, то есть там работает прямо целая команда, и будет очень любопытно, я бы так сказал. Поэтому, если вы на Clevelevel, посмотрите, скорее всего, вам будет и любопытно, и полезно. Кроме этого, мы с июня запускаем полноценный карьерный центр, где будем учить трём отдельным профессиям. Это бизнес-тренер, это коуч и это консультант. Потому что мы сами этот путь и проходили, и сейчас до сих пор в этих ролях функционируем. И мы знаем, что если вы уже сделали какую-то карьеру в индустрии, у вас есть опыт за плечами, у вас есть экспертиза, эту экспертизу можно переупаковать и, во-первых, зарабатывать деньги, используя параллельную профессию, не уходя из найма, повышать насмотренность и обогащать и свою компанию, и свой опыт, и повышать внешнюю заметность. В общем, работать прямо на себя, как на актив. Поэтому ещё одна интересная история. Там программы четырёхмесячные для того, чтобы мы могли проработать толково все вещи. Туда же включён курс по карьере и курс по выступлениям. Поэтому эти вещи мы тоже там будем прокачивать. Что важно знать вам, как участникам конференции, это то, что на все программы Стартоплана, которые стартуют в июне, у вас есть скидка 300 евро по промокоду М300. Действие скидки ограничено, поэтому не забудьте, пожалуйста, этот промокод ввести. И до 26 апреля, сегодня у нас двацать третий, ещё есть 3 дня для того, чтобы принять решение присоединиться к программам стартоплана, которые начнутся в июне. И первый доклад сегодня Александр Апозин, наш постоянный эксперт, человек, который получает очень хорошие оценки от наших студентов. Вот мы за этим следим. И Саша, конечно, потрясающую работу делает для того, чтобы занятия были максимально практичные. Мы сегодня будем говорить про узкие места и про то, что AI ускоряет, а что на самом деле он не ускоряет. Саш, захватывай эфир, врывайся. Вот и следующие 51 минута твои. >> Спасибо, Саш.
Да, большая честь открывать четвёртый день. Мой доклад называется тема моего доклада про то, как и ускоряет код, но при этом почему компания всё равно тормозит. А рассказывать буду, наверное, в большей степени из своего опыта, из своих общения с разными коллегами. И поэтому для начала представлюсь. Зовут меня Александр Апазиди. Я более 30 лет в в IT, то есть почти всю жизнь, ну, точнее, почти всю жизнь свою я в IT прошёл путь от разработчика до руководителя проектов и IT-директора. Работал в разных индустриях и в консалтинге в EBM, и в FMCG, в NLE и в NBве, в промышленности Volvo, в автомобильной или нефтьхимической всеборе. в ритейле и так далее, и так далее. Вот. И поэтому часть моего доклада будет опираться на мой собственный опыт, который я прошёл как руководитель. Но последние, значит, полтора года, чуть уже больше, время летит. Я преподаю в Стратоплане с большим удовольствием. Спасибо, Сажа, за такую высокую оценку, которую ты мне дал и в Яндекс-Практикум. Преподаю в большей степени на программах сетево Cio руководителя отдела. А, и во многом это мне тоже даёт возможность общаться с умными людьми. И несмотря на то, что работать нами тоже интересно, решать проблемы интересно, делиться знаниями оказалось не менее интересно. Плюс это даёт возможность насмотренность с разгонять совершенно колоссальной скоростью. А у меня прошло, наверное, пару сотен звонков за последний год с разными руководителями и личными разработчиками, поэтому тоже с этим поделюсь. Как обычно, если у человека есть Telegram-канал, он сразу после имени его называет. Я чуть позже его назову, но вдруг, если вам интересно, то буду рад, если вы подпишитесь. А, делюсь там мыслями про IT-менеджмент и про управление их, и про разработку и так далее, и так далее. Да, я был программистом, я ещё помню, что такой Сис админ и что такое всё такое. И если их интересно, и Фидо даже тоже помню. Если, кстати говоря, если уж совсем про олдскулы сводить, если вы знаете первый российский квест про Петьку Василия Ивановича, вот я к нему руку приложил, я один из тех людей, которого придумал и первую команду собрал этого квеста. Но как обычно-то
бывает, что проект завершают не те люди, которые его начали, а, соответственно не я. То, что вы знаете, то, что вы видите про Петси Ивановича, это не я выпускал. Но идея и команда была та, которую я собрал, да. Поэтому, да, Алдам, привет. А о чём сегодня будет поговорим, да, четыре идеи, которые хочу донести за сегодня. Четыре мысли, четыре блока. Это почему разработчик может ускориться в три-5ть раз, а компания не ускоряется или ускоряется на несколько процентов всего лишь. Второе, где и реально усиливает поставку и ценность, а где лишь раздувает типовые метрики и которых, в принципе, эффект особых нету. Как следствие, где тех шесть самых типов организационных потерь, задержек, на которые все съедают весь этот выигрыш. Вот. И и постараюсь закончить практическими советами, субъективными советами, скажем так, от себя. Что директор конкретно может сделать для того, чтобы поток поток не тормозился? Да. Поэтому давайте начнём с первого блока. Ускоряет ли АИ или тормозит? Если целиком взглянуть вот на весь мой доклад, то он будет состоять приблизительно вот из следующего парадокса, да? То есть с одной стороны слева у нас инженеры, которые генерирую стали генерировать гораздо больше результата. Генерируется больше кодок, генерируется больше полуреквестов, генерируется больше тестов, документации, всего, чего можно больше генерируется. Но при этом, если ты на уровне темледа и смотришь на поток, то, в принципе, всё как было, так и было, да? То есть летаем как такой же, как и был. Очереди согласования всё больше и больше увеличиваются и больше утыкается. А количество стыков растёт, количество людей, которые нужно привлечь для того, чтобы что-то заработало, тоже лишь увеличивается. С точки зрения бизнеса, с точки зрения директора совсем ситуация парадоксальна. То есть мы вкладываемся в этот самый и который должен нас ускорить и трансформировать, а как написано во всём интернете, вот этот весь фомы индекс о том, что, значит, нужно успеть, успеть, иначе опоздаешь. Вот при этом деньги вложили, а ценности нет никакой, да. Поэтому любимый вопрос любого директора, где деньги, а здесь он, наверное, как как никогда такой
острый, да? То есть где где та самая окупаемость, которую нам обещали. В общем-то, поэтому и про эти темы и будем говорить. И это есть тот самый основа доклада. И как я уже говорил, а то есть моей новой должности, мои новой профессии, даже так скажу, э менторы и тренера - это а те самые встречи с разработчиками и руководителями разных отделов. Вот поэтому аа очень интересная такая, значит, очень интересные разные мнения, да? То есть, если я разговариваю с разработчиками, с теми людьми, которые всё ещё пишут код, то там слышу прямо два разных полярных мнения. То есть первое полярное мнение, что это, блин, ишка меня ускорила. Как правило, это говорят такие прямо независимые предприниматели, ребята такие серийные, которые там по 10 стартапов у них за плечами и раз в неделю что-то выпускают. У меня есть такой один знакомый, раз в месяц он что-то начёт обязательно должен выпустить. У него прямо даже такой кипя есть раз в месяц по а проекту. Вот при этом ещё раз это люди это не не какие-то джуны или медлы, это синьоры с годами опыта разработки. То есть те люди, которые сотни тысяч срок кодали руками своими стали миллионы. А и поэтому они всё равно переключились на эту их разработку. Вторая вторая группа людей, не менее сеньёрные, не менее алдовые и не менее продвинутые ребята, которые говорят, что скорее тормозит, потому что это самый быстрый способ нагенерировать кучу legси, кучу техдолга. Потом всё, что она пишет, мне приходится переписывать, да? То есть там один человек за неделю что-то навайбкодил, потом я буду 2 месяца разгребать. Вот поэтому вторая половина говорит: "Скорее тормози". То есть прямо такие вот скептики и евангелисты мне не разделяются. Если поговорить с, а, руководителями с команд, которые уже, ну, тоже в большей степени, наверное, составляют круг моего общения, то там тоже интересная картина. То есть, если смотреть на маленькие студии, там где команда там пять человек, четырепять, шесть, может быть, человек максимум, а они говорят, что Ишка нас ускоряет, и Ишка нас ускоряет тоже где-то кратно, в два, в три раза. Прямо говорят, что это
прямо то, что то, что происходит, да. Недавно с одной геймстудией разговаривал, они, значит, полностью перешли тоже на её разработку и говорят, значит, чтобы по-другому мы бы не успели ни картинки рисовать, ни сценарии делать, ничего этого делать. При этом, если разговаривать с Бектехом, а их с компаниями, например, где-то там тысячи человек недавно был такой разговор, и коллега говорит, что мы ускорились, ну, максимум на 10%, и то ещё не факт, потому что, может быть, это и не 10% вовсе. Замерить мы не можем, а мы не уверены, и, может быть, мы желаемодаёмся действительно такой visual thinking, да? То есть, может быть, это и не факт, потому что мы вкладываемся очень сильно и очень много сил тратим на ускорение через и на иицию. Не знаю, как правильно назвать это направление. Вот. Но эффекта не видим. Поэтому, если это сложить, э, на такую вот буквально картинку из трёх, э, разов из из трёх колонок, да, то есть разработчик ускоряется в три-5ять раз, команда в два-три раза, организация большая в 10%, кудато всё девается. То есть поэтому вывод здесь совершенно очевидный и понятно, что масштаб съедает весь локальный выигрыш через согласование, через стыки зависимости между людьми и отделами. То есть это то же самое, что происходит при масштабировании любой эти системы, когда старая архитектура ломается, при увеличении организации, когда старая архитектура ломается. Ну, видимо, здесь такая же самая идея о том, что при увеличении организации весь этот выигрыш ОТИ куда-то девается и, а, как как сквозь пальцы пролезает. При этом, если добавить контекста и если раньше, например, там полтора года назад или там даже год назад в там январе-феврале прошлого года всех спрашивать ещё даже про вайп-кодинг значит не был придуман такой термин, да, и и как разработку использовало достаточно мало людей. В основном это были какие-то купайлы, это какие-то небольшие эксперименты. Вот. То сегодня это уже 90% так или иначе его используют. То есть нету почти среди тех, с кем я разговариваю, почти нет никого, кто бы не сказал бы, что мы так или иначе не используем яишку в работе. в среднем 1-2 часа в день. И средняя задача - это кодревью, документация, тесты, аналитика. Да, даже появилась
обратная задача, когда нужно спеку, которую через погнали через июшку, обратно вернуть промпт, чтобы понять, что на самом деле там человек имел в виду, да. Вот. То есть здесь вывод такой, что здесь не стоит вывод внедрять, не внедрять. То есть все уже так внедрили. То есть вопрос теперь как получить выгоду от того, что у нас происходит и то, как оно дальше будет делаться. Для этого предлагаю посмотреть на два отчёта. А есть, ну, я уверен, что, наверное, в этой аудитории почти все знают про эти отчёты Доры. Они ежегодно выпускаются. В 2024 году было 10 лет, то есть уже больше 10 лет выпускаются эти отчёты. Это отчёты. Они подводят итог тому, как прошёл год в индустрии, а разработки, насколько быстро команды стали работать, насколько больше ошибок стало, насколько всё, ну, в принципе, куда идёт индустрия, да, и что особенно ценное, что можно даже свою компанию прочекать. Поэтому, если вдруг вы, а, про Дору не используете, то вот сайтик dora.dev, там можно зайти и проверить, в том числе, свою компанию по метрикам, сравнить себя с друзьями по индустрии и и в целом по отчётам. Так вот, в 2024 году был очень интересный такой парадокс. То есть мы, в принципе, все ожидали, что Иишка наконец пришла, и теперь мы теперь мы заживём. Я имею в виду мы как разработчики, как IT-индустрия. Вот будет быстрее писаться код, будет быстрее поставка, да, поэтому давайте все срочно покупать копайлоты. Это прямо был такой такой в своё время тренд. Значит, давайте срочно их понакупим. Вот. Но при этом, так как дора измеряет именно время поставки, вре именно скорость и, э, стабильность, э, удивительное дело, что в 2024 году аа производительность output снизилась, да, а и нестабильность тоже, ну, нестабильность выросла, да, то есть поэтому а такой э качество и качество упало, и скорость упало. Вот поэтому вывод был такой, что ээ АИ даёт локальный выигрыш, но пропуская способность падает. И и ещё и ошибки
заключаются в 2025 году, если мы этот же самоотчёт посмотрим, который теперь ещё даже и назван, что там, э, брендирован как, э, разработка через Ии, да, то есть пропонако выросла по сравнению с прошлым годом, но но нестабильность тоже выросла, то есть количество ошибок стало ещё больше. То есть это что, какие выводы мы здесь делаем, что команды-таки научились как-то использовать и эффективнее для того, чтобы пропускную способность увеличивать, а так как стали инструменты более способными, стали появились агенты и так далее, и так далее. Но интегрировать это в свои процессы команды так и не научились, поэтому, собственно, оно это так и происходит. А, и это, в общем, не не парадокс. То есть те, кто читал книжку Голдретон, мгновенно, наверное, узнают эту схему с узким местом, с дорогой, где слева у нас пробка, справа, а, пустая дорога, несмотря на то, что, значит, хотя бы одна полоса должна была быть занята. И у Голдрота есть замечательная цитата в этой же книжке цель, что час экономленный не в узком месте мараж, а час экономленный в узком месте ускоряет всю систему на целый час. А, и из этого можем сделать вывод, что раз мы ускоряем разработку, ускоряем, ускоряем, но компания не ускоряется целиком, то, скорее всего, мы ускоряем не в узком месте, да, то есть, скорее всего, мы где-то в другом месте переместилось узкое место, и теперь нужно ускорять что-то другое. А можем это проверить на базовых расчётах, то есть, если даже Голдрото не верим, то простая математика, да? То есть, если почему, откуда берутся эти три-пять раз, про которые я говорил до этого? Если разработчик сам по себе разработчик и ни с кем не зависит, то у него время кодирования занимает 20%. Остальные 20% - это там перекуры, кофе и всё остальное прочее, что с разработкой не связано. При этом, если а кодированию ускоряется в пять раз, то та то, что раньше занимало 80% времени разделить на пять, будет 16%. А, собственно, выигрыш в те самые три-пять раз, да, которые мы про которые человек и говорит. То же самое и с командой. То есть, если команда небольшая, независимая студия, как я говорил, значит, ээ важный контекст, что
она независимая, у неё нету никаких, а, энтерпрайзных обвесов, да, которые она должна выполнять нормы, всё с этим связано, то у неё кодирование занимает 60%, остальное 40%. Ускоряем 60 в 5 раз, получаем 12%, то есть разница 48% те самые два раза, про которые а народ и говорит, что их ускоряет. То есть это чисто получается арифметика. Ну и такая же арифметика получается и для организации. Для организации кодирования совсем мало занимает времени, как мы знаем. И это тоже многочисленно проводились исследования. Если кто-то вдруг был на стратоплан B2B конф в январе, который проходил, там у меня был доклад, тоже про это говорили, эту тему изучали, от 10 до 20% в среднем по больнице занимает кодирование, да, то предположим, 15, э, и мы эти 15% ускоряем в три раза, получаем 3%. Ну, то есть вот те самые 12%, 10-12% - это де-факто тот максимум, на самом деле, который можно ускорить иишкой, э, существующую организацию. Поэтому здесь, наверное, вывод номер один для директора. Если не менять ничего, просто заменить инструменты, то максимум, который вы сможете достичь, скорее всего, этот потолок, эти самые 10% и есть. Может быть, иногда чуть больше, в зависимости от него того, насколько запущена ситуация была до этого или насколько она была оптимальна, да. Поэтому то цифры получаются, что не такие уж и удивительные, а совершенно чётко подтверждаются математикой. Этой же математикой подтверждае же математику подтверждает исследование другое. То есть если не верить Гуглу, точнее Google Cloud, который спонсирует Эдора тусовку, которая пишет эти отчёты, значит, если поверить Атласиону, который проводит ежегодное исследование Developer Experience, то за двадцать пятый год, а они спросили у разработчиков, сколько времени вы экономите с помощью EИ в неделю. И тут удивительная вещь, то есть тут, например, те самые 24%, которые говорят, что мы в разы ускоряемся, это, видимо, те люди, с которыми я чаще общался. Но в целом 68% разработчиков говорят, что мы экономим больше, чем 10 часов в неделю на своей работе с помощью инструментов.
А куда они уходят? В этом же опросе есть и другая их инфографика. Они уходят на согласование, да? То есть сколько времени вы тратите на согласование и на все задачи, связанные с нон-кодингом. А тоже половина народа говорит, что больше чем 10 часов. Те же самые, да? То есть тут ту тоже получается та самая брутальная правда, которая ээ с которой мы начали, что 10 часов заработали, 10 часов потратили на согласование, на стыки и на всё такое, что в организации связано. Поэтому это и есть тот самый ответ. Поэтому, подводя здесь общий итог к этому всего этого блока, что код ускорился, старые старые задержки, то, что мы раньше не считали узким местом, ну, то, что мы считали, например, ну, о'кей, там повстречались раз в неделю, обсудили приоритеты, это нормально, так и должно быть, потому что всё равно Battlnк у нас в разработке, да. Вот теперь Battlнек сместился, теперь вот те самые еженедельные встречи, например, или ежемесячные встречи стали слишком редкими. И именно теперь это тормозит весь поток. Узкое место сместилось. Поэтому, в общем-то, выводы здесь для директора такой, что теперь а скорость разработки перестала быть задачей разработки. Теперь скорость компании или операционная модель компании стала частью быть задачей директора, в принципе, как она всю жизнь была. И это, наверное, будет тоже один измотивов моего доклада сегодняшнего, потому что всё, что я говорю, это мало из этого будет такой вид какой-то новостью. Это всё хорошо проверенная классика, как тот же Голдерт, да? Вот и поэтому у Голдерата написано, что с узкими местами нужно бороться. Вот пять шагов, а как нужно бороться с узкими местами, найти ограничение, максимизировать его отдачу, подчинить всё остальное, расширить ограничение, повторить. То есть теперь работа директора, собственно, и есть эти самые пять шагов, особенно последние последние два именно там расширить ограничения и повторить, потому что теперь систему мы перебалансируем, перестраиваем совершенно заново. И, скорее всего, те процессы, о которые мы знаем сегодня - это совершенно не те процессы, которые будут завтра в каждой конкретной организации.
Вот на этом а первая часть моего спича закончена. Перехожу ко второму. То есть, собственно, как искать эти самые узкие места и что мне с ними делать, и как вообще с этим относиться. Да, здесь буду использовать статью аа 2003 года от Гергия Ореса и Кентебека. Кентбек, если кто не знает, это один из подписантов Ажайл Манифеста, создатель экстремального программирования. Вот он. Значит, это моя кошка мимо проходит. Она мне помогает обычно либо слева, либо справа. Вот они предложили использовать четыре уровня метрик. А от effort до импакта, то есть те метрики, которые можно померить, что делал каждый конкретный человек, это effor, да, то есть, например, сколько строк кода написано, сколько пиаров произведено, сколько фич закрыто и impact - это то, чего мы добились в конкретной организации. Эти метрики правые две метрики гораздо сложнее померить, потому что а они не индивидуальные, они командные, и на них уже каждый человек не может повлиять. И более того, в IT - это гораздо сложнее, чем чем в какой-нибудь Солзах. Как раз в своей статье Кент и Грег, они приводят пример, что селзам, например, им гораздо сильно легче стало. И они, а, слс обычный обычный торговый представитель, обычный продажник, может сказать: "Я сделал столько-то звонков, столько-то сделок у меня в ледах, столько-то сделок я заключил в на вум такой-то финансовый результат я принёс в организации за последний квартал". То же самое с айтишником и конкретным фичой сделать достаточно сложно. Вот. Но их основная идея была в том, что всё-таки давайте переходить, искать, как наша организация может измерять аутмы, импактметрики. А потому что именно там показана вся эффективность процесса. И один из их примеров был, что доротрики, которые, а, в том отчёте Дора, который я вот так прорекламировал, в нём есть ещё четыре известные доротрики, которыми измеряется любая организация и эффективность разработки любой организации. Они как раз относятся к ауткам и импакту, то есть тем метрикам, которые измеряют общекомандный результат. несмотря на то,
что и не позволяют каждому из сотруднику индивидуально на них напрямую влиять, да? То есть это частота поставки, это ли for changes, это сколько времени занимает у нас интеграция кода, временное установление и метрика, та, которая влияет на всю организацию, это сколько багов мы допустили в продакшн, потому что это конкретно продуктивная среда. Вот поэтому можно взять этот фреймворк как основу и найти те самые и аутмы, им impactтрики, которые помогут нам измерить перформас наших организаций. Если нет идей, какие использовать, то можно те самые дорометрики и использовать. А для того, чтобы их найти и посмотреть, как есть замечательные упражнения. В принципе, на самом деле, да, всё, что я рассказываю, мы, а, тоже порекламируем, значит, слонов стратоплана и курсов. Это большая часть из этого это в том числе взята из уроков стратоплановских. И мы это разбираем и про узкие места, и как делать wellстпing. Так вот, в том числе стремеaming - это упражнение по разбору того, как наш процесс устроен и сколько времени где мы тратим на этом на этом процессе. Вот. С одной стороны может показаться достаточно сложным с первого раза и непредсказуемым, но вот на этой картинке картинка тоже взята с сайта Дора. Там есть пошаговой гид, как это сделать, это упражнение для себя. Вот нарисовано, как это может выглядеть. И здесь, что интересно, из помимо шагов процесса, которые очень хороши, есть ещё и та команда, которая за него отвечает, за этот процесс или тот человек, который за него отвечает. И сразу же видно, что на этом процессе есть аж шесть стыков. То есть, когда разработчик передаёт на кодрев релиз инженеру между командами, в том числе когда происходит тот самый долгий встречи, например, раз в 2 недели встречи Change Advisory Board, когда команда решает, какие изменения будут поставлены в протоко. Нет, целость, целых шесть стыков. Но раз шесть стыков, значит, соответственно, и как минимум в шести местах может гореть и могут э пропадать те самые часы, про которые мы говорили, куда утекает вот эта вот самоэффективность от разработки. И если на этот на этот отчёт посмотреть,
на эту картинку посмотреть так немножко более трезво и и логично, то здесь даже особо думать не нужно, потому что вот единственная встреча, единственный шаг, который занимает 2 недели, скорее всего, в него всё и упирается, и это там достаточно легко можно проверить. Поэтому, если бы я был бы автором такого флипчарта, да, то я в первую очередь бы полез смотреть, а нельзя ли эти раз-д недели встречи каким-то образом разукрупнить для того, чтобы сделать поставки почаще и тем самым больше пользы своей компании наносить. А, и ещё одна картинка оттуда же, которая показывает, почему мы, собственно, используем этот стam mapaping и почему эти метрики работают. Потому что на весь наш процесс разработки с программом обеспечения, он от планирования до деплоя. Это и есть наш value стм, то то, что мы производим. И вот эти метрики от тестирования до deploy, le time, которые lead time for changes, аloyment frequency, сколько раз мы поставляем, как быстро выходим из кризиса, да? То есть это те все метрики, они интегрированы, ещё раз, на уровне всего процесса, который происходит. Именно поэтому позволяют использовать, э, этот эти метрики для анализа. И я обещал шесть мест, где выигрыш теряется. Вот это места тоже не самые такие новые. То есть, если кто-то ожидал какие-то классику того, чтобы как что-то прорывное, что у нас случилось за последний там, не знаю, год, то вряд ли я такое расскажу. Это всё хорошо известные места. Давайте, кстати, проведём, а, да, это из DLC, в том числе. Вот, давайте проведём, а, такое небольшое голосование. Вот шесть проблем, которые могут съедать время. Вот это время на решение decision time, то есть сколько времени мы тратим на решение, время на зависимости между командами, а время на регулирование, контроль, всё, что связано со стандартами их и проверку уже готового кода, параллельные работы, переделки, значит, реворки, всё связано и платформенная команда. То есть вот если у кого-то есть боль а по этим темам, а напишите, пожалуйста, в чат-номер. Вот.
И будет интересно потом посмотреть, э, значит, какой-то, ну, понятное дело, у нас не сильно репрезентативная выборка, хотя 200 человек в эфире. А так или иначе, наверное, будет всё-таки интересно посмотреть. Вот я вижу, что двоечек очень много, да, то есть классическая штука та, которая происходит между командами. Ну, это да, кстати говоря, здесь у меня это нету. Может быть, это тоже стоило принести, это стыки, да, Ярослав пишет. Вот поэтому, а, да, я сейчас расскажу чуть подробнее про эти каждые места. Вот. Поэтому, значит, если будет интересно, продолжайте голосовать. Я обязательно чатик потом проанализирую, возможно, какие-нибудь мысли натолкнёт. А время на решение, то есть время то, которое мы тратим ещё до написания кода. Вот знаете, что есть вот это вот вечные споры, как нам сделать быстро, качественно или безопасно или всё два, или всё три, или какой-нибудь четвёртый добавится критерий. Вот если двое человек, если два архитектора спорит, у них, как правило, два мнения. Если три архитектора спорят, то между ними там три-четыре мнения появляется там коалиции. Вот при этом в споре архитекторов непонятно, кто принимает решение, поэтому они эскалируют всё наверх, а спорят на архсоветах. Э сам был неоднократно участником этих споров, в том числе и провоцировал такие споры, поэтому говорю по себе, знаю, как это происходит. Вот в итоге всё пытается куда-то уйти наверх на топ-левел, где у человека и так меньше времени на какого-то директора, который вообще не в контексте и пытаются там арбитраж у него получить. Вот в итоге бывало так, что споры продолжаются дольше, чем написать и переделать несколько раз. Да, ещё в доашную эпоху у меня несколько проектов в Суборе было, а мои команды, две команды, они, значит, собрались и пошли в бар в пятницу, потому что, наконец, споры закончились, они получили согласование на архсовете, как можно двигаться дальше, можно теперь начать писать код. Да, это заняло у них, по-моему, по 2 с 1-3 месяца, да, то есть это такой э enterprise entтерпрайз, да, как как оно было раньше. Не думаю, что сейчас сильно быстрее стало выишную эпоху, но это то время, которое явно сжирает, да. Но если раньше разработка
занимала 9 месяцев, то можно было себе позволить 3 месяца по подумать до неё, да, то сейчас, когда разработка занимает несколько недель, то это уже всё происходит. Второе, это зависимости между командами. Да, пусть ишка она хоть и есть, но если команде А нужно что-то от команды Б, команда Б занята, то здесь оно всё будет так же тормозить, как оно всегда тормозило. Иишка здесь ничего не изменит. Поэтому можно, конечно, это время измерять. Если говорять, здесь тоже можно измерять время с с путём замера количество времени, потраченного на решение, да? Здесь в замеряем количество заблокированного времени, если у нас такая статистика есть. Вот. Э, если есть, в принципе, цифровые следы в системе, там даже даже в видемейлов, переписки, джиры тикетов, то, в принципе, установить достаточно это не так уж и сложно. Опять же спросить яишку можно об этом. Вот, поэтому можно посмотреть вот эти зависимости. В зависимости а вечная боль, поэтому, наверное, про неё останавливаться не буду долго. Её и так все знают. А про IT Governance та же самая беда, большая компания, значит, нужно выполнять стандарты. И это уже о том, как проверить тот код, который написан, да? То, что мы сделали, оно соответствует правилам соответствуем компласу, соответствует нашим архитектурным принципам или мы как-то всё на руках протаскиваем или что-то ещё происходит. Здесь интересно предла хочу предложить две метрики. То есть среднее время ревью, то есть среднее время, которое код тратит на на то, чтобы быть проверенными всеми, аа посмотреть. И второе, а количество, ну, относительно процент количественных э исключений из правил. То есть здесь очень интересно, например, если вы не сможете почить исключение с правил, потому что у вас нет правил, как, например, было у меня в одной компании, где 100% решение должно было быть архитектором согласовано, прежде чем программист, э, пойдёт их делать, да, потому что не было правил, архитектор сам их просматривал, вот, то это большой сигнал, да, или если у вас правила есть, но и всё равно исключение там больше 50%, это тоже сигнал о том, что правила возможно устарели. Поэтому здесь IT Governance решается как раз-таки вводом правил и их проверками. Ишка здесь как раз может
помочь эти правила проверять и делать. Четвёртое моё, пожалуй, любимая тема и рецепт - это параллельная работа, потому что я не знаю ничего, чтобы так более убивало продуктивность, как параллельная работа и в на индивидуальном уровне, в на уровне разработчика, и на уровне команды целиком. Вот здесь можно вспомнить мантру древнюю. Значит, ну, мантру или древнюю или мантру древних, как правильно будет, пятнадцатилетней давности стопстартинг, старт финишинг из канбана. А она сегодня как никогда актуально, потому что с помощью аишки можно кучу работы открыть, кучу проектов стартовать, кучу надо начать в недоделок и потом их бросить. И это, собственно, очень быстро забьёт всю очередь и весь когнитивный ресурс команды э съест. И мо мой традиционный рецепт VIP Work and progress измерять на уровне человека, чтобы эффективность команде повысить. Но так как у нас сегодня директорская созвон, да, то здесь, наверное, я бы измерял VIP на команду, да, то есть сколько у нас каждая команда делает проектов. У меня был, а, клиент, э, ну, консалтинговый клиент, там три команды, на на три команды было 15 проектов, да. Значит, как как как можно здесь работать эффективно, мало кто знает, да? То есть поэтому оно по-другому и не получится. Reworkк, а, который съедает ускорение. Здесь вспомним с скептиков, потому что действительно Иишка достаточно, ну, код, который генерирует и выхлоп, зависит от того контекста, который ты задашь, от тех правил, которые ты задашь. Нету правил, получил, получил галлюцинацию, получил кучу ошибок, переделываешь ревок, вот, или получаешь ошибки в проде. Соответственно, это зря потраченное время. Это то опять же, где съедается большинство всех этих выгод. И платформенная команда. Значит, если всё пойдёт хорошо, если кто-то будет в Питере в июне, там будет конференция конф. Э, если всё пойдёт хорошо и мы договоримся с организаторами, меня одобрят, то у меня там будет длинный доклад на эту тему. Но платформе команды их обычно создают для того, чтобы ускорять, но не всегда доводят это дело
до конца. Вот. И бывает. Платформа на команда становится не ускорителем, а батлнеком, тормозом, потому что, например, нужно поднять новое окружение, нужно поднять, не знаю, новую виртуальную машину, что угодно. Вот команда обращается в платформе на команду, ждёт там по 2-3 недели, пока её запрос выполнят. И, собственно, это тоже дело тормозит, да. Поэтому здесь нужно переводить, очевидно, в SРVice и смотреть, замерять SL. Как я уже сказал, ничего из этого не было новым. Это всё хорошо забыто старое. И есть такое же хорошо забытое старое. обезболивающие таблетки директора. То есть те те лекарства, которые продаются в безрецептовном отделе директорском лежат ээ в сборнике знаний любого менеджера уже много лет. Но тем не менее они хорошо работают именно сегодня, когда узкое место ишка сдвинула их куда-то в другое место. И теперь нужно вспоминать, как это дело всё оптимизировать заново, вот подчёркивать. Поэтому а эти таблетки какие? Значит, это давать полномоченные решения, внедрять матрицы Даси. То есть если наверняка многие из вас знают матрицу RI, которая используется для выполнения, есть такая же похожая матрица Dasси Driver approver consultant informed, где мы подчёркиваем, кто является владельцем решения, кто и кто кто за него кто его генерит, кто его двигает вперёд. Вот. И заодно один из главных принципов Дася, что владельцем должен быть конкретный человек, а не коллегиальный орган. То есть вместо того, чтобы говорить типа давайте на Арсаксовете обсудим там через 2 недели этот вопрос коллегиально примем решение, проголосуем, да, вопрос выдвоеть к тому, что ответственный Вася, у Васи 48 часов на решение, он должен его принять. Вот это, понятное дело, ускорит. Второе, маленькие команды, то есть и хочу напомнить, что маленькие команды уже сейчас показывают, что, в принципе, они достаточно хорошо аа получают выхлоп от ИИ, если команда маленькая, если она независимая. И почему они получают выхлоп от ИИ? Потому что они натурально, а гораздо ближе к тем самым ауткам и импактметрикам. То есть маленькая команда, она может сразу сделать весь поток ценности от начала до
конца и продемонстрировать, что, собственно, мы достигли, да? То есть сейчас на следующем слайде чуть подробнее размечем. VIP лимиты, ну, мы про них говорили, это ограничить портфель, платформа Product, довести платформу до продукта, понять, насколько платформа окупается, насколько действительно платформа снижает когнитивную нагрузку на команды. И последнее на пожалуй самое важное - это wellму упражнение тоже, которому уж я же не помню с какого года книжка Майкла Портера, когда он первый раз про этот начал говорить про Win, вот, но тоже наверняка лет 50. вот то найти то самое узкое место и конкурентное преимущество, то, как наша компания работает, и понять, куда именно в нашей конкретной компании утекает э вот эта вся производительность, которую мы могли бы достичь. Про маленькие автономные компании очень интересный кейс, который в в интернете нашёл. Значит, руководитель Адидаса по цифровизации говорит, у него там порядка 1.000 разработчиков. Он говорит о том, что мы провели исследование, и мы увидели, что мы в тех командах, которые независимы друг от друга, злилт архитеitк, а работают. Мы достигли выигрыша скорости в 20-30%. А они это достигли путём измерения team веelлоти и количества пиаров, которые команда генерирует. И там же он гордо пишет в этом отчёте. Кстати, по-моему, цитата даже в Доро есть про этот отчёт, про этот кейс, что мы увеличили свой хэппи тайм. Сотрудники стали больше на 50%, э, времени проводить своими интересными задачами, которые не связаны непосредственно с кодированием. А я это как руководитель, может быть, немецкий, но с этим, а, с русским стилем управления перевожу так, что сотрудники получили на 50% больше времени на кофе-брейки и перекуры. Вот. И вряд ли бы я бы этим гордился так уж сильно. То есть хэппи тайм -то хорошо, но мне бы хотелось бы, чтобы это было бы какое-то конкретное время. а достигнута для компании. А, но у него там же интересный отчёт был о том, что в Адидасе большой большое внедрение САП, ну, очевидно,
немецкая компания, да, то есть САП модели всё очень сильно связано с друг другом, а поэтому там в командах САПа они не смогли использовать, найти преимущество от того, как их и может это дело использовать. Такой вот интересный кейс, да. Да. Ну, вывод, собственно, как я уже сказал, команда может генерировать импаct, но happ нужно контролировать. Вот. А дальше, собственно, перехожу к финальной секции, которую я обещал. Какие конкретные рецепты? Потому что у нас был безрецептурный отдел. Сейчас отдел такой, что принимать осторожно, значит, требуются консультации врача. Ну, то есть я здесь под врачом не не только имею в виду какого-то консультанта, а то, что я сейчас буду говорить, пожалуйста, отнеситесь с дисклеймером, что это такой общесводный опыт, и его нельзя применять просто к себе в лоб. Нужно очень подумать, та ли ситуация у вас для того, чтобы её применять. Вот. Но главная идея, которая как что делать, какие советы в для директора, что ему делать прямо сейчас, очень сильно зависит от компании, а, а точнее от того, какое узкое место в компании, а, и куда ишка бьёт, как она влияет. Поэтому я такие четыре архетипа здесь выделил. А, это IT-подразделение вне IT компании, например, производство, какой-нибудь ритейл. Э-э, как правило, там, а, есть вот это деление на IT бизнес. Терпеть его не могу, но вот эти в таких компаниях оно как часто сильно проявляется. Там есть бизнес, есть IT и так далее. И поэтому количество запросов от бизнеса всегда больше. То есть ты сделал затаску, у тебя ещё две прилетело. Оттуда же есть любимое слово влёты. Значит, значит, мы делаем что-то, появились влёты. Прямо обожаю это слово. Вот. И узкое место в такой компании, очевидно, это спрос, да? То есть чем, ну, сама факт, сам факт наличия очереди в IT- это есть узкое место, потому что он это всё тормозит и переключение параллелится и происходит. Поэтому, если мы будем расшивать это узкое место в таких компаниях, это ещё лишь больше усугубит. В энтерпрайзе это
координация, вот, и подсвечивают эту эти стыки, проблемы на стыках, что куда происходит. В IT-продукте это продуктовые компании, в них наоборот самое интересное время, наверное, сейчас, потому что Иишка позволяет выпускать больше фич, больше конкурентоспособности. Вот при этом конкуренты ровно в такой же ситуации. При этом ещё и клиенты ваши в точно такой же ситуации, если вы работаете в продуктовой компании и клиенты думают, как бы ваш продукт заместить с помощью своей, собственно, там вайб-кодинга или ещё что-то такого. И самое интересное, пожалуй, IT аутсорс - это там, где вообще смена бизнес-модели должна какая-то, на мой взгляд, влияться, потому что больше продавать идею, что мы продаём часы программистов, это уже так себе конкурентное преимущество, его очень легко копировать, ишка прямо ровно в эту область-то и бьёт. Если посмотреть подетальнее на каждый из этих блоков, идти в IT в не IT-компании, а как правило, ещё раз, то, что это я вижу, может быть, у вас другое мнение, но из того, что я вижу, это десятки проектов на десятки разработчиков. То есть, ну, нередко, когда количество проектов равно количеству разработчиков или даже больше. А у меня была одна команда, 40 человек и 90 проектов было, да? Или там, как я уже говорил, была команда из 15 человек и из 20 человек и пцати проектов. Вот, как правило, там большой Legacy какой-то там древний, да, скорее всего, это какая-то коробка переписанная там либо са 1S, CRM, MES, WMS, любые другие три буквы подставьте, которые вам больше нравятся. Какая-то небольшая кастом разработка, что-то они своё своими силами пишут. Вот при этом узкое место - это спрос, который превышает ёмкость независимо от скорости. То есть выполнишь а один проект прилетит ещё два, как змей Горрыноч. Поэтому что такое компании я бы точно не посоветовал. Это не говорить о том, что мы ура наконец-то с помощью её разработки наши 10 разработчиков начнут работать как 30 или как 50. Вот. Потому что работа прилетит на 100 разработчиков или там проектов удвоится, да? То есть поэтому здесь это совершенно
точно. И здесь мой совет, наверное, - это сократить параллельность проекто в первую очередь то самое стопстартинг,стартфинишинг. А, говорю это совершенно осознанно, потому что вот в двух кейсах, где компания консультировала, это совершенно точно помогло. А мы сократили количество проектов до двух-трёх, и они внезапно полетели, стали гораздо быстрее выполнять за то, что не закрывалось месяцами. Но очевидно, если больше делать нечего, то нужно делать те проекты, которые выбрали Фокус. А второе, если бы я сейчас бы был быти директором такой компании, я бы точно бы поощрял бы использование всяких вот автоматических штуковин и тестов, а, понятно дела, с ограниченными там гвардрейлами, с ограниченными стандартами, с ограниченными безопасностями, а на пользу бизнеса прототипирования, потому что зачастую то, что нужно бизнесу сейчас, сегодня срочно, оно потом срочно не оказывается после того, как делаешь поставку, да? Сколько раз я видел, когда прилетает срочный change request, делайте там новый отчёт, новый дашборд, что угодно, потом смотришь его использованием. Вот открывали три раза последние полгода. Поэтому, если это можно сделать, погасить такой пожар быстро и прототипом, я бы это дело бы, гасил бы. И третье, я бы расшивал бы узкое место. То есть, как правило, в таких компаниях есть там 1д-три ключевых разработчика, которые там 10 лет работают, знают всё и без них ничего не работает. Поэтому я бы этих разработчиков как раз бы подключал бы к генерации баззнаний, к тому, чтобы, э, чтобы их работы в том числе могли выполнять сначала, как сначала другие разработчики, а потом аишка, да, то есть это и документирование, и, а, вытаскивание всех вот этих вот знаний, контекстов по ограниченных условиях из их голов. Второе, это большой entтерпрайз, а, предположим, это продвинутый enterpriseй, предположим, сотни тысяч разработчиков. Предположим, они уже внедрили Agile, уже все хорошие методологии, которые можно было использовали. А, ну, например, Save внедрён, это один из фреймворков для использования в Энтерпрайзе. Team Topologistes уже внедрены платформы, уже
команды сделали уже всё, всё, всё по максимуму сделать. И здесь, очевидно, узкое место будет то, о чём я больше большая часть сегодняшнего доклада говорил. Это координация, стыки, гэпы, регуляторка. Ой, регуляторки. Что я за опечатку? А зато видно, что не Ишка генерировала слайды. Вот время решений всё то, что и не трогает. Вот. А поэтому логично здесь, что чего не делать в таких компаниях. Я бы, а, уже много раз видел метрику там AI Adoption Rate или количество токенов на разработчика или количество курсоров, поставленных на рабочих местах. я бы сдел эту медрику, вообще бы её не игнорировал, потому что если максимум, что могу достичь, как мы уже говорили- это те самые, э, 10% максимум, да, они они и так и так прийдут. Вот поэтому я бы внедрял бы через э параллельные команды, которых дал бы возможность вырастить новый процесс. Почему вырастить? Потому что вот был классный комментарий, э, про SDLC, да? Так вот, SDLC, скорее всего, в том виде, котором мы знаем, он, скорее всего, изменится, да? То есть, поэтому вряд ли он останется таким же DLC заточен под людей и под такую поэтапную разработку. В для Ишки будет совершенно другой процесс разработки софта. А и мало кто знает, какой он будет конкретно в вашей организации сейчас. Я бы дал бы возможность такой процесс вырастить какой-то новой команде, посмотреть, как у них произойдёт. А, ну и, конечно бы, перераспределил бы их 20 30% те самые капаси, которые у них высвободятся в лучшем случае, перераспределил бы их не в хэппи тайм, а в что-то полезное. То самое, что раньше мы хотели сделать, но никогда до этого уроки не доходили. То есть у нас, например, в Сиборе у нас были проекты класса D, которые такие вкусные, сладкие, хочется их сделать, но денег на них не хватает, потому что всегда что-то важное вылезает вперёд. Вот теперь как раз то, что до чего руки не доходили, можно как раз сделать. Возможно, там самое прорывное место. Вот. Ну и, понятное дело, в большом энтерпрайзе самое узкое место и самое такое скандальное место - это власть. И поэтому, если возможно поделиться полномочиями для ускорения, то нужно
делиться. То есть, если один сеньор делает работу целую команду, то у него как минимум должны быть такие же полномочия, чтобы убирать препятствия, как у Тимледа. А если Тимлид с такими командами таких синьоров делает команды, работы низких команд, у него должны быть полномочия руководителя дела для того, чтобы он мог в кёрлинге лёд делать скользким перед перед командой, которай делает, который несёт вперёд. Вот это, наверное, будет здесь IT-продукт. А такая, может быть, немножко спорная мысль, но общая идея такая, что в IT-продукте скорость - это и есть та самае конкурентное преимущество, поэтому нужно ловить ту скорость, которая даёт сейчас. И здесь, наверное, ну, не лишнее будет вспомнить другого классика, там Фредора Фредерика Брукса, который говорил, что добавление людей в команду а лишь замедляет её. Да, он правда про проекты говорил, но тем не менее вот зачастую вижу, что команды стараются расти и стараются нанимать разработчиков для того, чтобы увеличивать капасть своё. Вот мой совет этим командам: не старайтесь расти, старайтесь наоборот оставаться маленькими, юркими и быстрыми, потому что много раз уже видел, как как на на углу обходит на по срезают по кривой, значит, э маленькие юрки больших э бигбоссов, да? То есть, ну, множество примеров здесь видно. Вот поэтому логично здесь нужно смотреть за лучшими, то есть платить хорошо тем самым лучшим. по правилу Netflix я с третьего совета начинаю, а, делать то, что раньше было невозможно, проверять гипотезу за один день, потом эту гипотезу устраивать продукт. Вот. Ну и, соответственно, улучшать аэ продукт свой не только в разработку, но и в свой продукт добавлять и чуть-чуть ускорить, чтобы закончить. Осталось буквально несколько слайдов. И финальный IT outsource бизнес-модель. Тут сама бизнес-модель под угрозой, потому что часы просто разработчиков уже недостаточно продать. Вот нужно продавать что-то другое. Сами заказчики спросят: "А вы с курсором
программируете или склад-кодом или как? Почему вы берёте старые ставки за или старые нормы времени за это время?" Вот поэтому здесь идея такая, что нужно outcomeм и импакт как раз-таки это те те самые метрики, которые мы можем через которые продать. Об этом тоже Голрт писал в своей книге уже не цель один, а цель три. А вторая идея, что никакая не работает без контекста, без знаний с доменной области. Именно этим тут можно этим торговать, потому что это точно нельзя быстро купить и быстро установить. И третье, так как IT outsour IT outsource или IT-галеры, как их называют, да, наверное, одни из первых испытали на себе все прелести и плюсы, и минусы и разработки, а вполне себе можно этот опыт продавать и перепродавать. Я думаю, ещё пару-тройку лет точно это будет актуально для всех компаний. Вот. И, собственно, итоги, которые бы хотел я подвести, а что аа и она ускоряет кодирование в разы. Это совершенно точный совершенно факт. Вот при этом в большинстве компаний, где и внедрено, это перестало быть узким местом в разработке кодирования. А в больших компаниях узкое место теперь, собственно, в согласованиях, стыках и принятии решений. Чем крупнее организация, тем меньше виден выигрыш от IT. И если уже задать себе вопрос, что сделать завтра, то я бы предложил бы, наверное, самый из всех тех рычагов, которые мы обсуждали, всех тех таблеток, это well стримпин. Вот если вы ещё не сделали, то это самый важный, самый первый шаг. Если бы его сделали, то вы и так знаете, значит, где у вас узкое место и что нужно делать. Вот. И его можно делать, не обязательно делать долго и сложно. Это можно взять там какую-то фичу, отследить её время от начала до конца, посмотреть, сколько времени где было проведено. Это не займёт много времени. Это там пару-тройку часов займёт, но зато понимание будет гораздо больше. Вот. А закончить хотел бы такой метафорой. В своё время в метро, когда мы оптимизировали процессы в ритейле, была использована метафора трубы с
дырками. Вот мне кажется, на сегодня такая же труба с дырками, через которую эффективность вытекает, вполне себе актуально. Поэтому, наверное, на этом я хотел бы закончить. И если есть вопросы, то готов ответить. И если есть желание, значит, приглашаю в подписчики своего канала или связываете в Телеграме, можем обсудить. Вот. Спасибо, Маргарита. Очень приятно. Я наконец могу на чатик посмотреть. Вот, >> да, Саш, спасибо. На самом деле не так много вопросов было. Вот. Но я давай зачитаю то, что я заметил. Вопрос от Влада. А зачем это не незаменимым опытным разрабам? Они что, дураки тренировать себе замену в виде искусственного интеллекта и последующее снижение дохода для них? Про человеческое сопротивление такой вопрос как бы >> здесь вопрос не я уверен не я первый, кто говорит это эту фразу. Аэ угроза этому разрабу опытному не от искусственного интеллекта исходит. Угроза опытному разрабу исходит от того, от другого опытного разраба, который использует иску искусственный интеллект. То есть она от человека с искусственным интеллектом исходит. Поэтому если не ходишь, не хочешь это тренировать, ну вот вернусь на этот слайд, 90% всё равно так или иначе уже используют. Вот поэтому это вопрос не то, что у меня есть выбор делать это или не делать. В любом случае делать. Вот и тебя заменит не искусственный интеллект, а заменит другой такой же разраб с искусственным интеллектом. >> Да. Александр пишет: "Спасибо за доклад". Есть ли дополнительные советы в вопросах установки метрик и приоритизации задач бэклога команд или портфелей проектов с учётом оценки экономического эффекта от их реализации, как фильтр, который не ускоряет процесс, скорее замедляет процесс, но делает его более экономически эффективным. Протей вопрос, как я понимаю. >> Ну так вы сами ответили, да? экономический эффект outcome и output метрики вот эти вот, ээ, ну, буквально этот самый экономический эффект ну вот вот эти две метрики эффект, который отпичи - это outc метрика в чистом виде. Вот в том числе, например, всю буримы, все проекты приоритизировали по той выгоде, которую они получат. Вот поэтому
а про Васю, которая знает 1С. О, слушайте, это это интересный код. Дмитрий, я, наверное, не на тот вопрос ответил. То есть тот вопрос, наверное, звучал так, что я посоветовал Вася, что вот тот Вася, который в э незаменимый, ему приходят и говорят: "Вася, вместо незаменимости ну-ка теперь документируй с помощью яишки". И он говорит: "Нафига мне это нужно?" Это классный кейс. Я на него не буду на этот вопрос отвечать, потому что мы на него 3 часа потратили на разбор урока, а буквально во вторник на нашем курсе руководитель отдела. Поэтому, извините, значит, как Саша говорит, покупайте наших слонов. >> Хорошо. Но вопрос от Дмитрия был. Вопрос изначальный был от Влада, по-моему. Это про легости всякого не IT-компания. Ага. >> Угу. Э, Дим, не понял вопрос. Ещё раз тогда что что начит про LEGO всякое? То есть зачем Васе вкладываться в это? Вася в это в это вкладываться, потому что >> не я мо я могу переформулировать. Ну, то есть если у нас есть LEG код и есть один там разработчик, который его там понимает и в нём шарит, вот зачем ему изучать искусственный интеллект? Вот, Дим, поправляй, если я неправильно переформулирую, >> потому что организации в очень скором времени, ну, то есть у него той Job Secкриity, ради которого он был незаменимый все эти годы, 10 лет, которые он там работал, она очень быстро исчезнет, очень скоро исчезнет, ближайшие там пару лет совершенно точно. И Вася, по идее, должен это понимать. если не понимает, то, ну, к сожалению, рынок его са сам сам по себе заменит. И чтобы Вася продолжать также спокойно работать в этой команде и стать ещё более ценным для этой команды сотрудником, ему выгоднее поделиться знаниями сейчас, да, то есть поэтому это это один из вариантов. И тут надо понять, на самом деле, почему Вася, ну, то есть я тогда давайте буду спойлерить урок, который мы во вторник проводили. Почему он незаменимый? Он такой незаменимый своей вредности, потому что он умышленно так хочет быть. Это, думаю, в меньшей степени случаев. или он незаменимый, потому что его так вынудили
сделать. Никто не хотел браться за задачи, которую он брался, и поэтому он набрался опыта. Вот. И поэтому я не исключаю второй вариант, что гораздо чаще будет случаться. Поэтому, ну, мой опыт общения с Васями. Васе, они очень счастливы, когда к ним приходишь и говоришь: "Вась, я тебя разгружу". >> Принято. Вопрос от Павла. Оценка Value EF теряет актуальность. Теперь value имеет больше вес, >> меньший. Ну, в смысле, меньше вес имеет, потому что, ну, valю стало меньше. Ой, господи, прошу прощения, Павел. Ээ, вечер туплю. Конечно, имеет большей вес, эффорт имеет меньше вес, потому что эффорт почти схлопнулся там до каких-то там незначительных величин. Поэтому то, что раньше было неокупаемо, я говорю проекты класса Д, оно теперь проект класса D становится. Поэтому, да, value effor MVP. Проверку идеи из бизнеса можно на отдел баво изложить. Я думаю, что да, если они умеют, я бы их научил бы совершенно точно. А если не умеют, то можно возглавить это. Вот некоторые компании так и делают. Я бы так бы и делал бы. Мне более того, кажется, что бизнес-аналитики могут быть крутейшими разработчиками в будущем, потому что умеют сдавать контекст. То есть не так важен синтаксис питоно или там Java, условно, чем раньше синьоры хвалились и пониманием, как оно происходило, как возможность задать контекст. Это то, чем бизнес-аналитики всю жизнь занимались. Поэтому >> класс. А Саша просит поделиться опытом работы с локальными моделями. >> Я не поделюсь. У меня нет такого опыта. Я что-то им не доверяю. Ну я и и я повторю ещё раз, я, э, к своему счастью перестал работать в найме, да. Значит, теперь, э, имею, значит, возможность преподавать, поэтому я такой независимый весь из себя, поэтому могу использовать любые модели, которые хочу. И, ну, одно из правил, которые мне Volvo вдолбили в своё время в голову, если можешьто
купить на рынке, не делать сам, то то сделай так. То есть я я лучше за то, чтобы open клоду денежку занести, антропику. Вот поэтому >> Угу. Д. Есть ли смысл углубляться в бизнес-анализ или эта область тоже будет покрываться искусственным интеллектом? >> Э да, совершенно точно. Имеет смысл. Вот. А это фич, да? Ответ. Ну я отвечу на на ответ Павла. Да, абсолютно точно, потому что если не знаете этот подход, то, ну, начинайте вот это сделать. А эта фишка, это это лишь подтверждение моих слов тому, что я покупаю всё, что можно купить. Это Google и IPR подписка. Купите её, у вас такая же будет кнопочка. Вот она, правда фигово работает, кстати. Вот поэтому я я я ею не пользуюсь. >> Вот. Слушай, Саш, спасибо большое, что нашёл возможность к нам ещё и на конференцию заглянуть. >> Спасибо, было очень приятно. И 200 человек в онлайне, это, мне кажется, шикарно. Круто. Спасибо за >> спасибо. Спасибо тебе, коллеги. Спасибо за вопросы. Если что, обращайтесь к Александру. Вот если окажетесь в программах Стратоплана в специализациях руководителя отдела сеть или CO, то там как раз с Сашей сможете волю пообщаться, вот и поработать ещё над практичными кейсами. Саша, отпускаем тебя тогда из нашего эфира. А, спасибо тебе большое. เฮ