Кельник
Компания
35,21
рейтинг
29 ноября 2012 в 12:38

Разное → Как снизить риски взаимодействия с клиентами в три этапа

Совсем недавно проект «Рейтинг Рунета» опубликовал неудивительную и оттого ещё более печальную статистику об оформлении отношений между заказчиком и веб-студией.

Шокирующие факты:
  • 17,5% процентов всех сайтов (и более 30% сайтов дешевле 100 000 рублей) делается вообще без всяких договоров.
  • Более 26% сайтов дешевле 300 000 рублей делается с формальным договором, служащим лишь основанием для перечисления денег.
  • Более 60% сайтов дешевле 100 000 рублей делается без техзадания или по техзаданию клиента.

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

Этап первый: Договор


Мы вообще не понимаем, как можно работать без договора, и почему рынку надо это объяснять. Очевидные и неумолимо реализующиеся риски при работе без договора:
  • Клиент не принимает результат выполнения работ. (Нет, что-то не то… Давайте ещё поиграем шрифтами?)
  • Клиент меняет требования. (Вы знаете, пока вы делали эту часть проекта, мы поняли, что нам ещё нужно…)
  • Происходят задержки с оплатой. (Да-да-да, мы заплатим, вы пока продолжайте второй этап.)

Это не просто теория, это несколько раз происходило с каждой компанией, работавшей без договоров или со слабо подготовленным договором. То есть факт необходимости договора по сути подтверждался «кровью» (а точнее, финансовыми потерями) многих компаний.

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

Самые важные пункты, которые мы внесли в наши договоры за время существования компании, были осознаны на горьком опыте — за каждым из них стоит один или несколько «проблемных» проектов. Поговорим о некоторых из них.

Пункт 1. «Виды и объём подлежащих выполнению работ подлежат уточнению и корректировке в соответствии с разрабатываемым Исполнителем Техническим заданием к настоящему Договору, которое с момента утверждения его заказчиком становится неотъемлемой частью Договора и приложением к нему».
У молодых компаний существует риск прописать в договоре реализацию некоторого функционала до его проектирования и качественной оценки стоимости.

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

Пункт 2. «В случае выявления в ходе исполнения обязательств по Договору необходимости выполнения дополнительных видов работ, не предусмотренных Договором (в т. ч. работ по регистрации доменного имени Заказчика, запуск проекта на хостинговой площадке Заказчика, написание текстов), такие работы выполняются Исполнителем на основании дополнительного письменного соглашения Сторон».
Борьба с теми же самыми рисками. «А мы думали, что вы зальёте тексты», «а мы думали, что вы развернёте хостинг» и так далее по отношению к тем работам, которые не входят в вашу структуру услуги.

Пункт 3. «Заказчик обязуется предоставить Исполнителю все запрашиваемые исходные данные и иную информацию, необходимые для исполнения Исполнителем обязательств по Договору. Такие исходные данные и информация должны быть актуальными, достоверными, полными и непротиворечивыми.

В случае нарушения положений настоящего пункта Договора Исполнитель вправе приостановить выполнение работ до устранения Заказчиком соответствующих недостатков исходной информации».
Качественное проектирование и разработка дизайна невозможны без знания бизнеса заказчика, его потребителей, состава его коммуникации с потребителями.

Дизайн с «Lorem ipsum» и текстами с Яндекс.Рефератов не решает бизнес-задач (это тема отдельного разговора, но это так). «Соберите нам сайт, а мы его потом наполним» — не работает. В результате такой уступки на свет появляется мертворождённый сайт, на котором никогда не появится контента (если, конечно, вы прошлым пунктом огородили себя от его создания за бесплатно).

Пункт 4. «В случае запуска проекта на хостинговой площадке Заказчика, Стороны заключают дополнительное соглашение на проведение таких работ. Стоимость запуска определяется в зависимости от параметров хостинга Заказчика».
Вы никогда не мучались со сборкой хитрого пакета PHP с непонятными модулями, которые работают на экзотической операционной системе заказчика, потому что его администратор, собравший этот сервер из бухгалтерских компьютеров, сам не может этого сделать? Если пока нет, то лучше внесите этот пункт в договор.

Пункт 5. «Если в процессе проверки работоспособности сайта (тестирования) у Сторон не возникло замечаний и корректировок по внешнему виду и функциональности сайта (без учёта содержания контента, размещённого Исполнителем на сайте), проект считается завершённым».
Классика: заказчик наигрался со шрифтами в процессе работы над дизайном. Сайт готов, а достать ЛПР (лицо, принимающее решения), чтобы подписать акт сдачи-приёмки, оказывается невозможно. Он то на конференции, то на Мальдивах, то занят.

Сайт готов, оттестирован, но его не принимают (и не оплачивают) полгода. Внедрение такого пункта помогает немного выправить cashflow:
Пункт 6. «Заказчик обязан в течение 5 (пяти) рабочих дней со дня получения от Исполнителя результатов выполненных работ подписывать со своей стороны Акт сдачи-приёмки результатов выполненных работ и направлять его Исполнителю либо представлять Исполнителю письменный мотивированный отказ от подписания Акта.

В случае неподписания Заказчиком Акта сдачи-приёмки результатов выполненных работ и непредставления мотивированного отказа от его подписания в указанные сроки, работы считаются выполненными Исполнителем надлежащим образом. В указанном случае Заказчик лишается права на предъявление претензий, связанных с обнаружением недостатков выполненных работ».
Пункт в поддержку предыдущего, закладывает конкретный срок на формулировку доработок.

Самое главное слово в юридических бумажках — «письменный».
Пункт 7. «В случае необоснованного отказа Заказчика от подписания Акта сдачи-приемки результатов выполненных работ, а также в случаях, предусмотренных в предыдущем пункте, Исполнитель вправе приостановить дальнейшее выполнение работ по Договору и потребовать от Заказчика уплаты 100% (сто процентов) от стоимости соответствующих работ».
Гвоздь в крышку несогласования результатов работ.

Пункт 8. «Исполнитель гарантирует Заказчику:
  • авторскую оригинальность результата выполненных работ и действительность основанных на получении результата выполненных работ авторских прав;
  • что при выполнении работ и создании результата выполненных работ по настоящему Договору не были нарушены права третьих лиц, включая неотчуждаемые личные неимущественные права;
  • что добросовестным (традиционным для данного типа объектов) использованием результата выполненных работ Заказчик не нарушит авторских прав (как имущественных, так и неимущественных) третьих лиц».
Не только заказчик несёт ответственность перед исполнителем, но и наоборот. В наших договорах строго прописаны наши обязанности, в том числе по отношению к правам на элементы работ (иллюстрациям, видео, программному обеспечению и так далее).

Этап второй: Отдельное проектирование


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

Почему договор не всегда работает:
  • Некоторые клиенты (сюрприз!) вообще не читают договор.
  • Даже если в случае конфликта вы заломали клиента договором, это не сделает его удовлетворённым.
  • Иногда суть договора читает менеджер проекта, форму согласовывает юридический отдел, а директор подписывает, не глядя. Тот самый директор, который любит играть шрифтами.

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

Основной коммуникативный риск связан с тем, что заказчик и исполнитель не одинаково понимают желаемый результат или не понимают его вовсе. Да-да, это про целеполагание, проектирование, прототипы и так далее.

Мы выделили этап проектирования в наших договорах ещё в 2006 году. Правда, тогда проектирование сводилось к написанию неких функциональных требований, где описывается базовая концепция сайта, плавно перетекающая в развёрнутое техническое задание. Тогда мы считали, что такой подход наилучшим образом решает задачи клиента.

Но старая схема «Оценка договора на фиксированную сумму → Подписание договора → Проектирование → Дизайн → Разработка» всё равно работала плохо, потому что в предварительной оценке стоимости по-прежнему легко было ошибиться на порядок. Даже с учётом прописанных пунктов в договоре это приходилось объяснять клиенту и это вызывало у него затруднения при планировании бюджета. Клиент не виноват, что мы ему не смогли объяснить, что он не понимает, чего он хочет.

Поэтому в 2011 году мы перешли на двухэтапную схему ценообразования:
  1. На проектирование: стоит фиксированную сумму, которую мы определяем до начала работ.
  2. И собственно разработку, стоимость которой определяется в результате проектирования.

Эта схема работает удобно и гибко, так как позволяет на этапе проектирования:
  • Выявить и описать все «хотелки» клиента, включая не существовавшие на этапе продажи проекта.
  • Продемонстрировать динамику изменения «хотелок».
  • Обосновать увеличение сроков проекта.
  • Оптимизировать состав и этапность разработки в зависимости от доступного клиенту бюджета.

В результате и волки сыты (клиент понимает, чего он хочет, сколько это стоит, и сколько он готов платить), и овцы целы (исполнитель не «попадает» на обязательства работать себе в убыток, чтобы закрыть последствия неточной оценки проекта). И ещё очень важный момент — в процессе проектирования вы сможете убедить клиента, что вы действительно хороши в работе и получить +100 к лояльности. Может быть и наоборот, придёт понимание, что дальнейшее сотрудничество вам некомфортно, и вы разойдётесь с минимальными потерями с обеих сторон.

Этап третий: Предпроектная презентация


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

Даже несмотря на то, что мы выделили этап проектирования, остаются высокие риски, связанные с тем, что менеджер проекта всё понимает, а ЛПР не понимает ничего.

Классическая жизненная ситуация: менеджер клиента всё понимает, всё подписывает, со всем согласен, всегда кивает головой, полное взаимопонимание… Менеджер агентства расслаблен, он получил идеального клиента…

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

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

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

В предпроектной презентации мы быстро и уверенно рассказываем то, что должен знать ЛПР:
  • Этапность работ, зачем каждая из этих работ нужна для клиента.
  • Этапность оплат.
  • В какие моменты потребуется его внимание и почему для клиента это важно.
  • Каковы риски полного делегирования своему менеджеру различных этапов согласований.
  • Обязанности заказчика по предоставлению необходимой информации.
  • Какие именно риски мы снимаем такой «сложной» схемой и почему нельзя просто нарисовать то, что ему понравится.

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

Что ещё интереснее, в процессе презентации нередко у ЛПР с хрустом начинается разрываться шаблон понимания, что такое сайт. Правильно построив презентацию, можно получить ещё +100 к лояльности. Это происходит, потому что клиент понимает масштаб и сложность работ, которую вам предстоит выполнить.

Этапы четвёртый, пятый, шестой…


А что же дальше? Мы работаем над многими вещами, увеличивающими эффективность взаимодействия с крупными заказчиками, включая создание интегрированного информационного пространства с клиентом, не пускающего его в глубокую «кухню» проекта. В то же время, мы уверены, что даже небольшие компании могут добиться существенного снижения коммуникативных рисков чисто организационными мерами, не прибегая к хитрым средствам автоматизации. Главное — не останавливаться.
Автор: @Neznaikos
Кельник
рейтинг 35,21
Компания прекратила активность на сайте

Комментарии (28)

  • 0
    Хорошая статья. Но договор договором, а если заказчик не собирается исполнять договор? Или платит большие деньги, но при этом хочет свою форму договора?
    • 0
      Насколько я понимаю, если какая либо сторона не соблюдает условия договора, то на нее можно подать в суд.
      Форма договора может быть любая, но в любом случае, договор должен составляться на взаимовыгодных условиях, иначе вы рискуете, остаться и без этих больших денег.
    • +1
      Поэтому и описаны этапы 2 и 3, насколько я понимаю. А если заказчик хочет свою форму договора, то имеет смысл либо вносить туда те пункты, без которых вы принципиально не согласны работать, либо, если это не получается, просто отказываться от заказа. Такая история грозит вам очень большими рисками, даже несмотря на «платит большие деньги».
    • 0
      Что делать в случае неисполнения договора заказчиком каждый может определить для своей компании сам: судиться, договариваться, разрывать договор.

      Главный вопрос — почему заказчик его не исполняет, возможно ответ на этот вопрос даст решение.

      Другая форма договора — почему нет, если большие деньги полностью нивелируют все возможные риски. Если нет и вы не можете туда добавить то, что важно для вас, лучше отказываться от такого договора.
      Опять же, нет никакого универсального метода (договора), который позволит решить все проблемы раз и навсегда.

  • –1
    По поводу «поиграться шрифтами»: я плохо понимаю, как дизайн можно загнать под ТЗ. Имхо, невозможно регламентировать творчество, а дизайн — это творчество, которое преследует определенные цели.
    • 0
      Имеется в виду что клиент начинает докапываться до дизайна по мелочам, вносить различные правки, которые замедляют процесс сдачи проекта. А на счет загонять дизайн в ТЗ — без этого никак, не выкидывать же этот пункт полностью из документа, иначе его никто не оплатит. Тут возможно берется сложность проекта, опыт ответственного дизайнера, его консультация по времени, так примерно и прикидывается.
    • 0
      Например, архитектура (строительство домов) — это вещь и творческая, и предельно регламентированная.

      То же самое и с сайтостроением. Если правильно выстроен процесс, то там творчество находится на своём месте, а инженерия на своём.

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

      Как я уже писал выше, нельзя выстроить стену, которая раз и навсегда оградит от всех проблем…
  • 0
    Тоже пришли к выводу, что прописывать заранее необходимо как можно больше. И зачастую даже не для того, что бы потом иметь возможность “махать кулаками“, а для того, что бы заказчик сам понимал как и что будет делаться. Ибо вы на 100% правы, что ЛПР зачастую даже не читают договор.
    • 0
      Попробуйте помимо прописывания, еще и рассказать об этом, заострив внимание на проблемных местах, чтобы для тех, кто не читает, не было сюрпризов.
      • 0
        обязательно рассказываем на встречах, но, во-первых, далеко не всегда ЛПР приезжает на встречу лично (те же вариации на тему Мальдив, важный заседаний и прочего), а во-вторых, даже доехав до встречи, они частенько сидят и кивают балваньчиком.
  • 0
    Интересно, что именно у вас является результатом работ по завершении этапа Проектирование?
    • +1
      По результатам проектирование:

      1. Интерактивный прототип.
      2. Отчет о тестировании прототипа фокус-группой (если в процессе тестирования выявлены нарушения сценариев использования, они устраняются и тестирования проводится вновь).
      3. Техническое задание на разработку (на базе реального ТЗ, которое может многократно изменяться в процессе проектирования происходит оценка дальнейшей разработки)
      • 0
        А какой софт, если не секрет, используете для прототипирования?
        • 0
          Если речь об интерактивном прототипе, то только Аxure
  • 0
    3. Техническое задание на разработку (на базе реального ТЗ, которое может многократно изменяться в процессе проектирования происходит оценка дальнейшей разработки)

    Честно говоря не понял про ТЗ, которое может меняться в процессе проектирования. Имелось ввиду, в процессе разработки?
    Если да, как вносите поправку к первоночальной стоимости, доп. соглашениями к договору? Или это как-то отдельно в договоре обговаривается?
    • 0
      ТЗ является последней работой в рамках Проектирования. Я не представляю, как можно писать ТЗ, если не определены методы достижения целей и задач проекта.

      Чтобы все обкатать придуманные идеи, создается и тестируется прототип. Уже после того, как он полностью готов, оттестирован и все сценарии выполняются, он описывается в ТЗ.

      Наверно, фраза ТЗ постоянно меняется некорректна, скорее ТЗ постепенно рождается в процессе проектирования.

      В договоре, конечно, оговорено, что дополнительные работы, не оговоренные прототипом и ТЗ, выполняются по доп.соглашениям.
  • 0
    это все хорошо и правильно, как если бы собрались все хорошие люди и убили всех плохих. На практике это все не реально. Можно сколько угодно умничать, пока не столкнешься с практикой. Большие системы могут только год изучаться для построения ТЗ, а за это время изменяются быстрее, чем пишется ТЗ. Взять например Укртелеком. Сроки любой разработки тоже будут сорваны — не зависимо от того есть ТЗ или нет. Любой. От укртелекома до Сталкера, от Дюка до Дума. :)
    А так — для сферического коня Шрёдингера в ваккууме — все верно — без ТЗ и предоплаты нельзя даже «здрасьте» говорить…
    • +1
      Статья описывает реальную практику нашей компании. Без договора нельзя «здрасьте» говорить. ТЗ разрабатывается не до договора, а в рамках договора.

      В случае больших систем их изучение — это отдельный проект, который имеет свои задачи, свою смету и свои результаты.
      • 0
        Все правильно, но процесс изучения крайне сложно укладывается в сроки и смету (попробуйте описать одной цифрой и датой поиск Янтарной Комнаты или воды на Марсе). Кроме того, когда он закончен, система к тому времени уже изменилась опять. Так что любой договор на эту тему — опять фикция. Его надо будет корректировать, продлевать и пр…
        Плюс не каждому заказчику можно пояснить, что написание ТЗ стоит 100500 долларов. И ваши конкуренты выиграют тендер еще на этапе ТЗ. А итог все равно простой — проблема заказчика должна быть решена.
        • 0
          В такой модели, о которой вы говорите, предложенная схема действительно не работает. Работает консалтинг с почасовкой.

          В той модели, с теми заказчиками (а они не мелкие) и в том рынке, где работаем мы, предложенная схема работает. Да, она не работает для полётов на Марс, но и не должна.

          Что касается ценовой конкуренции — мы в неё не играем, так что если конкуренты выиграют этот тендер, честь им, хвала, и удачи в работе с клиентом.
        • 0
          Почему вы решили, что вам необходимо сразу и до рубля посчитать стоимость поиска воды на Марсе? Об этом как раз идет речь во 2 части статьи: посчитать все и сразу и точно невозможно.

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

          Кстати, кто-то вообще работает по скраму и успешно продает такой подход.
  • 0
    Согласен с автором статьи. Сейчас правда мы поменяли существенно процесс, т.к., хоть и занимаемся заказной разработкой, но умудряемся работ по настоящему скраму, что немного облегчает задачу договоренностей.
  • +1
    Из моего опыта.
    Встречал, приближенно, три типа заказчиков.
    1. Хочу вот такую штуку. Без техзадания. Без требований. Устное или письменное перечисление благих пожеланий.
    2. Вот техзадание. Все довольно подробно, но без конкретных требований.
    3. Техзадание и список требований со скриншотами, таблицами, порядком и принципами работы, описанием оборудования и моделей девайсов.

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

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

    В третьем все проходит на ура, список требований, как часть договора, готовится техпроект, утверждается, начинается разработка. Принимается, подписывается акт приемки. Все довольны, заказчик остается с вами и в дальнейшем снабжает проектами и работой. Как причину объясняет, что у нас все быстро, качественно, то что надо, в срок, и в 2-3 раза дешевле.

    Имхо, когда заказчик точно знает, что хочет, то знает чего от исполнителя требовать. И адекватно стоимость и качество оценивает.
    • 0
      Если заказчик сливается по причине «нашёл в два раза дешевле» — это прекрасно. Если заказчик выбирает только по цене, с ним не получится нормального проекта — пусть мучаются другие.

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

      Просто в первом и втором случаях существуют ещё внятные заказчики, которые при грамотном предпроектном общении покупают проектирование. Вот с такими тоже имеет смысл работать.
      • 0
        Заказчик выбирает по цене, потому что он не знает, по какому еще критерию ему выбирать среди студий с одинаково няшными картинками в портфолио.
        • 0
          А это уже вопрос маркетинга и позиционирования. Естественно, заказчику нужно объяснять, по какому критерию надо выбирать, чтобы выбрали именно вас.
          • 0
            Было бы интересно почитать статью о вашем опыте в этом.
  • 0
    Хороший обзор пунктов в договорах от Андрея Терехова.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное