Forwarded from I’m CTO, bitch
😡 Советы для лидов
Придите к своему сотруднику и скажите, что вам не нравится как он работает. Что вы подозреваете, что он ничего полезного не делает, и вообще в офисе вы его не видите (хотя сотрудник официально на удалёнке, но сделайте вид, что вы забыли). Обязательно потребуйте, чтобы он до конца дня собрал вам письменный отчёт, детально описал всё, чем он занимался последний год. С доказательствами, метриками, ссылками на артефакты, контактами, кто может подтвердить — чтобы вы могли проверить его слова, а сотрудник знал, что обман не проконает.
Только не делайте это регулярно! Никакой отчётности раз в неделю! Наоборот, весь год говорите, что вы бирюзовые и доверяете сотрудникам. И никогда не обсуждайте проблемы в тот момент, когда они произошли. Накопите побольше, пусть отлежится, дождитесь, когда он забудет весь контекст. Внезапность — это ваше преимущество. Лучше всего нападите за 2 недели до годового ревью, когда сотрудник расслаблен и не ожидает.
Будьте готовы, что сотрудник захочет доказательств и оснований для ваших подозрений. Но не торопитесь. Помните, вы тут начальник. Скажите, что вам «поступают сигналы от других сотрудников», но раскрыть подробности вы конечно же не можете, так как это личное. Пусть он подозревает своих коллег, ведь любому коллективу жизненно необходима здоровая конкуренция.
Как вы понимаете, дело для сотрудника пахнет увольнением. Но когда он героически оправдает себя, вы так уж и быть сохраните его в команде. И поверьте, после такого он будет безумно рад узнать, что спустя 1,5 года работы зарплату ему повышают на целых 3.5%!
#рукойводят
Придите к своему сотруднику и скажите, что вам не нравится как он работает. Что вы подозреваете, что он ничего полезного не делает, и вообще в офисе вы его не видите (хотя сотрудник официально на удалёнке, но сделайте вид, что вы забыли). Обязательно потребуйте, чтобы он до конца дня собрал вам письменный отчёт, детально описал всё, чем он занимался последний год. С доказательствами, метриками, ссылками на артефакты, контактами, кто может подтвердить — чтобы вы могли проверить его слова, а сотрудник знал, что обман не проконает.
Только не делайте это регулярно! Никакой отчётности раз в неделю! Наоборот, весь год говорите, что вы бирюзовые и доверяете сотрудникам. И никогда не обсуждайте проблемы в тот момент, когда они произошли. Накопите побольше, пусть отлежится, дождитесь, когда он забудет весь контекст. Внезапность — это ваше преимущество. Лучше всего нападите за 2 недели до годового ревью, когда сотрудник расслаблен и не ожидает.
Будьте готовы, что сотрудник захочет доказательств и оснований для ваших подозрений. Но не торопитесь. Помните, вы тут начальник. Скажите, что вам «поступают сигналы от других сотрудников», но раскрыть подробности вы конечно же не можете, так как это личное. Пусть он подозревает своих коллег, ведь любому коллективу жизненно необходима здоровая конкуренция.
Как вы понимаете, дело для сотрудника пахнет увольнением. Но когда он героически оправдает себя, вы так уж и быть сохраните его в команде. И поверьте, после такого он будет безумно рад узнать, что спустя 1,5 года работы зарплату ему повышают на целых 3.5%!
#рукойводят
👍2✍1🔥1🤔1
Forwarded from Свободный слот
Изучаем искусство обратной связи с Сашей Прокшиной 🚀
Казалось бы, просто вежливо и своевременно пишешь правду. Но, как и всегда и везде при работе с командой, есть нюанс…
⬆️ В карточках собрали несколько советов о том, как давать обратную связь от Саши Прокшиной. А если информации на карточках недостаточно, ищите ответы на ваши вопросы в списке материалов из доклада:
А теперь честный вопрос-байт на реакции:
🔥 — если вы гуру обратной связи
❤️🔥— если обещаете посмотреть доклад
👍 — если открыли для себя хоть одну новую мысль после просмотра
Казалось бы, просто вежливо и своевременно пишешь правду. Но, как и всегда и везде при работе с командой, есть нюанс…
⚡️ «Радикальная прямота. Как управлять людьми не теряя человечности» — Ким Скотт;⚡️ «Эффективная обратная связь» — Harvard Business Review;⚡️ Обратная связь. Как сказать все, что думаешь, и получить все, что хочешь. Тереза Хьюстон⚡️ «Трудные диалоги» — Керри Паттерсон, Джозеф Гренни, Рон Макмиллан, Эл Свитцлер;⚡️ «Эмоциональный интеллект. Почему он может значить больше, чем IQ» — Дэниел Гоулман;⚡️ «Никаких компромиссов. Беспроигрышные переговоры с экстремально высокими ставками. От топ-переговорщика ФБР» — Крис Восс;⚡️ «Эмоциональная смелость» — Питер Брегман;⚡️ «Спасибо за отзыв. Как правильно реагировать на обратную связь» — Дуглас Стоун, Хин Шейла;⚡️ Доклад 1000 и 1 фидбек. Женя Голева
А теперь честный вопрос-байт на реакции:
🔥 — если вы гуру обратной связи
❤️🔥— если обещаете посмотреть доклад
👍 — если открыли для себя хоть одну новую мысль после просмотра
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from System Design World (Владимир в IT)
💡 В завершающей части вы изучите:
+ Strong
+ Eventual
+ Способы достижения
+ Примеры систем
💍 One ring to... распределить их всех
+ Избыточность. А зачем?
+ Бэкапы
+ Непрерывное резервирование с помощью реплики
+ Почему нужна промежуточная сущность?
+ Forward proxy для клиентов
+ Reverse proxy для бэкэнда
👉 Habr: System Design для начинающих: всё, что вам нужно
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
System Design для начинающих: всё, что вам нужно. Часть 6
Вам не нужно изучать какую‑либо теорию, кроме этой статьи, чтобы начать собеседоваться. После прочтения смело приступайте к решению типовых System Design задач. Изучая ...
Forwarded from Никита Ульшин про IT (Nikita Ulshin)
Как я прокачал промптинг и стал эффективнее
С LLM я работаю каждый день, поэтому постоянно ищу способы сделать свою работу проще и приятнее. Моё использование не ограничивается кодом: я много работаю с текстами, презентациями, генерацией идей и другими креативными задачами.
Поэтому я постоянно ищу идеи, как сделать свою работу эффективнее и приятнее. Сегодня я поделюсь тремя интересными находками, которые мне здорово помогли.
⭐️ Prompt like a pro in Google Workspace with Gemini
Короткий гайд от Google о том, как писать качественные промпты с Gemini. Сама инструкция умещается буквально на пару страниц, остальная брошюра — примеры промптов для разных контекстов.
Вот несколько полезных советов оттуда:
➡️ Структура «Персона — Задача — Контекст — Формат». Все эти части должны присутствовать в эффективном промпте.
➡️ Используйте естественный язык. Пишите промпты так, как говорили бы с коллегой.
➡️ Подключайте LLM к генерации промптов. Можно написать довольно простой промпт, который будет помогать вам улучшать свои собственные.
Примеры в брошюре классные, рекомендую выборочно ознакомиться с ними под свои контексты.
⭐️ Prompt Engineering by Lee Boonstra
Небольшой гайд по продвинутому промптингу. Большая часть посвящена техникам: step-back, chain/tree of thoughts, reasoning & act. Также в гайде есть примеры промптов и подборка лучших практик.
Вот несколько интересных рекомендаций:
➡️ Приводите примеры того, что хотите получить. Чем больше примеров получит LLM — тем точнее будут результаты.
➡️ Предпочитайте инструкции ограничениям. Исследования показывают, что качественные инструкции улучшают результаты LLM больше, чем просто ограничения.
➡️ Сохраняйте удачные промпты и обсуждайте их с другими. Написание промптов — новый навык нашего времени, и совместное обучение может ускорить развитие этого навыка для всех.
В брошюре есть некоторые тонкости, которые могут показаться избыточными — смело пропускайте.
⭐️ SmartGPT Prompt Enhancer
Я воспользовался рекомендацией из обоих гайдов — «подключать LLM к промптингу» — и нашёл этот отличный улучшатель промптов. Он пишет очень хорошие промпты. Достаточно объяснить ему свою задачу (можно даже запутанно и непоследовательно), и он сгенерирует подробный промпт для LLM. Этой штукой я пользуюсь каждый день.
// Есть классные лайфхаки по работе с LLM? Делитесь в комментариях🔥
С LLM я работаю каждый день, поэтому постоянно ищу способы сделать свою работу проще и приятнее. Моё использование не ограничивается кодом: я много работаю с текстами, презентациями, генерацией идей и другими креативными задачами.
Поэтому я постоянно ищу идеи, как сделать свою работу эффективнее и приятнее. Сегодня я поделюсь тремя интересными находками, которые мне здорово помогли.
Короткий гайд от Google о том, как писать качественные промпты с Gemini. Сама инструкция умещается буквально на пару страниц, остальная брошюра — примеры промптов для разных контекстов.
Вот несколько полезных советов оттуда:
Примеры в брошюре классные, рекомендую выборочно ознакомиться с ними под свои контексты.
Небольшой гайд по продвинутому промптингу. Большая часть посвящена техникам: step-back, chain/tree of thoughts, reasoning & act. Также в гайде есть примеры промптов и подборка лучших практик.
Вот несколько интересных рекомендаций:
В брошюре есть некоторые тонкости, которые могут показаться избыточными — смело пропускайте.
Я воспользовался рекомендацией из обоих гайдов — «подключать LLM к промптингу» — и нашёл этот отличный улучшатель промптов. Он пишет очень хорошие промпты. Достаточно объяснить ему свою задачу (можно даже запутанно и непоследовательно), и он сгенерирует подробный промпт для LLM. Этой штукой я пользуюсь каждый день.
// Есть классные лайфхаки по работе с LLM? Делитесь в комментариях
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Teamlead Good Reads – ежедневные советы про менеджмент людей и команд (Egor Tolstoy)
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%.
Мы в 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%.
Jetbrains
The State of Developer Ecosystem in 2025
Explore key software developer statistics for 2025 in the State of Developer Ecosystem Report. Trends, insights, and tools shaping the developer world.
Надоело переключаться между Jira и мессенджером, чтобы глянуть статус задачи или оставить комментарий. Поэтому написал SleepJiraBot — Telegram-бот, который умеет работать с Jira Cloud без открытия браузера.
Что умеет:
🔔 Подписки на задачи и проекты — уведомления о новых задачах, изменениях статуса, упоминаниях
🏃 /daily — сводка твоих задач на сегодня, идеально для дэйли
📋 /sprint — просмотр активного спринта одной командой
📊 Отчёты по расписанию — настраиваешь cron, бот сам шлёт JQL-отчёт в нужный чат
✏️ Действия с задачами — комментарии, смена статуса, назначение исполнителя
🌐 Русский и английский интерфейс
🔐 OAuth 2.0 + шифрование токенов (AES-256-GCM)
Бот уже работает — можно попробовать прямо сейчас:
Open source, исходники на GitHub:
https://github.com/Alexandr-Penkin/jira_bot
Лендинг: https://apenkin.pro/jira-bot
Если пользуетесь Jira Cloud — попробуйте, буду рад фидбеку
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - Alexandr-Penkin/jira_bot: Jira notifications, tools and reports for Telegram
Jira notifications, tools and reports for Telegram - Alexandr-Penkin/jira_bot
🔥3🤩1
Вчера Анатолий Панов на Podlodka TeamLead Crew затронул метод ICE.
Решил немного поподробней его изучить.
ICE — простой способ понять, за что тимлиду браться в первую очередь 👀
У тимлида почти всегда список задач выглядит примерно так:
— поправить процесс
— помочь команде с перегрузом
— наконец-то навести порядок в постановке задач
— внедрить quality gates
— запустить нормальные 1:1
— ответить бизнесу “почему так долго”
— не сойти с ума😅
И вот в такие моменты очень легко попасть в ловушку:
всё кажется одинаково важным.
Чтобы не метаться между “срочно”, “важно” и “горит вообще всё”, можно использовать ICE.
🥶
Это очень простой фреймворк приоритизации из трех вопросов:
I — Impact
Какой эффект это даст?
C — Confidence
Насколько я уверен, что эффект правда будет?
E — Ease
Насколько это вообще легко и быстро сделать?
Дальше можно просто поставить оценки, например от 1 до 10, и сложить их.
Например:
Сделать шаблон для постановки задач
Impact — 8
Confidence — 9
Ease — 8
Итого: 25
Полностью пересобрать весь процесс общения с бизнесом
Impact — 9
Confidence — 5
Ease — 2
Итого: 16
Запустить короткие еженедельные 1:1
Impact — 7
Confidence — 8
Ease — 7
Итого: 22
И тут внезапно становится видно, что не самая “громкая” идея может быть самой полезной.
Чем ICE хорош для тимлида 🤝
Он помогает не принимать решения по ощущению:
❌ “ну это вроде важно”
❌ “давно хочу этим заняться”
❌ “это больше всего обсуждают”
А смотреть чуть трезвее:
✅ это реально даст эффект?
✅ мы уверены, что туда вообще стоит идти?
✅ мы точно готовы тратить на это силы прямо сейчас?
Для тимлида это особенно полезно, потому что его работа — это постоянный выбор, куда вложить ограниченное внимание.
⚙️ Где можно использовать ICE
Например, чтобы понять:
— что из внутренних улучшений делать первым
— какие управленческие инициативы запускать сейчас
— что реально поможет команде, а что просто красиво звучит
— какую проблему решать первой, когда болит сразу всё
Очень хорошо работает для таких штук, как:
- онбординг
- 1:1
- шаблоны задач
- ретро
- quality gates
- правила работы команды
- изменения в процессе
- новые ритуалы команды
✨ Почему он удобный
Потому что ICE не требует сложных таблиц, длинных обсуждений и магии.
Это не идеальная система.
Это просто быстрый способ остановиться и подумать головой.
Иногда уже сам вопрос
“а мы вообще уверены, что это даст эффект?”
очень отрезвляет.
Но есть нюанс 🫠
ICE не волшебный.
Он может увести не туда, если:
— завышать impact
— ставить confidence “на ощущениях”
— выбирать только легкие задачи, потому что их приятно закрывать
— бесконечно откладывать сложные, но важные темы
Так что ICE — это не замена мышлению.
Это скорее удобный фильтр, чтобы не хвататься за всё подряд.
#тимлид #менеджмент #лидерство #приоритизация #ice #фреймворк
Решил немного поподробней его изучить.
ICE — простой способ понять, за что тимлиду браться в первую очередь 👀
У тимлида почти всегда список задач выглядит примерно так:
— поправить процесс
— помочь команде с перегрузом
— наконец-то навести порядок в постановке задач
— внедрить quality gates
— запустить нормальные 1:1
— ответить бизнесу “почему так долго”
— не сойти с ума
И вот в такие моменты очень легко попасть в ловушку:
всё кажется одинаково важным.
Чтобы не метаться между “срочно”, “важно” и “горит вообще всё”, можно использовать ICE.
Что такое ICE
Это очень простой фреймворк приоритизации из трех вопросов:
I — Impact
Какой эффект это даст?
C — Confidence
Насколько я уверен, что эффект правда будет?
E — Ease
Насколько это вообще легко и быстро сделать?
Дальше можно просто поставить оценки, например от 1 до 10, и сложить их.
Например:
Сделать шаблон для постановки задач
Impact — 8
Confidence — 9
Ease — 8
Итого: 25
Полностью пересобрать весь процесс общения с бизнесом
Impact — 9
Confidence — 5
Ease — 2
Итого: 16
Запустить короткие еженедельные 1:1
Impact — 7
Confidence — 8
Ease — 7
Итого: 22
И тут внезапно становится видно, что не самая “громкая” идея может быть самой полезной.
Чем ICE хорош для тимлида 🤝
Он помогает не принимать решения по ощущению:
❌ “ну это вроде важно”
❌ “давно хочу этим заняться”
❌ “это больше всего обсуждают”
А смотреть чуть трезвее:
✅ это реально даст эффект?
✅ мы уверены, что туда вообще стоит идти?
✅ мы точно готовы тратить на это силы прямо сейчас?
Для тимлида это особенно полезно, потому что его работа — это постоянный выбор, куда вложить ограниченное внимание.
⚙️ Где можно использовать ICE
Например, чтобы понять:
— что из внутренних улучшений делать первым
— какие управленческие инициативы запускать сейчас
— что реально поможет команде, а что просто красиво звучит
— какую проблему решать первой, когда болит сразу всё
Очень хорошо работает для таких штук, как:
- онбординг
- 1:1
- шаблоны задач
- ретро
- quality gates
- правила работы команды
- изменения в процессе
- новые ритуалы команды
✨ Почему он удобный
Потому что ICE не требует сложных таблиц, длинных обсуждений и магии.
Это не идеальная система.
Это просто быстрый способ остановиться и подумать головой.
Иногда уже сам вопрос
“а мы вообще уверены, что это даст эффект?”
очень отрезвляет.
Но есть нюанс 🫠
ICE не волшебный.
Он может увести не туда, если:
— завышать impact
— ставить confidence “на ощущениях”
— выбирать только легкие задачи, потому что их приятно закрывать
— бесконечно откладывать сложные, но важные темы
Так что ICE — это не замена мышлению.
Это скорее удобный фильтр, чтобы не хвататься за всё подряд.
#тимлид #менеджмент #лидерство #приоритизация #ice #фреймворк
Please open Telegram to view this post
VIEW IN TELEGRAM
podlodka.io
Онлайн-конференция Podlodka Teamlead Crew, сезон #16
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам тимлидства, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
👍4
Метрики 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 #менеджмент #лидерство
Иногда кажется, что команда всё время что-то делает: задачи двигаются, созвоны идут, релизы случаются, все заняты по уши.
Но занятость ≠ эффективность 👀
Чтобы понять, насколько команда правда хорошо доставляет изменения, часто смотрят на метрики 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 #менеджмент #лидерство
👍1