Time and materials что это
Разработка ПО по договору 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:
Принципы работы IT-Solution: Agile, Time&Material
Компания IT-Solution оказывает широкий спектр услуг: это интеграция, настройка и кастомизация решений 1С и Битрикс24, разработка приложений и собственных сервисов, разработка сайтов на 1С-Битрикс.
С нами удобно и быстро автоматизировать: методология позволяет гибко перестраивать требования и реализовывать желания заказчика. Но так как для многих заказчиков сотрудничество с нами является первым в сфере автоматизации бизнеса, мы решили кратко рассказать, как мы работаем и почему используем именно почасовую ставку оплаты.
Схемы оплаты по моделям Fixed Price и Time&Material
Есть 2 популярных на сегодня вида оплаты услуг в IT-сфере: Fixed Price (фиксированная цена) и Time&Material (время и расходники).
Fixed Price состоит из трех неизменных частей:
ТЗ составляет заказчик, поэтому для сбора и анализа данных и последующего написания ТЗ нужны квалифицированные профильные специалисты внутри компании или на аутсорсинге, время и оплату труда которых нужно также рассчитывать. Очень редки случаи, когда разработчик получает сразу ТЗ, по которому можно работать и которое не потребует корректировки.
Также исполнители, работающие по Fixed Price, несут все риски, поэтому закладывают дополнительную стоимость для их страхования в бюджет.
ТЗ может составляться как самостоятельно, так и совместно с разработчиком, заинтересованном в получении качественного результата.
Сравниваем выполнение одной задачи по разным моделям
Задача: разработка и настройка бизнес-процесса по работе с Лидами. Сроки сдачи проекта: неделя с момента запуска процесса разработки
Составляется заказчиком, проверяется и корректируется исполнителем. Нельзя начать работы до составления и утверждения ТЗ
Четко прописаны в договоре, но зависят от даты подписания ТЗ
4 часа на корректировку ТЗ, 10 часов на настройку
4 часа на корректировку ТЗ, 10 часов на настройку
Алгоритм работы с IT-Solution:
Почему мы выбираем Time&Material:
Для каких проектов рекомендуется Time & Material:
Три основные модели в ценообразовании: Fixed-Price, Time & Materials, и Milestone
В 21 веке вопрос о деньгах и прибыли стал интимным. Разговор о том, как строится стоимость товара/услуги в кругах бизнесменов не так часто и поднимается, а кому приятно выдавать собственные секреты?
Договор с фиксированной стоимостью часа (а именно в часах идет оценка проекта) всегда содержит точную смету работ, которая появилась после детального анализа объема работ и рисков по проекту. Качественная оценка объема работ зависит от описания требований к будущему продукту (в нашем случае мобильному приложению, примеры далее будут связаны с ними). В качестве таких требований выступает техническое задание, которое и оценивают разработчики.
Строгие сроки. Когда заказчик понимает, какие функции ему нужны в приложении, разработчики могут прийти к четкому плану и определенным срокам.
Предсказуемость. Все было обсуждено и запланировано заранее, легко отслеживать состояние разработки мобильного приложения. Нет необходимости выделять дополнительный ресурс для контроля.
Модель с фиксированной ценой лучше всего подходит для небольших проектов с ограниченными возможностями и четкими требованиями. Это также хорошо для MVP и проектов с ограниченным бюджетом и определенными сроками.
«Аппетит приходит во время еды», а именно доработки. Все доработки, которые не оценивались с самого начала, должны попадать под дополнительное соглашение и оплачиваться отдельно. Жесткие условия.
Любые доплаты воспринимаются заказчиком плохо, если не сказать критично. Хочется за те же деньги сделать все-все. Были случаи, когда по причинам доработок останавливались проекты.
Риски недопонимания. Всегда существует риск, что недопонимание может привести к доставке продукта, который не совсем соответствует тому, на что рассчитывал клиент.
Масштабируемость таких проектов минимальна, с большой долей вероятности проект не получит продолжения.
Изменения на рынке. Внести правки в будущую мобилку не удастся просто так, а учесть все изменения и необходимость всех функций в том виде, в котором они описаны в ТЗ, нельзя.
Долгое планирование. Долго, очень долго тянутся договора с фиксированной ценой. Сначала напиши ТЗ, разработай дизайн, оцени ТЗ и дизайн, согласуй и только после этого начинай разработку.
Модель с фиксированной ценой лучше всего подходит для небольших проектов с ограниченными возможностями и четкими требованиями, гос. сектор и прогосударственные компании любят такой подход. Также хорошо модель подходит для MVP (минимально жизнеспособный продукт) и проектов с ограниченным бюджетом и определенными сроками.
Гибкие требования. Работа делится на короткие спринты и ведет к MVP. Все функции проверяются должным образом и могут быть добавлены или удалены в любой момент.
Почасовые ставки. Клиенты платят установленную почасовую ставку, которая была обговорена с самого начала. Оплата происходит по факту выполненных работ (в некоторых случаях с частичным авансом, так называемые гарантированные часы).
Качество продукции. Продукт хорошо протестирован и доведен почти до совершенства благодаря нескольким итерациям, что приводит к созданию высококачественных мобильных приложений. Рай для перфекционистов.
Прозрачность. Модель времени и затрат позволяет клиентам отслеживать прогресс, так как разработчики представляют отчеты о проделанной работе. Часто клиент принимает участие в митингах компании по данному проекту. Прекрасный опыт воплощения гибких методологий ведения проектов.
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 режиме неуспешный, но оплаченный проект, можно получить недовольство на уровне руководства заказчика, кто бы ни был причиной этого неуспеха.
Дмитрий Завалишин дал комментарий каналу «Москва 24» о том, что может вызывать ошибки в мобильном приложении, отслеживающем перемещение городского общественного транспорта
Time and Material, Fixed Price, Fixed Budget: процесс работы, риски и ограничения при различных моделях оплаты
Вопрос оплаты, безусловно, является одним из ключевых моментов во всем процессе разработки продукта. Существует несколько основных моделей оплаты, каждая из которых имеет свои преимущества и недостатки, для каких-то проектов являясь эффективным решением, а для некоторых — далеко не лучшим вариантом.
Перед клиентом, отдающим проект в разработку, встает вопрос: на чем остановить свой выбор — Time and Material (почасовая оплата), Fixed Price или Fixed Budget (тут стоит отметить, что альтернативы, конечно, имеются, но мы сосредоточимся на этих трех моделях, т.к. они не только являются самыми популярными, но и имеют много преимуществ)?
Этот вопрос актуален не только для заказчиков — для нас, разработчиков, он также имеет огромное значение. Почему?
Для нас способ оплаты определяет то, каким образом будет построен весь процесс разработки (а также процесс коммуникации), насколько свободно будут вноситься изменения, сможет ли сам клиент что-то менять в спецификации (или просто это будет сделать или нет), будут ли сжатыми сроки проекта и т.д.
А теперь рассмотрим Fixed Price, Time and Material и Fixed Budget с точки зрения распределения рисков и наличия различных ограничений.
Модель Fixed Price в каком-то смысле довольно специфична. Она подразумевает полную оценку всех необходимых работ по проекту исходя из технического задания (ТЗ), предоставленного клиентом.
Устанавливаются цена за проект и сроки, за который он будет сделан. Заказчик получает своего рода гарантию, что его проект будет сделан к указанному времени и за определенную цену. Все это, безусловно, делает для клиента данную модель весьма привлекательным и удобным вариантом.
Так как правильно подсчитать весь объем работы (масштаб), рассчитать время (даже приблизительное), необходимое не просто для каждого этапа создания продукта, но и для каждой задачи (!) — вещь, мягко говоря, не простая, то тут на первый план выходит спецификация, предоставляемая заказчиком.
При таких проектах оплата по Fixed Price будет отличным решением, позволяющим изначально знать стоимость и время завершения проекта. Тем не менее, работа по этой модели накладывает свои ограничения.
Прежде всего, необходимо учесть все возможные риски, связанные с участием третьих лиц. Это может быть прохождение ревью Apple, интеграция с Facebook, обновление операционной системы и т.д.
Также любое изменение должно быть тщательно описано и запланировано исходя из графика и загрузки разработчиков, что требует согласования и планирования задач, на которые может уйти несколько дней.
Другой недостаток изменений заключается в том, что документация должна быть обновлена в соответствии с изменениями в масштабе работы. Углубляясь в этот вопрос, необходимо отметить, что компания-разработчик часто планирует начало другого проекта после окончания текущего.
Поэтому даже незначительный блок дополнительных работ ведет к хлопотам, связанным со смещением сроков следующего проекта либо совмещением обоих проектов и т.п.
Опасаясь как раз таких ситуаций, компания-разработчик, работая по Fixed Price, часто вынуждена вкладывать в стоимость риски, связанные с возможными изменениями и дополнительным временем на согласование задач. В любом случае, если нет подробной спецификации, лучше остановиться на каком-то из альтернативных вариантов.
Таким образом, для проектов, где нет четкого ТЗ или в которых возможны какие-либо изменения, способ оплаты Fixed Price будет неудачным решением.
Time and Material
Time and Material (TM) означает почасовую работу оплаты нанятых специалистов по принципу “you pay as we go”.
Оценка объема работ, масштаба проекта и сроков его завершения проводится, но приблизительная, так при TM часто происходят различные изменения, а главным становится конечный результат и его качество, а не время и цена, в которые необходимо уложиться любыми средствами. Это и определяет его преимущества перед другими способами оплаты (в частности, Fixed Price).
Отсутствует контракт с установленной ценой, границ которой нельзя (или очень, очень нежелательно) пресекать, так как любые изменения в спецификации, увеличение объема работы (например, ввиду реализации новых функций) неизбежно приведут к изменению контракта и поднятию цены, что не прибавляет оптимизма.
Также при Time and Material нет строгих дедлайнов, так как главным при ней является нацеленность на лучший результат.
Таким образом, на команду разработчиков нет такого давления, как при модели Fixed Price. Растет их мотивация везде искать самое эффективное решение.
Коммуникация проходит более легко и свободно: специалисты могут спокойно советовать заказчику оптимальные варианты, говорить, что где-то лучше потратить больше времени, зато получить более качественный результат, не опасаяюсь при этом, что не получится уложиться в указанные сроки.
Когда Time and Material будет эффективным решением:
Таким образом, TM определяют нацеленность на лучший результат (практически всегда дает лучший продукт), готовность к изменениям, гибкость рабочего процесса и прозрачная коммуникация.
Fixed Budget — отличная альтернатива Time and Material и Fixed Price, некий усредненный вариант этих двух моделей.
При данном способе оплаты заказчик определяет бюджет и расставляет приоритеты, предоставляя разработчикам максимально подробную спецификацию. Исходя из полученной информации они говорят, что можно сделать за указанную цену и когда будет готов результат.
Разработка продукта с минимальным функционалом (minimum viable product — MVP) как раз происходит при модели Fixed Budget. Суть MVP в том, что запуск приложения происходит максимально быстро, с экономией средств и ресурсов.
Что это значит: определяются главные функции продукта, которые нужно разработать в первую очередь, устанавливается время (у нас процесс занимает 2 месяца), затем осуществляется тестирование и стабилизация (около месяца).
Таким образом, клиент гарантированно получает качественное приложение за короткий срок, c возможностью протестировать его в действии (в том числе и на пользователях) и развивать продукт далее (при желании или необходимости). Модель Fixed Budget особенно эффективна в тех случаях, когда нужно как можно раньше выпустить приложение.
Следует отметить, что при Fixed Budget объем работ может меняться в зависимости от приоритетов, выставляемых заказчиком.
Главными преимуществами данной модели является то, что заказчик всегда знает, за какое время будет сделан проект, за какую цену (которую устанавливает он), а также то, что он получит качественное рабочее решение.
Теперь вы знаете, какие существуют модели оплаты, в чем их преимущества и недостатки. Часто бывает так, что какие-то компании привыкли работать по конкретной из них, но, тем не менее, для каких-то проектов лучше остановиться на чем-то ином. Мы же всегда готовы помочь вам определиться с выбором.