Хочу рассказать про два доклада, которые мне особенно понравились.
1️⃣ Доклад Артёма Арюткина о том, почему ускорять написание кода с помощью AI недостаточно.
Как мы знаем по собственному опыту, написание кода занимает только часть времени инженера. Остальное: разобраться в постановке, уже существующем коде, другой документации, с кем-то поговорить, потестить сделанное, провести код-ревью коллег, ну и, конечно, переписка и созвоны.
Последние пару лет индустрия в основном пыталась решить вопрос ускорения написания кода с помощью AI, и во многом это получилось. Но сразу появилось следующее бутылочное горлышко — код-ревью. Сейчас ускоряют его, а значит появится следующее.
Поэтому задачей руководителя становится не ускорение именно написания кода, а поиск мест, где конкретно в нашем процессе теряется время, и расшивание именно этих ограничений.
Причем определить это основываясь только на жалобах команды не всегда получится. Мне понравился пример из доклада: если разработчику приходится периодически перезапускать долгую сборку, он может вообще на это не жаловаться. Просто привыкает и начнет закладывать это время в оценку задачи.
Поэтому предлагается измерять опыт разработчиков системно: наблюдения, данные, регулярные опросы, короткие опросы после использования внутренних инструментов. И уже на основании этих данных решать, что именно имеет смысл ускорять с помощью AI.
Во второй части доклада Артём рассказывает, как выглядит целевая картина разработки с AI глазами менеджеров, и на чем планируется фокус в 2027.
✔️ Доклад стоит посмотреть, если вы занимаетесь процессами в команде, а также просто с точки зрения "интересно, куда руководители уровня CTO и CPO хотят двигать разработку".
2️⃣ Доклад Вадима Мадисона о том, как техлиду разговаривать с бизнесом и вышестоящим руководством.
Одна из главных мыслей полностью перекликается с моим опытом: ценность предложения нужно объяснять через то, что важно для человека, принимающего решение.
То есть для нас, технических специалистов, аргументами могут быть вопросы архитектуры, техдолга, сложности поддержки, но для бизнеса обычно нужно подбирать другие аргументы. Например, деньги, риски остановки процессов, влияние на пользователей и др.
Еще интересный момент доклада про изменение майндсета по мере роста руководителя. Если тимлид — это амбассадор и защитник своей команды, то чем выше уровень руководителя, даже технического, тем сильнее его фокус смещается на бизнес. Поэтому одну и ту же инициативу нельзя одинаково презентовать тимлиду и CTO: для них нужно подбирать разные аргументы, соответствующие их роли и зоне ответственности.
Еще понравилась часть про нереалистичные цели сверху. Когда такое приносят, первая реакция у технаря будет:
"Это невозможно, и сейчас я объясню почему"
Понятно, что такой ответ обычно не способствует укреплению отношений между бизнесом и разработкой 🤔
Можно и нужно посмотреть на ситуацию иначе: определить, какую проблему руководство пытается решить этими целями, и как мы можем помочь решить именно ее.
Это не означает превратиться в YES-man и подписаться под невыполнимыми обещаниями, а наоборот: разобраться в потребностях и предложить реалистичный способ приблизиться к нужному бизнес-результату.
✔️ На мой взгляд, доклад будет полезен тем, кто много общается с бизнесом: системным аналитикам, архитекторам, лидам и руководителям разработки.
На самой конфе кроме докладов было много активностей: тимлид-"техосмотр", управленческий покер, даже погребок с фирменными соленьями 🥒 В следующем году надо запланировать пойти оффлайн.
Где посмотреть записи докладов Avito.Tech.Conf:
🎞 на YouTube
💻 в VK