Agile-контракты между клиентами и агентствами: готов ли рынок?
Как контрактировать ответственность между заказчиком и исполнителем, чтобы эффективно управлять проектом? Ответ на этот вопрос искали участники панельной дискуссии «Agile-контракты между клиентами и агентствами: готов ли рынок?», модератором которой выступила Лилия Калашник, маркетинговая компания OSDirect, член Правления ВРК по связям с рекламодателями со стороны клиента.
Agile — это подход к управлению проектами, в которых требования к продукту или сервису изменяются с нарастающей скоростью. Это проекты с высокой инновационной составляющей, а также проекты, являющиеся по своей сути новыми для заказчика и исполнителя.
Лилия Калашник: Как понять, где заканчиваются ответственность исполнителя и ответственность заказчика, как того, кто платит деньги? Как это можно контрактировать и какие типы контрактов бывают?
Артем Сердюк, ISM eCompany and ISM Ukraine, преподаватель КМБШ: В наших проектах мы часто заходим в «зону неизвестного». По ходу такого проекта нас ждет много неожиданных открытий, а значит и изменений. Agile говорит, что изменения нужно приветствовать, а быстрая реакция на них — это основа конкурентного преимущества.
Но заказчики очень не любят неопределенность, поэтому часто пытаются её уменьшить, «зафиксировав» объем работы, время, затраты на проект, а ответственность за нарушения этих ограничений возложить на исполнителя. Так получается самый распространенный тип контрактов «Зафиксировано все»: бюджет, время и объем работы.
Например, сегодня, чтобы доехать на конференцию, я вызвал такси. Мне нужно было попасть в НСК «Олимпиский» до 11:45, таксист согласился и пообещал довезти за 120 грн. После этого я почувствовал себя спокойно, открыл новости и практически не смотрел по сторонам. Все риски взял на себя таксист.
По дороге, конечно, были пробки, мы долго стояли на светофорах. И хотя я читал новости, время от времени я смотрел на часы и все больше волновался. Мне хотелось заставить таксиста ехать быстрее, но как? В итоге я постоянно спрашивал: «Мы успеем?», а в ответ слышал: «Да-да, конечно».
Л.К.: У него, как у исполнителя, нет абсолютной мотивации привезти раньше или быстрее — все равно заплатят.
Вроде бы у исполнителя есть мотивация закончить раньше, но за счет качества. Когда таксист видит, что не успевает, и не может изменить пункт назначения и маршрут, страдает качество поездки: он будет нарушать, превышать, подрезать. В итоге мы все равно приезжаем в 11:55, вместо 11:45 и начинаем спорить: успел ли он вовремя, и стоит ли мне ему платить за такую поездку?
В таком проекте нехорошие, соревновательные отношения между клиентом и исполнителем. Сначала мы спорим, за какое время и за сколько денег он меня отвезет. В моих интересах, как заказчика, добиться суммы поменьше и времени пораньше. А таксист, как исполнитель, старается застраховаться от рисков, и добавляет ко времени и стоимости какой-то буфер.
А если я потом захочу на минуточку остановиться и выпить кофе, то, скорее всего, таксисту это не понравится, ведь это ставит под угрозу его обещания. А авария или пробка вообще приводят к провалу проекта.
Поэтому, хотя вроде бы мы и застраховались от изменений, и риски переложили на исполнителя, но на самом деле к неожиданностям проект не устойчив.
Л.К.: Итак, какие у нас альтернативы?
Расскажу ещё одну историю. Недавно я был у врача. Я сказал ему, что не очень хорошо себя чувствую, но у меня через три дня командировка и я должен быть здоров. Мне нужно, чтобы врач вылечил меня до отъезда, и сделал это не дороже, чем за 500 грн.
Конечно, ни один врач на такое не согласится, ведь он не видел мою историю болезни и не понимает, хватит ли мне трех дней, чтобы выздороветь. Даже после анализов и постановки диагноза неопределенность слишком большая, и врач не будет обещать, что я точно выздоровею за 3 дня и уложусь в свой бюджет.
Вместо этого он назначает мне лечение, а я плачу ему за время консультации.
Это другой тип контракта, который называется «Время и материалы«. Он полностью открыт к изменениям, ведь заказчик платит исполнителю только за потраченное время. При этом все риски лежат на клиенте. Отношения между клиентом и подрядчиком в таком случае гораздо лучше, и изменения приветствуются.
Но у такого контракта есть свои нюансы. Например, я сажусь в такси и говорю: «Поехали в НСК, я плачу за километраж». В таком случае я получу прекрасную обзорную экскурсию по Киеву. Мы бы поехали попить кофе, заехали бы на Андреевский спуск, посмотрели бы Днепр с двух сторон, и я бы получил обслуживание по высшему разряду. Но доеду ли я до места назначения до 11:45 и за 120 гривен? Скорее всего, я буду там гораздо позже и потратив намного больше денег.
Л.К.: Есть старый анекдот на эту тему:
Известный врач отошел от дел и передал своих пациентов сыну, молодому врачу.
Один из пациентов, которого отец лечил долгие годы, приходит на прием, и сын с удивлением видит, что болезнь у того совсем легкая. Он выписывает пациенту дешевое лекарство, и человек наконец-то выздоравливает.
Сын хвастается отцу:
— Папа! Ты лечил нашего пациента 20 лет, а я его вылечил сразу и легко!
Отец схватился за голову:
— Идиот! За эти 20 лет я вырастил тебя, дал тебе образование, мы построили дом! А ты взял и сразу его вылечил!
Именно. Исполнитель заинтересован, чтобы проект как можно дольше не заканчивался — ведь пока идет проект, он получает оплату. А заказчик счастлив, что все его идеи воплощаются.
Такое часто происходит, когда у вас есть in-house команда разработки, и вы автоматизируете в своей компании какой-то внутренний процесс. Клиент фонтанирует идеями, и этот «фонтан» может быть такой силы, что проект никогда не выходит «в жизнь». Его хоронят бесконечные изменения.
Л.К.: То есть, улучшения идут без конца.
Да, но все довольны.
Л.К.: Главное, что заказчик доволен. Он получил то, что хотел.
Безусловно, но можно было бы и дешевле, и быстрее.
Я бы предложил такой подход: почасовая оплата и либо бюджет, который ограничивает затраты, либо жесткий дедлайн. Объем работ в таком контракте не фиксируется. Например, когда я говорю: «1 км — 10 грн., но у меня всего 100 грн. Давайте постараемся доехать за эти деньги до «Олимпийского»». Или: «Мне нужно в 11-45 быть на месте, и в 11-45 наша поездка закончится, где бы мы в этот момент ни находились».
Такие контракты лучше чистого «Времени и материалов» тем, что у них есть конец, и это мотивирует исполнителя и держит в рамках клиента с его бесконечным потоком идей. С другой стороны, изменения возможны, и исполнитель им не сопротивляется. Ведь если клиент захотел заехать в Лавру, то в том, что в 11-45 мы возле Лавры, а не в пункте назначения, виноват только он сам.
Главный риск такого контракта — потратить свой бюджет и так и никуда не приехать. Но этот риск несет заказчик, поэтому он намного сдержаннее предлагает изменения и значительно лучше вовлечен в управление проектом. Вторая проблема в том, что если у вас есть бюджет, он будет потрачен полностью. Сэкономить не выйдет.
Идеальный контракт, по-моему, это такой, где изменения возможны и ожидаемы, но у обеих сторон есть мотивация закончить проект пораньше. Мотивацию довольно просто добавить бонусами за раннее окончание и штрафами за опоздание.
Хороший тип бонуса предлагает контракт Money for Nothing, Changes for Free (бесплатные изменения и деньги ни за что). В этом контракте клиент и исполнитель договариваются о какой-то дате, к которой примерно 80% проекта будут выполнены с 90% вероятностью. И дальше они двигаются вместе, причем клиент постоянно решает, стоит ли продолжать. Если в какой-то момент клиент решит досрочно закончить, он платит подрядчику бонус, равный прибыли, которую тот заработал бы за оставшееся время проекта.
Все довольны: заказчик заплатил меньше и раньше получил готовый проект, а исполнитель получил ровно ту же прибыль, но раньше и с меньшими затратами.
Изменения в таком проекте возможны, но, если какая-то работа добавляется, аналогичный объем должен быть из плана исключен.
Л.К.: То есть, подрядчик должен быть достаточно открыт в своих расчетах. И он должен быть готов назвать свою прибыль.
Да. А штрафовать за позднее окончание можно с помощью контракта Fixed Profit. Он говорит, что исполнитель получает фиксированную прибыль от проекта вне зависимости от того, раньше срока проект закончился или позже.
То есть если мы приехали на 10 минут раньше, таксист получит тот же бонус, что и в прошлом контракте — недополученную прибыль за последних 10 минут. А если мы на 10 минут опоздали, за время опоздания я плачу по себестоимости — и прибыль таксиста остается на том же уровне. Это очень мотивирует исполнителя закончить такой проект как можно раньше.
Л.К.: Итак, мы рассмотрели несколько типов контрактов. В зависимости от задачи и этапа отношений, на котором находятся заказчик и исполнитель, вы можете выбирать свой, понимая его риски и выгоды.
Если вы хотите знать больше про agile-контракты, читайте статьи agile-экспертов:
Манифест гибкого маркетинга (на английском)
Больше о типах agile-контрактов на английском
Мнения экспертов
Алексей Ключник, директор R&D в Terrasoft
Самой большой проблемой всех проектов и продуктов, независимо от того, по какой методологии они разрабатываются, является получение клиентом в точности той бизнес-ценности, которую он ожидает.
Согласно статистике, самый значимый фактор успешности проектов, который равен порядка 30%, заключается в участии пользователей и непосредственных заказчиков в реализации проекта. Для сравнения, ближайший следующий фактор, «понятные требования», равен всего 13%.
Традиционные методологии о взаимодействии с клиентом говорят мало, о его участии в ходе проекта — еще меньше.
Дмитрий Вергун, управляющий партнер Be Global
Мы не делаем коротких локальных проектов (задач). Выполняем проекты, связанные со стратегий клиента, его развитием. А это, так или иначе, касается минимум нескольких департаментов (функций) внутри компании, несущих различную ответственность, имеющих различные KPI и мотивацию. Т.е. заказчик, как правило, один, но в проекте постоянно есть «другая» мотивация и другие «зоны ответственности».
Многогранный проект: запуск крупным производителем программы лояльности для конечных потребителей.
Классический контракт: разработка механики, концепции, экономической модели, IT-архитектуры программы лояльности. Вторая часть — внедрение.
Первая часть работы была сделана, как по книжке: точно в срок, конкретные показатели. Менеджер со стороны заказчика был требователен, строг и уважителен к экспертизе и знаниям.
Вторая часть: внедрение. В компании изменилась организационная структура. Да еще и в проект подключились новые департаменты, от которых очень зависело его будущее. Но именно на этой стадии появилось столько новых вводных сложностей и предзадач, что конечная цель, а именно увидеть счастливое лицо покупателя с нашей карточкой лояльности, показалась практически недостижимой…
Надо отдать должное всей рабочей команде заказчика — тем, кто был в ней с самого начала, и тем, кто подключился недавно. Их мотивация была идеальна для работы в слабо прогнозируемой ситуации. Она была (!) и она была нацелена на результаты проекта.
Мы стали делить «слона» на кусочки. На те самые, без которых следующий шаг не реализуем. И те, которые так или иначе ведут нас к конечным целям.
И даже такие вопросы, как выбор и контракт с IT -поставщиком, мы не стали решать классически. Ну, как обычно — большой подрядчик, большой тендер, техзадание, длительные доработки, корректировки и так далее по кругу. Пошли итерационным путем. Малый подрядчик — первые шаги, первая обратная связь, первые корректировки в техзадание. Но уже на практике, в полях. Потому что, как еще оказалось, «в полях» все выглядело ну совсем не так, как изначально представляли все участники рабочей команды. Организационная готовность партнеров к запуску программы лояльности была непрозрачной. У кого-то не было никакой автоматизации и учета. У кого-то все было уже автоматизировано, и он не хотел менять свою систему учета. И узнали все об этом внутри проекта.
Хорошо это или плохо? И как вести себя в этом случае подрядчику, если его обязательства по контракту стали в ближайшем обозримом будущем превышать размер вознаграждения в 2-3 раза?
Все прекрасно понимали выгодность для заказчика достижение целей. Оцифровали малые цели и показатели по каждому локальному подпроекту. Перепланировали зоны ответственности внутри команды. Многим приходилось погружаться в новую экспертизу. Главное — качество, главное — получить качественную обратную связь. Понять, что мы изменили операции и это стабильно. Только после этого переходили к следующему подпроекту. Контрактование тоже изменили в привязке к результатам локальных подпроектов.
Финально: программа запущена, механика работает. Мы получили удивительные отклики от конечных покупателей. Наш пилотный проект усложняется с каждой итерацией, как конструктор. У него появляется дополнительный ряд целей. Аппетит приходит во время еды. 🙂
Форум маркетинг-директоров: 2-3 апреля, НСК Олимпийский
Панельная дискуссия «Agile-контракты между клиентами и агентствами: готов ли рынок?» состоялась 3 апреля в рамках Украинского форума маркетинг-директоров. Организатор — Всеукраинская рекламная коалиция. 