Спасибо большое за ваш комментарий и вопросы. Действительно, может сложится впечатление, что некоторые статьи похожи друг на друга. В рамках Канбан-метода есть 6 основных групп практик, которые можно использовать для улучшения текущего процесса поставки ценности для клиента и/или для решения отдельных проблем. Предположу, что подход к реализации практик может быть похож, но может меняться контекст команд/организаций, последовательность действий при применении и масштаб эффекта.
В Канбан-методе применяется эволюционных подход. Практики направлены не только на получение определенных выгод, но и на повышение зрелости команд (Модель КММ). Обычно, в самом начале пути, команды находятся на "рассеянном" уровне зрелости, когда каждый сам за себя. Группа отдельных экспертов в своей области. Далее команда эволюционирует на "командоцентричный" уровень, когда приходит понимание, что нет "моих задач", а есть задачи команды. Все работают над тем, чтобы завершить задачи совместными усилиями с максимально возможной скоростью. Здесь появляются общие метрики потока: Какие задачи мы делаем? Как быстро? Сколько в штуках и какого типа задач мы делаем за промежуток времени? Сам подход не направлен на измерение отдельных людей и их производительности. Он направлен не на людей, а на процесс. Мы оцениваем возможности "сервиса", ищем узкие места в процессе, повышаем предсказуемость и равномерность поставки ценности. Конкретно для вас, как части команды, появится понимание как быстро и много делает вся команда, куда нужно приложить командные усилия, чтобы стало лучше. Из опыта: как только метрики в виде скорости или количества задач появляются в KPI - команды интуитивно начинают их читерить.
В моей практике был опыт построения рабочего процесса с буферными этапами в виде "Анализ" и "Анализ готов", "Разработка" и "Разработка завершена" и т.д. Команде интересно было показывать, на каком этапе скапливается работа и есть ли простои, особенно на этапах взаимодействия с другими командами и заказчиками. В последующем, мы использовали статистику "простоев" между этапами, чтобы аргументировано разрабатывать правила для приемки задач и общения с приемщиками, для разработки правил перехода задач из одного этапа в другой (DoD и DoR). Кроме того, можно получить дополнительную статистику по реальному времени выполнения задачи (touch time) и сравнить с общим временем выполнения задачи в вашем сервисе (lead time), а на выходе получить метрику эффективности потока (Flow efficiency). Про "нафиг всё это надо" мы объясняли через ценность, что мы можем получить на выходе, если начнем собирать эти цифры. Конкретный пример: У команды зависали задачи на приемке и было непонятно то ли команда долго копается, то ли заказчики долго реагируют. Когда собрали фактуру в виде метрик по буфферному этапу, то смогли договориться о новых правилах с заказчиками за сколько они должны принимать задачу, когда мы их уведомляем и т.д.
Чтобы бизнес не приносил "абсурдные идеи" мы стали применять по всей организации скоринговые модели, которые позволяют оценить реальную ценность от задачи. Стратегия организации даёт понимание основных метрик, на которые мы должны повлиять. Эти метрики мы заложили в параметры скоринга задач. После этого, все задачи выстроились в прозрачный список, где сверху - самое актуальное и ценное, а снизу - менее важное и недостаточно ценное для компании. Т.е. тут двухсторонние отношения по повышению прозрачности: заказчики показывают, что действительно важно, а исполнители - сколько они обычно делают и в какие сроки.
Спасибо за вопрос. Улучшение метрик связано не только с декомпозицией задач. Если обратить внимание на первый график, то видно, что половина ранее существующих задач была адекватного размера и не нуждалась в дополнительном редуцировании. Вторая же половина представляла из себя смесь задач непредсказуемого размера, различные иерархические сущности для хранения более мелких подзадач, забытые задачи без должного фокуса внимания на них. Именно на вторую группу и был направлен комплекс мер, включая декомпозицию.
Как Agile-коучи мы не только принимаем непосредственное участие в декомпозиции задач, но и централизованно определяем правила иерархии проектов в командах, а также мониторим корректность применения этих правил.
В нашей практике мы стараемся принимать решения и делать выводы исходя из накопленной информации и собранной фактуры. Мы работаем с потоком задач и его состав далеко не всегда однороден. Могут встречаться "легкие задачи", а могут быть и "тяжеловесные". Основная задача команды взять в работу самое ценное для организации независимо от размера.
Спасибо большое за ваш комментарий и вопросы. Действительно, может сложится впечатление, что некоторые статьи похожи друг на друга. В рамках Канбан-метода есть 6 основных групп практик, которые можно использовать для улучшения текущего процесса поставки ценности для клиента и/или для решения отдельных проблем. Предположу, что подход к реализации практик может быть похож, но может меняться контекст команд/организаций, последовательность действий при применении и масштаб эффекта.
В Канбан-методе применяется эволюционных подход. Практики направлены не только на получение определенных выгод, но и на повышение зрелости команд (Модель КММ). Обычно, в самом начале пути, команды находятся на "рассеянном" уровне зрелости, когда каждый сам за себя. Группа отдельных экспертов в своей области. Далее команда эволюционирует на "командоцентричный" уровень, когда приходит понимание, что нет "моих задач", а есть задачи команды. Все работают над тем, чтобы завершить задачи совместными усилиями с максимально возможной скоростью. Здесь появляются общие метрики потока: Какие задачи мы делаем? Как быстро? Сколько в штуках и какого типа задач мы делаем за промежуток времени?
Сам подход не направлен на измерение отдельных людей и их производительности. Он направлен не на людей, а на процесс. Мы оцениваем возможности "сервиса", ищем узкие места в процессе, повышаем предсказуемость и равномерность поставки ценности.
Конкретно для вас, как части команды, появится понимание как быстро и много делает вся команда, куда нужно приложить командные усилия, чтобы стало лучше.
Из опыта: как только метрики в виде скорости или количества задач появляются в KPI - команды интуитивно начинают их читерить.
В моей практике был опыт построения рабочего процесса с буферными этапами в виде "Анализ" и "Анализ готов", "Разработка" и "Разработка завершена" и т.д. Команде интересно было показывать, на каком этапе скапливается работа и есть ли простои, особенно на этапах взаимодействия с другими командами и заказчиками. В последующем, мы использовали статистику "простоев" между этапами, чтобы аргументировано разрабатывать правила для приемки задач и общения с приемщиками, для разработки правил перехода задач из одного этапа в другой (DoD и DoR). Кроме того, можно получить дополнительную статистику по реальному времени выполнения задачи (touch time) и сравнить с общим временем выполнения задачи в вашем сервисе (lead time), а на выходе получить метрику эффективности потока (Flow efficiency).
Про "нафиг всё это надо" мы объясняли через ценность, что мы можем получить на выходе, если начнем собирать эти цифры. Конкретный пример: У команды зависали задачи на приемке и было непонятно то ли команда долго копается, то ли заказчики долго реагируют. Когда собрали фактуру в виде метрик по буфферному этапу, то смогли договориться о новых правилах с заказчиками за сколько они должны принимать задачу, когда мы их уведомляем и т.д.
Чтобы бизнес не приносил "абсурдные идеи" мы стали применять по всей организации скоринговые модели, которые позволяют оценить реальную ценность от задачи. Стратегия организации даёт понимание основных метрик, на которые мы должны повлиять. Эти метрики мы заложили в параметры скоринга задач. После этого, все задачи выстроились в прозрачный список, где сверху - самое актуальное и ценное, а снизу - менее важное и недостаточно ценное для компании.
Т.е. тут двухсторонние отношения по повышению прозрачности: заказчики показывают, что действительно важно, а исполнители - сколько они обычно делают и в какие сроки.
Спасибо за вопрос. Улучшение метрик связано не только с декомпозицией задач. Если обратить внимание на первый график, то видно, что половина ранее существующих задач была адекватного размера и не нуждалась в дополнительном редуцировании. Вторая же половина представляла из себя смесь задач непредсказуемого размера, различные иерархические сущности для хранения более мелких подзадач, забытые задачи без должного фокуса внимания на них. Именно на вторую группу и был направлен комплекс мер, включая декомпозицию.
Как Agile-коучи мы не только принимаем непосредственное участие в декомпозиции задач, но и централизованно определяем правила иерархии проектов в командах, а также мониторим корректность применения этих правил.
В нашей практике мы стараемся принимать решения и делать выводы исходя из накопленной информации и собранной фактуры. Мы работаем с потоком задач и его состав далеко не всегда однороден. Могут встречаться "легкие задачи", а могут быть и "тяжеловесные". Основная задача команды взять в работу самое ценное для организации независимо от размера.
Мне еще нравится "Наука общения" Ванесса ван Эдвардс, тоже легко читается. За список спасибо