01 февраля 2014
Плюсы и минусы фиксированной стоимости оплаты.
Плюсы и минусы фиксированной стоимости оплаты.
Существует два основных подхода в разработке программного обеспечения:
- Контракт с зафиксированной стоимостью оплаты (fixed price).
- Договор с почасовой оплатой труда (time & material).
Fixed price
При фиксированной оплате труда стороны заранее договариваются о стоимости проекта. При этом изначально все требования документируются в виде подробного технического задания, а также прототипа.
При таком подходе сторонам довольно легко планировать бюджеты и сроки. Однако, как известно, в техническом задании невозможно отразить абсолютно все требования, а также заложить предполагаемые изменения user-story. В ходе реализации или на этапе тестирования проекта нередко становится очевидно, что некоторые функции становятся не нужны, некоторых не хватает, а какие-то хотелось бы получить в другом виде, отличающимся от запланированного изначально.
Поскольку проект имеет фиксированный бюджет и требования, разработка продолжает вестись в рамках документации, в результате чего в конце проекта нередко формируется большой список доработок и улучшений, что может привести ко второй крупной итерации по доработке проекта.
Исполняя проект, по контракту с зафиксированной стоимостью, подрядчик полностью несет все риски, что отражается на конечной стоимости предложения. К оценке добавляется от 50% до 200% дополнительно заложенных трудозатрат в виде коэффициента неопределенности. Это ведет к дополнительным расходам со стороны заказчика.
Time & material
В случае применения подхода time&material оплата производится за затраченные над проектом часы. При этом нет необходимости разрабатывать детальные технические задания, поскольку разработка движется небольшими (например, недельными) итерациями. Эта схема очень хорошо сочетается с такими гибкими методологиями разработки, как Agile. Прозрачность данного подхода позволяет постоянно быть в курсе событий и непосредственно влиять на процесс разработки.
В случае необходимости перед каждой итерацией производится предварительная оценка поставленных задач. Поскольку при этом оцениваемые задачи зачастую достаточно небольшие, то становится проще получить более точную оценку, что в конечном итоге также минимизирует риски.
В данном подходе заказчик тесно взаимодействует с сотрудниками исполнителя, участвуя на каждом этапе создания проекта. Таким образом уделяется большое внимание деталям, что гарантирует высокое качество конечного результата. При этом в любой момент могут проводиться различные тестирования, в том числе и на реальных пользователях, чтобы можно было заранее внести коррективы в проект. Также производится выгрузка кода в репозиторий заказчика, при этом специалисты заказчика имеют возможность проверить качество кода и провести интеграцию необходимых компонентов в любой момент.
Ввод нового функционала не требует разработки новых технических заданий, составления дополнительных соглашений и т.д. Если необходимо, просто заводится задача в баг-трекере, проводится обсуждение с разработчиком и новый функционал внедряется либо безотлагательно, либо согласно плану менеджера проекта со стороны заказчика.
Процесс управления финансами упрощается, поскольку уже на самых ранних этапах видна скорость работы исполнителей и в случае необходимости могут быть приняты решения отложить тот или иной функционал или же сменить подрядчика. При этом риск переплаты сводится практически к 0.
В случае необходимости убедиться в добропорядочности исполнителя, возможно применение таких инструментов контроля, как скриншоты экрана, трекер активности пользователя, просмотр списка посещенных веб-ресурсов и т.д.
Существует два основных подхода в разработке программного обеспечения:
- Контракт с зафиксированной стоимостью оплаты (fixed price).
- Договор с почасовой оплатой труда (time & material).
Fixed price
При фиксированной оплате труда стороны заранее договариваются о стоимости проекта. При этом изначально все требования документируются в виде подробного технического задания, а также прототипа.
При таком подходе сторонам довольно легко планировать бюджеты и сроки. Однако, как известно, в техническом задании невозможно отразить абсолютно все требования, а также заложить предполагаемые изменения user-story. В ходе реализации или на этапе тестирования проекта нередко становится очевидно, что некоторые функции становятся не нужны, некоторых не хватает, а какие-то хотелось бы получить в другом виде, отличающимся от запланированного изначально.
Поскольку проект имеет фиксированный бюджет и требования, разработка продолжает вестись в рамках документации, в результате чего в конце проекта нередко формируется большой список доработок и улучшений, что может привести ко второй крупной итерации по доработке проекта.
Исполняя проект, по контракту с зафиксированной стоимостью, подрядчик полностью несет все риски, что отражается на конечной стоимости предложения. К оценке добавляется от 50% до 200% дополнительно заложенных трудозатрат в виде коэффициента неопределенности. Это ведет к дополнительным расходам со стороны заказчика.
Time & material
В случае применения подхода time&material оплата производится за затраченные над проектом часы. При этом нет необходимости разрабатывать детальные технические задания, поскольку разработка движется небольшими (например, недельными) итерациями. Эта схема очень хорошо сочетается с такими гибкими методологиями разработки, как Agile. Прозрачность данного подхода позволяет постоянно быть в курсе событий и непосредственно влиять на процесс разработки.
В случае необходимости перед каждой итерацией производится предварительная оценка поставленных задач. Поскольку при этом оцениваемые задачи зачастую достаточно небольшие, то становится проще получить более точную оценку, что в конечном итоге также минимизирует риски.
В данном подходе заказчик тесно взаимодействует с сотрудниками исполнителя, участвуя на каждом этапе создания проекта. Таким образом уделяется большое внимание деталям, что гарантирует высокое качество конечного результата. При этом в любой момент могут проводиться различные тестирования, в том числе и на реальных пользователях, чтобы можно было заранее внести коррективы в проект. Также производится выгрузка кода в репозиторий заказчика, при этом специалисты заказчика имеют возможность проверить качество кода и провести интеграцию необходимых компонентов в любой момент.
Ввод нового функционала не требует разработки новых технических заданий, составления дополнительных соглашений и т.д. Если необходимо, просто заводится задача в баг-трекере, проводится обсуждение с разработчиком и новый функционал внедряется либо безотлагательно, либо согласно плану менеджера проекта со стороны заказчика.
Процесс управления финансами упрощается, поскольку уже на самых ранних этапах видна скорость работы исполнителей и в случае необходимости могут быть приняты решения отложить тот или иной функционал или же сменить подрядчика. При этом риск переплаты сводится практически к 0.
В случае необходимости убедиться в добропорядочности исполнителя, возможно применение таких инструментов контроля, как скриншоты экрана, трекер активности пользователя, просмотр списка посещенных веб-ресурсов и т.д.