Когда клиент не прав?
Тяжело осознавать, особенно, когда пропагандируешь подходы CRM, что незыблемость утверждения “клиент всегда прав” подвергается сомнению. И так, всегда ли прав клиент? В каких случаях его нужно слушать, а в каких – нет? После очередной поездки к клиенту захотелось написать свое мнение на эту тему.
Как-то читал небольшое эссе на эту тему и там промелькнула мысль о том, что если клиент подробно указывает дизайнеру как делать дизайн, то он получит не дизайн, а собственное видение дизайна. Кстати, Виктор Ронин в своем блоге об IT бизнесе также упоминал об этом. Почему мне вспомнилась эта статья? Да вот очередной раз съездили к клиенту и записали все его “хотелки”. А если серьезно, то провели очередной этап “сбора требований к программному обеспечению”. Теперь и возникает вопрос о том, прав ли клиент, и что из его пожеланий нужно делать, а что ни в коем случае нельзя.
Вернемся к дизайну. Рассматриваем первый вариант: клиент заказывает дизайн, имея лишь смутные представления о том, что он хочет (кстати, довольно частая ситуация). Дизайнер предлагает решения, свое видение. Клиент может согласиться или нет. Если – нет, то дизайнер разрабатывает еще один вариант дизайна (за деньги или по доброте душевной – это уже вопрос к договоренностям между заказчиком и дизайнером). В этом случае клиент соглашается или нет с дизайнером, но не указывает как делать дизайн.
Вариант второй. Клиент также смутно представляет что ему нужно, но получив вариант дизайна начинает указывать, что, по его мнению нужно сделать “это передвинуть”, “здесь сделать такой цвет” и т.д. Если дизайнер воплощает все эти пожелания клиента (опять же за деньги или по доброте душевной), то клиент в итоге получает собственное видение дизайна, т.е. дизайнер, в общем-то, клиенту и не был нужен.
Теперь перейдем к разработке программного обеспечения. На первом этапе, когда еще ничего нет, клиент не может указывать разработчику куда что передвинуть и как что сделать. Не может, поскольку у него нет опыта разработки и он просто не знает как это можно реализовать.
И вот наступает второй этап, когда уже что-то есть и некоторый бизнес-процесс уже отражен в программе. Вот здесь и начинаются проблемы с переделками. Клиенту может быть “не удобно” и он хочет переделать (кстати, не удобно будет всегда, поскольку это закон – ко всему новому нужно привыкнуть). Но в отличие от дизайна у программного обеспечения есть четкий критерий, по которому можно сказать готово оно или нет. А критерий это – функциональность. Если функции, которые заявлены – выполняются, значит программное обеспечение – готово.
Теперь слушаем мнение заказчика, (вопрос о том, что обсуждать с заказчиком я уже поднимал здесь). Кстати, мнение кого? Исполнителя, который должен работать с программой? Руководителя, который заказывал разработку? Или инвестора, который оплачивал банкет? Обычно, при показе версии программы, общение идет или с исполнителями или с руководителями низшего звена, под управлением которых и будут работать исполнители. Их мнение и их взгляд далеко не всегда отражает реальное положение дел. На мнение людей может влиять политика, когда сотрудники просто против новой системы и на это есть свои причины. А может быть они просто хотят смоделировать свою текущую работу, к выполнению которой привыкли.
Например, если сотрудники до автоматизации работают с Excel, то и пытаются руками разработчиков сделать себе новый Excel. Если работают с рукописным документом, в который после расчета на калькуляторе вписывают цифру, то и пытаются заказать себе электронный документ, куда можно точно так же вписать цифру. Они всегда будут пытаться это сделать – такова человеческая природа. Исполнители не видят и не знают (да и не должны знать) как реализовать их задачи на новых инструментах. И если дать им волю (и возможность) влиять на архитектурные решения, то и получится “их видение программы”, которое, скорее всего будет таким же непрофессиональным, как в примере с дизайном и повлечет за собой огромное количество проблем, причем как для разработчика, так и для пользователя.
И какой из всего этого следует вывод? Слушайте заказчика внимательно, но бросайтесь делать все, что он скажет. Клиент будет не прав в случае, если он пытается влиять на решения, лежащие вне его зоны ответственности. Например, пригласив дизайнера, указывает ему как делать дизайн. Пригласив архитектора, делает архитектуру сам. Пригласив разработчика программного обеспечения, указывает ему как писать программу.
(рейтинг:+3, голосов:2) 
Loading...
Pingback: То, что я читаю и пишу #42 | kraynov.com
Prognow
В свое время писал программу на 1С для бывших пользователей Excel, кончилось тем, что я начал писать еще один Excel, хотя это был полный бред. К концу разработки, уговорами, обьяснениями и демонстрацией других подходов все таки пришли к тому, что выбросили все эти екселеподобные куски и начали работать нормально. Но переделывать привычки людей – это действиетльно адский труд.
По поводу того, кого нужно слушать руководителей или исполнителей.
По моему все таки людей, которые будут работать с программой, потому что нормальный руководитель в конце проекта прийдет к ним и спросит “Работает, помогает?” и ответ и будет финальным решением.
Pingback: » Ах дизайнер, дизайнер, в глазах огонек…