Как мы легко погрузили эффективную QA-команду в короткий срок и сэкономили заказчику кучу денег и нервов
Всем привет! На связи Екатерина Савинкина из «Лаборатории качества». Сегодня хочу поделиться с вами нашим опытом в решении одной из больных тем любой отрасли – как быстро и эффективно погрузить в проект новых сотрудников и не сойти с ума. Все знают важность управления рисками и наличия под рукой материалов для погружения новичков. Как не словить тревожность, если вдруг проектная команда кардинально поменяется завтра? Как быстро ввести в курс дела новых сотрудников, не сорвав сроки по проекту, и сохранить качество продукта?
Мы однажды столкнулись с такой ситуацией: сначала заменили на проекте своего тестировщика, а потом поменялась и вся остальная команда: РП, все аналитики и разработчики. А еще в итоге тестирование мы отдали вообще другой команде. Но каждый раз ввод новых сотрудников проходил легко и быстро. Но пришли мы к этому не сразу.
В чем суть, брат?
Был у нас клиент А, стартап. Мы работали вместе с привлеченной командой разработки над тестированием некоторых фич перед релизом. Здесь сразу хочется отметить несколько особенностей:
- сотрудники не особо понимали значимость тестирования и связанных с ним процессов;
очень часто разработчики сами что-то исправляли, сразу заливали это на прод без предварительного согласования тестировщиками. Как итог – взбодрившаяся команда, сбои, недовольное руководство. Забегая вперед, отмечу, что после долгих аргументов, отныне все исправления мы предварительно тестили на тестовом стенде, и ни один разраб мимо нас ничего не заливал на прод, как бы он ни был уверен в отсутствии ошибок в коде. Команда разработки зажила спокойнее, про экстренные устранения сбоев забыли;
- заказчик работал только с одним тестировщиком. Часто предложения иметь запасных игроков на случай какого-либо ЧП на проекте или просто подмоги не обсуждались.
Вернемся к нашей истории. За время работы над проектом менялись наши люди, в команде заказчика тоже были перестановки среди разработчиков и аналитиков. И вот однажды (где-то в марте 22) единственного QA-инженера по определенным причинам пришлось отключить от проекта. У нас была всего неделя на подготовку нового сотрудника. И тут возник ряд проблем:
- тестовой документации практически нет. Вся экспертиза в голове у единственного тестера;
- всяческие доработки заказчиком чаще всего проводились в устной форме без дополнительной фиксации;
- если бы мы описывали все процессы тест-кейсами, то на это надо было бы закладывать 2-4 недели работы фултайм одного сотрудника (как мы помним, второго QA у нас не было). Это повлекло бы остановку процесса тестирования на месяц, огромные финансовые потери заказчика, недовольных клиентов;
- на погружение каждого новичка уходило много времени, и все дружно тратили его на разъяснения, что и как в системе работает, отвлекаясь от своей основной работы.
Как мы это решили
Проанализировав ситуацию, мы поняли, что единственным правильным и быстрым решением в тот момент было сделать несколько вещей:
- составить карту сайта (продукта заказчика). Тут объясняли, где, что и как располагается и должно функционировать;
- по карте подготовить план погружения. Мы перечислили все модули системы. Уже по этому плану тестировщики созванивались, уходящий проводил демонстрацию работы системы, приходящий задавал уточняющие вопросы;
- записать обучающие видео. Они позволили зафиксировать всю экспертизу по продукту. Роликов было несколько на каждую важную тему. Теперь новички могли найти ответы на свои вопросы быстро, наглядно и без отвлечения коллег от работы.
Итог - процесс отлажен, новые люди погружаются быстро, самостоятельно, а качество продукта при этом не падает ни капли. Мы довольны, заказчик тоже, деньги и нервы целы.
Но через пару месяцев мы столкнулись с еще одной проблемой: компания заказчика переехала из РФ, и при этом практически вся команда сменилась. Мы снова всех заново погружали. Но нам уже было не страшно, мы были готовы хоть каждый месяц этим заниматься.
Потом команда разработки заказчика приняла решение взять тестера в штат. Мы им в этом тоже помогли. Всё получилось не с первого раза: не каждый кандидат справлялся со сложными задачами проекта, поиск стоящего человека занял около полугода. В итоге мы подготовили достойную замену нашему QA-инженеру, актуализировали материалы для погружения будущих сотрудников и на этом отпустили клиента в самостоятельное плаванье.
Заключение
Ребята, настоятельно рекомендуем проанализировать нашу ситуацию и принять рекомендации. Смотрите сами:
- легкие в подготовке инструменты помогли сэкономить полезное время и кучу денег нашему заказчику;
- мы оптимизировали процесс погружения новых сотрудников, сделали его легче, в первую очередь, для себя;
- нам настолько понравилось погружать новых людей, что мы готовы делать это хоть каждый месяц. Вам тоже понравится;
- не забывайте сообщать клиенту о важности тестирования. Разработчики могут сами искать и исправлять ошибки, но никто лучше тестера это не сделает;
- помните про управление рисками! Иметь в команде несколько человек одной должности – это плюс вам. Кто-то заболеет, кто-то будет в отпуске, у вас всегда будет тот, кто сможет их заменить.
Если у вас были похожие проблемы, поделитесь интересными кейсами в комментах.
А еще!
Всего безошибочного, ваша Екатерина.