Такое вот любопытное исследование про тимлидов 👇🏻

Похоже, что нужно лучше в тайм-менеджмент и распределение нагрузки) Иначе так сгорим все скоро.

По остальным пунктам звучит всё не так плохо, если только активнее в сообществах участвовать 😁

Я принес. Исследование руководителей разработки 2025

Подоспели результаты ежегодного большого исследования 742 руководителей разработки от ребят из devcrowd http://devcrowd.ru/tl-2025/

Что мне тут бросилось в глаза:
- 89% людей работают в распределенных командах. Как человека, настраивающего работу распределенных команд уже более 10 лет, меня это радует. Это вечный холивар про «загонять всех в офис плечом к плечу» vs «работать распределенно». Я тут могу много препираться и отстаивать свою точку зрения, но факт остается фактом – реалии таковы, что нужно уметь устроить работу в команде, где нельзя подходить к коллеге лично и дергать его за рукав в поисках сиюминутного ответа.

- 39% продолжают писать код. При этом продолжают покрывать около 15 типов всяких менеджерских активностей. И это плавная подводка к следующему пункту.

- 50% руководителей страдают от перегруза и лишь 15% тимлидов говорят, что не сталкивались с выгоранием (да, это субъективно) в прошедшем году. Может быть, тут есть какая-то взаимосвязь между этим и предыдущим пунктом?

- Интересно, что мидл-менеджеры и СТО про выгорание говорят немного реже. То ли они умеют хорошо делегировать и не сидеть на всех стульях сразу, то ли туда просто добираются самые стойкие 🙂 Вообще те мидл-менеджеры и СТО, которых я вижу – очень много работают.

- Помогают справляться с напрягами: хобби, отпуск и поддержка семьи. Когда у меня спрашивают, откуда силы успевать и работать, и канал вести, и 2 подкаста, и консалтинг, и доклады всякие готовить – я всегда отвечаю, что это благодаря поддержке и помощи жены. Я уверен на 146%, что если бы не было всё так хорошо в семье, то и половины (а скорее всего больше) из того, что у меня получается не было бы❤️

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

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

- 60% прошли хотя бы одно обучение за последний год. Меня это радует, как человека регулярно учащегося и повышающего квалификацию. В менеджменте всегда есть чему учиться. И это вечнозеленая история, так что считаю это хорошей инвестицией в себя.

- Мало активных участников сообществ. Около 10-15% процентов. С одной стороны, это вроде как нормальное распределение по популяции, а с другой – чем больше людей будет активно участвовать, обмениваться опытом и знаниями, выходить из комнаты, тем и в индустрии в целом станет чуточку лучше, и в жизни конкретных этих людей.

- В 5 из 5 тимлидских крупных мероприятиях я был или участником или организатором.

- Рад, что мой канал держит хорошие позиции в рейтинге читаемых, а в блоке «За кем из экспертов следить в 2026 году» очень горд стоять плечом к плечу с ув. тов. Шароватовым 🤝

- Отдельная гордость про 2 подкаста – «Три тимлида заходят в бар» и «Кода кода», которые заняли 2 места в рейтинге топ-3 без каких-либо финансовых вложений в маркетинг. Просто стараемся сделать хороший и полезный контент и им поделиться с сообществом.

Делитесь своими мыслями в комментариях, что вам бросилось в глаза в этом исследовании?

Коротко про рынок IT сегодня))

Тестирование, которое вы не делаете

Я вернулся из отпуска) И хочу сразу поделиться вот чем.

Был у меня как-то случай.

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

Само собой, у всего, что касается водоснабжения я проверил, что ничего нигде не течёт. Я включал все краны, сливал воду во все возможные отверстия, а управляющая компания даже проводила опрессовку системы (это когда все трубы проверяются под давлением на наличие мини-трещин). Всё было идеально. Я принял работу и с чистой совестью отпустил этих горе-строителей на следующий объект.

Но примерно через пару лет у меня начал течь коллектор отопления. Кто не знает — это такая "единая батарея", от которой уже идёт разводка труб на все остальные батареи в комнатах. И что самое ужасное, течь он начал потихоньку, незаметно. Обнаружил я это далеко не сразу, а когда мне уже залило стену. Цена ремонта оказалась очень высокой.

Как же так произошло?

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

Проверить сразу это было практически нереально — чтобы понять, что прокладка прохудится нужно 1-2 года.

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

Я видел аналогичные истории и в IT.

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

Мы проводим большое количество тестов перед тем, как система перейдёт в промышленную эксплуатацию. Разработчики пишут unit- и интеграционные тесты, QA делают smoke, функциональное, регрессионное тестирование. Потом мы проводим нагрузочное. Но один из видов тестирования, который чаще всего забывают — это Тест стабильности (Stability/Endurance Testing).

Я лично видел ситуацию, когда из-за смены пароля служебной учётки, периодическая интеграция через несколько месяцев попыток подключения переполняла счётчик попыток входа, который хранился в поле базы данных с типом tiny int, (максимальное значение в этом типе составляет 127). Из-за этого система сходила с ума и переставала пускать вообще каких-либо пользователей.

Или же по мере накопления логов заканчивается место на диске, из-за чего сервисы просто падают — это вообще классика.

Утечки памяти, забытый неочищаемый кэш и прочее — всё это тоже сюда.

В общем, раз уж канал для ИТ-специалистов и руководителей, хочу дать практический совет:

Не забывайте про тестирование стабильности на длительной дистанции.

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

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

P.S. У меня появилась идея сделать рубрику с объяснением разных айтишных тем на простых жизненных примерах постоянной. Это может быть полезно начинающим специалистам, да и вообще всем профессионалам для повышения общего образования.

Накидайте ❤️, если интересен такой формат)

А вы делаете тест стабильности у себя на проекте?

Делитесь вашей болью!

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

Напишите в комментарии темы, которые вас беспокоят. Это могут быть ситуации, в которых вы хотели бы получить независимое мнение. Или любые вопросы в целом из ИТ.

Я отвечу в комментариях или напишу по вашим вопросам отдельные посты, если ответ не получится коротким)

P.S. В этот пост вы можете в любой момент написать комментарий с идеей для поста в канал.

Искусство "дозирования" информации

Один из важнейших навыков лида — это управление объёмом информации, которую вы транслируете в команду или конкретным людям.

У руководителя обычно чуть больше осведомлённости о происходящем вокруг, чем у рядовых специалистов. И я видел много случаев, когда лиды нарушали баланс: либо болтали всем подряд слишком много, либо, наоборот, не делились с сотрудниками вообще ничем.

В первом случае высокая болтливость может приводить к излишним переживаниям команды из-за того, что ещё может и не случиться. Например, думаю, не стоит особо пояснять, что произойдёт с мотивацией людей в тот момент, когда вы скажете: "возможно, Федю скоро уволят". Правильно — вместо работы люди начнут обсуждать все плохие сценарии, выкладывать резюме на ХХ и плохо спать по ночам.

Я видел прямо вопиющие случаи нарушения принципа "дозирования": руководитель немалого подразделения ходил по коридору и направо и налево кричал, как в компании всё ужасно. И что он хочет уволиться и забрать половину команды. Так делать как минимум непрофессионально, даже если вы поругались с кем-то наверху. Мир ИТ узкий, а репутация — вещь хрупкая.))

Если выдавать такую информацию выборочно, то это может привести к ещё более плохим последствиям: он передаст её дальше по принципу сломанного телефона, да ещё приправит это своими домыслами и тем, что "по секрету узнал". Так начнутся слухи и сплетни. А ещё люди будут думать, что лид от них что-то скрывает.

Есть и обратная ситуация — вообще ничего не говорить команде до последнего.

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

В общем, правила тут простые.

Важную информацию нужно доносить до команды единомоментно, когда решение о чём-либо уже принято, либо когда от вероятности наступления чего-то зависит дальнейший план работ. Если это пока "не факт" и мы никак не можем на это повлиять, лучше повременить и не порождать лишние слухи и переживания.

Если вы сами планируете какое-то изменение, то воспользуйтесь алгоритмом, который я давал на онлайн-митапе "Рупор лида" по внедрению изменений (сначала договариваемся с ключевыми сотрудниками и лидерами, затем транслируем остальным).
Полная статья тут, краткий алгоритм здесь 👈🏻

Выборочно информацию давать можно, но осторожно. Всегда задумывайтесь, какие решения человек может принять, узнав о чём-либо. Может ли он, например, эскалировать проблему на вышестоящее руководство, хотя ещё не время? Может ли он в панике пойти смотреть рынок после новости, что коллегу хотят сократить? Может ли он транслировать всё "по секрету" в команду — и что произойдёт, если так случится?

Будьте честны и открыты. Если решение ваше, то старайтесь честно обосновать его и рассказать о причинах. В случае, когда новость приходит "сверху", объясните мотивы вышестоящего руководства, но старайтесь максимально помочь команде в период каких-то изменений. Если чего-то не понимаете, то так и скажите — ничего страшного в этом нет, все мы люди.

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

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

Держите пятничный лайфхак)

Всем хороших выходных!

Как сохранить скорость разработки с ростом числа продуктов?

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

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

22 октября Hilbert Team и Yandex Cloud обсудят, как небольшим и средним командам разработки запускать цифровые продукты в облаке еще быстрее. Покажут, как построить масштабируемый цифровой конвейер разработки без лишних затрат и выделенной платформенной команды.

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

Кому будет полезно: руководителям команд разработки, DevOps-инженерам, продактам, архитекторам и всем, кто отвечает за развитие цифровых продуктов.

22 октября, 12:00 мск

Ссылка на регистрацию

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

Я искренне считаю, что даже самые сложные вещи в этом мире можно объяснить «на пальцах» — с помощью аналогий и примеров. Если вы хорошо понимаете, как и где применяется технология или термин, вы всегда сможете выделить те самые 20% из принципа Парето и кратко изложить его суть как для своей бабушки.

Давайте сегодня попробуем сделать это для ещё одной полезной темы — подходов к совместному программированию.

Думаю, все знают, что для одновременной разработки программисты используют систему контроля версий Git. Основной сущностью там является ветка. По сути, ветки — это копии кода приложения с некоторыми изменениями под конкретные цели, аналогично, например, версиям текстовых документов. Просто студенты сохраняют файлы в папки, называя «Курсовая_1», «Курсовая_2», «Курсовая_2_финал», «Курсовая_2_точно_финал!!», а у программистов есть для этого специальная система с совместным доступом)).

В небольших проектах, когда несколько разработчиков пишут код одновременно, они могут заливать свои наработки и реализованные функции (делать коммиты) прямо в основную ветку, которая обычно называется main (или master). Это работает, когда сами фичи маленькие, делаются за 1–2 дня и изменения, которые в проекте делает Вася, не пересекаются с изменениями Стёпы.

Например, Вася реализует функцию оплаты, а Стёпа пишет авторизацию. Такой подход к совместной разработке называется Trunk Based. Чаще всего в этом подходе функции, которые разработчики только что реализовали, не тестируются отдельно: проверяется сразу вся система после реализации и влития в main сразу всех функций. Из проверок тут только вычитка кода (Code Review), который написал Вася и Стёпа их лидом перед тем, как загрузить его в main.

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

Представляете себе огромный монолит, который дорабатывают 5–6 человек, и каждый сразу пушит в основную ветку main? Очевидно, что когда перед релизом вы будете тестировать продукт (а вы же будете, верно?)), вы наткнётесь на баги, понять причину которых будет проблематично. Будет сложно выявить, в какой момент они возникли и именно что их вызвало — изменения Васи, Стёпы или вообще их комбинация.

Чтобы хоть немного минимизировать эти проблемы, придумали такую тему, как Feature Flags. Это подход, когда вы пишете какую-то функцию, но блок кода, который отвечает за неё, «включается» только когда вы указываете в конфиге в true какую-то переменную. Что-то типа:

if (new_payment_system == true) then
return processPaymentNewMethod();
else
return processPaymentLegacy();

Штука, конечно, полезная, но имеет много ограничений. Например, если ваша новая функция требует написания большого количества кода в разных местах, вы просто замучаетесь везде проставлять этот флаг, а потом везде его убирать)).

В общем, всё это работает в маленьких проектах.

А что лучше использовать в проектах побольше, напишу в посте ниже… 👇🏻

...продолжение предыдущего поста

Когда ваш проект становится хотя бы немного похож на серьёзное приложение, советую переходить на Git Flow — это стандарт организации ведения веток при совместной разработке. Тут тоже всё не сложно, но участвуют чуть больше веток. Обычно набор такой:

main/master — стабильный продакшен-код
develop — текущая разрабатываемая версия
feature/* — ветки для разработки фич
release/* — ветки для подготовки релиза
hotfix/* — ветки для срочных исправлений

Например, когда вы как разработчик взялись написать функцию оплаты, то вы создаёте себе новую ветку, копируя код из develop, а по окончании разработки снова заливаете в develop. Весь путь функции в гите будет выглядеть примерно так:

develop → feature/payment (2 недели разработки) → develop

Продолжая аналогию с документами, мы копируем себе актуальный файл, вносим туда правки, а потом делаем запрос на слияние (Merge Request) наших изменений в актуальный файл.

Иногда случается так, что чуть раньше другой разработчик Игнат уже внёс свои изменения в актуальный файл develop и изменил те же кусочки кода (абзацы), что и вы. В этом случае система подсветит это как конфликт, который вам нужно будет устранить: решить, какую версию абзаца взять — вашу или Игната. А уже после разрешения всех конфликтов и Code Review от лида наша функция загружается в develop — ура!

Когда наступает время выпускать релиз, лид копирует код из develop-ветки в «релизную». Например, для релиза v1.2.0 путь будет выглядеть так:

develop → release/v1.2.0 (тестирование, фиксы багов) → main + develop

По такому флоу живут практически все серьёзные проекты, в том числе те, у которых открытый исходный код (Open Source). По факту Git Flow — это стандарт индустрии, с которым вам придётся столкнуться на любом месте работы, который хотя бы немного перестаёт быть стартапом.

——

Сегодня мы стали знать чуть больше о Git Flow, Trunk Based и Feature Flags.

В двух постах мы разобрали основную суть самых популярных подходов к версионированию кода при совместной разработке. Как и во всех темах, тут есть нюансы, но те самые 20%, которые дают 80% результата, я описал выше.

А что используется у вас — Trunk Based, Git Flow или что-то своё?)

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

Ставьте 👨🏻‍💻, если подобные технические штуки интересны
Ставьте 🤓, если больше хочется про менеджмент и управленческие темы