Представим ситуацию, когда решение об автоматизации принято, интегратор определен, программный продукт выбран, коммерческие цели внедрения ясны, и команда «исполнитель-заказчик» выбирает пути их достижения.
Путь №1
Внедрение системы автоматизации по каскадной (waterfall) технологии применяется повсеместно и имеет ряд достоинств: согласованный регламент, описывающий пошагово все работы, роли и ответственность, выполнение этапов строго в зафиксированном порядке, детальная проработка стоимости и содержания проекта. «План» защищает и заказчика, и интегратора, придает уверенность, гарантируя ясное, регламентированное будущее и успехи внедрения.
Скрытая угроза
Но вспомним, что опытные игроки IT-рынка говорят более чем о 50% «провальных» проектов в области автоматизации, большая часть которых приходится на комплексные внедрения — сложные многоступенчатые проекты. Именно на них достоинства технологии waterfall превращаются в глобальные риски, поскольку вероятность того, что сложный, растянутый во времени многоуровневый процесс пойдет по плану без отклонений, очень мала.
План, проблема, провал
Начнем с того, что формирование плана, призванного стать монументальным «фундаментом» внедрения, само по себе требует времени и влияет на продолжительность проекта. Предпроектное обследование с подробной проработкой бизнес-процессов, интервьюированием пользователей, составлением, согласованием, принятием регламента и выработкой требований к создаваемой системе, на крупных проектах может занимать до двух месяцев – времени, уже оплаченного заказчиком, но не принесшему ему реальных выгод.
Отметим, что заказчику на этапе составления плана достаточно трудно сформулировать четкие требования к конечному продукту — создаваемой системе. При описании будущих бизнес-процессов он полностью полагается на интеграторов, не ставя во главу угла целесообразность внедрения тех или иных частей системы. Это в разы повышает вероятность необходимости внесения изменений в содержание проекта.
Если приступить к реализации «корректировок», проект затянется, станет дороже, и начнется «выгорание» заказчика, что означает усталость от внедрения, потерю веры в успех проекта. Игнорирование корректив, грозит появлением в водопаде «снежных комов» — накопление дополнительных требований, сопутствующих задач и неисправленных ошибок.
Конечно, опытные интеграторы закладывают рисковый буфер в план, но самый минимум, ведь перестраховка сделает проект громоздким, и всегда найдется тот, кто возьмется сдать работу в более короткие сроки и за меньшие деньги, просто «забыв» о рисках.
Сгорел на работе
Проблема «выгорания» заказчика стоит не менее остро, чем несовершенство плана и необходимость внесения в него корректировок. Опустив очевидные причины усталости от внедрения (повышенная нагрузка, отвлечение от основных обязанностей, давление со стороны руководства, оплата работ, не имеющих конкретного результата), отметим, что ни одно внедрение новой системы автоматизации не обходится без сопротивления будущих пользователей. Они могут быть просто ретроградами, не желающими осваивать новый интерфейс, а могут — опытными коррупционерами, «серые» схемы работы которых, новая система ставит под удар. Заказчик чувствует себя «единственным воином в поле», не до конца уверенным в своих решениях и полномочиях.
«Выгорание» приводит к тому, что заказчик готов прекратить проект при первой возможности, неважно, достигнуты результаты или нет.
Путь №2
Гибкая методология Scrum, с начала 90-х годов применяемая для управления проектами по разработке программного обеспечения, сегодня активно используется в сопричастных областях.
Принцип Scrum — за небольшие, четко фиксированные отрезки времени, называемые спринтами, предоставлять заказчику работающий программный функционал, для которого определен наибольший приоритет, — как нельзя более точно отражает потребности проектов внедрения программных продуктов 1С для создания автоматизированных систем управления на предприятиях.
Это связано с серьезным развитием решений 1С за последние годы. Программные продукты теперь обладают настолько богатым функционалом, что способны удовлетворить большую часть потребностей заказчиков без значительных доработок (кодирования). При этом адаптация решения под бизнес-процессы предприятия производится, главным образом, параметрическими настройками. Необходимо также признать, что функционал типовых решений фирмы 1С разработан на основе лучших практик, которые сами по себе являются ориентиром для построения эффективных бизнес-процессов. В таких условиях проекты, выполненные по Scrum-технологии, позволяют быстро получать полезные результаты и сильно выигрывают в сроках и стоимости.
Пора вступить в схватку
Примечательно, что Scrum не требует выдвижения структурированных требований к результату автоматизации в самом начале проекта, когда заказчик не может этого сделать просто потому, что у него нет понимания, что можно улучшить, от чего отказаться, а что включить в схему работы в прежнем виде.
Методология позволяет, начав с автоматизации процессов, в которых больше всего нуждается заказчик, а значит и хорошо их понимает, перейти на уровень подсистем логичным путем, а не потому что «так надо», нивелируя проблему принятия долгосрочных решений, которые к концу проекта могут кардинально измениться.
из мира 1С для ИТ-Директоров
Расставляем приоритеты
Запуская проект автоматизации по Scrum, обойтись без предварительного экспресс-обследования все-таки невозможно. Оно необходимо для обозначения ориентиров, выявления «узких мест» бизнес-процессов и основных потребностей будущих пользователей. По его результатам формируется журнал пожеланий (backlog). Он может отражать:
- Границы проекта во времени;
- Бюджет;
- Задачи и их рейтинг.
Приоритетная задача составляет бэклог спринта. Спринт дробиться на более мелкие «отчетные периоды», вплоть до 4-х часовых отрезков. Оценка готовности производится на регулярных собраниях. Дробление спринта исключает длительную работу с неактуальными задачами, упрощает вхождение новых игроков в команду и, при необходимости, дает возможность форсировать темпы проекта.
Не будем подробно останавливаться на «артефактах» методологии Scrum. Оценим эффективность ее применения непосредственно на проектах автоматизации, нащупаем «подводные камни» и возможности их обхода.
«Бумажные» вопросы
Сдача очередного спринта актуализирует бэклог. Он может пересматриваться как в «большую» (появление новых пожеланий), так и в «меньшую» (функционал потерял актуальность) сторону. При этом регламентирующим документом спринта является дополнительное соглашение, в котором обозначен объем работ и их стоимость за месяц.
Поскольку заказчик всецело контролирует работы, имея полную картину их выполнения (с помощью наглядных инструментов Scrum – Kanban-доске и диаграмме сжигания работ), он оперативно дает «зеленый свет» на следующий спринт, оставляя процесс согласования и подписания документов «за кадром» проекта. Такая постановка регламентации проекта исключает затягивание времени работ в целом и актуальных доработок в частности.
Нет проблем, есть новые задачи
Справится с появлением «снежных комов» в Scrum позволяет основная идея методологии: «Реакция на изменения важнее следования плану». Реакция выражается в простом перераспределении трудозатратах на следующие спринты. Отражение их на Kanban-доске позволяет наглядно оценить масштаб «реакционных» работ и их влияние на общий процесс достижения целей спринта.
Если в качестве реакции должны последовать действия, масштаб которых не вписывается в рамки существующего бэклога, инициируется параллельный проект. Сигналом к его запуску, может послужить, например, потребность внедрения дополнительного программного обеспечения.
При этом запуск параллельного проекта – решение отнюдь не обязательное, поскольку не сказывается на работоспособности «основной» системы и, следовательно, не усугубляет один из самых конфликтных моментов проекта – момент оплаты.
Знаю, за что плачу
В оплате проектов по Scrum есть свои особенности. Например, гибкая методология позволяет работать в независимости от того, был ли на этапе составления бэклога зафиксирован «потолок» стоимости проекта, или он остался неизвестен интегратору.
Все работы полностью подконтрольны и детально понятны заказчику, поэтому доработки и параллельные проекты он может оперативно санкционировать исходя из реальных потребностей и финансовых возможностей. В этом и заключается глобальное достоинство методологии Scrum: заказчик платит только за полезный функционал.
На стороне заказчика
Заказчик, как представитель интересов конечных пользователей и заинтересованных в продукте сотрудников, на проекте по Scrum становится неотъемлемой частью команды внедрения, что во много раз повышает его мотивацию в части достижения результата проекта.
Как уже упоминалось, заказчик детально вникает во все работы на проекте, что, в свою очередь, облегчает предоставление им отчетности руководству. «Запараллеливание» проектов, не только упрощает момент оплаты, но так же позволяет вовлечь в процесс отделы, не задействованные в основном проекте, распределить давление между несколькими ответственными со стороны заказчика и повысить общую лояльность сотрудников.
Еще раз кратко отметим сильные стороны гибкой методологии:
- Заказчик платит только за ценный для его бизнеса результат.
- Оперативная реакция на коррективы повышает качество конечного продукта, позволяет исправить ошибки на ранних стадиях и достигнуть стопроцентного соответствия функционала ожиданиям заказчика.
- Заказчик полностью контролирует работы на проекте, ощущает себя частью команды, может разделить давление с коллегами.
- Заказчик получает быстрые качественные результаты.
- Максимально короткое время проекта.
- Стремление к уменьшению объема документации.
консультация эксперта
самые свежие новости 1 раз в месяц
