Не секрет, что в ИТ-индустрии заказчикам нравятся проекты с фиксированной ценой, потому что это дает им ощущение безопасности (по крайней мере, они так думают). Заказчик обычно хочет иметь больше, исполнитель — делать меньше. Fixed price – это всегда компромисс денег и качества. Цель заказчика – экономить, на что исполнитель обычно отвечает минимально приемлемым качеством продукта. Попытаемся проанализировать плюсы и минусы Fixed Price на примере контрактов тестирования программного обеспечения, которые в можно считать типичными для целого ряда ситуаций внедрения корпоративных информационных систем. Этот анализ будет полезен как стороне тестирования, так, безусловно, и менеджерам команды разработки, в том числе, работающим в командах корпоративного заказчика.

Итак, начнем с самого понятия. Wikipedia дает следующее определение контракта с фиксированной ценой: Fixed Price Contract – это контракт, в котором размер вознаграждения не зависит от количества затраченного времени или ресурсов для достижения бизнес-цели.

Такой контракт – явно неидеальная среда для независимой команды тестирования. Ведь мы не всегда можем точно оценить, сколько времени у нас уйдет на приготовление завтрака или на дорогу до работы, хотя занимаемся этой «рутиной» регулярно. Что уж говорить о тестировании программного обеспечения, где элемент уникальности – неотъемлемая черта.

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

Итак, попробуем проследить образ мысли заказчика. Он думает, что на «фиксированном» проекте удастся сэкономить бюджет. Сумма, которая будет затрачена на реализацию проекта, известна заранее. В этом случае управлять бюджетом легко. При этом команда тестирования будет сосредоточена на основных бизнес-целях проекта и не станет допускать «распыления» средств на второстепенные задачи.

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

Кроме того, заказчик вполне может быть не погружен в доменную область требуемого решения. Он может оказаться представителем бизнеса, слабо разбирающимся в IT. Но при этом ему необходим контроль качества создаваемого продукта.

О чем же заранее должен быть осведомлен заказчик, чтобы впоследствии не возникло недопонимания?

    1. Бюджет проекта, скорее всего, будет переоценён исполнителем. Ведь команда QA берет риски на себя не «бесплатно». Неопределенность в требованиях может вылиться в очень существенный перерасход бюджета и это всегда учитывается в оценке.
    2. Может возникнуть ситуация, когда все обязательства по договору выполнены, однако бизнес-требования заказчика не удовлетворены. Например, проведя функциональное тестирование, но отказавшись от нагрузочного, можно на выходе получить продукт, который соответствует всем функциональным требованиям, однако, из-за крайне низкого быстродействия, не применим в бизнесе.
    3. Сроки исполнения контрактных обязательств стороной тестирования могут быть нарушены по объективным причинам. Например, после длительного перерыва необходимо заново собрать команду. Если не удалось привлечь специалистов, которые ранее работали на проекте, потребуется время на «введение» в проект новичков.
    4. Модель Fixed Price не позволяет заказчику иметь на своем проекте выделенную команду тестировщиков, поскольку возможно перераспределение кадров в пользу заказчиков на Dedicated Team или Тime & Material. Это не значит, что заказчик не важен, но в случае необходимости выбирать между проектами, решение определенно будет принято не в его пользу.

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

    Итак, вариант WIN-LOSE – заказчик «продавил» команду внешнего тестирования на исполнение всех требований с превышением бюджета, проиграл в сроках, но не понес дополнительных затрат. Для команды тестирования проект будет в такой ситуации глубоко убыточным.

    LOSE-WIN – команда тестирования выполнила функциональные требования заказчика и успела все сделать в срок. Но в таком виде приложение часто не готово выйти на рынок. Все дополнительные работы заказчику предложено выполнить отдельно за дополнительную плату. Тогда заказчик задумается: за тестирование он заплатил и рассчитывал с помощью приложения достичь определенного результата. Но в итоге – нет ни успешного продукта, ни денег.

    LOSE-LOSE – это крайне нежелательный и редко встречающийся в практике вариант. В этом случае команда тестирования заваливает проект и решает, что дальше продолжать убыточный проект просто не имеет смысла. Заказчик также в этом случае теряет и деньги и время.

    Но есть ли вариант WIN-WIN, когда в выигрыше обе стороны? Да! И об этом подробнее.

    Вводные для тестирования просты – необходимо достичь поставленных перед QA целей в рамках запланированного бюджета. Предоставляемый заказчику сервис должен быть стабилен при любых условиях. Что для этого необходимо? С организационной точки зрения – высокая дисциплина в команде, регулярный контроль бюджета, плавный рост команды от старта к финишу и запас на конечную фазу. С точки зрения тестирования, начинать реализацию QA проекта с fixed-price можно при соблюдении следующих условий:

    • Сроки старта работ согласованны, есть подтверждение от всех заинтересованных сторон.
    • Тестовое окружение настроено и все необходимые права доступа для тестирования получены.
    • Подготовлены все необходимые тестовые данные.
    • Собрана новая версия программного обеспечения. Есть уведомление (нотификация) от команды разработки.

    Если вы успешно стартовали – переходите к менеджменту. И здесь может поджидать множество угроз, для предотвращения которых надо соблюдать следующие правила:

    • Строгий контроль бюджета и сроков
    • Управление бизнес-процессами на стороне разработки должно соответствовать необходимому уровню, синхронизироваться с тестированием. Если этого нет, нужно предпринять меры для тиражирования процессов планирования QA на команду разработки. Это не всегда получается, но в практике бывают примеры успешной синхронизации с командой девелопмента.
    • Контроль и управление требованиями на протяжении всего проекта. Это функции бизнес-аналитика, однако они не всегда успевают за разработкой. Требования необходимо поддерживать в актуальном состоянии, согласовывать процесс их изменений, при этом указав допустимые границы.
    • Контроль рисков – это целая наука и, к сожалению, многие проектные менеджеры ею пренебрегают. Часто есть риск, что сдвиг сроков разработки (который влияет на дату поставки версии «в тестирование») не будет учтён в плане работ по тестированию, и, как следствие – срыв сроков.
    • Оценка трудозатрат перед каждой итерацией – фрагментирование работ и проверка перед каждой итерацией позволит на раннем этапе определить есть ли проблемы с бюджетом. Обновление стратегии тестирования происходит по ситуации.

    Ну а каковы условия успешности формата fixed price с точки зрения разработки?

    Эта модель подходит для команды девелопмента, если:

    • для разработки ключевым фактором является скорость вывода продукта на рынок;
    • все технические требования не могут быть детально проработаны до начала разработки;
    • проект подразумевает разработку комплексного масштабного приложения со сложной функциональностью;
    • это небольшой проект (до 1 месяца);
    • когда есть уверенность, что ТЗ не будет меняться;
    • легко управлять бюджетом и cash-flow, можно выделить большую сумму (или чаще всего частями) и точно знать, когда ее заплатишь.

    По мнению заказчика, дедлайны и ответственность будут стимулировать команду. Они БУДУТ напрягаться, так как отвечают за результат (в том числе финансово).

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