Материал раздела Основной

Что может пойти не так при разработке ПО для бизнеса. Карта рисков

Компании создают удачные enterprise-решения — ПО, ориентированное на оптимизацию бизнес-процессов, — лишь в 20% случаев (данные The Standish Group). Сергей Круглов, партнер в веб-интеграторе ITECH, составил карту рисков, которая поможет избежать провала
Фото: Evening Standard / Getty Images
Фото: Evening Standard / Getty Images

По данным агентства b2b-маркетинга NWComm, уход или остановка работы иностранных вендоров сильно повлияли на деятельность 86% российских компаний. Все они хотят уйти от использования зарубежного ПО — и часто для этого выбирают вариант внедрения собственных enterprise-разработок. Для того чтобы эти разработки в конце концов принесли пользу бизнесу, необходимо знать риски, с которыми часто сталкиваются подобные проекты.

Риск № 1. Не сформулировать видение целевого бизнес-эффекта

Бизнес-заказчики часто хотят получить систему, которая будет максимально похожа (в том числе интерфейсно) на предыдущую. Это ведет к тому, что время и деньги потрачены, а ключевые задачи пользователей так и не решены.

Как обойти риск

— Сделайте ориентиром требования и приоритеты бизнеса, а не стремление к созданию клона. Определите, каковы ключевые показатели сейчас и к каким показателям вы хотите прийти к конкретному сроку. Например, на данный момент на обработку одного обращения сотрудник тратит A минут, заказчик получает результат за B дней. Задача — сократить время обработки на х%, а срок до получения результата заявителем — на y%. Это нужно сформулировать и донести до всех участников проектной команды.

— Внедрите BI-дашборды на первых стадиях проекта, не откладывая это на более поздние этапы. Так вы гарантированно определите ключевые показатели и вовремя акцентируете на них внимание команды.

— Работайте с исполнителями короткими итерациями, начиная с создания минимально жизнеспособного продукта (MVP). Так вы снизите количество ошибок и шансы потратить дополнительные ресурсы на внесение изменений на поздних сроках.

Риск № 2. Не проверить требования топ-менеджеров и пользователей к системе на совместимость