договор time and material образец
Договор time and material образец
в LinkedIn
на free-lance.ru
в ЖЖ
in english
Вариант №1: time & material
Вариант №2: fixed price
Оплата фактически потраченных часов на работу над Вашими задачами, которые Вы можете ставить, снимать и изменять в любое время
Все просто: Вы ставите задачи, я их выполняю так, как если бы я был Вашим непосредственным подчиненным в организации. Какие-то задачи требуют больше времени, какие-то меньше, но, в целом, примерно столько же, сколько они бы потребовали времени у «обычного» достаточно высококвалифицированного и дисциплинированного сотрудника.
Два раза в месяц я передаю Вам отчет о потраченных часах за прошедшую половину месяца вместе с актом и счетом на оплату. В данный момент стоимость одного моего часа составляет 2.500 рублей (НДС не облагается в связи с применением УСН).
Преимущества по сравнению с «сотрудником в штате»:
Это классический вариант сотрудничества: мы встречаемся, Вы описываете стоящие цели и задачи, при необходимости я провожу предварительное обследование, оцениваю свои трудозатраты и риски, готовлю коммерческое предложение с описанием результата, этапами, сроками, ограничениями и стоимостью работ.
© Холодков Антон, 2000-2020. Буду рад использованию материалов этого сайта, но не забывайте ставить ссылку на него.
Договорные модели разработки ПО
Как юристы в сфере ИТ, мы готовим договоры на создание ПО как для разработчиков, так и для заказчиков. В договоре необходимо учесть особенности различных моделей разработки ПО, выделить возникающие в связи с этим риски клиента и постараться их нивелировать.
Сегодня мы рассмотрим наиболее популярные условия заказной разработки ПО с точки зрения распределения рисков между заказчиком и исполнителем и дадим рекомендации по их снижению на уровне договора.
Любая из указанных ниже моделей разработки ПО может быть реализована на базе нашего рамочного договора с приложениями в соответствующей модификации.
1. Договор с фиксированной ценой (Fixed Price)
Условия применения. Применяется в стандартных проектах с понятными решениями и требованиями, поддающимися детализации. Требования к результату выносятся в отдельное техническое задание. Фиксируются сроки выполнения работ и их стоимость.
Преимущества для заказчика. Понятный бюджет при определенных требованиях к результату.
Риски заказчика. Сложность изменения требований к продукту в процессе его разработки. В результате такие условия плохо подходят к разработке нестандартного ПО и сложных систем.
Способ снижения рисков.
Включите в Договор на разработку ПО следующие условия:
1) поэтапная приемка работ;
2) оплата за принятый этап;
3) отказ от продолжения работ без финансовых санкций.
В таком случае заказчик сможет на любом этапе поставить исполнителя перед выбором продолжить работу на изменившихся условиях или выйти из проекта, сократив издержки.
Преимущества для исполнителя. Возможны в случае наличия готового решения, не требующего существенной доработки.
Риски исполнителя. Риск отказа от оплаты по завершении работ или превышения фактических усилий на разработку над ценой проекта.
1. Заказчик может отказаться от приемки результатов работ в связи с их реальным или «мнимым» несоответствием требованиям технического задания. Такой вариант может быть использован заказчиком для снижения стоимости выполненных работ или списания затрат по проекту, утратившему для него ценность к моменту завершения.
Способ снижения риска.
Включите в договор комбинацию условий:
1) максимально возможная предоплата;
2) поэтапная приемка работ;
3) невозможность отказа заказчика от договора без финансовых санкций.
По завершении каждого этапа составляйте отчетную документацию и фиксируйте приемку результатов заказчиком. Желательно оформлять поэтапную приемку подписанием двустороннего акта. Такой вариант предоставляет максимальные гарантии. Но можно договориться и о предоставлении в электронной форме одностороннего отчета, который должен быть рассмотрен заказчиком в течение установленного срока. Молчание приравнять к согласию с отчетом. Главное правильно описать в договоре процедуру приемки и ее юридические последствия.
2. Реализация проекта может занять больше времени по обстоятельствам, зависящим от любой из сторон
Рекомендации по снижению рисков. Постарайтесь с максимальной ответственностью подойти к разработке технического задания. Укажите в нем участки работ, за которые отвечает заказчик или привлекаемые им третьи лица. Опишите жесткие требования к оборудованию, программным и информационным системам, под которые разрабатывается ПО. Включите в договор условия о выполнении новых требований к ПО за дополнительную плату. Обязанность доказывания соответствия требований техническому заданию возложите на заказчика.
2. Договор с условием оплаты по факту (Time & Materials)
Условия применения. Объем работ не может быть в достаточной мере определен заранее. Работы выполняются на основе отдельных заданий. Задания даются на короткий отрезок времени. При этом заказчик полагается на профессиональный уровень исполнителя.
Преимущества для заказчика. Привлечение профессиональной команды или специалистов на отдельные участки работ. Гибкое изменение требований к продукту. Оплата только фактически выполненных работ.
Риски заказчика. На этапе налаживания взаимодействия с заказчиком итоговая стоимость работ может превысить ожидания.
Способы снижения. В приложении к договору необходимо детализировать расценки на работы отдельных специалистов исполнителя. Включить в договор условия о порядке постановки задачи, включающем ее предварительную оценку исполнителем.
Преимущества для исполнителя. Полная оплата времени, фактически затраченного на выполнение задачи.
Риски исполнителя. Задачи ставятся на короткий период, поэтому не фиксируются в виде отдельных технических заданий, спецификаций или приложений к договору. Постановка и приемка задач выполняется с использованием электронной почты или систем управления проектами.
Способы минимизации. Необходимо дополнить договор разделом об электронном документообороте с использованием простой электронной подписи. В этом случае разработчик снимет массу вопросов заказчика по содержанию задачи, соответствию результата и адекватному биллингу.
3. Абонентский договор
Условия применения. Используется при найме профессиональной команды или узкого специалиста для решения неспецифичных задач заказчика на длительной основе. Предполагается высокий уровень доверия исполнителю.
В наших реалиях абонентский договор часто используется внутри группы компаний при выделении IT-инфраструктуры или команды разработчиков в отдельную организацию для оптимизации налогообложения или бизнес-процессов.
Преимущества для заказчика. Возможность постановки любых задач в рамках компетенции исполнителя, быстрое изменение требований к результатам за фиксированную стоимость.
В группе компаний используется для получения льгот по страховым взносам с фонда оплаты труда разработчиков.
Риски заказчика. Неполная загрузка исполнителя и, как следствие, переплата в сравнении с работой по схеме Time&Materials.
При использовании абонентского договора для оптимизации внутри холдинга главным риском являются:
1) чрезмерная простота договора, как свидетельство притворной сделки.
2) неполная и несвоевременная фиксация работ, выполненных по договору.
Помните, что несоответствие условий договора обычной деловой практике в отношениях между независимыми лицами может свидетельствовать о притворности сделки в целях получения необоснованной налоговой выгоды. Аналогичный вывод можно сделать и на основе анализа документального оформления взаимодействия сторон.
Способ снижения риска. Включите в договор условие о возможности пересмотра суммы абонентской платы по итогам нескольких отчетных периодов. Можно предусмотреть упрощенный порядок изменения стоимости услуг по результатам уведомления исполнителя за определенный срок.
Для устранения налоговых рисков необходимо предусмотреть порядок отчетности с детализацией по выполненным работам в отчетном периоде.
Преимущества для исполнителя. Исполнитель обеспечен стабильным финансированием на период действия договора.
Риски исполнителя. Превышения объема фактических работ над ожидаемым с учетом согласованного размера абонентской платы.
Способ устранения риска. Установит ограничение на объем работ, выполняемых за абонентскую плату. При превышении установленного лимита предусмотреть оплату превышения по фиксированной ставке либо отдельное согласование стоимости работ сверх лимита.
Проверьте свой договор. Достаточно ли эффективно в нем распределены риски с учетом выбранной модели разработки ПО?
Time & material — мечта и боль разработчика
Виды T&M
Для T&M контрактов существует широкий спектр форматов реального взаимодействия. Два самых ярких представителя:
Почти аутстафф: исполнитель поставляет ресурсы, которые делают то, что сказал заказчик. Бюджета нет, есть месячный платеж на покрытие стоимости команды. От полноценного аутстаффа этот формат может отличаться тем, что на стороне исполнителя находится тимлид и детальная постановка задачи.
Почти фикс: есть скоуп, твердый бюджет, на стороне исполнителя сформирована проектная команда, но планирование идет по принципу беклога, работа формируется в спринты. Детализация постановки, а также решение о глубине реализации той или иной функции идет в процессе работы. Очень похоже на agile, вам не кажется.
За что платит заказчик
Сама аббревиатура T&M обозначает Time and Material — оплату за время и иные потраченные ресурсы.
Иногда в рамках T&M оплачивается все рабочее время сотрудника, вне зависимости от того, что он делает и делает ли вообще. Исполнитель будет настаивать на такой трактовке, когда детальное (позадачное) планирование работы команды находится в руках клиента: если контрактоваться иначе, то у заказчика не возникнет ответственности за неэффективную работу или простой сотрудников, и он гарантированно будет этой возможностью злоупотреблять.
Другой формат — оплачиваются только конкретные работы из плана, акцептованные заказчиком. Детальное проектное управление находится в руках исполнителя, он же распределяет задачи на сотрудников. Такой формат предполагает, что у проекта есть запас дел не менее чем на 2-3 горизонта планирования. При этом менеджер, оценивая объем работы, по согласованию с клиентом, может корректировать размер команды.
Схема фиксации плана работ и задач
На старте проекта должен быть оговорен механизм принятия задач. Скоуп и объем работ на T&M раздувается очень быстро, и причина проста: у заказчика всегда есть неисчерпаемый запас идей и желаний, а исполнитель только и рад увеличить счет в сторону клиента, реализуя все мыслимые и немыслимые мечты.
При этом очень легко образуется треугольник разорванной ответственности: менеджер продукта (от заказчика) струится мечтами, менеджер проекта (от исполнителя) делает все, чтобы его ублажить, а когда счет двойного размера попадает в финансовый контроль к клиенту, менеджер продукта быстро бледнеет и заявляет, что он всего этого не заказывал. Вот огурцы и лучок — да, а шашлык по-царски и односолодовый виски — это исполнитель сам придумал, сам съел и сам выпил. Выкинул в пропасть.
Осложняется вся эта картина еще и тем, что любая попытка ввести на стороне исполнителя собственный финансовый контроль или управление скоупом, вызывает гнев означенного выше продакт-менеджера на первой же попытке отказать ему в реализации функции, ибо как смеет несчастный контрактатор наступать на горло его песне.
Тем не менее практика показывает, что исполнитель, работающий по контракту T&M для закрытия своих рисков, вынужден привносить в него элементы fix price проекта. Например, путем фиксации в договоре/ТЗ критического скоупа: стороны договариваются, что контракт не может считаться не исполненным, если у результата на дату Х есть пол, руль, мотор и колеса. Все остальное может быть добавлено или изъято движением мятущейся души заказчика, но не эти четыре детали. В таком раскладе исполнитель может работать с приоритетами, направляя основные силы на ключевые функции системы, и реализуя всяческие bells and whistles в рамках, например, четверти бюджета времени проекта.
Схема code freeze и формирование стабильных версий
Вторая проблема гибких проектов имеет в основе те же самые причины, но несколько иные риски на выходе. Предположим, что бюджет действительно бесконечен — редко, но так тоже бывает. Тогда нет проблемы с объемом работ, но есть даты релизов, или, хуже того, усталость заказчика более высокого уровня от ожидания. Если проект не успел к плановой дате, потому что менеджер клиента раздул скоуп, виноват будет все равно разработчик. Если реализация массы ненужных функций сделала код неуправляемым и нестабильным, никто не примет объяснений: «Вы сами так просили». Ответ заказчика будет прост: «Мы не просили делать плохо».
Риск работы с непрофессиональным сотрудником на стороне клиента
Можно быть идеальным исполнителем для менеджера со стороны клиента, но это не гарантирует успех: проект может провалить человек от заказчика. Для ИТ-компании это означает следующий риск: два года Вася из NNN говорил, что все идет идеально, а потом пришел его директор, Васю выгнал с треском, платежи остановил, потому что все это время руками подрядчика делали нечто, совершенно никому не нужное.
Такой риск в T&M проектах существенно выше, чем в фиксовых. Последний предполагает детальную работу с требованиями, а опытный аналитик никогда не забудет провести работу по выявлению реальных стейкхолдеров и выяснит, с кем, кроме Васи, нужно согласовать бизнес-цели проекта.
Нельзя рассматривать T&M контракт в режиме «мне приказали, я сделал, они обязаны заплатить». Исполнитель должен понимать бизнес-цели контракта, управлять скоупом проекта и не позволять линейным сотрудникам на стороне заказчика вести проект к неудаче. Даже если контракт и размер заказчика гарантируют оплату сколь угодно идиотской работы, кроме денег есть еще и репутация. Сделав в T&M режиме неуспешный, но оплаченный проект, можно получить недовольство на уровне руководства заказчика, кто бы ни был причиной этого неуспеха.
Договор на разработку мобильного приложения
Зачем нужен договор
У любого договора есть две функции — коммуникативная и юридическая. Коммуникативная помогает убедиться в том, что стороны правильно поняли друг друга. Они обсуждают условия работы, приходят к согласию и фиксируют эти договорённости на бумаге.
Юридическая функция даёт страховку на случай, если одна из сторон нарушит обязательства. Если спор не удаётся решить мирно, — поможет арбитражный суд. Он рассмотрит доводы сторон и вынесет решение, исходя из условий договора. Поэтому формулировки в нём должны быть чёткими: всё неясное, неточное и обтекаемое проясните до того, как поставите подпись.
В чём особенность договора на разработку мобильного приложения
Разработка приложения — длительный и сложный процесс, на который влияет множество факторов как со стороны заказчика, так и со стороны исполнителя. Прописать все нюансы и учесть все риски в техническом задании невозможно. В ходе разработки появляются новые идеи, которые нужно учесть, меняются условия использования дополнительных сервисов, возникают технические проблемы, наступают кризисы. Это приводит к срывам сроков и изменению общей стоимости проекта.
Чтобы обезопасить себя от непредвиденных рисков, нужно заключить договор, который защитит обе стороны. При конфликтных ситуациях используйте его для того, чтобы найти компромисс и продолжить сотрудничество, а не для того, чтобы давить на другую сторону. Составьте договор так, чтобы заказчик и исполнитель чувствовали себя партнёрами и знали, что у них равные права и обязанности. Тогда в процессе работы вам не придётся тратить время на волокиту с документами.
Структура договора на разработку мобильного приложения
Договор на разработку мобильного приложения комбинирует два типа договоров — на оказание услуг (исполнитель работает над приложением) и на передачу права интеллектуальной собственности (заказчик получает результат чужого интеллектуального труда). Он состоит из десяти пунктов:
1. Предмет и основные условия. Что? Для кого? За сколько? В этом пункте договоритесь об обязательствах сторон, этапах работы, о процессе оплаты и об электронной подписи.
2. Расчёты. В этом пункте — про условия оплаты. Облагается ли она налогами? Когда считается завершённой? Нужно ли отправлять бумажную версию отсканированного счёта? Ответы должны устраивать обе стороны.
3. Сдача и приёмка работ. Пункт про то, как работа сдаётся исполнителем и принимается заказчиком. Помимо очевидных вещей, в пункте прописано как себя вести, если пошло не так: заказчик долго не выходит на связь с исполнителем или исполнитель предоставляет некачественный результат.
4. Передача интеллектуальной собственности. Благодаря этому пункту, заказчик получает исключительные права на всё, что было сделано в рамках проекта. Договоритесь о том, в какой момент передаются права.
В отдельном подпункте укажите, что в разработке используются результаты интеллектуального труда третьих лиц. Готовые наработки — библиотеки, тексты, иконки, иллюстрации, программные коды — делают разработку быстрее и дешевле. Часто они находятся в свободном доступе и не требуют дополнительного соглашения. Но их использование может сопровождаться условиями, которые важно учитывать. Не все готовые решения можно применять в коммерческом закрытом ПО.
Пример. Вы разрабатываете мобильный мессенджер с платной подпиской. Чтобы сэкономить время, вы используете модифицированный код Telegram, который находится в открытом доступе. Согласно его условиям распространения, вы должны открыть финальный код своего приложения для всех.
5. Гарантии. Про срок, в течение которого исполнитель устраняет ошибки и недочёты в своей работе. В пункте оговаривается, на что гарантия не распространяется и в каких случаях она прерывается досрочно. Например, если заказчик решил поправить приложение своими силами и нарушил его работу, то разработчик больше не отвечает за его функционирование.
6. Конфиденциальность. В этом пункте стороны договариваются о неразглашении информации, заказчик разрешает исполнителю опубликовать результаты работ в портфолио. Аналогичное соглашение подписывается с третьими лицами, если они участвовали в разработке.
7. Ответственность и обстоятельства непреодолимой силы. Что происходит, когда стороны не выполняют свои обязательства. В пункте — начисление неустоек за срыв сроков и порядок досудебного разбирательства с последующим обращением в суд. Вы избегаете ответственности только в том случае, если на вашу работу повлияли обстоятельства непреодолимой силы. Но без справки от компетентных органов в это никто не поверит.
8. Действие и расторжение. Про сроки действия договора, возможность его продления и расторжение. В пункте говорится, что о пожелании расторгнуть договор нужно предупредить за месяц, и описывается порядок досрочного расторжения.
9. Иные условия. В пункте — стандартные вещи про документооборот: договор действует на основании ГК РФ, а дополнительные соглашения являются его неотъемлемой частью.
10. Реквизиты. Здесь указываются актуальные данные заказчика и исполнителя: адреса, налоговые идентификаторы, номера счетов, ставится дата и подпись.
Готовый договор от «Лайв Тайпинга»: скачайте и начните разработку сейчас
Работать с шаблоном от «Лайв Тайпинг» несложно: в нём есть интерактивное оглавление, с которым вы быстро просмотрите все разделы. Наш договор — рамочный, в нём прописаны общие правила и обязанности сторон, а договорённости и детали по конкретному проекту вам придется самостоятельно зафиксировать в дополнительных соглашениях. Вы найдете их под основным документом. В приложениях также есть шаблоны технического задания.
Чтобы получить готовый договор, вам нужно:
Какое дополнительное соглашение выбрать
Допсоглашения конкретизируют условия рамочного договора. Их основная задача — во всех деталях описать то, что клиент хочет получить от студии по итогу работы. Наш договор предусматривает три варианта шаблонов дополнительных соглашений, подходящих для разных видов сотрудничества:
1. Fixed price. Заказчик покупает законченный продукт или его часть. Например: создание кликабельного прототипа приложения, разработку дизайна мобильного приложения или разработку приложения под iOS целиком с нуля. Это доспоглашение описывает этапы работы с фиксированными ценой и сроками. Вариант Fixed price подходит для работы над простыми проектами с понятной функциональностью, чётко прописанной в ТЗ. Выход за рамки ТЗ с сохранением прежних сроков и стоимости работы невозможен. Если заказчик хочет на лету менять требования и не зависеть от ТЗ, то лучше выбрать более свободную модель оплаты.
2. Time&Materials. Заказчик платит за время специалистов, потраченное на работу над его проектом. Круг задач и стоимость часа работы оговариваются в допсоглашении. Например, клиенту нужно создать приложение для iOS. Для этого нужны менеджер проекта, дизайнер, разработчик и тестировщик. В течение месяца эти специалисты трудятся на проекте, а в конце месяца клиент получает отчёт о количестве затраченных часов и оплачивает их. Этот вид сотрудничества хорош тем, что клиент гораздо быстрее видит результат и может вносить изменения в процессе. Этот вариант подходит для долгосрочных проектов.
Лучше разобраться в тонкостях Fixed price и Time&Materials вам поможет наша статья.
3. Time&Materials period (он же Retainer). Данная практика пришла в ИТ из юридического бизнеса. Заказчик «оптом» выкупает всю команду, нужную для ведения проекта, на долгий срок. Период, состав команды и цена фиксируются в допсоглашении. Оплата и приём работ происходят раз в месяц/неделю. Это самый эффективный вариант работы над проектом, потому что в нём не нужно бесконечно подписывать документы, скрупулёзно считать часы и согласовывать каждый шаг. В начале периода заказчик и разработчик составляют план работ, в конце — подводят итог и фиксируют результаты, подписывая акт, который передаёт клиенту права на сделанные работы. Одновременно он является актом приёмки этих работ. Способ подходит для сложных и долгосрочных проектов, на которых важна полная вовлечённость всех участников команды.
Разработка ПО по договору Time&Material: риски и преимущества
Руководитель студии по разработке мобильных приложений Winfox Мухамедьянов Рустам, о том как работать по договору Time&Material
Правильное построение взаимоотношений между заказчиком и исполнителем это половина успеха разработки. Подходящий для проекта тип контракта помогает минимизировать риски и увеличить шансы на положительный результат для обеих сторон: клиента и компании-разработчика. Давайте рассмотрим одну из моделей ценообразования в аутсорсинге – работу по договору Time&Material.
При упоминании Time and Material часто возникает вопрос: «Почему бы подрядчику не потянуть резину чтобы получить побольше денег?». На деле это вопрос доверия. Этот способ ценообразования позволяет исполнителю гибко настроить процесс разработки, не огораживаясь доп. костами от рисков и не возводя преград в виде строгих ТЗ перед заказчиком. Хороший исполнитель заинтересован в правильном результате и старается сохранять процессы прозрачными.
Это хороший подход когда качество продукта для клиента на первом месте и не вызывает беспокойства мысль, что может быть потрачено больше ресурсов, чем планировалось. Однако для минимизации рисков, при составлении договора по модели Time and Material, надо детализировать план разработки ПО и обсудить сроки выполнения этапов и всего цикла разработки.
T&M это модель работы, при которой оплачивается не результат, а время исполнителя. Например, вы платите не за разработку и внедрение программы управления предприятием, а за человеко-часы, потраченные сотрудниками исполнителя на разработку. Но что означает Time&Material на самом деле? Западный опыт работы по Time & Material подразумевает, что заказчик оплачивает услуги исполнителя, на основе человеко-часов, дополнительно возмещая затраты на используемые материалы.
В российской практике существуют договор подряда и договор возмездного оказания услуг. По договору подряда работа, которую выполняет подрядчик, должна быть воплощена в материальный результат, в то время как по договору возмездного оказания услуг предметом является именно процесс, который и оплачивается заказчиком.
Договор Time and Material имеет ряд особенностей:
Положительное отношение к изменениям со стороны исполнителя. Этот подход хорошо дисциплинирует заказчика и стимулирует более обдуманно планировать и проектировать проект;
Максимальная гибкость. Клиент может позволить себе делать что угодно в каких угодно объемах. Вносить изменения можно с большей скоростью;
Первое опасение возникающее у потенциального клиента – компания разработчик может раздуть время и бюджет проекта до бесконечности. Для того чтобы снять это опасение давайте рассмотрим как работают компании по модели T&M.
T&M хорошо применять там где невозможно определить полный объем работы или сроки их реализации. Для каких типов проектов рекомендуется модель T&M?
1. Проект находится на стадии тестирования, технического обслуживания или доработок. Для выполнения отдельных блоков работ T&M – очень удобный вариант. Каждую стадию можно описать в подробных ТЗ, особенно когда готова вся документация по проекту.
2. Проекты, срок разработки которых занимают до 6 месяцев, на команду от 5 человек и требуют наличия технической документации. Модель «Оплата по факту» позволяет исполнителю подстраиваться под желания клиента и требования рынка, поэтому четкие спецификации, хоть и нужные, могут отсутствовать на первых порах. Тогда документация будет писаться в ходе работы или станет первой задачей в рамках проекта.
3. Крупные проекты, которые требуют команды от 25 человек, со сроками разработки от года. В связи с большими объемами и долгим временем разработки, предварительные спецификации будут фрагментированы и могут занимать тысячи страниц, которые будут корректироваться по ходу разработки.
Концепция договора Time&Material предполагает, что вы платите, после выполнения работ по заранее определенному плану. Этапы разработки определяются в начале сотрудничества. Вот как это работает в Winfox:
Результатом работы в конкретном периоде может служить как рабочий прототип, релизная версия, так и полноценный билд ПО. Разделение на этапы в модели T&M имеет общие черты с итерациями в Scrum, поэтому оплата по факту нередко сочетается с гибкими методологиями разработки.
При таком подходе подрядчик не сможет раздуть проект, ведь заказчик оплачивает трудозатраты на основе почасовых ставок всех членов команды. Оплата обычно производится поэтапно, в зависимости от оговоренных с подрядчиком условий, например, за установленный период спринта, ежемесячно и т. д.
Подобная модель на практике невозможна без хорошей системы планирования задач и мониторинга их выполнения. Для этого можно использовать такие системы, как JIRA, Redmine или Basecamp.
Сбалансированная команда. Заказчик имеет право определить количественный состав и квалификацию членов команды совместно с менеджером проекта со стороны подрядчика.
Прозрачная разработка и результат. Клиент максимально вовлечен в проект, имея доступ к системам управления задачами и учета трудозатрат. Разбивая проект на этапы и имея договоренности о промежуточных результатах клиент получает работающие промежуточные версии с законченным функционалом. Это исключает неприятные сюрпризы в случае многомесячной разработки без обратной связи с заказчиком или дискоммуникации.
Недобросовестные подрядчики. Всегда есть риск столкнуться с недобросовестной компанией, которая будет завышать реальные трудозатраты с целью получения прибыли. Поэтому нужно очень тщательно подходить к выбору исполнителя и планированию разработки проекта.
Мы рекомендуем заказчикам, которым хотят реализовать крупный долгосрочный проект, не рисковать и выбирать гибкую модель разработки и оплаты — Agile и Time&Material. Обычно на старте разработки крупных проектов заказчики редко имеют точное представление о всём необходимом функционале. Однако по мере развития проекта, мы вместе с вами глубже вникаем в задачи — так появляются новые идеи и улучшения. Time and Materials в таком случае очень удобен — вы можете вносить корректировки непосредственно в ходе работ.
Постоянная коммуникация и обсуждение всех деталей помогут вам создать проект, который будет эффективно решать задачи вашей компании и иметь перспективу для дальнейшего развития.