Следствия

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

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

Распространенные заблуждения

Методикам решения проблемы нет числа: тут и экстремальное программирование, и итеративная разработка и различные способы интуитивно понятной визуализации спецификаций (IDEF0 или UML). Практически все они нацелены на повышение участия клиента в разработке: промежуточные сдачи результатов, бета-тестированием и прочие социокультурные изысками. Но лично у меня создается такое впечатление, что все эти новшества еще более усугубляют проблемы.

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

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

Я ни в коем случае не противник спецификаций, проектирования и "современных методик разработки", все это действительно позволяет снизить трудозатраты. Но тем не менее, нужно понимать, что результат предварительного проектирования имеет значение только для разработчика. После подписания проектной документации клиентом, в дальнейшем общении с ним она имеет только сомнительную ценность доказательства в судебном (или не судебном) разбирательстве по поводу соответствия оказанных услуг.

Что делать

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

Хорошо, если разработчик может говорить на языке клиента и сидя рядом с ним вдумчиво объяснять ему все тонкости текста соглашения. Просто замечательно, если клиент найдет на это время. Но все-таки, самое главное, как можно раньше допустить клиента к тому, чтобы на опыте попользоваться разрабатываемым решением, причем лучше если это произойдет _до_ подписания каких-либо договоров.

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

Заключение

Думаю, читателю уже очевидно, что я, как и многие до меня, не могу предложить универсальной "серебряной пули". Надеюсь лишь на то, что и разработчики и их клиенты обратят внимание на проблему взаимопонимания между собой и с уважением отнесутся к ней: этот терминологический барьер неизбежен и через него нет королевского пути.

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

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