«DevOps. Ускоряйся» (Accelerate)

Короче есть история, что книги полезно перечитывать (ладно, хорошие книги).

Почему?

Ну потому что, вы меняетесь и ваши фокусы и понимание разных вещей меняется.

Тут вот я на досуге решил перечитать “Acceletate”.

Ииииии
В глаза бросился просто огромный и очень важный блок про опросы и метрики, который часто недооценивают (ладно, это я его прошлый раз недооценил).
Речь именно про научную теорию составления опросов.

Авторы прямо говорят: измерять всё «по логам» и метрикам из CI/CD — не всегда работает. Нужно комбинировать количественные данные и опросы инженеров.

Зачем нужны опросы?

Метрики без контекста мало что значат. Лог показывает, что сборка идёт 20 минут, но это может не быть проблемой, если разработчик параллельно работает над другим.

Опросы фиксируют восприятие. Важен не только факт, но и то, как команда его чувствует.
Субъективное мнение → объективный прогноз. Авторы доказали: восприятие инженеров хорошо коррелирует с реальными бизнес-результатами.

Как правильно проводить опросы по Accelerate?

1.
Использовать Likert-шкалы (от 1 до 7).
Вопросы должны быть оценочными:
«Как вы оцениваете скорость релизов?»
«Насколько просто вам катить изменения в прод?»
«Часто ли вы ощущаете, что процесс разработки мешает вам?»

2.
Фокус на восприятии, а не на цифрах.
Не спрашивай «Сколько минут билдится CI?».
Лучше «CI билдится достаточно быстро, чтобы не мешать работе?»

4.
Регулярность.
Обычно раз в квартал.
Главное - динамика, а не абсолютные цифры.

5.
Сравнение разных групп.
Сравнивать команды между собой, выявлять «локальных чемпионов» и «узкие места».

6.
Анонимность.
Ключ, чтобы люди честно говорили о проблемах.

Какие вопросы работают (по Accelerate)?

1.
Flow / скорость:
«Мы можем быстро выпускать изменения, когда это нужно бизнесу».

2.
Качество:
«Когда мы выкатываем изменения, мы уверены в их стабильности».

3.
Процессы:
«Текущие практики тестирования/релизов помогают, а не мешают нам».

4.
Культура:
«В нашей команде безопасно предлагать новые идеи и экспериментировать».

Главное правило
Авторы подчёркивают:
📊 Инженерные опросы - это такие же метрики, как и цифры из логов.
Если разработчики говорят: «CI работает медленно» - это уже проблема, даже если объективно он идёт 10 минут.

❤️ - если забрал в бэклог
🔥 - если читал и зашло
💊 - читал и не зашло

@badtechproject

Короче, я уже 2 часа на родительском собрании! 🆘

Наташка отказывается писать учительнице, что меня начальник вызвал на работу и, чтобы меня отпустили пораньше

😁

@badtechproject

Ну чисто мы?

#пятничное

@badtechproject

AI замедляет разработчиков

Ага-ага, сегодня у нас шок контент- исследование от серьезных ребят (METR), утверждающее, что AI замедляет разработчиков.

В пятницу вечером с Сашей Поломодовым сделали Разбор отчета METR "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", где показано замедление разработчиков при использовании AI.

Что нам удалось обсудить:
1.
Дизайн самого исследования:
246 задач, 16 инженеров, Open Source 10-й летний проект, все инженеры знакомы с проектом.

2.
Причины замедления работы.

3.
Наши основные когнитивные искажения при оценке задач.

В целом, я считаю супер полезное исследование для тех менеджеров, кто уже «готов заменить всех разработчиков».
Здесь нет победных реляций, а скорее намек на то, что в вашем легаси AI не сможет сейчас решать сложные задачи эффективнее инженеров: сложность и запутанность кода, неумение моделей удержать весь объем проекта и т.п.
То есть, исследование - здравая оценка реальных возможностей моделей на текущий момент.

Единственный минус - выборка в 16 инженеров.

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

@badtechproject

Команда Яндекса

Ну что, пришло время добавить себе приставку ex- в мой профиль про Яндекс.

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

1.
Если ты попал в Яндекс, то ты уже особенный: лучший из лучших.

2.
Если ты работал в Яндексе, внутри тебя навсегда останется культура бунтарства и желание докопаться до сути!

Это и, правда, то, что я заберу с собой!

Команда платформы, спасибо! Вы невероятно крутые.
Мы прошли сложный путь продуктовой трансформации, а для инженерных продуктов это ой как сложно (вы пробовали делать демо для языковых фреймворков?😉). Я уверен, что дальше будет только больше! Не теряйте драйв и задор!

P.S. До понедельника я отдыхаю, а там будем он-бордиться и сталкиваться с новыми вызовами!

Stay tuned😉

@badtechproject

Видели вчера презентацию новых iPhone’ов?
Стырили топовый цвет моей жилетки😁

Мой пост еще от 4-го июня))

Оп, а завтра вечером у нас будет он-лайн эфир на big tech night

Зацените, какие вопросы я накидал в дискуссию (все вопросы задавать не буду, это множество вопросов 😉
Ну а блиц- скрыт от участников, пока)

0) Разогрев — выровнять контекст
Какой самый дорогой фейл в кросс-деп проектах у вас за 2 года и чему он научил?
1) Команда, роли, ответственность
Кто принимает решение, когда «горит», и как это зафиксировано в одной странице?
Как делите людей и бюджет между тремя одновременными P0?
Какой общий KPI реально склеивает департаменты, а какой ломает поведение?
Как оформляете ответственность так, чтобы ошибки не прятались под ковёр?
2) Приоритеты клиентов и стейкхолдеров
По какой процедуре говорите «нет» крупному клиенту, если это ломает дорожную карту?
Есть ли общая очередь заявок для всех клиентов и как исключаете «кто громче, тот прав»?
Как проверяете, что крупный клиент не «высасывает кислород» у остальных?
3) Сопротивление изменениям
Топ-3 аргумента против внедрения, с которыми сталкивались, и как вы их переводите в ценность?
Как выбираете пилот так, чтобы через 6 недель было невозможно откатить?
Что обещаете не делать (границы продукта), чтобы не пугать клиента?
4) Продажа продукта (внутренняя и внешняя)
Кого берёте первым: спонсора с бюджетом или с влиянием — и почему?
Как монетизируете экономию времени/рисков для внутренних клиентов (showback/chargeback)?
Как выглядит «дека продажи» в 5 слайдов для ExCo, депглав и инженеров?
5) Процессы, бюрократия, метрики
Какие два регламента реально экономят деньги и защищают от «козлов отпущения»?
Какая метрика у вас диагностическая (а не кнутовая) и как отделяете outcome от output?
Какой минимальный устойчивый ритм синков и по какому правилу вы отменяете встречи?
6) Зависимости и риски
Как визуализируете критические зависимости между департаментами на одной странице?
Что у вас считается корректной эскалацией и какой SLA на ответ?
Какие «kill-criteria» для остановки потока работ и кто их утверждает?
7) Исполнение: от стратегии к поставке
Как планируете внедрение в три волны и кто идёт в каждой?
Что точно показываете на день 90 и какими KPI меряете ценность?
Как контролируете техдолг/процессный долг, не тормозя релизы?
8) Культура и люди
Как делаете безопасным раннее признание рисков (pre-mortem, ретро, форматы)?
Где проходит граница между платформенными и продуктовыми командами (контракт интерфейса)?
Какими наградами/санкциями усиливаете поведение, которое «склеивает» организацию?
9) Кейсы «на разбор» (сценарии по 60 сек)
VIP-фича ломает архитектуру: берём или отказываем? На каких условиях?
Общий релиз, один департамент не готов: ship или skip? Кто решает?
После внедрения метрика ухудшилась: что делаете на неделе 1/4/12?
Бюджет урезали на 30%: что режете первым и почему это честно?
10) Закрытие
Один артефакт, который вы внедрите завтра, и один, который уберёте.
Один совет «себе трёхлетней давности» про большие программы.
Одна вещь, без которой любые метрики не работают.

Как вам вопросы?
🔥 - если по кайфу
❤️ - если бы ты сделал лучше

@badtechproject