Тайм материал что это
Выбираем модель финансового взаимодействия. Time & Material
Чтобы научиться работать с компаниями-аутсорсерами на разных финансовых условиях, незачем проверять их на своем опыте и порой платить за это плохим настроением, сорванными сроками и перерасходами бюджета.
В идеальном мире можно один раз заплатить проверенной команде, сразу одобрить соответствующий всем требованиям и «хотелкам» продукт, пустить его в релиз и радоваться прибыли! Но в жизни все не так.
У каждой модели финансового взаимодействия есть свои плюсы и минусы, как для заказчика, так и для подрядчика. И определять подходящий вариант нужно на основании специфики бизнеса, объема работ и вида проекта. В прошлой статье мы сравнили подходы Fixed price и Dedicated team, пообещав отдельно рассмотреть Time & Material. Обещали – делаем!
Суть Time & Material
Понятие модели Time & Material (T&M, «Оплата по факту») означает оплату за результат, исходя из трудозатрат. Заказчик платит не за объем работы, а за человеко-часы, потраченные командой подрядчика на разработку и внедрение ПО. T&M хорошо показывает себя в случае, когда не получается определить полный объем работ или сроки их выполнения. Казалось бы,
Вот она, кнопка «деньги» для подрядчика – он может раздувать время проекта и его бюджет до бесконечности!
Но нет. Знающий заказчик делит сотрудничество с подрядчиком на этапы по 2-4 недели. Перед началом каждого этапа клиент и команда вместе определяют цели и задачи, а после его окончания исполнитель предоставляет отчеты о результатах и ведомости трудозатрат.
Этапы могут завершаться по-разному: от бэк-эндовых модификаций до полноценного рабочего прототипа/билда ПО, а в исключительных случаях и до версии системы, готовой к релизу. Кстати, по времени и принципу этапы T&M похожи на итерации в Scrum, поэтому модель «Оплата по факту» часто используется в связке с гибкими методологиями разработки.
Заказчик оплачивает проект на основе почасовой ставки каждого члена команды и трудозатрат. Поэтому неоправданно раздуть проект у подрядчика не получится. Условия оплаты оговариваются индивидуально. В зависимости от пожеланий заказчика, платежи производятся поэтапно, ежемесячно, раз в полгода и так далее.
Для планирования и контроля выполнения задач, а также мониторинга времени и ошибок, наша компания использует систему JIRA. Представители заказчика также получают к ней доступ, чтобы отслеживать ход работы над проектом и контролировать свои затраты. В ином случае, аутсорсинг-команда может получить доступ к системе заказчика, если ему привычнее работать в другой среде (Redmine, Basecamp).
Давайте посмотрим, когда рационально использовать T&M.
C точки зрения заказчика
Преимущества:
Минусы:
C точки зрения подрядчика
Преимущества:
Минусы:
Он может начать рассматривать каждую задачу под микроскопом и в некоторых особо тяжелых случаях никакая система учета трудозатрат не спасет. Вот программист отметил в той же JIRA выполнение задачи за 6 часов. Почему 6? Почему не 5, не 3? Стремление сэкономить каждый доллар, недоверие и, возможно, ограниченный бюджет вынуждают его спорить по каждой мелочи. Такому заказчику ничего не докажешь.
Для некоторых подрядчиков проще единожды получить указания и действовать в соответствии с ними от начала и до конца. А уж быстро подстраиваться под меняющиеся требования и одинаково эффективно работать с кардинально разными элементами – это не для всех.
Какие проекты подходят для T&M?
Конечно, особенности каждого проекта могут как упростить обеим сторонам жизнь, так и подпортить всем настроение. Поэтому мы хотим ещё и обозначить типы проектов, для которых рекомендуется модель Time & Material:
1. Проект на стадии тестирования, багфикса, обслуживания или доработок. Для выполнения отдельных блоков работ T&M – очень удобный вариант. Каждую стадию можно описать в подробных ТЗ, особенно когда первичная документация проекта тоже доступна и понятна.
2. Среднесрочный проект с нуля. Сюда мы относим продукты, которые укладываются в сроки до полугода, привлекают команды от 5 человек и требуют как минимум среднего уровня технической документации. Модель «Оплата по факту» позволяет подрядчику подстраиваться под желания клиента и требования рынка, поэтому четкие спецификации, хоть и нужные, могут отсутствовать на первых порах. Тогда документация будет писаться в ходе работы или станет первой задачей в рамках проекта.
3. Большой проект с нуля. Когда размеры продукта требуют усилий кросс-функциональной команды от 25 человек, а сроки разработки начинаются от 1 года, заказчику также выгодно использовать модель Time & Material. В связи с такими объемами и временем работы, предварительные спецификации для всего проекта составить крайне сложно. Они могут раскрываться хоть на тысяче страниц и будут корректироваться по ходу разработки.
Обдумывайте свой проект с разных сторон и советуйтесь со своим подрядчиком по поводу наиболее выгодной для вас системы проектного аутсорсинга. Напоминаем, что у нас есть удобная табличка со всеми тремя методами финансового взаимодействия. Изучайте и делайте свой проект прибыльным!
Три основные модели в ценообразовании: Fixed-Price, Time & Materials, и Milestone
В 21 веке вопрос о деньгах и прибыли стал интимным. Разговор о том, как строится стоимость товара/услуги в кругах бизнесменов не так часто и поднимается, а кому приятно выдавать собственные секреты?
Договор с фиксированной стоимостью часа (а именно в часах идет оценка проекта) всегда содержит точную смету работ, которая появилась после детального анализа объема работ и рисков по проекту. Качественная оценка объема работ зависит от описания требований к будущему продукту (в нашем случае мобильному приложению, примеры далее будут связаны с ними). В качестве таких требований выступает техническое задание, которое и оценивают разработчики.
Строгие сроки. Когда заказчик понимает, какие функции ему нужны в приложении, разработчики могут прийти к четкому плану и определенным срокам.
Предсказуемость. Все было обсуждено и запланировано заранее, легко отслеживать состояние разработки мобильного приложения. Нет необходимости выделять дополнительный ресурс для контроля.
Модель с фиксированной ценой лучше всего подходит для небольших проектов с ограниченными возможностями и четкими требованиями. Это также хорошо для MVP и проектов с ограниченным бюджетом и определенными сроками.
«Аппетит приходит во время еды», а именно доработки. Все доработки, которые не оценивались с самого начала, должны попадать под дополнительное соглашение и оплачиваться отдельно. Жесткие условия.
Любые доплаты воспринимаются заказчиком плохо, если не сказать критично. Хочется за те же деньги сделать все-все. Были случаи, когда по причинам доработок останавливались проекты.
Риски недопонимания. Всегда существует риск, что недопонимание может привести к доставке продукта, который не совсем соответствует тому, на что рассчитывал клиент.
Масштабируемость таких проектов минимальна, с большой долей вероятности проект не получит продолжения.
Изменения на рынке. Внести правки в будущую мобилку не удастся просто так, а учесть все изменения и необходимость всех функций в том виде, в котором они описаны в ТЗ, нельзя.
Долгое планирование. Долго, очень долго тянутся договора с фиксированной ценой. Сначала напиши ТЗ, разработай дизайн, оцени ТЗ и дизайн, согласуй и только после этого начинай разработку.
Модель с фиксированной ценой лучше всего подходит для небольших проектов с ограниченными возможностями и четкими требованиями, гос. сектор и прогосударственные компании любят такой подход. Также хорошо модель подходит для MVP (минимально жизнеспособный продукт) и проектов с ограниченным бюджетом и определенными сроками.
Гибкие требования. Работа делится на короткие спринты и ведет к MVP. Все функции проверяются должным образом и могут быть добавлены или удалены в любой момент.
Почасовые ставки. Клиенты платят установленную почасовую ставку, которая была обговорена с самого начала. Оплата происходит по факту выполненных работ (в некоторых случаях с частичным авансом, так называемые гарантированные часы).
Качество продукции. Продукт хорошо протестирован и доведен почти до совершенства благодаря нескольким итерациям, что приводит к созданию высококачественных мобильных приложений. Рай для перфекционистов.
Прозрачность. Модель времени и затрат позволяет клиентам отслеживать прогресс, так как разработчики представляют отчеты о проделанной работе. Часто клиент принимает участие в митингах компании по данному проекту. Прекрасный опыт воплощения гибких методологий ведения проектов.
Договорные модели разработки ПО
Как юристы в сфере ИТ, мы готовим договоры на создание ПО как для разработчиков, так и для заказчиков. В договоре необходимо учесть особенности различных моделей разработки ПО, выделить возникающие в связи с этим риски клиента и постараться их нивелировать.
Сегодня мы рассмотрим наиболее популярные условия заказной разработки ПО с точки зрения распределения рисков между заказчиком и исполнителем и дадим рекомендации по их снижению на уровне договора.
Любая из указанных ниже моделей разработки ПО может быть реализована на базе нашего рамочного договора с приложениями в соответствующей модификации.
1. Договор с фиксированной ценой (Fixed Price)
Условия применения. Применяется в стандартных проектах с понятными решениями и требованиями, поддающимися детализации. Требования к результату выносятся в отдельное техническое задание. Фиксируются сроки выполнения работ и их стоимость.
Преимущества для заказчика. Понятный бюджет при определенных требованиях к результату.
Риски заказчика. Сложность изменения требований к продукту в процессе его разработки. В результате такие условия плохо подходят к разработке нестандартного ПО и сложных систем.
Способ снижения рисков.
Включите в Договор на разработку ПО следующие условия:
1) поэтапная приемка работ;
2) оплата за принятый этап;
3) отказ от продолжения работ без финансовых санкций.
В таком случае заказчик сможет на любом этапе поставить исполнителя перед выбором продолжить работу на изменившихся условиях или выйти из проекта, сократив издержки.
Преимущества для исполнителя. Возможны в случае наличия готового решения, не требующего существенной доработки.
Риски исполнителя. Риск отказа от оплаты по завершении работ или превышения фактических усилий на разработку над ценой проекта.
1. Заказчик может отказаться от приемки результатов работ в связи с их реальным или «мнимым» несоответствием требованиям технического задания. Такой вариант может быть использован заказчиком для снижения стоимости выполненных работ или списания затрат по проекту, утратившему для него ценность к моменту завершения.
Способ снижения риска.
Включите в договор комбинацию условий:
1) максимально возможная предоплата;
2) поэтапная приемка работ;
3) невозможность отказа заказчика от договора без финансовых санкций.
По завершении каждого этапа составляйте отчетную документацию и фиксируйте приемку результатов заказчиком. Желательно оформлять поэтапную приемку подписанием двустороннего акта. Такой вариант предоставляет максимальные гарантии. Но можно договориться и о предоставлении в электронной форме одностороннего отчета, который должен быть рассмотрен заказчиком в течение установленного срока. Молчание приравнять к согласию с отчетом. Главное правильно описать в договоре процедуру приемки и ее юридические последствия.
2. Реализация проекта может занять больше времени по обстоятельствам, зависящим от любой из сторон
Рекомендации по снижению рисков. Постарайтесь с максимальной ответственностью подойти к разработке технического задания. Укажите в нем участки работ, за которые отвечает заказчик или привлекаемые им третьи лица. Опишите жесткие требования к оборудованию, программным и информационным системам, под которые разрабатывается ПО. Включите в договор условия о выполнении новых требований к ПО за дополнительную плату. Обязанность доказывания соответствия требований техническому заданию возложите на заказчика.
2. Договор с условием оплаты по факту (Time & Materials)
Условия применения. Объем работ не может быть в достаточной мере определен заранее. Работы выполняются на основе отдельных заданий. Задания даются на короткий отрезок времени. При этом заказчик полагается на профессиональный уровень исполнителя.
Преимущества для заказчика. Привлечение профессиональной команды или специалистов на отдельные участки работ. Гибкое изменение требований к продукту. Оплата только фактически выполненных работ.
Риски заказчика. На этапе налаживания взаимодействия с заказчиком итоговая стоимость работ может превысить ожидания.
Способы снижения. В приложении к договору необходимо детализировать расценки на работы отдельных специалистов исполнителя. Включить в договор условия о порядке постановки задачи, включающем ее предварительную оценку исполнителем.
Преимущества для исполнителя. Полная оплата времени, фактически затраченного на выполнение задачи.
Риски исполнителя. Задачи ставятся на короткий период, поэтому не фиксируются в виде отдельных технических заданий, спецификаций или приложений к договору. Постановка и приемка задач выполняется с использованием электронной почты или систем управления проектами.
Способы минимизации. Необходимо дополнить договор разделом об электронном документообороте с использованием простой электронной подписи. В этом случае разработчик снимет массу вопросов заказчика по содержанию задачи, соответствию результата и адекватному биллингу.
3. Абонентский договор
Условия применения. Используется при найме профессиональной команды или узкого специалиста для решения неспецифичных задач заказчика на длительной основе. Предполагается высокий уровень доверия исполнителю.
В наших реалиях абонентский договор часто используется внутри группы компаний при выделении IT-инфраструктуры или команды разработчиков в отдельную организацию для оптимизации налогообложения или бизнес-процессов.
Преимущества для заказчика. Возможность постановки любых задач в рамках компетенции исполнителя, быстрое изменение требований к результатам за фиксированную стоимость.
В группе компаний используется для получения льгот по страховым взносам с фонда оплаты труда разработчиков.
Риски заказчика. Неполная загрузка исполнителя и, как следствие, переплата в сравнении с работой по схеме Time&Materials.
При использовании абонентского договора для оптимизации внутри холдинга главным риском являются:
1) чрезмерная простота договора, как свидетельство притворной сделки.
2) неполная и несвоевременная фиксация работ, выполненных по договору.
Помните, что несоответствие условий договора обычной деловой практике в отношениях между независимыми лицами может свидетельствовать о притворности сделки в целях получения необоснованной налоговой выгоды. Аналогичный вывод можно сделать и на основе анализа документального оформления взаимодействия сторон.
Способ снижения риска. Включите в договор условие о возможности пересмотра суммы абонентской платы по итогам нескольких отчетных периодов. Можно предусмотреть упрощенный порядок изменения стоимости услуг по результатам уведомления исполнителя за определенный срок.
Для устранения налоговых рисков необходимо предусмотреть порядок отчетности с детализацией по выполненным работам в отчетном периоде.
Преимущества для исполнителя. Исполнитель обеспечен стабильным финансированием на период действия договора.
Риски исполнителя. Превышения объема фактических работ над ожидаемым с учетом согласованного размера абонентской платы.
Способ устранения риска. Установит ограничение на объем работ, выполняемых за абонентскую плату. При превышении установленного лимита предусмотреть оплату превышения по фиксированной ставке либо отдельное согласование стоимости работ сверх лимита.
Проверьте свой договор. Достаточно ли эффективно в нем распределены риски с учетом выбранной модели разработки ПО?
Разработка ПО по договору 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:
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 режиме неуспешный, но оплаченный проект, можно получить недовольство на уровне руководства заказчика, кто бы ни был причиной этого неуспеха.