Рассматриваем реальный кейс молодого разработчика вместе с экспертом — в поисках "красные флажки" в работе.

Павел Вейник работает в IT уже более 20 лет, 15 из них — обучает разработчиков, правда, в последние четыре года — уже только более продвинутого уровня и в рамках курсов, где преподает. Интересная деталь: перед каждым новым потоком он лично встречается с желающими обучаться у него и иногда… их отговаривает.

— У меня есть система трех не. Не продавать ради продажи. Курс — это дорога роста, он должен подходить потенциальному студенту, поэтому и встречаюсь отдельно с каждым, слушаю его "рабочую историю". Отказываю, если вижу, что человек пока не готов вкладываться временем и усилиями. Или не понимает необходимость и hard-, и soft-скилов. Для карьерного роста необходимо комплексное развитие, а это означает как системные знания, так и умение подать себя и завоевать уважение коллег. На самом деле, дорогу осилит не идущий, а понимающий, куда идти. А с экспертом просто проще настроить компас.

В дано:

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

— Работаю в этом банке почти четыре месяца, и есть проблема — большая нагрузка, — рассказывает Александр. — Понятно, есть основной бизнесовый бэклог, им занимается каждый. Но еще — система дежурств, она тоже всех касается: примерно раз в месяц неделю следишь за продом, фиксишь баги, работаешь с тикетами Service Desk. Это сложно, потому что компания большая, а я в ней недавно… Поэтому меня ставят еще чаще! Говорят, что я должен врываться в прод — и кидают на дежурство, саппортом у основной смены. Пушат, чтобы "погружался быстрее и глубже". Это стресс: каждый баг прода мне в новинку, плюс постоянно отрываюсь от основных задач…

Комментарий Павла:

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

Это один из этапов роста для сеньоров — особенно пришедших из аутсорса и не видевших самого продакшна. Лезть в прод и в реальном времени смотреть мониторинг с логами. Ага, что-то прилетело на сервак, столько-то запросов в секунду в такое-то время — а вот тут мы задеплоили нашу фичу и ее время такое, есть разница, откуда она и так далее…

Понятно, что тебе сложно: новая система, проект большой… Но это зона твоего активного и горячего роста. А стресс можно уменьшать. Во-первых, просто понимая и принимая пользу происходящего. Во-вторых, не стесняясь просить совета. Это нормально!

— Про дежурства — перестану волноваться, — немного с облегчением продолжает Александр. — Но есть и другие звоночки с нагрузкой, из-за которых подумываю уйти. В конце почти каждого спринта есть овертайм — PM'ы всегда пушат взять на себя побольше. Ну, когда мы уже совсем под завязку, лид может им сказать свое стоп-слово… Но потом каждый спринт одно и то же: "Ребята, а можете еще вот это взять? Ну давайте, а?". А еще дежурства, много других активностей. Я хочу уйти, но еще и волнуюсь, как рекрутеры отреагируют на мои четыре месяца работы и что говорить в такой ситуации… Не рассказывать же про начальника-самодура…

Комментарий Павла:

— А это уже действительно нездоровая ситуация. Во всех компаниях, где я был техническим директором, всегда выстраивалась система, в которой разработчики сами оценивали задачу и брали в спринт. С учетом оговоренных рисков и расстановкой высокой и низкой приоритетности. И у архитектора, и у менеджера в такой системе есть золотое правило — уточнять с разработчиком его оценку времени. Не с позиции "а чего так долго", конечно. Если происходит "оценивает он, делаю я" — как вообще можно отвечать за итог в сроки?!

Всегда отвечай по срокам спокойно и конструктивно. И смотри реакцию. Если в ответ слышишь: "Два дня даю и меня не волнует!", то это уже жесткий красный флаг. Значит, менеджер тебя втаптывает, а не помогает работать. Если же ответ будет в рамках дипломатии: "Я понял, ты новенький, давай подумаем, что делать с этим", то есть шанс наладить мосты. Многое зависит от формата, который заведен в компании: тут или кулак, или поиск решения. PM знает, что если команда что-то не сделает — под прессом окажется он. Наверху у него спросят, почему другой менеджер выбил из своих людей работу, а у него не получилось. И сделают вывод, что он просто не умеет работать с командой. Система "пушить и давить" всегда строится сверху. И это нормальная причина для ухода. Стресс — нормальная причина что-то менять!

Но вообще… Три-четыре месяца, любой срок до полугода работы в одном месте и увольнение — это всегда минус. Однажды у меня была история, что я два месяца поработал и ушел. Так я вообще этот опыт в резюме не указывал. Может, и тебе так стоит поступить? Умение подать себя — это тоже важное и сильное знание. Я слышу твое волнение и понимаю, что курс тебе подойдет, отговаривать не буду!

Выводы Павла:

— Часто сталкиваюсь с тем, что опытным инженерам хватает знаний, но не хватает умений и навыков, как влиться в новую команду и четко доносить свою позицию. Это проблема не только Алексея. Когда-то давно я понял, что техлидом или архитектором нельзя стать набирая в стек дополнительные фреймворки или добавляя новые домены в резюме. Технический лидер — это образ мышления. Именно поэтому почти пять лет назад я создал комьюнити Hard&Soft Skills, где опытных инженеров поддерживают такие же, будь то эксперты-преподаватели или сообщество выпускников. Самое приятное в преподавании матерым инженерам — видеть, как взрослые люди осознают, что перешли на другой уровень абстракции в мышлении, по-другому стали смотреть на проблемы и их последствия, видят систему целиком.

Кейс был разобран на вебинаре в рамках Technical Leadership — восьмого набора самого востребованного курса Hard&Soft Skills, на котором инженеры продвинутого уровня доводят свои hard- и soft-скиллы до идеала. Шанс записаться на курс (через предварительное собеседование) еще есть — переходи в официальном Telegram-канале. Старт обучения — 28 ноября.