x
 
Дмитрий Денисов
12 августа 2011

Артём, расскажите, как вы договариваетесь с заказчиками работать по флекс-скоупу? Ведь на первый взгляд идея платить за время, а не за результат любому заказчику покажется абсурдной. Какие вопросы задавать, как создать у заказчика нужное видение?

Заранее благодарен за ответ.



Дмитрий!

Важно понимать, что флекс-скоуп как раз гарантирует результат, а фикс-скоуп — бесконечный проект. Флекс-скоуп — это повременная оплата, лишённая своего главного недостатка — плавающих бюджетов и сроков.

Но вы совершенно правы, что клиент этого не знает. Более того, у очень многих наших клиентов, которые приходят за новым продуктом, нет опыта управления проектами. У них либо не было ничего, либо они годами создавали и медленно развивали свой старый продукт или сервис. Последняя ситуация даже вдвойне опасна, потому что клиенту с опытом эволюционной разработки и длительной поддержки часто кажется, что он легко справится с совершенно новым проектом.

Признаюсь честно, я не придумал, как человеку без предыдущего опыта проектов-долгостроев создать в голове картину с помощью открытых вопросов. И я буду рад идеям уважаемых советчиков.

Поэтому я действую иначе. Я просто искренне рассказываю о своих личных неудачах. Необязательно называть конкретные проекты — главное честно нарисовать их историю и взять на себя полную ответственность за их неудачу. Виноват не клиент и не его программисты, а то, что мы позволяли им рыть себе яму нашими руками бесконечными доделками и бесконтрольностью разработчиков.

А в конце я предупреждаю, что мы работаем по-новому всего несколько месяцев и этого слишком мало для убедительной статистики. Однако раньше у нас не было таких управляемых проектов и счастливых клиентов (за редкими исключениями), и к предыдущей схеме мы уже не вернёмся никогда.

Получается, что мне не приходится убеждать клиента, потому что у меня просто нет альтернативы. Конечно, мне жаль, если мой клиент пойдёт по пути других клиентов других студий, но это будет его решение.

Когда абсолютно все вокруг работают по-другому, решение работать по парадоксальному принципу — вопрос только личного доверия. Поэтому не пожалейте времени в начале знакомства на хорошие вопросы о бизнесе и задаче клиента, они повышают доверие лучше любых рассказов о себе.

Главное — копите опыт успешных проектов. Тогда сами поверите.

Fix time and budget, flex scope — принцип управления проектом, сформулированный в компании «37 сигналов». В вольном переводе означает «зафиксировать сроки и бюджет, сделать гибким функционал».
P. S.
Предлагаю всё же отметиться в комментариях дизайнерам и разработчикам, в чьих компаниях и студиях уже применяется ФФФ — fix time, fix budget, flex scope. Вдруг я неправ? :-)
P. P. S.
Это был пятничный совет по взаимоотношениям с клиентом. Хотите получить совет по самой эффективной системе переговоров без оружия? Присылайте вопросы.
P. P. P. S.
Совет помог? Напишите в комментариях.

Поделиться
Отправить

Комментарии

Павел Карасев
12 августа 2011

Кроме показательных примеров на основе бизнеса клиента, я хочу попробовать приводить в пример адвокатов. Вы покупаете время определённого адвоката по фиксированной ставке в час. Пока не проверял этот ход, но думаю, что некоторым так может быть понятнее. Про адвокатские фильмы можно ещё упомянуть :-)

Михаил Дроздовский
12 августа 2011

В нашей маленькой компании Drozdovsky Lab, в которой мы сейчас разрабатываем два новых веб-сервиса, используется как раз FFF :-)


12 августа 2011

Павел, я настоятельно не рекомендую использовать такую аналогию.

Адвокатской повременной оплаты все боятся именно из-за её непредсказуемости и бесконтрольности. При нашем же подходе ограничение срока гарантируется.

Кроме того, когда большинство дизайнеров работают иначе, вам просто ответят, что будут платить адвокатам за время, а вам, пожалуй, нет.

В таком разговоре вообще нельзя заострять внимание на том, что оплата за время. Это всего лишь следствие основного принципа и способ обеим сторонам почувствовать ответственность за дедлайн.

Рома Кривенко
12 августа 2011

У нас с небольшими проектами это отлично работает — все довольны, а вот по большим проектам почему-то не совсем получается. Например, есть клиент, которому мы всё сделали по определенному этапу, но два месяца ждали обратной связи. Не то, чтобы просто сидели и ждали, а звонили раз-два в неделю, напоминали, назначали встречи и сроки, но без результата. Наконец сейчас выполнили всё в срок, но от него ждём третью неделю несколько абзацев по объекту, о котором ничего не знаем, иначе сами бы всё написали уже.

Ещё есть пример, когда выполнили этап, клиент месяц-два не даёт обратной связи, потом утверждает работу и говорит, что сроки поджимают и он ждёт работы по оставшемуся этапу. Выполняем последний этап, снова фидбек только через две-три недели и оказывается, что не нравится всё, что было сделано с самого начала.

Есть проблема в ограничении клиента во времени обратной связи и не знаем как ее решить. В договоре записано пять дней на реакцию, но никто этого не придерживается, а каждый раз тыкать в условия договора не хотелось бы.

Александр Борисов
12 августа 2011

У себя, в Цифрономике, тоже внедрил принцип FFF — клиенты не нарадуются, да и рабочий день теперь заканчивается в 17:00 :-)


15 августа 2011

Рома, ваш клиент как раз не чувствует никакой ответственности за своё и ваше время — за время проекта, иными словами.

Если бы эти пять дней стоили бы денег, к ним было бы другое отношение.

При этом я хочу добавить, что главная цель FFF вовсе не в том, чтобы подгонять клиента. Цель — в постоянном принятии решений.

Антон Кулаков
25 августа 2011

Но ведь клиент не будет знать в действительности, сколько было потрачено времени на разработку. Как быть с этим моментом?


25 августа 2011

Наоборот, он будет точно знать. Дедлайн-то фиксированный.

Рома Кривенко
21 сентября 2011

Артём, спасибо большое. Оказалось, всё действительно так просто :-)

Андрей Голубев
23 ноября 2011

Опасаюсь, что я неправильно вас понял, поэтому спрошу в виде примера.

Приходит к вам заказчик разработать сайт с каталогом продукции.

По методу ФФФ вы у него уточняете бюджет и когда ему нужен сайт. Заказчик называет 1000$ и через 20 дней.

Вы назначаете некое количество сотрудников с определённой квалификацией (исходя их бюджета клиента и своей прибыли), примерно планируете график на 20 дней и принимаетесь за работу.

По истечении 1000$ бюджета и 20 дней у вас для клиента есть два ответа:
1. Посмотрите на сайт — клиент доволен, всё работает, всё замечательно;

2. За 1000$ и 20 дней мы нарисовали только шапку — у нас гибкий объём работ, весь остальной функционал не вместился в эту итерацию и будет продолжен в следующих, если вы продолжите с нами работать.

Я правильно понял смысл ФФФ?


23 ноября 2011

Нет.

Если мы согласились сделать сайт за 20 дней и 1000 долларов, через двадцать дней сайт будет висеть в интернете. Но, возможно, без шапки — и это будет наше совместное с клиентом решение.

Мария Смирнова
25 ноября 2011

Мы в «Интернет-клиенте» три месяца назад перешли на оплату за время по разработке сайтов. До этого уже год назад внедрили схему на поддержке.

Труднее всего оказалось обеспечить чёткую фиксацию сроков работниками в таск-менеджере, а не убедить клиента платить за время.

Клиента обычно смущает то, что мы можем сказать, что работа делалась день, а на самом деле делали час. Это беспокойство снимается очень просто, достаточно сказать клиенту, что мы поставим ему стороннюю систему контроля времени типа Odesk. Также объясняем, что платить за время выгодно и клиенту, так как нам не нужно в плане-графике и смете соответственно перезакладываться на риски. Ещё ни разу не попросили установить систему контроля, но сам факт нашей открытости уже убеждает клиента купить время. Словом, проблемы в продажах времени нет.

Alex Tikonoff
17 октября 2017

Мы внедряли Scrum и получали отличные результаты ещё в 2005 году. Почему всем не ознакомиться с этой методологией и не изобретать велосипед?


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Несмотря на то, что между нами была договорённость о работе по ФФФ, клиент был в бешенстве 5 Согласование замечаний Можно ли в договоре добавить пункт, что срок увеличивается пропорционально времени на согласование дизайна? 5 Как в бюро отвечают на вопросы «А почему ещё не готово?» и как борются со срывами сроков? 4




Недавно всплыло

О тексте как базовом элементе 6 Правдивость 3 1 3