Анализ вариантов технологии внедрения
Исаев В. В. v.isaev@solitonkg.ru
Филиппов Н. Б.
Выбор правильной технологии управления проектом внедрения — первый шаг к успеху автоматизации работы предприятия.
Практика внедрения программных продуктов для бизнеса, 1С ERP в том числе, использует несколько методик:
· Классическая, каскадная или «водопадная» модель;
· V-модель;
· Инкрементная модель (модель снижения риска) или «мульти-водопад»;
· Итерационная, спиральная модель (некоторые аналитики считают, что это 2 разные модели);
· Agile / Scrum;
Существуют и другие варианты моделей внедрения, такие как Сашими, рациональный унифицированный процесс (RUP), методология «чистой комнаты» (Cleanroom) и др. Но все эти модели могут быть отнесены к разновидности классического варианта, поскольку они являются последовательными, с четкой границей между этапами. К Agile относят методики FDD, Kanban, экстремальное программирование (XP), Lean и т.д.
Выбор оптимальной технологии управления проектом внедрения бывает непрост. Он сильно зависит от множества специфических факторов:
· от направленности проекта (переход с 1С УПП на 1С ERP, внедрение 1С ERP «с нуля», развитие системы, новая попытка внедрения и т.п.);
· от этапа жизненного цикла компании заказчика,
· от организационной структуры,
· от зрелости системы управления предприятия,
· от порядка финансирования,
· от особенностей бизнеса,
· от личных субъективных предпочтений руководителей,
· от опыта и наработок поставщика услуги.
Сравнительный анализ различных моделей управления проектом – полезная информация для принятия решения
Поскольку неправильный выбор модели может отрицательно сказаться на внедрении, и даже привести к провалу проекта, сравним главные особенности каждой из моделей в таблице.
|
|
Классическая, каскадная или «водопадная» модель |
Agile / Scrum
|
V-модель |
Инкрементная модель (модель снижения риска) или «мульти-водопад» |
Итерационная, спиральная модель (некоторые аналитики считают, что это 2 разные модели) |
|
Описание |
Программа проходит через фазы исследования, моделирования, определения требований, настройки, доработки, внедрения и тестирования. |
Работа разделена на отдельные шаги – Спринты («Sprint»). Регулярные собрания подводят итоги прошедшего шага и формируют перечень задач нового шага. После каждого шага заказчик может использовать результат и оценить, его. |
Вариант классической модели. Стадия тестирования (функционального, нагрузочного, интеграционного) проводится параллельно со стадией настройки и доработки. |
Поэтапное внедрение системы. Каждый модуль при внедрении проходит через этапы классической модели. |
На старте внедрения необязательна полная спецификация требований. Внедрение начинается с реализации части функционала, становящейся базой для определения дальнейших требований. Этот процесс повторяется «по спирали». |
|
Условия применения модели |
Когда требования к системе известны, тщательно продуманы, понятны и задокументированы. Противоречивых требований не имеется. Поставлены сроки внедрения. Приоритетом является качество. Временные и денежные траты имеют второстепенное значение. |
Подходит для внедрений, адаптируемых к сложным меняющимся условиям и пожеланиям пользователей. Перечень требований окончательно не определен, а изменения должны вноситься максимально быстро. |
Для малых и средних проектов, которым особенно важно бесперебойное функционирование в сложных условиях. |
Когда основные требования к системе четко определены и понятны. Но в то же время требования к дополнительным модулям не сформированы окончательно и могут дорабатываться с течением времени. |
Проект большой или очень большой. Требования к конечному результату заранее чётко не определены. Хорошо подходит для автоматизации сложных, но критически важных бизнес-процессов. |
|
Риски и критические условия реализации проекта |
Отличный результат только в проектах с чётко и заранее определенными требованиями, и способами их реализации. Есть риск, что конечный результат может иметь недочёты, на устранение которых понадобятся дополнительные ресурсы Если представители заказчика не планируют принимать активное участие в реализации проекта, велика вероятность, что конечный результат их не устроит. Исполнитель полностью несет ответственность за срыв сроков и незапланированное увеличение бюджета. |
В проекте должна работать команда с высоким уровнем профессионализма, опытом внедрения различных модулей и их интеграцией. Представители заказчика по внедряемому модулю принимают активное участие во внедрении на протяжении всего проекта. Возможность частого внесения правок может обернуться риском длительного совершенствовании системы. Также возможно неоправданное усложнение со снижением качества решения. Частые запросы на оценку работы системы могут вызвать раздражение пользователей. |
Снижается риск, что конечный результат будет иметь серьёзные недочёты, на устранение которых понадобятся дополнительные ресурсы
|
Предусматривает на первом большом этапе внедрение продукта в базовой функциональности, а затем уже последовательное внедрение новых модулей - «инкрементов». |
Предполагает 4 этапа для каждого витка: 1. исследование и планирование; 2. анализ рисков; 3. разработка и внедрение; 4. оценка результата и при удовлетворительном качестве переход к новому витку или новому модулю. Результат может быть не неидеален, главное, чтобы система работала. |
|
Уровень сложности управления проектом |
Простая, понятная логика и структура проекта, как для опытных специалистов, так и для новичков. |
Для старта проекта достаточно лишь общего, предварительного планирования. Но чтобы получить в итоге из отдельных частей цельный рабочий продукт, необходим высокий профессионализм от руководителей и исполнителей и грамотная организация всего процесса. |
Соответствует уровню классической водопадной модели управления проектом. |
Не нужно использовать много ресурсов на начальном этапе. |
Соответствует уровню классической водопадной модели управления проектом. |
|
Скорость внедрения |
Высокая, но рабочая эксплуатация возможна только после завершения последнего этапа. |
Позволяет быстро получать локальный результат после коротких шагов. |
Высокая за счет распараллеливания этапов внедрения. Рабочая эксплуатация возможна только после завершения последнего этапа. |
Высокая за счет последовательного ввода подсистем. Рабочая эксплуатация начинается с ввода первой подсистемы. |
Высокая за счет последовательного ввода подсистем. Рабочая эксплуатация начинается с ввода базовой подсистемы. |
|
Сроки и стоимость внедрения |
Стоимость фиксированная. Сроки заранее определены. |
Сложно заранее оценить стоимость. Сроки жёстко не определены. |
Стоимость фиксированная. Сроки заранее определены. |
Стоимость фиксированная. Сроки заранее определены. |
Отсутствие фиксированного бюджета и сроков. |
|
Гибкость, возможность оперативных изменений |
Нет возможности сделать шаг назад, список требований нельзя скорректировать в любой момент. Заказчик увидит готовый продукт только в конце разработки и только тогда может дать обратную связь. |
Возможность внесения изменений на каждом шаге проекта. |
Примерно соответствует гибкости классической модели управления проектом. Позволяет внести изменения еще на стадии разработки за счет параллельного тестирования. |
Ошибка обходится дешевле за счет более короткого шага для получения результата. |
Быстрое внедрение даёт возможность оперативно получать обратную связь от заказчика и пользователей. Возможность улучшений в последующих итерациях, основываясь на результатах, полученных в ходе предыдущих этапов. |
|
Условия оперативных изменений |
Стоимость внесения изменений высока, так как для выявления проблем и ошибок нужно ждать полного завершения этапа тестирования. Не нужно нанимать команду тестировщиков, можно опираться на подробную техническую документацию. |
Эффективное взаимодействие в команде важнее процессов и технологий. |
Необходимо достаточное количество инженеров тестировщиков. |
|
|
У каждой из методологий есть свои преимущества и недостатки, а также есть свои границы применимости. Нет модели, единственно верной, идеальной для всех ситуаций и граничных условий. Даже «гибкая» Agile не может применяться повсеместно по разным причинам: от неготовности руководства и сотрудников заказчиков к плотной работе, из-за неопределенности в графике финансирования, от непонимания того, каким в конце концов будет конечный результат.
Возможно ли, сочетая достоинства различных технологий, получить «комбинированный» продуктивный вариант для проекта?
Уверен, это вполне достижимо: в рамках одного проекта можно оптимально совместить Agile и Waterfall. Более того, это даже рекомендуется в ряде случаев. Такой подход реализуется на основе гибридных моделей (V, инкрементной, итерационной, спиральной). При разработке плана проекта верхнего уровня мы предлагаем опираться на долгосрочные цели, а конкретные этапы (учитывая специфику работ на них) «нарезать» на задачи, решаемые гибкими методами. Суть такого подхода - выбрать наиболее подходящую тактику для каждой фазы проекта.
Хотелось бы кратко остановиться на одном крайне непродуктивном подходе.
Некоторые, особенно крупные, компании или холдинги, стремятся на начальном этапе получить твердую определенность по цене и сроками проекта без предварительного исследования и без проработанных целей и границ. Они пытаются жёстко «продавить» подрядчика, получая при этом не лучший вариант решения, а лучшее маркетинговое предложение.
А это, как Вы понимаете, не дает гарантии успешного внедрения. Хорошо, если на исправление ошибок из-за неверного (под давлением) выбора технологии заказчик сможет найти дополнительные средства. Однако, существует немало случаев, когда такие проекты заканчиваются просто ничем.
Наши рекомендации заказчику до начала проекта для повышения качества результата.
Мы предлагаем поработать до начала проекта, немного подумать - определить свою организационную и техническую политику, найти адекватное решение для существующего вызова. В конечном итоге это позволит Вам избежать ряд принципиальных ошибок:
1) максимально точно определить цели проекта;
2) детализировать (насколько возможно) границы и требования к системе;
3) критично взвесить свои возможности и ресурсы - определиться, что можно сделать самим, что заказать на стороне, и что лучше сделать совместными усилиями;
4) запросить предварительные оценки и технологии реализации проекта от потенциальных подрядчиков;
5) привлечь экспертов для анализа представленных вариантов на наличие рисков и их исполнимость;
6) обсудить с потенциальными подрядчиками возможность корректировки предложения;
7) выявить профессиональный уровень подрядчика, его умение и желание работать;
8) доработать совместно с подрядчиком план проекта до рабочей версии;
9) провести переговоры для заключения контракта;