договор time and material шаблон
Договор time and material шаблон
в LinkedIn
на free-lance.ru
в ЖЖ
in english
Вариант №1: time & material
Вариант №2: fixed price
Оплата фактически потраченных часов на работу над Вашими задачами, которые Вы можете ставить, снимать и изменять в любое время
Все просто: Вы ставите задачи, я их выполняю так, как если бы я был Вашим непосредственным подчиненным в организации. Какие-то задачи требуют больше времени, какие-то меньше, но, в целом, примерно столько же, сколько они бы потребовали времени у «обычного» достаточно высококвалифицированного и дисциплинированного сотрудника.
Два раза в месяц я передаю Вам отчет о потраченных часах за прошедшую половину месяца вместе с актом и счетом на оплату. В данный момент стоимость одного моего часа составляет 2.500 рублей (НДС не облагается в связи с применением УСН).
Преимущества по сравнению с «сотрудником в штате»:
Это классический вариант сотрудничества: мы встречаемся, Вы описываете стоящие цели и задачи, при необходимости я провожу предварительное обследование, оцениваю свои трудозатраты и риски, готовлю коммерческое предложение с описанием результата, этапами, сроками, ограничениями и стоимостью работ.
© Холодков Антон, 2000-2020. Буду рад использованию материалов этого сайта, но не забывайте ставить ссылку на него.
Договор на разработку мобильного приложения
Зачем нужен договор
У любого договора есть две функции — коммуникативная и юридическая. Коммуникативная помогает убедиться в том, что стороны правильно поняли друг друга. Они обсуждают условия работы, приходят к согласию и фиксируют эти договорённости на бумаге.
Юридическая функция даёт страховку на случай, если одна из сторон нарушит обязательства. Если спор не удаётся решить мирно, — поможет арбитражный суд. Он рассмотрит доводы сторон и вынесет решение, исходя из условий договора. Поэтому формулировки в нём должны быть чёткими: всё неясное, неточное и обтекаемое проясните до того, как поставите подпись.
В чём особенность договора на разработку мобильного приложения
Разработка приложения — длительный и сложный процесс, на который влияет множество факторов как со стороны заказчика, так и со стороны исполнителя. Прописать все нюансы и учесть все риски в техническом задании невозможно. В ходе разработки появляются новые идеи, которые нужно учесть, меняются условия использования дополнительных сервисов, возникают технические проблемы, наступают кризисы. Это приводит к срывам сроков и изменению общей стоимости проекта.
Чтобы обезопасить себя от непредвиденных рисков, нужно заключить договор, который защитит обе стороны. При конфликтных ситуациях используйте его для того, чтобы найти компромисс и продолжить сотрудничество, а не для того, чтобы давить на другую сторону. Составьте договор так, чтобы заказчик и исполнитель чувствовали себя партнёрами и знали, что у них равные права и обязанности. Тогда в процессе работы вам не придётся тратить время на волокиту с документами.
Структура договора на разработку мобильного приложения
Договор на разработку мобильного приложения комбинирует два типа договоров — на оказание услуг (исполнитель работает над приложением) и на передачу права интеллектуальной собственности (заказчик получает результат чужого интеллектуального труда). Он состоит из десяти пунктов:
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). Данная практика пришла в ИТ из юридического бизнеса. Заказчик «оптом» выкупает всю команду, нужную для ведения проекта, на долгий срок. Период, состав команды и цена фиксируются в допсоглашении. Оплата и приём работ происходят раз в месяц/неделю. Это самый эффективный вариант работы над проектом, потому что в нём не нужно бесконечно подписывать документы, скрупулёзно считать часы и согласовывать каждый шаг. В начале периода заказчик и разработчик составляют план работ, в конце — подводят итог и фиксируют результаты, подписывая акт, который передаёт клиенту права на сделанные работы. Одновременно он является актом приёмки этих работ. Способ подходит для сложных и долгосрочных проектов, на которых важна полная вовлечённость всех участников команды.
Лайфхак: в любой непонятной ситуации умножай на три
Статья была написана три года назад но так и пылилась в черновиках. Публикую без изменений. Много воды утекло с тех пор. Однако может быть мой опыт кому-то пригодится.
Хочу обсудить проблемы, связанные с предварительной оценкой времени и сроков проектов. В этой статье я расскажу как обстоят дела на проекте, который я веду немногим более 5 месяцев. Я приведу некоторые свои мысли, объясню какие эксперименты с оценками я делал и какие выводы получил по прошествию этого срока.
Но сначала пару слов о себе. Мне 26 лет, я рaботаю в текущей компании чуть более четырех лет. Компания — типичный аутсорсер со штаб-квартирой в штатах. До этого (с 2002-го) я сменил 3 веб-студии.
Fixed Fee vs Time & Material
Так уж сложилось, что у нас в компании не любят Fixed Fee проекты. Причин тому много, но, по-большому счету, все упирается в неправильную первоначальную оценку как бюджета так и сроков. Это выливалось в проваленные сроки и убытки. Поэтому мы изо всех сил старались все проекты делать по схеме Time and Material — считали сколько времени потратили и умножали на стоимость часа. В этом случае мы ничем не рискуем когда у нас в корне неверные оценки бюджета. В самом худшем случае мы говорим клиенту “Простите, мы ошиблись в оценке. Мы не учли вот это и это, к тому же вы захотели переделать вот это и это. Поэтому ваш проект обойдется вам в Х раз дороже”.
Однако, не всех заказчиков устраивает ситуация, когда невозможно спрогнозировать бюджет. И я их понимаю. О каком финансовом планировании в компании может идти речь если вы не знаете во сколько вам обойдется “создание сайта”? Наш опыт показал что единственный действенный случай для успеха бессрочных проектов — это когда ваши услуги обходятся клиенту сравнительно дешево и его устраивает выкладывать какую-то небольшую сумму ежемесячно. Это напоминает ситуацию когда у вас нет достаточно денег что бы сделать ремонт всего дома целиком. И вы годами делаете ремонт частями — по-немногу каждый месяц, насколько хватает свободных средств.
Такие проекты могут тянуться очень долго: у заказчика постоянно возникают какие-то идеи и изменения. Вы их выполняете, затем у него рождаются новые идеи и так по кругу. До тех пор пока он с легкостью оплачивает счета.
Однако это неприменимо к новым проектам. Заказчик хочет увидеть результат как можно скорей. И, естественно, потратив как можно меньше средств.
Социальная сеть
Поэтому когда к нам пришел заказчик и сказал что хочет узнать сколько будет стоить сделать “социальную сеть” мы улыбнулись. Наметился тренд. Дело в том, что до этого мы делали… тоже социальную сеть.
Мы сказали что это займет очень примерно 3-4 месяца у 4-6 разработчиков и умножили цифру на нашу почасовую ставку что бы очертить порядок бюджета. Если вам нужно привлечь нового заказчика — такой вариант срабатывает почти всегда (если у них действительно большой проект) и они соглашаются начать разработку.
Когда выяснилось, что клиент ни в какую не соглашается на Time and Material я уже не улыбался. Было не до шуток. Задача по оценке бюджета социальной сети с нечеткими требованиями мягко говоря нетривиальна.
Еще интересным фактом было то что заказчик начинал разработку в другой компании, где ему сделали весь дизайн, сверстали большинство страниц в HTML и сделали первоначальную оценку дальнейшей стоимости работ. Потом они что-то не поладили и каким-то образом нашли нас. Таким образом у нас был готовый дизайн, частично готовый HTML (относительно сносного качества) и список функциональных возможностей системы.
Мы приняли решение взять этот список и прикинуть сколько времени может потребоваться на каждую из них. Мой американский коллега применил следующую методику: по 8 часов на страницу + какое-то количество общих часов (40-120) на отдельно взятую подсистему. Так, если под личные сообщения было сверстано 5 разных страниц то это выливалось в 80-100 часов работы.
Да, эта оценка была очень грубой. В последствии я подсчитал что она отличалась от реально потраченных часов в среднем в 2.25 раза. Сразу я очень был не доволен этой оценкой и понимал что она не адекватная. Однако полезность этой оценки я понял позже. Для более детальной оценки нужно потратить много дней на то что бы вникнуть в каждую возможность системы, увязать их между собой, учесть все возможные нюансы в пограничных условиях и т.д. А это сделать фактически невозможно — документации либо технического задания просто нет и не будет. Заказчик обсуждал все с предыдущей командой и у него уже постоянно есть ощущение “мы же это уже обсуждали”. И он считает что из макетов можно узнать что и как система должна делать. Со временем я понял что плохая и грубая оценка лучше чем ее отсутствие. А хорошую оценку во многих случаях сделать просто невозможно. Проект в процессе своего развития постоянно изменяется. Изменяются и требования к его функциям, внешнему виду и т.д. Соответственно должна меняться и первоначальная оценка. И именно поэтому первоначальные сроки и бюджеты просто не могут быть точны.
Хотя, бывают и исключения. Один из наших проектов — система учетов рисков для очень крупного швейцарского банка. Их бюрократия просто идеальна для нас. Они сначала утверждают все необходимые изменения, четко документируют их и только затем присылают их нам на оценку. В этом случае мы точно можем просчитать смету ибо все требования известны, все четко документировано и ничто уже до сдачи проекта не изменится. Но так бывает крайне редко. Это скорее исключение из правил.
Смета
Итак, при составлении сметы нашей социальной сети мы решили пойти не совсем обычным путем. Мы решили делать все функциональные системы отдельными фазами. Каждая фаза обсуждается, оценивается и утверждается заказчиком непосредственно перед ее выполнением. Когда мы составляли представление о наборе задач мы могли уже достаточно точно оценить время на их выполнение и составить коммерческое предложение по этим задачам. Таким образом у нас получилось нечто среднее между Time & Material и Fixed Fee.
Раньше с Fixed Fee проектами я особо дел не имел и поэтому мне было крайне интересно научиться трезво их оценивать. Среди разработчиков постоянно ходили шутки вроде “возьми эстимейт, умножь на два а лучше три и получишь что нужно”. Шутки — шутками, а как же все обстоит на самом деле? Это мне и предстояло выяснить.
Раньше я дробил задачи на максимально мелкие подзадачи, оценивал их, складывал сумму, умножал на магические цифры (добавлял 10% на deployment, 10% на тестирование и 10% на management&communication). Полученную цифру умножал на текущую стоимости часа работы разработчика и озвучивал цифру клиенту.
Поэтому по завершению первого же набора фаз (их делали разные люди) я начал собирать все данные для статистического анализа и строил всевозможные интересные для меня графики.
Проблема
Первые же цифры показали что дело — дрянь. Мы в убытке. Но почему?
Первый эстимейт был паршивый. Это было очевидно. К тому же американское руководство в процессе работы потребовало что сайт был полностью AJAX без единой перегрузки страницы. А мы этого не учитывали при оценке. Мы считали что сделаем несколько отдельных страниц со своими ajax-вызовами. И мы были вынужденны переделывать много вещей так, что бы перегрузки страниц не было вообще.
Подумав, я увеличил коэффициенты и добавил еще одни новый — прибыль. Я его добавил под влиянием какой-то статьи то ли на хабре то ли еще где-то. Ведь помимо оплаты труда мы должны получить еще и прибыль, верно? 🙂 С новыми коэффициентами мы выполнили еще три фазы (они шли параллельно). Попутно я вел работу с разработчиками, старался выяснить причины просрочек и исключать их. По завершению этих фаз графики показали что мы перестали терять деньги такими сумасшедшими темпами. Однако все еще разработчики тратили больше времени на выполнение задач чем предполагалось сметой. Это меня заинтересовало. Почему?
Провалы сроков
Я наблюдал следующую картину. Разработчик получает задачу на 8 часов. И он тратит на нее 8 часов. Ровно 8 часов. Иногда больше, но почти никогда — меньше. Потом показывает результат и этот результат нуждается в доработке. Я его отправляю переделывать и после второй или третей итерации я получаю удовлетворительный результат. К этому моменту сроки уже превышены. Просьбы показывать заранее и т.д. не возымели эффекта. И я пошел на хитрость — немного занизил выделенное время на задачу.
На 8-часовой задаче занижение эстимейта на 1-2 часа никто не заметил. Выделил шесть часов — разработчики по-прежнему тратил шесть часов, приходил и потом доделывал. Так мы стали кое-как вкладываться в сроки. Затем я пошел дальше и дошел до сокращения сроков вполовину. И это работало! Иногда, правда, ребята начали приходить и жаловаться что не успеют сделать задачу за такой срок и им понадобится больше времени. Я спрашивал сколько, они отвечали что еще 1-2 часа, получали мое согласие и делали в этот новый срок. А по итогу — получалось что делали быстрее чем начальный эстимейт. Процентов на 10-15% быстрее, а не на 15-20% дольше как это было раньше. Однако, это не очень хорошо сказалось на их настроении. Они были напряжены и нервничали из-за того что они не вкладываются в выделенное время. Я решил так кардинально не играть со сроками и просто занижаю их на четверть когда заполняю систему учета задач.
Дальнейшим шагом был переход к оценке задачи исполнителем. Раньше я сам оценивал сколько займет задача времени и сам выставлял сроки. Со временем, я перешел к схеме когда я только составляю список задач, мы их обсуждаем и разработчики говорят сколько времени у них займет их реализация. Таким образом я избавился от фраз типа “Не мы же оцениваем задачи! Вот поэтому и не вкладываемся в сроки!”. Теперь они оценивают свои задачи и с них весьма честный спрос если они сорвали сроки. Однако как занизить срок, который разработчик сам себе выбрал? Я перенес это занижение в коэффициенты, на которые в последствии умножаю общую сумму часов.
Разработка ПО по договору 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 в таком случае очень удобен — вы можете вносить корректировки непосредственно в ходе работ.
Постоянная коммуникация и обсуждение всех деталей помогут вам создать проект, который будет эффективно решать задачи вашей компании и иметь перспективу для дальнейшего развития.