Клиенты в разработке сайтов бывают разные, как впрочем и везде. Одни легки и мимолётны, другие тяжелы и остаются всерьез и надолго. Первые заказывают, потому что им положено по работе, другие делают это искренне и с энтузиазмом. Но есть два основных типа: одноразовые и те, кто возвращается. Почему же так происходит? 

Для начала нужно разобраться, на чьей стороне ответственность, от кого больше зависит восприятие результата клиентом? Кажется на это есть очевидный ответ - исполнитель. Ведь это он, а не кто-то другой все делает, выполняет работы, хорошо ли, плохо ли. Делает лучше или хуже, быстрей или медленней. Но не все так просто, как кажется.

Хороший клиент это владелец или руководитель бизнеса, который четко понимает зачем ему сайт. При этом он не стремится влезть во все детали, указывать как конкретно делать каждую мелочь. Он позволяет разработчику развернуться, реализовать свой опыт, показать на что он способен. В этом случае лучше, если он не позволяет сильно увлекаться, при этом оставаясь достаточно требовательным, чтобы исполнитель не расслабился.

Существует известная дилемма - заказчик всегда хочет получить больше за свои деньги, исполнитель стремится сделать меньше. За этой простой формулой кроется много разочарований, в пустую потраченных времени и денег.

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

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

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

Возьмем тот же ремонт квартир, машин, работу общественных служб, а также все те области, где знание того, как делать правильно находится полностью в недоступной для непрофессионала области. Большинство клиентов СТО не могу знать верно ли им поменяли аммортизатор, сделали плановое ТО или проверили свечи. Внешне все может выглядеть правильно, но как на самом деле знает только сам исполнитель либо нужно приглашать стороннего эксперта.

В области разработки сайтов похожая ситуация. Как обычный сотрудник компании, будь-то менеджер или директор по маркетингу, может оценить качество верстки или, тем более, программного кода. Это имеет две стороны. В одной заказчик, не являясь специалистом, не может оценить качество работы и принимает ее, полагаясь на профессионализм разработчика. В другом случае, когда заказчик гипер-активен, он лезет во все и требует изменений на свой вкус. О качестве таких изменений ходит много шуток и историй.

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

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

Одна из этих технологий называется эджайл (от англ. agile - гибкий). Попросту гибкое отношение к процессу. Нет смысла загонять себя в рамки бюджетов и сроков, когда никто толком не знает, что в итоге должно получится. На берегу, в начале работы, когда все еще только обсуждается, ни заказчик, ни исполнитель не могут дать стопроцентной оценки и гарантий результата. Как говорится, человек предполагает, а бог располагает.

В технологии эджайл есть два основных принципа, на которых, кроме всего прочего, она основана. Первый это итерации -  разделение работы на небольшие этапы по объему работы и срокам. Очень распространены итерации в неделю, две или месяц. Чем меньше, тем лучше, конечно. Просто не все задачи можно и имеет смысл дробить на слишком короткие промежутки.

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

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

Очень важно, чтобы результатом итерации было что-то, что можно использовать. То есть готовый продукт, с ограниченным функционалом. Совершенно не обязательно, что он будет выложен в общий доступ. Такой подход позволяет быстро оценивать результаты работы, плоды сотрудничества заказчика и исполнителя. Можно выложить сайт (или любой другой продукт из области информационных технологий) в режиме бета-тестирования. Позволить потенциальным пользователям попробовать его, получить обратную связь.

По результатам каждой итерации должно собираться большое количество отзывов от конечных пользователей. Это очень важная часть процесса, ведь именно для них делается продукт. Сомнительно, что будет иметь смысл результат, которым довольны заказчик и разработчик, но им никто не пользуется. Такое почти всегда происходит при разработке формальных продуктов. Когда работа выполняется для галочки, чтобы освоить бюджет. Так бывает в тех случаях, когда взаимодействие заказчика и исполнителя происходит за рамками качества и свойств продукта. Таких примеров масса, интернет забит такими сайтами, как вселенная тёмной материей.

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

Такой подход максимально эффективен и полезен для всех. Понять его жизнеспособность можно только на практике.