Описанные подходы я применяю в 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-командой применяем в работе. Напомню еще раз — это утренние брифинги, постановка и планирование задач команды. Эти подходы позволяют нам быстро фокусироваться, поставлять результаты в срок, и что не менее важно — держать команду в тонусе, показывая им результаты работы.