Бизнес-модели в IT- аутсорсинге. Часть 2. Оплата по фактически затраченному времени

Что видится на поверхности

Модель отлично подходит для взаимодействия с разработчиками в следующих условиях

1. Невозможно заранее учесть и оценить все требования, которые изменчивая бизнес-среда предъявляет к проекту;
   
2. Невозможно заранее определить и обозначить функционал системы в полном объеме;
3. Существует большая вероятность, что требования и, соответственно, характеристики решения изменятся в процессе реализации проекта.

Как правило, последовательность действий здесь следующая:

1. Проводится бизнес-анализ с целью выявления базовых историй и требований по проекту;
2. Создается исходное техническое задание на разработку программного обеспечения, являющееся преимущественно отправной точкой нежели основополагающим документом;
3. Разработчик предварительно оценивает объем работ и озвучивает свою часовую ставку;
4. Заключается контракт на разработку ПО, в котором фиксируется не цена контракта, а лишь часовая ставка.

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

Глубокое понимание и риски

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

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

Ниже представлены наиболее частые опасения заказчиков относительно рисков манипуляций со стороны разработчиков:

1. Разработчики заявят большее количество часов, чем они фактически потратили;
2. Разработчики использовали заявленное время неэффективно (низкая квалификация, низкая скорость выполнения задач).

Однако есть отличный способ избежать подобных рисков:

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

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