Клерк.Ру

Заказчик и разработчик: кризис доверия

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

Не бойтесь быть «чайником»

Думаете, для разработчика самое страшное, если клиент – новичок и ничего не понимает в создании сайтов? Ошибаетесь. Хуже, если вы стесняетесь своей некомпетентности и киваете головой, явно не во всем разобравшись. Непонимание вскроется обязательно! Но если это случится не на старте, а в середине пути, потери будут тяжелее.

«У нас был такой пример, – говорит генеральный директор интернет-агентства «Стерно.ру» Анна Федорук. – Человек говорит «Да-да, я все понял», а потом на этапе приемки сайта оказывается, что он понял не так: не разобрался в связи между прототипом и дизайном. Он не понял, что прототипы – это такие штуки, на основе которых потом делается дизайн. Он прокомментировал отдельно прототипы, потом совершенно отдельно от них начал комментировать дизайн, а когда ему сказали: «Ну как же, вот же вы комментировали прототипы!», сказал: «Я думал, это разные вещи». На то, чтобы все рассказать заказчику, иногда тратиться очень много времени, но это того стоит: вы будете уверены, что говорите с ним на одном языке».

Вывод: задавайте все вопросы, какие только приходят вам в голову, выясняйте, «как это будет выглядеть» и «что будет, если нажать сюда», добивайтесь полной ясности от разработчика. Если ответ не прояснил для вас картину – не стесняйтесь перефразировать вопрос, попросить объяснить еще раз, показать на примере. Любой разработчик хочет вашего осмысленного участия в процессе и на этапе первичного обсуждения проекта простит вам любую наивность. Вы имеете на нее право!

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

Определите свою цель

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

«Бывает, что заказчик чего-то хочет, но не уверен, что именно, – говорит Анна Федорук. – Например, он хочет интернет-магазин, но потом оказывается, что он еще не готов продавать и пока ему нужна только страничка в интернете. Но поскольку изначально он этого не понимал, он замахивался на большой сайт, а нужно было не это. Или хочет контентный проект, рассчитывая, что он привлечет внимание к его основному бизнесу, но когда проект готов, выясняется, что делать контент некому и некогда. Человек начинает метаться: «я хотел не так», «давайте это переделаем»... Главное, чтобы заказчик понимал, для чего он собирается делать сайт, какие цели преследует и мог донести свою идею. Все остальное происходит гораздо проще.»

Разработчик снимет все ваши проблемы, кроме одной: он не решит за вас, что вам надо. Даже если он предложит несколько вариантов, приемлемых в вашей ситуации, выбор цели (и ответственность за этот выбор) – за вами. Всегда, без исключений.

Не будьте всезнайкой

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

Опасайтесь гигантомании

Еще один бич новичков – гигантомания. Впервые выходя в интернет-пространство с собственным проектом, каждому хочется поразить мир самым крутым среди конкурентов продуктом. Мы верим, что «до нас никто еще такого не придумал», и рвемся сразу нагромоздить массу страниц и кучу опций.

«Обычно такие проекты обрастают огромным количеством трудностей, переделок, – объясняет Анна Федорук. – Потому что если ждать, когда весь процесс будет завершен и готово будет абсолютно все, то этот момент никогда не наступит. Или наступит, но к тому времени все уже забудут, чего хотели в начале».

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

Будьте конкретны

Обсуждаете ли вы дизайн или функционал – избегайте общих фраз, туманных формулировок. Здесь работает правило: все, что может быть понято не так, будет понято не так. Если вы присылаете разработчику пример дизайна сайта, который вам нравится, приложите комментарий о том, чем именно он вам понравился. Иначе может получиться, что вы имели в виду красивый переход цвета в шапке и шрифт меню, а разработчик решил, что здесь главное – обилие «воздуха» и большие картинки. Говорите конкретно, показывайте пальцем, обводите карандашом.

Право на доработку + ответственность

Очень больной вопрос – компромисс между бесконечным «не нравится» со стороны заказчика и стандартным набором вариантов со стороны разработчика. Действительно, бывает так, что несмотря на долгую работу исполнителю не удается сделать, скажем, дизайн, который бы радовал клиента. Что это: придирки капризного заказчика или отсутствие вкуса/непрофессионализм разработчика? А главное – как быть в такой ситуации?

«Иногда поиск другого дизайнера – единственный выход, но это все же крайняя мера, – отвечает Анна Федорук. — К этому не придется прибегать, если изначально были изучены пожелания заказчика и он понимает, чего хочет. Опытный разработчик на этапе первых обсуждений постарается понять, что нравится клиенту, и решить, смогут ли это сделать те, кто есть в штате. Но все бывает, и если никто никому не пойдет навстречу, то проект или закроется, или затянется».

Панацеи от «несовпадения вкусов» нет, но кое-что сделать вы можете. Изучите примеры работы исполнителя: они должны вам нравиться.

Выбирайте компании, где есть несколько дизайнеров и программистов. В случае чего, они смогут поискать другое решение с помощью коллег.

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

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

Примите мысль, что ваш вкус не идеален. Не все, что нравится лично вам – действительно оптимальный вариант. Если в целом работы исполнителя вам по душе, почему вы уверены, что именно ваш заказ он выполнил «не совсем так»? Будьте готовы принять что-то неожиданное для вас, новое, свежее.

Не недооценивайте объем работ. Неопытному человеку может казаться, что «переделать вот это – пара часов». Адекватный заказчик никогда не скажет: «Это должно быть готово через день и знать ничего не хочу».

Вчитайтесь в договор

Обратите внимание, прописаны ли договоре все этапы работы, их результаты и сроки, ответственность разработчика. Если вы договариваетесь с разработчиком о техническом сопровождении сайта, взаимодействии с хостинг-провайдером не забудьте внести это документ. Но главная рекомендация такова: договор – не техническое задание, в нем все должно быть понятно даже неспециалисту. Уточняйте все, что вызывает вопросы.

Материал был подготовлен совместно с редакцией сайта «ПроГрабли», консультировала Анна Федорук, генеральный директор «Стерно.ру»