Канбан-метод

"Мы выбираем, нас выбирают
Как это часто не совпадает"
(с) песня из к/ф Большая перемена

Всем привет! С вами рубрика Agile Shorts и сегодня мы с вами поговорим о "Предназначении".

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

В широком применении эти стороны, это, конечно же, Потребители (клиенты, заказчики) и Продукты (услуги, сервисы, товары). О них и пойдет разговор в сегодняшней статье.

Поговорим о Потребителях

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

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

• Зачем мне хлеб?

• Какой хлеб я хочу?

• Когда он мне нужен?

• Сколько сил я готов потратить на его получение? (Как сильно он мне нужен?)

Если вы себе задаёте другие вопросы, то вы предвосхитили мой следующий тезис другие люди задают себе другие вопросы.

С другой стороны, в разных ситуациях, я отвечаю на свои вопросы по-разному. Рассмотрим пару ситуаций:

Первая ситуация: Дома кончился хлеб

• Зачем мне хлеб? Люблю есть бутерброды

• Какой хлеб я хочу? Белый, мягкий

• Когда он мне нужен? Как можно быстрее, хочу попить чаю с бутерами

• Сколько я готов потратить на его получение? Денег немного. Сил максимум, дойти до угла дома

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

Вторая ситуация: жду гостей, накрываю на стол

• Зачем мне хлеб? Чтобы гости были довольны

• Какой хлеб я хочу? Злаковый, необычный, чтобы подчеркнуть заботу о гостях

• Когда он мне нужен? В течение четырех часов, я не спешу

• Сколько я готов потратить на его получение? Так как заказываю нечасто, готов потратиться на доставку.

Здесь я буду сравнивать по ингредиентам, отзывам, соотношению цена-качество.

Что мы видим? Один и тот же человек в разной ситуации может отвечать на свои же вопросы по-разному, и покупать продукт разного качества. В экономике это называется сегменты рынка. Этим размышлением я хочу подчеркнуть, что один и тот же человек в разных ситуациях может быть целевой аудиторией совершенно разных сегментов рынка. Его потребности меняются.

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

Поговорим о продуктах

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

Чтобы уйти от этой проекции, существуют разные инструменты исследования клиентского опыта CustDev, CJM, Persona Много разных. Это замечательные методы, которые помогают выйти из своих иллюзий и приблизиться к пониманию, что действительно хотят клиенты.

Лично мне нравится активно набирающий популярность продуктовый фреймворк F4P (Fit for purpose). Я о нем впервые услышал всего год назад, и с тех пор вижу, что его начинают использовать всё больше и больше людей.

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

Например, если спросить людей, как они выбирают ноутбуки, то ответы могут распределиться по таким критериям (по популярности):

• Приятный на ощупь

• Лёгкий

• Цвет нравится

• Хорошо смотрится у меня на столе

• И так далее...

Как видно, тут нет тактовой частоты процессора, количества USB-портов или механизма крепления клавиатуры. Это всё "под капотом" для несведущего пользователя. Хотя, несомненно, и на эти параметры найдется свой потребитель.

А вспомните теперь, по каким параметрам смотрят на успешность продаж товара маркетологи и продуктологи?

• PnL

• NPS

• Конверсия посетителей в покупатели

• Количество продаж за период

Эти показатели не видны пользователям. Совершая покупку, никто не смотрит на конверсию или PnL. Эти показатели реактивные, они показывают, что уже что-то случилось, что отразилось на их изменении, но не говорят, что именно. И нам надо еще потратить время и деньги, для того, чтобы только понять, что случилось.

Такие показатели фреймворк F4P называет показателями здоровья продукта, а для наблюдения за клиентским опытом рекомендует другие параметры показатели соответствия (fitness criteria).

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

• Скорость доставки важно для тех, кто заказывает еду, когда проголодается.

• Предсказуемость (точно в срок) например, точность прибытия транспорта. Важно для тех, кто планирует маршрут с пересадками.

• Совмещаемость с другими продуктами важно для тех, кто любит комбинировать что-то.

• Скорость реакции поддержки для тех, кто готов смериться с посредственным качеством, но готов компенсировать это помощью в настрой.

Что же главное при работе с fitness criteria? Важно следующее:

1. Найти их!

2. Сегментировать рынок на их основе выбрать свою целевую аудиторию в соответствии с нашими возможностями удовлетворять этим критериям.

3. Наблюдать за тем, не изменились ли критерии соответствия со временем.

Выбор критериев соответствия

В заключение своего рассказа, я расскажу один из алгоритмов, как можно вычислить fitness criteria. Для этого фреймворк F4P предлагает инструмент, который называется F4P Card.

F4P Card это анкета обратной связи, которая содержит три раздела: цели, удовлетворенность, объяснение. Ниже, я привожу пример, как это может выглядеть, например, для этой статьи. А если вы в комментариях ответите на эти вопросы, то, возможно, я напишу вторую статью на тему соответствия предназначению, где проведу анализ и сегментирование на основе вашей реальной обратной связи.

Итак, F4P Card для вас:

1. Напишите, пожалуйста, несколько целей, с которыми вы прочитали эту статью.

2. Для каждой из целей пункта 1, оцените, пожалуйста, насколько ваша цель была удовлетворена? Где:
   A намного превзошло ожидания
   В превзошло ожидания
   С в пределах ожидания
   D ниже ожидания
   E полностью не соответствует цели

3. Для каждой из оценок пункта 2, объясните, пожалуйста, вашу оценку.

Спасибо за внимание!

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

Начну, пожалуй, с подходов к обучению.

Обучение Канбану. Канон

Самыми полными и каноничными курсами по погружению в Канбан-Метод по праву считаются классы, которые разрабатывает Канбан Университет структура Дэвида Андерсона, автора метода.

У Университета сейчас в наличиичетыре(ну, хорошо, пять) больших теоретическихмодуля, постепенно погружающих в профессию,и два смежных, позволяющих еще шире взглянуть на работу и совершенствование сервиса.

Прямая линейка:

• TeamKanbanPractitioner(можно пропустить, это популярная выжимка основных вещей для первичного погружения в тему)

• Kanban System Design

• Kanban System Improvement

• Kanban Maturity Model

• Kanban Coaching Practices

Смежная линейка:

• FitforPurpose(раскрывает тему продуктового управления и работы с клиентом)

• EnterpriseServicePlanning(стратегическое планирование и управление организацией)

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

Минус, как ни странно, это Эволюция.

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

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

Расположение возвратного гортанного нерва у жирафа

То же самое случилось и с подачей материала Канбан Университетом. Вначале, когда метод только развивался, всю имеющуюся информацию Дэвид Андерсон структурировал в небольшой доклад, с которым ездил по профильным конференциям. Когда информации стало больше, появился тренинг и книга Kanban: Successful Evolutionary Change for Your Technology Business (на русском перевели как Канбан. Альтернативный путь в Аджайл).

В дальнейшем, линейка тренингов пополнилась вторым классом. Потом третьим, четвертым, ответвлениями. Но структура подачи материала почти не пересматривалась на первом тренинге сейчас преподают то же самое, что и десять лет назад, хотяконтекст(любимое слово Канбан-практиков) многократно поменялся.

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

В итоге, грамотно оперировать материалом можно только отучившись на всех курсах, получив (и усвоив) всю имеющуюся информацию, набрав большое количество практики применения, и пройдя эволюцию восприятия метода.

Другие тренинги. Свой лунный модуль

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

Одной из самых популярных баек на эту тему является история, как Хенрик Книберг краем глаза на конференции подсмотрел за лекцией Дэвида Андерсона, взял пару идей и выразил свое понимание в небольшой книге, которая у нас вышла под названием Скрам и Канбан. Выжимаем максимум. В этой книге Эрик сравнивает эти два фреймворка, радостно нацепив на себя первое из многих когнитивных искажений при восприятии Канбан-метода.

Существуют и другие адаптации идей, описанных Андерсоном, под локальные контексты тренеров и консультантов. Ихосновной минус часто неглубокое понимание авторами предметной области, выливающееся в догматы, которые работают только при определенных условиях, и искажающее обывательское представление о мощи и применимости инструмента.

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

Работа консультантов. Обучение через работу

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

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

Плюсытакого подхода прикладная польза для решения конкретных проблем.

Минусы в будущем проблемы могут быть другими и текущие практики не сработают.

Несколько советов, с чего начать

Как выбрать свой путь в постижении Канбана? Для этого я бы рекомендовал сначала определиться с целью. Рассмотрим две крайности получить академические знания и решить проблемы в производстве.

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

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

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

Персональный Канбан

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

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

Персональная канбан-доска

Также, можно посмотреть на практики категоризации и приоритизации потоковой работы.

Канбан для отдела

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

На какие практики я бы рекомендовал обратить внимание при такой работе?

Основная это, конечно, визуализация. Визуализация жизненного цикла задачи отдела. Здесь есть разные варианты визуализации работы, для начала можно обратить внимание на такие практики как агрегированный персональный Канбан или командный Канбан.

Агрегированный персональный Канбан

Персональные ограничения незавершенной работы (персональныеWIP-лимиты) тоже неплохо работают в виде ограничений на дорожки при агрегированном командном канбане или в виде аватарок при командном канбане.

Также, при визуализации работы рядом появляется необходимость обсуждать эту работу с тему, кто ее делает, и тут можно обратить внимание на практики проведения планерок.

Канбан для команды

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

Отличительная особенность команды:

• Общий результат

• Общая оценка результатов работы

• Размытие зон ответственности в смежные области для уменьшения точек передачи информации (в отличие, например, от при передаче её через функциональные отделы, где эта самая информация часто теряется)

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

Для более зрелой команды, когда в коллективе есть уже понимание общего результата, а объектом управления выступает уже не элементарная задача, а нечто, что понимает Заказчик, можно использовать практики разделения потоков работ и визуализации правил командной работы. В частном случае сделать попытку оценить количество задач в работе (смотря глазами Заказчика когда он считает, что задача уже в работе) и ограничить это число с точки зрения не должно быть в системе задач, до которых у нас руки не дошли в предыдущий отчетный период почитать, что такоеCONWIP-ограничение.

Командная канбан-доска

У командной работы, также, появляется предрасположенность к совместному обсуждению проблем в процессе и возможность улучшить свою работу. Введение практики регулярных ретроспектив помогает выстроить процесс совершенствования производства. (Да, да, это не ошибка ретроспектива тоже используется в Методе как одна из практик.)

Канбан для Владельца продукта

Еще один взгляд на работу взгляд человека, который отвечает за развитие и вывод на рынок продукта. В современном мире такого человека называют Владельцем продукта. Мышление этого уровня уже предполагает менеджерский подход к управлению. Его должны волновать взаимодействия с потребителем, ответы на вопросы что нужно делать уже сейчас, что потом?, кому нужен продукт?, а то ли это, что нужно клиентам?, а удобно ли пользователям получать продукт в то время, когда мы поставляем, и в том виде?.

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

Для определения цепи поставки уже стоит провести воркшопSTATIK(systemthinkingapproachtointroduceKanban, описан в книге Майка Барроуза Канбан-метод: улучшение системы управления)

Визуализация всего потока поставки

Менеджеру для широкого применения Канбан-методу, я уже рекомендую посетить первые два тренинга из основной линейки Канбан Университета, а также ответвлениеFitforPurpose, на которых обратить особое внимание на следующие инструменты:

• Объект управления чем именно нужно управлять Владельцу продукта, чтобы процесс поставки ценности был управляем и контролируем

• Группировка сходных типов работ (Фильтры, Цветовая дифференциация, Дорожки, Колонки)

• Фокус на поставке и Визуализация прогресса поставки - как именно изобразить процесс поставки, чтобы Канбан-визуализация служила системой раннего предупреждения о проблемах с поставкой?

• Управление рисками поставки. Проблема в поставке проблема менеджера, Метод дает широкий инструментарий для управления риском: визуализация блокировок; визуализация буферов и очередей; выявление источников проблем; ретроспективы и обзоры поставки

• Upstream-процесс. Процесс поставки начинается не с написания Технического задания, а с некоего предпроцесса, когда идея потихоньку оформляется в задачу. Проверка гипотез и воронка опций вполне себе процессы, которыми можно управлять, используя инструменты Канбан-метода.

• Метрики прогресса: T2MиLeadTime метрики, помогающие прогнозировать сроки; Fit for Purpose criteria продуктовыеметрики; пропускная способностьпроизводственной системы

Канбан для менеджера-проекта

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

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

В отличии от жизненного цикла проекта на управлении которым акцентированы популярные средства управления проектами, Канбан-визуализация должна фокусироваться на жизненном цикле производства элемента продукта и отвечать (например для ИТ-проекта) на вопрос Что нужно сделать, чтобы вывести этот кусок функциональности в Продуктив?

Канбан для управления портфелем проектов

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

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

А остальным что делать?

Почти все случаи, которые я описал выше, для решения своих насущных проблем могут обойтись ограниченными практиками, в них не обязательно погружаться глубоко в механики Канбана. Однако, начиная с менеджерского состава, который вовлечен в производство результатов умственного труда, я бы всем рекомендовал пройти три из четырех модулей Канбан Университета (KSD,KSI,KMM) и ответвлениеFitforPurpose. Причем, проходить их не подряд, а с промежутком на применение полученных знаний на практике, так как сама текущая механика обучения подразумевает прохождение эволюции восприятия инструментов Метода.

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

Удачи всем в совершенствовании собственной работы!

Я и мои коллеги по работе для внутренних сотрудников компании, в которой я работаю, периодически готовим небольшие статьи, где разбираем различные кейсы по гибким подходам, включая и кейсы использования Канбан-метода для совершенствования и управления процессами. Такие статьи мы называем "Agile-shorts". И я подумал, "А почему бы не открывать свои статьи и для более широкой аудитории?" И, вот, сегодня я публикую первую свою статью из этой серии.

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

Мало кто, работающий в ИТ-сфере, не слышал про гибкие подходы к созданию продуктов. Слова Agile, Kanban, Scrum уже крепко проникли в лексикон современных компаний. Кто-то их произносит с гордостью, кто-то с иронией, а кто-то сквозь зубы.

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

Но эта заметка не для них. Эта заметка для вас, тех, кто понимает, что инструменты можно использовать по-разному, а на ошибках готов учиться.

Ограничиваем Пользовательские Истории, а работаем с Подзадачами

Часто, познакомившись с основами практик и методов, которые используются в Agile-культуре, у людей складывается впечатление, что, нажав Ctrl+C и Ctrl+V, они у себя получат ту же замечательную вещь, которую они увидели в учебном кейсе. На деле же оказывается, что Ctrl+V приходится, как в анекдоте, тщательно дорабатывать напильником.

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

В итоге, на одном уровне управления можно встретить такие задачи:

• Сделать MVP Продукта - задача имеет ценность для Заказчика, так как пользователь получит в руки что-то, что может начать использовать.

• Провести нагрузочное тестирование не самостоятельная задача, а нужна для прогресса какой-то другой

• Заключить контракт с поставщиком ХХХ не самостоятельная задача, а нужна для старта работ по другой задаче

• Реализовать функционал голосового ввода пользователь получит новый функционал для использования

Так причем же тут WIP-лимиты?, спросите вы. Так вот, новички часто начинают применять этот инструмент на таком, типичном для многих, контексте. Ограничили, надеются, что работы пойдут быстрее, а в итоге, почему-то, получается всё наоборот - работы встают, все запутываются.

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

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

Что же делать, спросите вы? Ответ в том, чтобы разделить разные уровни управления и понимать, какую проблему мы решаем.

Какие бывают уровни:

• Работа на уровне исполнения задач одним человеком.

  • Для снятия перегруза с сотрудника используются персональные лимиты. В этом случае рассматриваются взгляд исполнителя на задачи смотрят со стороны сотрудника, который выполняет работу.

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

  • лимиты на систему/команду/сервис (Бэклог спринта частный случай лимита на систему)

  • лимиты на тип задач (Квотирование)

  • лимиты на этап (работа с узкими горлами)

  • и другие, более экзотические типы ограничений

В этом случае нужно смотреть на задачи глазами Заказчика работ. Появляется такой объект как Customer recognizable item задача, смотря на которую, Заказчик понимает, что это именно то, что он заказывал, и видит, что происходит с заказом.

• Работа на уровне портфеля

  • Для эффективного распределения ресурсов для реализации портфеля инициатив, используются лимиты на объекты портфеля.

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

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

• Попробуйте понять, для чего нужен инструмент, и в каком контексте он работает

• Осознайте проблему, которую вы хотите решить применением инструмента

• Если что-то не получается, допустите, что это не инструмент плох, а есть что-то, что вы не учли

И тогда, разочарование от того, что мы потратили кучу времени, а оно не работает, вас обойдет стороной.