Мы за скрам!

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

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

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

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

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

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

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

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

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

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

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

Мы эту методологию продекларировали год назад. По-настоящему внедрять у себя ее начали в январе 2014 года. Пока мы используем примерно 50%. Столько мы сумели освоить за прошедшие месяцы. И это вовсе не потому, что мы особо упрямые или глупые, а потому, что требуются изменения в головах большого числа людей. У нас по этой методологии работают несколько десятков человек. Самое главное – переход к командной ответственности.

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