Лучшие практики для разработчиков по работе с клиентами

Question

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

Как вы, и если да, то как вы справляетесь с клиентами?

Answer 1

Большинство проектов, над которыми я работаю, выполняются на основе временных и материальных контрактов, что означает: мы даем клиенту первоначальную оценку того, сколько времени займет проект, но выставляем счет за фактически отработанные часы, независимо от того, превышают ли они смету (Я не знаю, почему клиент согласился бы с этим, но они делают). После того, как проект «завершен» и запущен в производство, мы установили расширение услуг для контракта о времени и материалах, создав блок оплачиваемых часов для покрытия послепродажной поддержки. Когда клиент осознает, что ему выставляется счет за все контакты с нами, он стремится свести этот контакт к минимуму.

Answer 2

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

Answer 3

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

Answer 4

Я бы пошел вразрез с тем, что было сказано.

Клиент - ваш источник информации номер один

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

Вы должны тренировать свои навыки общения

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

• клиенты дают им плохую информацию
• они тратят время
• они получают стресс

В конце концов, никто не счастлив.

Но с помощью обученных коммуникативных навыков вы научитесь определять, когда, как долго и о чем будут ваши чаты, и так:

• Сделай любую сделку быстро и приятно
• Дайте уверенность клиенту
• Понимает, что хочет клиент (не то, что он говорит, что хочет)
• Убедитесь, что ответ удовлетворен (даже если он для вас не имеет смысла)

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

Думаете, разговаривать с клиентом скучно? Они тоже так думают. И оформление документов тоже скучно, но вы должны это делать, поэтому делайте это хорошо, а не ищите оправданий.

Answer 5

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

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

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

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

Answer 6

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

1. Они знают меня, и у меня есть вероятность, потому что я уже доставил им.
2. У меня есть знания об их бизнесе
3. Я использую свои знания, чтобы задавать вопросы о других частях их бизнеса
4. Я сажаю им крючков , когда говорю с ними, в их лучших интересах, конечно.
5. Я четко заявляю, что мы не "наезд", но мы действительно поддерживаем их бизнес.

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

Answer 7

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

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

И как указано выше - записывайте ВСЕ в обмен с клиентом. Это не позволяет заключить сделку «он сказал, что она сказала», в которую могут попасть клиенты.

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

Answer 8

лучших практик:

Помните, что клиент подписывает чеки.

Пользователи работают на клиента.

Направляйте любые пользовательские запросы клиенту на утверждение.

Всегда общайтесь с клиентом, потому что он понимает, что все, что вы делаете, будет стоить им денег.

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

Да, и что сказал MusiGenesis!

Answer 9

Я только что закончил свое образование и работаю на своей первой работе, но вот что мы делаем:

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

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

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

Answer 10

Я лично считаю, что разработчики никогда не должны взаимодействовать с клиентами. Вот почему у вас есть команда Q / A. Они получают требования, передают их разработчикам, обсуждают любые вопросы, планируют встречи по развитию. Если у разработчиков есть вопросы, обратитесь к персоналу Q / A, ответственному за требования и документацию. Разработчики - это инженеры, а не продавцы или посредники. Им должна быть предоставлена ​​среда для разработки стабильного, работающего кода, не отвлекаясь на телефонные звонки клиентов. Это то, сколько компаний имеют дело с клиентами независимо от размера компании. В конце концов, ваши шансы завершить проект вовремя выше, чем когда ваш клиент звонит и решает изменить требования или запросить функцию. Что, вероятно, означало бы, что вам придется вернуться на пару итераций и изменить что-то, что может нарушить все выполненное после этой точки.