[2/2] Measuring the Impact of AI on Developer Productivity at Meta (Рубрика #AI)
Этот пост продолжение разбора отличного выступления ребят из Meta содержит инсайты, которыми они поделились с аудиторией.
1️⃣ У пользователей DevMate (внутренний аналог Claude Code или Cursor) выше среднего Meta наблюдала примерно 6–12% рост DDM (Diffs per developer per month). Это не звучит как "революция в 2 раза", но для большой инженерной организации такой прирост уже выглядит существенным, особенно если он устойчиво воспроизводится на больших массивах внутренних данных.
2️⃣ Эффект использования AI был неравномерным. Пока ИИ генерирует условные 10–30% изменений в диффе, выигрыш по времени почти не виден. А заметные улучшения появлялись, когда AI вносил более 60% кода в diff. Это намекает, что максимальный выигрыш возникает не тогда, когда AI используется "понемногу везде", а когда задача и workflow действительно позволяют передать инструменту большой кусок рутинной работы. То есть AI окупается сильнее в задачах, где можно делегировать значимый объем механического кода, а не только подсказки по мелочам.
3️⃣ Senior engineers использовали AI эффективнее, чем junior, хотя junior могли обращаться к нему чаще. Это важный анти-интуитивный момент: более частое использование не равно большему эффекту. Похоже, выигрывают те, кто лучше задает контекст, умеет проверять ответ модели и понимает, где AI стоит доверять, а где нет. В итоге, в среднем диффы синьоров содержат заметно больший процент AI‑кода, чем диффы джунов. Тезис ребят в том, что опыт, архитектурное мышление и умение формулировать точные инструкции сильно усиливают эффект от ИИ - синьор как будто просто даёт ТЗ не джуну, а модели.
4️⃣ После внедрения AI сначала может быть просадка, а уже потом рост продуктивности (J-кривая адаптации). По данным Meta наблюдается просадка продуктивности порядка 15%: люди учатся промптить, перепроверяют код, меняют привычный процесс. Уже после адаптации (через несколько месяцев) начинается устойчивый плюс к DDM и сокращение времени кодинга на дифф, что и даёт итоговые 6–12% роста выхода. Практический смысл тут простой: если компания смотрит на эффект AI только в первые недели после rollout, она может ошибочно решить, что инструмент "не работает".
5️⃣ Телеметрия показала, что инженеры меньше сидят в чатах и документах, потому что ответы и контекст получают прямо в IDE через DevMate. Из‑за этого время "coding time per diff" формально растёт, но авторы считают это хорошим сигналом: меньше дёрганья по ссылкам и мессенджерам, больше фокуса в одном инструменте.
6️⃣ Не все команды выигрывают одинаково - команды с высокой долей ML/ресёрча показывают меньший рост DDM, потому что много времени уходит на ноутбуки, эксперименты и аналитику, которые плохо отражаются в "диффах". Также DDM сильно "шумит" от праздников и внешних факторов, поэтому Meta не использует его в лоб как KPI для людей, а только как агрегированную продуктовую метрику влияния ИИ‑инструментов.
Если подводить итог, то я могу порекомендовать это видео и сопутстующие whitepaper тем, кто занимается вопросами измерения эффекта AI в разработке - это хороший методологический и практический подход к этой сложной теме.
#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes #AI #ML #Architecture #DevEx #DevOps
Этот пост продолжение разбора отличного выступления ребят из Meta содержит инсайты, которыми они поделились с аудиторией.
1️⃣ У пользователей DevMate (внутренний аналог Claude Code или Cursor) выше среднего Meta наблюдала примерно 6–12% рост DDM (Diffs per developer per month). Это не звучит как "революция в 2 раза", но для большой инженерной организации такой прирост уже выглядит существенным, особенно если он устойчиво воспроизводится на больших массивах внутренних данных.
2️⃣ Эффект использования AI был неравномерным. Пока ИИ генерирует условные 10–30% изменений в диффе, выигрыш по времени почти не виден. А заметные улучшения появлялись, когда AI вносил более 60% кода в diff. Это намекает, что максимальный выигрыш возникает не тогда, когда AI используется "понемногу везде", а когда задача и workflow действительно позволяют передать инструменту большой кусок рутинной работы. То есть AI окупается сильнее в задачах, где можно делегировать значимый объем механического кода, а не только подсказки по мелочам.
3️⃣ Senior engineers использовали AI эффективнее, чем junior, хотя junior могли обращаться к нему чаще. Это важный анти-интуитивный момент: более частое использование не равно большему эффекту. Похоже, выигрывают те, кто лучше задает контекст, умеет проверять ответ модели и понимает, где AI стоит доверять, а где нет. В итоге, в среднем диффы синьоров содержат заметно больший процент AI‑кода, чем диффы джунов. Тезис ребят в том, что опыт, архитектурное мышление и умение формулировать точные инструкции сильно усиливают эффект от ИИ - синьор как будто просто даёт ТЗ не джуну, а модели.
4️⃣ После внедрения AI сначала может быть просадка, а уже потом рост продуктивности (J-кривая адаптации). По данным Meta наблюдается просадка продуктивности порядка 15%: люди учатся промптить, перепроверяют код, меняют привычный процесс. Уже после адаптации (через несколько месяцев) начинается устойчивый плюс к DDM и сокращение времени кодинга на дифф, что и даёт итоговые 6–12% роста выхода. Практический смысл тут простой: если компания смотрит на эффект AI только в первые недели после rollout, она может ошибочно решить, что инструмент "не работает".
5️⃣ Телеметрия показала, что инженеры меньше сидят в чатах и документах, потому что ответы и контекст получают прямо в IDE через DevMate. Из‑за этого время "coding time per diff" формально растёт, но авторы считают это хорошим сигналом: меньше дёрганья по ссылкам и мессенджерам, больше фокуса в одном инструменте.
6️⃣ Не все команды выигрывают одинаково - команды с высокой долей ML/ресёрча показывают меньший рост DDM, потому что много времени уходит на ноутбуки, эксперименты и аналитику, которые плохо отражаются в "диффах". Также DDM сильно "шумит" от праздников и внешних факторов, поэтому Meta не использует его в лоб как KPI для людей, а только как агрегированную продуктовую метрику влияния ИИ‑инструментов.
Если подводить итог, то я могу порекомендовать это видео и сопутстующие whitepaper тем, кто занимается вопросами измерения эффекта AI в разработке - это хороший методологический и практический подход к этой сложной теме.
#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes #AI #ML #Architecture #DevEx #DevOps
Telegram
Книжный куб
[1/2] Measuring the Impact of AI on Developer Productivity at Meta (Рубрика #AI)
Превосходное выступление от ребят из запрещенной в России Meta, которое я пересматривал раза 3, чтобы получше разобраться со всеми деталями. Выступали Payam Shodjai (senior…
Превосходное выступление от ребят из запрещенной в России Meta, которое я пересматривал раза 3, чтобы получше разобраться со всеми деталями. Выступали Payam Shodjai (senior…
❤16🔥6⚡3
[1/2] Soviet Space Mythologies: Public Images, Private Memories, and the Making of a Cultural Identity (Мифология советского космоса) (Рубрика #Space)
Прочитал превосходную книгу Вячеслава Геровича (Slava Gerovitch), историка науки, senior lecturer MIT. Оригинал вышел в 2015 году в University of Pittsburgh Press, а русский перевод вышел в 2024 году в "Новом литературном обозрении". У этой книги интересное происхождение - автор пришел к этой теме из истории вычислительной техники: его позвали в проект по истории бортового компьютера Apollo, после чего его заинтересовало, как в СССР решали задачи управления в пилотируемой космонавтике. Дальше вопрос сместился от истории компьютеров к более общему вопросу: как распределяются функции человека и машины, кто реально принимает решения, и как дизайн корабля отражает баланс сил внутри программы. В итоге проект превратился в исследование памяти, нарративов и профессиональной идентичности инженеров и космонавтов.
Книга стала результатом 13-летней работы, что финансировалась разнообразными американскими грантами: исследование на раннем этапе шло в рамках проекта по Apollo Guidance Computer, поддержанного Sloan Foundation и Dibner Institute; затем были два проекта National Science Foundation, Fellowship in Aerospace History от American Historical Association и проект oral history, поддержанный NASA History Program. Круто, что эти гранты получилось использовать для изучения советской истории космонавтики.
Ниже основные идеи книги, которые делают книгу захватывающей
1️⃣ Автор показывает, что советская космическая мифология родилась из конфликта между секретностью и пропагандой. Публичная версия истории вычищала ошибки, аварии и неудачи и оставляла образ безупречных космонавтов на безотказной технике (миф, который развеялся во времена перестройки)
2️⃣ Центральный конфликт книги - космонавт как герой-пилот против космонавта как пассажира автоматизированной системы. Это не просто образный прием: в главах о взаимодействии человека и машины автор показывает, что спор об автоматизации был одновременно техническим, профессиональным и политическим. Иными словами, спорили не только о безопасности и control loop, но и о статусе, ответственности и праве принимать решения.
3️⃣ В книге явно показывается, что дизайн системы оказывается функцией организационной политики. По словам автора, конструкция советских кораблей отражала расстановку сил внутри отрасли; доминирование инженеров закрепило парадигму автоматического управления, а роль космонавтов во многом свелась к резервированию основных систем. Плюс на архитектуру влияла конкуренция конструкторских бюро и их патронов наверху.
4️⃣ Автор рассказывает не только про основной миф, но и о контрмифах. Он специально подчеркивает, что задача историка не просто опровергать красивую легенду, а разбирать, как она вообще собирается и зачем живет. Поэтому в книге много дневников, мемуаров, интервью и сопоставления несовпадающих версий одних и тех же событий - особенно вокруг полета Гагарина. Меня эта часть настолько сильно заинтересовала, что я купил коробку книг издательства "Космоскоп" (на многие из них ссылается автор)
5️⃣ Ну и после распада Советов началась переработка советского космоса в символ национальной идентичности - старый нарратив рухнул, но космос быстро стал удобным источником "истории, которой можно гордиться", уже в новом идеологическом и даже коммерческом контексте. Например, я смотрел с интересом фильмы "Королев" (2007), "Главный" (2015) и "Время первых" (2017).
А в продолжении я расскажу что из этого можно забрать разработчикам софта и техническим руководителям на подумать:)
#Science #SystemDesign #Architecture #Processes #History #PopScience #Engineering #Culture #Leadership
Прочитал превосходную книгу Вячеслава Геровича (Slava Gerovitch), историка науки, senior lecturer MIT. Оригинал вышел в 2015 году в University of Pittsburgh Press, а русский перевод вышел в 2024 году в "Новом литературном обозрении". У этой книги интересное происхождение - автор пришел к этой теме из истории вычислительной техники: его позвали в проект по истории бортового компьютера Apollo, после чего его заинтересовало, как в СССР решали задачи управления в пилотируемой космонавтике. Дальше вопрос сместился от истории компьютеров к более общему вопросу: как распределяются функции человека и машины, кто реально принимает решения, и как дизайн корабля отражает баланс сил внутри программы. В итоге проект превратился в исследование памяти, нарративов и профессиональной идентичности инженеров и космонавтов.
Книга стала результатом 13-летней работы, что финансировалась разнообразными американскими грантами: исследование на раннем этапе шло в рамках проекта по Apollo Guidance Computer, поддержанного Sloan Foundation и Dibner Institute; затем были два проекта National Science Foundation, Fellowship in Aerospace History от American Historical Association и проект oral history, поддержанный NASA History Program. Круто, что эти гранты получилось использовать для изучения советской истории космонавтики.
Ниже основные идеи книги, которые делают книгу захватывающей
1️⃣ Автор показывает, что советская космическая мифология родилась из конфликта между секретностью и пропагандой. Публичная версия истории вычищала ошибки, аварии и неудачи и оставляла образ безупречных космонавтов на безотказной технике (миф, который развеялся во времена перестройки)
2️⃣ Центральный конфликт книги - космонавт как герой-пилот против космонавта как пассажира автоматизированной системы. Это не просто образный прием: в главах о взаимодействии человека и машины автор показывает, что спор об автоматизации был одновременно техническим, профессиональным и политическим. Иными словами, спорили не только о безопасности и control loop, но и о статусе, ответственности и праве принимать решения.
3️⃣ В книге явно показывается, что дизайн системы оказывается функцией организационной политики. По словам автора, конструкция советских кораблей отражала расстановку сил внутри отрасли; доминирование инженеров закрепило парадигму автоматического управления, а роль космонавтов во многом свелась к резервированию основных систем. Плюс на архитектуру влияла конкуренция конструкторских бюро и их патронов наверху.
4️⃣ Автор рассказывает не только про основной миф, но и о контрмифах. Он специально подчеркивает, что задача историка не просто опровергать красивую легенду, а разбирать, как она вообще собирается и зачем живет. Поэтому в книге много дневников, мемуаров, интервью и сопоставления несовпадающих версий одних и тех же событий - особенно вокруг полета Гагарина. Меня эта часть настолько сильно заинтересовала, что я купил коробку книг издательства "Космоскоп" (на многие из них ссылается автор)
5️⃣ Ну и после распада Советов началась переработка советского космоса в символ национальной идентичности - старый нарратив рухнул, но космос быстро стал удобным источником "истории, которой можно гордиться", уже в новом идеологическом и даже коммерческом контексте. Например, я смотрел с интересом фильмы "Королев" (2007), "Главный" (2015) и "Время первых" (2017).
А в продолжении я расскажу что из этого можно забрать разработчикам софта и техническим руководителям на подумать:)
#Science #SystemDesign #Architecture #Processes #History #PopScience #Engineering #Culture #Leadership
🔥18❤11👍8👌1
[2/2] Soviet Space Mythologies: Public Images, Private Memories, and the Making of a Cultural Identity (Мифология советского космоса) (Рубрика #Space)
Продолжая рассказ об этой книге, я хотел бы рассказать про инсайты, которые у меня всплывали по мере ее прочтения с учетом моего опыта проектирования и текущего фокуса на агентизации разработки и перехода инженеров-разработчиков в иную роль, чем прежде (как когда-то пилоты-космонавты стали скорее космонавтами-инженерами).
1️⃣ Автоматизация - это не только архитектура, но и governance. Как только вы решаете, когда система действует сама, а когда нужен ручное вмешательство, вы распределяете не только функции, но и власть, ответственность и blame. У Славы Геровича это одна из центральных осей книги.
2️⃣ Если публичный нарратив расходится с операционнной реальностью, то организация теряет способность учиться (просто не замыкается цикл обратной связи). Советская космическая история в официальной версии вычищала сбои и сложность. Это хорошо для витрины, но плохо для реального цикла улучшений. Очень современная мысль для любой компании, где PR и реальность расходятся слишком сильно.
3️⃣ У тех, кто строит систему, и у тех, кто ее представляет публике, почти всегда разные стимулы. Инженеры в советской программе имели больше влияния на дизайн, но были невидимы; космонавты были публичными героями, но часто с урезанной способностью влиять на решения. Это почти классический пример про скрытые платформенные команды и публичные бизнесово-продуктовые команды.
4️⃣ Контр-нарративы - это не шум, а телеметрия. Когда автор говорит, что задача историка не только развенчать основной миф, а разбирать основания мифа, то это очень похоже на хороший incident review. В общем, нельзя верить единственной официальной версии, нужно сопоставлять логи, интервью, документы, интересы групп и то, о чем система предпочитает молчать.
5️⃣ Память - это основа культуры и базис для принятия дальнейших решений. То, что организация празднует, замалчивает и повторяет, через несколько лет становится ее архитектурным мифом. А архитектурный миф потом влияет и на найм, и на статус ролей, и на то, какие решения кажутся "естественными".
В общем, это отличная книга о том, как сложная технологическая система превращается в смесь архитектуры, власти, пропаганды и коллективной памяти. Для читателей канала она может показать, что дизайн системы, распределение ролей, управление сбоями и официальный нарратив никогда не существуют по отдельности. Я бы даже больше сказал, что это пример того, что бывает когда observability заменяют мифом.
#Science #SystemDesign #Architecture #Processes #History #PopScience #Engineering #Culture #Leadership
Продолжая рассказ об этой книге, я хотел бы рассказать про инсайты, которые у меня всплывали по мере ее прочтения с учетом моего опыта проектирования и текущего фокуса на агентизации разработки и перехода инженеров-разработчиков в иную роль, чем прежде (как когда-то пилоты-космонавты стали скорее космонавтами-инженерами).
1️⃣ Автоматизация - это не только архитектура, но и governance. Как только вы решаете, когда система действует сама, а когда нужен ручное вмешательство, вы распределяете не только функции, но и власть, ответственность и blame. У Славы Геровича это одна из центральных осей книги.
2️⃣ Если публичный нарратив расходится с операционнной реальностью, то организация теряет способность учиться (просто не замыкается цикл обратной связи). Советская космическая история в официальной версии вычищала сбои и сложность. Это хорошо для витрины, но плохо для реального цикла улучшений. Очень современная мысль для любой компании, где PR и реальность расходятся слишком сильно.
3️⃣ У тех, кто строит систему, и у тех, кто ее представляет публике, почти всегда разные стимулы. Инженеры в советской программе имели больше влияния на дизайн, но были невидимы; космонавты были публичными героями, но часто с урезанной способностью влиять на решения. Это почти классический пример про скрытые платформенные команды и публичные бизнесово-продуктовые команды.
4️⃣ Контр-нарративы - это не шум, а телеметрия. Когда автор говорит, что задача историка не только развенчать основной миф, а разбирать основания мифа, то это очень похоже на хороший incident review. В общем, нельзя верить единственной официальной версии, нужно сопоставлять логи, интервью, документы, интересы групп и то, о чем система предпочитает молчать.
5️⃣ Память - это основа культуры и базис для принятия дальнейших решений. То, что организация празднует, замалчивает и повторяет, через несколько лет становится ее архитектурным мифом. А архитектурный миф потом влияет и на найм, и на статус ролей, и на то, какие решения кажутся "естественными".
В общем, это отличная книга о том, как сложная технологическая система превращается в смесь архитектуры, власти, пропаганды и коллективной памяти. Для читателей канала она может показать, что дизайн системы, распределение ролей, управление сбоями и официальный нарратив никогда не существуют по отдельности. Я бы даже больше сказал, что это пример того, что бывает когда observability заменяют мифом.
#Science #SystemDesign #Architecture #Processes #History #PopScience #Engineering #Culture #Leadership
Telegram
Книжный куб
[1/2] Soviet Space Mythologies: Public Images, Private Memories, and the Making of a Cultural Identity (Мифология советского космоса) (Рубрика #Space)
Прочитал превосходную книгу Вячеслава Геровича (Slava Gerovitch), историка науки, senior lecturer MIT.…
Прочитал превосходную книгу Вячеслава Геровича (Slava Gerovitch), историка науки, senior lecturer MIT.…
1❤11🔥7⚡4🤔2👍1🌚1
Optimizing for Time: Dark Matter (Рубрика #DevEx)
С большим интересом посмотрел доклад с концеренции DPE Summit Карима Накада (Karim Nakad) из запрещенной в России компании Meta. Мне понравилось название, которое отсылает к космологическим теориям, объясняющим через темную материю состояние нашей Вселенной. Здесь эта метафора относится к тому, что мы часто фокусируемся на видимом спектре разработи: на улучшении IDE и ускорении сборок, но игнорируем огромные затраты времени на ежедневную рутину. Собственно, спикер называет "тёмной материей" невидимую нагрузку на сотрудкниов: чтение корпоративных чатов, стендапы, написание документации и помощь коллегам. Измерение этих скрытых активностей помогает выявить истинные причины снижения скорости работы технических команд.
Мне особенно нравится разбор метрик продуктивности Meta, про которые я говорил и в других постах, например, при разборе выступления "Measuring the Impact of AI on Developer Productivity at Meta" с этой же конференции. Но в этом выступлении этот рассказ сфокусирован именно на метриках. Отдельно отмечается, что в Meta применяют агрегированные показатели для анализа процессов, строго запрещая их использование для индивидуальной оценки инженеров во избежание накруток. Сами метрики такие
- By Tool -» TSD (Time Spent Coding per Diff): отражает время кодинга на один пулл-реквест, что позволяет инфраструктурным командам оценивать эффективность инструментов разработчика.
- By Intent -» PCT (Percent Time Coding): показывает долю чистого программирования по отношению ко всем остальным задачам, помогая сокращать количество лишних встреч. Метрика важна для продуктовых команд
- By Workflow -» WTS (Workflow Time Spent): отслеживает затраты времени в разрезе конкретного процесса (например, устранения инцидента) для поиска узких мест при переключении между системами.
- By Value -» но здесь не показали метрики, а привели метафору про карту и про движение в нужном направлении (как бы это нужное направление не измерялось)
Если говорить про подучу, то мне понравились слайды про фрагментацию дня. На слайдах видно, как день инженера распадается на десятки коротких переключений между IDE, чатом, календарём, review tools, notebook и SQL. Интересно, что Meta предлагает смотреть не только на raw coding time, но и на coding intent time - то есть считать инженерной работой не только минуты в редакторе, но и связанные с задачей походы в чат, wiki, SQL и документацию. Иначе очень легко оптимизировать не то место.
Мне показались полезными идеи для инженеров о том, что надо защищать длинные focus-блоки, группировать коммуникации, глушить некритичные уведомления и перестать думать, что "настоящая работа" происходит только внутри IDE. А руководителям полезно посчитать стоимость переключения контекста и сравнить со стоимостью медленного билда; отдельно посмотреть на фокусное время команды, структуру календаря, объём асинхронного шума и только потом уже докручивать инструментарий. Иначе можно ускорить pipeline и всё равно потерять пропускную способность команды.
#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes #AI #ML #Architecture #DevEx #DevOps
С большим интересом посмотрел доклад с концеренции DPE Summit Карима Накада (Karim Nakad) из запрещенной в России компании Meta. Мне понравилось название, которое отсылает к космологическим теориям, объясняющим через темную материю состояние нашей Вселенной. Здесь эта метафора относится к тому, что мы часто фокусируемся на видимом спектре разработи: на улучшении IDE и ускорении сборок, но игнорируем огромные затраты времени на ежедневную рутину. Собственно, спикер называет "тёмной материей" невидимую нагрузку на сотрудкниов: чтение корпоративных чатов, стендапы, написание документации и помощь коллегам. Измерение этих скрытых активностей помогает выявить истинные причины снижения скорости работы технических команд.
Мне особенно нравится разбор метрик продуктивности Meta, про которые я говорил и в других постах, например, при разборе выступления "Measuring the Impact of AI on Developer Productivity at Meta" с этой же конференции. Но в этом выступлении этот рассказ сфокусирован именно на метриках. Отдельно отмечается, что в Meta применяют агрегированные показатели для анализа процессов, строго запрещая их использование для индивидуальной оценки инженеров во избежание накруток. Сами метрики такие
- By Tool -» TSD (Time Spent Coding per Diff): отражает время кодинга на один пулл-реквест, что позволяет инфраструктурным командам оценивать эффективность инструментов разработчика.
- By Intent -» PCT (Percent Time Coding): показывает долю чистого программирования по отношению ко всем остальным задачам, помогая сокращать количество лишних встреч. Метрика важна для продуктовых команд
- By Workflow -» WTS (Workflow Time Spent): отслеживает затраты времени в разрезе конкретного процесса (например, устранения инцидента) для поиска узких мест при переключении между системами.
- By Value -» но здесь не показали метрики, а привели метафору про карту и про движение в нужном направлении (как бы это нужное направление не измерялось)
Если говорить про подучу, то мне понравились слайды про фрагментацию дня. На слайдах видно, как день инженера распадается на десятки коротких переключений между IDE, чатом, календарём, review tools, notebook и SQL. Интересно, что Meta предлагает смотреть не только на raw coding time, но и на coding intent time - то есть считать инженерной работой не только минуты в редакторе, но и связанные с задачей походы в чат, wiki, SQL и документацию. Иначе очень легко оптимизировать не то место.
Мне показались полезными идеи для инженеров о том, что надо защищать длинные focus-блоки, группировать коммуникации, глушить некритичные уведомления и перестать думать, что "настоящая работа" происходит только внутри IDE. А руководителям полезно посчитать стоимость переключения контекста и сравнить со стоимостью медленного билда; отдельно посмотреть на фокусное время команды, структуру календаря, объём асинхронного шума и только потом уже докручивать инструментарий. Иначе можно ускорить pipeline и всё равно потерять пропускную способность команды.
#Engineering #Software #Bigtech #Productivity #Management #Leadership #Processes #AI #ML #Architecture #DevEx #DevOps
YouTube
Optimizing for Time: Dark Matter
Presented by Karim Nakad (Meta) at DPE Summit 2025, an event developed and hosted by Gradle.
Visit https://gradle.com/solutions/generative-ai/?utm_campaign=dpe-summit-2025&utm_medium=social-organic&utm_source=youtube&utm_content=optimizing-for-time-dark…
Visit https://gradle.com/solutions/generative-ai/?utm_campaign=dpe-summit-2025&utm_medium=social-organic&utm_source=youtube&utm_content=optimizing-for-time-dark…
👍9🔥6❤4
Как AI меняет инженерную культуру и что это значит для тимлидов и инженеров (Рубрика #Engineering)
Именно с таким докладом я выступаю сегодня в 15:40 на конференции "Dream Teamlead" от Яндекса. Я расскажу про то, как сейчас меняются инженерные процессы и что это значит для индустрии и для условного тимлида, которому надо уметь теперь не только работать в формате Software Engineering 1.0, но и в новом формате. Круто, что у ребят будет доступна трансляция на сайте конфы
Вообще мое выступление будет состоять из четырех частей
1️⃣ Как себя чувствует индустрия
Здесь я расскажу про наше исследование AI4SDLC, которое мы проводили в конце прошлого года и которое состояло из мета-исследования и опроса в котором поучаствовала примерно тысяча респондентов со всей России. Мы хотели ответить на вопросы
- В каких задачах разработки AI используется чаще всего, а где остаётся редким?
- Как соотносятся изменения продуктивности и качества (опросы, телеметрия, эксперименты)?
- Как доверие к AI-коду связано с практиками проверки (ревью, тесты, quality gates)?
- Какие элементы процесса превращают индивидуальный эффект в командный?
Сами результаты доступны здесь
2️⃣ От классического PDLC к AI-native-разработке
Здесь я расскажу про сдвиг индустрии от классических процессов к AI-native, как это выглядит и почему происходит. Здесь я поделюсь сигналами от западных бигтех компаний, а также расскажу как мы идем примерно в эту же сторону. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
3️⃣ От AI-native-разработки к AI-native-организации
Здесь я расскажу о том, как вслед за процессами разработки начинает меняться и огрдизайн компаний. Тут опять будут сигналы от западных бигтех компаний + размышления о том, почему так происходит, какие преимущества дает и какие вопросы при этом требуется решить. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
4️⃣ Как меняется роль тимлида
В последней части я расскажу а как меняется роль тимлида при этих изменениях, ведь ему приходится теперь не просто распределять задачи - он теперь проектирует контур разработки или human-agent систему. Про это у меня пока нет статьи, но я ее обязательно напишу как follow up к этому докладу.
P.S.
В докладе у меня не хватит времени поговрить про изменения в управлении задачами, но на своем сайте tellmeabout.tech я уже опубликовал статью "От классического управления задачами в Jira к AI-native task management (на примере Atlassian и Linear)", которая рассматривает этот интересный вопрос.
P.P.S.
Если будете очно на кофне, то можете поймать меня и пообщаться, а если вы будете онлайн, то сможете посмотреть доклад в трансляции.
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
Именно с таким докладом я выступаю сегодня в 15:40 на конференции "Dream Teamlead" от Яндекса. Я расскажу про то, как сейчас меняются инженерные процессы и что это значит для индустрии и для условного тимлида, которому надо уметь теперь не только работать в формате Software Engineering 1.0, но и в новом формате. Круто, что у ребят будет доступна трансляция на сайте конфы
Вообще мое выступление будет состоять из четырех частей
1️⃣ Как себя чувствует индустрия
Здесь я расскажу про наше исследование AI4SDLC, которое мы проводили в конце прошлого года и которое состояло из мета-исследования и опроса в котором поучаствовала примерно тысяча респондентов со всей России. Мы хотели ответить на вопросы
- В каких задачах разработки AI используется чаще всего, а где остаётся редким?
- Как соотносятся изменения продуктивности и качества (опросы, телеметрия, эксперименты)?
- Как доверие к AI-коду связано с практиками проверки (ревью, тесты, quality gates)?
- Какие элементы процесса превращают индивидуальный эффект в командный?
Сами результаты доступны здесь
2️⃣ От классического PDLC к AI-native-разработке
Здесь я расскажу про сдвиг индустрии от классических процессов к AI-native, как это выглядит и почему происходит. Здесь я поделюсь сигналами от западных бигтех компаний, а также расскажу как мы идем примерно в эту же сторону. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
3️⃣ От AI-native-разработки к AI-native-организации
Здесь я расскажу о том, как вслед за процессами разработки начинает меняться и огрдизайн компаний. Тут опять будут сигналы от западных бигтех компаний + размышления о том, почему так происходит, какие преимущества дает и какие вопросы при этом требуется решить. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
4️⃣ Как меняется роль тимлида
В последней части я расскажу а как меняется роль тимлида при этих изменениях, ведь ему приходится теперь не просто распределять задачи - он теперь проектирует контур разработки или human-agent систему. Про это у меня пока нет статьи, но я ее обязательно напишу как follow up к этому докладу.
P.S.
В докладе у меня не хватит времени поговрить про изменения в управлении задачами, но на своем сайте tellmeabout.tech я уже опубликовал статью "От классического управления задачами в Jira к AI-native task management (на примере Atlassian и Linear)", которая рассматривает этот интересный вопрос.
P.P.S.
Если будете очно на кофне, то можете поймать меня и пообщаться, а если вы будете онлайн, то сможете посмотреть доклад в трансляции.
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
Dream → Teamlead
Dream → Teamlead — практическая конференция Яндекса для тимлидов, руководителей и технических лидеров. Здесь говорят не про код и фичи, а про управление людьми, принятие сложных решений и развитие здоровых команд.
❤17🔥17👍6👎3
Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году (Рубрика #Management)
В предыдущих текстах этой серии я писал, что индустрия движется от классического PDLC к AI-native разработке, а затем — к AI-native организации. В этой статье я планировал рассмотреть подходы бигтехов к организации этого перехода и постановке целей внутри организации, а также измерения результатов.
По публичным сигналам Microsoft, GitHub, Google, Amazon, Meta, Uber, Stripe и Netflix видно, что AI становится полноценным слоем инженерной операционной модели. Он встраивается в PR (pull requests), ревью кода, тестирование, миграции, триаж багов, CI/CD пайпланы и все чаще — в агентские workflow, где система не только подсказывает, но и выполняет bounded task под контролем человека.
Мерить этот переход они тоже начинают по-новому: не одной метрикой usage, которая была популярна в прошлом, а целой цепочкой adoption → throughput → quality/risk → economics. Именно эта связка постепенно становится новым языком для технических топ-менеджеров и платформенных команд. Эта четверка выглядит примерно так
1) Adoption. Насколько AI вообще вошел в повседневный контур работы, сколько активных пользователей, каков adoption агентов, как распределено использование по командам, IDE, CLI и workflow.
2) Throughput. Сократились ли cycle time на PR и ревью, что произошло с time to merge, ускорился ли путь от первого коммита до открытого PR, выросла ли инженерная velocity.
3) Quality/risk. Что происходит с полезными комментариями, обратной связью, предотвращением дефектов, обработкой дубликатов ошибок, эффективностью тестирования и частотой инцидентов (это контр-балансирующие метрики относительно скорости и througput)
4 )Economics. Сколько сэкономили часов на конкретных джобах, человеко-лет спасено при миграциях, какое значение у CTS-SW (cost to serve software от AWS), какое ROI и какова стоимость масштабирования всего этого слоя AI.
Именно такая связка всё чаще просматривается в официальных материалах GitHub, Google, AWS, Uber и Amazon..
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
В предыдущих текстах этой серии я писал, что индустрия движется от классического PDLC к AI-native разработке, а затем — к AI-native организации. В этой статье я планировал рассмотреть подходы бигтехов к организации этого перехода и постановке целей внутри организации, а также измерения результатов.
По публичным сигналам Microsoft, GitHub, Google, Amazon, Meta, Uber, Stripe и Netflix видно, что AI становится полноценным слоем инженерной операционной модели. Он встраивается в PR (pull requests), ревью кода, тестирование, миграции, триаж багов, CI/CD пайпланы и все чаще — в агентские workflow, где система не только подсказывает, но и выполняет bounded task под контролем человека.
Мерить этот переход они тоже начинают по-новому: не одной метрикой usage, которая была популярна в прошлом, а целой цепочкой adoption → throughput → quality/risk → economics. Именно эта связка постепенно становится новым языком для технических топ-менеджеров и платформенных команд. Эта четверка выглядит примерно так
1) Adoption. Насколько AI вообще вошел в повседневный контур работы, сколько активных пользователей, каков adoption агентов, как распределено использование по командам, IDE, CLI и workflow.
2) Throughput. Сократились ли cycle time на PR и ревью, что произошло с time to merge, ускорился ли путь от первого коммита до открытого PR, выросла ли инженерная velocity.
3) Quality/risk. Что происходит с полезными комментариями, обратной связью, предотвращением дефектов, обработкой дубликатов ошибок, эффективностью тестирования и частотой инцидентов (это контр-балансирующие метрики относительно скорости и througput)
4 )Economics. Сколько сэкономили часов на конкретных джобах, человеко-лет спасено при миграциях, какое значение у CTS-SW (cost to serve software от AWS), какое ROI и какова стоимость масштабирования всего этого слоя AI.
Именно такая связка всё чаще просматривается в официальных материалах GitHub, Google, AWS, Uber и Amazon..
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
Medium
Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году
В предыдущих текстах этой серии я писал, что индустрия движется от классического PDLC к AI-native разработке, а затем — к AI-native…
👍8🔥6❤4👎1
State of AI4SDLC на DevOpsConf 2026 (Рубрика #DevOps)
Завтра я открываю конференцию DevOpsConf первым докладом в главном зале и расскажу про наше исследование AI4SDLC, а также что это значит для нас как инженеров, занимающихся разработкой и поставкой софта в продакшен. Я расскажу про то, как выглядят новые процессы разработки, а также про то, как их внедряют в зарубежных бигтехах, а также как действуем мы в Т-Банке.
Вообще мое выступление будет состоять из следующих частей
1️⃣ Как себя чувствует индустрия
Здесь я расскажу про наше исследование AI4SDLC, которое мы проводили в конце прошлого года и которое состояло из мета-исследования и опроса в котором поучаствовала примерно тысяча респондентов со всей России. Мы хотели ответить на вопросы
- В каких задачах разработки AI используется чаще всего, а где остаётся редким?
- Как соотносятся изменения продуктивности и качества (опросы, телеметрия, эксперименты)?
- Как доверие к AI-коду связано с практиками проверки (ревью, тесты, quality gates)?
- Какие элементы процесса превращают индивидуальный эффект в командный?
Сами результаты доступны здесь
2️⃣ От классического PDLC к AI-native-разработке
Здесь я расскажу про сдвиг индустрии от классических процессов к AI-native, как это выглядит и почему происходит. Здесь я поделюсь сигналами от западных бигтех компаний, а также расскажу как мы идем примерно в эту же сторону. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
3️⃣ От AI-native-разработки к AI-native-организации
Здесь я расскажу о том, как вслед за процессами разработки начинает меняться и огрдизайн компаний. Тут опять будут сигналы от западных бигтех компаний + размышления о том, почему так происходит, какие преимущества дает и какие вопросы при этом требуется решить. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
4️⃣ От классического task management к AI-native: как меняется сама единица работы. Тут я расскажу про подходы Atlassian и Linear, которые практикуют разные подходы к управлению задачами и являются лидерами рынка для корпораций и стартапов соответственно. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
5️⃣ Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году. Тут я расскажу про то, как бигтехи подходят к организации этого перехода и постановке целей внутри организации, а также как они планируют измерять результат. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
P.S.
У нас есть отдельный сайт ai4sdlc.tbank.ru про наши AI решения для разработки. И мы их не только используем внутри, но и продаем крупным компаниям.
P.P.S.
Если будете очно на кофне, то можете поймать меня и пообщаться.
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
Завтра я открываю конференцию DevOpsConf первым докладом в главном зале и расскажу про наше исследование AI4SDLC, а также что это значит для нас как инженеров, занимающихся разработкой и поставкой софта в продакшен. Я расскажу про то, как выглядят новые процессы разработки, а также про то, как их внедряют в зарубежных бигтехах, а также как действуем мы в Т-Банке.
Вообще мое выступление будет состоять из следующих частей
1️⃣ Как себя чувствует индустрия
Здесь я расскажу про наше исследование AI4SDLC, которое мы проводили в конце прошлого года и которое состояло из мета-исследования и опроса в котором поучаствовала примерно тысяча респондентов со всей России. Мы хотели ответить на вопросы
- В каких задачах разработки AI используется чаще всего, а где остаётся редким?
- Как соотносятся изменения продуктивности и качества (опросы, телеметрия, эксперименты)?
- Как доверие к AI-коду связано с практиками проверки (ревью, тесты, quality gates)?
- Какие элементы процесса превращают индивидуальный эффект в командный?
Сами результаты доступны здесь
2️⃣ От классического PDLC к AI-native-разработке
Здесь я расскажу про сдвиг индустрии от классических процессов к AI-native, как это выглядит и почему происходит. Здесь я поделюсь сигналами от западных бигтех компаний, а также расскажу как мы идем примерно в эту же сторону. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
3️⃣ От AI-native-разработки к AI-native-организации
Здесь я расскажу о том, как вслед за процессами разработки начинает меняться и огрдизайн компаний. Тут опять будут сигналы от западных бигтех компаний + размышления о том, почему так происходит, какие преимущества дает и какие вопросы при этом требуется решить. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
4️⃣ От классического task management к AI-native: как меняется сама единица работы. Тут я расскажу про подходы Atlassian и Linear, которые практикуют разные подходы к управлению задачами и являются лидерами рынка для корпораций и стартапов соответственно. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
5️⃣ Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году. Тут я расскажу про то, как бигтехи подходят к организации этого перехода и постановке целей внутри организации, а также как они планируют измерять результат. На эту тему у меня есть подробная статья на моем сайте tellmeabout.tech.
P.S.
У нас есть отдельный сайт ai4sdlc.tbank.ru про наши AI решения для разработки. И мы их не только используем внутри, но и продаем крупным компаниям.
P.P.S.
Если будете очно на кофне, то можете поймать меня и пообщаться.
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
1🔥13👏3❤2
Как AI меняет инженерную культуру / Александр Поломодов (Рубрика #Engineering)
Появилась запись моего выступления на конференции Dream Teamlead, что устраивал Yandex в прошлую субботу. Я уже рассказывал про него, но кратко в нем было 4 темы
1) Как себя чувствует индустрия разработки софта в эру AI - тут анализ основан на нашем исследовании AI4SDLC 2025
2) Как мы движемся от классического PDLC к AI-native-разработке (у меня есть статья на эту тему)
3) Как AI-native-разработка приводит к AI-native-организации (у меня есть статья на эту тему)
4) Как меняется роль тимлида в такой организации (так как выступал на конференции для тимлидов, то надо было поговорить о том, а что эти изменения значат для них)
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
Появилась запись моего выступления на конференции Dream Teamlead, что устраивал Yandex в прошлую субботу. Я уже рассказывал про него, но кратко в нем было 4 темы
1) Как себя чувствует индустрия разработки софта в эру AI - тут анализ основан на нашем исследовании AI4SDLC 2025
2) Как мы движемся от классического PDLC к AI-native-разработке (у меня есть статья на эту тему)
3) Как AI-native-разработка приводит к AI-native-организации (у меня есть статья на эту тему)
4) Как меняется роль тимлида в такой организации (так как выступал на конференции для тимлидов, то надо было поговорить о том, а что эти изменения значат для них)
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
YouTube
Как AI меняет инженерную культуру / Александр Поломодов
В своём докладе на Dream → Teamlead Александр Поломодов, Technical Director & Fellow, отвечающий за AI in SDLC, Architecture, Engineering RnD в Т-Банке, разобрал исследования и актуальные тренды влияния AI на разработку. Среди новых инструментов: умные suggests…
🔥19👍7❤3👎1
Внедрение AI в организации в стиле Григория Остера (Рубрика #AI)
Недавно было первое апреля, а сегодня еще и суббота, поэтому я решил сегодня рассказать в канале про свою статью о внедрении AI в организациях по заветам Григория Остера и его книг из серии "Вредные советы". Эти книги предназначалась для непослушных детей и их родителей и в ней давались абсурдные советы, что приводили к катастрофам. Именно так в детстве я учился “от противного” как поступать правильно. Эта статья примерно в таком стиле рассказывает про внедрение AI в организацию, которое очень напоминает подход к “цифровым трансформациям” бизнеса, которые были популярны 10–15 лет назад у бизнесов, построенных не вокруг IT (условно не digital native).
P.S.
Если после прочтения статьи вы захотите испробовать альтернативный подход, то можете почитать мои статьи о том, как это стоит делать, правда в домене разработки софта (или как мы это называем AI4SDLC). Я про это много писал уже, например, можно посмотреть статьи
1️⃣ От классического PDLC к AI-native-разработке
Здесь про сдвиг индустрии от классических процессов к AI-native, как это выглядит и почему происходит. Подробная статья на моем сайте tellmeabout.tech.
2️⃣ От AI-native-разработки к AI-native-организации
Здесь про то, как вслед за процессами разработки начинает меняться и огрдизайн компаний. Подробная статья на моем сайте tellmeabout.tech.
3️⃣ От классического task management к AI-native: как меняется сама единица работы.
Здесь про Atlassian и Linear, которые практикуют разные подходы к управлению задачами и являются лидерами рынка для корпораций и стартапов соответственно. Подробная статья на моем сайте tellmeabout.tech.
4️⃣ Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году.
Здесь о том, как бигтехи подходят к организации этого перехода и постановке целей внутри организации, а также как они планируют измерять результат. Подробная статья на моем сайте tellmeabout.tech.
Серия этих статей описывают концептуальный подход, который положен в основу нашей стратегии и тактики на этот год в направлении внедрения AI в разработке внутри компании.
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
Недавно было первое апреля, а сегодня еще и суббота, поэтому я решил сегодня рассказать в канале про свою статью о внедрении AI в организациях по заветам Григория Остера и его книг из серии "Вредные советы". Эти книги предназначалась для непослушных детей и их родителей и в ней давались абсурдные советы, что приводили к катастрофам. Именно так в детстве я учился “от противного” как поступать правильно. Эта статья примерно в таком стиле рассказывает про внедрение AI в организацию, которое очень напоминает подход к “цифровым трансформациям” бизнеса, которые были популярны 10–15 лет назад у бизнесов, построенных не вокруг IT (условно не digital native).
P.S.
Если после прочтения статьи вы захотите испробовать альтернативный подход, то можете почитать мои статьи о том, как это стоит делать, правда в домене разработки софта (или как мы это называем AI4SDLC). Я про это много писал уже, например, можно посмотреть статьи
1️⃣ От классического PDLC к AI-native-разработке
Здесь про сдвиг индустрии от классических процессов к AI-native, как это выглядит и почему происходит. Подробная статья на моем сайте tellmeabout.tech.
2️⃣ От AI-native-разработки к AI-native-организации
Здесь про то, как вслед за процессами разработки начинает меняться и огрдизайн компаний. Подробная статья на моем сайте tellmeabout.tech.
3️⃣ От классического task management к AI-native: как меняется сама единица работы.
Здесь про Atlassian и Linear, которые практикуют разные подходы к управлению задачами и являются лидерами рынка для корпораций и стартапов соответственно. Подробная статья на моем сайте tellmeabout.tech.
4️⃣ Как бигтехи планируют внедрять AI-native разработку у себя в 2026 году.
Здесь о том, как бигтехи подходят к организации этого перехода и постановке целей внутри организации, а также как они планируют измерять результат. Подробная статья на моем сайте tellmeabout.tech.
Серия этих статей описывают концептуальный подход, который положен в основу нашей стратегии и тактики на этот год в направлении внедрения AI в разработке внутри компании.
#AI #Management #Future #Software #Engineering #Productivity #Agents #Processes
Medium
Внедрение AI в организации в стиле Григория Остера
В детстве я любил читать книги Григория Остера из серии “Вредные советы”. Одна из книг предназначалась для непослушных детей и их родителей…
👏5🔥4❤3😁3🤣2👍1🤝1
Не усложняй! Управление проектами по методу P3.express (рубрика #Management)
Прочитал книгу Дмитрия и Валерии Ильенковых про управление проектами и она мне понравилась. Саму книгу мне дал почитать Дима, с которым мы знакомы со времен Teamlead Conf 2020, где оба выступали. По моему ощущению "Не усложняй" - это "Пиши, сокращай" для управления проектами, но в хорошем смысле этого слова (сама "Пиши, сокращай" вышла противоречивой для меня ). В "Не усложняй" много примеров, простые слова, ясная структура и подача без ощущения, что тебя сейчас завалят терминологией ради терминологии. При этом книга не "про поговорить", а про вполне прикладной каркас: метод P3.express разбит на 33 шага и 7 стадий, чтобы сделать проект более прозрачным и предсказуемым без тяжелой трансформации процессов. Мне понравилась эта простота - так как я слишком испорчен теорией IPMA, PMI, многослойным PMBoK и всем тем прекрасным бюрократическим великолепием, которое часто идет в комплекте с project management:)
Если говорить про плюсы книги, то они такие
1. Она очень приземленная. Советы почти всегда подкрепляются историями и кейсами - от Boeing и SpaceX до Сиднейской оперы, Денверского аэропорта и собственных факапов авторов. Из-за этого рекомендации не висят в воздухе.
2. Ее можно спокойно давать новичкам, которым надо просто и доступно понять, как начинать работать с проектами. И ее же можно дать опытным людям, которые устали от бюрократии и хотят упростить процессы, не разваливая управление совсем. Авторы прямо пишут, что книга полезна не только проджектам, но и тимлидам, владельцам IT-компаний, аналитикам и другим людям, которые регулярно делают проекты.
3. Для технических руководителей и инженеров книгу точно стоит читать. Не потому, что всем срочно надо стать PM, а потому, что она хорошо объясняет базовые опоры: кто такой спонсор проекта, зачем нужно краткое резюме проекта, как декомпозировать результаты, почему полезны регулярные Go/No-Go и как не тащить мертвые инициативы только потому, что в них уже вбухали силы и деньги.
Отдельно понравился кусок про sunk cost fallacy через "Конкорд". Авторы напоминают, что эффект Конкорда - это когда проект уже очевидно не летит, но его продолжают тащить просто потому, что слишком много вложили. В P3.express для этого есть повторяющийся момент проверки Go/No-Go: не "как бы дожать", а честно спросить, проект все еще нужен или мы страдаем по инерции. Очень здравая мысль для корпораций и больших внутренних инициатив.
Если совсем коротко, шесть принципов подхода p3.express такие:
- Выбирать результат и факты, а не привычки и привязанности
- Беречь энергию команды и экономить ресурсы
- Действовать проактивно
- Искать слабое звено системы
- Ничего не делать без ясной цели
- Опираться на переиспользуемые элементы: шаблоны, чек-листы, повторяемые шаги
Жизненный цикл проекта в P3.express тоже собран минималистично и понятно:
- Старт проекта
- Планирование цикла
- Еженедельный контур управления
- Ежедневный контур управления
- Закрытие цикла
- Завершение проекта
- Этап после проекта, где оценивают полученные выгоды и новые идеи
В общем, если вам нужен не еще один "великий свод знаний" аля PMBoK, а вменяемая книга, которую можно рекомендовать людям рядом - продактам, тимлидам, инженерам, молодым менеджерам и уставшим руководителям, - "Не усложняй" выглядит очень удачным кандидатом. Не как замена PMBoK, а хороший антидот к нему (а я PMBoK читал в трех разных изданиях)
P.S.
С Димой мы договорились записать эпизод подкаста и обсудить управление проектами в общем, а также эту книгу в частности. В общем, stay tuned ...
#Management #Leadership #ProjectManagement #Processes #Engineering
Прочитал книгу Дмитрия и Валерии Ильенковых про управление проектами и она мне понравилась. Саму книгу мне дал почитать Дима, с которым мы знакомы со времен Teamlead Conf 2020, где оба выступали. По моему ощущению "Не усложняй" - это "Пиши, сокращай" для управления проектами, но в хорошем смысле этого слова (
Если говорить про плюсы книги, то они такие
1. Она очень приземленная. Советы почти всегда подкрепляются историями и кейсами - от Boeing и SpaceX до Сиднейской оперы, Денверского аэропорта и собственных факапов авторов. Из-за этого рекомендации не висят в воздухе.
2. Ее можно спокойно давать новичкам, которым надо просто и доступно понять, как начинать работать с проектами. И ее же можно дать опытным людям, которые устали от бюрократии и хотят упростить процессы, не разваливая управление совсем. Авторы прямо пишут, что книга полезна не только проджектам, но и тимлидам, владельцам IT-компаний, аналитикам и другим людям, которые регулярно делают проекты.
3. Для технических руководителей и инженеров книгу точно стоит читать. Не потому, что всем срочно надо стать PM, а потому, что она хорошо объясняет базовые опоры: кто такой спонсор проекта, зачем нужно краткое резюме проекта, как декомпозировать результаты, почему полезны регулярные Go/No-Go и как не тащить мертвые инициативы только потому, что в них уже вбухали силы и деньги.
Отдельно понравился кусок про sunk cost fallacy через "Конкорд". Авторы напоминают, что эффект Конкорда - это когда проект уже очевидно не летит, но его продолжают тащить просто потому, что слишком много вложили. В P3.express для этого есть повторяющийся момент проверки Go/No-Go: не "как бы дожать", а честно спросить, проект все еще нужен или мы страдаем по инерции. Очень здравая мысль для корпораций и больших внутренних инициатив.
Если совсем коротко, шесть принципов подхода p3.express такие:
- Выбирать результат и факты, а не привычки и привязанности
- Беречь энергию команды и экономить ресурсы
- Действовать проактивно
- Искать слабое звено системы
- Ничего не делать без ясной цели
- Опираться на переиспользуемые элементы: шаблоны, чек-листы, повторяемые шаги
Жизненный цикл проекта в P3.express тоже собран минималистично и понятно:
- Старт проекта
- Планирование цикла
- Еженедельный контур управления
- Ежедневный контур управления
- Закрытие цикла
- Завершение проекта
- Этап после проекта, где оценивают полученные выгоды и новые идеи
В общем, если вам нужен не еще один "великий свод знаний" аля PMBoK, а вменяемая книга, которую можно рекомендовать людям рядом - продактам, тимлидам, инженерам, молодым менеджерам и уставшим руководителям, - "Не усложняй" выглядит очень удачным кандидатом. Не как замена PMBoK, а хороший антидот к нему (а я PMBoK читал в трех разных изданиях)
P.S.
С Димой мы договорились записать эпизод подкаста и обсудить управление проектами в общем, а также эту книгу в частности. В общем, stay tuned ...
#Management #Leadership #ProjectManagement #Processes #Engineering
p3express.ru
Книга «Не усложняй! Управление проектами по методу P3․express»
Если вы уже перепробовали все методы, но дедлайны все равно горят, а команды выгорают — поздравляем. Вы нашли решение, которое навсегда закроет эту проблему.
👍24❤11🔥6