Проблемы взаимодействия дизайнеров (сейчас речь о дизайнерах вне зависимости от специализации) и клиентов давно известны и во многом даже решены, в той или иной степени. Я, как старый джедай, тоже имею свои методы работы и способы решения тех или иных проблем, которые возникают при работе с клиентами. Основной постулат, которого, как мне кажется, стоит придерживаться, звучит следующим образом: «Все решаемо». Нет ни одной ситуации, выход из которой не устраивал бы обе стороны настолько, что могло бы показаться, что выхода и вовсе нет. Конечно, я могу судить, только исходя из своего опыта и практики общения с различными людьми. Но давайте обо всем по порядку.
Есть, по факту, две диаметрально противоположных позиции, которых придерживаются люди моей профессии.
Позиция 1. Клиент всегда прав.
Позиция 2. Клиент всегда не прав.
Конечно, в чистом виде вы не найдете их ни у кого, но общий посыл, безусловно, ясен. Первая позиция обуславливается следующими доводами:
Клиент лучше знает, как продавать свой товар или услугу, он знает свой рынок и свою целевую аудиторию.
Клиент, как правило, в курсе конкурентных преимуществ своего товара и, конечно же, знает сильные и слабые стороны конкурентов.
У клиента в голове есть четкая картина того, что он хочет получить, и лучше слушать его как можно внимательнее, чтобы удовлетворить даже самые незначительные его желания относительно вашей работы.
Ну и, в конце концов, клиент платит вам и только от него зависит, получите ли вы деньги или нет, что в конечном итоге и является нашей основной задачей.
С одной стороны, такой подход верен, потому как в идеале клиент должен твердо знать, что и для кого он делает, и как это лучше продать, но, к сожалению, такое бывает ровно в половине случаев. В другой половине мы имеем некомпетентных исполнителей или просто людей, которым не особо интересны результаты вашей работы. Поначалу мне казалось, что некомпетентность вкупе с желанием тотального контроля присуща, скорей клиентам невысокого уровня, например, я не ожидаю серьезных исследований рынка от местечковой сети магазинов обуви, с одним филиалом в области и ассортиментом, ничем не выделяющим сеть среди таких же. Но оказалось, что все куда более запущенно, чем кажется на первый взгляд. Поднявшись по карьерной лестнице, я наблюдал ту же саму картину и риск нарваться на некомпетентного, но очень напористого сотрудника крупной компании не меньше чем в случае с владельцем павильона в недорогом торговом центре. И в том, и в другом случаях мы имеем клиента, который скорее мешает работать, чем пытается продать свой товар или услугу посредством вашего дизайна. Все это работает и в IT сфере. Порой представитель компании-разработчика или ее владелец сильно оторваны от реальных нужд пользователя и не могут или не хотят вникать в их потребности.
В случае же когда дизайнер считает, что клиент всегда не прав, мы наблюдаем абсолютно противоположную картину. Любое предложение или замечание клиента встречается в штыки ровно потому, что он все равно ничего не понимает, и вообще я тут дизайнер, а вы не лезьте в мою профессиональную область. Такой подход тоже обречен, потому, как может работать исключительно в тех областях, в которых понимает сам дизайнер. В тех же сферах где дизайнер не знает ничего, он начинает строить логические конструкции с нуля, не подкрепленные реальными знаниями, что, в конце концов, и губит проект. А уж если клиент попадется знающий, то тут случай становится прямо таки хрестоматийным, и мы имеем полное непонимание сторон.
Золотая середина, тоже не так хороша, как может показаться поначалу. Наши знания в чужих предметных областях редко бывают идентичными. Наши образование, опыт и предпочтения тоже страдают сильной дифференцированностью, а потому так же не могут быть отправной точкой для установления баланса в работе.
Мой личный рецепт, на все случаи жизни звучит следующим образом: «Пойми кто перед тобой», это, собственно, одна из сложных сторон моей профессии. Например, ко мне приходит заказ на разработку крайне специфического приложения, что-нибудь из области, в которой я совсем ничего не понимаю. И тут крайне важно понять кто же тот человек, который будет принимать мою работу. Если это профессионал, знающий свой предмет от и до, расслабляться не стоит. Если продукт ориентирован не на профессионалов, то общение с ним придется перерабатывать, и все его замечания и предложения придется переводить на понятный пользователю язык.
Неоднократно случалось, что к моменту моего найма интерфейс программы выглядел, как серое поле с двумя кнопками непонятного назначения и кучей галочек практически без подписей, но прекрасно и стабильно работающее. Проблематика ясна, пользователь просто не захочет обучаться работе с программой, и эффект будет ровно таким же, как если бы программа не работала вовсе. В случае же, когда принимающий программу не компетентен, но наделен властью, а самое главное желанием участвовать в процессе не просто как администратор, а как полноправный разработчик, тут уже начинается история другого рода. Вы будете биться за каждую иконку и каждое меню, объясняя и доказывая, что так будет лучше для продукта и в конечном итоге для продаж. Как правило, такие вещи пагубно сказываются на сроках и оплате, и потому таких клиентов я стараюсь распознать как можно раньше, что бы еще на стадии подготовки контракта все стало на свои места, и у меня осталась возможность, что-то переиграть. Попросить другого менеджера проекта или на худой конец просто отказаться от работы.
Все что было написано выше, так же справедливо и для дизайнеров/разработчиков/проектировщиков, которые работают внутри одной компании.
Что же касается другой стороны вопроса, то есть, некомпетентных/неадекватных дизайнеров, здесь все тоже ой как не просто. Программа может быть сколь угодно красивая, но если простейший функционал, запрятан за 4 меню, да еще и требует знания специальной системы обозначения, то тут явно на лицо халтура. Дизайнер/проектировщик не сделал своей работы. Не вник в область, не изучил подводные грабли, не понял, кто клиент, не сделал банальнейшего набора действий, которые бы позволили избежать ошибок еще на этапе проектировки. В конце концов не провел переговоров со специалистами и не предоставлял промежуточные этапы работы. В этом случае мы имеем полное моральное право говорить, что проект получился плохим именно по вине дизайнера.
Подводя итог вышесказанному, следует заметить, что конечный результат работы - это совокупность действий обеих заинтересованных сторон. Иными словами, программа настолько плоха, насколько некомпетентны руководитель и разработчик. Причем, как правило, уровень слабейшего из специалистов и определяет результат.
Выход прост: надо быть адекватным, нужно уметь слушать и говорить, нужно постоянно спрашивать себя: «а не фигню ли я сделал?». И когда ответ самому себе станет отрицательным (а он никогда таковым не станет в полной мере, и с этим тоже придется мириться), можно считать проект завершенным и готовым к сдаче.
Надеюсь кому-то этот пост поможет разобраться в вопросе.
Прозит!
Есть, по факту, две диаметрально противоположных позиции, которых придерживаются люди моей профессии.
Позиция 1. Клиент всегда прав.
Позиция 2. Клиент всегда не прав.
Конечно, в чистом виде вы не найдете их ни у кого, но общий посыл, безусловно, ясен. Первая позиция обуславливается следующими доводами:
Клиент лучше знает, как продавать свой товар или услугу, он знает свой рынок и свою целевую аудиторию.
Клиент, как правило, в курсе конкурентных преимуществ своего товара и, конечно же, знает сильные и слабые стороны конкурентов.
У клиента в голове есть четкая картина того, что он хочет получить, и лучше слушать его как можно внимательнее, чтобы удовлетворить даже самые незначительные его желания относительно вашей работы.
Ну и, в конце концов, клиент платит вам и только от него зависит, получите ли вы деньги или нет, что в конечном итоге и является нашей основной задачей.
С одной стороны, такой подход верен, потому как в идеале клиент должен твердо знать, что и для кого он делает, и как это лучше продать, но, к сожалению, такое бывает ровно в половине случаев. В другой половине мы имеем некомпетентных исполнителей или просто людей, которым не особо интересны результаты вашей работы. Поначалу мне казалось, что некомпетентность вкупе с желанием тотального контроля присуща, скорей клиентам невысокого уровня, например, я не ожидаю серьезных исследований рынка от местечковой сети магазинов обуви, с одним филиалом в области и ассортиментом, ничем не выделяющим сеть среди таких же. Но оказалось, что все куда более запущенно, чем кажется на первый взгляд. Поднявшись по карьерной лестнице, я наблюдал ту же саму картину и риск нарваться на некомпетентного, но очень напористого сотрудника крупной компании не меньше чем в случае с владельцем павильона в недорогом торговом центре. И в том, и в другом случаях мы имеем клиента, который скорее мешает работать, чем пытается продать свой товар или услугу посредством вашего дизайна. Все это работает и в IT сфере. Порой представитель компании-разработчика или ее владелец сильно оторваны от реальных нужд пользователя и не могут или не хотят вникать в их потребности.
В случае же когда дизайнер считает, что клиент всегда не прав, мы наблюдаем абсолютно противоположную картину. Любое предложение или замечание клиента встречается в штыки ровно потому, что он все равно ничего не понимает, и вообще я тут дизайнер, а вы не лезьте в мою профессиональную область. Такой подход тоже обречен, потому, как может работать исключительно в тех областях, в которых понимает сам дизайнер. В тех же сферах где дизайнер не знает ничего, он начинает строить логические конструкции с нуля, не подкрепленные реальными знаниями, что, в конце концов, и губит проект. А уж если клиент попадется знающий, то тут случай становится прямо таки хрестоматийным, и мы имеем полное непонимание сторон.
Золотая середина, тоже не так хороша, как может показаться поначалу. Наши знания в чужих предметных областях редко бывают идентичными. Наши образование, опыт и предпочтения тоже страдают сильной дифференцированностью, а потому так же не могут быть отправной точкой для установления баланса в работе.
Мой личный рецепт, на все случаи жизни звучит следующим образом: «Пойми кто перед тобой», это, собственно, одна из сложных сторон моей профессии. Например, ко мне приходит заказ на разработку крайне специфического приложения, что-нибудь из области, в которой я совсем ничего не понимаю. И тут крайне важно понять кто же тот человек, который будет принимать мою работу. Если это профессионал, знающий свой предмет от и до, расслабляться не стоит. Если продукт ориентирован не на профессионалов, то общение с ним придется перерабатывать, и все его замечания и предложения придется переводить на понятный пользователю язык.
Неоднократно случалось, что к моменту моего найма интерфейс программы выглядел, как серое поле с двумя кнопками непонятного назначения и кучей галочек практически без подписей, но прекрасно и стабильно работающее. Проблематика ясна, пользователь просто не захочет обучаться работе с программой, и эффект будет ровно таким же, как если бы программа не работала вовсе. В случае же, когда принимающий программу не компетентен, но наделен властью, а самое главное желанием участвовать в процессе не просто как администратор, а как полноправный разработчик, тут уже начинается история другого рода. Вы будете биться за каждую иконку и каждое меню, объясняя и доказывая, что так будет лучше для продукта и в конечном итоге для продаж. Как правило, такие вещи пагубно сказываются на сроках и оплате, и потому таких клиентов я стараюсь распознать как можно раньше, что бы еще на стадии подготовки контракта все стало на свои места, и у меня осталась возможность, что-то переиграть. Попросить другого менеджера проекта или на худой конец просто отказаться от работы.
Все что было написано выше, так же справедливо и для дизайнеров/разработчиков/проектировщиков, которые работают внутри одной компании.
Что же касается другой стороны вопроса, то есть, некомпетентных/неадекватных дизайнеров, здесь все тоже ой как не просто. Программа может быть сколь угодно красивая, но если простейший функционал, запрятан за 4 меню, да еще и требует знания специальной системы обозначения, то тут явно на лицо халтура. Дизайнер/проектировщик не сделал своей работы. Не вник в область, не изучил подводные грабли, не понял, кто клиент, не сделал банальнейшего набора действий, которые бы позволили избежать ошибок еще на этапе проектировки. В конце концов не провел переговоров со специалистами и не предоставлял промежуточные этапы работы. В этом случае мы имеем полное моральное право говорить, что проект получился плохим именно по вине дизайнера.
Подводя итог вышесказанному, следует заметить, что конечный результат работы - это совокупность действий обеих заинтересованных сторон. Иными словами, программа настолько плоха, насколько некомпетентны руководитель и разработчик. Причем, как правило, уровень слабейшего из специалистов и определяет результат.
Выход прост: надо быть адекватным, нужно уметь слушать и говорить, нужно постоянно спрашивать себя: «а не фигню ли я сделал?». И когда ответ самому себе станет отрицательным (а он никогда таковым не станет в полной мере, и с этим тоже придется мириться), можно считать проект завершенным и готовым к сдаче.
Надеюсь кому-то этот пост поможет разобраться в вопросе.
Прозит!
Комментариев нет:
Отправить комментарий