Привет! Меня зовут Петр Александров, я много лет работал руководителем проектов и занимался календарным планированием, достижением дедлайнов и координации работ во времени. Сейчас я лидер продукта «Портал метрик продуктовых команд» в SM Lab и работаю с продуктовыми agile-командами. Такие команды делают задачи не к определенному сроку, а по потоку.

Что это значит?

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

2. Есть только один источник задач — бэклог команды. Никто не может передать задачу в работу команде иначе, чем поместив ее в бэклог.

3. Задачи в бэклоге приоритезирует Product Owner (заказчик), а не команда.

4. В работу берется самая приоритетная задача из бэклога, и только после того, как обработана и передана дальше по потоку предыдущая задача. Нельзя принудительно заталкивать в поток задачу раньше, чем команда готова ее взять.

5. Завершение уже начатой задачи приоритетнее взятия в работу новой. Нельзя откладывать текущую задачу ради новой, пусть даже очень важной.

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

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

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

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

Из этого следует, что традиционное проектное управление сроками, когда исполнитель берет на себя ответственность за выполнение плановых сроков (дедлайнов), к продуктовым командам неприменимо: 

1. Команда не может управлять сроками взятия задач в работу, так как не управляет приоритетами задач в бэклоге.  

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

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

Дедлайны, антихрупкие практики и зависимости задач

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

Хорошая новость: продуктовые команды умеют уменьшать количество дедлайнов за счет использования "антихрупких" практик.

Давайте рассмотрим какой-то внешний, объективно обусловленный дедлайн: законодательный акт, «черную пятницу», или просто начало нового сезона. Плохая новость: проигнорировать такой внешний дедлайн нельзя, если, конечно, вы заинтересованы в успехе компании. Хорошая новость: объективных внешних дедлайнов немного, как правило, не более нескольких в год.

Примечание: если у некоторой компании есть полсотни клиентов и в текущих контрактах с ними прописаны две сотни дедлайнов – значит ли это, что у этой компании двести объективных внешних дедлайнов в год?  Может быть, да, но, скорее всего, их гораздо меньше. Большая часть из них, вероятно, относятся к типовым задачам, не связанным с созданием нового знания, поэтому их выполнение в срок не несет существенных рисков. Часть может быть добавлена заказчиками, «чтобы подрядчики не расслаблялись», и их можно постепенно снять путем создания более доверительных рабочих отношений. GT

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

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

Очевидное решение: повышение прочности системы – шестерни из легированной стали, подшипники из рубинов и бриллиантов и т.п… Для IT это может выражаться, скажем, в политике найма исключительно суперпрофессионалов, не допускающих ошибок (теоретически), без изменения общего подхода к разработке. Этот путь часто оказывается тупиковым не только по экономическим причинам и из-за нехватки суперпрофи, но потому, что не отменяет хрупкость системы. Частота сбоев может снизиться, но их последствия по-прежнему будут катастрофичными. Развитие такой системы будет трудоемким и рискованным –  проще заменить целиком, чем модернизировать по частям.  

Антихрупкость

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

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

Мы использовали такие практики и раньше, но «must have» они стали именно в связи с переходом к продуктовой разработке. Хотя продуктовые команды вряд ли часто задумываются о концепции антихрупкости, но без таких практик у них не получается построить равномерный и быстрый поток выполнения задач. Если у задачи есть жесткая связь с задачей в другой команде, то вы не можете взять ее в работу и быть уверенным, что сможете довести ее до конца своими силами, не дожидаясь другой команды. 

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

Если речь идет о двух задачах в двух командах, выгода не так очевидна – двум командам договориться все же не так сложно. Но при увеличении количества связанных систем сложность возрастает по степенному закону. Вот вам история в тему.

Давным-давно в одной хорошей компании существовало Большое Тестовое Окружение (БТО) – тестовая копия существенной части IT-ландшафта компании связанной, в основном, с товарным планированием. Его состав не был постоянным, но обычно оно включало несколько десятков IT-систем. Это окружение использовалось и для экспериментов, и для обучения, но главное – для тестирования изменений, затрагивающих «сквозные» процессы и приемки их заказчиками. Так как у команд разработки задач всегда было в избытке, интеграционное тестирование обычно предполагалось проводить сразу на БТО, так как там не нужно эмулировать смежные системы и наборы данных – там были копии реальных систем с реальными данными. 

Но для связанных изменений необходимо проносить изменения и тестироваться «все вдруг» - ведь на старых версиях смежных систем новый процесс не протестируешь.  Поэтому, путем длительных обсуждений со всеми заинтересованными, определялась дата Большого Интеграционного Тестирования (БИТ). Редко когда удавалось договориться на дату раньше, чем через полгода от начала переговоров – у каждой системы или бизнес области были свои непреодолимые ограничения. Когда эта дата, наконец, наступала, то почти всегда оказывалось, что кто-то не успел или случилось что-то непредвиденное. 

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

Завершить этот процесс обычно удавалось только после того, как команды изобретали на ходу пару программных «костылей», затыкающих самые крупные нестыковки. А устранение «костылей» планировалось выполнить к следующему БИТ, который «должен состояться не позднее чем через два месяца»…  Удивительно, но при этом всем еще обеспечивалась стабильная работа продуктивных окружений в режиме 24х7!  

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

Цена антихрупкости и бенефиты от нее

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

мы получим "пучок" задач, которые можно выполнять примерно одновременно.

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

Антихрупкость не бесплатна. Выполнение “цепочки задач” по затратам будет, скорее всего, эффективнее, чем “пучка задач”, с учетом доли затрат на внедрение «необязательных» технических практик, отказа от шаринга ресурсов и содержание постоянных продуктовые команд. Это похоже на ситуацию с авиабилетами: цена билета с двумя пересадками меньше, чем на прямой перелет, но все меняется, если опоздать на стыковочный рейс. 

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

Команда 1 сделала свое дело первой и занялась другими делами. Затем свою работу сделала команда 2. Когда за работу взялись команды 3 и 4, у них возникли вопросы к командам 2 и 1. Но участники команды 1 уже полностью погружены в другие задачи, для них обратное погружение в контекст – тяжелый и не мгновенный процесс. Часто оказывается, что за прошедшее время результат задачи 1 перестать соответствовать изменившемуся окружению и его надо переделывать. Этого не происходит, когда команды имеют возможность выполнять свои задачи примерно одновременно.

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

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

3 способа координации событий на примере общественного транспорта

Есть три способа координации событий во времени:

1. Календарное расписание

2. Сервис по запросу

3. Прозрачность и прогнозируемость

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

Человек стоит на остановке и ждет автобуса, еще надо зайти в аптеку, но отойти страшно, вдруг это последний автобус на сегодня, сколько еще ждать и успеет ли он в аптеку - непонятно. 

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

В наше время эта проблема решается при помощи интернет-сервисов. В современной Москве это, чаще всего, сервисы Яндекса (это факт, а не реклама). 

Рассмотрим три из них:

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

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

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

Этот прогноз выглядит очень похожим на расписание в Яндекс.Электричках, но есть важное отличие: в расписании электричек каждая строка – это дедлайн, обязательный для исполнения машинистом, а водитель автобуса даже не знает, что в 6:15 вы его ждете на вашей остановке. Он просто едет по маршруту в своем темпе, соблюдая ПДД. Тем не менее в 6:15 он, скорее всего, прибудет куда вам нужно.

В нашем случае вместо автобусов и пассажиров надо координировать выполнение задач продуктовыми командами. Все три перечисленных подхода применимы:

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

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

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

Отсюда вытекает, что прозрачность и предсказуемость развития –  важное свойство продукта. Оно не менее важно, чем качество и скорость разработки. Я несколько раз встречал примеры, когда повышение прозрачности, «открытие команды миру», существенно улучшало удовлетворенность заказчиков, даже без немедленного улучшения качества и скорости работы команды. В нормальной обстановке продуктовым командам выгодно быть прозрачными и предсказуемыми, чтобы работать в более комфортной среде, не выстраивая линий обороны. Командам необходимо прилагать сознательные усилия и внедрять практики, которые делают их работу прозрачнее, так же, как они прилагают усилия к улучшению стабильности и скорости своего потока и качества своего продукта. 

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

Прозрачность через визуализацию

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

1. Общая карта: дает общий контекст – например, карта Москвы, на ней мы наблюдаем движение интересующих нас объектов.

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

3. Метрики: например, расстояния и баллы пробок на карте Москвы – это основа для построения объективных прогнозов.

Подходит ли на роль наглядной визуализации Канбан-доска команды? 

На первый взгляд, да. Есть доска с колонками, есть задачи, которые движутся по ней, их можно типизировать по десятку признаков, можно посмотреть на метрики – CFD диаграмму или control chart, например. Исходя из них можно оценить скорость движения задач и сделать прогноз.  

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

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

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

Общая карта 

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

На этом уровне нас не интересует устройство потока команд, которое все равно у всех разное, как пассажира не интересует устройство мотора автобуса - едет, и слава Богу. Поэтому мы упростим эту схему, отобразив только основные области:

Карта жизненного цикла состоит из областей и специальных точек, расположенных на их границах. Точки на границах обозначаются для удобства, с логической точки зрения достаточно было бы обозначить только области. Но в обсуждении проще сказать «ТПО», чем «левая граница области «Поток». Задачи, как правило, проходят области ЖЦ слева направо, последовательно. Правее области «Поток» есть еще область продуктивного использования, но мы сейчас ограничимся задачами визуализации и прогнозирования движения задач от идеи до установки на продуктив, поэтому самую правую область «Продуктивная эксплуатация» на нашей карте не отображаем. 

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

Точка Принятия Решения (ТПР) и область «Решили делать»: пересечение ТПР означает, что задача достаточно полезная и приоритетная и на нее можно начинать тратить ресурсы команды. Задачи в области выстроены по приоритетам,  приоритизация не строгая, в основном упорядочена «верхушка» области – несколько наиболее приоритетных и проработанных задач, которые скоро перейдут в следующую область. Проработка означает уточнение смысла и ценности задачи, первичное, примерное, проектирование, выявление и «снятие жесткости» внешних связей, декомпозиция до примерного размера задач, которые пригодны для выполнения в потоке команды. В случае отбраковки или понижения приоритета задачи ее выносят обратно в область идей или удаляют. 

Область «Готово к взятию (в поток)»: для левой границы этой области нет устоявшегося названия, поэтому назовем ее пока точкой «Х». Эта область содержит «короткий бэклог» команды – задачи, уже полностью готовые к взятию в работу и расположенные по приоритетам (для SCRUM команды – это план текущего и следующего спринтов). В эту область переносятся задачи, удовлетворяющие критериям Definition of Ready (DoR), индивидуальным для этой команды, с «допусками», также определяемым командой. В частности, оценка размера задач не должна превышать предельную для взятия в поток для этой команды (первичная декомпозиция происходит до пересечения точки «Х»). Отбраковка или понижение приоритета задачи на этом этапе также возможны. 

Точка Принятия Обязательств (ТПО) и «Поток»: Название Точка Принятия Обязательств подчеркивает, что команда принимает ответственность за реализацию задачи только в момент начала работы над ней в потоке – до этого момента заказчик имеет право передумать. Настройки процессов потока и допотоковой проработки задач направлены на то, чтобы, попав в поток, задачи двигались равномерно, без задержек и возвратов по потоку.  

Точка Исполнения Обязательств (ТИО): новая функциональность пронесена на окружение промышленной эксплуатации и доступна пользователям. Мы ограничимся этим и не будем здесь рассматривать оценку реальной пользы от выполненной задачи и замыкание цикла обратной связи от пользователей.

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

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

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

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

Типизация задач

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

Типизация задач и эпиков одинаковая. Всего выделяем четыре вида:

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

Технические задачи: важные и нужные задачи, влияющие на надежность и возможности развития системы, но результаты которых не видны конечным пользователям напрямую и не могут быть ими объективно оценены. Отдача технического долга команды обычно также типизируется как техническая задача. Чтобы техническая задача появилась в бэклоге и ее можно было взять в работу, команде надо доказать ее необходимость и полезность Product Owner-у.

Эксплуатация: полезные для бизнеса задачи, но, как правило, не связанные с изменением программного кода и функциональности системы. Сюда попадают всяческие загрузки/выгрузки/очистки данных, заведение новых объектов и справочников и прочие операции, до автоматизации которых еще не дошла очередь, поэтому их делают «руками». 

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

Отношения между типами задач примерно следующие:

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

На технические задачи, по согласованию с Product Owner, отводится некоторый процент средней мощности команды, чаще всего от 10 до 25%. Это, с одной стороны, дает возможность поддерживать технологическую актуальность продукта и не зарасти техдолгом, а с другой - не дает команде увлекаться техническими усовершенствованиями ради технических усовершенствований. Результат технических задач конечный пользователь не может увидеть самостоятельно, поэтому для него и труднее оценивать объективную ценность. 

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

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

Продуктовые эпики обычно бывают только бизнес и технические.

В большинстве команд задачи по эксплуатации и устранению дефектов – небольшие по трудозатратам, они гораздо меньше, чем бизнес и технические. Их часто берут в поток не через бэклог, а сразу, по мере появления, по отдельному swimlane. С учетом того, что заказчиков и смежников обычно интересуют только бизнес и технические задачи, эксплуатацию и устранение дефектов можно не отображать на нашей визуализации. Их наличие будет учитываться «кумулятивно и неявно», как фактор, отъедающий некоторый % мощности команды и, соответственно, замедляющий скорость движения бизнес и технических задач по потоку. Примерно так в Яндекс Транспорт отображается движение остальных машин, кроме общественного транспорта - как баллы загруженности дорог, а не как движение отдельных экипажей.

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