Найти слабое звено: делаем команду эффективнее без перегруза

Всем привет! Это снова Иван Антипин, заместитель технического директора AGIMA. В этой статье речь пойдет о слабом звене — том самом участке работы, из-за которого рушится весь процесс. Разберемся, как его найти, с помощью чего устранить и что потом делать. Пишу по материалам доклада Ивана Михеева.

Представьте цепь: она состоит из множества одинаковых звеньев, все они скреплены между собой и крепко держат друг друга. Чтобы ее порвать, нужно приложить много усилий. И если усилий будет достаточно, порвется она в каком-то определенном месте. То есть какое-то звено абсолютно точно окажется слабее остальных.Точно так же устроен почти любой процесс производства. Как бы идеально он ни выглядел, при высокой нагрузке он может сломаться на каком-то этапе. Поэтому важная задача тимлида — оперативно находить слабое звено и контролировать нагрузку на всю систему.

В этой статье я расскажу об инструментах поиска и устранения слабых мест в команде. Применять их могут как тимлиды, так и Project-менеджеры. Мы посвятили этому целый курс на площадке OTUS.

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

И когда кажется, что все процессы оптимальны, выясняется, что к цели команда так и не пришла.

Например, вам ставят бизнес-задачу снизить Time-to-Market — чтобы задачи максимально быстро проходили путь до продакшена. Что вы можете делать в этой ситуации? Внедрять CI/CD, внедрять практику автотестов, работать над тем, как формируются требования, чтобы разработчики точнее их понимали.

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

Чтобы было совсем понятно, можно показать этот же пример схемой:

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

Сколько бы не было задач на входе, на выходе их по-прежнему будет мало. На пути движения каждой их них встретится тестирование. А тестирование в нашем примере не может вырабатывать больше одной задачи в день. Усиливать аналитику или разработку бессмысленно — на общем процессе это не скажется.

Проще говоря, слабое звено — то узкое место в производственном процессе, которое на дает всему процессу работать эффективно.

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

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

2. Устраните лишнюю работу, которую делают на предыдущих этапах: это уменьшает информационный поток и сокращает очередь из задач, которые к тому же теперь не нужно приоритизировать.

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

3. Расширьте ограничение: найдите способы сделать пропускную способность узкого места выше — чтобы оно перерабатывало больше задач, чем раньше.

Возьмите новых тестировщиков, внедрите автоматизированное тестирование, сократите количество легаси-кода или внедряйте новые практики.

А дальше мы снова начинаем искать слабое звено. Даже самая крепкая металлическая цепь все равно может порваться — всё зависит от нагрузки. Так что устранив одно узкое место, мы не успокаиваемся.

Этот подход называется «5 шагов процесса непрерывных улучшений»:

Эти шаги повысят эффективность в разы и помогут смотреть на процесс в целом, а не на его отдельные куски.

В конечном итоге можно мотивировать всю команду работать над улучшением процесса и достигать общей цели. Этот механизм называется трекшен. Он состоит из 4 этапов:

Стоит поговорить о каждом из них подробнее.

Первый этап — формирование целей. Важно, чтобы каждая цель была четко сформулирована и понятна. Для этого ее стоит ставить по системе SMART.

Все три пример из левого столбца неизмеримые и неконкретные, а еще достигать их можно бесконечно долго. Примеры в правом столбце отвечают всем 5 критериям.

Дальше большую цель нужно разбить на маленькие задачи.Если вернуться к нашему примеру, то его можно декомпозировать так:

Чтобы сократить Time-to-Market, нам надо сократить время на регрессию, которая тратится при разработке и отладке тестирования. Чтобы ее избежать, нужно сократить технический долг, который у вас есть на проекте. Чтобы убрать этот технический долг, нужно договориться с продакт-оунером, чтобы он каждый спринт уделял время на устранение технического долга.

Эти шаги и есть стратегия по достижению цели. Теперь можно искать слабые звенья. Для этого подойдут 2 инструмента:

Причин, почему происходит то или иное действие, может быть больше. Для этого есть другой инструмент:

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

Проблема — высокий Time-to-Market. Почему он высокий? Есть несколько причин: во-первых, долгие процесс отладки и тестирования; во-вторых, много времени уходит на разработку. Почему у нас долгий процесс тестирования и отладки? Потому что у нас нет тест-кейсов. А еще тестировщики пропускают баги, и их находит заказчик. Это происходит, потому что багов много, тестировщики тратят время на их формализацию и описание. А почему так? Потому что у нас плохие требования. По ним тест-кейсы невозможно составить. Так как разработчики по плохим требованиям пилят неточный функционал, у нас возникает много багов. Вторая ветка: спрашиваем себя, почему разработчики тратят много времени. У нас плохие требования. По этому дереву мы видим, что корневая причина — плохие требования.

Причин может быть больше. Но, если составить полное дерево, вы все равно придете к одной корневой причине.

Когда причина сбоев ясна, ее нужно устранить. Для этого вы формируете гипотезы, которые могут приблизить команду к цели. Формулировать их лучше в виде «если… то…»

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

Хорошая гипотеза имеет те же атрибуты, что и хорошая цель (SMART). Практика показывает, что из 10 гипотез срабатывает одна. Поэтому тестировать нужно как можно больше. Так выше вероятность, что вы найдете гипотезу, которая устранит ваши ограничения.

Важно: гипотезы нужно формировать на ближайшее ограничение. Нет смысла придумывать, как снизить Time-to-Market. Нужно разобраться с нижним уровнем, чтобы приблизиться к главной цели.

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

Вот примеры вопросов, которые стоит задавать:

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

Любая команда собирается не просто так: у них есть цель, которую нужно достичь. Поэтому важно, чтобы этот процесс был прозрачным для всех и эффективным. Но во время работы не всегда легко посмотреть на взаимодействие команды со стороны. Тут требуется помощь тимлида, который сможет найти, где и что сломалось.

Но чтобы члены команды тоже помнили об этой ответственности, нужен трекшен. Этот метод помогает:

Всё это делает работу понятнее для тимлида и команды и помогает достигать прогнозируемого результата в конкретные сроки.