Pull to refresh
356.23
ГК ЛАНИТ
Ведущая многопрофильная группа ИТ-компаний в РФ

Как мы импортозаместили аутсорсинг тестирования. Пошаговая инструкция

Reading time 9 min
Views 7K
Когда в 2014 году курс доллара взлетел, а страна взяла курс на импортозамещение, мне пришлось заниматься заменой старой команды внешних тестировщиков, оплачиваемой в долларах, на новую, оплачиваемую в рублях. В этой статье я подробно расскажу, как мы организовали этот процесс перехода, с какими сложностями столкнулись, как их решали и какой экономический эффект получили. 


Как появилась потребность в аутсорсинге тестирования


Я работаю в ЛАНИТ уже 13 лет. В первое время объемы по тестированию в моем департаменте были небольшие, и я могла совмещать тестирование 2-3 маленьких проектов. Затем появились новые заказчики и проекты большего масштаба, и я начала разрываться.

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

Но в 2014 году случился кризис, курс доллара взлетел за очень короткое время с 32 до 50 рублей, затем до 70, а в пик достиг примерно 90 рублей. Такой рост доллара напрямую повлиял на стоимость аутсорсинговых сотрудников.

Ищем «рублевых» тестировщиков


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

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

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

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

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

Растим кадры


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

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

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

Формируем набор метрик


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

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

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

Показатели по команде измерялись ежемесячно по багтрекеру Jira. Основными были:

  • количество зарегистрированных дефектов, 
  • сколько среди них закрыто в резолюцией not a bug, 
  • какие приоритеты заведенных дефектов, 
  • сколько среди них дублей, 
  • обратная связь от аналитиков через опросник, где они оценивали по разным критериям работу каждого тестировщика, 
  • аналогичная обратная связь от разработки,
  • % пропущенных дефектов на production-среде за месяц/релиз, 
  • число протестированных задач, 
  • среднее время на регистрацию дефекта, 
  • среднее время на валидацию дефекта, 
  • среднее время на обработку инцидента от сопровождения, 
  • % неисправленных в релизе ошибок, 
  • коэффициент регрессии и много других.

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

Вот так выглядел регулярный сбор метрик на одном из наших проектов. 

Метрики в разрезе проекта

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

Метрики в разрезе команды

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

Погружаем новых людей


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

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

Было решено составить матрицу знаний на проекте. Для этого выписаны все проектные подсистемы/модули/функции, и каждый в группе тестирования старой команды должен был поставить самооценку по пятибалльной шкале, насколько он погружен в подсистему/модуль/функцию. Подробнее о матрице знаний в моей статье «Чему нас научило тестирование государственной информационной системы», там же можно найти шаблон матрицы знаний и использовать его в  работе.

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

Переданная база знаний проекта выглядела примерно вот так:


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

Целью скайп-совещаний было пояснение бизнес-процесса подсистемы/модуля, выделение  основных бизнес-функций с точки зрения аналитика, комментарии, на что обращать внимание при тестировании, что важно для заказчика + параллельное обсуждение новых доработок. 

Что дало проведение скайп-совещаний: 

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

По завершению первого этапа внедрения новых людей были выполнены ключевые задачи:

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

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

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

Затем новых тестировщиков оценивал ведущий аналитик с помощью 30-минутного интервью, на котором задавались вопросы о его подсистеме. Часто ведущему аналитику и не требовалось проводить интервью, если в процессе работы он много взаимодействовал с новым тестировщиком и мог без интервью оценить степень погруженности в функционал.

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

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

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

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

Пример сбора обратной связи с аналитиков по работе тестировщиков:


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


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

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

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

Экономический эффект


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

На старте импортозамещения, количество долларовых тестировщиков составляло примерно 60 человек. В процессе импортозамещения команда увеличилась примерно в 1,5 раза в пике и далее вернулась к количеству в 50 человек. Численность команды даже немного сократилась за счет оптимизации работы тестирования и повышения компетенции, которая в итоге стала полностью на стороне ЛАНИТ. 

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

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

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

Сейчас вектор развития направления тестирования в департаменте сосредоточен на расширении своих центров компетенции. Привлечение аутсорсинговых команд уходит на второй план. Мы привлекаем их для быстрого масштабирования по мере роста потребностей проекта. Однако принципы работы с большими распределенными командами в нашем департаменте остаются неизменными, детально про процесс тестирования с участием больших команд для ГИС-проектов, описан в моей статье. Накопленный опыт позволяет в короткие сроки внедрять в проект большие команды, обучать, наращивать компетенции, быстро набирать обороты по скорости тестирования при ротации команд и/или сотрудников внутри департамента без потери в качестве выпускаемого продукта.
Tags:
Hubs:
+71
Comments 35
Comments Comments 35

Articles

Information

Website
lanit.ru
Registered
Founded
Employees
over 10,000 employees
Location
Россия
Representative
katjevl