Привет! Меня зовут Галина, я руковожу отделом QA в питерском филиале IT-компании SimbirSoft. Во время общения с клиентами периодически сталкиваюсь с мифами и страхами, которые преследуют заказчиков при старте работы с аутсорс-командой. В этой статье хочу на примере QA-направления развеять популярные мифы об аутсорсинге. Материал может быть интересен как бизнесу, который пока размышляет о привлечении внешних команд, так и IT-компаниям, поскольку внутри мы делимся своими лайфхаками по организации работы.
Миф 1. Погружение внешних специалистов ресурсозатратно
Каждый проект требует особого внимания к принимаемым управленческим и технологическим решениям, выбору стратегии разработки, тестирования и техподдержки. Поэтому у заказчиков присутствует закономерный страх, что внешние специалисты, не включенные в проект, как минимум – будут выполнять работу по шаблонному сценарию без учета нюансов, а как максимум – своими действиями могут принести вред. На самом деле, опытный аутсорсер такого не допустит.
Что делать?
Погружение специалистов в проект – сложный процесс. Его длительность зависит от двух факторов:
– Насколько хорошо выстроен этот процесс внутри проекта.
– Какие задачи заказчик планирует ставить специалистам в первые месяцы работы.
Организовать ведение документации – одна из задач QA на проекте. Это нужно, чтобы расширение команды происходило с минимальными временными затратами, а передача дел, в случае отпуска или замены специалиста, была выстроенным процессом.
BUS FACTOR – это риск, который актуален и для инхаус, и для аутсорс-команды. Его можно и нужно предотвращать, закладывая время на дополнительные, но важные активности:
→ Проводите демо по новому функционалу приложения для всей команды. Каждый специалист должен знать обо всех обновлениях.
→ Записывайте видеодемки, как работает та или иная фича. Такой формат всегда будет доступен команде и поможет избежать зависимости от специалиста.
→ Устройте перекрестное ревью документации. Так вы не только повысите качество написанных тест-кейсов, но и погрузите QA во все области разработки.
→ Общая база знаний – держите ее всегда в актуальном состоянии, добавьте в воркфлоу этап, когда ответственный специалист должен зайти и обновить всю необходимую информацию о проекте.
Хорошая практика – чек-листы. Они помогают новым членам команды самостоятельно изучить всю необходимую информацию про проекту и за короткий период подготовиться к выполнению задач. В своей практике мы используем следующие документы:
- Карта погружения на проект. Помогает специалисту контролировать свои знания. В карту всегда оперативно добавляется новая терминология или бизнес-логика, с которой встречаются сотрудники при подключении на проект. Для удобства мы помечаем эти моменты разными цветами, чтобы понять степень владения терминологией. В идеале – через некоторое время новых терминов должно становиться все меньше, а карта окрашена в цвет, обозначающий полное погружение.
- Чек-лист «Старт проекта». Позволяет специалисту быстро ориентироваться в процессах, инструментах, окружении и всегда иметь под рукой нужные контакты. В нем прописаны все нюансы: например, ключевые митинги на проекте, перечень различной документации, особенности воркфлоу, задач или багов.
- Документ с вопросами и ответами. Очень часто на старте у любого QA возникает много вопросов к разработке и аналитике. Если на проект заходит большая команда, они могут повторяться. Собирать вопросы в единый документ, фиксировать там ответы на них, а также проводить регулярные разъясняющие встречи – отличный способ не только облегчить погружение специалиста на проект и дать ему почувствовать себя уверенно, но и сэкономить время команды на повторяющихся вопросах.
Аутсорс-команда погружена в проект, если:
→ Интересуется не только ТЗ, но и FAQ, юзер-гайдами и другой доступной документацией, задает вопросы, разбирает нюансы, озвучивает риски.
→ Запрашивает и уточняет нефункциональные требования (к производительности, кроссбраузерности, юзабилити и т.д.).
→ Позитивно относится к митингам с владельцем продукта и аналитиками, а полученные знания применяются при разработке ПО, тест-кейсов, предупреждая возможные технические риски.
→ Для изучения проекта использует также тикеты саппорта, комментарии разработчиков и заказчика во время демонстрации.
→ Интересуется, как пользователи воспринимают новые фичи в работе, и старается делать свои тесты, приближенными к реальным действиям, чтобы создать востребованный продукт.
→ Постоянно обновляет и улучшает документацию, следит за ее актуальностью, вносит изменения
Вывод: Процесс погружения специалиста – очень важный этап. От заказчика требуется предоставление полной информации о проекте и контроль за полнотой погружения, а от специалиста – быстрое обучение, внимательность и желание как можно скорее начать работать с максимальной отдачей. В быстром и успешном онбординге заинтересованы все. Правильная организация процесса и включенность с обеих сторон значительно снижает риски и затраты на реализацию проекта или привлечение дополнительных ресурсов.
Миф 2. Внешняя команда не разделяет ценности заказчика
Есть распространенное мнение, что привлеченные специалисты смотрят на проект формально – как на ряд задач, который нужно выполнить за определенный срок. Очевидно, что такой подход может негативно сказаться на многих аспектах продукта. Например, QA будет тестировать приложение строго по ТЗ и совсем не будет интересоваться потребностями реальных пользователей. В итоге на рынок может выйти продукт, соответствующий ТЗ, но бесполезный или слишком сложный для конечных потребителей.
Что делать?
Чтобы аутсорс-команда погружалась в бизнес эффективнее, хорошее решение – доносить до внешних специалистов ценностей компании с первых встреч. Быть глубоко вовлеченным в проект – прямая обязанность членов аутсорс-команды. Это позволяет вовремя отмечать и предотвращать риски, налаживать коммуникацию и постоянно улучшать качество разработки.
Еще один совет — предлагая очередную фичу на разработку или тестирование, рассказывайте, как бизнес будет презентовать и использовать эту функцию и как конечные пользователи будут с ней взаимодействовать. Это помогает специалисту не только глубже погружаться в ценности компании-клиента, но и открыто рассказывать о рисках, которые нужно обязательно учесть.
Приведу пример таблицы, которая помогает проанализировать ценности фичи и риски ее внедрения. Проект: онлайн-платформа для врачебных видеоконсультаций. Первоначально этот продукт разрабатывался для вендоров и пользователей.
Вывод: Чтобы команда чувствовала себя «как дома», не надо бояться делиться информацией о проекте. Любой IT-эксперт рад быть частью команды, которая приносит пользу, и всегда открыт для новой информации. QA используют дополнительные сведения о проекте для улучшения своей работы и повышения качества разрабатываемого проекта.
Миф 3. Аутсорс-команда может не развиваться так, как нужно проекту
При подборе специалистов заказчик ждет, что по мере развития проекта команда будет готова обучаться новым технологиям. Часто встречаются опасения, что внешние специалисты менее гибкие в этом плане в сравнении с сотрудниками компании.
Примеры медленного обучения фреймворку или буксировки тестирования из-за отсутствия у специалистов навыков автоматизации встречаются, но этот риск можно закрыть еще на старте проекта.
Что делать?
IT-технологии очень динамичны. Новые обновления, фреймворки, библиотеки появляются каждый день. Но гораздо эффективнее, если аутсорсер сможет предложить оптимальное решение и подобрать готовую команду с нужными компетенциями. Для этого ему потребуется полная информация о будущем ИТ-продукте. Не стоит забывать, что и аутсорс-эксперты могут предложить свой опыт решения технических задач, будь то поиск оптимального решения для нагрузочного тестирования или инструмент для хранения тест-кейсов.
Еще важный момент: заказчик прогнозирует развитие своего бизнеса, своего проекта/продукта. И на первых этапах (на момент создания MVP) нужны специалисты с одним набором компетенций, а по мере «взросления» проекта список требований может быть серьезнее. Например, принимается решение о внедрении автоматизации или использовании сложных инструментов, в которых не было необходимости на старте. Если подбирать команду сразу под будущие требования к специалистам, на первых этапах вы можете столкнуться с таким понятием, как оверквалификация сотрудников, что зачастую приводит к снижению мотивации. Когда для такого специалиста нет задач по его уровню, высок риск, что он покинет команду.
Аутсорсинг решает эту проблему. По мере необходимости вы можете в короткие сроки усиливать команду сотрудниками с набором компетенций, необходимым именно для текущего этапа развития проекта, а также подключать на определенные краткосрочные задачи или переформировывать команду для долгосрочных. Таким образом, на старте вы избежите лишних затрат и предотвратите нежелательную текучесть кадров.
Безусловно, постоянное обучение – залог того, что аутсорсер будет конкурентоспособным на рынке. Мы это прекрасно понимаем. Наши процессы построены так, что одним из важнейших скиллов у ребят является способность к быстрому и постоянному обучению, чтобы постоянно «быть в теме». Отличный инструмент для контроля развития специалиста, который мы используем, – индивидуальный план развития (ИПР).
Он всегда содержит технологический стек проекта, при этом его выполнение рассчитано на краткосрочную перспективу. Поэтому если у вас есть технологии и инструменты, которые хотели бы развивать, поделитесь с командой, расскажите им о преимуществах. С большой долей вероятности вы найдете поддержку, независимо от того, находится ли специалист в штате или на аутсорсе.
На одном из проектов в какой-то момент потребовалось внедрить автоматизированное тестирование UI. Наш специалист принял решение подтянуть навыки во фреймворке Selenide с помощью внутренних курсов компании, а затем сделать пробную автоматизацию с подробной презентацией для заказчика. На основе проделанной работы команда приняла решение развивать автоматизацию с помощью выбранной технологии. Для достижения этой цели был составлен ИПР:
Вывод: При подборе команды сразу наметьте планы развития проекта и команды на ближайшую перспективу. Специалисты, которые постоянно совершествуют свои профессиональные навыки, помогают внедрять новые технологии и улучшать продукт. Безусловно, на оттачивание скиллов потребуется время. Но часто выходит так, что если новые знания имеют моментальное практическое применение, скорость обучения увеличивается в разы.
Надеемся, что наши рекомендации помогли вам побороть сомнения в отношении к аутсорсингу. О других страхах ранее рассказывали здесь, а тут – почему инхаус-специалисты не всегда выгоднее привлеченной команды.
И еще раз повторю мнение коллег: во всём необходим грамотный переход. Например, можно начать с формирования гибридного состава: «core»-команда инхаус-специалистов с надёжным аутсорсным «усилением». О том, как выстроить эту работу эффективно, беседовали здесь.
Познакомиться с нашими проектами поближе можно на сайте.