Каждый, кто работал в команде, которая сталкивается с большим количеством требований заказчиков и стейкхолдеров, наверняка испытывал ощущение нарастающего хаоса и постоянного аврала. Как следствие — постоянные конфликты между разработчиками и бизнес-подразделениями, измотанность команды.
Отличным инструментом по улучшению процессов служит Kanban метод. С одной стороны, он делает все процессы и всю работу явной, прозрачной, а с другой — вносит ограничения в процесс (в виде одновременно выполняемой работы), которые контролируют количество задач в работе и фокусируют команду на завершении.
Какие ключевые мысли несет метод?
1. Перестать давать ложные обещания. Вместо этого проанализируйте пропускную способность. Давайте обещания только в момент, когда берете задачи в работу, на основе статистики о времени выполнения. Например, вы точно сможете сказать, когда вы спуститесь, только в тот момент, когда вы вошли в лифт, на основании знания статистики о среднем времени спуска. Но пока вы стоите в очереди, при том, что очередь постоянно меняется, вы не сможете давать объективных прогнозов. Либо вам придется эти прогнозы постоянно переделывать и тратить на это уйму времени.
2. Выстраивайте заказчиков в очередь. Невозможно все задачи принять и пообещать сделать и выполнить это обещание. Если заказчики внутренние, дайте им возможность договориться, какие задачи следующими пойдут в работу на основе вашей пропускной способности и бизнес-ценности каждой задачи. Дайте им инструмент приоритизации.
Если заказчики внешние, оцените, от каких задач вы можете сейчас отказаться. Примите как данность, что вы все равно не сделаете абсолютно все. Договоритесь, что, например, раз в неделю вы готовы выбрать по 3 новые задачи, а заказчики должны договориться, какие именно.
3. Запомните, что чем больше задач в работе, тем больше занимает время их выполнения. Поэтому не стремитесь взять больше (это объясняет Закон Литтла). Для этого в Kanban методе зашиты WIP лимиты (ограничение одновременно-выполняемой работы), которые выставляются на основе пропускной способности этапов и всей системы в целом. Также важно учитывать, что пропускная способность системы равна ее самому узкому месту в системе. То есть лимиты выставляйте исходя из пропускной способности ее самого узкого места, иначе задачи будут простаивать в очередях и их количество будет расти, увеличивая общее время выполнения всей задачи.
4. Начните управлять работой. Чтобы управлять, нужно понимать, что есть в работе, поэтому стоит всю работу визуализировать (например, с помощью доски) и далее каждый день собираться и смотреть: «Что подвисло?» «Что выполняется?», «Где нужна помощь?» и так далее.
5. Начните считать метрики поставки. Достаточно будет считать время выполнения каждой задачи и пропускную способность, чтобы получить распределение и дать объективные прогнозы по времени выполнения новых задач. По распределению времени выполнения вы сможете увидеть, за какое количество времени завершалось 90% задач, и это вам даст данные для прогнозирования. То есть вы сможете дать объективную оценку заказчику, сказав, что задача будет выполнена до Х дней с 90% вероятностью. Точность такого прогнозирования будет зависеть от того, какое количество данных вы успели накопить, поэтому дайте этому время.
6. Договоритесь о том, что запустите процесс регулярных улучшений, изменений, на основе ретроспектив и объективных метрик. Увидели проблему — собрались, подумали, как ее решить, как минимизировать простои, как расширить узкое горлышко. Не стоит улучшать все подряд. Сфокусируйтесь на самом узком месте в системе и начинайте планировать шаги по его расширению.
