Меньше слов, больше дела: как ускорить коммуникацию на 250%, а разработку на 50%

Ничто не увеличивается так незаметно, как количество коммуникации c заказчиком. С одной стороны, это значит, что сотрудничество развивается, клиент готов отдавать нам больше задач в работу, а релиз близко. Но с другой стороны возникает риск, что коммуникация, начинает занимать больше времени, чем сама разработка. И то, на что раньше уходило две недели, теперь нужно три. А в будущем последствия могут быть критическими – например, релиз будет серьезно задержан. Зачем такое допускать?
Мы уже девять лет занимаемся тестированием, поэтому такие ситуации видим заранее. И применяем эффективные инструменты управления проектами. Например, матрицу RACI. Но обо всем по порядку.

Как коммуникация может тормозить процесс?

Как коммуникация может тормозить процесс?

Как в нашем случае вышло так, что рост коммуникации, без изменения полномочий, мог привести к неэффективной работе команды и замедлению процессов?

Наше сотрудничество с крупной страховой компанией длится уже больше двух лет. Из них последние полгода мы успешно разрабатываем для клиента автотесты. С учетом специфики задачи в проекте сформировалась команда из трех автоматизаторов – одного ведущего и двух младших специалистов.

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

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

Как ускорить работу/тестирование при росте объема задач?

Как ускорить работу/тестирование при росте объема задач?

Оценив ситуацию и сделав вывод, что наш ведущий автоматизатор перегружен, мы начали поиск оптимального инструмента для делегирования полномочий и распределения ответственности. Нам подошла матрица RACI.

Что такое матрица RACI? Это удобный и наглядный инструмент для проектирования и планирования изменений в полномочиях и задачах команды. Её еще называют матрицей ответственности.

Название RACI сформировалось как аббревиатура из четырех ролей, которые нужно распределить в команде:

R – Responsible (исполняет задачу);

A – Accountable (несет ответственность);

C – Consult before doing (консультирует до исполнения);

I – Inform after doing (оповещается после исполнения).

Какие важные нюансы нужно учитывать при построении матрицы RACI, исходя из нашего опыта?

  1. Необходимо выписать все 100% задач и активностей, которые выполняются в команде. Только так возможно увидеть узкие места и принять меры. Поэтому при обсуждении должна присутствовать вся команда проекта.
  2. Каждая активность обязательно должна иметь роли “Ответственного” и “Исполнителя”. Иначе либо задачу некому выполнять, либо не с кого спросить результат. Это кажется логичным, но на практике при составлении матрицы RACI оказывается не всё так просто.

Составив матрицу RACI по текущей ситуации в проекте, мы наглядно убедились, что ведущий автоматизатор перегружен задачами и отвечает за большой объем работ на проекте. При этом он не может выполнять действительно важные задачи, так как часто отвлекается на текучку и коммуникации с разработчиками заказчика.

Что делать в такой ситуации? Делегировать полномочия!

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

  • запуск автотестов на ферме;
  • анализ прогона автотестов на ферме: постановка задач на исправление автотестов, проставление статусов в TestRail;
  • выборка тест-кейсов на автоматизацию и постановка задач по ним;
  • консультирование сотрудников заказчика.

Кажется, что можно было сделать это и без RACI, но именно ее наглядность и точность позволяет провести трансформацию максимально эффективно. Потому что в матрице детально видно, за что именно человек отвечает и что делает. И очень просто провести декомпозицию матрицы, собрав этот «кубик Рубика» с правильным, а главное нужным узором.

Да, в этой ситуации нам немного повезло, что ведущий автоматизатор продержался в роли «Атланта» ровно столько, сколько понадобилось младшим специалистам, чтобы набраться опыта. И на вопрос «ребят, человек загружен, а вы уже достаточно круто прокачались, давайте расти дальше?», было легко получить положительный ответ.

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

Что мы получили?

Что мы получили?

Результаты внедрения матрицы RACI порадовали и нас, и заказчика:

  1. Вместо 50 часов, затраченных на коммуникации в декабре, в январе мы потратили всего 14 часов. Старший автоматизатор снова занимался своей основной работой, потому что коммуникация ускорилась на 257%.
  2. Скорость разработки автотестов у старшего автоматизатора увеличилась на 50%! Вот, что бывает, когда человек занимается любимым делом и не переживает, что ничего не успевает.
  3. Младшие сотрудники прокачали новые профессиональные навыки и выросли. Ребята начали разбираться в новых модулях и автотестах.
  4. Старший автоматизатор получил важные навыки делегирования задач и ответственности.
  5. Прокачанные сотрудники стали взаимно дополнять и подстраховывать друг друга – мы получили более эффективную команду в комплексе.
  6. Мы нашли и опробовали новый инструмент, который повысил эффективность коммуникации в наших проектах на 30-50%.
  7. Получили очередного довольного клиента, оценившего ускорение процесса разработки и отсутствие авралов на проекте.

Заключение

Один из основных принципов построения и анализа матрицы RACI звучит так: «если у одного сотрудника в таблице слишком много ролей R или А, то стоит пересмотреть его обязанности – действительно ли сотрудник должен отвечать за такое количество задач или выполнять такое количество работы?». Эта фраза звучит логично и без матрицы, правда?

В этом и заключается главная идея – RACI всего лишь инструмент. Эффективный, но один из множества, который можно применять для организации работы команды в IT-компаниях. Главное – это результат, который дает внедрение матрицы. В нашем случае мы не допустили развития критической ситуации в работе, спасли сотрудника от возможного выгорания в будущем и ускорили разработку автотестов.

Не думайте, что наши наработки мы применяем только в тестировании. Отдел разработки поделился матрицей RACI с маркетологами и смотрите, как они адаптировали её для контроля многоэтапного процесса подготовки и участия экспертов ЛК в IT конференциях по всему миру.

Меньше слов, больше дела

Кстати, ближайший наш доклад пройдет 26 апреля в рамках первого дня VIII Международной IT-конференции «Стачка 2019» — смотрите детальную информацию по ссылке и приходите послушать.

И делитесь своим опытом — какие инструменты и методики вы использовали для IT-менеджмента и с какими подводными камнями сталкивались? Свой фидбек оставляйте в комментариях в блоге и наших соц. сетях.

Другие статьи
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
Email
guest
1 Комментарий
Популярные
Новые Старые
Межтекстовые Отзывы
Посмотреть все комментарии
Александр Михайлов
Александр Михайлов
5 лет назад

что такое М в таблице маркетологов?