Недавно я рассказывал вам про Kanban: вижу, формат зашёл. Решил сделать шпаргалку — пригодится коллегам и всем, кто хочет разложить проект по полочкам.
Для успешной работы с канбан-доской достаточно изучить несколько простых принципов. Рассказываю о них в статье.
Правило 1. Отражайте на доске реальный процесс работы
Самая частая ошибка — универсальные статусы вроде «В работе» и «На проверке». Они не показывают, что реально происходит с задачей.
Например, проект по редизайну сайта выглядит так: сбор требований → прототип → дизайн → согласование → правки → передача в разработку. Значит, такими же должны быть колонки на доске.
Если в проекте есть фрилансер — логично вынести это в этап «У фрилансера». То же самое про задачи в ожидании: если задача не у исполнителя (ждёт руководителя, клиента, подрядчика) — это отдельный этап, а не «В работе».
Критерий простой — по колонке должно быть понятно:
на каком этапе задача,
кто за неё отвечает,
что нужно сделать, чтобы она перешла дальше.
Правила 2. Добавляйте на доску задачи примерно одного размера
Когда начинаешь работать с канбаном, возникает соблазн перенести на доску вообще всё. В итоге рядом оказываются задачи разного веса, и по доске невозможно понять реальный темп работы.
Поэтому карточки должна быть сопоставимы по объёму работы, то есть примерно одинаковые по трудозатратам и времени закрытия.
Если задача заметно больше остальных — разбивайте на подзадачи. Если задача слишком маленькая — ей не место на доске.
Вот как выглядит сбалансированная канбан-доска:
Правило 3. Фиксируйте понятные точки старта и финиша по задаче
В канбане эти границы называют Commit Point и Delivery Point. Это не отдельные статусы, а договорённость команды, зашитая в структуру доски.
Commit Point — точка, в которой задача официально берётся в работу: понятно, что именно ну��но сделать, назначен исполнитель и можно начинать без уточнений. На доске Commit Point — это переход карточки из бэклога в первую рабочую колонку.
Если Commit Point не зафиксирован, задачи уезжают в работу сырыми: по ходу появляются уточнения, переделки и срывы сроков.
Delivery Point — точка, в которой задача считается завершённой и результат можно использовать. Например, для разработки — это выкатка в прод, для поддержки — закрытое обращение клиента.
Если Delivery Point не определён, задачи закрывают «по ощущению»: формально готово, но по факту результата ещё нет.
Правило 4. Назначайте ответственного за задачу
Это человек, который ведёт её целиком: добавляет исполнителей в карточку, следит за движением по колонкам и контролирует сроки. Если этап подвисает, ответственный тегает исполнителя, чтобы понять, в чём проблема.
В карточке задаче должен быть один ответственный.
Правило 5. Определяйте критерии готовности
Задача должна иметь хотя бы верхнеуровневое ТЗ. Даже если она простая, у того, кто её ставит, всё равно есть представление о результате и какие-то минимальные требования к нему. Их нужно сразу зафиксировать в карточке, иначе задача будет дорабатываться снова и снова.
Пример: руководитель ставит задачу «собрать презентацию для встречи». В этом можно написать что-то вроде:
не больше 10 слайдов,
с цифрами по KPI за прошлый квартал,
оформление в корпоративном стиле,
в формате PDF.
Правило 6. Двигайте карточки сразу
Канбан-доска должна быть продолжением вашей руки. Сделали шаг по задаче — тут же отразили это на доске. Вы не работаете отдельно в задаче и отдельно с доской — это один процесс.
То же правило должно быть у команды. Это вопрос не удобства, а дисциплины: канбан не должен восприниматься как «дополнительный сервис для отчёта». Пока карточка не сдвинута, считается, что шаг по задаче не зафиксирован. Тогда доска остаётся точным отражением того, что происходит в работе.
Правило 7. Делайте приоритеты видимыми
По одному взгляду должно быть понятно, какие задачи сейчас срочные и важные. Для этого визуализируйте приоритеты с помощью тегов, цветов или других меток, чтобы доска читалась без открытия карточек.
Правило 8. Управляйте потоком задач
Это правило нужно, когда задач в работе становится слишком много и они начинают зависать. Например, в отделе снабжения обрабатывают заявки на закупку: компьютеры, мебель, расходники. В колонке «В работе» одновременно лежит 20 заявок. Сотрудники прыгают между ними, часть задач «почти готова», но ни одна не закрывается быстро.
Чтобы этого не происходило, в используйте два инструмента: WIP-лимиты и pull-подход.
WIP-лимиты ограничивают, сколько задач может одновременно быть в работе. Например, в колонке «В работе» — не больше пяти карточек. Это заставляет команду сначала заканчивать начатое, а не открывать всё сразу. При этом лимит должен отражать реальную пропускную способность команды — универсального числа тут нет.
Если лимит в колонке превышен, вы увидите уведомление
Pull-подход означает, что новую задачу берут только тогда, когда освободилось место. Сначала завершают текущую, потом вытягивают следующую из бэклога.
На практике эти инструменты нужно вводить постепенно. Сначала можно просто отслеживать нагрузку и давать команде право выбирать следующую задачу.
Правило 9. Улучшайте процесс через метрики
Канбан опирается на принцип постоянных улучшений. Поэтому при работе с доской имеет смысл контролировать основные метрики, чтобы понимать, почему сроки растут, почему задач много, а результата мало, и что именно в процессе стоит менять.
Вот на что смотреть и как интерпретировать:
WIP (Work in Progress) — сколько задач сейчас находится в работе.
Например, в отделе снабжения одновременно в работе 12 заявок на закупку. Когда ограничили «В работе» до 6 задач, заявки начали закрываться быстрее, потому что сотрудники перестали вести всё параллельно и стали доводить задачи до конца.
Lead time — сколько времени проходит от появления задачи до её завершения, то есть время «от запроса до результата».
Например, заявку «Купить ноутбук» создали 1 апреля, а закрыли 10 апреля — lead time составил 9 дней. Если сам ноутбук покупают за 2 дня, значит остальное время задача просто ждала, пока до неё дойдут.
Cycle time — сколько времени задачу реально делают: с момента, когда её взяли в работу, и до завершения.
Например, ту же заявку взяли в работу 8 апреля и закрыли 10 апреля — cycle time составил 2 дня. Если cycle time маленький, а lead time большой, значит задачу делают быстро, но берут в работу слишком поздно.
Throughput — сколько задач команда закрывает за период (день, неделю, месяц). Это показатель стабильности работы.
Например, бухгалтерия обычно закрывает около 40 счетов в день, а на этой неделе — 25. Значит либо задачи стали сложнее, либо в процессе появился дополнительный этап, который замедляет работу.
Метрики удобно отслеживать в таск-трекере. Например, так выглядит отчёт в системе YouGile.
Теперь вы знаете правила работы с канбан-доской. Последняя мысль: настраивайте процесс постепенно. Если пока сложно с лимитами и объёмом задач, отложите их. И начните с простого: разбивки проекта по колонкам, оформления карточек и дедлайнов. Тогда поток задач не нарушится, команда сохранит ориентиры, а метрики будут работать вам в плюс.
Система управления проектами YouGile доступна бесплатно для команд до 10 человек — без ограничений по функциям и времени.
