Последние годы меня занимает поиск способов повышения эффективности разработки в IT. С одной стороны у нас есть всякие CI/CD, k8s и прочие ELK — инструменты, которые упрощают жизнь, экономят время и мыслетопливо. С другой стороны есть…люди, которые очень разные и работают по разному.
В этой статье будем говорить только про людей, а конкретно про вовлеченность в работу.
Раздолбаи
Очень коротко про эту когорту айтишников.
Лодыри, раздолбаи, “заработчики” всех мастей, кто пришел не работать, а доить компанию. Таких людей мы не будем рассматривать в этой статье.
Все мы знаем таких людей, это чистый минус для бизнеса, не буду о них долго, от таких “сотрудников” надо избавляться и не стоит ждать, что они возьмутся за ум. Не возьмутся. Они здесь не за этим. Но перед расставанием нужно, разумеется, убедиться что человек именно такой персонаж, а не жертва обстоятельств или тот кто хочет работать и приносить пользу, но навыков не хватает.
Что за вовлеченность?
Определение вовлеченности от ИИ, в целом, мне нравится…
Вовлеченность — это эмоциональное и интеллектуальное состояние человека, при котором он искренне заинтересован в процессе и готов прикладывать дополнительные усилия для достижения наилучшего результата.
Её не хватает в индустрии. Многим, простите, похер на всё: на бизнес, на качество инженерных решения, на пользователя.
Gallup в отчете State of the Global Workplace 2026 пишет:
- мировая вовлеченность сотрудников упала до 20%;
- это самый низкий уровень с 2020 года;
- снижение продолжается с пика 2022–2023 годов.
Особенно важно, что сильнее всего падает вовлеченность менеджеров, это критично для IT, потому что именно менеджеры поддерживают команды во время постоянных изменений, AI-трансформации и гибридной работы.
Но надо понимать, что зачастую дело не в в том что хорошие специалисты внезапно потеряли интерес к работе, а в том что условия работы становятся жёстче.
Свежие исследования разработчиков показывают:
- рост загрузки;
- разрыв между «идеальной» и реальной рабочей неделей;
- падение удовлетворенности при увеличении хаотичной нагрузки.
Исследование Microsoft среди разработчиков (2025) показало:
- чем больше разрыв между тем, как разработчик хотел бы распределять время, и тем, как он реально работает;
- тем ниже удовлетворенность и продуктивность.
Это важный индикатор снижения вовлеченности: люди всё чаще ощущают, что работают «не так, как считают правильным», больше времени уходит на координацию, встречи и организационный шум.
Исследования обсуждений разработчиков на Workplace StackExchange показали, что среди самых частых тем:
- конфликты;
- проблемы культуры;
- управленческие сложности;
- стресс;
- корпоративные политики.
Под вовлеченностью я понимаю, две основных, так скажем, статьи расходов сил:
- делать качественно;
- улучшать то, что уже есть.
Ремарка по 1 пункту, если вы что-то сделали и это принято к использованию, это не всегда значит что вы сделали хорошо, у вас больше всего контекста по задаче, вы (по идее) больше всего о ней думали, а коллеги, которые делают ревью вашего решения (ведь делают же?) могут быть гораздо менее погружены в проблематику и пропустить, неосознанно или осознанно, ошибки в решении. Получается вроде всем ок, но потом выясняется что получилась хрень. Жизненно.
По второму пункту есть мнение “работает — не трогай”, я с этим чаще не согласен чем согласен, работать может плохо, работать может неоптимально и то что кое-как подходит сегодня завтра уже может перестать подходить, а переделывать долго и дорого, это может касаться и систем и процессов.
Если вы работаете в стартапе, то фокус у вас, скорее всего, другой — на скорость: зачастую, стартап несётся вперёд подобно поезду Сапсан, не обращая внимание ни на что и преследуя одну цель: как можно быстрее выкатить MVP/MLP на рынок. В такой ситуации всем может быть совсем не до качества. Однако, не стоит забывать, что косяки оставленные на этапе “бега” потом придётся разруливать.
И давайте на всякий, случай, договоримся: быть вовлеченным не значит перерабатывать, если работа ведется ±весь рабочий день (с перерывами, разумеется), то быть вовлеченным не значит работать 10 часов вместо 8. Нет! Это значит делать качественные решения и часть времени выделять на самостоятельный поиск мест, где можно нанести пользу: поискать неоптимальные места к коде архитектуре, помочь коллеге, посидеть над сложным ревью, подумать как можно улучшить процессы, запилить задач для улучшения пользовательского опыта, производительности, поправить алетинг в мониторинге, можно бесконечно перечислять.
И не нужно прям гореть работой. Если вы настолько увлечены, что это бьет по личной жизни, сну, физической активности и т. п., поверьте, вам это не надо, в итоге вы как минимум выгорите, а то пожалеете о потраченном времени и надорвете здоровье.
Зачем это делать?
Это может казаться не совсем очевидным, но только так серьезные IT-проекты могут качественно работать.
Давайте поделим решаемые командами разработки задачи на типы:
Продуктовые
Если говорить о продуктовых задачах, то их придумывает продакт-менеджер или иной представитель “бизнеса”. Чем мы тут можем помочь? Ну, как минимум, критическим мышлением и я тут не про то, что нужно кошмарить любую задачу от продакта (а то есть любители :)), а про то что продакт и люди работающие с ним над подготовкой и обоснованием задачи (дизайнеры, аналитики и пр.) могут ошибиться и наша задача проверить их тезисы на верность: вопросы вроде “какую пользу мы принесем этой задачей пользователю?”, “есть ли аналитика востребованности такой функциональности?” вполне логичны и полезны, дизайн тоже можно “прожарить”. А как максимум мы можем и сами предлагать новую функциональность и то как она может быть реализована.
Такие усилия дают более качественный результат, так как IT-специалисты тоже погружены в предметную область, зачастую являются пользователями своего продукта и, чаще всего, понимают какие улучшения для пользователя можно сделать быстро.
Технические
Здесь мы — остриё копья.
Иногда такие задачи это только техдолг, но чаще есть и задачи на улучшения, которые генерят инженеры и технический менеджмент, это и есть результат той самой вовлеченности и если это не задачи ради задач, а, напротив, работа на будущее развитие и прокачку текущих систем, то это создает перспективу устойчивого развития на годы вперёд и это здорово!
Если говорить про техдолг, то это тоже результат чьей-то неравнодушности (“ну ок, сейчас сделаем так, но потом обязательно переделаем”), его наличие это нормально, но если его много, то кажется на качество слишком сильно забивается. С другой стороны, если техдолга нет, то, вероятно, команда не фокусируется совсем на качестве или решения “вылизываются” до идеала что может быть плохо для бизнеса, так как в этом случае пользователи получают улучшения значительно позже и бизнес развивается медленнее, а конкуренты ведь не дремлют.
Без проактивного улучшения системы со временем загибаются, так как без желания делать хорошо мы, соответственно, делаем плохо, не смотрим на перспективу, ничего не улучшаем — системы, деградируют, устаревают, не вывозят растущую нагрузку и объем функциональность. Если вовлеченных людей мало, то страдает всё: архитектура, код, мониторинг, документация и отсюда очень быстро появляются проблемы с масштабированием, развитием функционала, читаемостью кода, порогом входа, даже если изначально архитектура и процессы были неплохо выстроены. Техрешения устаревает, так как мы работаем в изменчивой среде со сложными системами, а процессы не спасут от фундаментальным проблем с инженерной культурой.
Иное
Улучшить процесс, внедрить инструмент, пересобрать оргструктуру. Такие изменения могут принести огромную пользу и при этом необходимость таких изменений могут очень долго не замечать, так как все сосредоточены в основном на своём домене, своего рода, туннельное зрение. Между тем, очень полезно иногда остановиться и посмотреть сверху на то что и как мы делаем, и где у нас bottlenecks. Гарантирую, вы всегда увидите несколько проблем, решение которых может дать буст.
Таким образом, если хотя бы значительная часть команды вовлечены в улучшение, а не просто являются исполнителями это дает мощный синергетический эффект и именно такие команды строят отличные проекты!
Есть и исследования, самое цитируемое направление исследований — мета-анализы Gallup и академические работы в PubMed. Они показывают устойчивую связь между вовлеченностью сотрудников и бизнес-результатами.
Ключевые выводы исследований:
- Команды с высокой вовлеченностью показывают:
- выше прибыльность,
- выше продуктивность,
- ниже текучесть,
- меньше прогулов,
- меньше инцидентов по безопасности,
- лучше клиентский опыт.
- В последнем крупном мета-анализе Gallup (2024) проанализированы данные более 3,3 млн сотрудников, 183 тыс. команд, 347 организаций, 90 стран.
- Разница между командами из верхнего и нижнего квартиля по вовлеченности составила в среднем:
- +23% прибыльности,
- +18% продаж/продуктивности,
- −21–51% текучести,
- −63% инцидентов безопасности.
Есть и академические подтверждения вне Gallup. Например, мета-анализ в American Psychological Association показал, что удовлетворенность и вовлеченность статистически связаны с:
- прибылью,
- удержанием сотрудников,
- клиентской удовлетворенности,
- производительностью.
Более свежие исследования в IT-компаниях это также подтверждают.
У вовлеченных разработчиков обычно растут:
- технический долг,
- задержки в поставке результатов,
- изолированность знаний внутри отдельных сотрудников или команд,
- «тихий уход» (когда человек формально работает, но фактически перестает вкладываться).
А у вовлеченных команд чаще наблюдаются:
- более быстрая поставка результатов,
- более высокий уровень ответственности за результат,
- меньше дефектов,
- лучшее взаимодействие.
А оно нам надо?
Можно возразить: “А зачем мне быть вовлеченным? Я делаю то, что мне говорят на устаивающем уровне, за это получаю деньги, бизнес работает, а если вдруг загнется, ну ок, пойду в другую контору”. А вот давайте разбираться.
Возражение выше звучит весьма логично, ну а действительно зачем? нанимают же для выполнения определенных задач, если он с работой справляется, то какие могут быть вопросы? проще говоря, зачем напрягаться?
Ну…как бы да.
Если же сотрудник не справляется с обязанностями, то тучи сгущаются, но ведь “это уже совсем другая история”, да?
Дело в том, что сейчас от инженеров и менеджеров разных грейдов начинают требовать вовлеченности, становится сложно просто делать то, что тебе говорят и быть уверенным что твое место не отдадут другому.
Gartner в 2025 писал, что компании активно внедряют практики:
- регулярного обсуждения продуктивности;
- мониторинга вовлеченности;
- новых управленческих норм для hybrid/RTO-среды.
То есть акцент смещается от: «Ты сделал задачу?» к: «Насколько ты встроен в команду и процессы?»
В IT-компаниях после волны сокращений 2023–2025 годов стало заметно больше требований к:
- инициативности;
- самоорганизации;
- «делать больше меньшими командами».
Это регулярно упоминается в аналитике McKinsey и в материалах про AI-driven productivity.
Фактически компании пытаются получить:
- меньше сотрудников,
- но более вовлеченных и универсальных.
Возможно, в вашей компании ничего такого не ждут от сотрудников, что ж, может вам это пока и не нужно, но на рынке труда вы будете менее конкурентоспособны, да и ваша компания может со временем потерять инициативу в своей отрасли. В общем будете ли вы востребованы если придётся искать новую работу?
Тут еще и ИИ подтянулся: предположим вы middle-разработчик, сложных задач не много, тихо сидите попиливаете код, иногда надо запрос соптимизировать, иногда баг найти и такой работы 90%, активности не проявляете, ничем не выделяетесь, чётко, спокойно сделали задачу, взяли следующую. Вроде норм всё, но чем вы лучше ИИ-агента? пока, вероятно, многим, но, кажется, ИИ нагоняет.
Ну и если вы хотите расти по карьерной лестнице, то ваша вовлеченность очень поможет вам себя правильно преподнести себя. Этот свойство характера или, если хотите, навык сейчас очень ценится.
На самом деле, мне бы не хотелось вести повествование с позиции “будьте вовлеченным, потому что необходимо чтобы удержаться в профессии и расти по карьерной лестнице”. Кажется основной драйвер вовлеченности это интерес и самореализация.
Вот мне интересно делать классно работающие продукты, команды, проекты, приносящие пользу пользователю и чтобы хотеть это делать мне не нужно чье-то требование или разрешение.
Системные проблемы возникновения вовлеченности
Ситуация первая
Возражение, которое я, к сожалению, часто слышу: “В компании всё через жопу, а на сотрудников работодателю плевать…в такой ситуации мне симметрично плевать на бизнес работодателя и не собираюсь напрягаться, а не нравится — пусть увольняет”. Сюда я включаю весь спектр проблем:
- качество менеджмента;
- отсутствие автономия;
- недостаток смысла работы;
- недостаток признания;
- сложности с развитием;
- несправедливая система оценки и оплаты.
К сожалению, такое вполне себе бывает, правда проблема может не в компании в целом, а в конкретных менеджерах, процессах, а то и просто в непонимании того как и для чего бизнес существует — тут надо бы выровняться с руководством, но это тема для отдельной статьи. Тем не менее, ситуация, при которой взгляды и приоритеты компании и сотрудника сильно не совпадают вполне возможна.
Ситуация вторая
Равнодушие коллег.
Если вы вовлеченный работник, то вам 100% знакома ситуация когда к вашим предложениям не прислушиваются, а ваши усилия не ценят. Вы стараетесь, находите способы делать качественно и улучшать то что вас окружает, но ваши старания не замечаются, а все предложения или задвигаются на “на потом” или вам сразу говорят что это ненужная херня.
На счёт ваших предложений, за свои решения нужно иногда бороться. Поймите, на вашу инициативы будут выделены ресурсы: ваше время или других людей, возможно, железо, вам нужно уметь обосновать ваше предложение, желательно в количественных метриках, но может достаточно будет и логичных объяснений.
Если же вам говорят что вы предлагаете ерунду, то пусть потрудятся объяснить вам почему это ерунда — возможно, вы друг друга не поняли, а может это правда ерунда и тогда вам будет полезно понять в чём вы не правы.
Что касается равнодушия коллег, бывают ситуации когда всем вокруг действительно ничего не нужно и возможно вам не по пути с этими людьми, но не спешите раздавать такие ярлыки — сначала разберитесь в ситуации. Всерьёз вы можете повлиять только на своих подчиненных и тут можно попробовать вовлеченность ребят развивать.
Что касается всех других, то остаётся либо уходить либо мириться с ситуацией — статистически, в большинстве команд вовлечённые сотрудники в меньшинстве — вы можете и не найти команду лучше и может не так уж всё и плохо.
Ситуация третья
И еще одна ходовая ситуация: “Да когда мне блин этим заниматься?! Руководство давит сроками, у меня и так жопа в мыле, я либо буду перерабатывать (еще больше), либо еще больше растягивать сроки и получать за это по шапке”.
Возможно, вы работаете в стартапе, у компании сейчас, глобально, только одна цель (см. часть про стартапы) и всё происходящее логично и правильно. Вопросов нет, нужно “делать то, что должен и не спрашивать что дальше”.
Но если у вас боль-мень зрелая компания, то такое поведение менеджмента это проблема. При этом от вас могут всё равно требовать инициативности, активности. Выглядит как парадокс, но такое бывает.
Есть несколько причин такой позиции руководства:
- Менеджмент может давить по срокам чисто формально (“на нас давят сверху, вот мы и торопим, но если уж нужно больше времени, то ок”) и в работу вполне можно делать вдумчиво и качественно, а в процесс разработки вполне можно встроить как поиск улучшений как и, например, саморазвитие, по договорённости с руководством. Можно прям формально встроить это в процессы. Тогда разработка будет выглядеть так: “мы пытаемся сделать фичу как можно быстрее, но выделяем время на это, это и это, иначе будет говно в техничке, бардак в процессах и т. п. и наш бизнес накроется”.
- Такое поведение руководства может говорить и о его невовлеченности (“набиваю лычки, выполняю задачи, а дальше хоть потоп”). Мне даже трудно такое описывать, менеджер, особенно высокого порядка, может иметь только одну мотивацию: держаться за место, ему главное не попасть в немилость к своему руководителю и он просто приспосабливается. Ваша вовлеченность, будь вы хоть, EM, хоть TL, хоть инженером, ему не интересна, потому что он не хочет в этом разбираться, при этом и выделять формально на это время он не очень хочет, так как от этого могут пострадать его краткосрочные KPI. Сроки устанавливаются жесткие, при этом за несоблюдение сроков ругают, лишают премии и т. п.
Точно ли вам нужна такая работа?) Напомню, у нас уже не стартап, а взрослая компания, чем тогда вызван такой несистемный способ работы, точно ли объективными причинами? Может ротироваться в другой отдел? Или найти место работы получше?
Если вам хочется делать хорошо, а вам не дают и нет света в конце тоннеля…не вижу смысла долго терпеть.
Выгорание
Иногда на инициативы просто нет сил. Кажется сейчас уже почти все научились диагностировать у себя выгорание. Однако, далеко не все умеют с ним бороться, а бороться с ним довольно сложно, так что лучшая позиция это не выгорать, возможно, вы не понимаете насколько это состояние вам вредит и что последствия могут быть не только на вашу работоспособность, но и на личную жизнь, физическое и ментальное здоровье. Не выгорайте, ребята, а если выгорели, то боритесь с этим.
Можно ли качнуть этот навык?
Вы можете спросить: “Как бы это так делать, чтобы от этого действительно была польза?”. ИМХО, чтобы предлагать дельные вещи нужны:
- знания и, желательно (но необязательно), опыт;
- навык защиты (обоснования) своего предложения — это довольно легко набивается, если у вас нет проблем с коммуникацией, если же есть, то вам может быть не просто — понадобится помощь коллег и руководителя, тема большая, тянет, пожалуй, на отдельную статью;
- мотивация — об этом выше написано, если вы органически неравнодушны к тому что делаете, то это прекрасно.
Если вам чего-то из этого не хватает, то не беда, можно качнуть.
Я этот путь сам не проходил, но прокачивал это в ребятах из моих команд. Сразу скажу, что если человеку работа не интересна, то ничего не получится.
Предположу возможные ситуации:
- К вам пришел руководитель, и сказал что вам не хватает вовлеченности / активность / инициативности / внимания к деталям, это могут по разному называть имея в виду, что вам надо давать что-то от себя, а не только по указке и/или что надо качественнее работать. Либо вы сами хотите прокачаться.
Нужно четко понять что от вас требуется, определиться для себя почему вы до сих пор так не работали, мешает ли что-то начать так работать, выработать план вместе с руководителем (а может с наставником), договориться о выделении времени на реализацию этого плана и начать двигаться, старый добрый ИПР, банальщина, но ничего лучше пока не придумали. Вам обязательно нужно подветить то, что вам действительно интересно и попытаться составить держа во внимании ваши интересы.
Это должно просто стать частью вас, вы вышли на новый уровень и просто так живете. Работа не становится тяжелее, вы не тратите на нее больше времени. Но вы стали более ценным специалистом и, в идеале, поймали волну — работать стало интереснее и вы прям чувствуете что влияете своими решениями на продукты, системы, процессы, причем это актуально и для инженеров и для менеджеров!
- Вы менеджер и хотите прокачать сотрудника. Очень похоже: Вырабатываете с ним план (или делегируете это), договариваетесь о выделении времени на реализацию этого плана и начинаете двигаться.
Вам или наставнику очень важно попытаться заразить человека интересом к тому что он делает, если этого интереса нет или он погас и показать что его решения влияют на бизнес, пользователя, качество систем, потому что это действительно так! даже если человеку кажется что он просто винтик в большой машине. В такой работе нет мелочей, так как мы делаем очень сложные системы, которые должны работать 24/7.
Иногда одни вещи могут быть интересны, а другие — нет, в этом случае следует рассмотреть ротацию в команду где интересные задачи преобладают.
Встречное движение
Чтобы культура вовлеченности процветала работодатель должен её поощрять. Неравнодушные люди всё равно будут неравнодушными, но долго ли они будут вашими сотрудниками?
Всё-таки по-настоящему вовлеченных людей не то чтобы много и их воспринимать как стандарт, то что вы привлекли таких людей это скорее удача и нужно хвалить и поощрять таких людей, давать им возможность самореализовываться и творить, и тогда они принесут вашему бизнесу огромную пользу!
Что реально работает на уровне компании:
1. Понятные цели и связь работы с результатом
2. Автономия
3. Нормальная нагрузка
4. Сильные менеджеры
5. Хорошие инженерные практики
6. Ответственность вместо контроля
7. Рост и развитие
Эпилог
Вам желательно быть вовлеченным.
В идеале это просто ваще нормальное состояние.
Ну а если нет, то нужно вовлеченность качать, возможно, ее отсутствие и не помешает вам стать успешным, но точно затормозит вашу карьеру, ну и нельзя забывать, что вас в перспективе могут заменить на более вовлеченного сотрудника или на ИИ.
Но это все грубо и негативно звучит 🙂 Так просто интереснее жить! Работа совсем не главное в жизни, но большинство из нас вынуждены тратить на нее кучу времени, сил и нервов и если она не приносит хотя бы удовлетворения, то чёт совсем грустно как-то становится.