Портал №1 по управлению цифровыми
и информационными технологиями

Оценка важности задач в Канбан-методе

В редакцию портала поступил вопрос:

Есть ли у канбан инструменты для оценки бизнес-эффекта от поставленной задачи? Бывают случаи, когда заказчики начинают наращивать функционал, который команде представляется не самой нужной для конечного пользователя и Компании. Например, излишняя отчётность. После смены заказчика (переживали не раз) функционал будет не востребован.

«Kanban Flow Metrics: управление потоковым производством на основе данных»
Тренажёр про метрики на реальных примерах

Комментариев: 1

  • Светлана Сапегина

    Чтобы дать более полный ответ, этот вопрос стоит разделить на несколько составляющих. Первый важный момент, который надо обозначить – метод управления процессом ИТ-разработки на основе Канбан говорит не о наращивании функциональности, а о создании ценности. Это важное понимание, которое лежит в основании того, как Канбан подходит к управлению работой.
    Если деятельность не создаёт ценности – это потери, от которых нужно избавляться. Такая деятельность может быть полезной, или нет, но она не является основной для сервиса, обслуживающего поток создания ценности.
    Это означает, что наращивание функциональности ради функциональности, без понимания того, какая ценность при этом создаётся, пустой процесс. Фокусировка должна быть на ценности, и её проявление начинается с того, что сам заказчик это понимает. Создание ценности процесс, который всегда начинается в бизнесе и заканчивается в бизнесе, поскольку только так можно оценить, действительно ли ценность была создана. Команда ИТ-разработки обслуживает только часть этого процесса, непосредственно поток задач, направленных на создание ценности.
    И это приводит нас ко второй важной части вопроса: команда, обслуживающая поток создания ценности, хочет соучаствовать в принятии решений вместе с заказчиком. Это очень хорошая тенденция.
    Зачастую, формулируя запрос, бизнес заказчик ставит задачу без понимания того, какую ценность хочет получить. Он отвечает на вопрос «что нужно сделать?» и не ставит вопрос «для чего это нужно сделать?». Если команда ИТ-разработки принимает задачу к исполнению, не интересуясь ценностью, велика вероятность, что она будет выполнять работу, на поверку оказывающуюся бесполезной.
    Команда должна быть клиентоориентированной, но при этом фокусироваться на ценности. И фокусировать на ней бизнес-заказчика. Простые вопросы о том, как идея должна функционировать в физической среде, для кого это делается, кто будет пользоваться и с какой интенсивностью, какую проблему позволяет решить – помогают перейти от формулировки запроса на разработку, к постановке и донесении ценности создаваемого решения.
    И зачастую формулировка ценности помогает самому бизнес-заказчику увидеть простые и быстрые решения, ведущие к получению такой же ценности без изменения функциональности. Если ценность может быть получена без лишней работы – это прекрасно! И так же нередко возникают ситуации, когда в процессе проявления предназначения, выясняется, что существующая функциональность способна полностью или частично решить проблему.
    Канбан-метод говорит о том, что между бизнес-заказчиками и сервисом, обслуживающим поток создания ценности, должны существовать правила совместной работы, фокусирующие постановку задач через понятие ценности. Задача, в которой ценность не описана явна, не может быть принята в работу, под ответственность сервиса. Бизнес должен её доработать.
    Но в вопросе есть ещё один немаловажный момент, касающийся востребованности решения. И эта ситуация, которая может возникнуть даже тогда, когда ценность сформулирована и реализована. Но не будет востребована, если это сделано невовремя.
    Дело в том, что чаще всего запрос от бизнес-заказчика проводит некоторое время в ожидании очереди на выполнения. Он должен быть приоритизирован и иметь прогнозные сроки реализации, но это не 100% защита от того, чтобы потерять востребованность.
    Мир бизнеса очень быстро меняется. И при этом он довольно жёсткий, иерархичный, построенный на рангах и согласованиях. Для того, чтобы в физической среде произвести перестройку бизнес-процессов, требуется соучастие большого количества людей. Это сложный, иногда длительный процесс.
    Поэтому Канбан-метод выстраивает дополнительную защиту на входе в поток создания ценности, от задач, доставка ценности которых не возможно в данный момент. Для этого служит собрание по пополнению с участием бизнес-заказчиков.
    Зачастую команды, обслуживающие поток создания ценности, уклоняются от соучастия бизнеса в их встречах. Им кажется, что в этом нет смысла, особенно когда бизнес информируется о прогрессе в решении задач, т.е. цикл обратной связи выстроен через другие каналы связи. При этом проблемы на выходе – долгое внедрение решений, отказ от уже реализованной функциональности и т.п. – никак не связываются с дисфункцией на входе – отсутствием согласования того, что мы принимаем в работу прямо сейчас.
    Бизнес-идея может сохранять ценность для бизнеса, может даже быть по-прежнему в первом приоритете, но если бизнес не готов реализовать её на своей стороне, то она зависнет на выходе, без подтверждения исполнения обязательств, подтверждения поставки ценности. Потому что не было фиксации соглашений на входе, что эта ценность востребована именно сейчас, что её приоритет не изменён, что бизнес ждёт и будет готов её принять в физической среде, нет барьеров, блокирующих её поставку.
    Чем более явно и оперативно будет выдано такое подтверждение, тем меньше вероятность того, что работа сервиса не будет сделана напрасно. Канбан-метод рекомендует использовать собрание по пополнению в том числе и для проверки блокеров со стороны бизнеса, которые не известны команде, обслуживающей поток создания ценности, и для оперативной переприоритизации задач в случае.
    Соблюдая эти несложные рекомендации: фокусироваться на ценности, фиксировать ценность в постановке запроса от бизнеса в явном виде и подтверждать востребованность реализации через собрание по пополнению, можно избежать ненужной работы по созданию бесполезной функциональности.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
;