Обзор книги “Визуализируйте работу” (“Making Work Visible”)

Уже давно прочитал отличную и главное простую книгу про улучшение рабочих процессов, главная мысль которой вынесена в название. Эта короткая и яркая книга может служить введением в Kanban подходы, которое на пальцах показывает их пользу. Эта простота и наглядность зашла мне до такой степени, что я решил написать краткое саммари … полгода назад. Вот год почти подошел к концу и я все-таки это сделал:)

Рис.1 “Обложка книги”

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

Рис.2 “Содержимое книги”

Этот знаменитый ироничный закон Паркинсона дает понять почему планирование работы с буферными запасами проблема.
Но если планировать работу задач на команду в режиме push, то можно столкнуть с тем, что требования к командам и их производительность не сбалансированы, что не позволяет выполнить все задачи вовремя. В итоге, нам нужна система с pull режимом, когда люди вытягивают новую задачу по мере завершения предыдущей. Такой системой, например, является Kanban. Но важно понимать какие задачи попадают в такой процесс — важно не соглашаться на все подряд, а обдуманно давать добро только на самые важные в конкретный момент и делать это визуально. Для этого надо организовать систему рабочего потока, выполняющую следующие задачи

Рис.3 “Задачи рабочего потока”

Для построения такой системы отлично подходит рассматриваемая книга. И начнем мы изучение этого источника знаний с первого пункта, а именно с

Пяти расхитителей времени

Первый и самый важный расхититель

Слишком большой объем незавершенных дел

или кратко WIP (Work In Progress). Кстати, для меня этот пункт — тоже самая большая боль.

Казалось бы говори чаще НЕТ и будет меньше дел, но не все так просто. Есть ряд причин почему мы соглашаемся на дополнительную работу

Рис.4 “Почему мы соглашаемся на дополнительную работу”

Теперь давайте обсудим почему большой WIP настолько плох, с этим нам поможет Литтл, который сформулировал свой закон в теории массового обслуживания, который в упрощенной форме звучит так

Где время цикла (cycle time) — это время, что задача проводит в статусе незавершенных работ (время от поступления до завершения задачи), а пропускная способность (throughput) — это количество работ, выполненных за определенный промежуток времени.

Чтобы понять насколько проблема с большим WIP относится к вам взгляните на картинку ниже и оцените есть ли у вас эти симптомы.

Рис.5 “Симптомы кражи времени большим WIP”

Следующий расхититель

Неизвестные зависимости

Автор выделяет следующие типы зависимостей

Рис.6 “Типы зависимостей”

Про архитектурные зависимости можно прочитать в статье с обзором “Clean Architecture” (Часть II: принципы дизайна модулей и разделения по компонентам). Навыки людей тоже страдают от этого типа расхитителя времени, особенно если работа требует навыков узкоспециализированных специалистов, которые часто бывают перегружены такими запросами и ждать от них помощи приходится долго. Аналогично происходит с изменениями, которые находятся вне поля нашего контроля. Зависимости опасны тем, что повышают вероятность опоздания.

Чтобы понять насколько проблема актуальна для вас взгляните на картинку ниже и оцените есть ли у вас эти симптомы.

Рис.7 “Симптомы кражи времени неизвестными зависимостями”

Неизвестные зависимости — коварная штука, особенно в век twopizza teams. Если такие маленькие автономные команды организовать в-лоб, то можно получить необходимость в больших межкомандных усилиях, которые нужны для координации их совместной работы. Может сложиться ситуация, что маленькие команды отдельно работают быстро, но организация в целом — медленно. Следующий пункт

Незапланированная работа

Незапланированная работа крадет время у запланированной. Этим она делает систему непредсказуемой, а главное для нас — это прогнозируемость и ожидания. Конечно иногда незапланированной работы не избежать, но … мы можем запланировать квоту времени на незапланированную работу (почти оксюморон). Кроме того, важно визуализировать незапланированную работу, над которой мы работаем и собирать статистику, которая позволит планировать такой тип работы. Дальше на повестке

Конфликтующие приоритеты

Если все задачи приоритетные, то ни одну из них нельзя назвать реально важной. Без внятных приоритетов людям приходится пытаться сделать слишком много сразу, что автоматически приводит к росту WIP, который замедляет всю систему.

Данная проблема актуальна для вас, если вы слышите от людей фразы навроде приведенных ниже

Рис.8 “Симптомы кражи времени конфликтующими приоритетами”

Или постоянно ходите на встречи, где обсуждается важность задач. Кроме одинаково максимально важных задач еще бывает

Заброшенная работа

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

Кроме того, важно уметь убивать проекты, на которые были потрачены силы, но которые уже не несут ценности и живут только из-за того, что людям присуща ошибка невозвратных потерь (sunk cost fallacy).

Дальше мы переходим ко второй части, в которой обсуждается

Как выявить расхищение времени, чтобы оптимизировать рабочий процесс

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

Как визуализировать работу

Первым примером приводится иллюстрация Филиппа Крачтена, крутого эксперта в архитектуре, на которой он показал отличия зримой и незримой работы

Рис.9 “Категории задач”

А вот базовая Kanban доска для отображения задач может выглядеть так

Рис.10 “Базовая Kanban-доска”

Часто возникает вопрос, а что должно попадать на такую доску — это зависит от типа работы и основных проблем. Также важно показывать на этой доске неопределенности, которые влияют на команду. Часто на доску не попадают маленькие задачи (условно 15-минутные), но их стоит добавить на доску, если выполняется один из следующих пунктов

Рис.11 “Когда маленькие задачи стоит выносить на доску”

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

  • Получить их поддержку и сократить WIP, так как при его игнорировании команда будет перегружена, как следствие cycle time будет увеличиваться и соседние команды будут ждать результата все дольше
  • Воспринимать рабочий процесс системно и оптимизировать его не только локально в своей команде, но и во всех связанных командах

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

  • Это позволяет убедиться, что категории и workflow соответствуют потребностям и требованиям всей команды
  • Когда люди участвуют в создании чего-либо, у них появляется чувство ответственности и мотивация для достижения результата

В книге также приведен пример карточки и атрибутов, которые она должна содержать. Мне это пример кажется очевидным, поэтому идем к следующей главе

Засада на главаря

Вы поймете, что у вас проблемы со слишком большим WIP, если для вас актуально что-то с изображения представленного ниже

Рис.12 “Симптомы слишком большого WIP”

Слишком большой WIP является основной проблемой и усиливает эффект остальных расхитителей времени. Нам надо контролировать WIP и если мы уже визуализировали работу на доске, то мы можем установить WIP лимиты: по колонкам, по единицам работы, по дорожкам (swimlines). Ограничения WIP создают давление в системе и позволяют людям закончить работу перед тем, как приступить к следующей:) Визуализируя работу и подсвечивая лимиты вы улучшаете коммуникации и понимание в команде.

Выявить зависимости

Есть такая говорящая фраза для этого расхитителя времени

Для отслеживания зависимостей можно использовать матрицы, как приведенная ниже. На ней отображены компоненты/фичи и по строкам и по столбцам. По строкам мы фиксируем входящие зависимости, а по столбцам исходящие. Значение на пересечении отображает вес зависимости.

Рис.13 “Матрица зависимостей между компонентами”

Запущенность истории с зависимости зачастую зависит от походов, которые использовались при создании системы. Если команда работала в проектном подходе и дальше была распущена для старта нового проекта, то это одна ситуация. Для достижения проекта в срок проектной команде часто приходится чем-то жертвовать, а значит велика вероятность того, что зависимостями никто не занимался — все равно это будет проблемой команды эксплуатации. Если же над системой работала продуктовая команда, которая остается с продуктом пока он приносит ценность, то ситуация зачастую иная. Я рассказывал про это отличие в статье “Про управление проектами”

Идеальное преступление — незапланированная работа

Незапланированная работа является проблемой, но мы можем с ней бороться и вот варианты

Рис.14 “Способы борьбы с незапланированной работой”

Приоритеты, приоритеты, приоритеты

Отсутствие четких приоритетов и понятного способа приоритизации — это большая проблема, так как не ясно в каком порядке работать над задачами, что приводит к слишком большому WIP. Существует несколько подходов к приоритизации и вот они

Рис.15 “Способы приоритизации”

Помимо приоритизации важно понимать как на доске выглядит линия обязательств — на рисунке ниже она визуализирована на базовой Kanban-доске, которая расширена дополнительной колонкой Variants.

Рис.16 “Базовая Kanban-доска с линией обязательств”

Как избежать заброшенной работы

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

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

Метрики, обратная связь и обстоятельства

И начнем с первой главы этой части

Метрики и деньги

Метрики нужны для того, чтобы выстроить внятные ожидания для клиентов. Без этого клиенты всегда жалуются, что работа идет слишком долго и нет никакого прогресса по их запросам. Если собрать правильные метрики, то эту проблему можно побороть.

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

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

Одной из основных метрик является время потока, которое показывает сколько времени заняло выполнение задачи от начала и до конца (это же время цикла). Для этой метрики существует закон Литтла, про который мы говорили выше и который выглядит так

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

Рис.17 “Допущения закона Литтла”

Есть пряма связь между объемом WIP и загрузкой производственных мощностей (capacity utilization) — чем больше утилизация, тем выше время ожидания, особенно в изменчивых областях навроде IT. Глубже про это можно прочитать в теории очередей и конкретно в формуле Кингмэна, которая связывает коэффициент использования мощностей и длину очереди, а следственно время ожидания в ней. Формула выглядит как-то так

И это можно визуализировать как представлено ниже.

Рис.18 “Визуализация этой формулы”

Следующий момент посвящен тому, что надо следить за работой, а не людьми. Если слишком много времени уделяется эффективности ресурсов, а не рабочего потока, время растрачивается впустую. Эффективность потока считается так

Важно обращать внимание на время ожидания, а не процесса. В итоге, появляются вопросы каким должен быть размер задач для поставки и что считать оптимальным сроком. Есть два фактора:

  • Отложенная обратная связь и отложенный выпуск продукта — это упущенная выгода
  • Определенные расходы связаны с транзакцией и координацией

Тут нужно уметь находить баланс.

Диаграмма расхитителей времени

Такая диаграмма достаточно проста — WIP можно увидеть прямо на доске. А остальное можно увидеть если специально разметить задачи по категориям: незапланированная работа, неизвестные зависимости, конфликтующие приоритеты, заброшенная работа. А дальше можно строить тренды и отслеживать как меняется ситуация.

Обзор операций

Если требуется понять как идут дела можно ориентироваться на следующие метрики

Рис.19 “Метрики для обзора операций”

Искусство встреч

Для эффективных стендапов надо задавать правильные вопросы, например, такие как указаны ниже

Рис.20 “Вопросы для эффективных стендапов”

Зверские практики

Существует набор практик, которые скорее являются антипаттернами и их использование сомнительно. Автор приводит их для того, чтобы читатели знали об их опасностях

Рис.21 “Антипаттерны в мире практик”

Этим набором антипаттернов заканчивается книга и напоследок автор рассказывает про важность согласованности работы технических и бизнес команд. Мне нравится фраза автора

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

Рис.22 “Трудности новых методов”

А вот что может сбиться с курса

Рис. 23 “Препятствия на пути к новым методам”

В общем, описанные выше подходы помогут улучшить рабочие процессы и преодолеть препятствия. Но перед стартом улучшений прочитайте оригинальную книгу:)

--

--

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Alexander Polomodov

Alexander Polomodov

1.6K Followers

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.