Не секрет, что в ИТ-индустрии заказчикам нравятся проекты с фиксированной ценой, потому что это дает им ощущение безопасности (по крайней мере, они так думают). Заказчик обычно хочет иметь больше, исполнитель — делать меньше. Fixed price – это всегда компромисс денег и качества. Цель заказчика – экономить, на что исполнитель обычно отвечает минимально приемлемым качеством продукта. Анализируем плюсы и минусы Fixed Price на примере контрактов тестирования программного обеспечения.
Итак, начнем с самого понятия. Wikipedia дает следующее определение контракта с фиксированной ценой: Fixed Price Contract – это контракт, в котором размер вознаграждения не зависит от количества затраченного времени или ресурсов для достижения бизнес-цели.
Такой контракт – явно неидеальная среда для независимой команды тестирования. Ведь мы не всегда можем точно оценить, сколько времени у нас уйдет на приготовление завтрака или на дорогу до работы, хотя занимаемся этой «рутиной» регулярно. Что уж говорить о тестировании программного обеспечения, где элемент уникальности – неотъемлемая черта.
Для того, чтобы лучше управлять проектом, надо отчетливо понимать, какую цель преследует заказчик, выбирая тип финансового взаимодействия fixed price, и какие внутренние условия могут этому способствовать.
Итак, попробуем проследить образ мысли заказчика. Он думает, что на «фиксированном» проекте удастся сэкономить бюджет. Сумма, которая будет затрачена на реализацию проекта, известна заранее. В этом случае управлять бюджетом легко. При этом команда тестирования будет сосредоточена на основных бизнес-целях проекта и не станет допускать «распыления» средств на второстепенные задачи.
В этом случае, по мнению заказчика, все риски находятся на стороне команды QA. Перерасход бюджета, простои команды, проблемы с окружением – все это забота компании-тестировщика. Ведь если исполнитель «затягивает» сроки, то несет существенные убытки и это не в его интересах. По этой причине заказчик предполагает, что сроки реализации проекта тестирования будут соблюдены.
Кроме того, заказчик вполне может быть не погружен в доменную область требуемого решения. Он может оказаться представителем бизнеса, слабо разбирающимся в IT. Но при этом ему необходим контроль качества создаваемого продукта.
О чем же заранее должен быть осведомлен заказчик, чтобы впоследствии не возникло недопонимания?
Бюджет проекта, скорее всего, будет переоценён исполнителем. Ведь команда QA берет риски на себя не «бесплатно». Неопределенность в требованиях может вылиться в очень существенный перерасход бюджета и это всегда учитывается в оценке.
Может возникнуть ситуация, когда все обязательства по договору выполнены, однако бизнес-требования заказчика не удовлетворены. Например, проведя функциональное тестирование, но отказавшись от нагрузочного, можно на выходе получить продукт, который соответствует всем функциональным требованиям, однако, из-за крайне низкого быстродействия, не применим в бизнесе.
Сроки исполнения контрактных обязательств стороной тестирования могут быть нарушены по объективным причинам. Например, после длительного перерыва необходимо заново собрать команду. Если не удалось привлечь специалистов, которые ранее работали на проекте, потребуется время на «введение» в проект новичков.
Модель Fixed Price не позволяет заказчику иметь на своем проекте выделенную команду тестировщиков, поскольку возможно перераспределение кадров в пользу заказчиков на Dedicated Team или Тime & Material. Это не значит, что заказчик не важен, но в случае необходимости выбирать между проектами, решение определенно будет принято не в его пользу.
