Как понять пользователя? Часть 2. Отказ пользователя

Отказ пользователя

Автор: Андрей Владимирович Морозов

(Или почему пользователь говорит не о том или не так)

Грамотный разработчик старается наладить взаимодействие c будущим пользователем. Обе стороны заинтересованы друг в друге: пользователь получит полезное устройство или программу, облегчающую ему жизнь, разработчик создаст продукт, что позволит ему реализоваться как профессионалу и заработать. Обе стороны готовы к сотрудничеству, но в ходе общения возникают осложнения, которые приводят к конфликтам и отказу от обмена информацией. Рассмотрим некоторые из таких осложнений.

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

- коммуникация (обмен сообщениями),

- взаимодействие (демонстрация и восприятие отношения к партнеру и словам),

- интеграция (изменение позиций, мнений).

Каждый процесс имеет свои особенности, но при этом связан с другим и влияет на его качество. В коммуникации ошибки возникают из-за внешнего шума, когда сообщение не услышать, или из-за ошибок в кодировании – декодировании. Но разрушить обмен информации можно и тем, что мы станем демонстрировать пренебрежение к словам собеседника: он просто замолчит. Или тем, что все его слова трактуются не так, как он рассчитывал. Другим словами: любой из трех процессов может свести эффективность общения к нулю.

Трудности перевода (коммуникация)

Все специалисты используют в своей речи профессиональный жаргон: специальные термины, аббревиатуры и особый порядок построения фраз. Терминология позволяет сокращать высказывания без потери смысла. Для того чтобы объяснить что-то «постороннему» человеку приходится говорить более простыми, но и более длинными фразами. Беда в том, что у профессионала возникает ощущение, что он не совсем точно выражает свою мысль. Он пытается прокомментировать уже сказанное, пояснить и уточнить наиболее важные моменты. Постепенно тема разговора смещается от обсуждения особенностей работы, к разъяснению основ профессии. Пользователя раздражает необходимость комментировать элементарные понятия своей предметной области. Разработчика раздражает то, что его начинают учить не относящимися к его делу вещам. Он чувствует себя идиотом, а этого никто не любит.

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

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

Самый тяжелый для взаимопонимания случай – когда используются слова естественного языка, но с особым профессиональным значением. Возьмем, к примеру, заголовок этого раздела: «Отказ пользователя». У специалиста в области техники он наверняка вызвал улыбку. В технике под отказом понимают ситуацию, когда устройство не выполняет заданную функцию из-за поломки. Получается, что «пользователь сломался». Для юриста, отказ – объявление о не выполнении оговоренных или предписанных действий на законных основаниях. Здесь пользователь должен объявить о том, что он не будет сотрудничать. В психологии отказ – явное или скрытое нежелание участвовать во взаимодействии. Здесь пользователь может прямо отказаться от сотрудничества, а может и маскировать свое нежелание различными уловками.

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

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

Кто на кого работает (взаимодействие)

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

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

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

Самомнение профессионала – обосновано. Он умеет то, что другие не умеют, знает то, что другие не знают, может сделать то, что другие не могут или сделает быстрее, надежнее, эффективнее. Именно за знания и умения приглашают на работу системного администратора, программиста, специалиста техподдержки или хелпдеска. Но самомнение нередко играет злую шутку со специалистом: он начинает требовать от других, чтобы они знали и умели то же, что и он. Стоит задавать время от времени себе вопрос: что буду делать я если пользователи научаться делать то, что сейчас умею только я?.

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

Еще один момент. Зачем нужны программы, хорошие интерфейсы, технические устройства? Риторический вопрос: для того чтобы избавить от рутины, ускорить процесс исполнения, увеличить объем выполненной работы. Другими словами пользователь ждет, что будут решаться его проблемы. Решаться, а не создаваться! Когда, вместо повышения производительности, пользователь сталкивается с потерями времени, с необходимостью исправлять или перепроверять уже сделанное, он начинает злиться. Ему психологически трудно разговаривать с «виновником» всех этих сбоев. У него есть стопроцентное оправдание: я делал свою работу и без этого ПО и никто не жаловался!

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

Оставим на минуту в стороне все выше перечисленное и представим, что разработчик ведет себя корректно и грамотно. Он нашел нужного пользователя, представился, ведет себя вежливо, задает понятные вопросы, спокойно отвечает на его вопросы. Вроде все хорошо. Но, по непонятным причинам, пользователь начинает торопиться, раздражаться, уходить от ответов. Что ему мешает? Разработчик – работает. Выполняет ту работу, за которую ему платят деньги. Пользователь тратит свое рабочее время на то, чтобы бескорыстно помочь одному из сотрудников…

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

Обратная связь (интеграция)

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

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

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

Человек может молчать потому, что не знает о чем конкретно надо говорить, ждет вопросов, не может подобрать слова, отвлекся и задумался о чем-то другом. Задайте вопрос, что еще надо обсудить? Или. Какие темы мы еще не осудили?. Ответ в любом варианте будет полезен для вас. Пользователь либо подтвердит окончание диалога, либо перейдет к волнующему его вопросу или предложит продолжить разговор в другое время, так как сейчас он не может продолжать, но темы для обсуждения еще есть

Человек ни о чем не спрашивает потому, что не понимает, чего он не понимает, или боится показаться глупым, не может выбрать момента, чтобы задать вопрос. Чтобы получить обратную связь предложите ему проговорить сомнения. Если сомнений нет, то пусть коротко расскажет о сути обсуждаемого вопроса. Например: Итак, мы сейчас обсуждаем вопрос о «…», что здесь на ваш взгляд важно?

В словах другого человека проще всего понять уже понятные вещи. Внимание концентрируется на важных с точки зрения слушателя моментах. «Мы хотим завтра «перелить» этот компьютер». Говорящий намекает на то, что было бы неплохо, если бы кто-то из отдела техподдержки пришел ЗАВТРА в отдел для переливки компьютера. Слушающий «четко» слышит, что МЫ САМИ завтра справимся с переливкой компьютера. Стоит ему проговорит свое понимание и конфликта завтра не будет.

Записанные ответы могут иметь такие же ошибки, как и услышанные. Последствия только еще хуже. Возникает желание сказать: «Но у меня же записано». Если записываются свои мысли, то это по-прежнему остается интерпретацией!

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

Во время обратной связи избегайте закрытых и риторических вопросов.

Закрытые вопросы – это вопросы, на которые можно дать ответ «да» или «нет». Простой вопрос: «Вам нужно, чтобы был написан макрос для этого документа?» Ответ – «Нет!». А теперь попробуйте понять: что имел в виду отвечающий:

Ему не надо, надо другим.

Ему нужен макрос для другого документа.

Макрос совсем не нужен.

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

Итак, пользователь явно или неявно перестает сотрудничать если:

- разработчик отказывается понимать его терминологию,

- он сам не понимает вопросов на профессиональном языке разработчика

- разработчик и пользователь используют одинаковые слова, но присваивают им разные значения,

- вместо поиска ошибок начинается поиск виновного,

- разработчик демонстрирует свое превосходство,

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

- пользователь теряет слишком много времени на общение,

- его слова интерпретируются с ошибками.

Ссылки по теме

• Как понять пользователя. Часть 1.2 Почему он молчит? Импликация знаний
• Как понять пользователя. Часть 1. Почему он молчит?

Автор: Андрей Владимирович Морозов

 Понравилась заметка? Подписывайся на обновления блога!
           

      ЖЖ  E-mail  RSS