Сколько стоит «правота» Клиента?

В последнее время огромное количество обсуждений вызвал пост о переходе с модели Fixed Price на Time and Material (20 комментариев!). Камнем преткновения стал вопрос о том, кто должен платить за «недопонятые или недосказанные» требования.

Сразу хочу сказать, что мы выносим за рамки обсуждения то, что требования не должны меняться, Заказчик и команда должны «протоколировать» все договоренности и т.д. Во-первых, требования никому и ничего не должны (доказано холиварным постом «Предпоследняя версия требований»). Во-вторых, вести протокол всех договоренностей с Заказчиком и его командой становится невозможным при размере команды примерно больше чем 5Х5 (5 – локально, 5 –аутсорсеров).

Я бы не возвращался к этой сложной теме, которая вызывает огромное количество споров, если бы недавно не натолкнулся на одну интересную идею из «другого бизнеса», которая, как мне кажется, может быть очень даже применима к ИТ.

Клиент неправ только в 2х случаях: Когда идет речь о принципиальной справедливости или Когда идет речь об «относительно» большой сумме денег.

Справедливость – это когда явно что-то описано или договорено, а Заказчик пытается вас обмануть. Это случается крайне редко, потому что факты обычно довольно упрямая вещь и адекватному человеку тяжело не согласиться с фактами. А второе – именно то, что нужно внедрять в ИТ компаниях.

Установите пороговое значение (деньги и/или время), до которого клиент всегда прав!

Философия этого подхода говорит о том, что вы должны делать Клиента счастливым, если его запрос не превысил какую-то «пороговую» сумму. Например, при контракте в 1000 у.е. это может составить 100 у.е. То есть, если Заказчик придет и скажет, что вы недопоняли требование ААА и при этом ваша оценка на изменение меньше 100 у.е., то стоит делать это изменение безоговорочно. Если это превышает данный порог, то необходимо объяснить Заказчику, что это значительное изменение требований, что приводит к пересмотру цены и времени.

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

Подавляющее большинство ваших клиентов – хорошие!

Можно предположить, что 1-5% ваших клиентов – жулики, которые пытаются вас «нагреть по полной», а значит против них нужно играть по жестким правилам. С другой стороны, относясь к остальным 95-99% как к жуликам, вы будете блокировать рост доверительных долгосрочных отношений. Я лично бы не стал клиентом компании, которая каждый мой «чих» документирует и потом тычет мне в лицо бумажками, хотя проблему мою так и не решили.

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

Вы контролируете суммы расходов

У вас есть «порог», после которого вы не будете делать те или иные изменения, так как работа станет невыгодной. И этот порог вам четко понятен и вы можете его контролировать. А это значит, что это не должно отразиться негативно на прибыльности вашего проекта.

Вы не тратите время на споры и переговоры

Пропуская споры, вы потратите время более продуктивно с точки зрения реализации идей Заказчика. В общем случае Вы и Заказчик долго бы препирались о том, кто виноват в этом «упущении», кто должен его исправлять и за чей бюджет. Иногда доходит до смешного, когда на проекте в 50 часов, обсуждение доработки в 5 часов занимает 20 часов времени команды (пример модели lose-lose). В своем тренинге Аутсорсинг как сервис я использую понятие «налог доверия», для описания феномена потери времени на том, что мы друг другу не доверяем.

Заказчик всегда рад получить чуть-чуть больше чем хотел

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

Вы выстраиваете долгосрочные отношения

Возьмем на выбор 2 компании, с которыми общался клиент. В первой ему разрешали вносить «уточнения» или делали что-то больше, чем требовалось. Во второй команда строго противилась всем изменениям и до хрипоты спорила с каждым уточнением. Угадайте, к кому он пойдет со следующим проектом (даже если он не на тех технологиях, в которых вы сильны)? Какую команду он порекомендует друзьям?

Вывод: Я понимаю, что всегда можно найти огромное количество причин, почему данный подход кажется нереализуемым. Но тенденция ужесточения конкурентной борьбы будет диктовать свои условия, которые заставят нас все больше задумываться над тем, как сделать сервис более клиенто-ориентированным. И если такой подход работает в других областях, то почему ИТ хуже?

P.S. Эту идею я встретил в книге «Клиенты на всю жизнь». Книга о том, как построить хороший сервис в области продаж и обслуживания автомобилей. Но идеи просто замечательные. Очень рекомендую для прочтения!

Feb 8th, 2011
  1. Если порог — допустим X. Как вы себя поведете, если стоимость изменений 10X? А если заказчик уже сделал 19 изменений стоимостью 0.5 X и запросил 19-ое?

  2. пардон, запросил 20-е

  3. Feb 9th, 2011 at 21:00 | #3

    @ Александр
    На первый вопрос ответить легко.

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

    И работать по стандартной процедуре change request и т.д. Тем более, что если вы покажете цифры о том, что проект станет убыточным… (ну это из разделе идеальных доверительных отношений).

    На второй вопрос хорошо отвечает автор книги, которую я рекомендовал. Перефразируя скажу, что и 19 изменений – это много (хотя опять же, смотря какой Заказчик). Посчитайте, выгоден ли Заказчик сейчас и ГЛАВНОЕ в перспективе. Если да, то идите на уступки. Если нет – см. п. 1 :)

  4. Feb 10th, 2011 at 07:58 | #4

    Сергей,

    Когда начал читать заметку, сразу вспомнился Сьюэл :) А в конце оказалось, что и правда он! Спасибо за правильную заметку!

    Коллеги, как человек уже использовавший подобную схему, могу сказать, что она
    1) Работает в IT на живых пользователях.
    2) Приносит очень сильную лояльность клиента и, следовательно, деньги.

    • Feb 10th, 2011 at 08:31 | #5

      @ Владимир Кузьмин

      С удовольствием опубликую Вашу историю в разделе “My Story“. Если есть факты того, что это работает у вас, значит я не одинок :)

      Пишите, стучите в контакты!

      P.S. Кстати, стоит отметить, что все таки я доработал идеи Сьюэла нашими ИТшными практиками!

  5. Feb 10th, 2011 at 09:42 | #6

    А вот у нас в практике был такой случай. Сделали мы систему одну. Отдали заказчику в опытную эксплуатацию, проходит опытная эксплуатация, заказчик и говорит
    - совсем не то, нам нужно принципиально другие процессы реализовывать.
    - Как же не то, удивляемся мы. Мы же всё по ТЗ делали, которое с вами согласовывали.
    - Ну вот значит надо ТЗ поменять. Мы же когда ТЗ согласовывали не думали, как это получится…

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

    • Feb 10th, 2011 at 16:11 | #7

      Павел,
      Опять же, вопрос первый: А выходят ли эти “пожелания” за рамки “дозволенного бюджета”. Если нет, то сделайте их и пусть Заказчик будет счастлив. Он обязательно придет к вам еще.

      Плевые изменения – нужно объяснять. Я вот например испльзую аналогию с первым этажем здания или несущими колоннами. Вы же не можете просто так “убрать” или “подвинуть” колонну на 3 метра влево, а то у меня телик не влазит :)

      И последнее, клиент всегда будет считать, что вы пытаетесь отбриться, пока его запросы не будут удовлетворены или даже перевыполненны. Хотите пример? – Попробуйте обменять обувь в магазине… если она вам “тесна” :)

  6. Feb 10th, 2011 at 12:36 | #8

    Сергей, на цельный пост, думаю, не наберется. Так что напишу здесь. У меня была некогда аутсорсинговая фирма. Занимались поддержкой информационных систем малого бизнеса. Так вот, порог на дополнительные работы, которые мы делали бесплатно, был 10% от месячной цены обслуживания.

    Клиенты нечасто пользовались чем-то дополнительным, так что подобные затраты можно было себе позволить. До того, как я прочитал книжку и начал применять на практике эти принципы, у меня за 6 месяцев прибавилось 4 клиента, а 2 ушли. Сарафанное радио совсем не было методом рекламы. С тех пор, как я стал применять такую тактику широко, за следующий год пришло более 30 клиентов. Ушло только 2, причем 1 из них просто “перерос” наши тогдашние возможности.

    Реклама при этом практически не использовалась. Пользователи рекомендовали нас друзьям и знакомым. Так что подобная клиентоориентированность приносила клиентов и деньги. При нулевой цене привлечения клиента я был рад делать дополнительную работу бесплатно. Это стало очень серьезным конкурентным преимуществом.

    Так что подобное поведение окупается. Если не всегда, то довольно часто.

    • Feb 10th, 2011 at 16:22 | #9

      30 к 2 – это просто отлично! Всего то за 10% бюджета (и то не для всех)!
      Владимир – зачет! :)

      • Feb 10th, 2011 at 16:33 | #10

        Еще и сокращение практически до 0 рекламных расходов. Так что меньше 10%. Люди сами звонили и предлагали с ними работать ;)

Leave a comment