Ничто не увеличивается так незаметно, как количество коммуникации c заказчиком. С одной стороны, это значит, что сотрудничество развивается, клиент готов отдавать нам больше задач в работу, а релиз близко. Но с другой стороны возникает риск, что коммуникация, начинает занимать больше времени, чем сама разработка. И то, на что раньше уходило две недели, теперь нужно три. А в будущем последствия могут быть критическими – например, релиз будет серьезно задержан. Зачем такое допускать?
Мы уже девять лет занимаемся тестированием, поэтому такие ситуации видим заранее. И применяем эффективные инструменты управления проектами. Например, матрицу RACI. Но обо всем по порядку.
Как коммуникация может тормозить процесс?
Как в нашем случае вышло так, что рост коммуникации, без изменения полномочий, мог привести к неэффективной работе команды и замедлению процессов?
Наше сотрудничество с крупной страховой компанией длится уже больше двух лет. Из них последние полгода мы успешно разрабатываем для клиента автотесты. С учетом специфики задачи в проекте сформировалась команда из трех автоматизаторов – одного ведущего и двух младших специалистов.
Ситуация была комплексной и на нее повлияло два фактора. С одной стороны, из проекта ушли «ручные» тестировщики, которые общались с клиентом, и вся коммуникация перешла на ведущего автоматизатора. С другой стороны, младшие специалисты были недостаточно опытны, чтобы решать некоторые задачи напрямую.
Количество задач в проекте увеличивалось – приходилось общаться с большим количеством разработчиков на стороне заказчика. В итоге ведущий сотрудник «оказался между двух огней» – нужно было больше общаться с заказчиком, но он не мог делегировать часть своих задач другим.
Как ускорить работу/тестирование при росте объема задач?
Оценив ситуацию и сделав вывод, что наш ведущий автоматизатор перегружен, мы начали поиск оптимального инструмента для делегирования полномочий и распределения ответственности. Нам подошла матрица RACI.
Что такое матрица RACI? Это удобный и наглядный инструмент для проектирования и планирования изменений в полномочиях и задачах команды. Её еще называют матрицей ответственности.
Название RACI сформировалось как аббревиатура из четырех ролей, которые нужно распределить в команде:
R – Responsible (исполняет задачу);
A – Accountable (несет ответственность);
C – Consult before doing (консультирует до исполнения);
I – Inform after doing (оповещается после исполнения).
Какие важные нюансы нужно учитывать при построении матрицы RACI, исходя из нашего опыта?
- Необходимо выписать все 100% задач и активностей, которые выполняются в команде. Только так возможно увидеть узкие места и принять меры. Поэтому при обсуждении должна присутствовать вся команда проекта.
- Каждая активность обязательно должна иметь роли “Ответственного” и “Исполнителя”. Иначе либо задачу некому выполнять, либо не с кого спросить результат. Это кажется логичным, но на практике при составлении матрицы RACI оказывается не всё так просто.
Составив матрицу RACI по текущей ситуации в проекте, мы наглядно убедились, что ведущий автоматизатор перегружен задачами и отвечает за большой объем работ на проекте. При этом он не может выполнять действительно важные задачи, так как часто отвлекается на текучку и коммуникации с разработчиками заказчика.
Что делать в такой ситуации? Делегировать полномочия!
Мы перераспределили часть задач ведущего автоматизатора на младших специалистов. По факту они могут выполнять любые его обязанности, просто пока не так быстро. Младшие специалисты включились в такие задачи:
- запуск автотестов на ферме;
- анализ прогона автотестов на ферме: постановка задач на исправление автотестов, проставление статусов в TestRail;
- выборка тест-кейсов на автоматизацию и постановка задач по ним;
- консультирование сотрудников заказчика.
Кажется, что можно было сделать это и без RACI, но именно ее наглядность и точность позволяет провести трансформацию максимально эффективно. Потому что в матрице детально видно, за что именно человек отвечает и что делает. И очень просто провести декомпозицию матрицы, собрав этот «кубик Рубика» с правильным, а главное нужным узором.
Да, в этой ситуации нам немного повезло, что ведущий автоматизатор продержался в роли «Атланта» ровно столько, сколько понадобилось младшим специалистам, чтобы набраться опыта. И на вопрос «ребят, человек загружен, а вы уже достаточно круто прокачались, давайте расти дальше?», было легко получить положительный ответ.
После перераспределения задач, у нас ушла неделя на обучение сотрудников и их погружение в задачи. Но эти затраты времени себя оправдали. Команда начала работать эффективнее и быстрее. Улучшились не только качественные показатели, которые можно измерить, вырос профессиональный уровень сотрудников.
Что мы получили?
Результаты внедрения матрицы RACI порадовали и нас, и заказчика:
- Вместо 50 часов, затраченных на коммуникации в декабре, в январе мы потратили всего 14 часов. Старший автоматизатор снова занимался своей основной работой, потому что коммуникация ускорилась на 257%.
- Скорость разработки автотестов у старшего автоматизатора увеличилась на 50%! Вот, что бывает, когда человек занимается любимым делом и не переживает, что ничего не успевает.
- Младшие сотрудники прокачали новые профессиональные навыки и выросли. Ребята начали разбираться в новых модулях и автотестах.
- Старший автоматизатор получил важные навыки делегирования задач и ответственности.
- Прокачанные сотрудники стали взаимно дополнять и подстраховывать друг друга – мы получили более эффективную команду в комплексе.
- Мы нашли и опробовали новый инструмент, который повысил эффективность коммуникации в наших проектах на 30-50%.
- Получили очередного довольного клиента, оценившего ускорение процесса разработки и отсутствие авралов на проекте.
Заключение
Один из основных принципов построения и анализа матрицы RACI звучит так: «если у одного сотрудника в таблице слишком много ролей R или А, то стоит пересмотреть его обязанности – действительно ли сотрудник должен отвечать за такое количество задач или выполнять такое количество работы?». Эта фраза звучит логично и без матрицы, правда?
В этом и заключается главная идея – RACI всего лишь инструмент. Эффективный, но один из множества, который можно применять для организации работы команды в IT-компаниях. Главное – это результат, который дает внедрение матрицы. В нашем случае мы не допустили развития критической ситуации в работе, спасли сотрудника от возможного выгорания в будущем и ускорили разработку автотестов.
Не думайте, что наши наработки мы применяем только в тестировании. Отдел разработки поделился матрицей RACI с маркетологами и смотрите, как они адаптировали её для контроля многоэтапного процесса подготовки и участия экспертов ЛК в IT конференциях по всему миру.
Кстати, ближайший наш доклад пройдет 26 апреля в рамках первого дня VIII Международной IT-конференции «Стачка 2019» — смотрите детальную информацию по ссылке и приходите послушать.
И делитесь своим опытом — какие инструменты и методики вы использовали для IT-менеджмента и с какими подводными камнями сталкивались? Свой фидбек оставляйте в комментариях в блоге и наших соц. сетях.
