Программист-прагматик. Путь от подмастерья к мастеру | страница 23
Нам, разработчикам, приходится общаться на многих уровнях. Мы проводим время на собраниях, слушаниях и переговорах. Мы работаем с конечными пользователями, пытаясь понять их нужды. Мы пишем программы, которые передают наши намерения машине и документируют наши размышления для будущих поколений разработчиков. Мы пишем предложения и служебные записки, в которых требуем и обосновываем предоставляемые нам ресурсы, сообщая наш статус и предлагая новые подходы. Мы работаем ежедневно в своих командах, отстаивая наши идеи, изменяя существующую практику и вводя новую. Большая часть дня проходит в общении, поэтому нам необходимо овладеть его искусством.
Мы обобщили ряд идей, которые находим полезными.
Возможно, самой трудной частью более формальных стилей общения, используемых в бизнесе, является выработка именно того, что вы хотите сказать. Беллетристы в деталях намечают сюжет книги перед тем, как начать свой труд, но люди, составляющие технические документы, часто рады сесть за клавиатуру, напечатать «1. Введение» и затем набирать все, что прилет им в голову.
Планируйте то, что вы хотите сказать. Напишите «рыбу». Затем спросите себя: «Не противоречит ли это тому, что я пытаюсь высказать?» Совершенствуйте содержание, пока не наступит момент выступления.
Этот подход применим не только к написанию документов. Когда вы готовитесь к важной встрече или телефонному разговору с важным заказчиком, законспектируйте идеи, которыми собираетесь обменяться, и разработайте несколько стратегий для четкого их изложения.
Вы общаетесь только в том случае, если передаете информацию. Для этого вам необходимо осознавать потребности, интересы и способности вашей аудитории. Всем нам приходилось присутствовать на собраниях, где нахал-разработчик затуманивает глаза вице-президенту по маркетингу долгим монологом о заслугах некоторой скрытой технологии. Это не общение: это просто разговоры и это утомляет [5].
Составьте устойчивый психологический образ вашей аудитории. Акростих WISDOM, показанный на рисунке 1.1, может помочь в этом.
Например, вы собираетесь предложить интернет-систему, позволяющую конечным пользователям представлять отчеты об ошибках. Об этой системе можно рассказать по-разному, в зависимости от аудитории. Конечные пользователи обрадуются тому, что смогут представлять отчеты об ошибках 24 часа в сутки, не занимая телефона. Отдел маркетинга сможет использовать этот факт в целях увеличения объема продаж. Менеджеры в отделе поддержки будут счастливы по двум причинам: можно будет обойтись меньшим числом сотрудников и генерация отчетов о возникающих проблемах будут автоматизирована. И, наконец, разработчики смогут приобрести опыт в работе с клиент-серверными интернет-технологиями и новым ядром баз данных. Выступая перед каждой из этих групп с отдельной трибуны, вы добьетесь того, что они станут неравнодушными к вашему проекту.