Модели взаимодействия

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

Почасовая оплата

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

Принцип работы

– Заказчик совместно с разработчиками формулирует задачи.
– Определяется приоритет выполнения поставленных задач.
– Каждая завершённая задача принимается заказчиком.
– Если это необходимо, в проект вносятся изменения.
– В итоге заказчик получает нужный ему программный продукт.

Преимущества

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

Применение

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

Фиксированный бюджет

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

Принцип работы

– Для проекта составляется точная спецификация.
– Бюджет и сроки разработки фиксируются.
– Требования к продукту меняются минимально.
– Выделяются промежуточные этапы разработки.
– Заказчик принимает каждый завершённый этап.

Преимущества

– Расходы на проект не превысят заложенный бюджет.
– Требования к проекту определены до начала работ.
– Сроки разработки известны в самом начале.

Применение

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

Выделенная команда

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

Принцип работы

– Определяется зона ответственности команды.
– Каждый специалист проходит валидацию заказчиком.
– Команда использует инструменты и окружение заказчика.
– Заказчик полностью контролирует процесс разработки.
– При необходимости состав команды меняется.

Преимущества

– Заказчик выбирает, какие инженеры будут работать над проектом.
– Сокращение расходов на подбор и содержание собственного персонала.
– Команда полностью подстраивается под внутренние процессы заказчика.

Применение

– При работе с долгосрочными комплексными проектами.
– Когда нет возможности собрать собственную команду.
– Если нужно быстро расширить существующую команду.

Гибридная модель

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

Принцип работы

– Для каждой части проекта выбирается своя модель.
– Модель оперативно меняется при необходимости.
– Каждая модель оформляется отдельным договором.

Преимущества

– Снижает риски как для заказчика, так и для исполнителя.
– Сочетает в себе плюсы остальных моделей взаимодействия.

Применение

– Если проект начинается в условиях большой неопределённости.
– Когда нужна дополнительная гибкость в финансировании проекта.