Бизнес-модели в IT- аутсорсинге. Часть 2. Оплата по фактически затраченному времени
Что видится на поверхности
Модель отлично подходит для взаимодействия с разработчиками в следующих условиях
- Невозможно
заранее учесть и оценить все требования, которые изменчивая бизнес-среда
предъявляет к проекту;
- Невозможно заранее определить и обозначить функционал системы в полном объеме;
- Существует большая вероятность, что требования и, соответственно, характеристики решения изменятся в процессе реализации проекта.
Как правило, последовательность действий здесь следующая:
- Проводится бизнес-анализ с целью выявления базовых историй и требований по проекту;
- Создается исходное техническое задание на разработку программного обеспечения, являющееся преимущественно отправной точкой нежели основополагающим документом;
- Разработчик предварительно оценивает объем работ и озвучивает свою часовую ставку;
- Заключается контракт на разработку ПО, в котором фиксируется не цена контракта, а лишь часовая ставка.
Очевидно, что данная модель
отлично подходит для больших и сложных проектов, реализация которых осуществляется
по методологии гибкой разработки (agile).
Данная бизнес-модель предоставляет
заказчику значительный контроль над проектом. При этом речь идет о контроле не
только качества продукта, получаемого на выходе, но и непосредственно самого
конвейера проекта. В качестве инструментов контроля используются обзоры
спринтов и отчеты, а также различные KPI, установленные в рамках проекта и
каждого из отдельных спринтов. В то же время, несмотря
на то, что модель предполагает большую гибкость с точки зрения внесения изменений,
повышения ценности разрабатываемой информационной системы и контроля над
проектом, некоторые заказчики могут отнестись к ней с опаской. Причина, прежде
всего, в том, что подобная схема оплаты требует абсолютного доверия к
надежности поставщика и его приверженности целям заказчика. Ниже представлены наиболее
частые опасения заказчиков относительно рисков манипуляций со стороны разработчиков: Однако есть отличный способ избежать подобных рисков: В первом случае, по сути,
фиксируется максимальное количество часов в неделю, которое разработчик может
предъявить к оплате. Во втором случае, заказчик получает мощный инструмент оперативного контроля над прогрессом по проекту и количеству затраченного времени по каждой из выполненных задач. И, наконец, в третьем случае, заказчик может составить достаточно четкое
представление о скорости и общей производительности разработчиков, задействованных
в проекте, и тем самым практически нивелировать риски неэффективного
использования рабочего времени.
Глубокое понимание и риски