Типичная ситуация для банка и любой крупной компании в целом – бизнесу требуется сложный и большой программный продукт для обслуживания клиентов, выбирается сложная и большая платформа, проводится тендер по результатам которого выбирается крупный известный подрядчик на fixed price контракт и начинается работа.
Особенностью корпоративного окружения является наличие десятков барьеров различного характера, которые крайне осложняют работу над проектом. Это и взаимодействие с компанией-подрядчиком – фиксированный контракт и существенные штрафы. Это проблемы в согласованиях между различными подразделениями внутри компании, у каждого из которых персональный KPI. Это мотивация сотрудников, ежеминутно сражающихся с непрерывно возникающими проблемами. Это проблемы в скорости поставки нужной функциональности на рынок, привлечении клиентов и увеличении ROI.
После двух с половиной лет ведения проекта руководство банка осознало, что изменения процесса критически необходимы. За основу изменений был взят Kanban Method (lean, поиск и устранение потерь), с целью создания эффективной Kanban-системы в проектной команде через оптимизацию цепочки поставки от первоначальной идеи до выхода функциональности в production.
Одно только прямое уменьшение проектных затрат составило более 30% - в результате изменений, прошедших в течение шести месяцев.
«Скрам для разработки сложных и долгосрочных инициатив, Канбан для выполнения потоковых задач» – довольно упрощенная формула, которую до сих пор многие используют по умолчанию, но иногда её приходится тестировать и обосновывать. Были исключения, когда формула не срабатывала для команды IT поддержки, так же, как и для разработки не всегда подходил Скрам.
Выбор методологии часто является спорным и даже, иногда, "религиозным" вопросом. Но все-таки, есть ли какие-то очевидные критерии выбора «Скрам или Канбан»? Зачем тратить время и силы на внедрение методологии Скрам, если все равно процесс упростится и от Скрама останется только доска!
Эту важную мысль мы попробовали донести до нашего клиента – крупного инвестбанка, когда Luxoft Agile Practice была приглашена провести масштабную трансформацию подразделения 80+ человек. Для этого подразделения клиент выступил с инициативой по созданию выделенной команды для L3-поддержки, при этом изначально был скептически настроен по отношению к Канбан. Основным аргументом против Канбан было отсутствие волшебной практики "коммитмента" на "скоуп". То есть, как ни странно, клиент настаивал на Скраме из-за нежелания меняться в своем plan-driven подходе.
Спустя почти 2 года от начала глобальной трансформации, L3-гильдия, использующая чистый Канбан, является одной из самых эффективных команд в программе. Сейчас, в общем пространстве появляются новые команды, новые Канбан-доски, так же как и новые Скрам-доски. Главное, чего удалось добиться в этой программе – при масштабировании проектная команда понимает критерии выбора «Канбан или Скрам» глубже чем простой шаблон - "Скрам для разработки, Канбан для поддержки".
Вячеслав Москаленко расскажет много интересных деталей, связанных с критерием выбора Скрам или Канбан в рамках одной программы. Также поделится своим опытом в переводе команд на гибкие методологии.
Речь пойдёт о важных характеристиках процесса (если угодно - метриках), о которых в сфере умственного труда говорят нечасто, измеряют реже и ещё реже на их основании принимают решения.
Происходит это отчасти по инерции - в самом деле в более изученной сфере производства материальных товаров и услуг, например, одна из этих величин стремится к 100%, другая почти всегда равна нулю, а третья является числом, а не распределением вероятностей. О них почти что можно не думать. Но когда покупательская ценность создаётся в головах сотрудников-интеллектуалов, а не на сборочной линии, всё гораздо интереснее.
В докладе мы обсудим, что вы можете сделать, придя на работу в понедельник, чтобы измерить эти величины. Затем мы обсудим, как, начиная со вторника, можно использовать эту информацию, чтобы найти более эффективные пути улучшения процессов, найти время для важной, но несрочной работы, сбалансировать нагрузку на вашу организацию с её способностями, принимать решения в условиях неопределённости и аккуратно прогнозировать проекты и выполение обязательств.
В 2008 Элияху Голдратт написал статью «Стоя на плечах гигантов», где он показал, что Toyota Production System и система Форда – это два конкретных прикладных решения, основанных на четырех фундаментальных принципах, одним из которых является ограничение объема незавершенной работы. В этой статье приводится пример компании, в которой эти прикладные решения оказались не способны принести никакого положительного результата на систему. Основываясь на тех же четырех фундаментальных принципах Элияху Голдратт описывает новое прикладное решение (Барабан-Буфер-Канат), применимое в более широком круге производственных систем.
В своем докладе я расскажу о нескольких ситуациях из своей практики, где канбан в привычном для нас виде оказался не способным эффективно решить задачу управления потоком, и где с успехом было применено решение Голдратта. В докладе будут разобраны применения метода Барабан-Буфер-Канат как на тактическом уровне (управление задачами поддержки) так и на стратегическом (управление портфелем проектов и определение состава и плана релизов).
