Time material что это
Принципы работы 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:
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 объем работ может меняться в зависимости от приоритетов, выставляемых заказчиком.
Главными преимуществами данной модели является то, что заказчик всегда знает, за какое время будет сделан проект, за какую цену (которую устанавливает он), а также то, что он получит качественное рабочее решение.
Теперь вы знаете, какие существуют модели оплаты, в чем их преимущества и недостатки. Часто бывает так, что какие-то компании привыкли работать по конкретной из них, но, тем не менее, для каких-то проектов лучше остановиться на чем-то ином. Мы же всегда готовы помочь вам определиться с выбором.
Выбираем модель финансового взаимодействия. 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. В связи с такими объемами и временем работы, предварительные спецификации для всего проекта составить крайне сложно. Они могут раскрываться хоть на тысяче страниц и будут корректироваться по ходу разработки.
Обдумывайте свой проект с разных сторон и советуйтесь со своим подрядчиком по поводу наиболее выгодной для вас системы проектного аутсорсинга. Напоминаем, что у нас есть удобная табличка со всеми тремя методами финансового взаимодействия. Изучайте и делайте свой проект прибыльным!
Разработка ПО по договору 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 режиме неуспешный, но оплаченный проект, можно получить недовольство на уровне руководства заказчика, кто бы ни был причиной этого неуспеха.