Developer Ecosystem 2025

Мы в JetBrains каждый год проводим огромнейший опрос разработчиков из разных стеков, чтобы получше разобраться, как меняется технологический ландшафт. Держите самый свежий репорт! Вот некоторые из интересных фактов:

👉Языки, на которые разработчики хотят перейти: Go, Rust, Python, Kotlin, TypeScript.
👉Ruby совсем умирает, за последние 8 лет доля упала с 15% до 4%. Похожее падение есть и у PHP, но доля там остается все еще большой.
👉Самые частые задачи, делегируемые AI – написание бойлерплейта, поиск информации в интернете и конвертация кода из одного языка в другой. Самые редкие – общение в почте и мессенджерах, написание бизнес-логики, выполнение действий в терминале.
👉Самые большие опасения разработчиков относительно AI – качество сгенерированного кода, невозможность AI понять сложную логику, приватность и негативное влияние на навыки программирования. Только у 1% нет никаких опасений.
👉88% использующих AI верят в то, что экономят больше часа в неделю. 19% говорят про экономию больше 8 часов.
👉Восприятие текущего рынка вакансий сильно зависит от страны. Лучше всего дела обстоят в Японии и Испании. Хуже всего – в Южной Корее, Канаде и Китае. Восприятие так же зависит от уровня опыта – на сложности жалуются 61% джунов и только 34% сеньоров.
👉Страна влияет и на восприятие сложности конкретных задач. Например, на контекст свитчинг среди восточноевропейцев жалуются 54%, а среди японцев только 14%.
👉Немного статы про выгорание. Среди работников больших компаний на выгорание жалуются 47%, а среди маленьких только 11%. Среди джунов – 61%, среди людей с опытом в 16+ лет – 38%.

Метрики DORA: как понять, что команда не просто занята, а реально хорошо доставляет изменения 🚀

Иногда кажется, что команда всё время что-то делает: задачи двигаются, созвоны идут, релизы случаются, все заняты по уши.

Но занятость ≠ эффективность 👀
Чтобы понять, насколько команда правда хорошо доставляет изменения, часто смотрят на метрики DORA.

Их всего четыре:

1. Deployment Frequency
Как часто команда выкатывает изменения в прод.
Если релизы редкие, обратная связь тоже приходит медленно.

2. Lead Time for Changes
Сколько времени проходит от изменения в коде до продакшена.
Тут уже видно скорость не одного разработчика, а всей системы целиком: код, ревью, тесты, согласования, релиз.

3. Change Failure Rate
Какой процент изменений приводит к проблемам: багам, откатам, инцидентам 😬
Эта метрика помогает понять, не покупаете ли вы скорость ценой качества.

4. Time to Restore Service
Сколько времени нужно, чтобы восстановиться после сбоя.
Проблемы случаются у всех. Вопрос в том, как быстро команда приходит в норму.

Почему DORA полезны?
Потому что они показывают картину сразу с двух сторон:

⚡ насколько быстро вы доставляете изменения
🛡️ насколько стабильно вы это делаете

То есть не просто “мы часто релизимся” или “у нас всё надежно”, а более честный взгляд на delivery.

Для тимлида это особенно ценно, потому что можно говорить не ощущениями:

❌ “кажется, мы долго всё возим”
✅ “у нас lead time 8 дней, релиз раз в 2 недели, и каждый 4-й релиз требует фиксов”

И тут уже гораздо легче понять, где проблема на самом деле:
• в долгом ревью
• в ручном тестировании
• в согласованиях
• в релизном процессе
• в слабой реакции на инциденты

Но тут важно помнить одну вещь 🙏
DORA — это не метрики для оценки отдельных людей.
Это метрики системы.

Их смысл не в том, чтобы найти “медленного” разработчика,
а в том, чтобы увидеть, где у команды проседает весь поток работы.

Если совсем по-простому:
DORA помогают понять, насколько быстро, стабильно и предсказуемо команда довозит изменения до прода.

А это уже намного полезнее, чем просто смотреть, кто сколько задач закрыл 📊

#тимлид #dora #delivery #менеджмент #лидерство

Job Demands-Resources: почему команда выгорает не просто от большого количества задач 👀

Иногда со стороны всё выглядит логично:
ну да, работы много, вот люди и устали.

Но на практике команда выгорает не только от объема работы.
Очень часто проблема глубже — в дисбалансе между нагрузкой и ресурсами.

Именно про это модель Job Demands-Resources.

Если по-простому, у любой команды есть две стороны:

🔻 Demands — всё, что требует сил
Это не только количество задач, но и:

- постоянные переключения
- хаос в приоритетах
- срочность
- неясные постановки
- сложные согласования
- конфликты
- эмоционально тяжелая коммуникация

🔹 Resources — всё, что помогает с этим справляться
Например:

- понятные цели
- ясные приоритеты
- автономия
- поддержка лида
- нормальная обратная связь
- сильные коллеги рядом
- адекватные процессы
- ощущение, что работа имеет смысл

И вот в чем важная мысль:
людей ломает не просто “много работы”, а ситуация, когда demands растут, а resources не хватает.

Можно выдерживать высокий темп, если:

- понятно, что делать
- зачем это делать
- что сейчас главное
- где можно попросить помощь
- и что ты не один на один с этим всем

А можно устать даже от не самого большого объема, если вокруг:

- хаос
- постоянное “срочно”
- меняющиеся вводные
- отсутствие поддержки
- и ощущение, что ты всё время не успеваешь неизвестно куда

Для тимлида здесь очень важный вывод 💡
Его работа — не только раздавать задачи.

Его работа — еще и строить среду, в которой команда может эти задачи вывезти.

Не всегда можно убрать всю нагрузку.
Но почти всегда можно добавить ресурсов:

- сделать приоритеты понятнее
- убрать лишние переключения
- снизить хаос
- зафиксировать ожидания
- дать больше ясности и опоры

Иногда команда устает не потому, что люди “слабые”.
А потому что система долго забирает силы и почти ничего не дает взамен.

И вот это тимлиду полезно замечать как можно раньше.

#тимлид #лидерство #менеджмент #выгорание #jdr

Как ИИ‑агенты меняют управление IT‑проектами https://habr.com/p/1022176/

'Я не менеджер, я просто промпт написал': как ИИ делает управленческие функции частью повседневной инженерной практики

Разработчики используют Claude Code, код появляется быстрее, результат на первый взгляд выглядит прилично, но продукт не выходит к клиенту быстрее, баги не исчезают, а на проверку кода уходит больше времени, чем раньше. Менеджер смотрит на метрики и видит, что команда делает больше. Потом смотрит на продукт – и не видит соразмерного результата. В чем дело?

Каждый, кто работает с ИИ, теперь сам принимает решения как разбить задачу на части, сам оценивает качество того, что выдала модель, сам решает доверять ей или нет. Это все управленческие функции. Но тот же ИИ маскирует некомпетентность и создаёт иллюзию продуктивности. Получается, что ИИ превращает исполнителей в менеджеров - только недообученных.

Читать без VPN

Maker’s Schedule vs Manager’s Schedule: почему встречи ломают разработку

Иногда кажется, что часовая встреча — это просто часовая встреча.

Ну, подумаешь, поставили созвон с 11:00 до 12:00.
Потом ещё один с 14:00 до 15:00.
Вроде бы у разработчика всё равно остаётся несколько свободных часов.

Но проблема в том, что разработка плохо живёт в нарезке по часу.

Чтобы нормально разобраться в задаче, нужно загрузить контекст в голову:
что меняем, где это лежит, какие есть ограничения, что уже пробовали, какие могут быть побочные эффекты.

И только ты более-менее вошёл в поток — звонок.

После звонка нужно снова вернуться, вспомнить, где остановился, открыть файлы, восстановить мысль. Формально встреча заняла час. По факту она могла сломать половину дня.

Пол Грэм хорошо описывал эту разницу через два типа расписания:

Manager’s Schedule — день менеджера легко режется на слоты по 30–60 минут.
Встреча, ещё встреча, синк, обсуждение, планирование.

Maker’s Schedule — день человека, который что-то создаёт, работает большими непрерывными блоками.
Код, архитектура, дизайн, текст, анализ — всё это требует длинного фокуса.

И вот тут появляется типичная проблема тимлида.

Тимлид часто живёт в manager’s schedule, а команда — в maker’s schedule.
Если об этом не помнить, можно случайно начать оптимизировать свой календарь за счёт фокуса команды.

Например:

— поставить короткий синк посреди утра;
— разбить день разработчика двумя “быстрыми вопросами”;
— назначить обсуждение на 16:00, когда человек почти добрался до решения;
— постоянно дёргать в личке, потому что “там же всего один вопрос”.

Каждое такое действие выглядит маленьким.
Но вместе они превращают рабочий день в кашу.

Что можно попробовать:

1. Блоки без встреч
Например, не ставить встречи команде до обеда или выделить 2–3 дня в неделю с длинными фокусными окнами.

2. Office hours для вопросов
Не дёргать разработчика хаотично, а собирать вопросы в конкретное окно.

3. Async-first для несрочного
Если вопрос не требует живого обсуждения прямо сейчас, лучше написать контекстом: что случилось, что нужно решить, какие варианты уже есть.

4. Не путать доступность и эффективность
Если человек быстро отвечает в мессенджере, это не значит, что он эффективно работает. Иногда это значит, что он вообще не может сфокусироваться.

Мне кажется, одна из задач тимлида — не просто ходить на встречи самому, а ещё и защищать команду от лишних встреч.

Потому что фокус — это тоже ресурс команды.
И его очень легко потратить незаметно.

А у вас что чаще ломает рабочий фокус: встречи или внезапные “быстрые вопросы”?

Как понять, что команда занята, но не движется

Есть неприятная ситуация, знакомая многим тимлидам.

Команда вроде бы постоянно что-то делает.
Задачи в Jira двигаются.
Созвоны идут.
В чатах активность.
На дейли все рассказывают, чем заняты.

Но если посмотреть на результат, возникает странное ощущение:
движения много, а прогресса мало.

Это один из самых опасных режимов для команды — высокая занятость без нормального потока результата.

Снаружи всё выглядит живым.
Внутри система может быть забита ожиданиями, переключениями и незавершённой работой.

На что я бы смотрел в первую очередь.

1. Много задач “в работе”

Если у каждого разработчика по 3–5 активных задач, это не многозадачность.
Это очередь из незавершёнки.

Человек переключается между контекстами, что-то ждёт, что-то чинит, что-то “почти доделал”.
В итоге задач много, завершённых мало.

2. Задачи долго ждут ревью

Очень частый затык.

Код написан, но не принят.
Разработчик уже ушёл в новую задачу.
Потом прилетают комментарии, нужно снова вспомнить старый контекст.
Потом ещё один круг.

Формально работа идёт.
Фактически задача стоит в очереди.

3. Слишком много статусов и мало смысла

Если процесс выглядит красиво, но никто не может быстро объяснить, где именно тормозит задача, статусы не помогают.

“В работе”, “на проверке”, “на тестировании”, “ожидает релиза” — это полезно только если команда понимает, что с этим делать.

4. Регулярно появляются срочные задачи

Когда каждый день прилетает “вот это надо срочно”, план перестаёт быть планом.

Команда вроде бы занята, но не тем, что собиралась делать.
А потом на ретро все удивляются, почему спринт опять не сошёлся.

5. Много обсуждений, но мало решений

Созвон был.
Поговорили хорошо.
Разошлись.

А кто принимает решение?
Что делаем дальше?
Кто владелец?
Когда вернёмся к вопросу?

Если после встречи нет следующего действия, встреча легко превращается в имитацию движения.

Мне кажется, здесь важно перестать спрашивать только:

“Все ли заняты?”

И начать спрашивать:

“Что мешает задачам завершаться?”

Потому что эффективность команды — это не количество параллельной активности.
Это способность стабильно доводить важные изменения до результата.

Что можно сделать практически:

1. Посмотреть, сколько задач сейчас одновременно в работе.
2. Найти задачи, которые дольше всего висят без движения.
3. Отдельно посмотреть очередь на code review.
4. Выписать все внеплановые задачи за последние 2 недели.
5. На ретро обсуждать не “кто не успел”, а “где поток ломается”.

Иногда команда не медленная.
Иногда она просто забита работой, которая мешает другой работе завершаться.

А у вас где чаще всего застревают задачи: разработка, ревью, тестирование, согласования или релиз?

AI-native команда — это не команда, где все просто пользуются AI

Прочитал статью How Anthropic Builds AI-Native Engineering Teams про то, как Anthropic строит инженерные команды вокруг AI:
https://newsletter.eng-leadership.com/p/how-anthropic-builds-ai-native-engineering

Главная мысль: AI-native — это не “разработчики иногда просят AI написать код”.

Это процесс, в котором AI встроен в работу команды: от проектирования и реализации до тестов, ревью и проверки результата.

И тут есть несколько важных выводов.

1. Структура команды не исчезает

AI может ускорять разработку, но он не отменяет ownership, архитектуру, поддержку, коммуникацию и ответственность за качество.

Команде всё ещё нужны люди, которые понимают систему и отвечают за результат.
Подписка на AI, как выяснилось, не заменяет мышление. Неловко вышло.

2. Каждый инженер становится немного tech lead

С AI команда может вести больше направлений параллельно: быстрее писать код, тесты, документацию, черновики решений.

Но больше параллельности — это не всегда больше результата.

Если ревью, принятие решений и приоритизация остались медленными, команда просто быстрее создаёт WIP и очереди.

AI не лечит плохой фокус.
Он может сделать хаос более производительным.

3. Роль PM / TPM становится важнее

Когда реализация ускоряется, главный вопрос меняется.

Не “можем ли мы это сделать?”,
а “правильную ли вещь мы сейчас делаем?”

AI помогает быстрее строить решения.
Но он не обязан понимать бизнес-эффект, пользователя, ограничения и приоритеты.

Чем быстрее команда может писать код, тем дороже становится плохая приоритизация.

4. Ревью AI-generated кода — новый важный навык

Инженер уже не просто пишет код руками.
Он формулирует задачу, управляет AI-агентом, проверяет результат, смотрит на архитектурные последствия и отвечает за итог.

AI может написать код.
Ответственность за этот код всё равно остаётся на человеке.

5. Важно описывать результат, а не задачу

Плохой запрос:
“Сделай дашборд”.

Нормальный запрос:
“Нужен дашборд, который помогает понять, где команда теряет время: в ревью, ожидании требований, тестировании или согласованиях”.

AI лучше работает, когда есть контекст, критерии успеха и ограничения.

Как и люди, внезапно.

Главный вывод

AI-native команда — это не про инструменты.
Это про зрелость процесса.

Если у команды есть фокус, понятные приоритеты, хорошее ревью, тесты и ownership — AI может дать сильное ускорение.

Если этого нет, AI просто ускорит хаос.

Вопрос не в том, используют ли разработчики AI.

Вопрос в другом:

готова ли система команды к тому, что разработка станет быстрее?

AI не решит проблему плохого фокуса

Есть соблазнительная мысль:

если разработчики будут использовать AI, команда начнёт работать быстрее.

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

Но есть нюанс.

AI ускоряет исполнение внутри задачи.
Он не чинит систему, в которой задачи постоянно прерываются, переоткрываются, ждут ревью, меняют приоритет и теряют контекст.

Если у команды плохой фокус, AI может сделать ситуацию даже хуже.

Почему?

Потому что раньше человек физически не успевал создать слишком много незавершённой работы.
А теперь успевает.

Можно быстрее написать код.
Быстрее открыть pull request.
Быстрее нагенерировать вариантов.
Быстрее начать следующую задачу.

Но если ревью и принятие решений не ускорились, очередь просто переезжает в другое место.

Получается странная картина:

— кода стало больше;
— pull request’ов стало больше;
— обсуждений стало больше;
— а delivery быстрее не стал.

И тимлид в этот момент может попасть в ловушку.

На уровне активности всё выглядит хорошо.
Команда “использует AI”, задач в работе много, артефакты появляются быстрее.

Но продуктовая ценность всё равно выходит медленно.

Проблема в том, что AI хорошо помогает на уровне отдельного исполнителя, но delivery — это командная система.

В ней есть:

— постановка задачи;
— понимание цели;
— декомпозиция;
— архитектурные решения;
— ревью;
— тестирование;
— релиз;
— обратная связь от пользователей.

Если узкое место не в написании кода, ускорение написания кода не даст большого эффекта.

Простой пример.

Команда страдает от того, что задачи плохо подготовлены.
Разработчики постоянно уточняют требования, спорят с аналитиками, ждут решений от бизнеса.

Внедрили AI.

Теперь код по неясным требованиям появляется быстрее.
Но требования от этого не стали яснее.

Или другой пример.

Главный bottleneck — code review.
Ревью и раньше висели по 2–3 дня.

С AI разработчики стали быстрее открывать pull request’ы.
Очередь на ревью выросла.
Lead time не улучшился, а ревьюеры начали уставать ещё сильнее.

Поэтому я бы не начинал внедрение AI с вопроса:

“Как нам писать код быстрее?”

Я бы начал с другого:

“Где у нас сейчас реально тормозит поток работы?”

Если тормозит boilerplate — AI поможет.

Если тормозит ревью — нужны правила ревью, размер PR, ownership, возможно, AI-помощники для первичной проверки.
Если тормозит постановка задач — нужен лучший discovery и Definition of Ready.
Если тормозит релиз — надо смотреть CI/CD, тесты, согласования и rollback.

AI — это усилитель.
Но он усиливает не только хорошее.

Если в команде порядок, он может дать хороший прирост.
Если в команде хаос, он может просто помочь производить хаос быстрее.

Что можно сделать тимлиду:

1. Перед внедрением AI посмотреть текущий flow.
2. Найти реальное узкое место.
3. Не мерить эффект только количеством написанного кода.
4. Смотреть на lead time, cycle time, ревью, баги и возвраты.
5. Договориться с командой, где AI помогает, а где создаёт риск.

Мне кажется, главный вопрос про AI в разработке сейчас не “заменит ли он программистов”.

Более практичный вопрос:

какую часть нашей системы он ускорит, и не сломается ли от этого всё остальное?

А у вас AI уже ускорил delivery или пока только написание кода?

WIP: почему команда делает много, а заканчивает мало

Есть одна метрика, которую я люблю за простоту.

WIP — Work in Progress. 
То есть сколько задач одновременно находится в работе.

Звучит скучно, но на практике это один из самых быстрых способов понять, почему команда вроде бы занята, а результата мало.

Типичная картина:

— один разработчик делает фичу 
— параллельно чинит баг 
— параллельно ждёт ревью 
— параллельно отвечает на вопросы аналитика 
— параллельно “быстро смотрит” срочную задачу 
— параллельно у него ещё висит почти готовая доработка

В календаре человек занят. 
В Jira всё двигается. 
В чатах активность есть.

Но завершённых задач мало.

Проблема в том, что мозг не работает как процессор с бесконечным количеством потоков. Каждое переключение съедает контекст. Чем больше задач одновременно в работе, тем больше времени уходит не на работу, а на возвращение в неё.

Для тимлида WIP полезен как простой индикатор перегруза системы.

Если у команды одновременно открыто слишком много задач, почти всегда появляются симптомы:

— ревью копятся 
— задачи долго висят в “почти готово” 
— люди чаще забывают детали 
— растёт количество мелких ошибок 
— сроки становятся менее предсказуемыми 
— все заняты, но мало что доезжает до done

Самое неприятное: высокий WIP часто выглядит как продуктивность.

Много карточек в работе. 
Много обсуждений. 
Много коммитов. 
Много движения.

Но ценность появляется не когда задача “в работе”. 
Ценность появляется, когда задача завершена и дошла до пользователя.

Что можно попробовать без сложных процессов:

1. Посмотреть, сколько задач сейчас реально в работе.
2. Отдельно посчитать задачи, которые “почти готовы”, но чего-то ждут.
3. На неделю договориться: не начинать новую задачу, пока не помогли закрыть старую.
4. Посмотреть, стало ли быстрее доходить до done.

Иногда лучший способ ускорить команду — не начать ещё одну задачу, а наконец закончить три старые.

А у вас чаще проблема в том, что задач мало в работе или наоборот слишком много?

AI не решит проблему плохого фокуса

Есть неприятная ловушка: кажется, что если дать команде AI-инструменты, то она начнёт делать больше и быстрее.

Иногда так и происходит. Код появляется быстрее. Черновики решений появляются быстрее. Документация пишется быстрее. Даже тесты иногда появляются быстрее.

Но если у команды уже был хаос с фокусом, AI этот хаос не чинит.

Скорее наоборот.

Если разработчика постоянно дёргают встречами, срочными вопросами, переключениями и “можешь быстро посмотреть”, то AI просто помогает быстрее плодить незавершённую работу.

Было:

— задача начата
— потом переключились
— потом ещё одна задача
— потом ревью
— потом срочный баг
— потом вернулись и уже не помним контекст

Стало:

— задача начата
— AI быстро нагенерировал кусок решения
— потом переключились
— потом ещё одна задача
— потом ещё один AI-черновик
— потом ревью стало сложнее, потому что теперь надо понять не только код, но и то, насколько автор сам его понимает

Проблема не в AI.
Проблема в системе работы.

AI хорошо ускоряет локальные действия: написать код, накидать варианты, собрать черновик, объяснить кусок документации.

Но delivery обычно тормозит не только на написании кода.

Он тормозит на:

— неясных требованиях
— долгом ревью
— постоянных переключениях
— зависимостях между людьми
— ожидании решений
— незавершённой работе
— отсутствии нормального приоритета

И если это не чинить, получится странная картина: активность выросла, кода стало больше, задач “в работе” стало больше, а до прода всё едет примерно так же.

Для тимлида тут простой вывод.

Перед тем как радоваться ускорению от AI, стоит посмотреть на flow команды:

1. Сколько задач одновременно в работе?
2. Где задачи чаще всего ждут?
3. Сколько времени занимает ревью?
4. Как часто людей дёргают вне текущей задачи?
5. Становится ли быстрее доставка ценности, а не только написание кода?

AI может быть хорошим усилителем.

Но он усиливает не только сильные стороны.
Он так же хорошо усиливает бардак.

Если в команде есть фокус, понятные приоритеты и нормальный процесс ревью — AI может дать хороший прирост.

Если всего этого нет, он просто добавит скорости туда, где и так не хватало управления.

А у вас AI уже ускорил delivery или пока только написание кода?

Написал на vc.ru большой пост про своего Telegram-бота для Jira:

https://vc.ru/dev/3010823-telegram-bot-dlya-jira

Изначально идея была простая: мне надоело постоянно открывать Jira ради мелких, но частых действий.

Посмотреть статус задачи.
Понять, что зависло.
Быстро подготовиться к дейли.
Проверить активный спринт.
Получить сводку по команде.
Увидеть, где задачи стоят слишком долго.

Вроде бы всё это можно сделать в Jira.
Но если за день таких переключений десятки, инструмент начинает съедать внимание сам по себе.

Так появился SleepJiraBot.

Это не попытка заменить Jira и не “ещё один таск-трекер в Telegram”. Скорее тонкий слой поверх Jira, который помогает быстрее доставать нужный контекст там, где уже идёт рабочая коммуникация.

В посте рассказал:

— зачем вообще делать бота для Jira;
— какие сценарии он закрывает для тимлида и команды;
— как работают подписки на задачи и проекты;
— зачем нужна /daily-сводка;
— какие отчёты по спринтам и канбану хочется видеть;
— почему автоматизация не чинит плохой процесс, но хорошо подсвечивает, где он болит.

Бот уже можно попробовать: @Sleep_Jira_Bot
Исходники тоже выложил на GitHub.

Буду рад фидбеку, особенно от тех, кто живёт между Jira, Telegram, дейли, ревью и вечным вопросом: “а что у нас сейчас происходит?”