Ошибки при работе с клиентами. Наш опыт реализации веб проектов

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

Ошибка №1. Верить клиенту на слово

Это не значит, что нельзя никому верить на слово. Но ничто все-таки не внушает сильно доверие к клиенту, как 100% предоплата.

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

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

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

Обсудили что-то в колле, зафиксируйте хотя бы в групповом чате кратко достигнутые договоренности. В этом случае гораздо сложнее манипулировать "я же вам 100 раз говорил, что ...". Все договоренности должны быть текстом, чтобы их можно было проверить.

Ошибка №2. Работа со слабым сложным клиентом

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

Вы, как студия, имеете некие ресурсы. Вы можете их потратить на хороший проект, который даст вам рост профессионально.

А можете увязнуть в проекте, где изначально очень большие проблемы в основании:

• владелец продукта (ВП) не понимает базовых моментов по становлению продукта
• ВП не хочет вникать в детали
• ВП имеет нереалистичные ожидания
• ВП не имеет четкого видения продукта, а только ориентируется на конкурентов (мы сделаем лучше чем у них)

Дополнительные факторы-маркеры проблемного проекта:

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

Не всегда возможно распознать такие проекты. А выходить из них тоже не просто. И получается вы теряете время и ресурсы - по сути, несете альтернативные экономические издержки.

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

Есть негативные факторы - дважды подумайте о последствиях. Возможно имеет смысл потратить ресурсы на свой продукт и более активно его продавать. 

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

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

Ошибка №3. Слишком много людей на проекте

Если добавить в 2 раза больше людей на проекте - работа будет идти медленнее, а не быстрее.

Во-первых, где их взять этих дополнительно 4-5 человек, они же не лежат в табакерке и не ждут своего часа. В студии не бывает незанятых рук. Человек либо работает, либо его нет в студии. Поэтому резко взять и увеличить количество людей проблематично.

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

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

Чем меньше людей на проекте, тем все проще и быстрее. В идеале - 2-3 разработчика.

Ошибка №4. Переживать за проект больше, чем сам владелец продукта

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

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

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

То, что я видел в разных веб-проектах, это подтверждает. Сильный ВП просто доводит дело до конца.

Заключение

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

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