Подход к внедрению 1С — какую методологию предпочесть?
При внедрении крупных и сложных проектов мы в ФТО обычно придерживаемся классической «водопадной» методологии:
- Первым этапом проекта является «Анализ и дизайн». В ходе этого этапа проводится интервью с бизнес-экспертами, подрядчик готовит документ «Дизайн решения», и согласует его с клиентом. В результате этого мы получаем точно определенный функциональный объем проекта, а также детальный план работ вплоть до запуска в промышленную эксплуатацию, точные сроки, фиксированный бюджет.
Далее, друг за другом, идут этапы:
- Построение. Выполняется вся разработка, тестирование, создание документации. Окончание этапа – интеграционный тест (приемка системы клиентом на синтетических тестах).
- Внедрение. Обучение пользователей, загрузка начальных данных, подготовка плана запуска.
- Запуск и активная поддержка. Запуск системы в эксплуатацию, помощь пользователям на старте.
Подробно об этой методологии читайте здесь.
Однако не всегда этот вариант подходит заказчику, иногда результат нужен как можно скорее и времени на последовательное внедрение просто нет. В этом случае мы используем гибкую методологию, заранее предупреждая заказчика о всех возможных рисках.
Минусы классического подхода
- Непопадание в ожидания. В классическом проекте от согласования дизайна на систему до первой демонстрации ее (т.н. интеграционного тестирования с заказчиком) проходит до 6 месяцев, а до запуска системы в эксплуатацию – до 9 месяцев, а в крупных проектах и больше. Часть ожиданий клиента относительно системы, которая была недостаточно точно отрефлексирована в дизайне, оказывается не выполненной, и это становится известно только через месяцы работы.
- Компания не стоит на месте. За время разработки и подготовки к запуску (условно, 9 месяцев) бизнес-процессы в компании меняются, и запускаемая система уже отстает от жизни. Стоимость внесения изменений по ходу проекта высока.
- Существенная часть бюджета тратится на малополезную работу. Этап «Анализ и дизайн» проекта (проведение интервью, написание и согласование дизайн решения) занимает 20-30% бюджета проекта. В нашей практике крайне редки случаи, когда после запуска проекта полученный дизайн решения реально используется.
- Работа на корзину. На этапе дизайна бизнес-эксперты могут придумывать процессы или функциональность, которые не будут использоваться в реальной жизни. Все согласованные пожелания разрабатываются полностью, а после запуска существенная часть функционала переделывается, или выкидывается и разрабатывается с нуля.
- Запланированный CAPEX тратится целиком. Невозможно в произвольный момент остановить проект и пользоваться тем функционалом, что уже готов: клиент получает результаты только после запуска.
Альтернативный подход
Альтернатива – методология agile, или гибкий подход.
Ключевые отличия подхода:
- Разработка ведется итеративно. Каждая итерация приводит к созданию и запуску нового блока функциональности.
- Планирование работы команды ведется не сразу на весь проект, а на следующую итерацию.
- Существенно уменьшен объем создаваемой документации.
- Больше коммуникации между командой клиента и подрядчика
Подробнее об этой методологии.
1. Итеративная разработка
Окончание каждой итерации – демонстрация промежуточных результатов клиенту и (чаще всего) запуск новой функциональности в эксплуатацию. Такой подход позволяет:
- Получать быструю обратную связь от бизнес-экспертов и конечных пользователей по новой функциональности и корректировать планы по созданию системы.
- Система всегда в состоянии «готова». В любой момент времени можно остановить разработку (и соответственно выделение бюджета) и пользоваться тем продуктом, который уже разработан.
- Изменение требований – это хорошо, это естественная ситуация, а не отклонение от нормы (как в «водопадной» модели). Бизнес не стоит на месте.
2. Планирование по итерациям
Общий план проекта – не расписан детально, а представляет из себя roadmap по ключевым функциям. Детальное планирование ведется только на ближайшую итерацию.
За счет этого:
- Разрабатывается только то, что необходимо: низкоприоритетные задачи не будут разрабатываться до высокоприоритетных (а может и никогда).
- Сокращается избыточная работа на планирование руководителя проекта как со стороны клиента, так и подрядчика
- Уменьшается ставка в проекте: подрядчик не должен закладывать в ставку риски недооценки проекта, возникновения форс-мажорных ситуаций и т.п. На примере ФТО ставка по agile модели меньше ставки в fix-price проектах на 40%.
3. Меньше документации
В ходе проекта не создается полный дизайн решения на всю систему, этапа «Анализ и дизайн не существует. Документация на создаваемую функциональность в рамках ближайшей итерации создается в упрощенном
виде.
В результате этого:
- Уменьшаются непроизводительные затраты труда. За счет того, что документация создается непосредственно перед или во время разработки (когда часть системы уже работает), повышается ее точность и качество.
- Сокращается бюджет проекта, за счет отказа от этапа дизайна, снижается количество документации.
4. Больше коммуникации
- Команда подрядчика общается с командой заказчика не только на интервью и приемке системы, а на регулярной основе (ежедневно/еженедельно).
- «Владелец продукта» со стороны клиента вовлекается в проект с той же частотой: он всегда понимает, что нужно делать в каком порядке, и транслирует это команде.
- Личное общение в команде лучше, чем согласование ТЗ.
- Все это дает возможность глубже погружаться в бизнес клиента и более оперативно реагировать на изменения.
5. От чего придется отказаться?
Важно! В agile проекте не может быть фиксированного бюджета или фиксированного срока.
Классический проект: после согласования дизайна функциональный объем определен точно, из него легко
определяются бюджет и сроки.
Agile проект: функциональный объем не определен точно – функции разрабатываемого решения добавляются, уточняются и удаляются в любой момент по ходу проекта. Без детального ТЗ нельзя оценить точно трудозатраты.
Фиксируется один из параметров:
- Определяется приблизительно функциональный объем, по его достижению («система всех устраивает») проект прекращается. Стоимость и сроки – переменная величина.
- Фиксируется бюджет и/или срок. Проект завершается по достижению заданных параметров в том функционале, что
удалось реализовать за заданный бюджет.
Когда нельзя применять Agile?
- Внедряемая система заменяет старую. Поскольку новая система создается и внедряется поэтапно, нормальная работа бизнеса нарушается: старая система уже не работает, новая еще не работает.
- Большая команда (более 5 бизнес-экспертов). С ростом команды простая коммуникация (без детальных описаний процессов и согласований на всех уровнях) крайне затрудняется.
- Нет «владельца продукта» со стороны заказчика (или его невозможно выделить). Без человека, который точно понимает, что конкретно надо реализовать в системе в первую очередь, невозможна тактика частой
поставки продукта. - Нет доверия к подрядчику. В agile проекте невозможно точно оценить и зафиксировать бюджет. Работа по принципу Time&Material (оплата по фактически потраченному времени) в условиях недоверия некомфортна клиентам.
При этих вводных «водопадная» модель работает лучше.
Когда можно применять Agile?
- Создается новая система. До начала проекта функциональность отсутствовала, поэтому возможно запускать новую систему поэтапно: персонал и руководство клиента приветствуют более быстрое получение результатов.
- Разумный размер команды клиента. В небольших командах возможны ежедневные/еженедельные планерки, на которых согласуется содержание и функциональность, создаваемая на очередном этапе работы, а специалистам
подрядчика напрямую уточнять у бизнес-экспертов детали реализации. Это позволяет сократить сроки за счет отказа от подробного описания. - Есть доверие к подрядчику. Работа по T&M в таких условиях возможна и экономит бюджет.
- Особенно Agile полезен в том случае, если к началу проекта ожидания от системы у клиента не до конца ясны – например, автоматизируются бизнес-процессы, которых еще нет в реальной жизни компании. В этом случае работа постепенными приближениями еще сильнее спасает от работы на корзину, что обязательно случается в классических проектах: бизнес-экспертам, как и всем людям, сложнее придумать правильный процесс, чем рассказать тот процесс, что уже есть.