Вовлеченность клиента — один из самых важных факторов успеха проекта, и она напрямую зависит от отношений, которые команда выстроит с ним.
В реальной жизни мы стараемся построить крепкие отношения, основанные на доверии. Такого же подхода стоит придерживаться в работе. Однако в бизнесе ваша цель не просто завоевать доверие. Вам нужно постоянно подкреплять его своими действиями и проделанной работой.
За годы моей карьеры проектного менеджера я успела поработать с десятками клиентов. Полученные знания помогли мне выделить пять признаков того, что есть риск потерять доверие клиента или спровоцировать у него сомнения в компетентности команды. Если не игнорировать эти “тревожные звоночки”, клиент, возможно, останется с вами. Если вы не уделите им внимания, он, вероятнее всего, уйдёт.
1. Недостаток прозрачности
Сегодня много говорят о том, как важны прозрачность бизнеса и открытость компании.
К сожалению, многие организации просто внедряют новейшие приложения и программы, которые помогают им достичь поставленной цели на уровне документации и организации. На этом изменения и заканчиваются. В то же время, легче всего сделать прозрачными именно коммуникации в команде и с клиентом.
Сейчас мы как никогда открыто можем взаимодействовать с людьми со всего мира. Хотя глобализация сближает нас, очень важно помнить, что люди, с которыми мы работаем, могут значительно отличаться от нас в культурном отношении. Именно поэтому важно поддерживать включённость человека в коммуникацию и помнить о его языковых особенностях и культуре. Например, в групповом slack-чате кто-то заводит беседу на языке, на котором не все участники могут свободно общаться. Да, большинство все-таки поймет это сообщение, но не понявший человек будет чувствовать себя обделенным.
Решением такой проблемы может быть введение единой языковой политики не только для видеозвонков с клиентом, но и для остальных каналов коммуникации. Конечно, речь идет не только о языковых различиях, важно создавать атмосферу включённости в целом. Поэтому также стоит избегать шуток, понятных только узкой группе сотрудников и упоминать закрытые обсуждения, с итогами которых клиент может быть не знаком.
2. Невыполненные обещания
Установили дедлайн для устранения багов с вашим фронтенд-инженером, но он не успевает и просит его продлить? Знакомо, да? Безответственное отношение к срокам не только ставит в неудобное положение менеджера, но и беспокоит других разработчиков. Чтобы команда действовала слаженно, каждый участник должен быть выполнять свои обязательства. Это залог успеха и качественного продукта, которым клиент останется доволен, и, по закону сарафанного радио, может помочь привлечь новых клиентов.
Я считаю, что очень важно суметь создать в компании такую среду, где все достижения и успехи могут регулярно отслеживаться и отмечаться. Это помогает членам команды лучше сосредотачиваться и следить за своими обязанностями и задачами. Например, на протяжении нескольких последних месяцев мы в Mad Devs внедряем подход OKR. И положительный эффект виден с первых итераций. Это, несомненно, помогает разработчикам лучше понимать вносимый ими вклад и более эффективно распределять свое время.
3. Слабое информирование клиента о происходящем
Этот пункт чаще возникает в компаниях, которые находятся на раннем этапе развития, или же в командах, которые не имеют четкой организационной структуры. Давайте рассмотрим это на примере. Допустим, вы подписали договор с клиентом и тщательно спланировали работы. Наступает этап непосредственной реализации. Ваша команда инженеров занимается разработкой продукта, но клиент постоянно спрашивает о достигнутом прогрессе. Не поймите меня неправильно, заинтересованные и вовлеченные клиенты — это очень хорошо! Тем не менее, регулярные вопросы. клиента о происходящем в проекте — не что иное, как сигнал плохо организованного информационного поля в проекте, где каждый участник осведомлен о важных решениях и достижениях команды.
Это можно сделать, наметив правильный план взаимодействия и предоставив клиенту инструменты для отслеживания проделанной работы, а также настроив качественный процесс отчетности. Для этого вы можете использовать такие современные приложения, как JIRA, Basecamp и др. С их помощью вы можете создать простые для понимания графики, чтобы вам и клиенту было удобно контролировать работу над проектом.
4. Дискредитация команды
Представьте себе ситуацию: дата выпуска продукта уже очень близка, но тестировщики нашли новые баги, которые задерживают сроки сдачи проекта. И теперь вам придется объяснить это клиенту. Этот разговор точно не будет простым. Но, независимо от того, что будет происходить, вы должны сохранять спокойствие и мыслить ясно. Под давлением обстоятельств очень легко начать перекладывать вину на других членов команды, представляя их в дурном свете. Однако в конце концов, вы должны помнить, что любые возникшие проблемы должны преодолеваться сообща. В команде не может быть козлов отпущения. Если у вас что-то не получается, это чаще всего признак поломанных процессов работы. Возможно, в команде нерационально расходуется время или были допущены ошибки на этапах планирования и тестирования.
Обсуждать с клиентом ваших коллег не лучшее решение. Если у вас есть какие-либо претензии к определенному человеку, их следует обсуждать непосредственно с адресатом.
5. Игнорирование запросов клиента
Зачастую у разработчиков и клиентов расходятся представление о том, как должен выглядеть финальный продукт. За время работы над проектом инженеры проникаются его идеей и хотят усовершенствовать ее всеми возможными способами. Это хорошо, и такой энтузиазм команды нужно поощрять. Тем не менее, не стоит бездумно внедрять все предложения, т.к. это может негативно сказаться на ваших отношениях с клиентом и на продукте. Любые изменения, которые вы хотите внести, должны быть согласованы с заказчиком во избежание недопонимания.
Иначе вы рискуете потратить время команды на придуманную функцию, отложив более приоритетные вопросы на второй план, и подвести клиента.
Помимо этого, я часто сталкивалась вот с такой ситуацией. Клиент имеет четкое представление о продукте и транслирует его команде. При этом разработчики будто перестают слышать и начинают навязывать ему свои идеи. В итоге обе стороны говорят на разных языках. Да, возможно, вы как человек с техническим опытом, лучше понимаете специфику и предлагаете стоящие вещи. Но не забывайте, что перед вами стоит заказчик, главный идейный вдохновитель проекта и тот, кто за всё платит. Поэтому, если ваша идея действительно важна для продукта, вы провели SWOT-анализ и все еще считаете нужным внедрить её, то стоит дождаться правильного момента, когда клиент убедится в вашей компетентности. При таком раскладе у вас больше шансов на успех.
Бывают и случаи, когда техническая команда просто упрямится и не понимает, что их приоритеты не совпадают с ценностями клиента. Тут на помощь могут прийти другие коллеги, выступая в роли арбитра и готовые объяснить нецелесообразность разработки лишнего функционала. Важно смотреть на ситуацию с разных точек зрения, принимая во внимание мнение всех заинтересованных лиц.
Заключение
Конечно, это не единственные пункты, которые могут указывать на возможные проблемы. Тем не менее, эти небольшие ошибки (которые в основном касаются недостатка общения) могут быть безболезненно устранены и положительно повлиять на отношения с клиентом. Я надеюсь, что эта статья поможет вам быть осторожнее в своих действиях, и тогда отношения с клиентами не пострадают от типичных ошибок, перечисленных выше.
Ранее статья была опубликована тут.