5. Менеджер проекта проверяет прохождение тестирования.

6. Менеджер проекта планирует показ демоверсии высшему руководству.

7. Если топ-менеджер хочет, чтобы команда внесла изменения, то руководитель проекта проводит анализ влияния изменений, функция возвращается в пункт 1 и по порядку двигается к пункту 8.

8. Функция выполнена и включена в следующий релиз.

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

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

Рис. 9.3. Эта канбан-доска представляет более точную картину того, как протекает проект

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

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

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

Рис. 9.5. Канбан-доска делает потери более очевидными, когда вы видите, что в течение рабочего процесса они встречаются несколько раз