Пост Саши Орлова с вопросом «как создать доверительные отношения с заказчиком и не потерять его доверия» натолкнул меня на ряд размышлений.
Ни для кого не секрет, что взаимоотношения заказчик-подрядчик самые непростые. И не важно, что делает подрядчик: программное обеспечение или, как было в моем случае, предоставляет pr-услуги.
Мне хочется думать (и тут я могу ошибаться), что в разработке софта все немного проще. Во-первых, если команду наняли, то от нее так быстро уже не откажутся. Тот же Agile предполагает, что заказчик хотя бы знает, что когда-нибудь ему хотя бы чисто теоретически придется рассматривать себя как часть команды, то есть минимальные предпосылки к доверию есть. Понятно, что все зависит только от желания обеих сторон.
В работе pr-агентсва с заказчиком, как мне кажется, все немного сложнее. Во-первых, большие компании работают с несколькими агентствами, и могут отказаться от услуг одного достаточно быстро и безболезненно для себя; во-вторых, компании часто проводят и тендеры и могут поменять агентство, если их что-то до этого не устроило; в-третьих, представитель компании заказчика никогда (по крайней мере я с такими случаями не сталкивалась) не будет рассматривать себя как часть команды агентства, и соответственно со своей стороны не будет пытаться строить доверительные отношения (его задача чаще всего – выискать к чему придраться, чтобы снизить цену или получить бонус – это я утрирую, но где-то близко к правде). Так что здесь, чтобы выработать доверие, будет работа только с одной стороны.
С другой стороны везде проблемы похожи, так что исходя из своего опыта, я могу предложить следующие шаги к преодолению недоверия и выработке соответственно доверия:
- В команде должен быть порядок, взаимодоверие и прозрачная картина. Когда в команде бардак – заказчик это сразу же почувствует, даже если он с вами практически не общается
- Выполняйте обещания. Не давайте нереальных обещаний. Лучше объясните, почему вы можете сделать что-то только к такому сроку, чем пообещаете и не сделаете
- Про проблему стоит уведомлять, как только она возникла, а не дожидаться, что она сама собой рассосется. Если проблема возникла, нужно не только о ней сообщить, но и предложить пути решения проблемы, а не взваливать все на плечи заказчика.
- Уважайте заказчика и будьте к нему терпеливы. Если вы мило общались с заказчиком по телефону, а потом положили трубку и вслух рассказали, что он такой-сякой нехороший, не удивляйтесь, почему члены вашей команды никогда не станут испытывать к нему уважения, а уж про доверие и говорить не приходится.
- Отстаивайте интересы своей команды и коллег в глазах заказчика. Если что-то пошло не так, то стоит признать, что виновата вся команда, а не отдельные Петя Иванов и Вася Сидоров.
- Если у вас (по вашему мнению) ужасный заказчик – воспитывайте его. Как? Тут уже вам виднее, то ли своим примером, то ли примером соседних команд, то ли книгами, то ли тренингами, ищите свое. Как говорится, кто ищет, тот всегда найдет.
- Помогите заказчику сэкономить на чем-то.
- Нацельтесь на длительные отношения с заказчиком. Узнайте его долгосрочные планы и цели.
- Сделайте для него чуть-чуть больше, чем он ожидал.
- Будьте скептическими к себе, ищите пути постоянного улучшения, как своей работы, так и взаимоотношений с заказчиком.
- Не стесняйтесь иногда попросить у заказчика совет.
- Не останавливайтесь на достигнутом. Расширяйте горизонты.
- Проявляйте инициативу.
- Ну и последнее – клиент всегда прав. Если клиент не прав – то все равно «клиент всегда прав», при этом здравый смысл никто не отменял 🙂
И самое главное, о чем не стоит забывать, чтобы построить доверие понадобится очень много шагов. А чтобы его потерять достаточно, к сожалению, только одной ошибки.
Я имела дело с разными заказчиками: и с нервными истеричками, и с добрыми лентяями, и с унылыми дотошниками, и прочее, прочее, прочее, – к каждому надо искать свой подход, часто наступив на свою гордость, но искать его приходится.
Хороших и доверяющих вам заказчиков!
Недавно обнаружил, что если речь идет о локальном украинском рынке разработки софта или о краткосрочных проектах, то ситуация очень похожа на описанную в статье для pr-агентств.
Тут тебе и работа заказчика с несколькими фирмами/командами, чтобы “подстраховаться”. И тендеры по выбору “самой дешевой” команды. И отсутствие интереса и участия к делам команды: “я вам деньги плачу, а вы мне вопросы задаете”.
Так что все советы на 100+% применимы для разработки софта.
Александр, согласен с вами, что со стороны разработчиков все тоже не радужно.
Сам был в роде заказчика и приходилось кроме придумывания продукта еще и обучать команду фрилансеров, чтобы хоть как-то получить результат.
У меня давно устойчивое мнение, что на просторах xUSSR управлению проектами системно не учат. “Мы все учились понемногу чему-нибудь и как-нибудь”, поэтому для заказчика найти грамотную и адекватную команду – это благо. В итоге рынка разработки софта как такового и нет. Есть люди, которым нужно что-то сделать и есть люди, которые умеют и могут что-то делать. И встречаются они друг с другом очень редко 😉
Это классно.
Хотел бы поделиться вестями “с той стороны баррикад”. Есть менеджеры проектов и с той стороны. И регулярно с учащающейся частотой сталкиваешься с дилетантами в своей и моей предметной областях, которые к тому же активно ищут выход “наверх”, чтобы если что показать себя “белыми и пушистыми”. сроки изначально занижают, оголтелый оптимизм процветает, суммы вписывают из того же оптимизма, а потом надо расширять бюджет уже с первой фазы.
а над тобой висят с другой стороны корпоративные правила и стандарты. и расширение бюджета -процедура длиной месяца в 3 с неизвестным заранее результатом.
Так что таки-да, я как чел “по ту сторону баррикад” буду искать вменяемых людей с адекватным пониманием задачи и рисков. Но часто стандарты и правила ставят в позу “зю”. и начинаешь менять подрядчиков как перчатки.
С ув. Семенов Александр.