- PVSM.RU - https://www.pvsm.ru -
Всем привет! Это снова Иван Антипин, заместитель технического директора AGIMA. Весной я рассказывал здесь о матрице компетенций [1] — удобном инструменте менеджмента. И поскольку статья вызвала интерес, я подготовил еще одну. В этот раз речь пойдет о слабом звене — том самом участке работы, из-за которого рушится весь процесс. Разберемся, как его найти, с помощью чего устранить и что потом делать. Пишу по материалам доклада Ивана Михеева.
Представьте цепь: она состоит из множества одинаковых звеньев, все они скреплены между собой и крепко держат друг друга. Чтобы ее порвать, нужно приложить много усилий. И если усилий будет достаточно, порвется она в каком-то определенном месте. То есть какое-то звено абсолютно точно окажется слабее остальных.
Точно так же устроен почти любой процесс производства. Как бы идеально он ни выглядел, при высокой нагрузке он может сломаться на каком-то этапе. Поэтому важная задача тимлида — оперативно находить слабое звено и контролировать нагрузку на всю систему.
В этой статье я расскажу об инструментах поиска и устранения слабых мест в команде. Применять их могут как тимлиды, так и Project-менеджеры. Мы посвятили этому целый курс на площадке OTUS. [2]
Когда перед командой ставят конкретную цель, все производственные процессы обычно подгоняют под ее достижение. При этом не всем этапам работы уделяют одинаковое внимание. Часто тимлид концентрируется на самых понятных участках, в которых у команды больше компетенций, а про остальные забывает.
И когда кажется, что все процессы оптимальны, выясняется, что к цели команда так и не пришла.
Например, вам ставят бизнес-задачу снизить Time-to-Market — чтобы задачи максимально быстро проходили путь до продакшена. Что вы можете делать в этой ситуации? Внедрять CI/CD, внедрять практику автотестов, работать над тем, как формируются требования, чтобы разработчики точнее их понимали.
Но в то же время у вас появляется много легаси-кода, много регрессий, потому что внесение изменений в один модуль приводит к изменениям в других. Получается, вы работали над оптимизацией отдельных кусков, но в итоге к выработке процесса не добавили ничего. У вас быстрая поставка на продакшен и точные требования. Но сам процесс неоптимален. Это и есть слабое звено или, иначе, узкое горлышко.
Чтобы было совсем понятно, можно показать этот же пример схемой:
На схеме вы видите поток, который состоит из нескольких стадий. Допустим, это аналитика, разработка, тестирование и релиз. У каждого из этапов своя производительность. В этом случае тестирование — слабое звено, так как переваривает меньше всего задач.
Сколько бы не было задач на входе, на выходе их по-прежнему будет мало. На пути движения каждой их них встретится тестирование. А тестирование в нашем примере не может вырабатывать больше одной задачи в день. Усиливать аналитику или разработку бессмысленно — на общем процессе это не скажется.
Проще говоря, слабое звено — то узкое место в производственном процессе, которое на дает всему процессу работать эффективно.
1. Сделайте интуитивно понятные шаги: проследите, чтобы в узком месте люди работали эффективно и без простоя, а все задачи приходили к ним готовыми к исполнению.
В нашем примере важно, чтобы тестировщики не ждали артефактов, тест-кейсов, или когда им развернут тестовую среду. Пусть они постоянно обрабатывают этот поток. Процесс сразу станет эффективнее.
2. Устраните лишнюю работу, которую делают на предыдущих этапах: это уменьшает информационный поток и сокращает очередь из задач, которые к тому же теперь не нужно приоритизировать.
Теперь на тестирование приходят только актуальные задачи и только в том количестве, которое тестировщики могу переварить. Таким образом вы можете прогнозировать срок поставки точнее, чем когда у вас накопился большой бэклог
3. Расширьте ограничение: найдите способы сделать пропускную способность узкого места выше — чтобы оно перерабатывало больше задач, чем раньше.
Возьмите новых тестировщиков, внедрите автоматизированное тестирование, сократите количество легаси-кода или внедряйте новые практики.
А дальше мы снова начинаем искать слабое звено. Даже самая крепкая металлическая цепь все равно может порваться — всё зависит от нагрузки. Так что устранив одно узкое место, мы не успокаиваемся.
Этот подход называется «5 шагов процесса непрерывных улучшений»:
Эти шаги повысят эффективность в разы и помогут смотреть на процесс в целом, а не на его отдельные куски.
В конечном итоге можно мотивировать всю команду работать над улучшением процесса и достигать общей цели. Этот механизм называется трекшен. Он состоит из 4 этапов:
Обозначить цель для команды так, чтобы каждый ее понимал.
Найти ограничения и преграды для команды и декомпозировать их до мельчайших.
Выработать гипотезы, направленные на устранение этих ограничений.
Контролировать достижение цели.
Стоит поговорить о каждом из них подробнее.
Первый этап — формирование целей. Важно, чтобы каждая цель была четко сформулирована и понятна. Для этого ее стоит ставить по системе SMART [3].
Рассмотрим на примерах:
Плохой пример |
Хороший пример |
Хотим быстро пилить фичи |
Хотим сократить Time-to-Market с 5 недель до 2 до конца года |
Хотим много зарабатывать |
Хотим удвоить обороты компании за следующий год |
Хотим увеличить команду |
Хотим взять в штат 5 новых разработчиков за ближайшие 2 месяца |
Все три пример из левого столбца неизмеримые и неконкретные, а еще достигать их можно бесконечно долго. Примеры в правом столбце отвечают всем 5 критериям.
Дальше большую цель нужно разбить на маленькие задачи.
Если вернуться к нашему примеру, то его можно декомпозировать так:
Чтобы сократить Time-to-Market, нам надо сократить время на регрессию, которая тратится при разработке и отладке тестирования. Чтобы ее избежать, нужно сократить технический долг, который у вас есть на проекте. Чтобы убрать этот технический долг, нужно договориться с продакт-оунером, чтобы он каждый спринт уделял время на устранение технического долга.
Эти шаги и есть стратегия по достижению цели. Теперь можно искать слабые звенья. Для этого подойдут 2 инструмента:
«Пять почему»
Почему я не могу сократить Time-to-Market? У меня много регрессии. Почему у меня много регрессии? У нас много легаси-кода, там всё непонятно. Почему там всё непонятно? Потому что мы с ним не работаем, все наше время уходит на разработку продуктовых фичей. Почему так происходит? Потому продакт-оунер нам их так ставит.
Причин, почему происходит то или иное действие, может быть больше. Для этого есть другой инструмент:
Дерево текущей реальности
Этот инструмент помогает собрать все нежелательные явления или проблемы в кучу и найти для них единственную корневую причину. Устраните ее — исчезнут остальные проблемы. Вот как выглядит это дерево:
Проблема — высокий Time-to-Market. Почему он высокий? Есть несколько причин: во-первых, долгие процесс отладки и тестирования; во-вторых, много времени уходит на разработку. Почему у нас долгий процесс тестирования и отладки? Потому что у нас нет тест-кейсов. А еще тестировщики пропускают баги, и их находит заказчик. Это происходит, потому что багов много, тестировщики тратят время на их формализацию и описание. А почему так? Потому что у нас плохие требования. По ним тест-кейсы невозможно составить. Так как разработчики по плохим требованиям пилят неточный функционал, у нас возникает много багов. Вторая ветка: спрашиваем себя, почему разработчики тратят много времени. У нас плохие требования. По этому дереву мы видим, что корневая причина — плохие требования.
Причин может быть больше. Но, если составить полное дерево, вы все равно придете к одной корневой причине.
Когда причина сбоев ясна, ее нужно устранить. Для этого вы формируете гипотезы, которые могут приблизить команду к цели. Формулировать их лучше в виде «если… то…»
Если мы исправим технический долг, то у нас снизится количество багов.
Хорошая гипотеза имеет те же атрибуты, что и хорошая цель (SMART). Практика показывает, что из 10 гипотез срабатывает одна. Поэтому тестировать нужно как можно больше. Так выше вероятность, что вы найдете гипотезу, которая устранит ваши ограничения.
Важно: гипотезы нужно формировать на ближайшее ограничение. Нет смысла придумывать, как снизить Time-to-Market. Нужно разобраться с нижним уровнем, чтобы приблизиться к главной цели.
Делать это удобнее всего через трекшен-встречи. На них вы выясняете, все ли понимают цель, и напоминаете о ней, если это необходимо. Также на трекшен-встрече можно подводить промежуточные итоги.
Вот примеры вопросов, которые стоит задавать:
Какие изменения уже произвели и что сделали за предыдущий период?
Как это повлияло на цели?
Ушли ли ограничени?
Что мы будем делать дальше?
Трекшен-встречи проходят еженедельно. Важно, чтобы они были обязательными и неотвратимыми. Проводить их можно со всей командой или с отдельным человеком.
Еще одна черта трекшен-встречи: цели и решения должны исходить от участников. В противном случае это ничем не будет отличаться от стандартной схемы, когда начальник диктует подчиненному, что делать. При таком подходе каждый член команды чувствует личную ответственность за проект и больше верит в достижимость целей. А это улучшает общий результат.
Любая команда собирается не просто так: у них есть цель, которую нужно достичь. Поэтому важно, чтобы этот процесс был прозрачным для всех и эффективным. Но во время работы не всегда легко посмотреть на взаимодействие команды со стороны. Тут требуется помощь тимлида, который сможет найти, где и что сломалось.
Но чтобы члены команды тоже помнили об этой ответственности, нужен трекшен. Этот метод помогает:
грамотно ставить цели перед командой;
находить узкие места;
находить лишнюю работу и отказываться от нее.
Всё это делает работу понятнее для тимлида и команды и помогает достигать прогнозируемого результата в конкретные сроки.
Автор: Иван Антипин
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/matritsa/376017
Ссылки в тексте:
[1] Весной я рассказывал здесь о матрице компетенций: https://habr.com/ru/company/agima/blog/659387/
[2] Мы посвятили этому целый курс на площадке OTUS.: https://otus.ru/lessons/project_management/?utm_source=partners&utm_medium=free&utm_campaign=project-adv&utm_content=welcome&utm_term=agima_habr
[3] ставить по системе SMART: https://ru.wikipedia.org/wiki/SMART
[4] Источник: https://habr.com/ru/post/671500/?utm_source=habrahabr&utm_medium=rss&utm_campaign=671500
Нажмите здесь для печати.