Сложные заказчики и клиенты — это всегда “геморрой”, много нервов и проблем на всех стадиях проекта. Коммуникационный аспект в нашей работе всегда занимает существенное место. Отчасти, это из-за специфики, мы чаще создаем приложения для спорта и нередко сталкиваемся с непростой коммуникацией, как на этапе обсуждения проектов, так и в процессе реализации. Когда приходишь на этот рынок — начинаешь бороться за заказы, т.к. они часто “жирные” в финансовом плане, клиентами разбрасываться не приходится, особенно в начале пути. Это пост — попытка классифицировать тяжелых заказчиков и обобщить наш опыт работы с ними. Рассказать, что стоит делать в ситуациях, когда отказываться от сотрудничества не хочется, но коммуникация оставляет желать лучшего, и как не попасть в сложную ситуацию с конкретными типами сложных клиентов.

Тип 1: Референсный оптимист

"Хочу как у Ювентуса, но в нашем фирменном стиле!"

Проблема: Отсутствие нишевой экспертизы

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

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

У нас был клиент, который хотел сделать сервис, опираясь на Ями Ями, и заявил, что “хочет также”. Пришлось объяснять, что у “Ями Ями” есть ещё мобильное приложение и собственная интегрированная CRM. Мы озвучили ориентировочную стоимость и он согласился с тем, что будет достаточно адаптивного веб-сайта, т.е. лучше остановиться на PWA (progressive web application).

Решение: В подобных ситуациях необходимо продемонстрировать клиенту, что успешность продукта зависит в, первую очередь, от его соответствия текущим задачам, ожиданиям аудитории и способности решать профит-генерирующие задачи. Эти задачи будут разными у малого и среднего бизнеса. Это часто тяжело и лучше всего показывать цифры. Например, объяснить, что при затратах в 15 млн. рублей экономический эффект будет таким же, как эффект от 2 млн. рублей. Когда речь об одной точке, важно заботиться о выживании, когда две — как оптимизировать косты, а когда сто — как развиваться и сделать тысячу, и это принципиально разные задачи. К слову, приведённый пример с “Ювентус” — это классика. Разобрались почему

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

Тип 2: Всё и сразу

"Хочу быстро, качественно и дёшево!"

Проблема: Непонимание взаимозависимости качества, сроков и стоимости.

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

Удивительно, но таких людей не становится меньше. ИТ — не исключение. Хотя иногда за абстракциями “быстро” и “дёшево” скрываются совершенно разные цифры. Для кого-то дешево — это 1 миллион, а для кого-то — 10 млн. И здесь важно понять, что клиент имеет в виду. Мы сразу стараемся рассказать, что их ожидает впереди. Как минимум ориентировочно прогнозировать сроки и бюджет, объяснить риски. 

Решение: Подчеркиваем, что в треугольнике “Быстро, качественно, дёшево” можно выбрать только две вершины, а третья будет напрямую зависеть от первых двух. Если заказчик оперирует абстракциями — выясняем его ожидания, особенно про  “дёшево” и “быстро”. Мы всегда настаиваем на качестве, так как стремимся сохранять свои корпоративные стандарты. Если клиент предлагает экономить на тестировании или ещё на чем-то, чтобы влезть в бюджет, мы изредка предлагаем делегировать какую-то часть работ сторонней команде, но лишь в том случае, если это поможет реализовать обоснованные и разумные требования. 

Тип 3: Вечный сомневающийся

"Расскажите мне, что мне нужно... Да вы что, издеваетесь? Тут всё должно быть иначе. Как? Не знаю. Если бы знал к вам бы не обращался.."

“Пример: "Это хорошее решение, но... нет. У меня нет конкретных замечаний, просто предложите что-то другое."

Проблема: Постоянные изменения требований.

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

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

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

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

Тут важный момент, нельзя проводить проектирование и писать ТЗ бесплатно. Это уже работа, причем нескольких специалистов. PM и тимлид должны оценить количество часов, потратить время на онбординг и т.д. Смету бесплатно делают многие студии, нам тоже важно понимать объём не меньше клиента. А вот описывать архитектуру, проектировать приложение и писать ТЗ бесплатно можно только при 100%-й уверенности в том, что клиент будет работать с вами. 

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

Тип 4: Самый умный

"Я знаю, как должно быть!"

Цитата: "Я знаю, как и что нужно сделать. Сам бы написал, но времени нет"

Проблема: переоценка экспертизы

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

Решение: Обычно с такими клиентами рекомендуют не бояться отстаивать свою позицию и не опасаться гнева клиента. В нашем случае всё проще. Мы просто предлагаем аутстаффинг, клиенту предоставляется один или несколько специалистов и он сам руководит процессом и делает продукт с нашей командой, но без нашей экспертизы. По опыту, некоторые потом возвращаются к альтернативам, которые мы предложили и покупают нашу экспертизу, так как далеко не всегда позиция “я самый умный” позволяет решить проблемы заказчика.

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

Случай из практики: При оценке стоимости flutter-приложения удивили клиента стоимостью 8 млн. рублей. Было видно, что клиент “самый умный”. Он начал говорить, что конкурентам сделали нейронку за 8 млн. После чего начал возмущаться и утверждать, что flutter — куча проблем и декларировать это как факт. Например, сослался на то, что такие приложения нельзя заливать в магазины порознь.

Как поступили: Мы начали объяснять, что flutter — это всего лишь фреймворк,  надстройка, использующая Dart и что работа с приложениями с магазином — это совсем разные вещи. По ходу диалога, выяснилось, что клиент не компетентен в разработке от слова совсем, но строит из себя “самого умного”. Отказываться не стали, предложили аутстаффинг: “ты умный, ты всё знаешь и думаешь, что предложенное тобой решение лучше, вот разработчики, они стоят столько-то, ставишь им задачу и делаешь сам”.

Тип 5: Критик после факта, шантажист

"Всё было хорошо, пока вы не закончили работу… Переделывайте бесплатно или я испорчу вам репутацию!"

Проблема: Недовольство и претензии возникают уже тогда, когда проект завершен.

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

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

Бывают клиенты, которые говорят: “ завершите проект и мы оплатим”, а а для того, чтобы завершить проект PM со стороны клиента должен его принять. При этом  договор предполагает жесткие дедлайны, но не содержит четких критериев приемки. Внезапно выдвигаются новые требования, что-то приходится переписывать из-за чего сдвигаются сроки и соответственно наша оплата. Мы стараемся подходить с пониманием к подобным требованиям, но иногда у нас по сути не остаётся выбора, как завершать проект с новыми требованиями. 

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

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

Тип 6: Дотошный перфекционист

"Это поле должно быть смещено на 1 пиксель влево!"

Проблема: Придирки к мельчайшим деталям.

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

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

Решение: Мы стараемся заранее обозначить рамки приемлемых правок, а также приоритезировать изменения. Если сталкиваемся с острым желанием сдвинуть что-то на пару пикселей — никогда не отказываем. Не исключено, что когда-нибудь мы откажемся от заказа с космической степенью абсурдных требований (знаю, что такие бывают), но пока тактика заключается в удовлетворении перфекционистских претензий, даже, если речь идёт о пустяковой формальности. Иногда мы можем не до конца понимать абсурдны требования или нет. Это важное допущение, какие-то моменты подтверждаются фактами, какие-то остаются лишь гипотезами.

Заключение

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