Или станешь менеджером, или накопишь много денег и тогда сможешь дауншифтнуться, кататься на серфе у берегов Австралии, выращивать помидоры в деревне.
В поисках ответов на вопрос “А куда дальше развиваться в профессии?” всё ещё много стереотипов и движения по инерции, но кажется, становится получше. Инженеры всё чаще имеют возможность двигаться не обязательно в сторону превращения в лида или руководителя, но быть высоко квалифицированными individual contributors. В грейдах появляется больше вариативности.
Интересная сторона вопроса – кейсы про горизонтальное развитие, когда люди меняют одну ИТ-роль на другую. Обязательно ли это должно происходить при достижении уровня senior в ранее выбранной роли? Возможно ли в рамках одной компании или чаще связано со сменой работодателя?
Расспросили об их опыте смены роли коллег из ИТ-команды Сравни:
Таня – прошла путь от специалиста первой линии поддержки до Delivery-менеджера в DevOps-команде;
Максим – прошёл путь от QA-инженера к Delivery-менеджеру и затем к Product Owner;
Света – из QA-инженера стала Frontend-разработчиком.
Вот, что они рассказали.
Карьерный трек
Таня
Работать я начинала специалистом первой линии поддержки. По прошествии какого-то времени поняла, что достигла “потолка” – знала, как решить любой входящий запрос; стало скучно.
Знакомые позвали в другую компанию, на роль QA-инженера. Прямого опыта тестирования у меня на тот момент не было, но люди знали, что я ответственная, и считали, что справлюсь – для них этого было достаточно.
Проработала в роли QA-инженера 1.5 года. Доросла до тест-менеджера с командой в 12 человек.
Через какое-то время в компании случились организационные изменения, роль тест-менеджера была упразднена. Я решила остаться в организации, в новой для себя роли – Scrum-мастера. Это были времена Agile-трансформаций, мне понравилась идея уходить от сценариев в духе “3 месяца разрабатываем, ещё 3 месяца тестируем и потом выясняем, что пользователям нужно что-то другое” в сторону более коротких итераций.
По прошествии времени здесь снова на горизонте замаячил “потолок” – процессы настроены, команда продуктивно взаимодействует с Product Owner, всем всё комфортно, прозрачно и предсказуемо. Я решила, что пора двигаться дальше и перешла в один из топ-5 проектов компании и занялась задачей по организации межпроектного взаимодействия в области сквозного тестирования.
Не все изменения в карьере были по моей инициативе – в 2022 компания ушла из России, я пошла искать новую работу. Пришла в Сравни на роль Delivery-менеджера в DevOps-команду. Пригодился опыт работы Scrum-мастером и тест-менеджером – умение работать со сроками, планировать, выстраивать отношения с командой.
В Сравни я пришёл в качестве QA-инженера. На мой взгляд тестировщикам важно уметь общаться, выстраивать коммуникации – нужно “быть на короткой ноге” с разработчиками, аналитиками; со всеми находить общий язык. Общаться я умею и люблю в обычной жизни – пригодилось и в работе.
Со временем я стал практиковать то, что называется навыками T-shaped – в дополнение к своей основной специализации тестировщика стал участвовать в аналитических и продуктовых задачах.
В какой-то момент наша Product Owner ушла из компании – на время поисков нового человека на эту роль обязанности подхватил я. Когда появился Product Owner, я встал перед выбором – вернуться в тестирование или заняться чем-то ещё. Посоветовался с руководством насчёт вариантов, появилась опция стать Delivery-менеджером.
Попробовал – понял, что-то не так. Снова обсудил возможные сценарии относительно роли с руководством – в этот раз появился вариант стать не временным, а постоянным Product Owner в одной из команд, занялся этим.
Следующее изменение случилось в тот момент, когда работа над продуктом вышла на плато – почувствовал, что нужен новый вызов, сложная задача. В очередной раз отправился обсуждать опции и договариваться про роль – в итоге стал Product Owner в своём нынешнем продукте.
Работать я начинала в качестве QA-инженера. Сначала занималась ручным тестированием, потом автотестами. Переход был для меня органичным – нравилось разбираться с кодом.
Решила попробовать пойти дальше по пути автотестирования, сменила компанию. Там случилось расхождение между ожиданиями и реальностью: думала “сейчас будет больше кода в работе”, а по факту пришлось заниматься “продажей” идеи автотестов руководству, разбираться не с техникой, а с внутренней корпоративной политикой. Пошла снова менять работу, устроилась в Сравни QA-инженером на ручное тестирование.
Чем дальше, тем отчетливее я понимала, что хочу заниматься разработкой. Стала смотреть обучающие видео, читать документацию, готовиться к собеседованиям на разработчика. Когда посчитала, что готова начать подаваться на вакансии по разработке, пошла предупредить руководителя о планах по смене роли. Он предложил попробовать сменить специализацию, оставаясь у нас в команде.
В течение пары месяцев это был гибридный формат работы: часть времени я занималась тестированием, другую часть посвящала разработке. Постепенно перешла в разработку на фултайм.
Из полезного – по совету тимлида начала погружение в процессы в новой роли с правки мелких багов.
Несмотря на то, что формально я переставала заниматься тестированием, мне помог советами и морально поддержал руководитель направления QA, за что я ему благодарна.
Что было сложно
Таня
Когда переходила из тестирования в тест-менеджмент, всё время хотелось пойти всё за всех протестировать самой (“я ж QA!”).
В работе со сроками сложным было научиться не занижать прогнозы (“мы ребята умные, успеем”) и не завышать предполагаемые моменты готовности (“заложим +30% времени, на всякий случай”). Здесь пришлось даже проводить отдельные ретроспективы – не о команде и итогах спринта в целом, а для корректировки того, как считаем сроки.
Света
Учиться читать чужой код – боль. На курсах по разработке практически все примеры – красивые и аккуратные. В реальности реальный код может выглядеть сильно менее привлекательно.
Как понять, что пора менять роль
Таня
Для меня главный триггер – это потеря интереса. Когда всё одно и то же, всё понятно и предсказуемо – начинаешь задумываться о том, чтобы идти дальше.
Важный инструмент в помощь с определением подходящего момента для перемен – обратная связь от окружающих. Было несколько моментов, когда я спрашивала фидбек у коллег и ментора; их ответы мне помогли, добавили определенности и решимости.
Советы для тех, кто задумывается о смене роли
Максим
В любой непонятной ситуации – поговори с кем-нибудь об этом. С командой, коллегами, знакомыми. Их опыт и взгляд со стороны могут подсветить моменты относительно возможной смены роли, которые ты не замечаешь. Или наоборот скажут тебе то, что ты и так думаешь сам – тоже полезно, как дополнительный довод, что ты на правильном пути в своих поисках.
Мне в смене роли несколько раз помогал разговор с руководителем. Тут важно не просто жаловаться и считать, что тебя должны обеспечить всеми необходимыми возможностями для профессионального развития. Твоя карьера – твоя ответственность – твоя инициатива. Аргументируй, подсвечивай свои сильные стороны, признавай и принимай точки роста и ограничения.
Таня
Когда только начинаешь заниматься чем-то новым, есть риск, что не получится. Нужно быть готовым к негативной обратной связи и простому человеческому недовольству. Да, неприятно, но если пережить это, дать эмоциям пройти все стадии, то в любом фидбэке, даже негативном, можно найти массу полезных идей, мотивирующих тебя на рост.
А если речь идёт не только о новом для тебя деле, но и в целом мало привычно для людей в компании процессе (так было у меня в своё время со Scrum), лучше быть морально готовым, что будут недовольные уже хотя бы потому, что отторжение может быть вызвано нововведения самими по себе, а не тем, как конкретно ты это делаешь. Правильный настрой поможет сформировать более реалистичные ожидания.
Ещё – в хорошем смысле прагматичным подходом к смене роли может быть установка на то, чтобы не торопиться сжигать мосты и не стремиться радикально менять вообще всё. Например, для начала можно присмотреться к новым возможностям в рамках той же компании – поискать варианты перейти в другой проект или команду, на другую роль. Довольно часто такие варианты существуют.
Света
В процессе освоения чего-то нового не нужно стесняться задавать вопросы, даже даже если кажется, что спрашиваешь что-то глупое. В большинстве случаев люди готовы помочь; среди коллег полно отзывчивых и понимающих людей.
Насмотренность решает. Смотри как делают другие, читай документацию – в какой-то момент количество начнет превращаться в качество.
Ещё – когда узнаешь что-то новое, расскажи об этом другим. Новичкам в команде; коллегам, кто может столкнуться с подобными задачами и проблемами. Так не только поможешь окружающим, внесешь вклад в общее дело шаринга экспертизы, но и в процессе подготовки к расссказу систематизируешь свои знания, наведешь порядок у себя в голове.
===
Такими историями поделились коллеги из ИТ-команды Сравни о своем опыте смены роли. В подобных рассказах неизбежно много субъективного, нужно учитывать контекст, встречается “ошибка выжившего”. Поэтому не возьмёмся назвать опыт ребят универсальным, советовать всем поступать в точности как они.
Но надеемся, эти истории могут натолкнуть вас на какие-нибудь полезные мысли о развитии в профессии, со сменой роли или без.
“Насмотренность решает” (с)