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

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

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

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

«Kanban-метод: практика построения быстрого потока»
Учебный курс, основанный на опыте консалтинга

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

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

    Чтобы дать более полный ответ, этот вопрос стоит разделить на несколько составляющих. Первый важный момент, который надо обозначить – метод управления процессом ИТ-разработки на основе Канбан говорит не о наращивании функциональности, а о создании ценности. Это важное понимание, которое лежит в основании того, как Канбан подходит к управлению работой.

    Если деятельность не создаёт ценности – это потери, от которых нужно избавляться. Такая деятельность может быть полезной, или нет, но она не является основной для сервиса, обслуживающего поток создания ценности.

    Это означает, что наращивание функциональности ради функциональности, без понимания того, какая ценность при этом создаётся, пустой процесс. Фокусировка должна быть на ценности, и её проявление начинается с того, что сам заказчик это понимает. Создание ценности процесс, который всегда начинается в бизнесе и заканчивается в бизнесе, поскольку только так можно оценить, действительно ли ценность была создана. Команда ИТ-разработки обслуживает только часть этого процесса, непосредственно поток задач, направленных на создание ценности.

    И это приводит нас ко второй важной части вопроса: команда, обслуживающая поток создания ценности, хочет соучаствовать в принятии решений вместе с заказчиком. Это очень хорошая тенденция.

    Зачастую, формулируя запрос, бизнес заказчик ставит задачу без понимания того, какую ценность хочет получить. Он отвечает на вопрос «что нужно сделать?» и не ставит вопрос «для чего это нужно сделать?». Если команда ИТ-разработки принимает задачу к исполнению, не интересуясь ценностью, велика вероятность, что она будет выполнять работу, на поверку оказывающуюся бесполезной.

    Команда должна быть клиентоориентированной, но при этом фокусироваться на ценности. И фокусировать на ней бизнес-заказчика. Простые вопросы о том, как идея должна функционировать в физической среде, для кого это делается, кто будет пользоваться и с какой интенсивностью, какую проблему позволяет решить – помогают перейти от формулировки запроса на разработку, к постановке и донесении ценности создаваемого решения.

    И зачастую формулировка ценности помогает самому бизнес-заказчику увидеть простые и быстрые решения, ведущие к получению такой же ценности без изменения функциональности. Если ценность может быть получена без лишней работы – это прекрасно! И так же нередко возникают ситуации, когда в процессе проявления предназначения, выясняется, что существующая функциональность способна полностью или частично решить проблему.

    Канбан-метод говорит о том, что между бизнес-заказчиками и сервисом, обслуживающим поток создания ценности, должны существовать правила совместной работы, фокусирующие постановку задач через понятие ценности. Задача, в которой ценность не описана явна, не может быть принята в работу, под ответственность сервиса. Бизнес должен её доработать.

    Но в вопросе есть ещё один немаловажный момент, касающийся востребованности решения. И эта ситуация, которая может возникнуть даже тогда, когда ценность сформулирована и реализована. Но не будет востребована, если это сделано невовремя.

    Дело в том, что чаще всего запрос от бизнес-заказчика проводит некоторое время в ожидании очереди на выполнения. Он должен быть приоритизирован и иметь прогнозные сроки реализации, но это не 100% защита от того, чтобы потерять востребованность.

    Мир бизнеса очень быстро меняется. И при этом он довольно жёсткий, иерархичный, построенный на рангах и согласованиях. Для того, чтобы в физической среде произвести перестройку бизнес-процессов, требуется соучастие большого количества людей. Это сложный, иногда длительный процесс.

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

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

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

    Чем более явно и оперативно будет выдано такое подтверждение, тем меньше вероятность того, что работа сервиса не будет сделана напрасно. Канбан-метод рекомендует использовать собрание по пополнению в том числе и для проверки блокеров со стороны бизнеса, которые не известны команде, обслуживающей поток создания ценности, и для оперативной переприоритизации задач в случае.

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


Добавить комментарий для Светлана СапегинаОтменить ответ

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
    • 5 основных тенденций развития искусственного интеллекта и машинного обучения на 2022 год
      Вот несколько основных тенденций, к которым вашему бизнесу стоит начать готовиться. Искусственный интеллект и машинное обучение становятся доминирующей частью технологической
    • 6 тенденций в ИТ, за которыми нужно следить
      Чтобы выжить во время пандемии, организации обратились к ИТ, чтобы помочь справиться с последствиями - как негативными, так и позитивными. В некоторых отраслях, таких как телемедицина и видеоконференции, бизнес резко вырос, и ИТ-отделам таких компаний пришлось в спешке справляться с нагрузкой. В других, например, в сфере путешествий и развлечений, бизнес резко просел. Кроме того, возобновилось стремление к цифровой трансформации.
    • Восход Desktop-as-a-Service: что это такое и зачем вам это нужно?
      Широкое распространение облачных вычислений добавило в наш словарь множество сокращений, наиболее распространенными из которых являются SaaS, PaaS и IaaS. Действительно, наступила эра облачных решений, которые доставляют программное обеспечение, платформу и инфраструктуру потребителям и предприятиям по запросу и с оплатой по мере использования.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT