Transcription
Добро пожаловать обратно на подкаст «Инженерное обеспечение». С вами ваш ведущий, Джастин Рик. Этот выпуск был записан в прямом эфире на DX Annual, где к нам присоединилась Джен Сен-Пьер, старший вице-президент по опыту разработчиков и трансформации в Dell, где она руководит стратегическим [музыка] видением того, как Dell's Infrastructure Solutions Group создает, эксплуатирует и развивает, создавая бесшовный опыт для разработчиков, охватывающий от лабораторных сред до инструментов и рабочих процессов, которые обеспечивают повседневные инновации. Джен рассказывает о том, что на самом деле означает переход к разработке программного обеспечения, основанной на генеративном ИИ, и почему самая сложная часть трансформации ИИ — это не [музыка] инструментарий, а переход людей, стоящий за этим. Она делится уроками прошлых отраслевых сдвигов, от DevOps до внедрения облачных технологий, и объясняет, почему организации, которые рассматривают ИИ как простую развертку инструментов, рискуют создать страх, сопротивление и организационную нестабильность. Давайте приступим. >> Доброе утро всем. Я хочу начать с быстрой мыслительной игры для всех присутствующих, верно? Я хочу, чтобы вы представили, что это было 3 года назад, и вы заходите в кабинет вашего генерального директора, вашего ИТ-директора или вашего руководителя отдела инженерии и говорите им, что в ближайшем будущем то, как мы создаем программное обеспечение, изменится. Наша работа больше не будет измеряться тем, что команда разработчиков может предоставить, а сместится к тому, где разработчики станут оркестраторами агентов, и наши идентичные системы будут генерировать готовый к производству код, рефакторить целые репозитории, писать наши наборы тестов и объяснять устаревшие системы лучше, чем наши лучшие разработчики сегодня. Теперь я не знаю, как вы все в этой комнате, но 3 года назад меня бы просто высмеяли из офиса, и моя достоверность была бы под вопросом. И тем не менее, сегодня мы ведем именно этот разговор в этой комнате. И извините, я вчера вечером потерял голос, так что если я буду появляться и исчезать, то из-за этого. Агентное управление разработкой больше не является теоретическим, верно? Вы слышали это от всех, кто выступал сегодня на сцене. Трансформация происходит сейчас, и она происходит во всех вертикалях и во всех отраслях. И это больше, чем просто инструмент, верно? Это не просто технология, и она выходит за рамки экспериментального. Инновации и достижения, которые происходят прямо сейчас в области ИИ, меняют то, как сегодня разрабатывается наше программное обеспечение, и то, как будет протекать наша работа. И это будет в более непрерывных циклах по сравнению с дискретными передачами в том, как мы работаем сегодня. ИИ [кашляет] и агенты изменят то, как мы думаем о ценности и о том, как она создается, как будут меняться наши рабочие процессы. И самое главное для разговора, который, я думаю, мы все ведем, это то, как наши инженеры будут определять себя. И я готов поспорить, что большинство из вас уже сегодня ведут эти дебаты в своих организациях. И эти разговоры, я рискну сказать, что эти разговоры для всех вас будут одновременно захватывающими из-за возможностей, которые открывает технология с точки зрения инноваций, но также и сопровождаться опасениями по поводу того, как мы туда доберемся? И когда мы туда доберемся, что это будет означать для нашей организации? И это стратегическое изменение в каждой организации, и каждая организация [кашляет] в этой комнате должна будет определить, как это будет выглядеть для вашей организации. Теперь я приведу вам всем аргумент, что мы здесь не впервые. Мы, как организации в области разработки программного обеспечения, прошли через огромное количество изменений. И организации, которые проходят через это, — это те, кто не просто ищет лучшие инструменты. Это те, кто понимает, что технологические переходы — это на самом деле переходы людей. Но знание этого паттерна не облегчает его проживание для нас сегодня, верно? Особенно с нарративами, которые заполняют ваши организации прямо сейчас и тянут ваши команды в противоположных направлениях. Подумайте о разработчике, который научился программировать на перфокартах, верно? Они отправляли свои задания. Вы ждали. Иногда вы ждали всю ночь. А потом однажды появились терминалы. Интерактивные, мгновенные, и вдруг пришлось думать в реальном времени. Некоторые из наших разработчиков в то время не сделали этот переход. Те, кто сделал, никогда не оглядывались назад. Затем вычисления перестали быть дефицитными для наших команд. У каждого на столе была машина. И внезапно отношения разработчика с машиной стали интимными, как никогда раньше. Возникли совершенно новые категории программного обеспечения. И вместе с ними совершенно новые определения того, кто такой разработчик. Затем появился интернет и мгновенно изменил единицу доставки, верно? Вы больше не отправляли коробку, вы предоставляли услугу. Работа не уменьшилась, она расширилась до операций, времени безотказной работы и развертывания. И с этим пришла большая ответственность и большая сложность, в дополнение к большей ценности. Затем DevOps сказал: «Вы создаете это, вы это запускаете». Это был не технический сдвиг, это была культурная революция того, как мы думали о разработке программного обеспечения. И архитектура программного обеспечения начала отражать архитектуру наших команд. Таким образом, каждый раз технология двигалась быстрее, чем люди. И поэтому мы были здесь раньше. Я бы утверждал, что детали одинаковы. Паттерны имеют тенденцию следовать одному и тому же. И в каждом крупном сдвиге, который у нас был, инженерия обычно следовала этому паттерну. У нас много волнения. Затем мы переходим к высокому уровню скептицизма. Затем организация переходит к страху, что это значит? И тогда мы переходим к продуктивности. А затем мы притворяемся, что всегда делали это так, и задаемся вопросом, как мы вообще делали это раньше. Агил изменил то, как мы думали о процессе, DevOps изменил то, как мы думали о сотрудничестве в наших командах. А облако изменило владение инфраструктурой. И вот мы снова здесь, и ИИ изменит то, как будет завершаться наша работа. Десятилетиями основная атомарная деятельность разработки программного обеспечения заключалась в написании кода и считалась одной из самых когнитивно сложных работ в отрасли. Деятельность кодирования также была в значительной степени изолирована от уровней изменений. Конечно, мы могли перейти от водопада к Agile, что изменило определение единицы работы, но разработка программного обеспечения в целом считалась защищенным навыком, а разработчики рассматривались как люди с захваченными знаниями в нашей организации. И эта защита начинает растворяться. Не потому, что наши разработчики становятся менее ценными, а потому, что барьеры, которые делали их знания захваченными, устраняются. И вопрос, на который мы все должны ответить: что заполняет это пространство? Таким образом, машины могут мгновенно генерировать большие объемы кода, изучать, как работает система, и предлагать способы улучшения того, что мы построили. Это создаст напряженность в вашей организации сегодня. Я уверен, что у вас есть разработчики в вашей команде сегодня, которые спрашивают: «Меня заменяют?» И я думаю, что мы, как лидеры, спрашиваем себя: «Мы движемся слишком быстро или слишком медленно, проходя через эту трансформацию?» Когда обе стороны испытывают неопределенность, во всех наших организациях происходит что-то очень предсказуемое. Нарративы заполняют вакуум, и эти нарративы имеют тенденцию парализовать организацию. У вас будет один край, который скажет, что ИИ заменит разработчиков. У вас будет другой край, который скажет, что это просто хайп. Ничего фундаментально не изменится. Оба крайних варианта будут эмоционально удобны, и, честно говоря, оба появятся в вашей организации. Иногда вы даже увидите, как они появляются на одном и том же совещании, на котором вы сидите. И они упрощают сложность, но ни один из них не является точным, верно? ИИ не устраняет разработчиков. Он меняет то, на что они тратят свое время, что заполняет их день, как они добавляют ценность и где будет применяться их суждение. Он повышает уровень, на котором им приходится работать. Но повышение может ощущаться как очень дестабилизирующее, прежде чем оно начнет давать силу нашим инженерам. И эта фаза дестабилизации — это то, где живет управление изменениями. Если мы ее игнорируем, мы получаем сопротивление. И если мы ее решаем, мы получаем трансформацию. Теперь, если все мы в этой комнате будем рассматривать ИИ как развертку инструментов, вы слышали на сцене ранее, верно? Вы получите соблюдение, верно? Вы можете поставить галочку, вы можете посмотреть на использование, вы можете сделать все это. Если вы рассматриваете это как человеческую трансформацию, вы получите приверженность. И эти результаты не одинаковы в вашей организации. Итак, что нужно для получения приверженности, верно? Как это выглядит, а не соблюдение? Итак, я проведу вас сегодня. Я видел много организаций, которые прошли через это. Некоторые сделали это очень, очень хорошо, а некоторые потерпели неудачу. И те, кто потерпел неудачу, рассматривали это как развертку ИТ, а те, кто преуспел, рассматривали это как вызов лидерству для всех нас в этой комнате. И разница сводится к пяти вещам, о которых я вам сегодня расскажу. Это не теории, это своего рода операционные необходимости, о которых, я думаю, вам всем нужно думать в вашей организации, чтобы провести эту трансформацию. Это начинается с развития общего понимания того, почему переход к агентному управлению разработкой хорош для меня, верно? Это начинается с индивида. Если разработчики не понимают, почему происходит внедрение ИИ, они будут считать, что это связано с сокращением расходов в вашей организации. И если лидеры не понимают опасений разработчиков, они могут рассматривать это сопротивление как самодовольство своих команд. Обе интерпретации этого чрезвычайно опасны для вашей организации, верно? Общее понимание означает, что мы создаем прозрачность относительно того, почему это происходит, относительно существующих конкурентных давлений, ускорения рынка, которое это открывает, и стратегического намерения, стоящего за тем, что мы делаем. Это не санированная версия. Это должна быть реальная версия для вашей команды. Я приведу вам пример. Представьте, что две компании сегодня внедряют инструменты кодирования. Компания А говорит своим командам: «Мы внедряем это, потому что это повышает производительность». А компания B говорит: «Мы внедряем ИИ, потому что наш рынок ускоряется. Нам нужно проводить больше экспериментов, быстрее итерировать и создавать более качественные решения. ИИ даст нам возможность повысить роль инженеров в более стратегическом решении проблем». Тот же инструмент, разное представление, и я не знаю, как вы, но я бы предпочел быть в компании B, чем в компании A, при такой развертке, верно? Это вызовет совершенно другую эмоциональную реакцию вашей организации в том, как вы формулируете то, что делаете. В каждой трансформации, которую я видел, она останавливалась, потому что «почему» либо отсутствовало, либо было нечестным по отношению к команде. Люди в вашей организации могут справиться с суровой правдой того, что это означает. Чего они не хотят, так это чтобы ими управляли в процессе внедрения инструмента. Общее понимание также не означает, что все согласятся. Это будет означать, что все работают с одной и той же честной позиции реальности. Теперь часть вашего общего понимания — это четкое видение того, как выглядит будущее состояние, которого мы пытаемся достичь. Люди не сопротивляются самому изменению. Они сопротивляются неопределенности того, что это изменение означает для них, если они не видят картины того, куда вы идете, они будут сопротивляться. И в трансформации ИИ неопределенность сейчас повсюду. Поэтому лидеры, которые говорят расплывчато, думая, что они защищают свои команды, на самом деле делают обратное. В будущем наши роли в разработке не определены. Люди будут представлять себе замену, если они не понимают, как будет выглядеть их роль в будущем. Если наши карьерные пути размыты, люди будут представлять себе стагнацию в своей карьере. И если дорожная карта навыков расплывчата, люди будут представлять себе устаревание в том, что они делают. Таким образом, определяя свое будущее состояние, вы должны быть откровенны в отношении этих вещей. Четкое будущее состояние отвечает на три вопроса для вашей команды. И есть, и простите, три вопроса для вашей команды. И это те вопросы, которые ваша команда задает себе сегодня и ищет на них ответы. Какова будет моя работа? Что будет вознаграждаться в будущем? И что или кто уйдет? И последний вопрос будет неудобным. Но если вы не ответите на этот вопрос для них, они ответят на него сами. И их версия обычно будет намного хуже, чем реальная правда. Таким образом, когда люди могут увидеть себя преуспевающими в новом мире, который вы представляете, вовлеченность резко возрастает, изменение становится желанным, а не угрожающим. И поэтому я хочу начать с того, как вы думаете об этом в своей организации? И я приведу вам нетехнический пример, верно? Я собираюсь в отпуск на следующей неделе с семьей. И я хочу, чтобы вы представили, что я говорю своей семье, что мы едем в отпуск, и это будет где-то тепло. Тогда у всех у них уши навострятся. Была очень долгая зима в Новой Англии. А потом я говорю им: «Может быть, будет проточная вода, а может и нет. Мы еще не решили, как туда доберемся. Упакуйте все». Тогда моя семья становится немного менее взволнованной предстоящим отпуском со мной. Ясность имеет значение в том, как вы формулируете эти вещи, верно? Это не ново для их команд. И я уверен, что все вы были здесь раньше. И для некоторых из нас это может быть более недавним, чем для других, верно? Я приведу пример, который, я уверен, все мы можем понять, и он не связан с ИИ, но мы были здесь раньше, и это очень важно для того, как мы думаем об изменении ролей. Представьте, что вы находитесь в инженерной организации, мы объявляем, что станем продукто-ориентированными и гибкими, верно? Команды внедряют Scrum, проводятся стендапы, отслеживаются баллы историй, улучшаются метрики скорости, но права принятия решений остаются централизованными, циклы финансирования остаются ежегодными, мы их на самом деле не меняли, и релизы по-прежнему требуют одобрения руководства. Процесс изменился, но операционная модель — нет. И через 2 года вы смотрите на свои команды, и они по-прежнему работают быстрее, но они внутри той же клетки, верно? Это не провал Agile, это провал видения того, какой должна быть операционная модель и как она должна измениться. И никто не определяет, как на самом деле выглядит автономия в новом мире, верно? Таким образом, команды будут оптимизировать метрики, которые у них были, а не результаты, которых кто-либо на самом деле стремится достичь. Вы должны измерять результаты, которых вы хотите достичь. Итак, что я имею в виду под четким будущим состоянием? Я не имею в виду лозунг, верно? Не придумывайте броскую фразу, не придумывайте лозунг. Вы должны обеспечить конкретику в том, как вы об этом говорите. В контексте кодирования с помощью ИИ я приведу вам пример того, как вы могли бы это сформулировать. Вы могли бы сказать: «Разработчики будут использовать инструменты ИИ». Но лучшим способом может быть сказать: «В течение 12 месяцев мы хотим, чтобы 80% нового кода генерировалось с помощью агентных рабочих процессов ИИ. Разработчики будут тратить больше времени на определение, проектирование и проверку кода, а ревью кода будут смещаться от исправления синтаксиса к проверке дизайна». Теперь у вас есть видение, в котором люди могут себя увидеть. Им это может не всем понравиться, но они могут увидеть картину. И я хочу быть честным кое в чем. Создание четкого будущего состояния означает ответы на вопросы, которых большинство из нас иногда хочет избежать. Какие роли будут сокращаться? Какие навыки станут неактуальными в будущем? И какие священные процессы, которые у нас есть, исчезнут? Это будут трудные разговоры для всех нас. Но вот что я узнал, проходя через это: ваши команды уже ведут их. Они ведут их без вас и без точной информации о том, что это на самом деле означает. И если люди не могут представить себя преуспевающими в будущем, которое вы описываете, они подсознательно будут пытаться сохранить настоящее, потому что это то, что им комфортно. Теперь, когда у вас есть четкое видение, вам нужно обеспечить ясность в отношении ролей в этом видении. Как развиваются продуктовый менеджмент, CTO и инженерия? Размываются ли границы и нужны ли новые возможности в организации, которые нам нужно развивать? Объявление новых ожиданий без подготовки людей к их выполнению — это не просто плохое управление изменениями, это нарушение доверия со стороны нас, как лидеров, к нашей организации. Вы не можете сказать кому-то «будьте более стратегичными», не обучив его системному мышлению. И вы не можете сказать «используйте ИИ ответственно», не определив стандарты проверки, которым вы хотите, чтобы они следовали в организации. Ожидания плюс возможности плюс подкрепление того, что вы просите их сделать, должны совпадать в такой трансформации. В противном случае у вас будет тревога, замещающая мотивацию в вашей организации. Я опишу что-то, что большинство из вас либо пережили, либо видели. И я думаю, что большинство из нас в этой комнате видели это. У вас есть блестящий старший архитектор, глубокий системный мыслитель в организации, видит технические проблемы наперед и уважаем всеми в организации. Открывается вакансия директора в команде, и это кажется очевидным. Вы продвигаете их на эту должность. И через 3 месяца что-то кажется не так, верно? Они все еще глубоко погружены в pull requests, все еще участвуют в каждом архитектурном споре. Между тем, дорожные карты лишены ясности, межкомандные зависимости срываются, не проводятся беседы о производительности. Никто не потерпел неудачу в этом сценарии, но роль изменилась для индивида, и никто не переопределил ее для них. Никто не сказал, что перестать делать, какие решения теперь находятся на их уровне, и что на самом деле означал успех при переходе от индивидуального контрибьютора с глубокой системной экспертизой к роли директора. И никто не инвестировал в развитие возможностей этой новой роли для них, верно? Потому что как организация, мы иногда предполагаем, что возможности передаются с повышением или изменением должности, но это не так. И именно это происходит сейчас в масштабе с внедрением ИИ. Организации говорят разработчикам, что им нужно сосредоточиться на работе с более высокой ценностью, работать более стратегически, двигаться вверх по цепочке создания стоимости. И это правильные инстинкты. Это то, что нам нужно, чтобы они делали. Но если ИИ генерирует весь ваш черновой код, вы не просто изменили инструмент для разработчика, вы изменили его работу. И если вы не определили для них, какой вы хотите видеть эту новую работу и что она на самом деле означает для них, какие навыки она требует, как измеряется производительность в этой новой работе и как выглядит их успех, вы ничего не трансформировали. Вы просто дестабилизировали свою организацию. Стратегические изменения без ясности ролей создадут тревогу в вашей команде. Изменения ролей без развития возможностей вызовут страх среди ваших разработчиков. А развитие возможностей без ясности создает пустые инвестиции в наши команды. Все три этих аспекта должны двигаться вместе, когда вы проходите через эту трансформацию. Каждый стратегический сдвиг, который создает напряженность в ролях, если мы не определим новые ожидания явно, люди либо будут цепляться за старые определения, либо будут угадывать, какими вы хотите видеть новые определения. Теперь я хочу, чтобы вы спросили себя: когда вы проходите этот путь со своими организациями. Если бы вы спросили 10 разработчиков в вашей команде прямо сейчас, как будет выглядеть их работа через 18 месяцев, получили бы вы от всех них одинаковый ответ? И если вы не получите, если это не тот ответ, это не их проблема, это наша проблема как лидеров. Это работа, которую мы должны исправить. Теперь, при любых изменениях, связанных с людьми, одним из самых больших индикаторов успеха является психологическая безопасность, которую вы можете создать в своей команде. Внедрение ИИ потребует экспериментов. Вы слышали это сегодня утром на сцене передо мной. И эксперименты должны допускать ошибки. И с ошибками мы должны создать безопасность для команд, чтобы они могли их совершать, а затем учиться на них. И тем не менее, большинство организаций неосознанно делают обратное. Если инженеры боятся осуждения за неправильное использование ИИ, они не будут исследовать. Если они беспокоятся, что их владение ИИ будет использовано против них в оценках производительности, внедрение и сотрудничество будут разрушаться в вашей организации. И если инженеры не смогут сказать, что вывод этой модели ненадежен или этот график нереалистичен, без политических последствий, вы, как лидеры, будете работать на неполной информации. И неполная информация на уровне руководства масштабируется и увеличивает затраты на то, чтобы пройти через это. И это не просто управление изменениями и пустой звук, верно? Я приведу пример из Google. Google годами изучал, что на самом деле отличает их самые высокопроизводительные команды. И проект «Аристотель» исследовал более 180 команд. Они смотрели на стаж, они смотрели на плотность талантов, они смотрели на структуру команды, и они смотрели и сказали, что главным предиктором эффективности команды была психологическая безопасность, созданная в этой команде. Не самые умные инженеры. Те, кто чувствовал себя в безопасности, говоря. Это означает, что некоторые из самых успешных команд будут выглядеть хуже на бумаге. Потому что члены команды не будут бояться поднимать проблемы. Я использую это как: если все зеленое, вы должны быть самыми скептичными. Когда все красное, вы знаете, что получаете полную картину. И в трансформации ИИ это становится еще более критичным, потому что технология развивается в реальном времени. Этические последствия будут реальными для вашей организации, а влияние на работу сейчас эмоционально нагружено. Ставки за молчание выше, чем когда-либо прежде. Все вы должны поразмыслить над своими собственными совещаниями руководства. Если они всегда спокойны, не думайте, что у вас есть согласие. Вы должны предполагать, что у вас есть отфильтрованная картина того, что на самом деле происходит среди вашей команды. Психологическая безопасность не означает гармонию. Это означает откровенность без возмездия. Это означает, что люди могут не соглашаться без ущерба для репутации в вашей команде. И это означает, что опасения рассматриваются как данные, а не как сопротивление. Я переведу это в разработку программного обеспечения для всех нас, верно? Психологическая безопасность в конечном итоге смещает ваше обнаружение дефектов влево, не в вашем коде, а в вашем разговоре. И как лидеры, мы не строим эту психологическую безопасность, прося обратную связь один раз. Вы должны регулярно задавать себе эти вопросы. Как я недавно реагировал на плохие новости? Как я относился к человеку, который выявил риск в проекте? И действительно ли откровенность моей команды изменила решение? Или ее просто отметили и проигнорировали? И обертка вокруг любой трансформации, и очень подходящая для конференции, спонсируемой DX, — это то, как вы подкрепляете структуру и метрики. Итак, я начну с того, что спрошу вас всех кое-что. Сколько из вас до сих пор измеряют производительность разработчиков метриками, разработанными до появления ИИ? Да, все вы, верно? Потому что если мы по-прежнему измеряем строки кода, мы по-прежнему измеряем индивидуальный героизм, и мы по-прежнему измеряем скорость тушения пожаров, ИИ просто ускорит наши старые плохие привычки. Это будет быстрее, это будет в масштабе, и это будет в неправильном направлении. Этот принцип преимущественно касается организаций, и большинство организаций хотят пропустить этот шаг. Потому что это самый трудный из всех для измерения. И вы слышали это на сцене. В некотором смысле, мы пока не знаем точно, что измерять. И поэтому это может сделать это экспоненциально более сложным. Но именно поэтому это имеет наибольшее значение. Измерение строк кода — это просто, верно? У нас был этот разговор. Я уверен, что все мы здесь с DX, когда мы говорили об этом. Измерение архитектурного качества, бизнес-результатов и поддержки команд — это действительно сложно, верно? Особенно в инженерных организациях, которые десятилетиями оптимизировались под количественные метрики. Это будет самым сложным для всех нас, чтобы сделать правильно, потому что нет единого ответа, и это будет уникально для каждой из наших организаций. Но сложность — это не причина избегать этого. Это причина начать думать об этом сейчас. И ИИ сделает это измерение метрик в вашей операционной модели более сложным, а не менее. У нас теперь есть совершенно новые модели затрат и измерения потребления, которые мы должны учитывать, которых не существовало 2 года назад. Токеномика, маршрутизация моделей и затраты на рабочие процессы, о которых мы не думали 2 года назад, но думаем сегодня. И у большинства организаций пока нет для этого никаких рамок. Пробел — это риск, но одних метрик будет недостаточно. Настоящий вопрос в том, будет ли ваша операционная модель в целом подкреплять новое поведение, которое вы хотите видеть от своих команд. Отражают ли структуры управления новую модель? Финансирование ли обеспечивает новые способы работы в вашей организации? И вознаграждают ли стимулы будущее состояние или старое? Метрики и структура должны двигаться вместе. В противном случае мы просим людей измениться, пока организация остается прежней. И вот тест. Если вы завтра перестанете говорить о трансформации в своей организации, будет ли ваша структура по-прежнему стимулировать желаемое вами поведение? Если ответ «нет», у вас нет трансформации, у вас есть инициатива в вашей организации. Если ответ «да», вы создали прочные изменения в своей команде. Теперь каждый из этих принципов требует, чтобы кто-то в этой комнате пошел первым. Не после того, как стратегия будет идеальной, не после того, как инструменты будут проверены, а сейчас, пока это еще неопределенно, и это все мы в этой комнате. И как лидеры, наша роль в этой трансформации — не просто спонсировать ее. Это моделировать ее. Это рассказывать о ней, и это оставаться присутствующим в ней. Вы должны знать хорошее, плохое и уродливое от ваших команд напрямую, и вы должны пройти через это вместе с ними. Вы должны вознаграждать эксперименты, даже когда они терпят неудачу. Вы должны использовать инструменты сами, наглядно, несовершенно, честно, и это означает постоянное повествование об изменениях, а не просто объявление об этом один раз и движение дальше. Вам придется сделать карьерные пути ваших сотрудников явными, а не концептуальными. Вам придется сделать это очень конкретно для них, что это означает. Потому что разработчики тихо задают вопросы, на которые мы им еще не ответили. Они будут задавать вопросы: «Могу ли я расти здесь, не становясь менеджером? Ценится ли глубокая техническая экспертиза, если ИИ может воспроизвести мой результат? И что означает мастерство, когда инструменты меняются так быстро?» Если мы не ответим на эти вопросы намеренно, люди ответят на них сами, а лучшие из них, те, у кого есть варианты, ответят, уйдя. И для всех нас в этой комнате будет стандартным требованием оставаться эмоционально присутствующими в трансформации такого масштаба. Не просто стратегически вовлеченными, а эмоционально присутствующими для наших команд. Потому что вашей команде нужен не просто спонсор, им нужен лидер, который понимает, каково это на самом деле. И им нужно понять, что больше всего бросает вызов командам. Теперь, единственное, в чем мы все можем быть уверены, когда говорим о том, когда мы уйдем отсюда сегодня, это то, что ИИ изменит то, как разрабатывается программное обеспечение. И если не управлять этим намеренно, это изменение рискует быть интернализованным как снижение ценности наших разработчиков для организации. Когда правда прямо противоположна. Эта трансформация повысит уровень, на котором они работают, но повышение потребует намеренного управления изменениями. И организации, которые преуспеют, переопределят свои роли, переработают карьерные пути в своей организации и ре-гуманизируют инженерию. Потому что в конце концов, ИИ будет генерировать код. Люди будут генерировать направление. ИИ ускорит выполнение, а люди определят смысл того, что мы строим. И смысл по-прежнему является самой ценной системой, которую мы строим. Я закончу там, где начал. 3 года назад этот разговор положил бы конец моей достоверности в Dell. Сегодня, если его не вести, это поставит вашу организацию под угрозу. Вот как быстро это движется. Это означает, что окно, чтобы вести это намеренно, а не реагировать на него, — это прямо сейчас. Спасибо. >> [аплодисменты]