+7 (983) 315-86-66 support@sharkdevelop.com
English EN Français FR Русский RU

Fixed price VS Dedicated team: какую схему оплаты выбрать?

| 5 Дек 2018 | Клиентам

Допустим, вы решили разработать программное обеспечение, не имея собственной команды разработчиков. Понятно, что без подрядчика здесь не обойтись. Не ясно другое: как эту работу оплачивать? То есть какую из моделей финансового взаимодействия выбрать: фиксированную ставку или выделенную команду? Что будет рационально именно для вас? Вопрос резонный и волнующий, а потому – давайте разбираться.

Существует ещё одна модель – Time & Material. Прочитать о ней вы сможете в следующей статье.

fixed price vs dedicated team

С точки зрения клиента

Модель с фиксированной ставкой (Fixed price model)

Когда использовать:

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

Модель с фиксированной ставкой любит грамотно и тщательно составленную документацию. Документацию, требования в которой не будут меняться с направлением ветра, настроением и чем бы то ни было. Конечно, договариваться с подрядчиком можно о чем угодно, но если проект идет полным ходом, а вы решаете перевернуть все с ног на голову – пеняйте на себя. И имейте в виду, что дедлайн (с большой вероятностью) будет просрочен, а релиз проекта – задержан.

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

Модель с выделенной командой (Dedicated team model)

Когда использовать:

  • В долгосрочной разработке программного обеспечения, когда текущий план развития подразумевает привлечение дополнительных ресурсов и использование новых технологий.
  • Когда первоначальные потребности и цели неясны, то есть в самом начале не совсем ясно, каким будет конечный результат (например, в случае стартапа).
  • Когда заранее известно, что будут меняться требования к проекту или приоритеты задач (поскольку на вас работает выделенная команда, поменять курс не составит сложностей).

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

Чтобы выбрать модель, действительно целесообразную для вас в каждом конкретном случае, нужно обсудить целый ряд деталей. И обсуждать это стоит непосредственно с подрядчиком.

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

И не бойтесь, что мнение подрядчика будет идти вразрез с тем, что оптимально для вас. Впрочем, вот вам мнение разработчиков относительно каждой из моделей взаимодействия.

С точки зрения разработчика

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

Модель с выделенной командой (Dedicated team model)

Преимущества выделенной команды:

  • Некоторые люди любят знать, что они будут делать следующие несколько месяцев, поэтому они предпочитают стабильность работы в выделенной команде.
  • Модель выделенной команды позволяет разработчику получить более глубокие знания технологий проекта. Осознание того, что скорее всего придется поддерживать проект после окончания его разработки, заставляет разработчиков более четко продумывать его архитектуру, масштабируемость и т.д.
  • Ежедневное общение с заказчиком или его представителем – обязательное требование для таких проектов. Это повышает коммуникативные навыки разработчиков и улучшает взаимопонимание между клиентом и командой.

Минусы выделенных команд:

  • На каждом проекте есть более или менее интересные задачи. Так вот задачи по доработке и поддержке проектов, как правило, относятся к не самым интересным. К примеру, в таком случае, команда может тратить более 20% времени на техподдержку разных проектов заказчика.
  • Поскольку любая выделенная команда – это «компания внутри компании», команда подчиняется всем процессам заказчика. Иногда эти процессы отличаются от тех, к которым они привыкли в своей компании. Тут важную роль играет способность конкретного специалиста приспосабливаться к новым условиям: все очень индивидуально.
  • У выделенных команд обычно упрощенные спецификации на разработку нового функционала или проекта. Это дает им определенную свободу: возможность предлагать свои решения поставленных задач, вместо того чтобы слепо следовать написанным спецификациям. Но и здесь есть свои оговорки: буквально каждое такое решение должно быть согласовано с владельцем продукта на стороне клиента до начала его разработки, что требует от специалиста настойчивости в обосновании своих решений.

Модель с фиксированной ставкой (Fixed price model)

Преимущества проектов с фиксированной ценой:

  • Некоторые разработчики, напротив, любят изменения. Каждый новый проект требует изучения новых технологий, подходов и решений. И четкий дедлайн воспринимается некоторыми специалистами как вызов: достаточно ли они хороши, чтобы справиться с задачей в короткие сроки?
  • Понятные спецификации позволяют более полно взглянуть на проект.
  • Новый проект, к примеру стартап, может рассмотреть предложенное подрядчиком техническое решение, которое наилучшим образом подойдет для реализации проекта, разработки его архитектуры, подбора необходимых инструментов и т.д.
  • Уже на стадии оценки разработчики «разбивают» проект на отдельные задачи, так что клиент заранее представляет, как будет строиться работа. В то время как выделенная команда проделывает то же самое, уже в процессе работы на стороне заказчика.

Минусы проектов с фиксированной ценой:

  • В таких проектах разработчики редко общаются напрямую с заказчиком. Как правило, этим занимается менеджер проектов. А это значит, что успешность проекта во многом зависит от того, насколько хорошо налажен диалог. Но есть и другая сторона: разработчикам не приходится отвлекаться от работы на ежедневные разговоры.
  • Такие проекты нельзя назвать гибкими, ведь риски по умолчанию присутствуют всегда, а при данной модели ими сложно управлять. Все осложняется и тем, что нужно уложиться в бюджет. Но это проблема отнюдь не программиста, а управленца на проекте.

Заключение

Все очень и очень относительно: одни и те же особенности разных моделей могут считаться как плюсами, так и минусами. Причем как для вас, так и для подрядчика. А потому однозначно отвечать на вопрос, какая же из моделей лучше, попросту не имеет смысла. Ведь в каждой конкретной ситуации ответ будет новым. Разговаривайте с подрядчиком, обсуждайте нюансы, приходите к общему знаменателю и принимайте рациональные решения.

Источник: webmartsoft.ru

Недавние посты

Тренды в языках программирования 2019

  2018 запомнится нам открытиями в сфере искусственного интеллекта и машинного обучения, скачками биткоина и развитием блокчейна. Что нас ждет в новом году?   Автоматизация поглощает отрасли целиком. Появляется всё больше...

Монетизация приложения: 6 прибыльных бизнес-моделей, которые работают

  Разработчики создают приложения с разной целью. Кому-то нужно повысить уровень лояльности аудитории к своей компании, кто-то хочет получить больше клиентов, а кто-то просто желает заработать здесь и сейчас.   Зачастую...

Пользователи и пользовательницы: гендерный вопрос в интерфейсе

  Как выбрать обращение, чтобы никого не обидеть, и почему розовый — не универсальное решение для девочек.   Где проявляется пол текст, иконки и изображения, цвета и оформление.   Как делать не надо Иконки и изображения...

Progressive Web Apps – это просто

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

3 причины, почему пользователи уходят из вашего приложения и как это исправить

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

Хотите заказать приложение?

 

Напишите нам