В ближайшее время многие компании столкнутся с необходимостью оперативно адаптировать новых сотрудников в команде и на проекте. Далеко не всегда это просто сделать, особенно в сжатые сроки.

Елизавета Голованова, ведущий аналитик в Лиге Цифровой Экономики, поделилась опытом и лайфхаками, которые помогут сделать из потерянных джунов уверенных в себе специалистов, чтобы это было выгодно для всех сторон.

Наша компания недавно преодолела планку в 5,5 тыс. сотрудников и продолжает расти. Мы регулярно проводим стажировки для молодых специалистов и для тех, кто хочет сменить профессию. Я поделюсь своим опытом вывода начинающих сотрудников на проекты, а также расскажу, как сделать появление нового специалиста полезным и выгодным для всех сторон.

Я сама стала аналитиком два с половиной года назад и была именно тем джуном, который при помощи стажировки обрел новую профессию. 

Адаптацию я проходила в стиле «плыви, кутеночек». Меня вбросили в проект и сразу стали давать задачи, к которым на стажировке не готовили. Если честно, было очень страшно.

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

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

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

А вот на поддержку и развитие действующих систем будут направлены джуны-аналитики.

Что они из себя представляют? Я сейчас не буду обращаться к официальной литературе и классификации, а оттолкнусь от своего представления. 

Это выпускник университета по специальности, сотрудник, прошедший переквалификацию с помощью стажировок, или аналитик, который в своем единственном проекте занимался техническим писательством и поверхностно погружен в другие важные аналитические дела.

Помимо прочего, мне доводилось адаптировать в своем проекте опытного аналитика, быть наставником выпускника вуза, а также радушно встречать в команде коллег любых ролей. Я нередко рассказываю о нашем продукте дизайнерам, разработчикам и тестировщикам. (Если честно, всегда проще рассказать самостоятельно, чем потом недоумевать, почему новый коллега не понимает «элементарных вещей».)

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

Часть 1. «В вашем доме появился кутенок!»

Как подготовиться к адаптации с нового сотрудника и с чего лучше начать, чтобы не добавить себе проблем в дальнейшем

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

• неверное ведение документации (несоблюдение шаблонов, сохранение не в тех местах, дублирование каких-либо артефактов и так далее);

• коммуникации не с теми коллегами (заведение переписок, назначение встреч на участников не того уровня, например, вместо аналитика смежной команды джуны сразу пишут лидеру трайба);

• принятие своевольных «гениальных решений» (внезапно полностью изменить интеграцию, потому что, по его мнению, так будет лучше, а в действительности методы существуют именно в таком виде, потому что у вас древний контракт, который, что называется, «работает — не трожь»).

И опасаясь всех этих событий, мы зачастую преждевременно негативно относимся к новичкам. 

Сидишь ты, работаешь свою работу, и вдруг тебе вручают этого замечательного товарища в руки и требуют за месяц добиться от него космической производительности.

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

Первое, что пришло мне в голову, когда со мной случилось такое счастье — это залезть в «Гугл».

По запросу «Как быстро адаптировать сотрудника на проекте?» можно найти следующее:

1. Проинформируйте новичка о политике и преимуществах компании.

2. Обеспечьте понимание сотрудником своей роли.

3. Проведите обучение.

4. Ознакомьте сотрудника с корпоративной культурой.

5. Помогите сформировать взаимодействие с коллегами.

Ну, первый и четвертый пункт мы все-таки вынесем за скобки, и пусть этим занимаются HR и Product Owner. А вот второй, третий и пятый в действительности придется реализовывать вам.

Многие читатели наверняка подумали: «Ага, да у меня своих задач вагон и маленькая тележка, еще кого-то обучать, погружать в проект, давать понимание чего-то там».

От всей души понимаю. Когда все горит (а если у вас не горит, научите меня как), разработчик ждет требований, тестировщик — утверждения тестовой модели, дизайнер — согласования макетов, а Product Owner просит написать кучу ОЧЕНЬ ВАЖНЫХ писем, вклинить в свой список дел еще и чью-то адаптацию кажется совсем невозможным и утомительным мероприятием.

Но что, если посмотреть на это под другим углом? Джун-аналитик — это обуза или соратник?

Мое субъективное наблюдение говорит о том, что наш менталитет не позволяет делать вложения ресурсов без сиюминутной выгоды. Зачем тратить свои силы, если не понятно, принесет ли это какую-то пользу или нет? В случае с молодым аналитиком (я вам на крови поклянусь, если хотите) — точно принесет.

Ведь на практике, если не вложиться в аналитика на старте, вы с высокой вероятностью все равно потратите кучу времени на то, чтобы:

• верифицировать его требования;

• переделывать за ним задачи;

• исправлять допущенные ошибки;

• управлять ожиданиями заказчиков, которые взбунтовались из-за сорванных сроков поставки;

• и так далее и тому подобное. 

Всегда есть риск, что этих временных затрат будет даже больше, чем придется потратить на адаптацию.

Поэтому тем, кто только что узнал, что у него на проекте грядет пополнение, лучше расставить в своем календаре на ближайшие пару недель несколько болванок встреч. Полчаса-сорок минут, не больше. Предварительно стоит подготовить:

1. Артефакты по вашему проекту:

   1. Описание системы (для кого, зачем, что умеет);

   2. Архитектуру;

   3. Бизнес-требования (в идеале с диаграммами, картинками и прочими наглядными штуками);

   4. Технические требования.

2. Список заинтересованных лиц:

   1. Внутри команды;

   2. От заказчика;

   3. От зависимых и смежных систем.

3. Структуру процессов внутри команды:

   1. Кто и когда берется за задачу;

   2. DOR, DOD;

   3. Зоны ответственности аналитика (есть ли авторская приемка, нужно ли читать за разработчиками код, чье слово решающее в вопросах макетов и дизайна).

4. Примеры задач по проекту:

   1. Истории;

   2. Дефекты.

На встречах сначала лучше рассказать о своем проекте, а затем выдать коллеге все, что можно почитать, изучить, пощупать.

Все становится понятнее, если есть возможность увидеть это воочию и использовать по назначению.

Затем в начале новых встреч стоит выделить время на ответы на возникшие вопросы и не забывать: глупых вопросов не бывает, глупым будет только то, что постеснялись спросить.

При необходимости лучше потратить пятнадцать минут в начале или в конце рабочего дня, чтобы ответить на вопросы к поставленным задачам. Так наставник будет отчасти контролировать происходящее и сможет вовремя исправить ошибки, а также создать ощущение надежного плеча рядом.

Таким образом, процесс погружения нового члена команды будет систематизированным, контролируемым и не выдергивающим из задач.

И на первый взгляд это все может показаться таким объемным, долгим, сложным, но так будет только в первый раз. На самом деле, если пройти этот путь единожды, каждого нового сотрудника можно будет встречать по накатанной и практически без усилий. 

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

Часть 2. «Смотри, кутенок, все, на что падает свет, — наше владение, и когда я уйду, это будет твоим!»

Для новичка проект — как не открывшаяся до конца игровая карта. Как помочь освоить ее быстрее?

На мой взгляд, топ-2 проблемы в работе неопытных аналитиков выглядят так:

1. Слишком много времени на выполнение задач, а следовательно, задержка разработки.

2. Дефекты требований, а с ними трата временного и человеческого ресурса на исправление этих самых дефектов, которые обязательно проскользнули в разработку, и не дай бог в пром.

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

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

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

После получения задачи хороший сотрудник сначала пытается изучить карту и только потом приступает к выполнению задания.

Если при этом он не понимает, что прячется за туманом соседних областей, он может упустить что-то важное или принять сложно поддерживаемое и нерасширяемое решение. И наставник будет смотреть на это и гневливо недоумевать: «Да как так вообще можно было сделать?!». Но в действительности новый коллега не виноват, он сделал как видел. 

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

В идеале, конечно, у вас должен быть артефакт с описанием продукта, о котором я упоминала в предыдущем блоке, но как мы все знаем, идеального мира не существует, а устно объяснить можно даже больше и понятнее. 

И вот когда новоявленный сотрудник увидит всю картину в целом, ему будет проще выполнять свою работу, а наставнику не придется разгребать за ним значительное количество косяков.

Часть 3. «Одно из двух: можно или от ошибок прятаться, или... извлечь урок»

Как давать конструктивную критику, которая предотвратит ошибки джуна в дальнейшем

Теперь я хочу рассказать о камне, о который мне довелось споткнуться не единожды, прежде чем получилось понять, почему это происходит и как обойти препятствие.

Мы можем сделать все идеально, полностью погрузить в проект, выдать на руки все координаты, явки и пароли, но рано или поздно мы все равно столкнемся с тем, что новоиспеченный аналитик допустит ошибку.

Что мы обычно делаем, когда новичок совершает оплошность? 

Мне в таком случае всегда было проще сказать: «С кем не бывает» и исправить эту ошибку за своего коллегу, чем помочь ему самостоятельно с этим разобраться. 

Это происходило потому, что мне казалось, что так будет быстрее и ошибки не повторятся. Но что выходило на самом деле? Правильно, сталкиваясь с задачей, которую за него переделывал кто-то другой, мой коллега совершал те же ошибки ровно в тех же местах. И только после череды неудач и колоссальной усталости от постоянных перегрузок чужими задачами до меня наконец дошло.

Возможно, мой коллега просто не знает каких-то вещей, и на самом деле помочь ему может банальное обучение.

И здесь снова нужно взвесить: или наставник тратит время и силы на то, чтобы исправлять ошибки за тем, кто их совершает, или же единожды собирает маленькую библиотечку курсов, тренингов и вебинаров по необходимым навыкам.. Желательно эту библиотечку не прятать, а положить в свободном доступе неподалеку от документации по проекту. 

Помимо помощи в обучении, нужно найти в себе силу давать корректирующую или развивающую обратную связь. Если не говорить коллеге, что в его работе можно что-то улучшить, он вряд ли сам об этом догадается.

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

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

1. Давайте обратную связь в конфиденциальной обстановке.
   Это продемонстрирует уважение и не создаст неоднозначной ситуации с коллективом.

2. Соблюдайте схему +/-/+(она же «Модель бутерброда»): сначала обозначьте положительные моменты работы сотрудника, потом проговорите проблемы, а затем поддержите коллегу и выскажите уверенность в том, что он справится с исправлением ошибок.

3. Высказывайтесь о проблеме, а не о личных качествах сотрудника. При таком подходе новичок сосредоточится на решении проблемы, а не на самозащите.

4. Не пытайтесь искать виноватого и причины допущенной ошибки, сразу концентрируйтесь на поиске решения проблем. Так коллега будет чувствовать, что наставник заинтересован в том, чтобы ему помочь, и не будет замыкаться в себе.

5. Всегда конкретно говорите о проблеме и ее последствиях. Стоит избегать размытых и неизмеримых формулировок вроде «снижение производительности», «снижение качества продукта», а говорить конкретно: «Из-за этого дефекта пользователи на проме не могут использовать новую функциональность». Так у аналитика не будет возможности воспринимать обратную связь как способ просто «докопаться».

Если соблюдать эти шаги, обратная связь получится конструктивной, а главное — полезной. В таком ключе сотрудник быстрее поймет причины и последствия своих ошибок и сможет их не повторять. Впрочем, стоит заметить, что моделей обратной связи существует множество, и под каждого сотрудника лучше всего подойдет своя, но я привожу в пример то, что сработало с моими подопечными.

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

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

Тут нужно понимать, готовы ли вы тратить ресурсы на взаимодействие с таким коллегой и будет ли в итоге его участие в проекте полезным и продуктивным. 

Если да — здесь работают все те же принципы +/-/+. Согласитесь с коллегой в том, что его идея была бы очень полезной в других обстоятельствах, но постарайтесь аргументировать, почему именно сейчас она не подходит и ее нужно отложить «в стол», а затем предложите реализовать его решение позже, подготовив для этого все необходимые условия.

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

Часть 4. «И если станет одиноко, ты вспомни, что эти ребята всегда помогут тебе. И я тоже»

Какая проблема с коллективном может «тормозить» новичка и чем способен помочь наставник

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

Что еще может тормозить работу новичка? На мой взгляд, это попытка занять свое место в команде. 

Многим наверняка знакома ситуация, когда в новом коллективе первое время сидишь молчаливым истуканом и только наблюдаешь за коллегами. Изучаешь, с кем можно пошутить, к кому лучше не подходить до первой чашки кофе, кто радушно поможет с задачей, а у кого можно стрельнуть печенюшку к чаю.

Почему это важно? Внушительная часть ресурса эмоционального и интеллектуального расходуется именно на то, чтобы найти для себя комфортное место.

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

Если наставник помогает новому коллеге адаптироваться в коллективе, знакомит с командой, рассказывает, к кому и с каким вопросом можно обратиться, он, во-первых, существенно облегчит ему жизнь, а во-вторых, быстрее получит сотрудника, который сконцентрирован на выполнении задач, а не на волнениях о том, как эти задачи будут оценивать другие.

Помимо прочего, новые сотрудники зачастую страдают перфекционизмом. И он, в свою очередь, влияет на следующие качества: 

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

2. Скорость — «нет предела совершенству», человек «держит» задачу дольше необходимого, все время пытаясь ее переделать и улучшить. В этом зачастую нет необходимости, ведь в разработку почти всегда можно отдавать и верхнеуровневые требования, а детализацию дорабатывать в процессе. 

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

Можно пригласить новичка прерваться на кофе, сходить с ним на обед, предложить командный поход в кафе в честь пополнения. 

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

Часть 5. «Нет. Вглядись, дружок. Видишь? Он живет в тебе»

Какие бенефиты даст в дальнейшем обучение новичка

Мы много говорили о том, чем наставник способен помочь начинающему аналитику и совсем косвенно коснулись того, что тот даст своему учителю.

Есть очевидные профиты: 

• разделение обязанностей;

• делегирование;

• развитие проекта;

• обоюдная верификация.

Когда аналитиков на проекте от двух и более, это чаще всего идет на пользу системе, над которой они работают. Как говорится, одна голова хорошо, а две лучше. Можно поделить пополам фасилитацию встреч, передать новичку рутинные дела, например, по грумингу задач в бэклоге или удалению неактуальных страниц в конфлюенсе. 

При таком разделении у сотрудника высвободится больше ресурса на анализ и разработку решений для своих систем. Последние можно проверить с помощью второго аналитика, ведь в коллективе регулярно рождаются идеи, и когда решения принимают несколько участников, есть поддержка или, наоборот, сдерживающая сила. 

Ну а верификация — дело хорошее. Полезно, когда кто-то свежим взглядом вычитывает документ, над которым человек работал несколько дней и, возможно, не замечал каких-то неточностей. 

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

Что касается безопасности, если сотрудник допустил ошибку из позиции равного коллеги, то никакой указующий перст не уткнется ему в грудь. Все на добровольных началах, а значит, вы можете вынести урок без серьезных взысканий за упущенные неточности. 

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

Когда занимаешься адаптацией и/или обучением нового сотрудника, так или иначе повторяешь все то, что мог забыть, а иногда даже узнаешь новое. Если ищешь для джуна какие-то курсы, можешь понять, что привычный способ выполнения задачи уже не актуален — есть другой, более быстрый. Согласитесь, всегда приятно, когда что-то получается упростить и ускорить в ежедневной рутине?

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

Итоги

Итак, надеюсь, мне удалось донести главную мысль: адаптация нового сотрудника — это своего рода инвестиция времени. Наставник вкладывает собственные ресурсы в новичка, чтобы получить отдачу в виде разделения обязанностей, обоюдной верификации и свободного времени на новые идеи и решения. 

Повторю ключевые советы:

1. Процесс адаптации — то, что можно систематизировать и контролировать, если заранее спланировать процесс.

2. Если рассказать новому сотруднику о проекте как потенциальному пользователю, можно упростить и ускорить выполнение задач, потому что у новичка разовьется целостное понимание того, над чем вы работаете.

3. Ошибки случаются, но если собрать и положить поблизости методичку по ключевым навыкам, необходимым в проекте, это позволит джуну извлекать из ошибок уроки и развиваться.

4. Если помочь коллеге адаптироваться в коллективе, он будет тратить меньше ресурсов на поиск своего места в команде и повысит качество и скорость выполнения задач.

5. При участии в адаптации нового сотрудника в дальнейшем наставник получает следующие плюсы:

   a) надежного соратника,

   b) бесценный опыт,

   c) саморазвитие,

   d) больше времени на свои задачи.