Клиент прав или клиент неправ?

25.11.2011 at 16:50 2 комментария

На конференции FailConf,  посвященной ошибкам в ИТ-бизнесе 12 ноября в Екатеринбурге, Леонид Волков среди прочего сказал: «Мы в 2004 году эмпирическим путем вывели принцип «клиент всегда неправ».
Тема эта достаточно больная и часто поднимается при обсуждении проблем ИТ отрасли.


Так,  в августе 2011г статья «Правила технического задания» в рубике «Из песочницы» активно обсуждалась (42 комментария, многие вполне пространны). Причем, техническое задание рассмативается именно в контексте «Сложность отношений «пользователь-отдел IT», … чаще всего это непонимание, возникающее из-за того, что стороны говорят на разных «языках» с различной терминологией. Пользователь понимает, что он хочет, но не может это сформулировать, IT-специалист понимает пользователя, но опасается, что результат выйдет иным, чем видит это первый. Чаще всего проблема начинается с того, что именно пользователь не готов к диалогу…»
А в обсуждении встречаются такие фразы как:
«…пользователи не понимают профессиональных тонкостей разработчика..»,
«…Пользователь понятия не имеет, что ему нужно, пока вы не сделаете хоть что-то…»
«Рядовые пользователи понятия не имеют, что они хотят. …Пользователь может описать свои пожелания только на самом примитивном уровне, и не заставляйте его писать развернутые ТЗ, он напишет все равно самым примитивным языком».
И еще: «…как правило, пользователь не может сам определить, что именно ему нужно — во многом потому, что он не знает, а что именно можно сделать. Определение того, что нужно заказчику — это долгая и непростая работа, анализ».

Читаю и думаю: бедные бедные пользователи, тупые недалекие люди. И за что только им зарплату платят на их рабочем месте….
Мне в жизни таких подходов к пользователям оооочень много пришлось повидать! При наличии в команде хороших аналитиков, специалистов вот так относящихся к пользователю (клиенту, заказчику, или где как принято называть) подпускать нельзя вообще: велик риск провала проекта.

Или вот крик души: КЛИЕНТ ВСЕГДА ПРАВ! КЛИЕНТ! ВСЕГДА! ПРАВ!

«Именно так и никак иначе следует считать, если ты зарабатываешь на том, что продаешь свои или чужие товары, или оказываешь какие-то важные услуги за деньги. Ясно, что ты делаешь это для того, чтобы получать деньги, прибыль.
Как ты будешь использовать другой вопрос. Здесь весьма важна твоя репутация. Если ты будешь отказывать клиенту в его правоте, это может сказаться на твоей репутации, и ты можешь остаться без клиентов. Удержание клиента в 12 раз дешевле, чем привлечение нового. И совершенно плохо, когда от тебя уходит клиент к кому-то другому.

Но всегда ли это работает? Действительно ли следует придерживаться клиент-ориентированности всегда? Вообще, эти два вопроса стоило бы рассматривать независимо. На первый я бы ответил, что нет. Просто клиенту деваться некуда. Это не значит, что мы можем им управлять, но мы можем указать на его неправоту, доказать это, попытаться уговорить его не делать это, но … потом сделать то, что он хочет. Т.е. придерживаться ответа «да», на второй вопрос. Почему? Да потому, что в такой ситуации и ты, и твой клиент — почти уже семья, этакий сплоченный коллектив, пронизанный обязательствами, историей отношений и т.п. Т.е. проще сделать тот абсурд, который почему-то нужен клиенту. Проще тебе — спокойней нервы, проще для клиента — он доволен в данный момент (даже если ты понимаешь, что клиент загоняет себя в ловушку). Клиент же — это тоже человек, зачем учить его жить?»

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

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

Я придерживаюсь именно такого взгляда – нельзя просто спросить клиентов о том, что им нужно. Необходимо разобраться в их реальных потребностях – они их знают, хотя действительно не всегда могут четко сформулировать на понятном ИТишникам языке.
Не каждый клиент может формулировать потребности на языке бизнеса, прогнозируя развитие этих потребностей (а ведь только так можно заниматься автоматизацией), и задача аналитика найти в команде заказчика такого специалиста.
Не кидайте в меня помидорами в связи с путаницей терминов – заказчик, клиент, пользователь – я понимаю, что строго говоря, это могут быть не только разные люди, но даже разные организации.
Но в реальной жизни и при общении с разными категориями партнеров соблюсти строгость определений вряд ли удастся, так что по мне лучше — как я уже писала – как договорились, так и назвали.
А по поводу того прав клиент или нет – как это ни банально – истина практически всегда лежит посередине. Клиент он, конечно, прав, но в чем именно он прав, и как эта его правота звучит в приложении к задачам автоматизации, ему должны помочь разобраться бизнес-аналитики. И сделать это так, чтобы клиент был уверен, что это именно он «заказывает музыку» и все делается по мановению его «дирижорской палочки».
Вот вам и ответ на вопрос – зачем нужен бизнес-аналитик.

Реклама

Entry filed under: Бизнес/аналитик, Обзоры, Пользователь и ИТ-специалист, Термины. Tags: , , , , , .

Конференция об ошибках Сангвис – продолжение истории – 1996 год

2 комментария Add your own

  • 1. businessanalyst2009  |  02.12.2011 в 09:56

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

  • 2. Евгений  |  02.12.2011 в 06:39

    Реализовать неочевидные «хотелки» одного клиента — не честно по отношению к другим клиентам, если программа имеет серийное распространение. Попытка параметризировать всё и вся сделает настройку (не только первоначальную, но и дальнейшую, при измнениях бизнеса) программы неуправляемо сложной для самих клиентов и значительно повысит стоимость поставки и сопровождения программы.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


Подписка на новости сайта

Подпишитесь на новости сайта (RSS)

RSS

Архивы

Рубрики

Главные книги аналитика

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

Требования для программного обеспечения: рекомендации по сбору и документированию |Илья Корнипаев
Анализ требований к автоматизированным информационным системам | Юрий Маглинец
Пользовательские истории. Гибкая разработка программного обеспечения |Майк Кон


%d такие блоггеры, как: