Оригинал: Why IT communications fail to communicate
Автор: Боб Льюис (Bob Lewis)
Не путайте документацию с коммуникациями! Назначение документации — не передавать информацию, а служить напоминанием.
Бизнес-аналитик моего клиента спросил, как я оцениваю качество разработанной спецификации.
Я давным-давно я убедился на собственном опыте: когда кто-то просит вашего совета, скорее всего он ищет союзника. Поэтому в ответ я поинтересовался, откуда у него возник этот вопрос.
«Я отдал документ разработчику, а он сказал, что это плохая спецификация. Поэтому я хочу узнать ваше мнение.»
Понятно: нужен союзник. Те мне менее, я взглянул на эту спецификацию. Сам по себе документ был неплох. Но, как и многие другие документы, он был плохим по простой причине: бизнес-аналитик использовал ее в качестве средства передачи спецификаций разработчику.
Это распространенная ошибка, причем не только применительно к бизнес-аналитикам и спецификациям программного обеспечения. ИТ-директор, ИТ-менеджеры, да и если уж на то пошло, прочие работники типичного предприятия тоже пытаются общаться, пересылая туда и обратно документы.
В некоторых ситуациях это неизбежно, но все же, если надо достичь взаимопонимания — практически по любому вопросу — это не лучший вариант.
Корень проблемы в том, что коммуникации посредством документации не учитывают фундаментальную природу человеческого общения.
Четыре фундаментальных недостатка документации
Если вы предпочитаете общаться с помощью документации и стимулируете всех в вашей организации следовать этому примеру, вы столкнетесь с четырьмя аспектами коммуникаций.
Язык: любой естественный язык, будь то английский, латынь или даже эсперанто, как минимум неточен. Синонимы приблизительны и не точны; слова определяются через другие слова, что ведет нас по пути бесконечной рекурсии; интерпретируя прочитанное, разные люди используют разный словарный запас и разные допущения.
За исключением ситуации, когда в качестве языка для написания спецификации используется псевдокод. Он достаточно точен и однозначен. Но тогда мы придем к тому, что бизнес-аналитики будут писать код вместо спецификаций, и в чем смысл?
Однозначность: как бы ни старался даже лучший автор, ему не удастся создать документ, полностью свободный от двусмысленностей и запутанной логики. Те, кто пытается этого добиться, обнаруживают, что они идут по тому же пути, что и представители другой профессии, для которой двусмысленность и вероятность неправильной трактовки столь же проблематичны: у них получается текст в юридическом стиле, похожий на контракт, в котором их жертвы пытаются разобраться столь же тщетно, что и в тексте стандартного лицензионного соглашения конечного пользователя.
Разногласия: вне зависимости от того, насколько хорошо бизнес-аналитик (возвращаясь к примеру с разработкой приложений) описал дизайн, заинтересованные стороны, с которыми он работал над документом, могут не по всем пунктам быть с ним согласны. Разногласия между заинтересованными сторонами неизбежно приводят к компромиссам при проектировании или к противоречивым спецификациям, что еще хуже.
С аналогичными проблемами сталкивается ИТ-директор в ходе разработки проекта бюджета.
Посредничество: устранение посредников — это то, чего большинство ИТ-организаций не делает. Вместо этого они занимаются посредничеством. К сожалению, типичный бизнес-аналитик выступает в роли посредника — из-за ошибочного мнения, что технический специалист не способен вести конструктивный диалог с бизнес-пользователями своих продуктов.
Это совершенно нелепая доктрина была общепринятой на протяжении десятилетий, но с ней давным-давно пора покончить. Если технические специалисты не способны эффективно общаться с нетехническими людьми, то как получается, что они женятся на нетехнарях, как растят детей, первые слова которых — «мама!» (или, возможно, «нет!»), а не «<p>текст параграфа</p>», жарят шашлыки с соседями, которые (надо же!) работают в маркетинге или в бухгалтерии или, если уж на то пошло, обучают собак голосовым командам?
ИТ-директора нередка попадают в эту же ловушку. Они рассматривают организационную структуру как набор программных модулей с четко определенными интерфейсами внешнего взаимодействия — как будто речь идет о вызове подпрограмм — и полагают, что остальные руководители смотрят на предприятие так же.
Но точно так же, как не существует идеальной организационной структуры, нет и идеального способа прописать работу отдела через выходы и входы, которые другие отделы должны подать, чтобы получить желаемый выход.
Решение — в диалоге
Конечно, проблемы не ограничиваются спецификациями в ИТ. Это просто пример того, как, полагаясь на документацию как на средство коммуникации, мы сами себе создаем проблемы.
Встречайте решение. Оно несложное: когда людям нужно понять друг друга, им надо разговаривать — вести диалог, уметь (я надеюсь) слушать. В частности:
- Выражать заинтересованность: человек или люди, которых вы слушаете, должны быть уверены, что вам действительно небезразличны мысли, которые они излагают.
- Давать возможность другому говорить: даже если он говорит не на ту тему, на которую вы бы хотели, уделите внимание тому, о чем он хочет рассказать. Ему нужно выговориться, прежде чем он сможет сконцентрироваться на том, что интересует вас.
- Придерживаться темы: дать им говорить — это одно, дать им говорить без конца — совсем другое. Поэтому в какой-то момент надо предложить сконцентрироваться на интересующей вас теме.
- Попросить (1) уточнить: если неясно, что ваш собеседник имеет в виду, попросите дополнительные разъяснения.
- Попросить (2) повторить: если вы не уверены, что собеседник вас понял, попросите его повторить сказанное, причем своими словами, а не вашими.
- Попросить (3) сформулировать: как должен звучать итоговый вывод, чтобы его можно было задокументировать.
- Напомнить: когда документация готова, пройдитесь по ней с ключевыми заинтересованными лицами в ходе очной встречи, чтобы убедиться, что в ней верно отражено содержание прошедших бесед.
Я немного идеализирую? Возможно. У вас может не получиться встретиться очно со всеми заинтересованными лицами, причем чем масштабнее тема, тем это сложнее.
Есть также проблемы перевода: если вы и ваш собеседник не владеете свободно одним и тем же языком, то коммуникации через документ могут оказаться более эффективными, чем диалог.
Так что приходится признать, что иногда мы вынуждены общаться через документацию. Как, например, прямо сейчас, когда вы читаете эти слова.
Обсудить