Всем привет! Когда-то на старте карьеры мне на собеседовании пообещали одну очень заманчивую вещь — развитие. Мне казалось, что я попаду в среду, где меня будут постепенно учить, направлять и поддерживать. Вряд ли кого-то удивлю, сказав, что ожидания начинающего специалиста и реальность не совпали. С тех пор я научилась брать развитие в свои руки, составлять рабочий ИПР (индивидуальный план развития) и добиваться заметных результатов за короткие циклы. Делюсь опытом в своей первой статье.   

Меня зовут Анастасия Новожилова, я Head of QA в Sminex, в IT — с 2012 года. Я работала в разных компаниях и командах: где-то процессы уже были выстроены, а где-то QA и саму логику развития приходилось выстраивать с нуля. Думаю, многие выбирают компанию не только из-за зарплаты, задач или бренда, но и потому, что там обещают рост, обучение и перспективы. Это особенно цепляет начинающих, также было и у меня – на первую работу я шла за профессиональным развитием. А дальше выяснилось, что всё это «развитие» на практике выглядит примерно так: тебя никто не поддерживает, ничего не объясняют, а просто кидают в воду и смотрят, выплывешь или нет. Не сразу, но в какой-то момент я всё чаще ловила себя на мысли, что здесь что-то не так. А потом — на другой: похоже, если я хочу расти, пора перестать ждать готовую систему и начать собирать её самой.

Сейчас я работаю в Sminex и на контрасте особенно заметно, насколько легче двигаться вперёд, когда у тебя есть ориентиры и регулярная поддержка. У нас развитие встроено в работу: есть понятные ИПР, более ясный вектор роста и внимание к тому, как человек двигается дальше. Но мне хочется поговорить не только о том, как хорошо, когда система уже есть. Гораздо чаще всё устроено иначе: развитие вроде обещано, но по факту человеку приходится выстраивать его для себя самому. И вот в такой ситуации ИПР может стать полезным рабочим инструментом, даже если идеальных условий вокруг нет.

Когда ИПР начинает работать

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

Именно на таких вещах я впервые очень ясно почувствовала, что ИПР может быть полезным, а не формальной бумажкой про «развитие». В этом, по-моему, и суть. ИПР начинает работать не тогда, когда в нём написано что-то красивое и абстрактное. А в момент, когда он помогает менять то, как ты работаешь. Когда развитие перестает быть отдельным пунктом на «когда-нибудь потом» и начинает происходить внутри реальных задач.

Рабочая цель — это не «хочу развиваться»

Очень часто проблема начинается уже на уровне формулировки. «Хочу развиваться», «хочу стать крутым специалистом», «хочу расти» — это хорошие намерения, но они пока ничего не меняют. Непонятно, что именно человек начнёт делать иначе, в какой момент это можно будет заметить и по каким признакам вообще понять, что движение есть.

Рабочая цель начинается там, где понятно, что именно ты будешь делать иначе.

Не «хочу стать автономнее», а, например, «хочу приносить план проверок и риски по задаче». 

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

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

Почему ИПР так часто ломается

Даже с понятными целями наш ИПР может забуксовать. И дело тут в достаточно приземленных причинах:

• ИПР составляют для галочки и потом больше не открывают,

• в плане есть пункт «учиться», но нет плана действий внутри реальных задач,

• развитие не связано с текущей работой,

• операционка начинает спорить с ростом — и, конечно, побеждает всё срочное,

• нет понятных точек результата, а значит, прогресс сложно заметить,

• нет регулярной сверки.

Вот здесь, как мне кажется, особенно важно не начинать ругать себя там, где проблема на самом деле в самом устройстве процесса. Когда развитие вынесено за пределы работы, оно почти всегда проигрывает. Потому что рабочая реальность сильнее благих намерений. У задач есть сроки. У релизов есть срочность. У команды есть текучка, инциденты, срочные фиксы и всё остальное, что легко съедает «время на развитие», если оно существует где-то в отдельном воображаемом слоте. Поэтому рабочий ИПР держится не на силе воли, а на маленьких шагах, ритме и видимом результате.

Из чего состоит хороший ИПР

Мне нравится очень простая структура:

цель → действия → результат

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

Это важно, потому что ИПР очень быстро становится формальностью, если в нём не остаётся ничего осязаемого. За шесть недель не нужно делать ничего гигантского. Обычно вполне достаточно трёх-четырёх полезных результатов, которые можно показать, обсудить и при необходимости улучшить. Это может быть страница с рисками и планом проверок, чек-лист или шаблон, разбор дефекта по схеме «причина → меры» или улучшенный кусок регресса.

Но важны не только сами артефакты. Главное — меняется ли сама работа. Например, стало ли меньше вопросов в духе «а что вообще тестить?». Стало ли больше инициативы и ясности. Стало ли меньше переделок. Появилось ли больше доверия к твоим решениям. Вот по этому обычно и видно, что ИПР работает.

ИПР нужен ритм

Даже хороший план довольно легко бросить, если он существует без ритма и регулярности. Мне нравится короткий цикл на шесть недель. Он достаточно длинный, чтобы что-то успело измениться, и достаточно короткий, чтобы про ИПР не забыли. Внутри этого цикла хорошо работает очень простая логика: один маленький результат в неделю и короткая сверка раз в две недели. На такой сверке обычно достаточно трёх вопросов: что сделано, что мешает, что меняем.

И здесь есть ещё одна важная вещь: ИПР не должен превращаться в жёсткий план, который нельзя менять. Если у вас поменялись приоритеты, прилетел сложный релиз, сместился фокус команды — план можно пересобрать. Это нормальная адаптация под реальность. Но если план не трогали две недели и больше, то есть большой шанс, что он уже не работает или устарел.

Цели развития у джуна, мидла и сеньора

Ещё одна ошибка, которая часто мешает, — смотреть на развитие слишком одинаково для всех. У джуна рост обычно начинается с надёжности: с перехода от случайных проверок к аккуратной и повторяемой работе. Поэтому здесь хорошо работают такие задачи: вести и обновлять чек-лист по определенному разделу продукта, разбирать дефекты и пытаться понять, почему они произошли и как их можно было бы поймать раньше. Ещё до разработки задавать несколько базовых вопросов к требованиям: что здесь критично, где крайние случаи, какие нужны данные. На этом уровне развитие довольно быстро становится заметно: меньше пропусков, меньше хаоса, больше понятности (и для самого человека, и для команды).

У мидла фокус уже другой. Здесь мало просто хорошо выполнять проверку. Важно уметь собрать вокруг неё ясную картину: что критично, что можно отложить, где риск выше, где ниже, на что смотреть в первую очередь. Поэтому задачи мидла чаще связаны с планом, приоритетами и риском. Это может быть одностраничное описание рисков по фиче, план проверок с приоритетами «обязательно / желательно / если успеем», мини-гайд по тестированию модуля или предложение о том, как улучшить регресс в своей зоне — что сократить, что усилить, что сделать устойчивее.

У сеньора рост уже почти никогда не измеряется количеством проверок. Он виден в другом: становится ли система устойчивее и предсказуемее. Здесь важны постмортемы с понятной связкой «причина → действия → контроль», улучшение и стандартизация регресса, ответственность за целую зону — что проверяем, как мониторим, как релизим, — и в целом работа на то, чтобы качество держалось не на героизме отдельного человека, а на системе. Это, наверное, одна из самых важных разниц: сеньор ценен не тем, что он всё удержал на себе, а тем, что после него остаётся система.

Роли сотрудника и руководителя

У ИПР всегда должны быть понятные роли. Очень часто всё буксует по простой причине: сотрудник ждёт, что его будут развивать, а руководитель думает, что человек сам сориентируется. В итоге план зависает где-то между ожиданиями.

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

Что делать, если поддержки нет

На практике включённый руководитель есть не всегда. И это неприятно, но не смертельно для самого подхода. Если поддержки нет, ИПР всё равно можно двигать по упрощённой схеме: одна цель на шесть недель, один шаг в неделю и один маленький, но видимый результат. В такой ситуации особенно важно не уходить в абстракцию. Лучше держаться за что-то очень конкретное: шаблон, чек-лист, страницу рисков, разбор дефекта, улучшение в регрессе, мини-гайд — что угодно, что можно показать другим и обсудить не как «оцените меня», а как рабочий результат. Можно поискать готовые материалы в открытых источниках или попробовать собрать самостоятельно. У меня как раз был такой опыт: при поиске работы я пошла анализировать информацию по грейдам и компетенциям QA-специалистов на рынке. В итоге собрала это всё в единую таблицу. Это помогло мне со стороны посмотреть на свои знания, соотнести их с ожиданиями разных компаний, выявить новые векторы развития. Понятно, что у разных компаний всё может сильно отличаться, но поделюсь здесь файлом, возможно, кому-то будет полезно. 

Обратную связь можно просить у команды, у смежников, у профессионального сообщества. И здесь очень помогает правильно сформулированный запрос. Например: «Посмотрите на мой результат: что стоит улучшить, чтобы этим мог пользоваться кто-то ещё?». На такой вопрос людям обычно легче отвечать. Он конкретный, и сразу переводит разговор из оценки личности в доработку результата. Ещё полезно вести для себя очень простой трекер: сделал / понял / поменяю.

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

Важная вещь напоследок

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