Как разработка прототипа поможет выбрать ИТ-подрядчика и технологическую платформу
Выбор ИТ-подрядчика и технологической платформы — очень ответственный шаг, особенно если речь идет о разработке сложной и масштабной корпоративной системы. От решения зависят сроки, бюджет и соответствие результата задаче. Один из вариантов проведения конкурсной процедуры — разработка прототипа. Расскажем на реальном примере, в чем плюсы такого подхода и когда им можно воспользоваться.
Какие бывают прототипы и для чего они нужны
В этой статье речь пойдет о прототипах крупномасштабных корпоративных систем: ERP, CRM, СЭД, системы для работы с заявками, системы планирования маршрутов и т. д. В зависимости от решаемых задач выделяют несколько видов прототипов:
- Proof of Concept (PoC, подтверждение концепции). Такой прототип создается, чтобы проверить, можно ли с помощью рассматриваемых технологий реализовать необходимую функциональность. Он позволяет оценить скорость разработки, концепцию UI, риски или ограничения. Самое главное — PoC не предназначен для использования в продуктивной среде.
- Minimal viable product (MVP, минимально жизнеспособный продукт). Такой прототип содержит ограниченный набор функций, но в нем уже могут работать реальные пользователи и обрабатываться реальные данные. MVP позволяет быстро получить первый результат автоматизации, а также заложить основы для будущей полномасштабной системы.
Прототипы помогают с минимальными затратами проверить идеи и пользовательские сценарии, уточнить требования, получить обратную связь для дальнейшей разработки системы. Также это возможность на практике познакомиться с подрядчиком и технологиями. Можно оценить как объективные критерии (скорость разработки, гибкость, сочетание с имеющимся ИТ-ландшафтом и т. д.), так и субъективный комфорт.
Когда подойдет PoC, когда — MVP:
| PoC | MVP |
|---|---|
|
|
Прототип как один из этапов выбора партнера для разработки корпоративного ПО
Часто разработка прототипа становится первым этапом проекта, когда подрядчик и технологии уже выбраны. Но также это один из возможных вариантов проведения конкурсной процедуры. Как заказчик может прийти к этому?
Сперва у компании появляется задача по внедрению ИТ-системы. Это может быть замена иностранного продукта, который сложно развивать и поддерживать после ухода поставщика с российского рынка, или же переход от электронных таблиц и почты к специализированному ПО. Далее рабочая группа изучает представленные на рынке готовые продукты и понимает, что они не покрывают все запросы компании. Требуется настолько сильная кастомизация, что проще разработать уникальную систему на заказ. Следующие вопросы — поручить проект собственному ИТ-отделу или подрядчику, а также какую технологическую платформу выбрать. Формируется список требований, на его основе определяется список финалистов. Разработка прототипа может стать решающим этапом конкурсной процедуры. Например, один из заказчиков Хоулмонт, компания из сферы страхования, таким способом выбирала технологическую платформу и подрядчика для разработки системы автоматизации процессов из трех вариантов.
В чем плюсы такого подхода:
- Можно оценить технологическую платформу применительно к конкретным задачам.
- Если речь идет о разработке MVP, то с минимальными затратами можно получить первые результаты автоматизации.
- Разработанный прототип станет основой для будущей полномасштабной системы.
Разумеется, прототип — не волшебная таблетка и не универсальное решение. В некоторых случаях использовать такой подход для выбора технологий и подрядчика нецелесообразно. Например:
- Речь идет о государственных организациях с жестко регламентированными процедурами.
- Нет ни технологической, ни функциональной неопределенности, можно сразу готовить ТЗ и начинать проект.
- Нет возможности взаимодействовать с несколькими компаниями параллельно, оценивать прототипы, давать обратную связь и выбирать между ними.
Какая функциональность должна быть заложена в прототип
Ключевая особенность прототипа — разработка с минимальными затратами. Поэтому важно не ставить слишком всеобъемлющую задачу. Из всей функциональности системы можно выделить один процесс или модуль. Также в список требований к прототипу можно добавить что-то критичное для вашей компании, например, ролевую модель или механизмы фильтрации данных. На данном этапе можно обойтись без интеграций или без стилизации интерфейса. Конечно же, если проект предполагает специфические интеграции, а также если есть сомнения, что их можно реализовать при помощи рассматриваемых технологий, то можно включить одну интеграцию в прототип.
Наш заказчик, уже упомянутая компания из сферы страхования, планировала автоматизировать все ключевые бизнес-процессы, а в рамках прототипа запросила у финалистов реализовать процесс урегулирования убытков. Также в число требований на этом этапе вошли BPM-модуль, авторизация пользователей и справочники. Прототип должен был работать на минимальном наборе данных и без интеграций. Заказчик выбрал процесс, который требовалось в сжатый срок перевести в российскую систему вместо иностранной. Нельзя было затягивать проект.
Другой пример — CRM для промышленного предприятия, одного из крупнейших в мире производителей удобрений «ЕвроХим». Весь проект предполагает создание системы, охватывающей все этапы воронки продаж, а также сопутствующие направления, такие как прогнозирование спроса и маркетинговые активности. В PoC вошли работа с лидами, ролевая модель и визуализация воронки продаж, в MVP — процесс обработки лида от поступления до сделки.
Как оценивать прототип
По каким критериям можно оценивать прототип:
- Функциональные критерии: решены ли задачи, реализованы ли требуемые пользовательские сценарии, корректна ли бизнес-логика.
- Технические критерии: как реализована архитектура, насколько актуальны технологии, какие доступны интеграционные механизмы и механизмы безопасности, можно ли масштабировать систему.
- Удобство пользователей: понятен ли интерфейс, какая обратная связь по работе в системе.
- Польза для бизнеса: помогает ли система ускорить работу, обеспечить прозрачность процессов, снизить издержки, улучшить качество клиентского сервиса и т. д.
- Работа с подрядчиком: как организованы коммуникация и отчетность, насколько быстро компания реагирует на запросы, может ли команда масштабироваться или работать совместно со специалистами заказчика.
В примере нашего заказчика в оценке прототипов, разработанных финалистами, участвовали подразделения ИТ и ИБ, а также бизнес-заказчик. Среди критериев оценки были гибкость фильтрации данных, удобство интерфейса, реализация переходов между экранами и загрузки файлов. Самым сложным для участников стало требование внести изменения в прототип в процессе разработки. Платформа Jmix, на базе которой мы реализовали проект, позволила успешно справиться с таким запросом, но не все технологии способны на такую гибкость. Все это может быть важно проверить на этапе выбора, а не когда уже заключен долгосрочный контракт на крупномасштабный проект.
Что будет после разработки прототипа
После выбора технологической платформы и поставщика вы сможете продолжить работу с созданным прототипом и развивать его до полномасштабной системы. В рамках следующих этапов можно расширять функциональность, добавлять новые модули, проводить интеграции, совершенствовать интерфейс, масштабировать систему.
В примере с нашим заказчиком MVP был доведен по полноценной системы, позволяющей автоматизировать процесс урегулирования убытков. За счет того, что большой объем работы был проделан на этапе прототипа, заказчику удалось провести импортозамещение в срок. Параллельно происходили выбор поставщика и закладка первых кирпичей технологической базы. На следующие два года запланированы еще три очереди проекта.
Сроки и стоимость разработки прототипа
На создание PoC требуется 30–40 часов, на разработку MVP — 2–4 месяца.
Стоимость зависит от вида прототипа и деталей проекта. Большинство компаний работают по моделям Fix Price или Time and Material.
Разработка MVP обойдется примерно в 2–3 млн рублей. Если речь идет о крупномасштабной корпоративной системе, то это относительно небольшая сумма. Выбор технологической платформы и подрядчика путем сравнения нескольких прототипов требует более существенных затрат и занимает больше времени по сравнению с другими процедурами, например, по сравнению с запросом коммерческих предложений. Однако в результате вы сможете на практике сравнить, какие инструменты лучше соответствуют вашим задачам и с какой компанией комфортнее работать. Это позволит снизить неопределенность и уменьшить риск того, что в проекте что-то пойдет не так на более поздней стадии, когда стоимость ошибки существенно дороже. Более того, прототип уже будет приносить пользу компании.
Разработка PoC стоит существенно дешевле.
