Взаимодействие заказчика и разработчика

Согласие есть продукт непротивления сторон, утверждал ильфопетровский механик сцены. Любые проблемы между заказчиком и исполнителем есть продукт неправильного или нечеткого понимания результата разработки — как правило, со стороны заказчика. Потому что исполнитель обычно (хотя не всегда) все-таки понимает, что он делает. Другое дело, что он не всегда может сделать то, что собирался, но это отдельный вопрос.

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

Почему возникают трения между заказчиком и разработчиком (отбросим случаи явной недобросовестности, когда разработчик прекрасно знал, что ему нужно было сделать, но не захотел или не смог это сделать). А возникают они потому, что с самого начала они были поставлены по разные стороны баррикад. Задача заказчика — сделать сайт и заплатить за это как можно меньше денег. А задача разработчика — сделать сайт и получить за это как можно больше денег. Поскольку и тот, и другой во время составления договора смутно представляют, что именно они собираются делать, то, даже если в результате будет сделано именно то, что нужно, у заказчика будет смутное чувство, что он переплатил, а у разработчика — что ему недоплатили. А уж если возникнет конфликт — тем более!

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

Что это за этапы?

Этап первый. Видение проекта

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

Этап второй. Функциональные спецификации.

На этом этапе составляется детальное описание сайта. То есть, буквально описываются все разделы, все страницы.

Если это обычная страница, то указывается, какого типа информация там будет. Например: «на странице 15 находится информация о просветительской деятельности общества „Мемориал“. Перечислены основные направления деятельности, даются ссылки на подразделы — лекционную программу, выставочную, библиотечную».

Если эта страница генерируется автоматически, то указывается механизм генерации. Например: «Страница „Новости“ содержит две колонки, одна из которых — новости общества „Мемориал“, вторая — новости сайта. В каждой колонке публикуется не более 10 последних новостей. По мере прибытия свежих новостей устаревшие новости общества „Мемориал“ перемещаются в архив новостей, устаревшие новости сайта уничтожаются».

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

Еще одна важная составляющая функциональных спецификаций — таблица трудозатрат, которая выглядит примерно так:

Эта таблица очень важна с двух точек зрения.

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

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

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

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

Этап третий. Разработка.

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

Замечу, кстати, что одна из основных причин задержки — несвоевременное предоставление заказчиком материалов — фотографий, текстов и т.п.

Этап четвертый. Тестирование.

Вот тут сайт подвергается тщательной проверке. Что именно проверяется?

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

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

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

Дальше. Проверяем сайт на корректную работу в разных браузерах. Не секрет, что три основных сейчас браузера — Microsoft Explorer, Netscape Communicator и Opera одни и те же тэги отображают по-разному, а то и не отображают вовсе.

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

И так далее.

Когда тестирование закончено, можно сдавать сайт заказчику. Он сам, если требуется, проводит тестирование — примерно по тому же принципу. Он может, кстати, принимать участие в тестировании и до того. Но главное для нас — чтобы он убедился, что сайт соответствует функциональным спецификациям. Тогда работа по текущей версии завершена, можно подписывать акты сдачи-приемки и получать оставшиеся 50%.

Чем хороша эта схема?

• Тем, что на каждом этапе заказчик точно знает, за что он платит деньги.

• Тем, что заказчик непосредственно участвует в работе на всех этапах.

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

Алексей Бабий