Казалось бы, что может быть сложного в работе рядового менеджера по работе с клиентами среднестатистической веб-студии? Записывай себе пожелания, аки следователь показания, передавай в отдел разработки и следи за продвижением работ. Да, в первом приближении все выглядит именно так. Однако есть нюанс. И этот нюанс содержится в специфике восприятия людей.
И если очень не хочется получить проблемы с одной стороны, именуемой в дальнейшем Заказчик, и решать проблемы с другой стороны, именуемой в дальнейшем Исполнитель, — рекомендуется обратить особое внимание на моменты, о которых пойдет речь ниже.
Об основной проблеме восприятия
Людям свойственно идеализировать собственные творения. Об этом знают все, однако внимание обращают на это немногие. В случае веб-строительства таких идеалистов как минимум двое: в первую очередь Заказчик, а во вторую — Исполнитель. Заказчик идеализирует то, что он навоображал в голове, Исполнитель — то, что он реализовал в виде дизайна и кода. И в тот момент, когда первый видит результаты второго, происходит столкновение с суровой реальностью для обоих. "Этот красный цвет немного не тот, который я хотел, а вот здесь шрифт не такой, какой я люблю, меню с другой стороны выглядело б лучше, заголовок вот этой статьи здесь не поместится, картинка слишком большая, логотип слишком маленький, да и форум, я смотрю, грузится чего-то долго" — что-то наподобие этого слышит Исполнитель от Заказчика, когда первый раз показывает результаты проделанной работы. В чем причина такой «неприязни» со стороны Заказчика? Вроде бы и цвет красный, как он хотел, и меню там, где он хотел, и длину заголовка рассчитывали, и логотип он предоставил, да ведь и форум такой навороченный... А причина возникновения недовольства Заказчика одна — он не все сказал Исполнителю, да и Исполнитель не все и не так понял из того, что все-таки смог ему рассказать Заказчик. Что делать дальше? Вариантов два: или оставить все, как есть, уговаривая, что это самое то, или переделывать. Замечу, первое решение не понравится Заказчику, второе решение не понравится Исполнителю. Существует третье решение, самое правильное: снизить до минимума вероятность возникновения такой ситуации. Это и есть задача менеджера по работе с клиентами.
Минимизация рисков
Как мы выяснили, основные проблемы возникают из-за недопонимания. Кстати, это относится вообще к любой области жизнедеятельности, где присутствует человеческий фактор. Так вот, во избежание такого развития событий следует вместе с Заказчиком выяснить, чего он хочет на самом деле и чем это чревато. Для этого рекомендуется действовать следующим образом.
Прежде всего выясните у Заказчика цель создания сайта
Прежде всего, и это чрезвычайно важно, необходимо выяснить цель создания сайта. Заказчик просто хочет свою страничку в Интернете, без новостей, без каталога продукции, без интернет-магазина и тому подобного? Это сайт-визитка, значит, минимум информации при максимальной информативности, упор на дизайн. Заказчик хочет, чтобы предлагаемую его компанией продукцию находили при помощи Интернета и покупали именно у него? Тогда это веб-сайт с каталогом продукции. Заказчик хочет именно продавать посредством веб-сайта? Значит, ему нужен интернет-магазин. И так далее и тому подобное. Здесь главное не распыляться, а конкретно выяснить, зачем ему сайт, какие задачи предполагается решить при помощи сайта. Все подробности, детали работы и варианты реализации следует обсуждать именно после выяснения цели создания сайта, ибо в нашем случае цель не только оправдывает средства, а и указывает на них.
Обсудите необходимые программные механизмы
После выяснения цели создания сайта необходимо обсудить необходимые программные механизмы (модули) для функционирования сайта. То есть будут ли на сайте новости, статьи, может быть, форум или гостевая книга. Здесь очень важно, чтобы менеджер подробно объяснил, какой модуль за что отвечает и что с его помощью можно сделать. Например, необходима ли Заказчику возможность добавления нескольких картинок в новостном модуле? Или в модуле интернет-магазина возможность указания нескольких цен? А может, клиенту достаточно в форуме всего лишь авторизации без возможностей добавления тем? И так далее по всем программным модулям, которые необходимо будет реализовать на сайте. Кроме того, важно объяснить, что, например, поддержка интернет-магазина с большим каталогом товаров требует больших затрат как в отношении времени на обновление каталога продукции (добавление новых товарных позиций, новых разделов, описание продукции, изменение цены на каждую товарную позицию), так и в отношении того, что, возможно, потребуется отдельный человек, обеспечивающий выполнение заказов. Или, например, что немодерируемый форум (гостевая книга) постепенно превращается в лучшем случае в бесплатную доску объявлений, а в худшем — в свалку бессмысленных сообщений и выяснение личных отношений между участниками форума. Все эти и другие возможные тонкости необходимо объяснить во избежание дальнейшего недовольства Заказчика и незапланированных трудо- и прочих затрат с обеих сторон.
Этот этап работ наиболее трудоемкий, и обсуждение функциональности сайта может быть завершено через несколько часов, а может и через месяц. Главное, чтобы Исполнитель объяснил Заказчику, что именно будет реализовано и в какой форме, а Заказчик понял, что именно такую функциональность он хочет получить на своем сайте. А чтобы убедиться, что действительно всем все понятно, необходимо записать функциональность сайта в договоре (удобнее в форме приложения к договору) и скрепить подписью и печатью. Этот способ наиболее точно отобразит степень взаимопонимания и позволит избежать взаимных обвинений из серии «мы так не договаривались». Подчеркиваю, именно взаимных обвинений. Для Заказчика такой договор — гарантия получения функциональности именно такой, как написано в договоре, а для Исполнителя это фактически техническое задание на разработку сайта.
В обязательном порядке необходимо выяснить пожелания к дизайну
Следующим этапом является обсуждение дизайна. На что здесь обратить особое внимание Заказчика? Практически на все. Начиная с цветовой гаммы и заканчивая расположением меню и размером букв. Естественно, менеджер по работе с клиентами — это не дизайнер, и у него вряд ли получится сделать набросок по результатам беседы с Заказчиком. Однако такие вещи, как цветовая гамма, размеры букв, «резиновость» сайта, расположение и расширяемость меню, наличие анонсов статей или новостей, количество товарных позиций на главной и остальных страницах сайта и прочие ключевые вещи, можно сказать, скелет сайта — это менеджер обязан выяснить и передать дизайнеру наиболее точно. Нет, не спорю, можно сказать клиенту: «Доверьтесь профессионалам» — и пустить все на самотек. Однако такой самотек может с высокой вероятностью превратиться в «самовытек». Причем течь будут деньги из кармана Исполнителя за повторный редизайн, а в особо запущенных случаях — к разрыву договора, возврату аванса и оплате неустойки.
Заказчик хочет присутствие логотипа на сайте? Надо узнать, где он хочет его видеть, и объяснить, где это лучше будет смотреться. Надо узнать, сможет ли он предоставить логотип в цифровом виде, желательно в векторном формате. Не знает, что такое векторный формат? Объяснить. Не может предоставить? Рассказать (а лучше показать), как выглядит логотип, отсканированный с визитки и увеличенный до нужных размеров. Также необходимо объяснить, что некоторая функциональность влияет на дизайн, а дизайн на функциональность. Заказчик хочет сайт, выполненный целиком на Flash? Объяснить, что увеличиваются время загрузки сайта и оплата трафика* на хостинге. Объяснить, что качество индексации пострадает. Выяснить, необходима ли возможность увеличения количества пунктов меню или подменю, где будут располагаться новые пункты меню, что делать, если строка меню или заголовка не помещается целиком, и так далее. В целом работа менеджера в этом случае очень похожа на работу на втором этапе. Аналогично крайне желательно пожелания записывать в договоре.
Выясните, в каком виде будет предоставлена информация для наполнения сайта
Наступает очередь обсуждения такого момента в разработке, как условия предоставления первичной информации для наполнения сайта. Что такое первичная информация? Это та информация, которая будет на веб-сайте в момент окончания работ и демонстрации результата Заказчику. Необходимо выяснить и договориться с Заказчиком о том, кто будет первично наполнять информацией веб-сайт и в каком виде эта информация будет предоставлена. Возможен, конечно, вариант, когда Исполнитель сам будет наполнять первичной информацией сайт... например, фразами «TestTestTest» или "Информация не предоставлена...". Вместо картинок будет что-то наподобие этого:
Да, это тоже вариант. Но ведь гораздо лучше будет, если там будут нормальные картинки и нормальный текст. Для Заказчика лучше, потому что он получит работоспособный, нормально выглядящий сайт, а для Исполнителя лучше, потому что сдать такой сайт проще. Замечу, однако, что совсем непросто информацию для наполнения получить от Заказчика. И это опять-таки задача менеджера — обеспечить получение такой информации в полном объеме и в срок. Для этого... ну вы догадались. Да, вписываем сроки, объемы и формат предоставления информации в договор.
И не забудьте про хостинг
И напоследок, не стоит забывать о такой немаловажной вещи, как хостинг*. О технических требованиях к хостингу также необходимо информировать Заказчика. Чтобы не возникло неприятной ситуации, когда разработанный Исполнителем веб-сайт будет отказываться работать на том хостинге, который выбрал Заказчик по тем или иным причинам. Таким образом, все тонкости, такие как версии PHP, Perl, операционная система, наличие или отсутствие базы данных, наличие необходимых библиотек или утилит, SSI*, SSH* и тому подобное, — обо всем необходимо предупреждать Заказчика, и абсолютно не лишним будет вписать эти требования в договор.
Вывод
Все, о чем было сказано выше, — не панацея от всех бед, а всего лишь способ не допустить их возникновения. Да, в реальности всех нюансов и тонкостей не учтешь, однако грамотный менеджер по работе с клиентами к этому должен стремиться.
Ссылки по теме
Статья получена: hostinfo.ru