Как мы импортозаместили аутсорсинг тестирования. Пошаговая инструкция
Когда в 2014 году курс доллара взлетел, а страна взяла курс на импортозамещение, мне пришлось заниматься заменой старой команды внешних тестировщиков, оплачиваемой в долларах, на новую, оплачиваемую в рублях. В этой статье я подробно расскажу, как мы организовали этот процесс перехода, с какими сложностями столкнулись, как их решали и какой экономический эффект получили.
Как появилась потребность в аутсорсинге тестирования
Я работаю в ЛАНИТ уже 13 лет. В первое время объемы по тестированию в моем департаменте были небольшие, и я могла совмещать тестирование 2–3 маленьких проектов. Затем появились новые заказчики и проекты большего масштаба, и я начала разрываться.
Как раз в этот момент на нас вышла компания, предлагающая аутсорсинг тестирования. Ее основной специализацией было именно тестирование, сотрудники стоили относительно недорого по сравнению с опытными тестировщиками из Москвы, но несмотря на это, взаиморасчеты нужно было осуществлять в долларах. Мы стали работать вместе и вместе росли по мере усложнения задач на проектах, делились опытом, и я очень многому научилась у своих партнеров.
Но в 2014 году случился кризис, курс доллара взлетел за очень короткое время с 25 до 50 рублей, затем до 70, а в пик достиг примерно 90 рублей. Такой рост доллара напрямую повлиял на стоимость аутсорсинговых сотрудников.
Ищем «рублевых» тестировщиков
Одновременно в тот же период руководство страны дало курс на импортозамещение зарубежного ПО. Импортозамещение потребовалось и в тестировании, так как привлекаемые на аутсорс команды были не российскими, а взаиморасчеты в долларах быстро вычерпывали весь бюджет тестирования.
Из-за увеличения количества проектов в департаменте, встал вопрос о расширении команд тестирования. Потребности департамента в специалистах по тестированию уже не мог обеспечивать в полном объеме наш долларовый подрядчик и мы вынуждены были искать варианты сотрудничества с другими компаниями. Ситуация с ростом курса доллара еще быстрее подтолкнула нас к поискам партнеров на российском рынке.
Вместе с импортозамещением пришли и новые сложные задачи. Требовалось найти на российском рынке компании, предоставляющие услуги аутсорсинга тестирования с высоким качеством работ и возможностями быстро масштабироваться, так как потребности в тестировании в нашем департаменте постоянно росли, пакет проектов расширялся и необходимо было как можно скорее найти «рублевых» тестировщиков, которые удовлетворяли бы нашим запросам.
Мы стали исследовать рынок, опрашивали коллег, в том числе, работающих в других компаниях, запрашивали рекомендации, проводили огромное количество встреч с разными компаниями. В итоге были найдены те, кто соответствовал нашим запросам по компетенциям и с кем мы готовы были работать на российском рынке. Самое главное — они были готовы продавать нам не просто тестировщиков, а комплекс услуг.
Затем были выполнены предварительные расчеты затрат, сроков по импортозамещению, составлен план работ. После утверждения плана по импортозамещению со стороны директора департамента и руководителя проекта началась работа с российскими командами, их руководством, обсуждение условий сотрудничества и моих требований к команде и качеству работ.
Растим кадры
Услугой, которая была для нас очень важна, являлась возможность в короткие сроки вырастить тестировщиков из стажеров. Конечно, эти услуги предоставляли и старые долларовые партнеры и вопроса к качеству услуг у нас не было, вопрос был в их стоимости и нашей потребности снизить затраты. Наши новые партнеры имели стажерские программы, компетентных коучей, психолога, грамотного HR-специалиста и быстро находили, учили и внедряли незаметно в проект людей.
Когда эти люди завершали внутреннюю стажировку, их показывали мне на собеседование. Если погруженность в проект, знания теории тестирования и выполнение практических заданий по проекту были на «отлично», мы брали их в свою проектную команду.
И вот команда собрана, а я убедилась, что новый подрядчик надежен, самостоятельно закрывает многие активности по работе с персоналом (обучение, внедрение в проект (по договоренности это был минимум двухнедельный тренинг за счет подрядчика), мотивацию, помощь в решении проблем, программы профессионального развития, гарантирует договорными отношениями стабильность ставок в рублях в долгосрочной перспективе, а также демонстрирует лояльность заказчику. Теперь осталось решить самую сложную задачу — заместить более дорогих специалистов на более дешевых без потери качества.
Формируем набор метрик
Итак, цель была ясна — заменить команду, сохранить качество, существующий процесс, хорошие отношения с прошлым подрядчиком, с которым мы проработали на тот момент около пяти лет. Реалии бизнеса таковы, что требовались перемены, уступки, гибкость с обеих сторон ради долгосрочного сотрудничества. Пока руководство департамента и наши давние партнеры пытались искать варианты, как продолжить сотрудничество в новых экономических условиях, передо мной встал вопрос, чем мы будем мерить качество, чтобы понять, стало лучше/хуже или все стабильно.
Параллельно с процессом импортозамещения рос и совершенствовался производственный процесс в департаменте на крупных проектах. Поэтому вопрос о контроле за качеством на регулярной основе был для нас особенно актуален в этот период.
Для начала надо было понять «общую температуру» по проекту, что мы имеем на протяжении определенного периода и что мы можем измерять. Были сняты метрики за последние полгода, так как это довольно длительный период, за который не происходило каких-то глобальных изменений в составе рабочих команд аналитики, разработки и тестирования. Такие метрики были максимально релевантны. Мы смогли измерить показатели в работе текущей команды, а также показатели в разрезе проекта.
Показатели по команде измерялись ежемесячно по багтрекеру Jira. Основными были:
- количество зарегистрированных дефектов,
- сколько среди них закрыто в резолюцией not a bug,
- какие приоритеты заведенных дефектов,
- сколько среди них дублей,
- обратная связь от аналитиков через опросник, где они оценивали по разным критериям работу каждого тестировщика,
- аналогичная обратная связь от разработки,
- % пропущенных дефектов на production-среде за месяц/релиз,
- число протестированных задач,
- среднее время на регистрацию дефекта,
- среднее время на валидацию дефекта,
- среднее время на обработку инцидента от сопровождения,
- % неисправленных в релизе ошибок,
- коэффициент регрессии и много других.
Все данные сводились в таблицы, которые затем анализировались тест-менеджером проекта. Если какие-то метрики отличались от целевых показателей, то принимались меры.
Вот так выглядел регулярный сбор метрик на одном из наших проектов.
Метрики в разрезе проекта
А так выглядел сбор метрик по качеству работы команды тестирования, причем для сравнения были взяты долларовые и рублевые команды подрядчиков.
Метрики в разрезе команды
Мы собрали статистику о качестве работы текущей команды, определили критерии качества и удовлетворенности работой команды со стороны проектных аналитиков, разработчиков и руководителя проекта. Теперь появилось понимание, с какими показателями начали процесс импортозамещения — тот самый набор метрик, с которым можно было бы сравнить результат.
Погружаем новых людей
Далее можно было готовить материалы для погружения в проект новых людей и постепенной передачи компетенций и дел новой команде.
Чтобы процесс проходил плавно и безболезненно, был разработан план график. Ключевой особенностью было то, что основные компетенции по тестированию были сосредоточены у меня, и я являлась не просто распределителем задач по ресурсам тестирования, а тест-менеджером на проектах, где требовалось импортозамещение. То есть понимание стратегии тестирования, тест-планы, критерии старта и завершения теста, приоритеты со стороны бизнеса — все это было в рамках моих знаний и компетенций, и мне оставалось лишь грамотно выстроить план поэтапного замещения людей.
Было решено составить матрицу знаний на проекте. Для этого выписаны все проектные подсистемы/модули/функции, и каждый в группе тестирования старой команды должен был поставить самооценку по пятибалльной шкале, насколько он погружен в подсистему/модуль/функцию. Подробнее о матрице знаний в моей статье «Особенности процесса тестирования ГИС», там же можно найти шаблон матрицы знаний и использовать его в работе.
Затем актуализировали проектную wiki и для этого попросили руководителей групп тестирования в старой команде дополнить или создать методические материалы, инструкции по погружению в подсистемы/модули/функции, которые были нами определены как самые критичные для передачи знаний. Эти методички и инструкции было необходимо передать новой команде в первую очередь.
Переданная база знаний проекта выглядела примерно вот так:
Параллельно этому процессу были запланированы скайп-совещания с ведущими аналитиками по подсистеме/модулю, на которых присутствовали как ответственные по тестированию от старой, так и от новой команды.
Целью скайп-совещаний было пояснение бизнес-процесса подсистемы/модуля, выделение основных бизнес-функций с точки зрения аналитика, комментарии, на что обращать внимание при тестировании, что важно для заказчика + параллельное обсуждение новых доработок.
Что дало проведение скайп-совещаний:
- объединение команд: старая + новая,
- запись скайп-лекции с участием ведущих аналитиков всех подсистем/модулей, которую можно использовать в будущем для погружения новых людей в проект,
- улучшение коммуникаций «аналитик-тестировщик»,
- матрица знаний в объединенной команде старых и новых тестировщиков, по которой можно было ежемесячно отслеживать рост погружения в проект новых людей.
По завершению первого этапа внедрения новых людей были выполнены ключевые задачи:
- собраны методические материалы для погружения в проект,
- проведено знакомство команд и обмен знаниями,
- новые люди изначально «заведены» под более опытных старых участников команды, которым была поставлена задача мониторить качество работ по тестированию новых участников команды,
- составлены матрицы знаний новых/старых участников тестирования, которые по мере погружения в проект актуализировались на регулярной основе ежемесячно.
На втором этапе было необходимо закрепить полученные знания процесса, проекта и были запланированы собеседования, которые также проводились в несколько итераций.
Сначала ответственный за подсистему/модуль из старой команды тестирования собеседовал всех, кто погружался в его подсистему/модуль на предмет знания бизнеса подсистемы, оценивал качество составляемых тест-дизайнов, регрессионных тест-кейсов по новым доработкам, собиралась статистика по пропущенным дефектам после теста (всегда кто-то более погруженный выборочно проверял новые доработки, чтобы избежать пропусков дефектов со стороны новых тестировщиков).
Затем новых тестировщиков оценивал ведущий аналитик с помощью 30-минутного интервью, на котором задавались вопросы о его подсистеме. Часто ведущему аналитику и не требовалось проводить интервью, если в процессе работы он много взаимодействовал с новым тестировщиком и мог без интервью оценить степень погруженности в функционал.
При возникновении необходимости ротации выбывающих участников из старой команды мы не согласовывали ротацию на их дорогостоящих специалистов, а проводили такую ротацию самостоятельно, расширяя команду новыми людьми из России.
Также важной задачей было не обидеть тестировщиков старой команды, а пояснить, что мы стали работать не только с ними, но и расширять команду, привлекая других специалистов, что вопросов к компетенциям людей нет, есть производственная необходимость расширять географию распределенной команды и делать это будем вместе.
Спустя полгода такой ротации объем команды, конечно, сильно увеличился, что и было запланировано. Но как только показатели работы новых тестировщиков стали схожи с показателями старых, а коэффициент удовлетворенности аналитиков и разработчиков проекта стабилизировался, начался обратный процесс — сокращение команды за счет постепенного вывода более дорогих тестировщиков и замена их на российских специалистов.
Параллельно анализировался производственный процесс и снималась обратная связь, выделялись самые критичные проблемы, которые предстояло решать при каждом новом релизе.
Пример сбора обратной связи с аналитиков по работе тестировщиков:
Пример сводного перечня выявленных проблем процесса тестирования, стратегия решения проблем и мониторинг исправления ситуации, с целью не ухудшить качество тестирования на проекте, где выполнялся процесс импортозамещения ресурсов:
Руководству проекта и директору департамента на регулярной основе высылались отчеты с информацией по результатам импортозамещения.
В отчеты вносилась сводная информация с результатами проведенного анализа работы старых и новых тестировщиков, демонстрировался прогресс в передаче знаний и анализ качества работы команд по заранее определенным критериям оценки качества.
Процесс импортозамещения растянулся примерно на год, так как команды были очень большие на старте процесса, а проекты значимые для департамента. Это обусловило определенные сложности в процессе замещения, и могло привести к резкой потери качества, если выполнять импортозамещение быстро.
Экономический эффект
В итоге можно посчитать, какой объем экономии бюджета произошел, после процесса импортозамещения.
На старте импортозамещения, количество долларовых тестировщиков составляло примерно 60 человек. В процессе импортозамещения команда увеличилась примерно в 1,5 раза в пике и далее вернулась к количеству в 50 человек. Численность команды даже немного сократилась за счет оптимизации работы тестирования и повышения компетенции, которая в итоге стала полностью на стороне ЛАНИТ.
Экономическая выгода от проделанной работы составила 35%, но реальные плюсы заключаются в том, что поставленная задача по импортозамещению подстегнула нас к открытию своих собственных ресурсных центров для нужд департамента.
Первоначально центры компетенции были задуманы для решения проблем с недостатком сотрудников по тестированию, в связи с активным развития тестирования в департаменте, однако со временем там появились специалисты разных направлений — сопровождение, DevOps-специалисты, разработка, аналитика.
На текущий момент наш департамент почти полностью перешел на работу с российскими тестировщиками. Важно отметить, что большая часть — это сотрудники департамента, работающие в региональных ресурсных центрах. Мы открыли свои собственные ресурсные центры по тестированию в Челябинске, Ижевске, Перми и большую часть работ по многим проектам полностью закрываем своими командами тестирования. Кстати, у нас открыта вакансия разработчика автоматизированных тестов.
Сейчас вектор развития направления тестирования в департаменте сосредоточен на расширении своих центров компетенции. Привлечение аутсорсинговых команд уходит на второй план. Мы привлекаем их для быстрого масштабирования по мере роста потребностей проекта. Однако принципы работы с большими распределенными командами в нашем департаменте остаются неизменными, детально про процесс тестирования с участием больших команд для ГИС-проектов, описан в моей статье. Накопленный опыт позволяет в короткие сроки внедрять в проект большие команды, обучать, наращивать компетенции, быстро набирать обороты по скорости тестирования при ротации команд и/или сотрудников внутри департамента без потери в качестве выпускаемого продукта.
