Минусы и ограничения Kanban 😂 Никогда не думал, что буду писать про минусы Kanban, но на конференции (когда я рассказывал про Kanban) мне задали такой вопрос. Давайте попробую ответить.

Отсутствие чёткого таймбокса Нет спринтов (ужас) → сложно планировать релизы, если нужен фиксированный ритм. Для команд, которые привыкли к "sprint-goal, sprint-done" — может быть непривычно и даже тревожно. Кому больно: продуктовым менеджерам, которым нужен план на ближайшие 2 недели.

Сложно оценить производительность "в моменте" Без накопленных данных метрики работают хуже. Нужно время, чтобы набрать историю, увидеть закономерности, строить прогнозы. Кому больно: тем, кто хочет сразу видеть impact от изменений.

Риски перегруза без WIP-лимитов Без строгих WIP-ограничений команда может тащить слишком много задач одновременно. Кажется, что "работа кипит", а по факту — всё стоит. Типичная ловушка: "Ну давай ещё одну задачку в «In Progress»".

Низкая мотивация без целей Нет цели спринта → меньше чувства завершённости. Команда может чувствовать себя как белка в колесе, если нет точек празднования побед. Как лечить: добавлять review-моменты, ретро.

Может стать “Task Zoo” Если не поддерживать порядок, доска превращается в хаос: 100500 задач в “To Do” старые задачи не закрываются дубли, баги, техдолг — всё валится в одну кучу Лекарство: регулярный груминг + правила “что мы сюда вообще кладём”. ++ Не для всех ролей прозрачен++ Стейкхолдерам без контекста сложно понять: где прогресс? когда релиз? Kanban хорош для команды, но требует превращать поток в репорты для внешних глаз. Как спасаться: генерировать отчёты, выжимки, дашборды для бизнеса.

🧠 Бонус: Культурные проблемы Команды, привыкшие к командно-контрольной модели, могут сопротивляться «самоорганизации». Без культуры ответственности и доверия Kanban может развалиться в «ничего не понятно — и никто не отвечает».

Теперь вы знаете про минусы и можете их победить, значит Kanban у вас станет еще лучше 🔥