Лично я обнаружил, что, когда хорошие разработчики работают с клиентами, они часто втягиваются в процесс послепродажной поддержки, и этот процесс трудно отменить, поэтому было просто интересно услышать различные стратегии, которые разработчики используют в поддерживая здоровые, полезные отношения, которые позволяют клиентам использовать подходящего человека в нужное время.
Так вы и, если да, как вы относитесь к клиентам?
Я бы пошел против того, что было сказано.
Большая часть того, что было сказано здесь ранее, в основном связана с тем, что программисты обычно имеют плохие коммуникативные навыки. Таким образом, они попадают в типичные ловушки:
В конце концов, никто не счастлив.
Но с обученными навыками общения вы научитесь руководить, когда, как долго и о чем будут ваши чаты, и так:
Все будут счастливее: клиент будет чувствовать себя хорошо и позволит вам работать в мире, пока у вас будет информация, чтобы продолжать работать. В конечном итоге получающееся программное обеспечение будет лучше.
Подумайте, что говорить с клиентом скучно? Они тоже это думают. И оформление документов тоже скучно, но вы должны это сделать, так что делайте это хорошо, а не искать оправдания.
Только совет: запишите все, что говорит вам клиент.
Большинство проектов, над которыми я работаю, выполняются по срочным и материальным контрактам, что означает: мы даем клиенту первоначальную оценку того, как долго будет выполняться проект, но счет за фактические часы работы, будь то сверх или по оценке (Я не знаю, почему клиент согласился бы на это, но они это делают). После того, как проект "завершен" и в производстве, мы установили расширение услуги по контракту времени и материалов, создав блок оплачиваемых часов для поддержки послепродажной поддержки. Когда клиент осознает, что им выставлен счет за все контакты с нами, они, как правило, поддерживают этот контакт до минимума.
Еще один момент: я обнаружил, что лучше всего общаться с клиентами по электронной почте, где это возможно. Это гораздо более эффективный способ передачи информации (при условии, что все участники могут писать), и она оставляет постоянную запись того, что клиент сказал вам сделать.
Это боль, которую мы чувствуем. Как только вы помогаете клиенту, для клиента слишком просто связаться с разработчиком позже и запросить поддержку. И поскольку мы обычно стремимся угодить и, вероятно, чувствуем себя ответственными, когда у приложения, которое мы создали для них, есть проблема, мы слишком часто даем клиенту быструю помощь.
Я думаю, что разработчики должны быть отделены от клиентов, но для этого требуется, чтобы у компании был отдел поддержки/взаимодействия, который может решить проблему. Они, в свою очередь, должны быть свободны связаться с разработчиком, если только это не огромная компания с основным приложением, где меньше риска того, что проблема может быть прослежена до проблемы с исходным кодом.
Но позвольте мне сказать вам, я понимаю, насколько это сложно. Я много лет работаю в нашем консультационном магазине, начиная с поддержки, и теперь я в основном управляю другими консультантами и развиваюсь. Есть много клиентов (например, сотни), которые считают, что у них есть личные отношения со мной, и предполагают, что они могут позвонить мне прямо даже через годы и годы.
Мой совет, чтобы убедиться, что у вас есть хорошая сеть консультантов и сторонников, которые могут помочь клиенту для вас, и попросите их связаться с вами, если они не могут понять это.
Я только что закончил свое образование и работаю на своей первой работе, но вот что мы делаем:
Я общаюсь с третьей стороной из той же компании с "более высоким рангом". Третья сторона - это тот, кто хорошо осведомлен о требованиях к программному обеспечению, но не в разработке программного обеспечения. Когда я спрашиваю о спецификациях или отправляю их предложения, он отдаляет суть своих ответов, отправляйте их мне.
Я думаю, что этот способ работы с материалом ограничивает количество запугивания клиента, который может уйти, когда дело доходит до изменения спецификаций, расширения спецификаций и т.д.
Для меня это особенно полезно, так как мне всего 21 год, и у людей может возникнуть проблема с верой в то, что я могу все сделать.
лучшие практики:
Помните, что клиент подписывает чеки.
Пользователи работают для клиента.
Обратитесь к любым запросам пользователя к клиенту для утверждения.
Всегда обращайтесь с клиентом, потому что они понимают, что все, что вы делаете, будет стоить им денег.
Если клиент хочет послепродажной поддержки и готов заплатить за него, отдайте его ему весело.
О, и что сказал MusiGenesis!
Лучший способ - никогда никогда не отдавать свою прямую линию клиенту. Попросите их пройти техническую поддержку (если она существует) в первую очередь. Мы используем этот метод, и он работает хорошо. Разработчики программного обеспечения - последнее средство - для тех, которые поддерживают просто не могут/не знают, как исправить - например, администратор баз данных, не зная, что серверы созданы. Но он отключит тип телефонных звонков, не подключающихся к интернетам.
Вы также можете заставить все запросы поддержки проходить через электронную почту/секретаршу. В этот момент вы можете различить, какие из них являются критическими, и какие из них можно решить с помощью простого "учебника" по устранению проблемы.
И как указано выше - записывайте ВСЕ в обмен с клиентом. Это предотвращает "хорошо, что он сказал, что сказал", что клиенты могут упасть.
Затем снова - если вы получаете тонну проблем с поддержкой клиентов, вы должны смотреть на причину этого - будь то проблема обучения или законно ли ошибка программного обеспечения.
В нашей компании каждый разработчик также является продавцом. Если я выйду за дверь Клиента, тогда я буду в хорошем положении, чтобы сделать больше бизнеса.
Возможно, это не так, как это делает вся компания, но я думаю, что вы должны использовать людей, которых у вас есть, что у allready есть нога внутри компании-клиента, чтобы действительно работать с ними, а также делать больше бизнеса и привязывать клиента к вам.
Я лично считаю, что разработчики никогда не должны взаимодействовать с клиентами. Вот почему у вас есть команда Q/A. Они получают требования, передают их разработчикам, обсуждают любые вопросы, планируют развитие прогресса. Если у разработчиков есть вопросы, обратитесь к персоналу Q/A, отвечающему за требования и документацию. Разработчики - это инженеры, а не продавцы или переговорщики. Им следует предоставить среду для разработки стабильного рабочего кода, не отвлекаясь на телефонные звонки клиентов. Это то, как многие компании имеют дело с клиентами независимо от размера компании. В конце концов, ваши шансы на завершение проекта вовремя выше, чем когда клиент звонит и решает изменить требования или запросить функцию. Вероятно, это означало бы, что вам нужно вернуться к повторению нескольких итераций и изменить что-то, что может сломать все, что прошло после этого.
Много и много общения. Общение может быть таким же простым, как проверка с вашими клиентами, останавливаясь у них на стойках (если вы находитесь совместно) или поддерживаете связь с телефоном. Чем более личным является общение (индивидуально бьет телефонный звонок, телефон звонит бьет по электронной почте и т.д.), Тем сильнее будут ваши отношения.
Другая хорошая практика разрешения конфликтов, которую я использовал, содержит как можно больше информации в одном общем месте. Для этой цели я использовал базу данных ошибок/функций (JIRA), вики и даже сетевой сетевой диск, но дело в том, что ни одна из сторон не имеет эксклюзивного доступа для записи/записи. Обновления могут быть сделаны вместе с вашими клиентами, и существует ясная публичная запись истории изменений вашей системы.