Читайте канбан справа налево: как команде накапливать и использовать знания

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

Процесс накопления знаний нелинеен

Процессы, связанные с информацией, почти никогда не движутся линейной цепочкой «раз и навсегда». Возьмём знакомый сценарий – команда ищет разработчика.

На идеальной схеме всё просто:

1. HR публикует вакансию и собирает отклики;

2. менеджер просматривает резюме и отбирает тех, с кем стоит пообщаться;

3. кандидаты приходят на интервью.

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

Берите на заметку. Любое накопление знаний – это не эстафета, а сеть параллельных веток. Это нормально. Важно уметь это увидеть.

Чем тут помогает визуализация времени

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

• Диаграмма Ганта даёт возможность выстроить зависимости: что от чего зависит, куда подключать людей, где узкие места и паузы.

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

Зачем вообще нужна канбан-доска

В офисной среде работа не видна: час назад человек сидел за ноутбуком – и через час он там же.

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

В офисе такой роскоши нет, поэтому и появилась потребность в визуальном эквиваленте умственного труда.

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

Ещё один важный момент – буферные состояния. Между «Аналитикой» и «Разработкой» есть промежуток «Готово к разработке». Он необходим, чтобы фиксировать готовность и не терять факты: когда закрыли анализ, почему разработка не стартовала, что мешает переходу. В этих небольших промежутках спрятано много управленческой правды.

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

Почему не стоит гонять карточки взад-вперёд

Типичная ситуация: тестирование обнаружило дефект. По инерции карточку отправляют назад в «Разработку». Выглядит логично, но у этого подхода есть минус – мы теряем исторический след. Кажется, будто задача снова стартует «с нуля», хотя на самом деле в неё уже вложены время и деньги.

Лучше заводить блокер – заметную метку поверх текущей карточки. Она не передвигает работу по колонкам, а подсвечивает место, где мы споткнулись. Что указывать в блокере:

• суть проблемы (что именно не так);

• когда именно возникла блокировка и когда её сняли;

• кого нужно подключить для решения (роль/команда, а не только имя).

Такой подход помогает сохранять контекст и видеть, где именно задача застопорилась: в тестировании, на ревью, в ожидании данных, из-за доступа или инфраструктуры.

Чтобы понять логику, представьте учебный пример. Школьник решает задачу, но ему не хватает темы, которую он пропустил год назад. Он не возвращается «учиться с нуля», он точечно закрывает пробел. Блокер – именно про это: не перемещать работу назад, а обозначать конкретное препятствие и ликвидировать его.

Как это работает в TEAMLY

Мы добавили в базу знаний Тимли инструменты, которые помогают отмечать, приоритезировать и анализировать такие ситуации:

• Статусы и теги на карточках: задайте правило, что «красный» – это блокер, а «жёлтый» – риск.

• Сроки и просрочки: система подсветит, где вышли за рамки.

• Ответственные: понятна роль, которая снимает блокировку.

• Автоматизация через «Создать правило»: при появлении просрочки карточка автоматически получает тег блокера и сигнал тимлиду.

• Сортировка и фильтры: одним кликом собираете все проблемные карточки по отделам, периодам или типам блокеров.

• Диаграммы: видно, какие препятствия «съели» больше всего времени и как это сказалось на сроках.

Два ключевых эффекта от блокеров

1) Честная приоритезация. Когда блокер «горит» на карточке справа (там, где уже пройдено больше пути), задача не конкурирует с лёгкими «новичками» слева. Мы не обесцениваем вложенные ресурсы. Полезное правило: начинаем день с обхода доски справа налево – закрываем то, куда уже вложились сильнее всего.

2) Больше не «люди-колонки». Частая беда – каждый живёт в своей колонке: тестировщики – в «Проверке», аналитики – в «Аналитике», разработчики – в «Разработке». Блокеры ломают жёсткие границы: аналитик может подключиться на этапе теста, разработчик – помочь на стадии анализа, если там всплыл риск. Команда видит единый процесс, а не набор изолированных лотков.

Не удаляйте блокеры – превращайте их в базу рисков

Блокер – это не «стыдный след», а сработавший риск. У каждого риска есть два параметра: вероятность и последствия. Если проблема задерживает выпуск на пять дней и случается десятки раз в год, бессмысленно каждый раз «клеить заплатку». Нужна системная реакция.

Как это делать на практике:

• Сохраняйте все блокеры, не стирайте историю после снятия.

• Периодически пересматривайте массив: раз в квартал/полгода собирайте статистику.

• Классифицируйте: внутренние (процессы, договорённости, навыки) и внешние (инфраструктура, интеграции, зависимость от других отделов).

• Смотрите на время решения: какие препятствия пожирают недели, а какие снимаются за часы.

• Отслеживайте частоту: множество одинаковых блокеров – сигнал к системным изменениям (регламент, доступы, шаблоны, чек-листы, автоматизация).

Цель – перейти от «ретроспективной косметики» к инженерному подходу: собрали данные → нашли повторяющиеся причины → приняли архитектурное решение (процедура, сервис, правило, SLA, обучение).

Накопление знаний – это ещё и анализ того, как они появляются

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

1. Сделать процесс видимым (доска, таблица, буферы).

2. Фиксировать препятствия (блокеры, роли, сроки).

3. Автоматизировать реакцию (правила, уведомления, эскалации).

4. Периодически извлекать метрики (частота, длительность, источник).

5. Принимать системные решения (процессные правки, изменения в архитектуре, обучение).

TEAMLY поддерживает все звенья этой цепочки – от быстрых тегов и сортировок до правила «первым делом смотрим вправо» и визуальных отчётов, по которым видно, где именно сгорает время.

Маленькие практики, которые дают большой эффект

• Единый язык меток. Договоритесь о понятных тегах: блокер, риск, внешняя зависимость, ожидание. Уберите лишнее, оставьте 5–7 реально используемых.

• Буферы – не мусорная колонка. Чётко определите критерии «готовности к следующему этапу»: что именно должно быть на входе, чтобы работа смело автоматизированно переходила дальше.

• Дежурство по правому краю. Каждый день начинайте с правых колонок: что мешает выпустить работу, кого нужно подключить, какие блокеры снимаем сегодня.

• Данные важнее впечатлений. «Кажется, мы часто ждём доступы» – слишком размыто. Проверьте цифры: сколько раз за месяц, среднее время, кто владелец решения.

• Системное обучение. Повторяющиеся блокеры – сигнал к микрокурсам, чек-листам, шаблонам артефактов. Знания не только копятся, но и возвращаются в процесс в виде готовых инструментов.

Вместо финала

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

А теперь интересно именно ваше мнение: какие идеи из подхода Пименова вы готовы протестировать первыми, и какие блокеры чаще всего встречаются у вашей команды?

Используйте инструменты TEAMLY, чтобы управлять рабочими процессами

Записывайтесь на онлайн-презентацию! Продемонстрируем интерфейс и все возможности платформы

Получить демо