Fixed Price, Time & Materials и Retainer: что выбрать для разработки ИТ-решения

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

Всё сверх ТЗ — за дополнительную плату. Если в процессе работы над проектом по Fixed Price заказчик понял, что ему нужно что-то еще, заключается дополнительное соглашение с отдельной оплатой к уже заключенному договору.

Увеличенная стоимость часа работы. Исполнитель берет на себя обязательство, что проект будет выполнен в срок и без доплат. Поэтому в рейты на Fixed Price закладываются все возможные риски (как со стороны заказчика, так и со стороны исполнителя), привлечение руководителей проектов и других специалистов.

Fixed Price — идеальная модель для работы над проектами с четкими требованиями, ограниченным бюджетом и определенными сроками:

• для небольших сайтов — корпоративных, лендингов, одностраничников;
• для отдельного блока работ над сайтом — разработки конкретных инструментов (например, калькуляторов), точечной автоматизации бизнес-процессов;
• для MVP (от анг. minimum viable product — минимально жизнеспособный продукт) — первой версии ИТ-продукта, обладающей минимальным набором функций, достаточных для удовлетворения потребностей пользователей.

Мы работаем по Fixed Price над добавлением дополнительных функциональных блоков в продукт для постоянного клиента, техническим аудитом систем, предпроектной аналитикой.

Мы понимаем, что изменения в процессе разработки бывают критическими для для успеха проекта, а Fixed Price их запрещает. Поэтому индивидуальную разработку по этой модели мы организовываем, используя Wagile-подход, благодаря которому оставляем границы проекта по Fixed Price, но добавляем гибкости для получения более эффективного результата.

Гибкость. Работая с подрядчиком по T&M, заказчик волен добавлять или удалять функции и возможности в проекте в любой момент без заключения дополнительных договоров и соглашений. Важно только помнить, что любая новая задача — это время команды разработчиков, за которое потом нужно будет заплатить.

Прозрачный процесс. Работая по T&M, разработчики всегда держат клиента в курсе текущих дел на проекте: регулярные встречи с заказчиком, презентации и постоянное логирование времени в тайм-трекерах. Мы на проектах по T&M раз в пару недель проводим демо для клиентов и каждый месяц присылаем отчет о том, что было сделано, и сколько часов это заняло.

Лучше всего T&M подходит для больших проектов, требующих гибкости и не имеющих определенного ТЗ и списка функциональных требований.

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

Стабильность. На клиента работают одни и те же люди, неизменное количество часов в месяц за «железную» сумму. Ни один из этих параметров не изменится на протяжении всего действия Retainer-договора.

Гибкость. Как и в случае с T&M, заказчик волен менять требования, ставить задачи и добавлять функциональность. Важно только помнить, что время команды на реализацию ограничено договором.

Неизрасходованные часы сгорают. Если клиент оплачивает 30 часов в месяц, а команда справляется с поставленными задачами за 20, разница сгорает, а не переносится на следующий месяц.

Retainer подходит, когда у заказчика есть масштабный проект, который нужно разрабатывать или развивать, а своего IT-отдела нет, или его нужно усилить кадрами извне, нанять готовую команду разработки:

• для стартапов и компаний с идеей, но без компетенции в IT;
• для крупных постоянно развивающихся сервисов, работа над которым не останавливается и после релиза;
• для проектов на поддержке.

Продуктовая и заказная разработка требует гибкости, поэтому порой полезно переходить от одной модели сотрудничества к другой.

Этому есть две причины.

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

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