📰 На хабре вышла моя статья про эффективные команды. С картинками и котиками. Рассмотрим вершины эффективной команды, её паттерны и почему цели - самое важное.
🦾 Призываю лайкать за букву “ө” в слове “өчпочмак”
https://habr.com/ru/articles/1011932/
🦾 Призываю лайкать за букву “ө” в слове “өчпочмак”
https://habr.com/ru/articles/1011932/
Хабр
Что такое эффективная команда, почему 91% сотрудников работают вслепую и причем тут «эчпочмак»?
TL;DR: Эффективная команда - это команда, которая в первую очередь достигает своих бизнес-целей cоздает психологическую безопасность и закрывает мотивацию персонала метрики потока которой обеспечивают...
2👍6🔥4😁1
Перевел очень холиварную статью, которую мы супер часто в последние пару месяцев обсуждали и в проф. сообществах, и на работах, и даже в коворкинге.
Она вкратце про то, что:
☠️ SDLC больше нет. AI-агенты не ускорили привычный жизненный цикл разработки, они его схлопнули.
- Agile-ритуалы мертвы. Планирование спринтов, оценки в story points, релизные поезда и многодневные ожидания аппрувов в PR — всё это пережитки прошлого.
- Все этапы слились воедино. Сбор требований, system design, написание кода и тестов происходят одновременно — в реальном времени и в диалоге с агентом.
- Code Review — это новый луддизм. Машина генерирует 500 PR в день, человек физически не может их проверить. Код должен лететь прямо в main под прикрытием автотестов, feature flags и хорошо настроенного observability.
🌱🤖 Новый жизненный цикл — это узкая петля:
Intent (Намерение) → Build (Создание) → Observe (Наблюдение).
Она вкратце про то, что:
- Agile-ритуалы мертвы. Планирование спринтов, оценки в story points, релизные поезда и многодневные ожидания аппрувов в PR — всё это пережитки прошлого.
- Все этапы слились воедино. Сбор требований, system design, написание кода и тестов происходят одновременно — в реальном времени и в диалоге с агентом.
- Code Review — это новый луддизм. Машина генерирует 500 PR в день, человек физически не может их проверить. Код должен лететь прямо в main под прикрытием автотестов, feature flags и хорошо настроенного observability.
🌱🤖 Новый жизненный цикл — это узкая петля:
Intent (Намерение) → Build (Создание) → Observe (Наблюдение).
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
SDLC мертв. AI-агенты его убили
Перевод статьи Boris Tane: SDLC is Dead (ссылка в шапке). Пост автора ангажированный и местами кликбейтный. Но автор рассуждает в очень правильном направлении. AI-агенты не ускорили жизненный цикл...
1❤🔥7👍1🤔1
Если вы в Уфе, и если вы читали статью выше - то определенно приходите подискутировать с QA-сообществом "Как меняется роль и работа с качеством в эпоху AI-инструментов"!
Тема наболевшая, открываю первый митап Agile Ufa этого года актуалочкой.
Тема наболевшая, открываю первый митап Agile Ufa этого года актуалочкой.
Forwarded from Marat Kiniabulatov
Открываем Agile Ufa 2026 с митапом "Как меняется работа с качеством в эпоху ИИ"
🗓 9 апреля, 19.30
🗺 Верхнеторговая 6, БЦ Нестеров, 4 этаж.
Подискутируем и рассмотрим, как будет меняться и уже меняется парадигма работы с качеством в SDLC
📣 Обсудим:
- Как трансформируется роль и обязанности QA в эпоху AI-SDLC
- Какие изменения ждут другие роли в команде
- Как изменилась ваша роль в команде по мере внедрения AI в процесс разработки.
👉 Регистрация здесь по ссылке на Timepad
🗓 9 апреля, 19.30
Подискутируем и рассмотрим, как будет меняться и уже меняется парадигма работы с качеством в SDLC
📣 Обсудим:
- Как трансформируется роль и обязанности QA в эпоху AI-SDLC
- Какие изменения ждут другие роли в команде
- Как изменилась ваша роль в команде по мере внедрения AI в процесс разработки.
👉 Регистрация здесь по ссылке на Timepad
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍1🔥1👨💻1
В этом году выступаю с темой
"Что такое эффективные команды и как убедиться что они слаженно работают, если их 45?"
на Merge Innopolis. Забабахали промо-код со скидкой на покупку билетов на конференцию.
- Программа события готова и уже на сайте.
По промокоду UFA действует скидка 15% на билеты.
"Что такое эффективные команды и как убедиться что они слаженно работают, если их 45?"
на Merge Innopolis. Забабахали промо-код со скидкой на покупку билетов на конференцию.
- Программа события готова и уже на сайте.
По промокоду UFA действует скидка 15% на билеты.
1🔥4
🤝️️️️️️ Что такое устойчивая (sustainable) команда?
• "Хьюстон, у нас проблема с мотивацией."
• Окей. А с чем конкретно? С целями? С лидером? С нагрузкой? С признанием? С ростом?
Мы уже рассматривали почему цели - самые важные в модели командой эффективности. Теперь время обсудить тех, кто эти самые цели и реализует.
💠 Концепция
Устойчивая команда — команда, которая:
• Достигает результатов
• Не выгорает
• Сохраняет людей
• Растёт в capability
Это точно не "довольная команда". Пожалуйста, не путайте. Нам важно постоянное достижение результатов на длинной дистанции (а не то, что все довольны и радостны).
🏗 Составные части устойчивой команды
Формат: Аспект, Что это, Почему важно
• Психологическая безопасность: Можно говорить правду без страха. Это фундамент для всего остального.
• Качество управления: Качество работы руководителя. На 70% вырастает вовлеченность.
• Цели и их значение: Понимание зачем и куда. Внутренняя мотивация важнее денег.
• Стабильность состава команды: Стабильность состава. Важно так как стабильный состав влияет на концетрацию знаний и стадию зрелости команды.
• Рост и развитие: очевидное название. 3% уходят из-за скуки
• Признание: Признание вклада. Повышает вовлеченность в 2.5 раза.
• Work-life Balance: Баланс нагрузки. 76% сотрудников испытывают выгорание
• Компенсация: Справедливая оплата. Гигиенический фактор.
⛓️ Как это связано
Всё влияет на всё. Примеры цепочек:
Цепочка 1: Безопасность → Выгорание.
> Низкая безопасность → скрывают проблемы → копится техдолг → перегрузка → выгорание → уход людей → потеря знаний → ещё ниже безопасность
Цепочка 2: Leadership → Everything
> Слабый лидер → нет четкости целей → нет признания → нет проф. развития → люди уходят
Цепочка 3: Цели → Motivation
> Непонятные цели → нет смысла и ценности → нет вовлеченности → "просто работаю" → ищу где интереснее
🧬 Какие модели устойчивых команд бывают и из чего они состоят
Есть разные модели: Google Aristotle - модель эффективной команды, модель архитектуры команды Хакмана, модель продуктивной команды SPACE (Microsoft).
•👍 но я напишу про Spotify Health Check: Самодиагностика. 8 измерений, команда сама оценивает, без сравнений. Самое простое, с чего можно начать уже завтра.
• "Хьюстон, у нас проблема с мотивацией."
• Окей. А с чем конкретно? С целями? С лидером? С нагрузкой? С признанием? С ростом?
Устойчивая команда (Sustainable team) - это система показателей.
Мы уже рассматривали почему цели - самые важные в модели командой эффективности. Теперь время обсудить тех, кто эти самые цели и реализует.
💠 Концепция
Устойчивая команда — команда, которая:
• Достигает результатов
• Не выгорает
• Сохраняет людей
• Растёт в capability
Это точно не "довольная команда". Пожалуйста, не путайте. Нам важно постоянное достижение результатов на длинной дистанции (а не то, что все довольны и радостны).
🏗 Составные части устойчивой команды
Формат: Аспект, Что это, Почему важно
• Психологическая безопасность: Можно говорить правду без страха. Это фундамент для всего остального.
• Качество управления: Качество работы руководителя. На 70% вырастает вовлеченность.
• Цели и их значение: Понимание зачем и куда. Внутренняя мотивация важнее денег.
• Стабильность состава команды: Стабильность состава. Важно так как стабильный состав влияет на концетрацию знаний и стадию зрелости команды.
• Рост и развитие: очевидное название. 3% уходят из-за скуки
• Признание: Признание вклада. Повышает вовлеченность в 2.5 раза.
• Work-life Balance: Баланс нагрузки. 76% сотрудников испытывают выгорание
• Компенсация: Справедливая оплата. Гигиенический фактор.
Всё влияет на всё. Примеры цепочек:
Цепочка 1: Безопасность → Выгорание.
> Низкая безопасность → скрывают проблемы → копится техдолг → перегрузка → выгорание → уход людей → потеря знаний → ещё ниже безопасность
Цепочка 2: Leadership → Everything
> Слабый лидер → нет четкости целей → нет признания → нет проф. развития → люди уходят
Цепочка 3: Цели → Motivation
> Непонятные цели → нет смысла и ценности → нет вовлеченности → "просто работаю" → ищу где интереснее
🧬 Какие модели устойчивых команд бывают и из чего они состоят
Есть разные модели: Google Aristotle - модель эффективной команды, модель архитектуры команды Хакмана, модель продуктивной команды SPACE (Microsoft).
•
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥4💯4
Рассуждаем, как меняется цикл разработки в эпоху AI:
- в проектах без исторической кодовой базы (с нуля, greenfield)
- в существующих продуктах (brownfield)
- в зарегулированных индустриях (regulated)
Мы очень долго спорили с кучей коллег, знакомых, друзей - над контентом поста. Спасибо большое Свете, Вадиму, Боре, Кириллу, Илье и Колину за правки и комментарии.
https://habr.com/ru/articles/1015004/
- в проектах без исторической кодовой базы (с нуля, greenfield)
- в существующих продуктах (brownfield)
- в зарегулированных индустриях (regulated)
Мы очень долго спорили с кучей коллег, знакомых, друзей - над контентом поста. Спасибо большое Свете, Вадиму, Боре, Кириллу, Илье и Колину за правки и комментарии.
https://habr.com/ru/articles/1015004/
1❤🔥3👍2
Всем привет и богоподобных выходных!
В рамках сообщества Agile Ufa делаю небольшое исследование и нужен ваш опыт и мнение:
• 🗳 Уделите пару минут на опрос (гугл формы): Как меняется работа с качеством и какой становится роль QA с приходом ИИ-инструментов в нашу работу.
Результаты я опубликую в этом канале ровно через неделю + напишу что наблюдаю в своей работе.
• 📍 Если вы в Уфе + хотите поучаствовать в митапе про качество в эпоху ИИ - вот анонс с регистрацией (напишите мне в личку, если мест не хватает).
•🤗 Ну, а если хотите стать частью сообщества: велком в @agileufa 🙂
В рамках сообщества Agile Ufa делаю небольшое исследование и нужен ваш опыт и мнение:
• 🗳 Уделите пару минут на опрос (гугл формы): Как меняется работа с качеством и какой становится роль QA с приходом ИИ-инструментов в нашу работу.
Результаты я опубликую в этом канале ровно через неделю + напишу что наблюдаю в своей работе.
• 📍 Если вы в Уфе + хотите поучаствовать в митапе про качество в эпоху ИИ - вот анонс с регистрацией (напишите мне в личку, если мест не хватает).
•
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
AgileUfa
#AgileUfa - единственный в Уфе митап про гибкость, бережливость, и любые бизнес-процессы, которые вращаются вокруг этого :)
🔥5
В этом году со-организую BitGN (от автора ERC - enterprise rag challenge) в Уфе!
Приходите, будет весело 🚀
Приходите, будет весело 🚀
🔥1
Forwarded from Aigiz K
BitGN PAC1 — Хакатон по AI-агентам в Уфе 🤖🔥
📅 11 апреля
📍 Школа 21 (Сбер), Уфа, ул. Заки Валиди, 32/2Б
Собираемся оффлайн, чтобы вместе прокачать своих персональных AI-агентов и посоревноваться на платформе BitGN!
Расписание:
🕐 12:00 — Старт. Разбор кейсов, обмен опытом, помощь друг другу, донастройка агентов
🕐 15:00–17:00 — Соревнование
🕐 18:00 — Объявление победителей и награждение 🏆
Что нужно от вас:
— Ноутбук с доступом к LLM
— Заранее написанный агент (на месте будем дорабатывать и тюнить)
Воду обеспечим, остальное — ваш скилл и желание побеждать 💪
Мероприятие проходит при поддержке Уфа IT Коворкинг и Школа 21 от Сбера.
Если есть вопросы - вступайте в нашу группу.
Если ещё не смотрели — познакомьтесь с платформой и примерами агентов заранее:
🔗 Платформа: https://api.bitgn.com
🔗 Примеры агентов: https://github.com/bitgn/sample-agents
До встречи 11 апреля!
📅 11 апреля
📍 Школа 21 (Сбер), Уфа, ул. Заки Валиди, 32/2Б
Собираемся оффлайн, чтобы вместе прокачать своих персональных AI-агентов и посоревноваться на платформе BitGN!
Расписание:
🕐 12:00 — Старт. Разбор кейсов, обмен опытом, помощь друг другу, донастройка агентов
🕐 15:00–17:00 — Соревнование
🕐 18:00 — Объявление победителей и награждение 🏆
Что нужно от вас:
— Ноутбук с доступом к LLM
— Заранее написанный агент (на месте будем дорабатывать и тюнить)
Воду обеспечим, остальное — ваш скилл и желание побеждать 💪
Мероприятие проходит при поддержке Уфа IT Коворкинг и Школа 21 от Сбера.
Если есть вопросы - вступайте в нашу группу.
Если ещё не смотрели — познакомьтесь с платформой и примерами агентов заранее:
🔗 Платформа: https://api.bitgn.com
🔗 Примеры агентов: https://github.com/bitgn/sample-agents
До встречи 11 апреля!
🔥5❤2
🪙 Токенмаксинг — новая религия Silicon Valley
Статья на хабре: https://habr.com/ru/articles/1020648/
Пока вы работаете, ваш коллега уже сжёг 210 миллиардов токенов за неделю. Это 33 Википедии. Он не написал ни строчки в продакшн — но возглавил корпоративный лидерборд и получил звание «Token Legend».
Разработчик в Meta* (признана экстремистской на территории РФ) создал внутренний рейтинг сотрудников по потреблению AI-токенов. За месяц — 60 триллионов токенов на ~$9 млрд (если смотреть на тарифы Claude). Jensen Huang предлагает выдавать токен-бюджет как часть зарплаты.
Добро пожаловать в эпоху, где метрика продуктивности — это сколько денег ты потратил на нейросеть. 🙈
Строки кода накручивали в 2000-х. Теперь накручивают токены. Только теперь это стоит $72 000 в месяц из кармана компании.
PS: Полгода назад я писал, почему мы отказались смотреть на AI-adoption через токены и количество запросов к LLM. А антипаттерн-то цветет и пахнет.
PSS: Пока читал материалы, за вчера два раза упёрся в лимиты по Claude Code на своем Pro-тарифе. Токены нынче действительно роскошь.
Статья на хабре: https://habr.com/ru/articles/1020648/
Пока вы работаете, ваш коллега уже сжёг 210 миллиардов токенов за неделю. Это 33 Википедии. Он не написал ни строчки в продакшн — но возглавил корпоративный лидерборд и получил звание «Token Legend».
Разработчик в Meta* (признана экстремистской на территории РФ) создал внутренний рейтинг сотрудников по потреблению AI-токенов. За месяц — 60 триллионов токенов на ~$9 млрд (если смотреть на тарифы Claude). Jensen Huang предлагает выдавать токен-бюджет как часть зарплаты.
Добро пожаловать в эпоху, где метрика продуктивности — это сколько денег ты потратил на нейросеть. 🙈
Строки кода накручивали в 2000-х. Теперь накручивают токены. Только теперь это стоит $72 000 в месяц из кармана компании.
PS: Полгода назад я писал, почему мы отказались смотреть на AI-adoption через токены и количество запросов к LLM. А антипаттерн-то цветет и пахнет.
PSS: Пока читал материалы, за вчера два раза упёрся в лимиты по Claude Code на своем Pro-тарифе. Токены нынче действительно роскошь.
Хабр
Tokenmaxxing: Новый тренд в бигтехах в 2026 году
Что такое токенмаксинг Токенмаксинг (tokenmaxxing) — это практика, при которой сотрудники компаний соревнуются за максимальное потребление AI-токенов, превращая сам факт использования ИИ-инструментов...
1💯6🤣1
Митап «Роль QA в эпоху ИИ» (как пошутил мой знакомый, «эпоха ИИ» звучит как название исторического периода в Японии).
Прошлая неделя в Уфе выдалась насыщенной на ИИ-события: мы провели хакатон по персональным агентам и митап, где 44 человека в мини-группах обсуждали трансформацию QA.
🗯 Что обсуждали на митапе
Мы искали ответы на четыре главных вопроса в контексте агентизации:
1⃣ Как в идеальном сетапе должна измениться роль QA?
2⃣ Как должны поменяться другие роли?
3⃣ Какие сейчас существуют блокеры?
4⃣ Что нужно начать делать уже сейчас, чтобы прийти к целевому сетапу?
Краткая сводка по опросу — в заголовке поста (на картинке), а подробные выводы из презентации я оставил в комментариях.
🎚 Уровни внедрения ИИ
Для себя я с легкой руки делю Adoption на четыре стадии:
• LVL 1. Общение с LLM в чате.
• LVL 2. Написание кода с одним агентом.
• LVL 3. Использование нескольких агентов с разными скиллами.
• LVL 4. Оркестрация агентских систем.
🐰 Суровая реальность и инсайты
Митап оказался отрезвляющим. Реальный уровень внедрения ИИ пока довольно низкий:
• Подавляющее большинство (90%) застряло на LVL 1, используя нейросети как обычный чат, даже дома для пет-проектов.
• Фразы уровня «для QA нужна специально обученная LLM» отлично показывают, что с агентами и скиллами пока почти никто не работает.
• Моделями Anthropic и OpenAI в работе пользуются только 20% участников, а платные китайские сетки применяют от силы 5%.
• Доступ по API и использование продвинутых платных моделей — это пока удел стартапов, где разработчикам дают больше свободы.
• К локальным LLM много недоверия из-за сложностей с развертыванием в РФ (дефицит нужного железа и качественных открытых моделей).
• В крупной нефтянке и около-госсекторе внедряют модели, одобренные ФСБ, но они показывают плохие результаты и лишь множат скепсис.
Было очень интересно. Работы впереди много — надо продолжать!
Прошлая неделя в Уфе выдалась насыщенной на ИИ-события: мы провели хакатон по персональным агентам и митап, где 44 человека в мини-группах обсуждали трансформацию QA.
🗯 Что обсуждали на митапе
Мы искали ответы на четыре главных вопроса в контексте агентизации:
1⃣ Как в идеальном сетапе должна измениться роль QA?
2⃣ Как должны поменяться другие роли?
3⃣ Какие сейчас существуют блокеры?
4⃣ Что нужно начать делать уже сейчас, чтобы прийти к целевому сетапу?
Краткая сводка по опросу — в заголовке поста (на картинке), а подробные выводы из презентации я оставил в комментариях.
🎚 Уровни внедрения ИИ
Для себя я с легкой руки делю Adoption на четыре стадии:
• LVL 1. Общение с LLM в чате.
• LVL 2. Написание кода с одним агентом.
• LVL 3. Использование нескольких агентов с разными скиллами.
• LVL 4. Оркестрация агентских систем.
Митап оказался отрезвляющим. Реальный уровень внедрения ИИ пока довольно низкий:
• Подавляющее большинство (90%) застряло на LVL 1, используя нейросети как обычный чат, даже дома для пет-проектов.
• Фразы уровня «для QA нужна специально обученная LLM» отлично показывают, что с агентами и скиллами пока почти никто не работает.
• Моделями Anthropic и OpenAI в работе пользуются только 20% участников, а платные китайские сетки применяют от силы 5%.
• Доступ по API и использование продвинутых платных моделей — это пока удел стартапов, где разработчикам дают больше свободы.
• К локальным LLM много недоверия из-за сложностей с развертыванием в РФ (дефицит нужного железа и качественных открытых моделей).
• В крупной нефтянке и около-госсекторе внедряют модели, одобренные ФСБ, но они показывают плохие результаты и лишь множат скепсис.
Было очень интересно. Работы впереди много — надо продолжать!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5
В продолжение темы про ИИ — наш второй пост о хакатоне персональных агентов-помощников BitGN. Платформу для него сделал наш бывший коллега Ринат Абдуллин, который сейчас живет в Вене. Огромное ему спасибо за такие классные инициативы!
В этом мероприятии я выступил как соорганизатор
- с Айгизом (автором колонки Homai и ML Engineer в TimeToAct),
- Вадимом (тимлидом TYIN и активным контрибьютором в AI community).
- Школа 21 Уфа (предоставили площадку).
а заодно прочитал мини-лекцию.
Ожидания и реальность
Помните, в прошлом посте я говорил про низкий уровень владения ИИ? На хакатоне это подтвердилось наглядно: около 80% пришедших участников до этого не ставили вообще никаких оболочек для работы с LLM.
Мой коллега и идейный вдохновитель хакатона сначала думал, что с установкой софта участники справятся сами и париться не стоит. Но я, наученный опытом внедрения ИИ в своем отделе, понимал, что без базы мы далеко не уедем.
Лекция и долгая установка
Пришлось сделать подробный вводный гайд. Мы разобрали, что такое LLM, токены и контекст, а затем пошагово ставили opencode (CLI/UI) и шли в OpenRouter. Отдельно учились брать бесплатные модели (nemotron 30b free), так как платные мало кто использует, а до китайских сеток люди вообще не добираются.
На прикрепленной фотке я в полуспящем состоянии читаю этот самый гайд по настройке оболочек. В итоге установка, которая в идеальном мире занимает 10 минут, растянулась на добрые полтора часа. 😄
Практика с агентами
Когда мы справились с инфраструктурой, началось самое интересное — запуск Python-агента сначала в песочнице, а потом в проде. Агент должен был выполнять задачи разного профиля, но делал это с заранее заложенными ошибками.
Участникам нужно было разобраться в его логике, найти баги и заставить агента работать правильно.
Крутые итоги
Получилось очень здорово! Мы фактически с нуля научили 35 человек пользоваться opencode и оплатили им доступ к модели GLM (за это отдельное спасибо @listl). Наши ребята попали в топ лидерборда и прокачались в создании агентов.
Дело за малым — осталось обучить технологиям ИИ остальные 1,1 миллиона жителей Уфы! 😄
Думаем летом сделать Vibe Code Night 🍾
В этом мероприятии я выступил как соорганизатор
- с Айгизом (автором колонки Homai и ML Engineer в TimeToAct),
- Вадимом (тимлидом TYIN и активным контрибьютором в AI community).
- Школа 21 Уфа (предоставили площадку).
а заодно прочитал мини-лекцию.
Ожидания и реальность
Помните, в прошлом посте я говорил про низкий уровень владения ИИ? На хакатоне это подтвердилось наглядно: около 80% пришедших участников до этого не ставили вообще никаких оболочек для работы с LLM.
Мой коллега и идейный вдохновитель хакатона сначала думал, что с установкой софта участники справятся сами и париться не стоит. Но я, наученный опытом внедрения ИИ в своем отделе, понимал, что без базы мы далеко не уедем.
Лекция и долгая установка
Пришлось сделать подробный вводный гайд. Мы разобрали, что такое LLM, токены и контекст, а затем пошагово ставили opencode (CLI/UI) и шли в OpenRouter. Отдельно учились брать бесплатные модели (nemotron 30b free), так как платные мало кто использует, а до китайских сеток люди вообще не добираются.
На прикрепленной фотке я в полуспящем состоянии читаю этот самый гайд по настройке оболочек. В итоге установка, которая в идеальном мире занимает 10 минут, растянулась на добрые полтора часа. 😄
Практика с агентами
Когда мы справились с инфраструктурой, началось самое интересное — запуск Python-агента сначала в песочнице, а потом в проде. Агент должен был выполнять задачи разного профиля, но делал это с заранее заложенными ошибками.
Участникам нужно было разобраться в его логике, найти баги и заставить агента работать правильно.
Крутые итоги
Получилось очень здорово! Мы фактически с нуля научили 35 человек пользоваться opencode и оплатили им доступ к модели GLM (за это отдельное спасибо @listl). Наши ребята попали в топ лидерборда и прокачались в создании агентов.
Дело за малым — осталось обучить технологиям ИИ остальные 1,1 миллиона жителей Уфы! 😄
Думаем летом сделать Vibe Code Night 🍾
🔥6❤1
🍷Классическая романтика продуктовой разработки полна уютных ритуалов:
- многостраничные описания в Google Docs,
- стратегические сессии,
- бесконечные груминги,
- детальные диаграммы пользовательского пути.
🧱Индустрия решила добавить в этот процесс щепотку сурового реализма и максимальной прикладной пользы.
TL;DR: Google обновил формат собеседований для продакт-менеджеров — кандидатов просят открыть Cursor и собрать работающий прототип фичи ровно за 45 минут.
Акаш Гупта любезно подсветил этот новый тренд в X. Процесс оценки уверенно перешел в плоскость создания осязаемых артефактов.
Кандидаты демонстрируют уверенное владение ИИ-инструментами и способность буквально на лету превращать концепции в кликабельный код. Привычные продуктовые фреймворки и красивые презентации теперь дополняются навыком быстрого «вайбкодинга».
Практика для команд:
Способность продакта самостоятельно собрать демо-версию радикально повышает прозрачность процессов. Прототип, созданный за час с помощью Cursor или Bolt, переводит обсуждение гипотез в предметное русло.
Команда разработчиков сразу получает осязаемый контекст, количество слепых зон на планировании стремится к нулю, а идеи обретают форму задолго до попадания в бэклог. Это отличный инструмент для снижения рисков и повышения общей предсказуемости поставки ценности. Навык самостоятельного ИИ-прототипирования уверенно занимает свое место в резюме рядом с CustDev-ом.
Чо как у вас с ИИ? Уже собираете прототипы сами, или пока просто изучаете инструменты? 👇
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥3🤡2❤1
Echpochmak_efficiency-condensed_final.pdf
48.3 MB
Материалы к сегодняшнему выступлению на MergeConf Tatarstan 2026, можно не ходить, а просто посмотреть на презу :)
50 команд и 1 Учпочмак: масштабируемый рецепт эффективности
50 команд и 1 Учпочмак: масштабируемый рецепт эффективности
Статьи на Хабре
• Что такое эффективная команда, почему 91% сотрудников работают вслепую и причем тут «эчпочмак»? Модель «Учпочмак» подробно: три вершины, чек-лист диагностики, статистика. Текстовая основа доклада.
• Предсказуемость и метрики потока
Throughput: как научиться перестать гадать сроки и начать их предсказывать через Monte-Carlo Как использовать Throughput для вероятностных прогнозов. Закон Литтла в действии, Lead Time перцентили, симуляции.
• 5 причин, почему ваши Story Points не работают (и что делать) Почему переход на flow metrics (Cycle Time, Throughput, Lead Time, Aging) даёт более объективную картину, чем Story Points.
• Цели и Feature Factory
Уводим стартап от «конвейерной штамповки фичей». Включаем продуктовый подход и начинаем считать ROI Feature ROI Check и Engineering Cost Check — как понять, какие фичи создают ценность, а какие уходят в никуда.
Источники и литература по вершинам модели
Вершина 1: Цели
• Gallup — State of the Global Workplace gallup.com/workplace Ежегодное исследование вовлечённости.
• McKinsey & Company — исследования по strategy execution mckinsey.com/capabilities/people-and-organizational-performance
• Axios HQ — Employee Communication Report 2024 axioshq.com Исследование о степени согласованности целей сотрудников. Ищите их Annual Employee Communication Report.
Вершина 2: Люди
• Книга: The Fearless Organization (2018) — Harvard Business Review Press amazon.com → "Amy Edmondson Fearless Organization"
• Оригинальное исследование: "Psychological Safety and Learning in Work Teams" (1999) scholar.google.com → "Edmondson 1999 psychological safety"
• Реально виновных в намеренном вредительстве — 1–4%
Google — Project Aristotle rework.withgoogle.com
• Spotify Squad Health Check Model Авторы: Henrik Kniberg, Anders Ivarsson (Spotify). «Spotify Squad Health Check» → оригинальный пост Kniberg на Spotify Engineering blog
• Gallup — роль менеджера. В лучших организациях вовлечённость менеджеров достигает 79% против глобального среднего 22%. gallup.com/workplace
Вершина 3: Предсказуемость
• Daniel Vacanti — Actionable Agile Metrics for Predictability Книга — главный источник по flow metrics для Kanban/Agile.
• David J. Anderson — Kanban Книга: Kanban: Successful Evolutionary Change for Your Technology Business (2010)
• Little's Law L = λW → Lead Time = WIP / Throughput Оригинал: Little, J.D.C. (1961). «A Proof for the Queuing Formula L = λW». Работает для любых стабильных систем.
• Troy Magennis — Monte Carlo для Agile focusedobjective.com Вероятностное прогнозирование на основе исторического Throughput. Шаблоны и инструменты — на сайте (бесплатно).
QBR (Quarterly Business Review)
Atlassian — гайды по QBR atlassian.com/team-playbook Практические шаблоны для квартальных ревью с командами.
Инструменты
• Jira + OKR-плагины для
трассировки задач (OKR Board, BigPicture)
• Predictable Team - анализ и рекомендации по метрикам потока, прогнозирование выполненной работы методом монте-карло
• ActionableAgile Analytics - Flow metrics (Lead Time, Throughput) - из РФ нет доступа
• Monte Carlo Excel шаблоны, вероятностные прогнозы - focusedobjective.com
Марат Киньябулатов
• Телеграм-канал
t.me/predictableteam предсказуемость, метрики, управление командами.
• Habr: habr.com/ru/users/Eskimo
• LinkedIn: linkedin.com/in/maratkinyabulatov
🔥11❤1
🤖 Почему внедрение ИИ не делает разработку быстрее? Наш опыт на масштабе моего подразделения (500 человек)
Все ждут, что AI автоматически ускорит Time-to-Market, но на практике всё гораздо сложнее. Мы проверили три гипотезы ускорения Lead Time (LT) с помощью ИИ на 500 инженерах, и ни одна не сработала так, как ожидалось.
Вот как эволюционировал наш подход:
❌ Гипотеза 1: Дать доступ к LLM = ускорить работу
Мы просто раздали доступы и получили красивый рост использования (MAU) до 50%, но Lead Time не сдвинулся. Оказалось, что использование ИИ в формате чата — это просто «туризм» без формирования привычки. Люди ситуативно играются, но барьер для применения ИИ непосредственно в написании кода остается огромным.
❌ Гипотеза 2: Обучить кодингу через агенты = ускорить работу
Поняв ошибки, мы применили фреймворк изменений ADKAR: заменили рассылки на воркшопы и добились того, что 40% инженеров стали регулярно использовать API агентов. Разработчики стали быстрее писать код, но метрика Lead Time снова не сдвинулась.
Причина: Локальная оптимизация. Мы ускорили только одно звено, но общее время ожидания аналитики и тестирования осталось прежним, поэтому вся цепь не ускорилась.
❌ Гипотеза 3: Agentic Engineering (ИИ забирает весь цикл)
В пилоте 2 разработчика с помощью ИИ взяли на себя e2e ответственность и сделали объем работы фиче-команды из 5 человек. Жизненный цикл разработки (SDLC) сжался, но появилось новое бутылочное горлышко — человек. Чем быстрее агенты генерируют код, тем сильнее перегружаются бизнес-эксперты на валидации требований и лиды на ревью.
💡 Главные системные выводы, которые мы вынесли:
- Считайте людей, а не токены: Количество запросов в дашбордах легко раздувается автоматизацией одного инженера. Поэтому мы смотрим на регулярность. Главная метрика, которая предвосхищает готовность команды к переходу на Agentic Engineering — это когда 80% команды использует агентов 80% рабочих дней (с поправкой на отпуска и выходные).
- ИИ внедряется через Pull, а не Push: Насильно заставить использовать ИИ не получится, это вызывает только сопротивление. Сработали малые демо-группы и демонстрация конкретной пользы («сделаешь 30 DTO за 2 минуты вместо 2 часов»).
- AI не чинит сломанное: Недостаточно ускорить одну команду, нужно работать с системными ограничениями всего потока поставки ценности.
А на каком этапе внедрения AI находится ваша команда: пока просто тестируете чаты или уже решаете проблему перегруза на код-ревью сгенерированного кода? Делитесь в комментариях! 👇
Все ждут, что AI автоматически ускорит Time-to-Market, но на практике всё гораздо сложнее. Мы проверили три гипотезы ускорения Lead Time (LT) с помощью ИИ на 500 инженерах, и ни одна не сработала так, как ожидалось.
Вот как эволюционировал наш подход:
❌ Гипотеза 1: Дать доступ к LLM = ускорить работу
Мы просто раздали доступы и получили красивый рост использования (MAU) до 50%, но Lead Time не сдвинулся. Оказалось, что использование ИИ в формате чата — это просто «туризм» без формирования привычки. Люди ситуативно играются, но барьер для применения ИИ непосредственно в написании кода остается огромным.
❌ Гипотеза 2: Обучить кодингу через агенты = ускорить работу
Поняв ошибки, мы применили фреймворк изменений ADKAR: заменили рассылки на воркшопы и добились того, что 40% инженеров стали регулярно использовать API агентов. Разработчики стали быстрее писать код, но метрика Lead Time снова не сдвинулась.
Причина: Локальная оптимизация. Мы ускорили только одно звено, но общее время ожидания аналитики и тестирования осталось прежним, поэтому вся цепь не ускорилась.
❌ Гипотеза 3: Agentic Engineering (ИИ забирает весь цикл)
В пилоте 2 разработчика с помощью ИИ взяли на себя e2e ответственность и сделали объем работы фиче-команды из 5 человек. Жизненный цикл разработки (SDLC) сжался, но появилось новое бутылочное горлышко — человек. Чем быстрее агенты генерируют код, тем сильнее перегружаются бизнес-эксперты на валидации требований и лиды на ревью.
💡 Главные системные выводы, которые мы вынесли:
- Считайте людей, а не токены: Количество запросов в дашбордах легко раздувается автоматизацией одного инженера. Поэтому мы смотрим на регулярность. Главная метрика, которая предвосхищает готовность команды к переходу на Agentic Engineering — это когда 80% команды использует агентов 80% рабочих дней (с поправкой на отпуска и выходные).
- ИИ внедряется через Pull, а не Push: Насильно заставить использовать ИИ не получится, это вызывает только сопротивление. Сработали малые демо-группы и демонстрация конкретной пользы («сделаешь 30 DTO за 2 минуты вместо 2 часов»).
- AI не чинит сломанное: Недостаточно ускорить одну команду, нужно работать с системными ограничениями всего потока поставки ценности.
А на каком этапе внедрения AI находится ваша команда: пока просто тестируете чаты или уже решаете проблему перегруза на код-ревью сгенерированного кода? Делитесь в комментариях! 👇
1🔥14👍2👏2
Kiniabulatov_Marat-AI-Adoption_DUMP_(bq).pdf
17.7 MB
Привет старичкам и всем новичкам ♥️
Преза с выступления сегодня на DUMP (о чем она - пост выше).
📚 Доп. материалы:
• Мысли вслух: Как AI-агенты меняют процесс разработки в разных типах проектов (Хабр)
• ИИ-ассистенты не ломают поддерживаемость кода. Но есть нюансы (выжимка из исследования Echoes of AI) (Хабр)
• Что такое ADKAR. - фреймворк управления изменениями в организациях
• Серия постов про внедрение AI (цель, изменения, мероприятия, события, ограничения)
- Изменение роли QA в эпоху ИИ
- Что такое эффективная команда и как на это смотреть на масштабе
Преза с выступления сегодня на DUMP (о чем она - пост выше).
📚 Доп. материалы:
• Мысли вслух: Как AI-агенты меняют процесс разработки в разных типах проектов (Хабр)
• ИИ-ассистенты не ломают поддерживаемость кода. Но есть нюансы (выжимка из исследования Echoes of AI) (Хабр)
• Что такое ADKAR. - фреймворк управления изменениями в организациях
• Серия постов про внедрение AI (цель, изменения, мероприятия, события, ограничения)
- Изменение роли QA в эпоху ИИ
- Что такое эффективная команда и как на это смотреть на масштабе
1🔥10✍2👍2❤🔥1
AI_Engineering_Report_2026_The_Acceleration_Whiplash_Faros.pdf
1.8 MB
🚀 Парадокс 2026 года: мы стали писать код быстрее, но качество летит в пропасть
Каждую неделю у меня по расписанию агент подкидывает все последние новости из AI + SDLC + Management исследований. Сегодня поделюсь отчетом от Faros AI: я наблюдаю очень похожие выводы на своем масштабе - а тут они подтверждаются сильнее). Отчет приложил.
Вышел мощный отчёт Faros AI, основанный не на опросах в духе «как вам кажется?», а на суровой телеметрии 22 000 разработчиков. Аналитики назвали новый феномен «Acceleration Whiplash» (травма хлыстом от ускорения).
Суть: ИИ-инструменты (Copilot, Cursor, Claude Code и другие) позволяют двигать роудмапы, но при этом ломают на части процессы ревью и тестирования. Наш старый процесс просто не рассчитан на новую скорость генерации кода (раз, два).
📈 Что хорошего в отчете про ИИ (где AI реально ускоряет):
- Закрытых эпиков на разработчика: +66%
- Количество закрытых задач (throughput): +34%
📉 Где скрыта боль (тот самый Whiplash):
- Количество багов на разработчика: +54%
- Инциденты на один PR: +242% (каждый мёрдж стал почти втрое опаснее!)
- Средний размер PR вырос на 51%
- Время ревью одного PR увеличилось в 5 раз
🧠 Почему так происходит?
ИИ отлично генерирует код, но не понимает ваш архитектурный контекст. Инженер быстро(если долго смотреть станет плохо) принимает сгенерированный блок и отправляет его дальше. Главный защитный механизм индустрии — «маленькие PR до 400 строк» — сейчас сломан.
На ревьюера падает огромный кусок логики. Его когнитивная нагрузка зашкаливает (об этом я говорил на докладе на прошлой неделе). Итог: на 31% выросла доля PR, которые мёрджатся вообще без содержательного ревью (просто не глядя).
🛠 Что с этим делать тимлидам и руководителям?
1. Верните жёсткие лимиты на размер PR
Исследования (в т.ч. от Microsoft) показывают: PR больше 400 строк ревьюить бесполезно, мозг переходит в режим слепого скроллинга. Вшивайте в обвязку (agent harness) автоматические гайды и алерты на огромные многофайловые коммиты от ИИ.
2. Меняйте метрики.
«Строки кода» и «количество PR» больше ничего не значат (AI легко их накрутит). Смотрите на Code Churn (сколько строк пришлось удалить/переписать после мёрджа) и Incidents per PR (ошибок на PR - и аварий, и багов).
3. Инженеры-люди нужны как никогда.
Сокращать штат с мыслью «AI напишет код за них» — фатальная ошибка. Вам нужны сильные (senior) инженеры именно как надёжный буфер на код-ревью между ИИ-генератором и вашим продакшеном. Именно такие синьоры, которые умеют выстроить систему, которая будет справляться (качественно) с новым объемем артефектов от агентов.
В 2026 году выигрывает не та команда, которая генерирует больше кода, а та, которая смогла перестроить пайплайны ревью под эти сумасшедшие объёмы - заключает исследование
👍 Больше про системную работу с эффективностью команд + AI в блоге Марата Киньябулатова про предсказуемые команды
Каждую неделю у меня по расписанию агент подкидывает все последние новости из AI + SDLC + Management исследований. Сегодня поделюсь отчетом от Faros AI: я наблюдаю очень похожие выводы на своем масштабе - а тут они подтверждаются сильнее). Отчет приложил.
Вышел мощный отчёт Faros AI, основанный не на опросах в духе «как вам кажется?», а на суровой телеметрии 22 000 разработчиков. Аналитики назвали новый феномен «Acceleration Whiplash» (травма хлыстом от ускорения).
Суть: ИИ-инструменты (Copilot, Cursor, Claude Code и другие) позволяют двигать роудмапы, но при этом ломают на части процессы ревью и тестирования. Наш старый процесс просто не рассчитан на новую скорость генерации кода (раз, два).
📈 Что хорошего в отчете про ИИ (где AI реально ускоряет):
- Закрытых эпиков на разработчика: +66%
- Количество закрытых задач (throughput): +34%
📉 Где скрыта боль (тот самый Whiplash):
- Количество багов на разработчика: +54%
- Инциденты на один PR: +242% (каждый мёрдж стал почти втрое опаснее!)
- Средний размер PR вырос на 51%
- Время ревью одного PR увеличилось в 5 раз
🧠 Почему так происходит?
ИИ отлично генерирует код, но не понимает ваш архитектурный контекст. Инженер быстро
На ревьюера падает огромный кусок логики. Его когнитивная нагрузка зашкаливает (об этом я говорил на докладе на прошлой неделе). Итог: на 31% выросла доля PR, которые мёрджатся вообще без содержательного ревью (просто не глядя).
🛠 Что с этим делать тимлидам и руководителям?
1. Верните жёсткие лимиты на размер PR
Исследования (в т.ч. от Microsoft) показывают: PR больше 400 строк ревьюить бесполезно, мозг переходит в режим слепого скроллинга. Вшивайте в обвязку (agent harness) автоматические гайды и алерты на огромные многофайловые коммиты от ИИ.
2. Меняйте метрики.
«Строки кода» и «количество PR» больше ничего не значат (AI легко их накрутит). Смотрите на Code Churn (сколько строк пришлось удалить/переписать после мёрджа) и Incidents per PR (ошибок на PR - и аварий, и багов).
3. Инженеры-люди нужны как никогда.
Сокращать штат с мыслью «AI напишет код за них» — фатальная ошибка. Вам нужны сильные (senior) инженеры именно как надёжный буфер на код-ревью между ИИ-генератором и вашим продакшеном. Именно такие синьоры, которые умеют выстроить систему, которая будет справляться (качественно) с новым объемем артефектов от агентов.
В 2026 году выигрывает не та команда, которая генерирует больше кода, а та, которая смогла перестроить пайплайны ревью под эти сумасшедшие объёмы - заключает исследование
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5💯2