Команда, где младшему сотруднику шел пятый десяток, а самой опытной специалистке — уже восьмой, не только пережила болезненный переход на новую систему, но и закрыла критичные задачи лучше, чем ожидал ее молодой руководитель. История про возраст в IT, опубликованная на Habr / Карьера, бьет по одному из самых живучих мифов отрасли: что после 45 разработчик якобы превращается в дорогой и бесполезный артефакт из прошлого.
Поводом для обсуждения стал личный текст руководителя Ивана Донченко о событиях 2014–2015 годов в компании «АйТи Энерджи Сервис» — преемнице Главного вычислительного центра энергетики, основанного в 1968 году. Автор вспоминает, как в 27 лет получил повышение с тимлида до руководителя направления и вместе с ним — не самый красивый набор предубеждений. В его зоне ответственности оказались сразу две реальности: молодая команда, строившая вторую очередь ключевой системы, и «Старая Гвардия», поддерживавшая первую версию, собранную вокруг Excel-файлов с макросами.
Сюжет здесь важен не как ностальгия по корпоративному прошлому, а как довольно точный срез того, как в IT рождается эйджизм на уровне команды. Новый руководитель видел в возрастных сотрудниках прежде всего бюджетную строку. Люди с большим стажем казались ему временной обузой: пережить миграцию, а потом, выражаясь его же логикой тех лет, «почистить» штат. Ситуация знакомая для любой компании, которая меняет стек, автоматизирует старые процессы или пытается резко омолодить команду под новую технологическую повестку.
На бумаге все выглядело предсказуемо. Старая система продолжала жить, пока параллельно разрабатывали новую. Затем команды физически посадили в один open space, а потом и организационно объединили, фактически удвоив число подчиненных руководителя. Чем ближе был запуск, тем сильнее росло напряжение. Поддержка пользователей шла в том же помещении, звонки первой линии не давали никому расслабиться, а масштаб проекта был вполне индустриальный: сотни энергетических компаний по стране, две госкомпании на стороне заказчика и требования Минэнерго РФ по срокам консолидированной отчетности. То есть речь не о внутреннем чат-боте для отпуска, а о системе, сбой в которой очень быстро превращается в проблему для крупных организаций.
После запуска начался классический пострелизный ад. Пользователи, по описанию автора, прошли все стадии — от отрицания до принятия, а команде было не до оргструктуры: «все делали всё». Но когда система стала стабилизироваться, возник тот самый неудобный вопрос: что делать с людьми, годами работавшими с VBA-формами, Excel-отчетами и старыми процессами поддержки? И вот здесь история разворачивается в противоположную сторону. Вместо массового выбывания началась перепаковка компетенций. Сотрудницу, занимавшуюся аналитической отчетностью, перевели на SAP BusinessObjects. Сначала она делала верстку и оформление отчетов, затем освоила бизнес-логику, а позже взяла на себя разработку многомерной аналитики. Специалисты с опытом работы с базами данных стартовали с точечных правок, а затем дошли до процедур, триггеров и оптимизации запросов.
Почему сработал не возраст, а способность учиться
Самый показательный эпизод связан с сотрудницей по имени Лидия Никитишна, которой, по словам автора, шел уже восьмой десяток. Именно ее молодой руководитель почти до последнего мысленно держал в списке на выбывание. Причина была банальна и неприятна: возраст, стереотипы и ощущение, что новый технологический контур она не потянет. Но вмешался проектный форс-мажор. Субподрядчики, поддерживавшие часть системы на Oracle APEX, ушли, и направление пришлось поднимать своими силами. Опыт с Oracle у компании был, а вот с APEX — нет. Решение оказалось вынужденным: попробовать в этой роли сотрудницу, которую почти списали.
Результат, если верить автору, оказался быстрым и болезненным для всех предубеждений сразу. За месяц Лидия Никитишна освоила новое направление настолько, что проблема фактически перестала быть проблемой. Формулировка в первоисточнике еще жестче: задачи она «лузгала как семечки». Это важная деталь не ради красивой человеческой истории, а потому что она ломает удобную для менеджеров отговорку: будто возраст в IT автоматически означает низкую обучаемость. На практике маркером оказался не возраст, а готовность человека включаться в новое, задавать вопросы, не бояться стартовать с азов и держать темп, когда проект горит.
Собственно, сам автор формулирует главный вывод довольно честно: его роль свелась к тому, чтобы быть рядом, подсказывать и не дать людям почувствовать, что их бросили в новую среду на выживание. Остальное они сделали сами. Это неприятный, но полезный вывод для руководителей. Очень часто проблема не в том, что возрастные специалисты не умеют адаптироваться, а в том, что компания даже не пытается построить для них внятный маршрут адаптации. Людей десятилетиями держат в узкой зоне задач, а потом внезапно объявляют устаревшими, потому что стек изменился. Хотя нормальная логика здесь обратная: если сотрудник знает предметную область, процессы заказчика, типовые сбои и организационные узкие места, то доучить инструмент нередко дешевле и быстрее, чем выращивать все это с нуля в новом человеке.
Для российского рынка этот сюжет особенно чувствителен именно сейчас. Разговоры про возраст в IT шли и десять лет назад, но тогда отрасль действительно была сильнее завязана на культ «быстрых рук»: новый фреймворк, новая мобильная платформа, новый стартап, новая команда. Теперь среда изменилась. Бизнес живет в постоянной миграции между инструментами, поверх разработки навис ИИ, а ценность чистой скорости кодинга постепенно перераспределяется. Когда рутину можно делегировать ассистентам, выше становится цена тех, кто умеет отличить важную ошибку от косметической, понимает домен, видит риск до инцидента и не паникует во время перехода на новую архитектуру. Это уже не романтика хакатона, а взрослая эксплуатация сложных систем.
Что это значит для команд и найма
Из текста Донченко можно вытащить и вполне прикладной вывод для бизнеса. Если команда проходит болезненный технологический поворот, руководителю стоит смотреть не на дату рождения в резюме, а на три вещи: способность учиться, глубину доменной экспертизы и рабочую дисциплину. В его истории на пенсию в итоге проводили только одного сотрудника — не потому, что тот был старше остальных, а потому что не хотел ни брать новые задачи, ни работать по-настоящему. Это, пожалуй, самое трезвое место всей истории: проблема не в возрасте как таковом, а в отказе адаптироваться. И это одинаково верно и для 25-летнего разработчика, который застрял в одном стеке, и для 60-летнего специалиста, который не хочет выходить за пределы привычной зоны.
Для HR и IT-директоров здесь тоже есть неприятный, но полезный сигнал. Фильтрация кандидатов по возрастным маркерам выглядит все менее рациональной, особенно в командах с тяжелым легаси, сложной отраслевой логикой и длинным циклом внедрения. На рынке много разговоров о дефиците кадров, но дефицит нередко создают сами компании, когда заранее вычеркивают людей с опытом только потому, что те не похожи на идеализированный образ «быстрого» разработчика. История со «Старой Гвардией» показывает более скучную, но работающую модель: смешанные команды, где вчерашние студенты и ветераны отрасли закрывают разные типы рисков, часто оказываются устойчивее моновозрастных коллективов.
Именно поэтому спор про возраст в IT уже трудно свести к морали или корпоративной этике. Это вопрос эффективности. Если нейросети и дальше будут удешевлять типовую разработку, рынок начнет еще жестче переоценивать то, что плохо автоматизируется: опыт миграций, знание предметной области, умение удерживать систему в рабочем состоянии и обучаться без истерики. Выиграют не обязательно самые молодые и не обязательно самые опытные. Выиграют команды, которые перестанут путать возраст с профпригодностью.