Второй день #Teamlead принес крутое визионерское выступление Авенира Воронова. Два тезиса. Первое – ускорение разработки в 10 раз обнуляет нынешнюю систему планирования и управления через задачи. Потому что, когда проверка гипотезы теперь занимает день-два, вместо двух месяцев, то традиционный бэклог на квартал или год исчезает: ведь каждая гипотеза приносит новую информацию, и там получается точка ветвления. Вместо списков задач управление будет идти через стримы активностей с целевыми векторами и оперативным маневром внутри. Как следствие, это обнуляет существующую систему метрик. Зато вайбкодинг позволяет сделать специальные метрики под каждую гипотезу, что ранье было недоступно. Но в целом управление гибридной командой людей и ИИ-агентов нужно строить совершенно иначе, чем мы привыкли.

Второе. Когда не только разработчики, но и сейлы и все остальные работают через копилоты, то общение с копилотом дает не только реальную картину того, чем занимаются сотрудники, но и как они это делают, как они общаются и каково их эмоциональное состояние в реальном времени. И это делает возможность реальный анализ происходящего, то, чего добивались, побуждая разработчиков фиксировать ход работ комментариями в таск-трекере и git. В том числе – показывая скрытую сложность задач, или различные грабли. Что дает объективную картину вклада в проект, обеспечивая справедливость. А также показывает эмоциональное состояние: можно, например, видеть, что работа с бизнес-логикой в конкретной области проекта приводит в ярость, или видеть задачи, которые были сделаны в стрессе, что чревато инцидентами на проде – ведь в стрессе когнитивные способности снижены и человек не может хорошо выполнить свою часть работы.

И это – реальность, которая уже пришла, компания Авенира делает тулы, которые это все обеспечивают.

Замечу, что это перекликается с совершенно неожиданным выступлением Юлдуз Фаттаховой и Андрея Березина из Сбера об изменении ответственности продукта и техлида с приходом ИИ. Юлдуз говорила, что вайбкодинг позволяет продуктам быстро проверить гипотезы, не обращаясь к команде разработке и запускать только перспективные. Но команда разработки при этом вместо привычных задач получает на вход результаты этого вайбкодинга. А еще в их выступлении был разобран кейс встройки ИИ в продукты создание в существующем продукте анализа данных ИИ-помощника, чтобы вести анализ могли не только технари, забирающиеся в запросах, но и другие пользователи. Такая встройка порождает совершенно новые задачи по подбору моделей, обеспечению и тестированию качества и времени ответа от такого помощника и так далее.

Еще хочу отметить выступление Надежды Погиной про AI-first команду. Она рассказала о нетипичном пути внедрения ИИ: вместо того, чтобы обязать всех применять ИИ и следить за метриками пережевывания бэклога или аналогичными, были собраны энтузиасты, которые искали конкретные точки, которые можно было ускорить за счет ИИ, и делали проекты по проверке этих гипотез. При этом сначала были собраны идеи, а потом проводился скоринг и выбор перспективных. И система ожидаемого изменения метрик была под каждый проект своя, что логично. В презентации – ссылки на материалы, которые позволяют использовать опыт, в частности, сценарий интервью для описания гипотезы. Из вопросов было понятно, что такой подход – делать конкретные проекты вместо того, чтобы обязать всех – необычен для аудитории.

В целом трек ИИ на #Teamlead был, на мой взгляд, сильнее, чем на Highload. Больше конкретики, сделанных проектов, и меньше рассуждений о том, как «космические корабли будут бороздить просторы Большого театра». Я тут хочу отметить выступление Марка Быстрова из ЦИАН о ИИ-конвейере, который обеспечивает гарантированное переписывание сервисов на другой техстек – с pyhton на C# или обратно. На первом такте там анализ сервиса и его тестов, проверка достаточности описания контракта и покрытия тестами, затем – написание дополнительных тестов на тонкие места, чувствительные к смене стеков, поэтапный перенос и тестирование. Люди – есть, они анализируют проблемы и дорабатывают настройки конвейера. Через конвейер они успешно пропустили несколько сервисов, и не получили ни одного отката на проде. ИИ за несколько месяцев с присмотром пары инженеров с неполной занятостью в этом проекте успешно сделал работы, которые по оценкам требовали пары лет работы команды.

Смене мышления, которое влечет ИИ, был посвящено и выступление Александра Зизы, но его фокусом было следующая из прихода ИИ необходимость самоопределения. Еще были интересные выступления Алексея Пронского про использование ИИ-агентов для работы с архитектурой, Андрея Сотника и Родиона Лунева из X5 про эксперимент по разработке нового проекта на ИИ с реальными метриками, Владимира Гриненко, Дарины Коршуновой, Екатерины Боголеповой и других – я слушал не все выступления про ИИ.

Естественно, на конференции были выступления не только про ИИ. Я хочу отметить выступление Александра Апазиди о том, как сделать, чтобы платформенная команда была ускорителем, а не барьером. А еще надо отметить, что нынешняя обстановка приводит к обострению корпоративных политических игр, и об этом тоже рассказывали. И о выгорании, которое тоже актуально.

Конспект выступлений – будет, но позднее, я сначала разберу Highload, а потом доберусь до Teamlead. А пока – этот пост по следам конференции.

Анатолий Левенчук с июня прошлого года создает описание системного подхода для ИИ - First Principle Framework (FPF), первая версия была опубликована в сентябре, с тех пор релизы регулярно обновляются. А с февраля он начал делать это с помощью агентов. Агентам важно создать правильный harness под конкретную задачу, и завтра 28.06 Анатолий будет делать это в прямом эфире для одной из своих рабочих задач. Это бесплатный практикум, потом будет записью Подробности - в посте, там же ссылка на канал, где будет ссылка чтобы присоединиться и запись.

Опубликован мой отчет с Saint #Highload в Питере https://habr.com/ru/companies/oleg-bunin/articles/1053550/ Превалировала тема ИИ, ей был посвящен отдельный трек, и еще ряд выступлений и много мастер-классов на других треках. Отмечу новое хайповое слово: harness – им называют обвязку вокруг ИИ – получение контекста, настройку скилов для агентов других правил работы, и так далее. Еще из хайпа следует отметить ai-native и ai-first – ярлыки, которые стремятся на себя повесить, как 10 лет назад вешали лейбл Agile чтобы выглядеть модно, молодежно и прогрессивно. Как и тогда, содержание может быть самое разное.

А в целом конференция дала мне инсайт: инженеры используют тему ИИ, чтобы воплотить давние мечты. Одни – чтобы собрать-таки правильный водопад, пусть на агентах, раз на людях не получается, Spec Driven Development – об этом. То есть слова об изменении процессов остаются словами, инженеры верят, что классический водопад – самый правильный процесс. Другие – вообще реализовать давнюю мечту писать платформы вместо того, чтобы заниматься бизнес-задачами, которые отдать бизнесу, переложив разработку на агентов полностью. Обе – не реалистичны по системным причинам, но корпорации ведутся: там любят мегапроекты, которые сулят большие выигрыши, надеются получить высокую скорость и избавиться от зависимости от ИТ-шнков. При этом корпорации ждут готовых фреймворков, они не готовы реально экспериментировать с радикальным изменениям процесса, сложившаяся оргструктура сопротивляется. Это четно видно. А вот небольшие компании – реально экспериментируют и меняются, это я видел и на Highload, и на других конференциях.

Посмотрел семинар Анатолия Левенчука про очередное развитие его First Principle Framework – объяснение системного подхода для ИИ. Очередной этап – теперь можно одной командой создавать описания для конкретной предметной области – Domain Principle Framework (DPF). Семинар вызвал размышления, из которых получилась статья https://habr.com/ru/articles/1056178/, в ней же – ссылки. Читайте и оценивайте.

Реплика вдогонку к https://xn--r1a.website/mtsepkov/1184. В семинаре Анатолия был очень хороший образ: первые принципы (FPF) описывают физику устройства мира, и будут отсекать невозможные решения, подобные вечному двигателю, которые устройству мира противоречат. И вот интересно проверить это на практике вот на каком кейсе. Опыт развития ИТ показал, что описать с помощью требований и спланировать достаточно сложный проект так, что результат будет получен в предусмотренные сроки и будет пригоден для внедрения без доработки напильником – невозможно. И этот опыт имеет теоретические объяснения, связанные с высокой неопределенностью, во-первых, а, во-вторых, с необходимостью для получения достоверного плана принять ряд проектировочных решений. которые можно практически проверить только на этапе разработки. То есть это не просто плохое исполнение, это обусловлено устройством мира. В результате появился Agile и другие современные методы ведения проектов.

Теперь вопрос. Подход Spec Driven Development – реализация той же идеи, только на новом витке технологий. Предполагается, что заказчик (сам или с помощью ИИ-агентов) будет создавать спецификацию, реализация на основе которой гарантирует пригодность результата для внедрения. И эту спецификацию можно будет проверить. И на полном серьезе ряд корпораций ставят задачу довести разработку с помощью ИИ именно до такого состояния, исключив человека и итерации с его участием из цикла исполнения. То есть задачу, которая противоречит устройству мира, подобно вечному двигателю. Вопрос: можно ли с помощью FPF это проверить и как? Или надо еще сделать DPF для области ведения ИТ-проектов и только там это будет?

Понятно, что это надо проверять практически – взять и спросить, но пока у меня нет времени, так что я просто кину такую реплику...

Прочитал книгу Владимира Воловика и Петра Щедровицкого «Конструктивное мышление: недооцененный фактор». Основная идея – роль конструктивного мышления как ключевого фактора, который позволил перейти от индивидуализированного ремесленного изготовления отдельных образцов к массовому производству было появление нового типа мышления. Книга вызвала размышления не только про этот способ мышления, но и о том, почему он оказался востребованным на Западе, какие потребности этому способствовали. Подробности – в моем отзыве https://mtsepkov.org/PG-ConstuctThink

Опубликован мой отчет с #Teamlead в Питере https://habr.com/ru/companies/oleg-bunin/articles/1057164/ Как я писал по горячим следам, на конференции было крутое визионерское выступление Авенира Воронова, и еще ряд интересных выступлений с конкретными кейсами ИИ. Как я писал, на мой взгляд трек ИИ на Teamlead оказался круче, чем на Highload. Так что ловите отчет с конспектами!

Алексис де Токвиль в своей книге «Демократия в Америке» (1835-1840) проводит сопоставление демократического способа управления, изучать который он поехал в США послом Франции на 10 лет, с авторитарным, монархическим, принятым тогда в Европе. Слабость монархии очевидна: на троне может оказаться неподходящий человек, и страна деградирует. Демократия предотвращает появление таких людей во власти, но она же и не дает продвинуться способным, но авторитарным людям. А еще он задается вопросом: если демократия превосходит авторитаризм с точки зрения развития своей страны, то почему в Европе она так редка, не говоря об остальном мире. И, анализируя историю, он дает такой ответ: демократия многократно зарождалась в Европе, он приводит конкретные примеры. Но развитие требует времени, а решения при демократии при демократии принимаются медленнее. И поэтому авторитарные соседи просто поглощали такое государство на начальном этапе, пользуясь его слабостью.

Рэймонд Мередит Белбин в своей теории командных ролей выделяет две роли руководителей: Координатор, который принимает решения через консультации, выбирая лучшие, и авторитарный Шейпер, который ведет команду по выбранному им пути. Есть еще аналитик-стратег, который умеет анализировать различные варианты, но отличается от координатора тем, что не очень может принять на себя ответственность, если однозначно лучшего решения нет, предпочитает дополнительные исследования, на которые нет времени. Белбин сравнивал эффективность команд с разным руководством в своих исследованиях, через которые прошли сотни команд. Статистически он показал эффективность Координатора и Шейпера примерно одинакова и превосходит эффективность других руководителей. Однако, это – различная эффективность: команды с Координатором реже принимают неверные решения, однако долгий процесс принятия по сравнению с Шейпером не всегда дает возможность принять решение во-время, они проигрывают из-за отсутствия принятого во-время решения. А команды с Шейпером чаще идут по неверному пути из-за уверенности в нем Шейпера, хотя верная гипотеза у кого-то из членов команды была.

Я сейчас путешествую по Бразилии и погружаюсь в ее историю. И она очень хорошо иллюстрирует достоинства и недостатки демократического управления. Развитие страны требует фокусировки и порождает недовольство, в результате лидер становится объектом критической атаки и судьба его часто незавидна. Так что, в некотором смысле, они жертвуют собой ради проведения соей программы. При этом Бразилия в силу логики исторического развития находится в относительно хороших условиях, она защищена расстояниями от основных театров военных конфликтов. И в целом развивается страна успешно.

Совершенно уникальный опыт дает Китай, в историю которого я тоже погружался в последнее время. Я тут опираюсь на книги Николая Вавилова, автора ряда книг про устройство китайской власти. Коммунистическая партия Китая – не едина, в ней есть 3-7 крупных сил. При этом есть определенный консенсус, касающийся целей развития страны, а вот взгляды на пути развития тактические цели – различаются. И они создали систему, при которой на руководящие должности внутри ведомств и провинций назначаются представители разных групп, которые должны договариваться и координировать свои действия, чтобы руководимое ими организованность достигала поставленных и согласованных с руководством целей, так же организовано и управление на уровне страны в целом. И это получается интересный гибрид демократии и авторитаризма, который синтезирует сильные стороны и предотвращает недостатки, работоспособный в условиях сильного внешнего давления. Это я знал раньше, когда писал свою книгу про Китай, но свежее знакомство с историей Бразилии и размышления о возможных траекториях развития разных стран дало яркую возможность для такого сопоставления.

P.S. Для России сценарий Бразилии применим слабо, потому что у нас человек зимой без теплого дома замерзнет, а тут – нет. Это – объективная разница.

Мне не очень нравится, как @mtsepkov делает доклады, потому что мне кажется, что он все время недоговаривает и быстро перескакивает от одной мысли к другой.
Но мне очень нравится с ним cвободный формат, потому что его можно притормозить и попросить уточнить.
В этом выпуске мы обсуждаем, как внедрение ИИ-агентов отражается на структуре и процессах команд разработки.

💙 VK
📹 Youtube

К сожалению мы очень поверхностно прошли по документам AI PDLC (Сбер) и AI PDC (Amazon), поэтому я очень жду когда нам получится договориться о записи с авторами AI PDLC.

Основные темы разговора:
–Что меняется в цикле разработки с приходом агентов и как это соотносят с классическими моделями (SDLC, водопад, гибкие методологии)

–Разделение труда между человеком и ИИ: от горизонтального и вертикального разделения (методология Г.П. Щедровицкого) к практическим вопросам «онбординга» агента, оценке его надёжности и измеримости результатов

–Разница в эффектах от новых инструментов в стартапах (высокая скорость проверки гипотез) и корпорациях (организационные ограничения, устоявшиеся процессы)

–Опыт Китая: как устроены автономные команды, культура обсуждения фактов без потери лица, торг за стоимость инициатив, отношение к ошибкам

–Динамика рынка труда: сложности поиска работы в русскоязычном IT, обесценивание узкой экспертизы, изменение требований к фронтендерам и другим специалистам

–Практические стратегии для инженеров, продакт-менеджеров и руководителей: как адаптироваться, не теряя навыков, и где искать точки для внедрения ИИ с измеримой пользой

–Критический взгляд на распространённые рекомендации (например, курсы по промпт-инжинирингу) и важность сохранения способности решать сложные задачи без опоры на агента

На площадке «Т‑Бизнес секреты» вышла моя статья «Ловушка вендора: почему банки и корпорации переходят на свою разработку и как сделать это правильно». Тема актуальная, в последнее время крупные банки активно отказываются от вендорских решений в пользу собственной разработки, а вайбкодинг и agentic engineering могут сделать это возможным и для среднего сегмента. При этом часто идут по пути разработки собственного ядра или платформы. В статье я подробно разбираю этот вопрос, опираясь на свой опыт работы в индустрии, в котором не только заказные решения, но и разработка платформ для них. Я разбираю не только технические вопросы, но и организацию, включая взаимодействие с привлекаемыми подрядчиками. Читайте, пишите отзывы!

В путешествии по Южной Америке добрались до острова Пасхи. Посмотрели знаменитые мега-статуи. Как обычно, делюсь такими впечатлениями в своем ЖЖ https://maksiq.livejournal.com/148300.html, читайте. Впечатления других стран тоже зреют, буду делиться.