Никогда не путайте документацию с общением. Цель документации — напомнить, а не сообщить.

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