Гибридный подход к управлению проектами при внедрении продуктов «1С»

Существует множество методов управления проектами. Одни лучше подходят для строительства и разработки сложных инженерных объектов, вторые — для разработки программного обеспечения, третьи — для реализации проектов в государственных организациях. Для использования в разработке и внедрении программного обеспечения зачастую используются два подхода – классический каскадный (Waterfall) и гибкий (Agile).

Waterfall
Agile
Гибридный подход
Рекомендации к реализации гибридного подхода

Waterfall

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

Если следовать данному методу, то заказчик проекта получит результаты работы эффектом «большого взрыва» и будет вынужден проверять весь объем работы исполнителя за 2-5 месяцев. После этого сформируется реестр замечаний, который запустит процесс исправления результатов, похожий на предыдущий.

К преимуществам каскадного подхода обычно относят последовательность выполнения, подробную документацию и прогнозируемость. При этом Waterfall подходит не всем, особенно если изменения в компании происходят быстро и задачи, зафиксированные в ТЗ, через 2-5 месяцев могут стать неактуальными.

Отсутствие гибкости, выявление проблем лишь на поздней фазе тестирования, несовместимость с изменениями, непригодность для проектов с нечетко определенными целями и требованиями — известные недостатки каскадного подхода, которые сокращают его применение в чистом виде. 

Agile

В конце прошлого-начале этого века общественности был представлен гибкий метод разработки программного обеспечения — Agile. Суть его заключается в формировании краткосрочных планов — релизов (2-8 недели) на реализацию полезного для заказчика продукта из набора верхнеуровневых функций (бэклог). 

При таком подходе к реализации проектов нет ни конечного плана-графика, ни сроков, ни стоимости проекта, а, значит, нет устава и плана управления проектом, поскольку планы могут меняться от релиза к релизу. 

К плюсам гибкого подхода относят итеративную разработку, тесное сотрудничество с клиентом и адаптивность к изменениям.

Для Agile также присущи недостатки. Это недостаточная документация, не поддающиеся прогнозированию сроки выполнения заказа и стоимость, неприменимость для проектов с жесткими требованиями или где предсказуемость — необходимое условие. 

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

Гибридный подход

В случае внедрения продуктов «1С» наиболее оптимальной видится гибридная модель управления проектом, когда в контракте фиксируются этапы, сроки, трудозатраты, стоимость проекта и получаемые результаты этапов, а внутри этапов происходит порелизная работа и сдача результатов. 

Этот метод можно сравнить со стеклянным снежным шаром: крепкая твердая оболочка, зафиксированная в контракте и уставе проекта, а внутри — выполняемые работы, которые можно планировать и перепланировать так, как того требует ситуация или заказчик проекта. 

Рассмотрим, как гибридный подход к управлению проектом реализуется на практике. 

По результатам интервью с ключевыми пользователями на предприятии в фазе предпроектного обследования бэклог наполняется задачами (функциональными разрывами или gap-ами). В ходе моделирования, когда пользователи знакомятся с тем, как бизнес-процессы будут выглядеть в 1С:ERP, бэклог дополняется и детализируется. Требования могут уточняться и в дальнейшем: в фазе опытной эксплуатации, когда пользователи самостоятельно тестируют систему, а иногда и в ходе промышленной.

Реализация проекта делится на стримы — части функционального блока проекта, например, регучет, продажи, закупки, производство, планирование, склад и т.д. И пока бэклог наполняется задачами по одним стримам, работа по другим стримам может уже вестись. Выглядит это так:

1. Выявление gap-ов и составление функциональных технических заданий/листов требований 

2. Реализация требований

3. Сверка результата и снова выявление gap-ов.

Таким образом этапы проектирования и разработки могут идти параллельно.

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

Если после тестирования на данных предприятия заказчик выдвигает дополнительные требования, то разработанный функционал документируется, задача закрывается, а в бэклоге создается новая.

Работа спринтами позволяет:

• не уходить в длительную разработку, а после каждого спринта выдавать полезный продукт, с которым можно работать,

• сократить затраты ресурсов на исправления за счет быстрой обратной связи, ошибки не накапливаются.

Рекомендации к реализации гибридного подхода

Для достижения наилучших результатов при использовании гибридного подхода следует придерживаться следующих рекомендаций:

1. Четко определить, каким будет конечный продукт, требования к системе зафиксировать в бэклоге.

2. Контролировать соответствие полученного результата запланированному на всех этапах проекта.

3. Для контроля выполнения требований к продукту пользовательские истории необходимо объединить в матрицу трассировки требований, где у каждой истории указываются бизнес-цель, приоритет, номер спринта, номер поставки, идентификатор документации.

4. Использовать метод освоенного объема (earned value management, EVM), чтобы объективно понимать прогресс по проекту и эффективность его реализации в части сроков, содержания и стоимости.

5. Вести документацию: от требований к продукту — чтобы не было разночтений между заказчиком проекта и исполнителем, до описания каждой поставки — для понимания, для чего то или иное было сделано и как с этим работать. Это касается не только описания продукта, но и всей документации по проекту.

6. Максимально вовлекать сотрудников заказчика в работы по планированию спринта и тестирование полученного в результате его реализации продукта.

7. Соблюдать установленные в проектной документации сроки на всех этапах проекта.