Мы используем файлы cookie. Продолжив работу с сайтом, вы соглашаетесь с Политикой обработки персональных данных.
OK

Визуализация работы — Часть 1: Делаем актуальную работу видимой

Перевод статьи Fernando Cuenca, размещённой на squirrelnorth.com. Оригинал можно прочитать здесь. Вы решили создать доску, чтобы сделать работу вашей команды видимой: что на ней должно быть и как это должно быть представлено? Первую статью из этой серии читайте по ссылке.
Моделируйте разные виды работы по-разному
Первый ключ к ответу на эти вопросы можно получить, наблюдая, откуда взялись различные части работы. Скорее всего, вы обнаружите, что работа была выполнена разными людьми или группами (включая саму команду) и что она отвечает разным потребностям и ожиданиям. Кроме того, правила или этапы обработки, применимые к различным частям работы, могут значительно различаться.

Сейчас команды нередко называют свою работу «историями», часто не делая между ними особых различий. Если называть всё «историями», то есть опасность, что это скрывает всё это разнообразие, а также побуждает команду относиться ко всему одинаково, однородно. Позже это затрудняет суждения о работе, потому что вы вынуждены использовать очень большой общий знаменатель для вещей, которые по сути очень разные.

Итак, начните с признания того, что работа бывает разной: поймите различные типы ваших рабочих элементов, а затем найдите способы сделать их визуально разными. Использование цветов — распространённая практика для достижения этой цели, но возможны и другие варианты, такие как использование тегов, стикеров различной формы или отдельных строк на доске.
Если вы отойдёте и посмотрите на свою доску со стороны, сможете ли вы чётко увидеть (и различить) разные виды «запросов», над которыми вы работаете?
Направляйте внимание на распознаваемые результаты для клиентов
Ещё одно важное наблюдение: то, что вы визуализируете, будет сильно влиять на то, о чём вы будете говорить, когда будете вести обсуждения перед доской (например, во время ежедневного стендапа).

Когда доски содержат в основном задачи по реализации, то обсуждения, как правило, направлены внутрь, а не на клиента. Более того, эти задачи часто связаны с конкретными людьми. В будущем это приведёт к тому, что обсуждение будет сосредоточено на выполнении индивидуальных задач, а не на результатах команды. Всё это можно смягчить, визуализируя только «распознаваемые клиентами» результаты (т.е. «запросы, которые клиенты ожидают от команды, выраженные в знакомых им терминах).

Если большая часть вашей работы сегодня выражается в терминах задач по реализации, этот совет не следует интерпретировать как призыв скрыть эту работу. Скорее, я бы посоветовал вам отследить распознаваемый результат клиента, который породил эти задачи по реализации (очень возможно, объединение нескольких задач в один внешний результат) и визуализировать их.
Если вы отойдёте и посмотрите на свою доску со стороны, сможете ли вы чётко увидеть (и различить) разные результаты, над которыми работает ваша команда?
Обратите внимание на дизайн тикета
Большинство команд визуализируют свою работу, создавая стикер для каждого элемента, а затем записывают на нём название элемента. Часто добавляется дополнительная информация, например идентификатор из системы отслеживания, данные по оценке или кто работает над тикетом. Однако дизайну самого тикета уделяется не так много внимания.

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

Возможно, следует отметить, что цель не в том, чтобы использовать доску в качестве источника документации. Я видел, как команды пытались разместить слишком много информации в своих тикетах (например, подробные описания, критерии приёмки и т. д.). Этот уровень детализации лучше хранить в цифровом виде в вашей системе отслеживания или других базах знаний, используя тикеты для отражения информации, необходимой для принятия решений и самоорганизации.

Хороший пример — практика отображения списка чекбоксов с типичными внешними зависимостями, которым подвергается работа в данный момент. Чекбоксы указывают, действительно ли зависимость необходима для данного конкретного элемента, и была ли она уже выполнена или нет. С помощью этой информации член команды может решить, кого ещё необходимо привлечь к выполнению этой части работы, можно ли её вообще начинать сейчас или нет и т. д.
Эта практика может быть расширена ещё больше, чтобы отразить этапы процесса, ограничения и другие решения. Например, представьте, что вы работаете в команде, которая разрабатывает приложение, используемое в нескольких географических регионах. Приложение разрабатывается постепенно, при этом разные регионы получают новые функции в разные моменты времени, в зависимости от их потребностей и других ограничений локального развёртывания. В большинстве случаев конкретную сборку можно безопасно развернуть в местах, где не требуются содержащиеся в ней новые функции. Но в других случаях необходимо проявлять особую осторожность, чтобы НЕ развёртывать некоторые сборки в некоторых местах, поскольку локальные несовместимости сделают приложение непригодным для использования. Когда команда планирует релиз, ситуация анализируется, и список на тикете обновляется, чтобы отразить сделанные выводы и решения.
Если вы отойдёте и посмотрите на тикеты на своей доске со стороны, сможете ли вы чётко увидеть информацию о каждой части работы, как о значении, так и о статусе, а также для принятия обоснованных решений?
Сделайте блокеры заметными и запоминающимися
Ещё одна распространённая практика — помечать заблокированные элементы маленьким красным стикером. Практика имеет очевидное преимущество, т.к. направляет внимание на работу, которая по какой-то причине перестала двигаться.
Следующий шаг состоит в записи дополнительной информации о блокере: дата возникновения блокировки и причина. Если ставить точки на тикете за каждый день, когда наклейка с блокером остаётся на доске, это даст визуальное представление о том, как долго блокер остаётся на месте. Это поможет команде принимать решения о расстановке приоритетов, эскалации и т. д.

Если все эти «стикеры блокеров» собираются с течением времени, вы можете использовать их в качестве входных данных для «Кластеризации блокеров», а это может привести к лучшему пониманию и управлению источниками задержек в вашем процессе.
Если вы отойдёте и посмотрите на свою доску со стороны, сможете ли вы чётко увидеть, какая работа остановилась, как долго она была заблокирована, и что требует немедленного внимания?
Эту тему мы разбираем на тренингах:
Четырехдневный онлайн-курс
Kanban System Design
Расширенный курс по построению систем управления с дополнительными материалами и проработкой большего числа кейсов и вопросов. Курс будет полезен для менеджеров проектов, топ-менеджеров и менеджеров среднего звена, которые хотят провести изменения постепенно, избежать сопротивления и повысить эффективность работы команды в сложных условиях.
Шестидневный онлайн-курс
Extended Kanban System Design
Расширенный курс по построению систем управления с дополнительными материалами и проработкой большего числа кейсов и вопросов. Курс будет полезен для менеджеров проектов, топ-менеджеров и менеджеров среднего звена, которые хотят провести изменения постепенно, избежать сопротивления и повысить эффективность работы команды в сложных условиях.