Фиксированная цена за сайт или оплата по факту выполненных работ

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

Казалось бы, это идеальная для заказчика модель сотрудничества с IT-компанией. Но если бы все было так просто, как кажется, мы бы не начали писать эту статью. Альтернатива фиксированному ценнику — гибкое ценообразование, также известное как Time and Materials (или T&M). При такой модели сотрудничества заказчик изначально не знает, сколько будут стоить услуги IT-компании, и когда вообще будет завершен проект. Звучит, как очень плохое предложение, но у него тоже есть свои плюсы, уж поверьте.

Преимущества и недостатки фиксированного и гибкого ценообразования при реализации IT-проектов мы бы и хотели рассмотреть в этом материале.

При планировании IT-разработки или реализации какого-то проекта команды применяют два разных метода организации работы:

• Waterfall. Это последовательное планирование задач. Например, сначала утверждение проектной документации, потом разработка, потом тестирование, потом сдача заказчику и внесение правок. Работы над проектом выстроены в цепочку последовательных действий, которое идет одно за другим. Визуализировать такой подход проще всего в диаграмме Ганта, в которой конец одной задачи по времени отмечает начало следующей

• Agile. Так называемый гибкий метод менеджмента проектов. У него нет четкой выстроенной по времени структуры, как у Waterfall. Объем работы вообще практически невозможно спрогнозировать вначале. Работа делится на отрезки — спринты, в рамках которых выполняется конкретный и законченный объем работы. В рамках каждого спринта, определенный участок работы делается полностью, в том числе с тестированием. После спринта, команда и заказчик осматриваются, оценивают сделанное, и на основе этого планируют следующий спринт.

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

Как вы уже, наверное, догадались, методы организации работы напрямую влияет на модель оплаты. Четко обозначить сроки и стоимость выполнения проекта можно только при модели Waterfall, когда ключевые этапы разработки последовательно выстроены и оценены по времени. В таком случае заказчик еще до начала работы утверждает проектную документацию, менеджер рассчитывает необходимо время на утвержденные задачи. Также, легко посчитать окончательную стоимость проекта, потому что в IT основные издержки компании — это время специалистов, а оно заранее оценено и посчитано.

Другое дело — Agile, здесь невозможно заранее посчитать время (и окончательную стоимость, само собой, тоже). Над проектом можно работать и проводить новые спринты бесконечно, пока окончательный результат не устроит заказчика. Более того, дополнительные спринты с обновлениями можно делать и после окончательного запуска проекта. Поэтому для Agile модели подходит только оплата по факту выполненных работ.

Начнем с плюсов.

• Точный расчет цены и сроков. Об этом мы уже сказали выше. При Waterfall модели организации работы, компания может точно сказать заказчику, сколько времени и средств нужно на реализацию проекта. Точная информация о затратах и сроках очень важна для заказчика. Руководитель может прогнозировать работу компании и движение денежных средств.
• Клиент еще до начала работы понимает, какой продукт получит. Менеджер составляет проектную документацию, в которой полностью описан функционал. Работы начнутся только после утверждения функционального задания. Специалисты компании точно переведут проектную документацию в готовый продукт.
• Полная прозрачность как для членов команды, так и для заказчиков. Все стороны точно понимают, на каком этапе сейчас находится проект, и когда будет закончен.

Но есть и недостатки у такого подхода

• Во-первых, отсутствие гибкости. После утверждения проектной документации, бесплатно внести правки уже не получится. Любые дополнительные работы — это время сотрудников компании, которое будет увеличивать смету.
• Не стоит ориентироваться на обозначенную в начале стоимость, скорее всего, вы захотите что-то доработать и изменить. Обычно, первые идеи по доработке и внесению правок в проект, приходят в голову заказчику сразу после окончания разработке. Почти невозможно все предусмотреть с самого начала. После того как вы получите готовый продукт — сайт, приложение или учетную систему, и впервые попробуете им воспользоваться, у вас сразу появятся идеи, как его можно сделать удобнее, лучше и эффективнее. Но для доработок нужно создавать новую проектную документацию и осмечивать время специалистов.
• Скорость разработ. Последовательное планирование и выполнение задач, в среднем, требует больше времени, чем работа Agile-спринтами. Но это не аксиома — есть достаточно много Waterfall команд, которые в скорости могут составить конкуренцию. Многое зависит от особенностей проекта, итогового объема работы и профессионализма руководителя/сотрудников компании-исполнителя.

С другой стороны, в Agile вы тоже столкнетесь с этой же проблемой. Сдельная оплата труда специалистов = дополнительная оплата за правки, тут никакого выигрыша нет. Фиксированная оплата за проект и сотрудничество с командами, работающими по принципу Waterfall подходит для абсолютного большинства IT-задач корпоративных заказчиков. Мы рекомендуем ее для разработки корпоративных сайтов, внедрения CRM-систем, настройки учетных систем 1С и многих других стандартных задач бизнеса. За редким исключением (о которых мы расскажем ниже) IT проекты на заказ стоит реализовывать именно по Waterfall модели с заранее известными сроками и ценой работ.

На самом деле, при таком подходе плюсы и минусы будут зеркальны Waterfall-модели с заранее известной стоимостью и сроками реализации. Начнем с плюсов:

• Гибкость. Результат и объем работ заранее неизвестны. Заказчик вместе с командой проекта может хоть после каждого спринта менять цель, структуру, дизайн, функционал и другие переменные. Он может основываться на результате уже выполненной работы. В итоге, проект эволюционирует по ходу разработки. Нет необходимости все продумывать заранее, решения можно принимать в процессе работы над продуктом.
• Высокая скорость работы. В большинстве случаев разработка короткими спринтами, по итогам которых часть проекта сразу тестируется и корректируется,быстрее, чем последовательное выполнение задач, в котором каждый последующий этап зависит от скорости завершения предыдущего.
• Снижение влияния ошибок и недочетов. Уже упомянутое выше периодическое тестирование после каждого спринта позволяет быстро находить как технические ошибки, допущенные разработчиками, так и недочеты проекта в целом. Чем быстрее найдена ошибка, тем меньше вреда она нанесет, поскольку не повлияет на последующую работу.
• Сокращение времени на составление проектной документации. При Waterfall модели план реализации проекта нужно максимально детально продумать заранее. Иногда, для сложных проектов составление документации может занять существенный срок, вплоть до нескольких месяцев. Особенно если заказчик постоянно вносит в него правки. При гибком Agile подходе эта проблема исчезает. Достаточно просто схематично обозначить контуры конечного продукта и запланировать первый спринт. Дальше проблемы решаются по мере их возникновения, а новые спринты планируются с учетом полученного результата.

Теперь о недостатках:

• Во-первых, очевидно, что невозможно заранее запланировать ни время, ни бюджет проекта. Нет предела совершенству, новые спринты с доработками и новым функционалом можно проводить бесконечно, пока заказчик в этом заинтересован. Это большая проблема, поскольку бизнес не может планировать ни свою работу, с учетом времени запуска продукта, ни бюджет (изначально непонятно, сколько денег будет потрачено).
• Не всегда понятно, какой именно продукт будет получен в конце. «Открытый конец» гибкой разработки — это еще одна проблема для бизнеса. Да, основные цели и контуры проекта обозначаются заранее, но гибкая разработка может сильно увести конечный продукт от изначальных ориентиров. Планировать дальнейшую работу компании после внедрения разработанного продукта также достаточно сложно.
• Постоянное включение заказчика в работу. Еще один недооцененный недостаток. При Waterfall модели организации разработки проекта с фиксированной оплатой роль заказчика (и его сотрудников) ограничивается взаимодействием на этапе планирования и составления проектной документации. И уже после сдачи проекта, при внедрении и обучении сотрудников они тоже нужны, но непосредственно в разработке и оценке промежуточных результатов они не участвуют (максимум, консультативная роль). В Agile заказчик должен быть включен в работу над проектом постоянно. Оценивать промежуточные результаты, планировать новые спринты, думать над развитием проекта на этапе разработки. Это не всегда минус, в отдельных случаях по-другому поступить и нельзя.

Для того чтобы Agile метод организации проекта стал оптимальным выбором, должно одновременно соблюдаться 2 условия:

• Во-первых, заказчик должен полностью и беспрекословно доверять компании-исполнителем. В противном случае обязательно возникнет недоверие и ощущение раздутости сроков. Это главная проблема сдельной оплаты Time and Materials (T&M). Заказчику будет казаться, что конкретную задачу или группу задач можно решить быстрее, а подрядчик только затягивает время, чтобы раздуть смету.
• Во-вторых, это должен быть сложный проект, требующий постоянного участия заказчика. Обычно — это IT-стартапы или бизнесы, основанные на каких-то программных продуктов. Тогда руководитель может быть постоянно включен в разработку и участие в проекте, да и к тому же полностью спланировать продукт на этапе составления проектной документации достаточно сложно.

Вот в таких случаях Agile подходит даже лучше, но повторим еще раз, для большинства стандартных IT-задач корпоративных клиентов лучше выбирать команды, работающие по Waterfall-модели с фиксированной оплатой. Не знаете, какой метод подойдет вам? Мы еще сильнее усложним выбор.

На самом деле, между Agile и Waterfall выбор не безальтернативный. Некоторые команды используют гибридные методы организации работы, при которых выстроена критическая цепочка последовательных задач, позволяющая оценить сроки. Но при этом в самом процессе разработке применяются Agile спринты и параллельное выполнение задач.

Таким образом получается использовать преимущества обеих моделей одновременно. И достаточно четко определенные сроки/бюджет, и гибкость со скоростью выполнения задач.

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