Стоимость системы

Варианты договоров

Две наиболее популярные схемы оплаты разработки программного обеспечения — это проекты с фиксированной стоимостью (Fixed-Cost) и проекты с повременной оплатой (Time-and-Material). В зависимости от пожеланий наших клиентов мы используем одну из этих схем, а иногда некоторые гибридные схемы.

В схеме с фиксированной стоимостью (Fixed-Cost) стоимость известна заранее и заказчик может с ней либо согласиться либо не согласиться. Заказчик может планировать свой бюджет. При этом все риски лежат на нас. Даже если окажется, что мы недооценили сложность проекта, мы все равно гарантированно доводим его до запланированного результата в рамках запланированного бюджета. Обычно, когда компании требуется выполнить небольшой или средний проект, заказчики выбирают именно такую схему.

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

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

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

Гибридные договоры могут, например, предусматривать разработку требований по схеме Time & Material, с последующей разработкой по схеме Fixed-Cost. Возможен также вариант, когда работы в рамках технического задания выполняются по фиксированной схеме, а все изменения и доработки, не предусмотренные ТЗ, выполняются по схеме с почасовой оплатой. Выбор варианта договора зависит от специфики проекта и пожеланий заказчика.

Схема с фиксированной оплатой

Обычно это выглядит так: потенциальный клиент приходит с некоторым запросом. Мы интервьюируем ключевых сотрудников. Затем мы пишем ТЗ высокого уровня, называемый также «бизнес-требования» или BRD (business requirements document). Этот документ описывает ЧТО система должна делать. Вопросы КАК делать обычно детализируются в последующих документах.

Для большинства средних проектов достаточно 3-5 дней, чтобы завершить такой документ.

Мы называем «средним» проект с бюджетом 25.000$-75.000$. Для более крупных проектов может потребоваться от недели до месяца работы аналитиков для написания и согласования бизнес-требований.

Для средних проектов мы можем разработать бизнес-требования бесплатно на свой страх и риск. Бизнес-требования — это главный инструмент коммуникации между нами и заказчиком, позволяющий гарантировать, что мы говорим об одних и тех же вещах на одном языке и понимаем друг друга. Обычно бизнес-требования утверждаются на уровне высшего руководства компании заказчика. Бизнес-требования также хороши тем, что по ним можно примерно оценить стоимость проекта. Точность оценки обычно составляет около 60%. Т.е. мы, например, можем гарантировать, что стоимость реализации будет находиться в диапазоне от 30.000$ до 50.000$.

Если этот диапазон устраивает заказчика, мы договариваемся о разработке детальных функциональных требований или FRD (Functional Requirement Document). Это уже более объемный документ с проработанными сценариями, диаграммами состояний, форматами данных. Все существенные вопросы проработаны, прошли через обсуждение и закрыты. Этот документ позволяет программисту «сесть и начать писать». В дальнейшем, когда система готова, этот документ используется техническим писателем для разработки пользовательской документации.

Стоимость разработки функциональных требований для средних проектов составляет 2.000-5.000$. Эта работа может оформляться отдельным договором либо входить в основной договор в качестве первого этапа. Как правило для системы среднего размера удается разработать и согласовать FRD за 4-6 недель. Если речь идет о разработке более крупной системы, мы всегда стараемся предложить клиентам итеративный подход.

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

Договор на разработку системы обычно разбивается на несколько этапов. По каждому этапу оговаривается набор результатов, которые позволяют заказчику контролировать прогресс разработки. Типичное описание этапов из договора выглядит так:
№ Основное содержание этапа Передаваемая документация и материалы Сроки окончания этапа Стоимость в % от стоимости всей работы
1. Детальное техническое задание Техническое задание в формате PDF 31 марта 2008 25
2. Разработка онлайновых отчетов Онлайновые отчеты в среде Исполнителя 22 апреля 2008 25
3. Разработка оффлайновых отчетов Оффлайновые отчеты в среде Исполнителя 15 мая 2008 25
4. Разработка полнофункциональной версии системы, включая административный интерфейс и экспорт в CSV. Рабочая версия в среде Заказчика План развертывания системы. Полнофункциональная версия в среде Заказчика. 30 мая 2008 25

Схема с повременной оплатой

В этом случае заказчику необходимо несколько сотрудников с определенной квалификацией (skill-set). Мы предоставляем сотрудников на условиях повременной оплаты. Каждый сотрудник ежедневно заполняет табель учета рабочего времени. Счет выставляется в соответствии с реально отработанным временем на проекте заказчика.

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

Раз в месяц мы выставляем заказчику счет с полной детализацией рабочего времени на проекте и итоговой суммой к оплате.