Как навести порядок в процессах

Встречаясь с потенциальными заказчиками, я за день дважды столкнулся с одной ситуацией. Две компании попросили меня поделиться приёмами scrum, так как их собственная система управления процессами работает хуже, чем хотелось бы.

Я не часто рассказываю клиентам про скрам, lean и agile с целью, чтобы они что-то внедрили. Для этого есть профессиональные консультанты. Вообще, чтобы внедрить новую методику, нужны воля и власть. А желание меняться должно исходить от первых лиц компании.

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

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

После пары вопросов получилось нащупать главные проблемы компаний:

1. Часть задач теряется и не выполняется.
2. Если задача в приоритете, то в установленный срок (квартал/ полгода/ год) её все-таки успевают закончить. Но в процессе работы приходит Главный и выясняется, что здесь не так, а тут он по-другому себе представлял. Так в незаконченном проекте появляются новые задачи, а часть старых либо требуют переделки, либо становятся не актуальными. Как будто моешь посуду, а тебе еще подкидывают.

Обе организации понимали: чтобы усилить контроль над проектами, нужно их визуализировать. И они честно пытались это сделать, но лучше почему-то не стало. Компании (никак не связанные друг с другом!) показали похожие схемы неопознанного происхождения — нечто среднее между цветастой радиальной диаграммой и пентаграммой для призыва демонов. Проекты (кажется, это были они) подписаны непонятными аббревиатурами. В схеме проглядывается что-то похожее на приоритетность, но кто исполнитель и на каком этапе работа с задачей — понять невозможно.

Конечно, оно не работало. И вопрос, почему задачи теряются, отпал сразу.

А в статье я разберу, как разложить проекты по полочкам и успеть сделать все до дедлайна без помощи бизнес-консультантов.

Чем понятнее образ, тем лучше он работает. В этом плане хорош канбан: одна доска, несколько колонок со стадиями и по ним разбросаны карточки с проектами — проще некуда.

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

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

Но подстроить канбан под свои процессы, даже если их много и в каждом — уникальное течение работ, возможно.

У всех задач плюс-минус одинаковый жизненный цикл: нужно сделать — в работе — выполнена. Вот их и вынесите на канбан. Можно добавить дополнительные графы — например, у компаний с большим количеством задач во втором столбике висят задачи «В первую очередь» — те, которые пока не горят, но скоро начнут дымиться.

Когда колонки сформированы и по ним раскиданы карточки с проектами — получается ясная картинка, что вообще есть и на каком этапе. А сами проекты с их уникальным потоком работ можно вести во вспомогательной программе — присмотритесь к Scrumban или Trello.

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

Хорошая идея (к сожалению, не реализованная в Trello и толком не додуманная в Scrumban) — плавательные дорожки. Но если у вас ламповая пробковая доска (или хотя бы ватман) — выделите на ней под каждого руководителя горизонтальные дорожки и раскидайте задачи по ответственным. Сразу найдёте проекты без присмотра и с несколькими менеджерами и увидите, кто перегружен, а кому можно докинуть задач.

Желание навесить на руководителей побольше задач, чтобы быстрее все сделать, понятно. Но неправильно.

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

Показать и расписать, что сокращение Work In Progress ускоряет процессы, не так-то просто. Это не очевидно. Можете поверить мне, а можете попытаться разобраться самостоятельно — с помощью экспериментов над сотрудниками и чтения книг по lean и канбан.

Вот вам суровая канбан математика — адаптированный пример из книги Л. Джеффри «Дао Toyota». Не стану грузить вас историями про производство компьютеров — держите сладкий рассказ про выпечку.

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

1. испечь бисквитное тельце;
2. смазать его кремом;
3. водрузить вишенку на кремовую шапку.

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

Сначала вы ждёте, пока в первом отделе выпекут 10 бисквитных основ, потом — когда следующий отдел обмажет их кремом, и после везёте недокексы в отдел декорирования — украсить вишенкой. Если на каждый вид работы уходит 1 минута, то первое изделие будет готово через 21 минуту, а партия из 10 кексов — через 30 минут. При этом одновременно в процессе выпечки, обмазывания кремом и декорирования находится не менее 21 кекса.

Но если поделить работу на небольшие задачи с готовым продуктом на выходе — дело пойдет быстрее.

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

На каждый этап по-прежнему нужна 1 минута. Так как вы теперь не ждёте, пока этап полностью завершится для 10 кексов, работники выпекут первый уже через 3 минуты. А 10 кексиков будут готовы через 12 минут. При этом работа идёт только с 2 кексами одновременно.

Этот метод исключает возникновение запасов и излишков — они серьезно тормозят работу. Пока вы производите продукцию и выполняете задачи впрок, тот, кто делает проект последовательно маленькими порциями и не тратит ресурсы на создание запасов, уже закончил.

Сокращение WIP обязательно приведет к простою каких-то сотрудников или остановке всего предприятия. Но так как все хотят быть занятыми (вернее, выглядеть таковыми) — набирают новые проекты, да побольше. Эффект локальной оптимизации. И он мешает организации в целом.

Сокращение WIP помогает понять главное: кто или что в компании — узкое звено. Мы должны управлять системой через ограничение. Если видим, что работа застопорилась из-за того, что бухгалтерия не успевает подписывать акты — это повод оптимизировать работу бухгалтерии. Чтобы остальные отделы не набирали новые задачи, а как можно быстрее заканчивали текущие.

Запомните: где есть запас — появляется затык. И запишите. Повесьте в рамочку над рабочим столом и бросайте плюшничать и создавать запасы.

А подробнее о WIP читайте у Элияху Голдратта.

Из-за того, что задачи станут короче, скорее всего, потребуется уменьшить период планирования. Классические квартал / полгода / год — не всегда комфортный срок для реализации проектов. За это время пропадает актуальность части задач, ослабевает контроль. Отсюда — проблема, когда Главный ругается, потому что его ожидания не совпали с реализацией проекта. И докидывает новые задачи по проектам, с которыми вы мысленно попрощались уже месяц назад.

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

Здесь мы близко подошли к agile с его двухнедельными итерациями. Но этот период подходит не для всех. Две недели — достаточный срок для маркетинга и разработки ПО, но его не хватит для разработки, скажем, электроники. Комфортный для вашей компании срок итераций нужно нащупать опытным путём.

Если проекты в компании идут неисповедимыми путями, часть при этом теряется, а виноватых вроде как и нет, нужно что-то делать. Здорово, если в компании это понимают и ищут пути решения.

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

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