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

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

Чтобы разобрать данную ситуацию я хочу поделиться своим личным опытом. Лет 6-7 назад в уже всеми забытом Лето-банке (ныне ПочтаБанк) я пришел на позицию менеджера по тестированию. На момент моего прихода в команде было пару тестировщиков, которые фактически работали с момента активного развития банка и были, можно сказать, гуру в тестировании систем банка. Но через месяц после моего появления, главный эксперт по тестированию принял решение уволится, а за ним еще пару человек. Фактически со мной в команде оставалось пару новеньких ребят, которые только погружались в банковскую специфику тестирования и не могли никак сравниться с опытными ребятами.

К сожалению специфика любой работы подразумевает наращивание экспертизы, особенно в ИТ сфере. И этот рост дает не столько профессиональное развитие, как специалиста, а опыт именно работы в конкретном месте, с определенной спецификой. Тебя, как специалиста, все занют, тебе доверяют, к тебе прислушиваются. О таких ребятах я очень часто слышу: "Обязательно поговори с Иваном, он у нас самый главный эксперт по тестирования АБС." или "Только Иван может тебе сходу сказать, сколько времени займет тестирование этой фичи". Если у Вас в компании проскальзывают подобные фразы, то самый повод задуматься о небольшой перезагрузке и минимизировать риски ухода таких специалистов.

Так что же делать в подобных ситуациях?

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

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

1. Вики наше все.

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

2. Правильно распределять компетенции внутри команды.

К сожалению часто возникают ситуации, когда экспертиза сотрудников замыкается на конкретных областях работы. Сотрудники начинают показывать там высокую эффективность, что в итоге приводит к тому, что "Ну тестирование процесса оформления - это к Васе". Но так быть не должно. Во-первых, нужно регулярно ротировать сотрудников внутри команды и не концентрировать экспертизу в руках одного человека. Как минимум это упростит задачу передачи активностей на период отпусков, когда не нужно будет держать сотрудников годами без отпуска (а некоторые это делают специально, чтобы при увольнении им выплатили все отпускные), а во-вторых, в случае увольнения, менеджеру не придется судорожно бегать и искать того самого, что заберет разом все знания у уходящего специалиста. Более того, как показала моя практика, регулярная ротация сотрудников между задачами очень положительно влияет на их мотивацию, потому что это дает большую возможность для роста и развития вашего сотрудника внутри компании, потому что каждому из нас нужны перемены и смена обстановки, чтобы не выгореть. А ротация - это лучший способ сохранять мотивацию сотрудника в течении длительного промежутка времени.

3. Если базу знаний не вели.

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

4. Когда ничего из пунктов выше не случилось.

Тут начинается самое интересное. Именно с этой ситуацией я столкнулся на своем проекте. Вы приходите на проект, а вся команда экспертов уходит. Успеть кому-то передать знания - это конечно хорошо, но вряд ли молодые ребята, которые еще не имеют глубокое представление о специфики тестирования систем, смогут быстро вникнуть и забрать на себя задачи. Тут необходимо включать навыки коммуникатора и идти с повинной к своему руководителю, менеджерам других отделах и договариваться о дальнейшей работе. В моей ситуации я поступил следующим образом. Я прямо сообщил своему руководителю, что в течении месяца в производительности QA команды будет небольшая просадка, сообщив при этом причины данной ситуации, а также какие пути я вижу для максимально быстрого решения (каждый выход из подобной ситуации уникален, но глобально, нужно правильно распределить экспертизу, найти варианты наращивания экспертизы для команды и определить, когда команда сможет вернуться на свой обычный уровень производительности). Я организовал встречи с командой аналитики и разработки, с целью, во-первых проинформировать их об изменениях, а во-вторых заручиться их поддержкой в части помощи в технических вопросах. Каждому сотруднику, особенно эксперту, не очень нравится, когда к нему постоянно приходят с вопросами и отвлекают от работы над проектом. В этом и была моя задача, а именно, получить от них поддержку в течении определенного промежутка времени, тогда это был 1 месяц, в течении которого, к примеру, аналитик, будет готов отвечать на все вопросы от команды тестирования, даже если они будут глупыми и неосмысленными. Очень важно проговорить подобные моменты с другими подразделениями ИТ, так как это позволит вам значительно ускорить как скорость реакции данных специалистов на поступающие вопросы, так и скорость обучения новой команды тестировщиков. Принципиально важно озвучить сроки данного периода "щедрости", так как никто не готов быть ходячей википедией все время. За это время нам удалось не только сильно прокачать команду молодых QA инженеров специфики бизнеса и процессов, но и выйти на прежний уровень производительности команды в целом, не обманув при этом ожидания моих руководителей и бизнеса в целом.

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