Если вам приходилось управлять высокоспециализированными командами, вы наверняка видели, как специализация диктует приоритет работы. Хуже того, она часто создает препятствия, мешающие вашей команде быстро и эффективно добиваться результатов.
Дело в том, что специализация уменьшает поток. А сочетание специализации и значимости в команде может быть особенно разрушительным.
Сегодня мы рассмотрим, как специализация влияет на вашу общую производительность. И если это влияет на результаты вашего бизнеса, я дам вам несколько действенных советов (которые вы сможете применить уже завтра утром!) для решения этой проблемы.
Дилемма
Давайте проанализируем следующий сценарий. Это диаграмма старения команды разработчиков, состоящей из одного дизайнера, 2 front-end разработчиков, 2 back-end разработчиков и одного специалиста QA. Их процесс состоит из следующих состояний: Development, Code review, Code review (Done), Testing, Testing (Done) and Deployment.
Эта команда внедрила систему Kanban pull system. Все состояния “DONE” – это состояния очереди. Эти состояния используются для сообщения о том, что работа готова перейти к следующему состоянию.
CONWIP системы составляет 10 рабочих элементов. CONWIP означает постоянное количество незавершенных работ или, проще говоря, максимальное количество незавершенных работ, которым разрешено находиться в системе в любой момент времени.
В данный момент в состоянии Code Review (Done) находятся 5 карточек, ожидающих обработки в состоянии Testing. Никто над ними не работает, они просто лежат и стареют в процессе. В настоящее время команда работает над 8 рабочими элементами в целом, так что у них фактически есть возможность обработать еще 2 задачи.
Теперь мой вопрос к вам: “Должна ли команда начать новую работу в этой ситуации?”. У них все еще есть два свободных места, прежде чем они достигнут предела WIP в системе. Поскольку у разработчиков есть возможность выполнить больше работы, должны ли они перевести новые задачи в состояние “Разработка”?
Ваша скорость доставки была ограничена
Вот что происходит на самом деле. В штате тестирования образовалось нелепое узкое место. Очевидно, что специалист по контролю качества не в состоянии справиться со всей работой, которую выполняют разработчики.
Результат? Команда может работать только со скоростью самого медленного этапа процесса – этапа тестирования. Производительность команды теперь ограничена производительностью состояния тестирования.
Итак, учитывая эту перспективу, скажете ли вы, что имеет смысл начать новую работу? Не повлияет ли это действие на скорость сдачи системы, или, скорее, не усугубит ли проблему нагромождение все новых и новых рабочих элементов перед состоянием тестирования?
Лучший подход для работы с этим сценарием заключается в том, чтобы остановить начало работы и взять людей, которые имеют наибольшую доступность, и позволить им внести свой вклад в работу людей, которые имеют наименьшую доступность. Это вскоре позволит возобновить поток работы.
Вызов подкрепления
Давайте прибавим газу! Может ли разработчик заниматься тестированием? Есть ли у разработчика навыки, которые помогут ему в тестировании?
Да, а если и нет, то разница между теми навыками, которыми он обладает сейчас, и теми, которые ему необходимы, вероятно, невелика.
- Конечно, чтобы это работало, должны быть применены некоторые правила. Например:
- Разработчики не должны тестировать свой собственный код
- Специалист по контролю качества решает, что тестируют разработчики и как это тестировать
- Специалист по контролю качества проверяет работу разработчиков
- Специалист по контролю качества – единственный человек, который имеет право продвигать работу дальше в рабочий процесс.
Давайте рассмотрим другой пример. Допустим, PM помогает клиентам в процессе регистрации, и она не может запланировать работу на следующую итерацию. В результате система испытывает голод.
Итак, может ли дизайнер помочь доработать карты в процессе upstream, чтобы внести некоторую ясность и подготовить работу к разработке? Конечно, им необходимо следовать установленным явным политикам процесса, чтобы продвигать работу по воронке, но вполне вероятно, что дизайнер сможет справиться с этим.
Здесь происходит нечто большее, чем просто поощрение проактивного поведения. Такой подход на самом деле поможет команде развить новые навыки и стать более эмпатичной, более вовлеченной в концепцию потока, чтобы на самом деле помочь достичь результатов наиболее эффективным способом.
Полезное и не очень полезное поведение
Поведение, которое я наблюдаю в командах и которое делает их неспособными эффективно справляться с подобными ситуациями, обычно связано со специализацией. Поскольку под специализацией скрывается сильное чувство идентичности человека, которое позволяет ему чувствовать себя значимым и ценным.
Если вы единственный человек в команде, который обладает особым ремеслом, люди, занимающиеся вашей деятельностью, заставят вас чувствовать себя менее значимым.
Хотя мне нравится идея, что люди обладают особыми навыками, я не хочу видеть сценарии, в которых только один человек может внести вклад в решение определенной проблемы, которая ждет своего решения. Еще хуже то, на что вам действительно следует обратить внимание, это когда эксперты в предметной области сопротивляются тому, чтобы делиться своими знаниями.
Это та ситуация, когда специализация может стать причиной действительно плохой черты характера. Поэтому, когда вы замечаете такое нежелание, вы должны его пресечь.
Когда я работаю с высокоспециализированными командами, я часто прибегаю к одному из моих любимых методов общения – заставляю их проверить свои названия. Если кто-то называется front-end разработчиком, это не обязательно означает, что он занимается только front-end работой. Да, они могут выполнять эту работу большую часть времени, но часто ощущение специализации возникает само собой. И я пытаюсь показать им, что они – единственные люди, которые воспринимают себя таким образом.
С точки зрения бизнеса, если люди работают только над теми задачами, которые подходят для их специальных навыков, это разрушительно, потому что либо начало работы искусственно откладывается, либо после ее начала срок выполнения жестко привязывается к наличию специалистов. В обоих случаях мы задерживаем работу и упускаем возможности для улучшения в долгосрочной перспективе.
Вот очень простой шаг, который вы можете предпринять, который поможет вам сосредоточиться на результатах вашей системы доставки и позволит вашей команде самоорганизоваться вокруг работы!
Внедрите четкую политику процесса, описывающую, как команда должна управлять своей незавершенной работой. Это может выглядеть следующим образом:
- “Как только вы закончили работу, вместо того, чтобы сразу же брать новую из бэклога, сначала просмотрите карточки на доске. Начните с крайней правой колонки, затем двигайтесь к началу рабочего процесса.
- Ищите элементы, которые ни за кем не закреплены, любые проблемы, которые нужно исправить (даже если они не закреплены за вами), все, что ждет обзора кода или реализации обратной связи от обзора кода.
- Новый элемент работы следует начинать только в том случае, если вы буквально ничего не можете сделать, чтобы помочь текущим элементам работы продвинуться вперед в процессе”.
- Понаблюдайте, как соблюдение этой политики влияет на поведение команды, и сосредоточьтесь на устранении препятствий, которые мешают им заниматься работой друг друга.
Важно помочь команде понять цель такого подхода. Если позволить людям помогать друг другу и сосредоточиться на эффективном управлении работой, это повысит скорость выполнения работы. Обмен знаниями и навыками не только повысит их эффективность, но и позволит им стать по-настоящему сплоченной командой.
Всегда помните, что достижение устойчивых бизнес-результатов сводится к эффективному управлению работой. Обеспечение ценности для наших клиентов – это взаимные усилия. Создавайте атмосферу сотрудничества, доверия и уважения. Это и есть основной подход к повышению общей эффективности работы.
Flow Metrics: управление потоковым производством на основе данных
В октябре мы запустили новый учебный курс «Flow Metrics: управление потоковым производством на основе данных». Новый курс дистанционный, для самостоятельного изучения. Его можно пройти часов за 8-10, хотя доступ мы даём на полгода.
Мы подготовили более 70 паттернов для 7 ключевых метрик потока, чтобы можно было не столько читать теорию, сколько тренироваться на практике, на графиках и диаграммах, а их на курсе больше 170.
Поэтому если вы неравнодушны к словам «поток создания ценности» и «измеримые показатели», то приглашаем вас посмотреть на наш новый курс.
По запросу мы предоставляем демонстрационный доступ к первым разделам курса.
