Максим Цепков - Менеджмент цифрового мира

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

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

WIP-лимиты и вытягивание – ограничиваем незавершенную работу.

Основными характеристиками сервиса является мощность потока задач, которые он обрабатывает и скорость прохождения отдельных задач через сервис. Как учит теория ограничений Голдратта, для высокой скорости прохождения задач необходимо ограничить количество незавершенной работы. Для этого в Kanban есть механизм WIP-лимитов, которые ограничивают незавершенную работу. При этом используется разные виды лимитов: на человека, на задачу в целом, на классы обслуживания, на этапы работ. Отметим, что в случае обычного производства ограничением является какие-то конкретные этапы обработки. А в IT из-за высокой неопределенности, связанной с исполнением задачи и длинного хвоста распределения вероятности выполнения, мы, как правило, не можем уверенно выделить этапы, являющиеся ограничениями. Поэтому WIP-лимиты устанавливаются для всех этапов.

WIP-лимит служит ограничением не только числа задач, находящихся в работе на конкретной фазе, но и для тех, которые уже готовы для передачи на следующий этап. В этом и состоит суть вытягивания: задача закреплена за фазой исполнения до тех пор, пока на следующей фазе не освободиться для нее место. Таким образом, возможна ситуация, когда завершив очередную задачу сотрудник не может взять следующую, потому что сработало ограничение лимита. И в этот момент возникает вопрос: а что ему делать? Ответы могут быть разными: «отдохнуть и выспаться», «помочь другим», «посмотреть, что можно сделать в других этапах», «почитать книгу». Важно не брать задачу сверх лимита, увеличивая этим незавершенную работу и нарушая, таким образом, производительность Kanban-системы. Теория ограничений говорит: простои сотрудников не ведут к деградации сервиса. Отметим, что переход к вытягиванию и WIP-лимитам поощряет или даже вводит культуру помощи. Сотрудники учатся видеть потенциально узкие места, в которых скапливаются готовые задачи, которые невозможно продвинуться, потому что на следующих этапах образовалось бутылочное горлышко, и помогать в его разгребании. На статусе у доски разбор идет не по сотрудникам, а по задачам справа налево, и следует обращать особое внимание на те зоны, в которых бутылочное горлышко может возникнуть. А еще такой разбор привносит культуру завершения: начиная с задач, которые продвинулись дальше и уже получили больше незавершенной работы, мы даем им больше внимания, фокусируясь на завершении начатого. И, наконец, формируется культура управления через структурирование работы, а не людей, при этом предполагается, что люди сами соорганизуются вокруг работы, которую им необходимо выполнить. Во время перехода к Kanban это делает коуч, а постепенно навык получает вся команда. И таким образом культура сотрудничества, фокуса на завершении задач (ориентированность на клиента) и другие ценности Kanban прорастают в команде. Так же ценностях и культуре Kanban есть перевод хорошей статьи Майкла Барроуза.

Переход к вытягивающей системе выполняется не сразу. WIP-лимиты вводят постепенно, анализируя изменения, к которым их изменение привело для обработки потока задач. И не существует никакой формулы, которая бы позволила вычислить «правильные лимиты» в зависимости от команды: многое зависит именно от конкретного потока задач, а он индивидуален.

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

Если такие ситуации регулярно возникают и являются типичными, то команда превращается в «отдел ждунов», и это сигнал ситуации, когда никакие внутренние реорганизации не смогут принципиально изменить ситуации. Стоит задуматься о перестройке работы, например, исключении лишних согласований со смежниками или руководством. Сила Kanban-системы в том, что она позволяет увидеть такие ситуации и оценить потери от лишних согласований, а также реальные риски их отсутствия: сколь часто возникают ситуации, когда на согласовании задача была изменена. Алексей Пименов в упомянутом выше докладе рассказывал, что у него было много кейсов, когда согласование занимает 30—50% от времени реализации, и отделу принимать решения без согласования получалось ускорить процесс в полтора раза.

Отдельно стоит сказать про буферную зону входных задач. Для начала можно его не ограничивать, наблюдая за пополнением. И начать регулярно проводить процедуру оценки актуальности задач в буфере: очень часто срочные задачи перестают быть срочными, а не выполненные становятся не актуальными, и нет никакого смысла сохранять их в буфере. И уже после этого вводить ограничения.

Начинать здесь стоит со срочных задач, и не только в буфере, а в целом на обработке, потому что практика показывает, что большое количество срочных задач, которых никто не учитывает, является основной причиной нарушения регулярной работы. Может показаться, что ограничение на срочные задачи – не реалистичное, потому что они часто выполняются по прямому поручениями руководства. Однако, если контролировать их и объяснять, что реально такое количество задач срочно выполнено точно не будет, и надо поставить реальные приоритеты, то получается конструктивный диалог. Практика показывает, что достаточно часто срочность оказывается ситуативной и теряет актуальность, а руководство забывает ее отменить. При этом выполнение в «пожарном режиме» того, что оказалось не нужным является очень сильным демотиватором. Отметим, что выполнение задач, которая стала не актуальной – один из примеров лишней работы, muda в lean.