При разработке программного обеспечения государственное предприятие «Астерус» использует несколько вариантов взаимодействия с Заказчиком.

Вариант «Фиксированная цена» 

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

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

Достоинства:

  • Строгие сроки. Когда заказчик понимает, какие функции ему нужны в приложении, разработчики могут прийти к четкому плану и определенным срокам.
  • Предсказуемость. Все обсуждается и планируется заранее, легко отслеживать состояние разработки. Нет необходимости выделять дополнительный ресурс для контроля.

Недостатки:

  • Жесткие условия. Все дополнительные работы (доработки), которые не оценивались с самого начала, подпадают под дополнительное соглашение и оплачиваются отдельно.
  • Риски недопонимания. Всегда существует риск, что недопонимание может привести к разработке продукта, который не совсем соответствует тому, на что рассчитывал клиент.
  • Долгое планирование. Длительный процесс заключения договора с фиксированной ценой. Разработка детального технического задания, дизайна, механизмов взаимодействия, их согласование и утверждение увеличивает сроки реализации самого проекта.

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

Вариант «Время/Материалы»

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

Достоинства:

  • Гибкие требования. Работа делится на небольшие подпроекты. Все функции проверяются должным образом и могут быть добавлены или удалены в любой момент.
  • Почасовые ставки. Заказчик платит установленную почасовую ставку, которая оговаривается с самого начала. Оплата происходит по факту выполненных работ.
  • Качество продукции. Благодаря разбиению крупного проекта на несколько мелких программный продукт можно более тщательно протестировать, исключить из него все недочеты и довести практически до идеала.
  • Прозрачность Вариант «Время/Материалы» позволяет клиентам отслеживать прогресс, так как разработчики представляют отчеты о проделанной работе.

Недостатки:

  • Неопределенные сроки. Внесение изменений в разрабатываемый проект может отсрочить окончательный выпуск на неопределенное время.
  • Неопределенный бюджет. Оценить проект можно только приблизительно, поэтому клиент не знает сколько денег потребуется на его выполнение.
  • Ресурсозатратность. Клиент сам вынужден управлять временем, желанием и возможностями. Чем больше требований, тем дороже проект.
  • Трудные решения. Рынок меняется стремительно, дизайн или функции, которые были реализованы в начале, бывают неактуальными или устаревшими к концу проекта. Приходится принимать решение: переделывать или оставлять как есть.

Вариант «Модель поэтапной работы»

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

Достоинства:

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

Недостатки:

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