Как мы починили QA-процессы и выстроили системную работу

Описанные подходы я применяю в IT-компании, где я и сейчас тружусь менеджером проектов. Одним из направлений моей деятельности является курирование QA-команды (Quality assurance — Обеспечение Качества). К нам приходят разноплановые задачи — от банальных проверок исправленных багов, до создания некой фичи путем конфигурации софта. Здесь же и регрессионное тестирование, и end-to-end (сквозное тестирование).

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

Пару лет назад у нас была проблема. Были QA-специалисты, но они не были закреплены ни за одним проектом, существовали сами по себе, выполняя только лишь проверки исправленных багов, изредка занимаясь документацией. Проекты в компании велись по «водопаду». Поэтому постоянное присутствие тестировщиков или QA не требовалось. Сотрудники могли прыгать с проекта на проект чуть ли не каждый день. Но, что самое печальное, они не видели результатов своей работы, и было непонятно, то ли они делают или не то. Это демотивировало.

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

Как мы проводим ежедневные брифинги

Утренние брифинги мы так или иначе уже проводили. Но мы привнесли в них чуть больше смысла. Что они сейчас из себя представляют? Для нас это базовый ритуал, который требует от каждого из группы или команды собраться вместе, и очень коротко ответить в нужное время на три вопроса: Сделал. Планирую. Мешает.

Это подход позволяет:

• повысить индивидуальную ответственность за результат в команде;
• повысить результативность и ясность результатов команды;
• выстроить процесс с минимальным вмешательством в непосредственную работу.

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

Важно проводить брифинги в одно и тоже время. Почему это так важно? Брифинг нужен в первую очередь для того, чтобы гарантированно сфокусировать себя и команду в начале рабочего дня. К тому же у команды вырабатывается чувство ритма.

Я покажу проблему, которая возникает, когда мы не координируемся с утра. Думаю, всем знаком PDCA цикл Деминга.

Он предполагает, что мы запланировали, потом начали делать, потом контролируем и так далее.

Что такое утренний брифинг? Это тоже акт планирования. С утра мы встретились, поняли какие проблемы у кого есть, и назначили отдельные встречи с теми людьми, с которыми их нужно решить. Проблемы, которые есть, на брифинге не решаются, чтобы не тратить время невовлеченных коллег.

Так вот, если мы с утра не собрались и не скоординировали общие действия, то мы будем делать это целый день — звонить, отвлекать друг друга. Этот PDCA цикл будет разрываться.

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

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

Постановка задач команде

С точки зрения делегирования, задачи можно разделить на два типа:

• Типовые — регламентированные, они повторяются из раза в раз, такие задачи мы уже делали. Это вот как раз история про тестирование, например прохождение чек-листов.
• Нетиповые — такие задачи раньше не выполнялись, они обладают высокой степенью неопределенности.

Если с типовыми все более-менее понятно, то к нетиповым задачам мы применяем такой подход, который включает в себя четыре этапа.

Первый этап — определяем зачем нужна задача

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

Здесь конечно же есть минус — приходится постоянно включать осознание, и думать зачем это нужно? Что я хочу получить? Это нагрузка на сознание.

Есть еще один тонкий момент — если я себе не ответил на этот вопрос, то и сотруднику будет трудно показать, зачем эта задача нужна. Здесь есть огромный риск того, что при исполнении задачи будут искажения. Если сотрудник не понимает, к чему он идет, он сам себе дорисует картину на основании своего уровня экспертизы.

Второй этап — представляем результат

Здесь я воображаю — что я жду в результате? Простой пример, задача — «настрой дашборд для демки». Задача ушла в работу. Какой здесь риск?

Я-то понимаю, что пойду на встречу с клиентом, у меня там 15 минут, за эти 15 минут я должен буду донести ключевую ценность своего продукта, и показать дашборд буквально с 2-3 чартами из будующего проекта.

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

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

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

Если трудно сформулировать ожидаемый результат, нужно ответить — какую проблему мы решаем при выполнении этой задачи?

Третий этап — записываем задачу

У нас принята такая формулировка — название проекта + задача, которая начинается с глагола в совершенном виде — сделать, выполнить, сконфигурировать.

Глагол должен быть направлен на получение конкретного результата. Отметаем все лишнее, нам нужно получить конкретный результат. Формируем далее заголовок задачки — рекомендуемая длина 5-7 слов, не более.

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

Ставим дату исполнения, но только если задачу или ее часть нужно выполнить до окончания спринта.

Четвертый этап — определяем кто делает?

На этом этапе мы определяем, кто в команде будет отвечать за результат выполнения задачи. Я предлагаю команде выбрать самостоятельно. Обычно вместо этого шага выполнялась простая процедура:

— Скажи мне, как ты меня услышал?

— Я тебя услышал так, что нужно сделать то-то и то-то.

Это хорошо, это сразу же обратная связь, это сразу контроль восприятия. Но, к сожалению, есть патология у такого подхода — зачастую это заканчивается тем, что сотрудник учится заучивать — развивается слуховая память. Услышал, запомнил, повторил.

Как вы думаете, в чем здесь минус? Мне нравится афоризм — «Из нескольких возможных интерпретаций коммуникации, наименее удобная является самой правильной» — Майкл Хардинг Роберт, автор «Project Management Book».

Осознания не произошло. Но мы взяли такой подход — это спросить первый шаг у исполнителя.

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

Планируем задачи команды

Вот здесь мы объединяем все то, о чем говорили раньше. Мы говорили про брифинги. Они должны опираться на что-то твердое, должны опираться на осознанную расстановку приоритетов задач. К тому же, все в ИТ любят трекить свои задачки. Мы используем для этого Trello, с вот таким набором списков:

• В «Проектах и идеях» мы держим крупноуровневые задачи и проекты, которые внутри разделены на более мелкие. Потом мы эти более мелкие перетаскиваем в список «Все задачи».
• В списке «Все задачи» содержатся задачи, которые нам предстоит реализовать примерно в течение месяца-полутора, т.е. в обозримом будущем.
• В начале недели, обычно это понедельник, мы накидывае задачи из списка «Все задачи» в «Спринт», тем самым планируя загрузку, но кроме прочего стараемся оставить небольшой запас времени на работу над внезапными задачами, которые могут появиться.
• В «Спринт» мы перетаскиваем те задачи, которые по общему мнению мы реально сделаем в течение недели.
• «Сегодня в работе» — название говорит само за себя — здесь висят карточки, над которыми работаем сегодня. Мы используем лейблы для придания контекста статусу задачи, но есть еще общее правило — более приоритетные задачи висят сверху.
• «Девеломпент» — здесь мы отмечаем те задачи, которые будут или были назначены разработчикам, и мы ждем пока они вернутся к нам.
• «Сделано» — сюда помещаются те задачи, которые были выполнены, протестированы и задокументированы. В этой же колонке мы отделяем каждую неделю. Например — неделя заканчивается 12 числа. Я завожу карточку и пишу название «12 февраля — закончить энд ту энд тестирование мобильного приложения». Это значит, что приоритет на неделю — тестирование мобильного приложения. Плюс, таким образом мы видим, что за неделю сколько задач было сделано. Это знание имеет мотивационный эффект. Мы сделали за неделю 25 задач. Ура, ура, мы — молодцы!

Помните, в начале я говорил про три вопроса? Так вот, я прошу записать вечером заранее три текстовых ответа к завтрашнему брифингу, опираясь именно на карточки задач с нашей доски:

• в блок «Сделано» — все задачи, выполненные за завершенный рабочий день (сегодня), лежащие в колонке «Готово»;
• в блок «Планирую» — все задачи, находящиеся в колонке «Сегодня в работе»;
• в блок «Мешает» — трудности и сложности, которые могут помешать выполнить план на завтра.

Это позволяет осознать, что надо будет сделать завтра и на брифинге, не нужно будет мучительно долго вспоминать — что же я вчера сделал, и что мне осталось доделать сегодня.

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