Допустим, вы решили разработать программное обеспечение, не имея собственной команды разработчиков. Понятно, что без подрядчика здесь не обойтись. Не ясно другое: как эту работу оплачивать? То есть какую из моделей финансового взаимодействия выбрать: фиксированную ставку или выделенную команду? Что будет рационально именно для вас? Вопрос резонный и волнующий, а потому – давайте разбираться.
Существует ещё одна модель — Time & Material. Прочитать о ней вы сможете в следующей статье.
С точки зрения клиента
Модель с фиксированной ставкой (Fixed price model)
Когда использовать:
- Когда проект краткосрочный.
- Когда у вас есть полное описание проекта, с указанием четких целей, рабочих процессов и результатов.
- Когда вероятность того, что требования к проекту изменятся, ничтожно мала.
- Когда вы работаете с новым исполнителем (пилотный проект с фиксированной оценкой может стать отличной проверкой подрядчика, который обещает быть вашим постоянным партнером).
Модель с фиксированной ставкой любит грамотно и тщательно составленную документацию. Документацию, требования в которой не будут меняться с направлением ветра, настроением и чем бы то ни было. Конечно, договариваться с подрядчиком можно о чем угодно, но если проект идет полным ходом, а вы решаете перевернуть все с ног на голову – пеняйте на себя. И имейте в виду, что дедлайн (с большой вероятностью) будет просрочен, а релиз проекта – задержан.
В форс-мажорных ситуациях необходимо определить, насколько важны изменения для текущей версии продукта. Если менять состав задач все-таки нужно, но отодвинуть дедлайн при этом нет возможности, остается разве что вариант жертвовать другими задачами.
Модель с выделенной командой (Dedicated team model)
Когда использовать:
- В долгосрочной разработке программного обеспечения, когда текущий план развития подразумевает привлечение дополнительных ресурсов и использование новых технологий.
- Когда первоначальные потребности и цели неясны, то есть в самом начале не совсем ясно, каким будет конечный результат (например, в случае стартапа).
- Когда заранее известно, что будут меняться требования к проекту или приоритеты задач (поскольку на вас работает выделенная команда, поменять курс не составит сложностей).
Преимущество модели с выделенной командой в том, что последняя находится в полном вашем распоряжении: поставщик услуг предоставил инфраструктуру, административную поддержку и специалистов, а уж вы вправе диктовать им методологию разработки и практики, техническую платформу и даже корпоративную культуру и политику. Команда находится на удаленном расстоянии, но выполняет все, чем должна заниматься команда, находящаяся у вас в офисе. По сути, функции менеджера проекта остаются за вами.
Чтобы выбрать модель, действительно целесообразную для вас в каждом конкретном случае, нужно обсудить целый ряд деталей. И обсуждать это стоит непосредственно с подрядчиком.
Возможно, в вашем случае оптимальнее всего будет начать с фиксированной ставки и через некоторое время перейти к привлечению выделенной команды.
И не бойтесь, что мнение подрядчика будет идти вразрез с тем, что оптимально для вас. Впрочем, вот вам мнение разработчиков относительно каждой из моделей взаимодействия.
С точки зрения разработчика
Чтобы быть как можно более объективными, мы обсудили вопрос с разработчиками, которые имеют опыт более трех лет и успели за это время поработать как в выделенной команде, так и в проектах с фиксированной оценкой. И вот, что из этого вышло.
Модель с выделенной командой (Dedicated team model)
Преимущества выделенной команды:
- Некоторые люди любят знать, что они будут делать следующие несколько месяцев, поэтому они предпочитают стабильность работы в выделенной команде.
- Модель выделенной команды позволяет разработчику получить более глубокие знания технологий проекта. Осознание того, что скорее всего придется поддерживать проект после окончания его разработки, заставляет разработчиков более четко продумывать его архитектуру, масштабируемость и т.д.
- Ежедневное общение с заказчиком или его представителем – обязательное требование для таких проектов. Это повышает коммуникативные навыки разработчиков и улучшает взаимопонимание между клиентом и командой.
Минусы выделенных команд:
- На каждом проекте есть более или менее интересные задачи. Так вот задачи по доработке и поддержке проектов, как правило, относятся к не самым интересным. К примеру, в таком случае, команда может тратить более 20% времени на техподдержку разных проектов заказчика.
- Поскольку любая выделенная команда – это «компания внутри компании», команда подчиняется всем процессам заказчика. Иногда эти процессы отличаются от тех, к которым они привыкли в своей компании. Тут важную роль играет способность конкретного специалиста приспосабливаться к новым условиям: все очень индивидуально.
- У выделенных команд обычно упрощенные спецификации на разработку нового функционала или проекта. Это дает им определенную свободу: возможность предлагать свои решения поставленных задач, вместо того чтобы слепо следовать написанным спецификациям. Но и здесь есть свои оговорки: буквально каждое такое решение должно быть согласовано с владельцем продукта на стороне клиента до начала его разработки, что требует от специалиста настойчивости в обосновании своих решений.
Модель с фиксированной ставкой (Fixed price model)
Преимущества проектов с фиксированной ценой:
- Некоторые разработчики, напротив, любят изменения. Каждый новый проект требует изучения новых технологий, подходов и решений. И четкий дедлайн воспринимается некоторыми специалистами как вызов: достаточно ли они хороши, чтобы справиться с задачей в короткие сроки?
- Понятные спецификации позволяют более полно взглянуть на проект.
- Новый проект, к примеру стартап, может рассмотреть предложенное подрядчиком техническое решение, которое наилучшим образом подойдет для реализации проекта, разработки его архитектуры, подбора необходимых инструментов и т.д.
- Уже на стадии оценки разработчики «разбивают» проект на отдельные задачи, так что клиент заранее представляет, как будет строиться работа. В то время как выделенная команда проделывает то же самое, уже в процессе работы на стороне заказчика.
Минусы проектов с фиксированной ценой:
- В таких проектах разработчики редко общаются напрямую с заказчиком. Как правило, этим занимается менеджер проектов. А это значит, что успешность проекта во многом зависит от того, насколько хорошо налажен диалог. Но есть и другая сторона: разработчикам не приходится отвлекаться от работы на ежедневные разговоры.
- Такие проекты нельзя назвать гибкими, ведь риски по умолчанию присутствуют всегда, а при данной модели ими сложно управлять. Все осложняется и тем, что нужно уложиться в бюджет. Но это проблема отнюдь не программиста, а управленца на проекте.
Заключение
Все очень и очень относительно: одни и те же особенности разных моделей могут считаться как плюсами, так и минусами. Причем как для вас, так и для подрядчика. А потому однозначно отвечать на вопрос, какая же из моделей лучше, попросту не имеет смысла. Ведь в каждой конкретной ситуации ответ будет новым. Разговаривайте с подрядчиком, обсуждайте нюансы, приходите к общему знаменателю и принимайте рациональные решения.
Источник: webmartsoft.ru