Лого vc.ru

Как вести себя с заказчиком, который мешает проекту — опыт агентства «Дело в сайте»

Как вести себя с заказчиком, который мешает проекту — опыт агентства «Дело в сайте»

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

Поделиться

«Дело в сайте» — устойчивая веб-студия полного цикла с отработанным механизмом работы. Мы из тех ребят, что не первый год замужем: хорошо шаблонизируем работу, умеем оценивать сроки и выдерживать их, понимаем как удержаться в графике, где нагнать, а где срезать стоимость. Но иногда наш студийный внедорожник крепко потряхивает. Это значит, что мы наехали на заковыристого клиента.

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

Мы познакомились тёплым и солнечным ноябрьским утром. Клиент (для простоты будем называть его «Компания “Джессика”») прислал нам письмо с просьбой оценить сайт. «Джессика» производит, к примеру, бани, и продаёт их с помощью дилерской сети. У всех людей бани разные, поэтому дилеру нужно детально рассчитать заказ, выбрать компоненты, даже нарисовать несложный чертёжик.

В «Джессике» хотели всё это автоматизировать могучими силами интернета — создать закрытый сайт с калькулятором. Мы прикинули время, стоимость и выслали будущему клиенту письмо с примерным рассчётом. Смеркалось.

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

Тёплым и солнечным мартовским вечером мы заключили договор с кучей различных приложений. Мы внимательно прочитали приложения и удивились — в них «Калькулятор Бань» обрастал новой функциональностью. Это, очевидно, прибавило бы нам работы, но договор мы всё же подписали.

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

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

Урок 3. Перед подписанием договора нужно понять и отдельно зафиксировать материалы, которые есть у заказчика. В нашем случае у «Джессики» было только туманное представление о том, какой калькулятор нужен и что он должен делать. В результате клиент тратил наше время на то, чтобы сделать свою работу — придумать, что же должен делать калькулятор.

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

Урок 4. Разработчик должен строго следовать прописанному в договоре порядку работы. Если разработка сайта состоит из прототипирования, дизайна, программирования и вёрстки, то не смейте начинать с программирования. Нужно либо отдельно прописывать свободный порядок работы, либо сразу расставлять этапы в правильном порядке.

Бани — это сложная штука, поэтому нам пришлось самим превратиться в конструкторов бань и немало попариться над этой задачей. Мы ездили на встречи к «Джессике», обсуждали особенности рассчёта печей, предбанников и берёзовых веников. Казалось, что «Джессика» погружается в особенности своей работы вместе с нами. Часто задачи придумывались на ходу. Сложность калькулятора увеличивалась — он обрастал всё новой и новой функциональностью.

Урок 5. Иногда бывает так, что для заказчика результатом является не сайт, а понимание того, чего они хотят. Вы в этой ситуации выступаете консультантом: помогаете клиенту разобраться, ходите с ним за ручку (как мы с «Джессикой»). При этом вы сами не понимаете своей роли. Это неприятная ситуация, которой нужно избегать — клиент бесплатно изучает свой проект, а вы тратите своё бесценное время. 

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

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

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

Урок 7. Как только заказчик ощутимо затягивает сроки, нужно сразу же переводить отношения из телефонно-почтовых в формат официальных писем с уведомлением о вручении и описью вложения. Это не попытка напугать, а способ предупредить клиентскую похоть.

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

«Джессика» и дальше хотела вытаскивать новые фишечки, словно фокусник вытаскивает кроликов из шляпы. Но тут, кажется, мы все устали.

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

Урок 8. Следуйте принципу «ФФФ»: сначала запускаем работоспособный прототип, а потом дорабатываем его. Никаких попыток строить космическую ракету из банной печи и досок от забора! Разумеется, не соглашайтесь просто так делать что-то, что не входит в договор. Новая функциональность закрепляется дополнительным соглашением. И новым счётом. 

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

Представители «Джессики» нашли нового исполнителя на сайт прямо на курсах по «Битриксу» и предложили нам расторгнуть договор. «Джессика» хотела выкупить у нас прототип калькулятора для бань за совсем небольшие деньги. Подумав, мы отказались. Мы выслали им письмо-обоснование повышения стоимости, а в ответ получили претензию.

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

На сегодняшний день наши отношения с «Джессикой» вошли в стадию воинственной комы. Заказчик требует от нас вернуть предоплату и завершить отношения, мы уверены в своей оценке проекта и готовы отстаивать свою точку зрения в суде. Мы обязательно расскажем об окончании этой истории. Надеемся, что наш опыт окажется для вас полезным — берегите умные лбы от глупых заказчиков и юридических грабель.


Чтобы написать колонку для ЦП, ознакомьтесь с требованиями к публикуемым материалам.

Популярные статьи
Показать еще
Комментарии отсортированы
как обычно по времени по популярности

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

Такие клиенты это 80% клиентов, по-крайней мере крупных. Говорю по опыту.
Я отсудил и отвоевал денег больше, чем заработал на нормальных проектах.
Работаю, правда, тоже в сфере ИТ.

Главное - научиться детектировать таких клиентов в зародыше и не начинать с ними работать.

0

В этой ситуации виновата студия. Вернее менеджер студии, который отвечает за проект.

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

Расторжение в одностороннем порядке – как правило, возврат денег. За 2-3 месяца мы отфигачили не слабый конструктор, который явно стоит больше, чем аванс по договору.

Круто, а отчего заказчику об этом не сказали?

0

Сказали, он с ценой не согласился, даже торговаться не стал ). Попросил письмо-обоснование и на этом перешли в режим почтовой переписки. Сначала претензии, теперь отказ. Мы предложили пойти на мировое, встретиться и договориться.

С себя вы, конечно, всю ответственность за провал снимаете?

Старались как могли. По договору 25 дней на утверждение ТЗ. А смету утверждали на основании списка общих требований.

ну а к заказчику какие претензии, если смета на базе хрен знает чего?

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

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

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

P.S. А вообще лучше работать по маленькому договору (не переписывать весь ГК), так его будет проще согласовывать, а по каждому этапу работ – приложение.

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

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

В выборке из 3 рандомных дней в Питере все 3 - солнечные, это сильно)

Не, надо все фиксировать и прописывать отдельно. 90% проблем решатся сами собой.

0

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

0

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

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

0

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

Что с актом выполненных работ, с договором? Если он составлен по уму, то через суд вынете в легкую.

0

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

0

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

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

Ну и самый главный вывод - нефиг к битрегзоидам за разработкой обращаться, они на другом деньги делают)))))

Лучше всего про вас скажут не награды, а это d.pr/i/15E9Y

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

/thread

0

Больше не буду вас благодарить, так и быть, уговорили.

0

Странно, как такая опытная фирма не соблюдает простейших вещей, на которые натыкаются только новички-фрилансеры.

1) ТЗ нужно писать четко, и здесь представитель заказчика совершенно прав: ТЗ было полностью расплывчатое, раз его можно трактовать, как угодно. Что это вообще за ТЗ, если вы 3 месяца разбирались, что за калькулятор там вообще нужен?

2) ТЗ исполнителем пишется за деньги ДО начала работ, отдельным контрактом. Для небольших сайтиков его можно включить в стоимость, но такие мелкие заказы опять же интересны только фрилансерам.

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

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

−1

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

0

Было похожее недавно. Делали web app для расчета и аналитики различных рисков для нефтегазовой компании.
Мы до последнего внедряли новые фичи, клиент за это периодически переводил некоторую сумму. На говнокод, что получился я даже смотреть не могу.
Когда около 80% денег было заплачено просто оставили все как есть на его сервере. У него вроде претензий нет, мы тоже в минусе не остались.
Как уже написали, ошибки в:
1) Не был проведен предварительной аналитической работы (я думаю просчет рисков будет даже посложней чем просчет бань ;))
2) Проект больше выглядел как стартап. Стадий исследования и прототипирования разумеется не было
3) ТЗ конечно же

Боже, как все знакомо.)))))))) даже смешно стало)))) мы сейчас с такой Джессикой работаем, правда они маленькая такая компания и сайт они хотели такой маааленький простенький изначально))) а потом бубух и на тебе)))) хотим это, хотим то.

0

а, ну и сами мы такие маааленькие пока, только начинаем.

0

Ребят, вы хоть PMBOK почитайте перед тем, как жаловаться на заказчиков.
Управление проектами - такая наука есть )))
Для первого проекта простительно)

0

Рад, что не остались равнодушным.

0

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

Максим, верю, что вы очень умный и правильный человек, никогда не ошибаетесь и советуете всем только хорошее. Спасибо!

0

Просто посыл статьи не корректен. Это же не школьный форум.

0

Денис, не расстраивайтесь вы так. Все сливали бюджеты. Что вы, как ребенок? ))

0

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

0

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

0

Если по сути:

Урок 1. Прежде чем заключать договор с клиентом, узнайте о его предыдущем опыте разработки.

Если вы еще менее профессиональны, чем предыдущий разработчик, ваш результат будет еще хуже.

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

Он потому и крупный, что умеет содрать с вас 3 шкуры.

Урок 3. Перед подписанием договора нужно понять и отдельно зафиксировать материалы, которые есть у заказчика.

Это называется "коцепция проекта".

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

И не только разработчик. Договор на то и договор, что, как говорится, дороже денег.

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

Этот этап называется "уточнение требований, проектирование, написание ТЗ".

Урок 8. Следуйте принципу «ФФФ»: сначала запускаем работоспособный прототип, а потом дорабатываем его.

Это называется "гибкая разработка".

0

Господи, ребята, это просто смешно. Мало того, что вы растянули все возможные сроки и отпустили клиента, так вы еще и не смогли четко и ясно обосновать свою позицию, погнавшись за мнимыми попугаями. Разочарован. Вам эта страшилка точно не в плюс, как минимум вашему менеджеру проектов.
Не надо так.

Возможность комментирования статьи доступна только в первые две недели после публикации.

Сейчас обсуждают
Олег Дергилёв

В России есть ТВ?

«Российскому ТВ не хватает ощущения того, что ты общаешься с живым человеком»
0
Vladislav Kharchev

Это где, например?

МГТС разослал своим клиентам бесплатные тестовые SIM-карты вместе со счетами
0
Олег Дергилёв

C ботами работал на основной работе, как-то было очевидно, что хайп про них пустой и за этим не последует рывка.

Интересно, а рубрика с факапами на ЦП будет иметь большой успех?! Ведь примеров этого у каждого найдется немало...

5 советов о том, как провалить проект
0
XageRu
Xage

Vladislav Kharchev, у вас жена и дети есть?

«Содержать семью в Долине сложно даже на зарплату сотрудника Facebook»
0
Mikhail Kuropatkin

Пользователь должен самостоятельно решать кому доверить свои данные, ведь это ЕГО данные.
Хочешь сбор данных родной стране? нет проблем, используй только отечественное.
Попытка навязать или самоизолироваться сделает только хуже, пользователи российских сервисов за границей будут от них постепенно отказываться, свои будут относится с опаской и по возможности избегать.
В США контактик спокойно работает, и никто не пытается его ограничить, ЦРУ плохо работает?

Касперская рассказала о работе ФСБ и Роскомнадзора над перехватом и дешифровкой трафика россиян
0
Показать еще