Масштабные ИТ-внедрения без бюрократии: роль владельца продукта

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

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

Как организационные проблемы тормозят проект 

Реализация тяжелых корпоративных систем — это всегда набор организационных рисков. С какими проектами может возникнуть больше всего сложностей: 

1. Внедрение системы с множеством модулей и интеграций.
2. Разработка уникальных композитных систем, объединяющих функциональность ERP, СЭД, CRP и других классов ПО. 
3. Миграция legacy-решений, которые «жили» 20–30 лет. 

Какие организационные факторы риска мешают реализации масштабных проектов: 

• Большое количество лиц, принимающих решения;
• Длинный процесс принятия решений;
• Нет документации по старой системе;
• Необходимость оптимизации процессов;
• Классическая каскадная модель не работает на длинной дистанции.

Разберем подробнее, как это тормозит проект. 

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

• Выделить на стороне заказчика владельца продукта (product owner).
• Сфокусироваться на быстром запуске и последующих запросах на изменение.

Далее разберем каждый совет подробнее. 

Для чего нужен владелец продукта и какие задачи он выполняет 

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

За счет чего обеспечивается ценность системы для бизнеса: 

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

Как появляется владелец продукта? Чаще всего владелец продукта появляется эволюционно, когда проект буксует. Но для сложного проекта будет полезно на старте определиться, кто возьмет на себя эту роль. 

Как выглядит работа владельца продукта? Рассказываем на примере нашего заказчика (название компании под NDA). Суть проекта — замена иностранной ERP-системы, состоящей из десятков модулей. Внедрение происходит поэтапно. На каждом этапе владелец продукта вместе с командой определяет, какая функциональность самая важна, а какую можно отложить. Проводится несколько встреч с бизнес-заказчиками, обсуждается и утверждается общая рамка проекта. На мелкие вопросы, которые неизбежно возникают в процессе работы, владелец продукта должен иметь полномочия ответить самостоятельно. С его подачи может быть инициировано изменение бизнес-процессов или регламентов. Если согласовывать решение на более высоком уровне, то потеряется ценность функциональности относительно времени, затраченного на реализацию. 

Какие решения принимает владелец продукта? Рассказываем на примере другого проекта. Здесь тоже речь идет о замене иностранной системы. Один из ее модулей предназначен для автоматизации документооборота. На старте процессы были описаны as is, по аналогии со старой системой. Однако при запуске в эксплуатацию возникли сложности, система была не востребована среди пользователей. Сначала владельца продукта не было, но после кадровых перестановок появился инициативный сотрудник, который предложил переосмыслить процессы. В системе реализовали конструктор, позволяющий связать процессы между собой. Когда завершается один шаг, сразу запускается следующий, пользователям больше не нужно это делать вручную. Изменения привели к росту популярности модуля автоматизации документооборота. 

Что дает заказчику появление владельца продукта? Все решения принимаются в единой точке, ресурсы фокусируются на критически важных функциях. В результате заказчик может ускорить выход системы в эксплуатацию на 30–40%. 

Для чего нужны быстрый запуск и запросы на изменение 

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

В рамках каждого этапа выполняются следующие шаги: 

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

Шаг по разработке прототипа требует пояснения. В данном случае речь идет о Minimal Viable Product (MVP) — версии системы или отдельного модуля с минимальным набором функциональности. В отдельной статье мы рассказывали о видах прототипах и их различиях. Но вернемся к поэтапной разработке. 

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

Что дает заказчику поэтапный подход? Фокус на быстром запуске и быстром получении обратной связи позволяет не промахнуться на начальном этапе и не тратить деньги там, где был шанс увидеть ошибку раньше. За счет разделения на этапы команде будет проще отрабатывать замечания пользователей после запуска. 

Что делать на старте масштабного проекта 

Некоторые проекты невозможно выполнить без активного участия со стороны заказчика и пересмотра подхода к работе. Вот несколько советов, которые помогут успешно довести проект до результата, а не слить бюджет: 

1. Определите владельца продукта, который будет отвечать за ценность разработки для бизнеса. 
2. Выдайте ему необходимые полномочия. Ключевую роль в успехе играет доверие.  
3. Подходите к проекту без лишней бюрократии. Не получится сначала описать требования по всей системе, а потом разработать и внедрить, слишком быстро меняется и внешняя и внутренняя среда. 
4. Добейтесь минимально работающего результата. 
5. Постепенно улучшайте функциональность на основе обратной связи от бизнеса и пользователей.