Любопытное начало серии постов в блоге DEV.BIZ.OPS, которые открывает статья с провокационным заголовком: Developer Experience is Dead
Новые инструменты, как новые игрушки, - признается автор. Разбираться, строить, пробовать и составлять что-то новое из частей в природе разработчика (поэтому у многих есть коллекции лего). Теоретически, чем лучше инструменты, тем лучше результат, и вот все уже кинулись улучшать “опыт разработчика”. В 2021 на глобальном рынке инструментов для разработчиков было 1286 продуктов. И продаются они не сверху вниз, как было раньше, теперь решения все чаще даже в больших компаниях за теми, кто будет пользоваться покупкой в своей работе. Концепция более-менее устоялась и включает в себя:
- Опыт использования продукта (продуктивность, функциональность, UI/UX)
- Документация
- Онбординг - насколько легко начать использовать
- Поддержка
- Осведомленность - как узнают про инструмент (блоги, видео, гитхаб, вебинары и конференции)
- Сообщество
Все пункты важные, а все же то, как понимали DE уже не работает. Кривое управление командой не исправить идеальными инструментами, сколько бы на них не тратили бюджета. Нужны окружение, культура и процесс.
Продолжение во второй статье Enablers of Developer Flow, где Mark Birch делится опытом внедрения Stack Overflow Teams. Продукт любимый и популярный, вызвал большой энтузиам, но у некоторых не прижился и не из-за проблем самого инструмента, а из-за процессов вокруг разработки. Продуктивность, с точки зрения автора, это все, что “помогает коду возникнуть” и влияет на процесс - “активация” (Enablement) разработчика. На чем она основана:
- Развитие талантов
- Сотрудничество - как мы общаемся и вместе работаем
- Управление знаниями
- Планирование загрузки
- Показатели здоровья “активации” - как мы измеряем эффективность и продуктивность команд
- Культура - как мы встраиваем общие ценности и организационное видение.

Часть этих “столпов” уже охвачена HR, общая работа зависит от команды Платформ, а загрузку планируют продакты или команда аджайл. Но у областей нет того, кто мог бы окинуть их единым взглядом и понять, как вносить изменения так, чтобы команды были более продуктивны с инженерной точки зрения. Это должна быть отдельная роль, а впоследствии отдельная команда, управляющая всеми аспектами “активации”. #конспект