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

Решена она за счет четырех следующих принципов:

  1. Короткий цикл обратной связи.
  2. Непрерывный непакетный процесс.
  3. Понимание, разделяемое всеми.
  4. Социальная защищенность программиста.

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

Давайте разберемся, какой из этих принципов является ключевым и позволяет экстремальному программированию согласовывать интересы заказчика и разработчиков. Думается, что это принцип «Заказчик всегда рядом». Дело в том, что заказчик в экстремальном программировании – это не тот, кто оплачивает счета, а конечный пользователь программного продукта, а в нашем случае – посетитель сайта.

Экстремальное программирование постулирует, что заказчик все время должен быть на связи и доступен для вопросов.

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

Иногда бывает, что заказчик просто не знает свою целевую аудиторию в силу слабости маркетинга. Но эту ситуацию мы рассматривать не будем, хотя она очень и очень нередкая (рекомендуем статью портала E-xecutive о зависимости трудоемкости создания сайта от состояния маркетинга заказчика).

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

Следующим по важности оказывается принцип простоты, выражающийся в т.ч. в непрерывности тестирования. Экстремальное программирование исходит из того, что условия задачи в процессе работы неоднократно меняются, и спроектировать готовый продукт заблаговременно целиком и полностью невозможно, это напрасная трата времени. Проектирование – настолько важный процесс, что он выполняется постоянно в течение всего времени работы над проектом, и заказчику (напоминаем, это не клиент, который платит деньги, это реальный пользователь) необходимо постоянно предлагать для тестирования создаваемые версии сайта с тем, чтобы получить от него обратную связь. Насколько для него удобно, привлекательно, интересно?

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

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

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

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

Если мы эти два принципа (заказчик рядом и непрерывности проектирования) реализовали успешно, и они выполняются и работают, то тогда последнее, что нам остается, — организовать «игру в планирование». Мы будем быстро формировать предварительный план работы и обновлять его по мере того, как условия задачи уточняются, решаются, выдвигаются новые. В этом случае заказчик и разработчик обмениваются пожеланиями о том, что должно быть сделано, и планами работы по технической реализации. Таким образом, заказчик отвечает за бизнес-решения, а команда разработчиков – за их техническое воплощение. Разделение сферы ответственности делает процесс реализации сайта успешным, а проект – эффективным и завершенным. А значит, реализуется и принцип социальной защиты разработчика.

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

Результаты известны…

И в завершение — короткий медиа-фильм о замечательной целевой аудитории одного из наших клиентов: