ное оборудование, программное обеспечение, системы пасности и защиты от сбоев;
• постоянные расходы на исследования и изучение новых тех нологий. Крупная компания-разработчик, дорожащая свои, имиджем на рынке, не может позволить себе полагаться н непроверенные технологии. С другой стороны, термин «кои серватизм» в области интернет-технологий является синонимом слова «самоубийство». Единственный выход — вклады-вать средства в собственные исследования;
• расходы на поддержание управляющей структуры. Когда в компании работает пять человек, любой вопрос можно решить на уровне личного общения. Когда организационная структура включает более 20 человек, руководители тратят все свое время на решение рутинных организационных вопросов, что неминуемо приводит к торможению в росте, застою и отставанию от конкурентов. Единственная альтернатива — организация устойчивого механизма управления и делегирования полномочий, что связано с дополнительными значительными издержками.
Преимущества крупной компании, за которые приходится платить заказчику, также очевидны:
• стабильность и надежность компании;
• гарантии квалификации и возможностей компании (наличие опыта решения аналогичных задач);
• лучшая управляемость проектами и организация адекватного взаимодействия;
• формализация отношений (можно предъявить претензию и подать в суд).
В силах заказчика дать исполнителю большее чувство комфор' та при оценке проекта и таким образом снизить величину рисков (по крайней мере, внешне) и соответственно общую цену проекта. Делается это за счет:
• предоставления четко сформулированного запроса на преД' ложение (RFP — Request for Proposal) с представлением крй' териев оценки и конечных бизнес-задач;
• признания возможных изменений в функциональности сист мы в процессе реализации и выделения определенного проД611 та бюджета (10 — 20%) на реализацию подобных изменений;
. уважительного отношения к требованиям исполнителя и поиска разумного компромисса по спорным вопросам; это вызовет у исполнителя чувство уверенности в том, что спорные вопросы в процессе разработки также будут решаться путем компромисса.
Таким образом, наиболее оптимальный, с точки зрения цено-бразования, выбор поставщика базируется на следующих принципах:
. наличие у поставщика опыта разработки систем для вашей индустрии, выраженного в виде модулей и наработок;
• заказчик и исполнитель имеют однозначные ожидания о потенциальных рисках проекта и определяют их сразу, до запуска проекта;
пользователях, долгосрочного планирования. За такой бюджет начинают бороться серьезные интернет-компании, если только заказчик не хочет получить в рамках этого бюджета серьезный информационный проект.
«Большим» считается бюджет $50-60,000 в год и более. Компания должна иметь веские основания для выделения подобного бюджета, в частности она должна четко представлять непосредственную коммерческую отдачу от вложений. Обычно решение принимается на основе бизнес-плана, представляющего расходную и доходную части проекта. Для таких проектов поставщика выбирают долго и кропотливо, оценивая все возможные факторы. Устойчивость и профессионализм потенциального поставщика услуг в этом случае играют основную роль.
Размер бюджета на развитие интернет-технологий, строго говоря, не связан с размерами компаний. Основным определяющим фактором является важность интернет-технологий с точки зрения развития бизнеса. В нашей практике много случаев, когда суммарный годовой бюджет крупной корпорации на развитие интернет-технологий в России составляет $3-5,000 (менее 0,01% от маркетингового бюджета), а компания из 20 сотрудников тратит более $50,000 в год на систему электронной коммерции и интернет-маркетинг (до 30% маркетингового бюджета), которые в результате создают оборот в более чем миллион долларов в год.
Каким может быть размер Бюджета на развитие интернет-технологий?
«Маленьким» считается годовой бюджет в размере до $12,000. Такой бюджет позволяет решать частичные задачи (дизайн, веб-программирование, рекламные акции и т.д.). Он может быть оправдан Для компаний, у которых есть собственный сильный отдел производства, способный квалифицированно выполнять часть работ, например для рекламных агентств, имеющих собственный производственный департамент, издательств или, например, компаний, производящих программное обеспечение. «Маленький» бюджет могут выделять и круп-ные компании, которые хотят «попробовать» воз-°*ности использования Интернета в своей работе. Подобные заказы наиболее интересны небольшим компаниям, штат которых не превышает двух-Tf>ex человек.
РеоншЬ бюджет на поддержку и развитие кор-"°Ративного сайта составляет $25-30,000 в год. Рэмках такого бюджета можно решить задачи ОДвржки пользователей, поддержки традици-НЬ|х каналов маркетинга и продаж, маркетин-ВЬ|* акций, сбора и анализа информации о
• корпоративный уровень исполнителя должен соответствовя уровню заказчика; крупной компании лучше работать с круп ными поставщиками услуг, небольшой компании-заказчик • лучше выбрать поставщика услуг поменьше и более мобиль ного;
• работы, связанные с постановкой задачи и написанием функ. циональных и бизнес-требований системы, являются неотъемлемой частью процесса ее разработки и должны оплачиваться в рамках отдельного предварительного договора или осуществляться в рамках первого этапа работ после заключения основного договора.
Если попытаться резюмировать приведенный выше опыт для оценки типовых проектов, встречающихся на рынке, можно составить приблизительные градации проектов с точки зрения коммерческого интереса участников рынка. Уложив предполагаемый бюджет на интернет-разработки в эти рамки, вы сможете оценить степень заинтересованности потенциальных поставщиков в вашем заказе.
Зная нашу любовь к иностранным словам, сразу определим, что такое «тендер» и чем он отличается от иногда используемого слова «питч» (pitch). Тендер — это конкурс на проведение какого-либо комплекса работ, связанных с технической и интеллектуальной деятельностью исполнителя. Критерии отбора победителя разнообразны и весьма изощренны. Питч же —• спор на тему о том, кто дешевле сделает уже определенную заказчиком вещь. В интернет мире термин «тендер» обычно используют, когда хотят получит интернет-стратегию, отдельные ее элементы (техническую конце цию, дизайн, медиаплан). Вопрос о том, кто дешевле, к пример)'
«испортит» надоевший дизайн «старого» корпоративного
сайта
или развесит баннеры 100 х 100 на этом, этом и этом (да, и еще ъ том) интернет-сайтах — это уже «питч».
Интернет — особая среда со своим ускоренным темпом Говорят, что год в Интернете — это семь лет в реальной Поэтому и создание проектов, и проведение тендеров в дани
•зачастую создание интернет-проекта занимает считанные ме-и в таком случае конкурс на его реализацию — непозволи-
ьная роскошь. Ведь на определение задач проведения конкур-
объявление о нем, доведение информации до возможных ис-
'днителей, непосредственное проведение, оценку, принятие, до-
лКУ работ может уйти два-три месяца. Таким образом, выполне-
самой бизнес-задачи отодвигается. Случаи, когда специалисты,
аботающие над каким-то проектом, на полпути к его завершению
вдруг обнаруживают, что их опередили, нередки. Именно поэто-
му решив проводить конкурс, необходимо помнить, что времен-
ные рамки здесь ограничены.
Помимо временного фактора очень важен и фактор сохранения информации. Несмотря на то что бизнес-ниш в Интернете достаточно, как только появляется какая-нибудь перспективная, ее одновременно пытаются занять многие. Если вы обнаружили такую нишу, сообщать об этом не в ваших интересах, а объявление конкурса само по себе является разглашением информации о создании какого-то проекта.
Кроме того, объявляя открытый конкурс, вы должны знать, что на него откликнутся непрофессионалы, запрашивающие минимальную цену и утверждающие, что смогут создать необходимый вам продукт, хотя на самом деле это далеко не так.
Надо отметить, что действительно достойные студии нечасто участвуют в конкурсах. Связано это с тем, что многие организаторы конкурсов в Интернете не слишком хорошо понимают специфику Сети. Среди организаторов торгов часто нет профессионалов в области Интернета, и конкурсная комиссия не в состоянии корректно оценить поступившие предложения и сделать верный выбор. В таких условиях единственным критерием оценки стано-вится цена, а конкурировать на уровне цен с огромным количе-твом непрофессионалов — лишняя трата времени и усилий. о некотором смысле решением проблемы может стать закрытый к участию в котором привлекается ограниченный, ото-вами круг исполнителей-профессионалов. В таком случае Работу должны оценивать такие же профессионалы. Если кон-УРс проводится, оценивать результаты должны специалисты, ко-РЬГХ вам предстоит пригласить. Если же вы готовы обратиться т°ронним специалистам, значит, вы заведомо признаете их ком-еНтность, и тогда стоит решить, что лучше: провести конкурс или РУЧить этим специалистам найти достойного исполнителя друти-Методами. Выбор определяется следующими соображениями:
• если у заказчика есть специалисты, способные четко i лить состав и направление работ, то проще обратиться в i салтинговое агентство. Там вам объяснят целесообразно и затратность мероприятий по вхождению в рынок, подбеп команду исполнителей;
• если заказчик может обрисовать задачу, но не понимает д конца, каким образом это должно выглядеть в Интернете имеет смысл провести конкурс.
Итак, вы составили список из пяти-шести студий и теперь не можете принять окончательное решение, кому отдать предпочтение. Объявите конкурс. И поскольку первичный выбор уже сделан, конкурс может быть закрытым.
Составьте приглашение к участию в конкурсе (тендере), в котором детально опишите следующее:
• главную задачу тендера;
• суть заказа;
• основные условия тендера на разработку сайта;
• комплект документов для участия в тендере.
Опишите условия тендера:
• сроки проведения;
• результирующие документы, которые должны быть предоставлены (укажите, какие это документы, в каком формате они будут приниматься на рассмотрение, кому они должны быть предоставлены);
• кто и по каким критериям будет оценивать результаты тендера (допустим, это конкурсное жюри);
• предупредите о том, как участники конкурса узнают о его результатах;
• укажите вознаграждение победителю и участникам тендер (это тоже важно).
Комплект документов, которые вы захотите получить от студи должен включать:
• заявку на участие в тендере (например, документе произвел ной форме в формате MS Word);
• резюме о деятельности студии с любыми приложениями (о11 сание состава портфолио или списка клиентов, список оси ных услуг и т.д.);
. концепцию заказываемого сайта с точки зрения исполнителя;
рредварительную оценку объема работы (сроки, ресурсы, технологии).
цем четче составлено конкурсное задание, тем легче будет оце-
ать предложения и сравнивать их между собой. В идеале нуж-
представить участникам конкурса приблизительный план пред-
ожения, который вы ожидаете получить: главы документов, по-
пядок презентаций, основные вопросы, в понимании которых вы
хотите убедиться.
Календарный план проведения тендера включает в себя:
1. Объявление тендера — рассылка приглашения к участию в тендере по электронной почте.
2. Оповещение предполагаемых участников с целью подтверждения получения информации о тендере.
3. Сроки подачи заявок об участии (например, три рабочих дня с момента получения объявления о проводимом тендере).
4. Срок подготовки презентаций (например, две недели с момента подтверждения готовности участвовать в тендере).
5. Проведение презентаций участников (лучше завершить в течение одного дня).
6. Анализ полученных предложений и вынесение финального решения (неделя от даты презентаций).
7. Информирование всех участников о решении жюри.
8. Расчеты с участниками тендера.
9. Подписание договора с победителем тендера.
Результатом проведенного конкурса обычно является заключение договора с победителем. Разумеется, лица, подающие заявки аУчастие в конкурсе, должны иметь возможность ознакомиться с сУЩественными условиями будущего договора, о ходе подготовки к конкурсу следует уделить особое внима-е Формулированию его условий, так как по закону договор дол-н быть заключен с победителем конкурса в любом случае, если еДитель может быть определен исходя из условий конкурса Работ, представленных на конкурс. Поэтому есть риск того, что °БИЯ конкурса, определенные недостаточно четко, могут со-УЖить вам плохую службу: вам придется заключить договор Цом, представившим предложения, не отражающие ваших Ребностей, но формально удовлетворяющие условиям кон-
ческом отношении «сооружение», содержащее базы данных, па пределенное на нескольких компьютерах и т.д. Вне зависимое? от того, насколько сложным будет ваш сайт, вы должны заказат создание технической части (написание программного кода интеп нет-страниц) и дизайна. Если информация, которую вы намерещ. разместить на сайте, будет обновляться достаточно редко, то в д0 говор на разработку ресурса можно включить работы по размещению подрядчиком этой информации.
Для того чтобы ваш сайт был доступен интернет-пользователям необходимо не только разработать его, но и разместить на компьютере, постоянно подключенном к Интернету. Этот компьютер должен иметь:
• соответствующую операционную систему;
• специальную программу (веб-сервер), которая обеспечивала бы прием запросов из Интернета и отсылку запрошенной информации с вашего сайта пользователям (посетителям).
Таким образом, вам предстоит определиться с тем, какие расходы необходимо нести в связи с созданием, технической поддержкой, размещением сайта, а также доступом к нему пользователей.
Несмотря на то что все это, скорее, экономические, нежели правовые, аспекты «сайтовладения», мы описываем их здесь исходя из сугубо практических соображений: все они так или иначе будут описаны в виде юридических документов.
Типы договоров
В зависимости от того, какой вариант будет более приемлемым исходя из ваших потребностей и возможностей, вы можете заказать услуги по разработке, размещению, технической поддеРжке и ^' министрированию сайта у одного или нескольких лиц. Немногие компании смогут предложить вам весь комплекс услуг, но тем не менее хотелось бы сразу весьма кратко определить наиболее вероятные варианты и выделить наиболее характерные особенности документов.
Договор на проектирование предполагает выполнение компле^ са аналитических и исследовательских работ, фиксацию основнЫ* технологических и художественных решений в виде концепций' технического задания и технического (эскизного) проекта. Не сто
•я в предыдущих частях, о техническом задании и техническом рроекте речь пойдет далее.
договор на разработку будет включать в себя разработку про-яниушого обеспечения и дизайна сайта. Процедурно два этих па-ллельно осуществляющихся процесса едва ли имеют различия. Однако случаи, когда разработка программного обеспечения зака-ывается одной компании, а разработка дизайна, то есть графического решения, — другой, не являются чем-то из ряда вон выходящим. Стоит, правда, сразу оговориться, что подобная ситуация возникает прежде всего в ходе разработки сложных систем, к которым предъявляются крайне жесткие требования функционального и эстетического характера.
Договор хостинга потребуется, если вы намерены разместить свой сайт у провайдера — компании, предоставляющей «аренду» дискового пространства на компьютерах, имеющих подключение к Интернету и снабженных соответствующим программным обеспечением. Ситуация, в которой заказчик размещает сайт у провайдера, наблюдается в большинстве случаев, поскольку это значительно дешевле, нежели прокладывать канал с высокой пропускной способностью, покупать мощный компьютер, серверное программное обеспечение и обеспечивать администрирование этой сложной системы самостоятельно. Существующие технологии позволяют в большинстве случаев осуществлять удаленное администрирование сайта, установленного на веб-сервере в любой точке планеты так же, как если бы веб-сервер находился в вашем офисе. Возвращаясь к вопросу о провайдере, следует учесть, что современные системы, названные емким словом «сайт», работают в тесном взаимодействии с серверным программным обеспечением. Поэтому при выборе провайдера, который будет предоставлять ам услуги хостинга, необходимо прежде всего учитывать его воз-°Жности с точки зрения совместимости серверного программно-обеспечения. Другими словами, обеспечение, которым распо-Гает провайдер, должно быть совместимо с теми технологиями, торые использовал разработчик вашего сайта. Например, если работчик создавал интернет-сайт исходя из того, что он будет ановлен на платформе MS US, то компания, предлагающая УГИ хостинга под UNIX, не подойдет вам в качестве провайдера. Ийт НаконеЧ' предстоит заключить еще один вид договора. Ваш 4 еРйет-сайт должен иметь свой адрес, желательно благозвучный, с Жирующийся с вашей деятельностью, в идеале совпадающий •^ВсШирчч/г пятттой vпмггянии или гтпллтктя jcrrrnnoMV 6vAPT ттогкя-
Проведение конкурса, по сути, очень близко ть оферты, то есть выставлять предложения воров.
Проведение конкурса предполагает подготовку его условий кладывает определенные обязательства на организатора. Так' пример, компания, объявившая публичный конкурс, вправе из\ нить его условия или отменить конкурс только в течение первой п ловины установленного для представления работ срока. При это в случае изменения условий конкурса или его отмены лицо, объ явившее о конкурсе, должно возместить расходы, понесенные любой организацией, которая выполнила предусмотренную в объявлении работу до того, как стало или должно было стать известно об изменении условий конкурса или его отмене. В этом случае лицо объявившее конкурс, все же может быть освобождено от обязанности возмещения расходов, однако нужно будет доказать, что работа была выполнена конкурсантом не в связи с конкурсом (например, если работа была выполнена до объявления о конкурсе) либо заведомо не соответствовала условиям конкурса.
Применительно к правовой проблематике заключения договора на создание сайта на основе проведенного конкурса следует заострить внимание на еще одном важном вопросе.
Как известно, сайт содержит объекты авторского права и, более того, сам является таковым. Договор между заказчиком и разработчиком интернет-сайта должен включать положения, регулирующие авторские правоотношения сторон. Применительно к проведению конкурса статьей 1060 Гражданского кодекса РФ предусмотрено, что лицо, объявившее публичный конкурс, приобретает преимущественное право на заключение с автором произведения, удостоенного обусловленной награды, договора об использовании произведения с выплатой ему соответствующего вознаграждения.
Вы определились с местом вашего будущего интернет-ресуР в хитросплетении бизнес-процессов предприятия, разработ его структуру, выбрали подрядчика, который будет осуществлю разработку. Следующим этапом вашей деятельности станет закл10 чение договора на разработку сайта. В этом разделе мы рассм рим особенности, характерные для договоров на выполнение добных работ. При этом под особенностями будем понимать
о юридические тонкости, которых, кстати, не так уж много, Т° тличия подобных договоров, обозначившиеся в практике их Й° мгания. Чтобы уяснить эту мысль, обратите внимание на сле-поДП11 дуюшие моменты:
с позиций гражданского права договор с разработчиком интернет-сайта не является особым видом договора. Все, что будет сделано разработчиком, исчерпывающим образом описывается соответствующими главами Гражданского кодекса РФ. В частности, здесь говорится о «Договоре подряда» и «Договоре оказания услуг». Однако договор, который вам предстоит заключить, скорее всего, нельзя будет отнести к какому-то одному виду договора, предусмотренного Гражданским кодексом. Как правило, данный документ будет предусматривать и оказание услуг, и выполнение работ, будет содержать элементы авторского (лицензионного) договора, а возможно, и элементы договоров другого типа. Таким образом, говоря о классификации такого договора с точки зрения гражданского права, мы будем иметь в виду договор смешанного типа; • описание практики, которая сложилась в отношениях между разработчиком (подрядчиком) и заказчиком, касающихся разработки или технической поддержки, необходимо здесь потому, что некоторые пункты предложенного потенциальным подрядчиком договора могут вас смутить и вызвать негативную реакцию, единственным объяснением которой может служить ваша недостаточная осведомленность. Дабы избежать неоправданной траты времени, проведенного в переговорах с представителями разработчика в поисках компромисса, остановимся на наиболее существенных практических моментах более подробно.
Итак, для заключения договора вы должны вначале определиться с объемом работ, выполнение которых ожидаете от подрядчи-а- (Здесь и далее мы будем говорить о «работах», имея в виду под тим также и услуги, если иное не будет прямо указано.) Если рассматривать некий гипотетический минимум, необходимый вла-ЛЬДУ сайта, то можно составить представление о той разновид-сти отношений, стороной которых вам предстоит стать.
фежде всего вам предстоит создать сайт. Юридически поня-
6 <<сайт» является чрезвычайно широким. Под этим может под-
разУмеваться и несколько страниц, содержащих основную инфор-
Цию о вашей компании, и сложнейшее в структурном и техни-
Продолжение ~fr
формулировка закона «Об авторском праве и смежных правах», предусматривающая, что «права, прямо не переданные по авторскому договору, считаются непереданными». Это означает, что в договоре требуется указать все права, которые передаются вам исполнителем вашего заказа. Вы не станете обладателем тех прав, которые не будут указаны в договоре.
В соответствии со ст. 16 закона «06 авторском праве и смежных правах» автор (в нашем случае правообладатель — разработчик сайта) имеет следующие имущественные права:
• воспроизводить произведение (право на воспроизведение);
• распространять экземпляры произведения любым способом: продавать, сдавать в прокат и так далее (право на распространение);
• импортировать экземпляры произведения в целях распространения, включая экземпляры, изготовленные с разрешения обладателя исключительных авторских прав (право на импорт);
• публично показывать произведение (право на публичный показ);
• публично исполнять произведение (право на публичное исполнение);
• сообщать произведение (включая показ, исполнение или передачу в эфир) для всеобщего сведения путем передачи в эфир и (или) последующей передачи в эфир (право на передачу в эфир);
• сообщать произведение (включая показ, исполнение или передачу в эфир) для всеобщего сведения по кабелю, проводам или с помощью иных аналогичных средств (право на сообщение для всеобщего сведения по кабелю);
• переводить произведение (право на перевод);
• переделывать, аранжировать или другим образом перерабатывать произведение (право на переработку).
Применительно к заказу разработки интернет-сайта можно выделить следующие имущественные права, которые необходимо получить заказчику:
• право на воспроизведение, если заказчик имеет потребность в создании копий сайта в количестве, превышающем необходимое для резервного копирования;
• право на распространение, если заказчик намерен любым способом распространять (продавать, сдавать в прокат и т.д.) экземпляры про-
изведения. Очевидна необходимость получения этого права, например, для ASP — провайдеров приложений, бизнес которых как раз и состоит в сдаче программного обеспечения в прокат;
• право на импорт, смысл которого применитель-но к сайту мы постарались раскрыть ниже;
• право на публичный показ;
• право на сообщение для всеобщего сведения по кабелю. Несмотря на анахроничную форму «по кабелю», содержание этого права, раскрытое в законе «Об авторском праве и смежных правах» достаточно полно отражает процессы загрузки страниц сайта пользователями;
• право на перевод, если планируется осуществить перевод соответствующих составляющих сайта на другой язык. Особенно уместно получение этого права, если исполнитель по договору помимо всего прочего создает контент;
• право на переработку, если заказчик намерен осуществлять дальнейшую модернизацию интернет-сайта как самостоятельно, так и силами третьих лиц.
Для практики разработки сайтов характерно, что для конкретного заказчика чаще всего эксклюзивно разрабатывается только графическое решение ресурса и его структура (то есть набор и взаимосвязь тех или иных информационных блоков). Зачастую структура сайта разрабатывается самим заказчиком или с его непосредственным активным участием. На эти объекты или, по крайней мере, на объекты, составляющие дизайн, заказчик должен получить исключительные имущественные права использования.
Функциональные возможности сайта определяются программным обеспечением, включенным в него. Программное обеспечение для конкретного проекта создается крайне редко, чаще всего исполнитель осуществляет лишь его настройку в со-ответствии с техническим заданием и/или адап-тацию к платформе, на которой будет установлен сайт. В связи с этим получение исключительных прав на программное обеспечение сайта прзкти-чески неосуществимо. Исключение составляют фрагменты кода, отдельные программные модуле написанные специально. Целесообразность полу-чения исключительных имущественных прав на эти объекты может определить только заказчик.
Помимо этого большое значение имеет такое понятие, как срок, на который по договору пере-
Даются те или иные права использования объекта (авторских прав. Если передача прав планируется на срок, отличный от пяти лет, то этот срок дол-1жен быть обязательно указан в договоре. Договор ножетопределять различный срок использования различных объектов. Так, например, для внешнего графического решения (дизайна) сайта может ггь установлен срок использования, равный трем дам, а для созданного программного обеспечения — пяти. Несмотря на желание многих заказ-Ичиков «на всякий случай» получить права на ис-'пользование разработок на как можно больший гсрок, практика показывает, что в подавляющем "„•большинстве случаев увеличение сроков ничем не г оправдано. Полное моральное и техническое уста-.. ревание разработок сейчас происходит стремительно, и к моменту истечения сроков использования сайт подвергается настолько значительным .изменениям, что использование разработок 3-5-летней давности, положенных в его основу, фактически прекращается.
В договоре также обязательно должна быть ука-' зана возможность передачи прав использования объекта авторского права третьим лицам. Если такое право по договору не передано в явном виде, считается, что заказчик сайта его не имеет.
Практическое значение этого обстоятельства состоит прежде всего не в придании заказчику сайта возможности беспрепятственно распространять результаты разработок, а в наделении заказчика определенной свободой действий при реорганизации собственного бизнеса.
В некоторых случаях привлечение инвестиций в проект возможно только путем создания новой ,',-Компании со старыми участниками и инвесторами, входящими в число участников в качестве новых. Как правило, имущественные права и другие активы не принято передавать в порядке лраво-; преемства при создании новой компании и свертывании деятельности существующей. Длительность процедуры ликвидации, выделения долей имущества участников, создания после этого но-в°й компании значительно замедляют процессы, •-Связанные с привлечением финансовых средств от новых участников в компанию — владельца ин-;, еРнет-проекта. Поэтому наиболее распространен "Уть привлечения новых участников передачи ак-Ивов из старой компании в новую, при этом не окончания процедур ликвидации либо даже их начала.
Таким образом, «старая» компания — владелец проекта — должна обладать правами на передачу имеющихся у нее прав на объекты авторского права другому лицу.
Территория использования результатов разработок исполнителя по договору о создании сайта так же, как и срок, может устанавливаться отдельно для отдельных объектов. Категорически не рекомендуется не указывать территорию использования вообще, поскольку в этом случае будет считаться, что права переданы для использования объекта авторского права только на территории России. Теоретически такое1 положение можно признать удовлетворительным только для серверных приложений, то есть программного обеспечения, устанавливаемого на веб-сервере заказчика при условии, что сам веб-сервер находится на территории России. Следует учесть, что в этом случае становится невозможным создание так называемых зеркал, а также адаптированных национальных версий сайта, работающих на том же программном обеспечении за рубежом.
Применительно к графике, составляющей дизайн интернет-сайта, HTML-коду, скриптам и прочим объектам, транслируемым на компьютеры пользователей, единственно возможным вариантом определения территории использования является «использование по всему миру», «без ограничения территории использования» (так называемые мировые права).
Потребность создания упомянутых зеркал (полных копий сайта на других веб-серверах), а также адаптированных национальных копий ресурса за рубежом предполагает, что заказчик (владелец) сайта должен обладать правами на импорт объектов, которые также должны быть переданы ему разработчиком по договору.
И наконец, отметим еще одно обстоятельство. С автором (исполнителем) должен быть урегулирован вопрос о том, какое именно название, имя автора или псевдоним указывается заказчиком. Если заказчик не желает указывать имя/название автора на сайте либо других объектах или такое указание вообще невозможно (например, имя автора никогда не указывается на баннерах), заказчик должен получить право анонимного использования результатов разработок.
щен ресурс. Договор на регистрацию доменного имени
ется с регистратором доменных имен. При этом доменное имя существует с момента регистрации, то есть с момента его занесения в базу данных регистратора, и перестает существовать с момента удаления из базы. В соответствии со сложившейся практикой д0. менное имя не может формально рассматриваться как объект купли-продажи. С юридической точки зрения, право на доменное имя является, скорее, правом пользования, нежели правом собственности. Такой позиции придерживаются прежде всего регистраторы доменных имен. Однако несмотря на это получили распространение разного рода соглашения о возмездной уступке права использования доменного имени одним лицом другому. Процесс сопровождается одновременной заменой в базе данных регистратора данных о прежнем владельце данными о новом. В любом случае доменное имя, которое вы будете использовать, должно быть зарегистрировано на вас; именно вы должны иметь возможность администрирования (изменения сведений) записи в базе регистратора.
Рассмотрим более подробно отдельные части договора на разработку (создание) интернет-сайта.
Прежде всего, хотя это и не является особенностью договоров на такие работы, данный договор должен содержать сведения о сторонах, между которыми он заключен; кроме того, он может быть заключен только лицами, имеющими соответствующие полномочия.
Договор может быть заключен органом юридического лица, например директором. В наличии таких полномочий у конкретного лица, заключающего договор, можно убедиться, ознакомившись с уставом, положением (о филиале, учреждении, директоре и т.д.) или решением высшего органа данного юридического лица. Све дения о документе, предоставляющем эти полномочия данно>, лицу, должны содержаться в договоре.
Если договор заключается представителем юридического ли ^ то его полномочия на заключение договора должны быть указа в соответствующей доверенности, которая должна быть деист тельна на момент заключения договора.
'Подписание контракта: авторские права
!: Вопрос о соблюдении авторских прав при заклю--,'чении договора на разработку сайта чрезвычайно ' важен, поэтому мы уделим ему несколько большее • внимание, нежели остальным правовым вопросам, рассматриваемым в данной книге.
При подписании договора на выполнение работ, связанных с созданием сайта, просто необходимо уделить особое внимание положениям, регулирующим права на результаты работ. Заключаемый договор должен позволять как можно проще определить, что же досталось вам после того, как вы заплатили деньги.
С одной стороны, все предельно просто: Гражданский кодекс РФ определяет, что «результаты работ, созданные по договору подряда, принадлежат Заказчику». Действительно, как же может быть иначе? Заказчик платит деньги, предоставляет материа-. лы, проект и т.д. Еще большее сходство отношений, ; возникающих в ходе «построения сайтов», с отно-. шениями, возникающими, например, при строительстве домов, придает, казалось бы, тот факт, что за-j частую отношения заказчика и исполнителя регу-|лируются договором подряда. I Однако существует ряд обстоятельств, не счищаться с которыми — значит, допускать небрежность по отношению к своей собственности.
Первое обстоятельство, хотя и лежащее на по-верхности, заслуживает внимания: правовая при-; Р°Да договора не определяется его названием. '. Другими словами, если договор содержит условия :, авторского договора, договора о совместной деятельности или другого типа договора, но называйся при этом «договором подряда», то к нему бу-ДУ1" применяться те нормы законодательства, ко-°Рые соответственно регулируют авторские пра-в°°тношения или совместную деятельность.
На практике же случается, что договор содержит УСЛОВИЯ, которые регулируют правоотношения различного характера, возникающие между его сторонами, и не может быть целиком отнесен ни к однокодексом. В этом случае мы говорим о смешанном договоре, то есть таком, что содержит условия различных видов договоров. К условиям смешанного договора применяются нормы законодательства, регулирующие соответствующий вид договора. Что касается компонентов сайта, создаваемых в ходе его разработки, то все они защищаются законом «Об авторском праве и смежных правах». Как правило, это так называемые произведения литературного творчества (программа, база данных, тексты страниц, скрипты и пр.) или изобразительного искусства (отдельные графические элементы или весь дизайн в целом). Все вместе и каждый такой элемент в отдельности — объекты авторских прав.
В соответствии с законом «Об авторском праве и смежных правах» те или иные права на объект авторских прав могут быть переданы только по авторскому договору. Это не означает, что вы будете должны заключать с исполнителем работ отдельный авторский договор помимо собственно договора на разработку, но, как и было указано выше, условия авторского договора в этом случае будут включены в смешанный договор (как бы он при этом ни назывался).
Важным моментом является также разграничение имущественных и неимущественных прав. Неоднократно приходилось видеть в договорах формулировку «исключительные авторские права на результаты работ принадлежат Заказчику». Такая формулировка — плод смешения понятий имущественных и неимущественных прав. Неимущественные авторские права (например, право называться автором произведения) на результаты тех или иных работ, в ходе которых был создан объект авторских прав (произведение), могут принадлежать только тому человеку, который выполнил работы и собственно создал этот объект; никакой договор не может служить основанием для их передачи.
Имущественные же права могут передаваться автором другим лицам, но только по авторскому договору. Следовательно, часть вашего будущего договора, регулирующего создание сайта, будет определять объем передаваемых вам имущественных прав. Несмотря на то что, как было написано выше, «результаты работ, созданные по договору подряда, принадлежат Заказчику», существует
Терминология, испопьзуемап в договоре
Договор на разработку сайта, как правило, включает в себя доволь но сложные технические термины. Само по себе это не является чем-то недопустимым, однако вы должны иметь максимальные гарантии того, что тот или иной термин однозначно понимается сторонами. Более того, при подготовке текста договора следует учитывать возможное судебное разбирательство между сторонами договора. С этой точки зрения подробное и адекватное толкование терминов, используемых в договоре, становится необходимым условием.
Исходя из этих соображений целесообразно включить в текст договора отдельный раздел, посвященный используемой терминологии.
К сожалению, какой-либо общепринятой терминологической базы, на которую можно было бы сослаться в тексте, подобно тому как используется ссылка на Инкотермс, сегодня не существует. Поэтому приходится исходить исключительно из собственных способностей по формулированию определений.
Предмет договора
Предмет договора должен позволять однозначно определить суть выполняемых работ, а также другие обязательства сторон, например обязательства об оплате. Поскольку для подобных договоров характерно высокое многообразие работ, выполняемых поэтапно, то, как правило, предмет конкретизируется в тексте договора ниже,
Общим правилом для вас должно стать не стремление к принятой структуре текста договора (предмет, обязанности сторон, порядок оплаты, ответственность и т.д.), хотя это и необходимо, а максимальная точность определения обязанностей сторон и поряд0 их соблюдения.
Помимо общих вопросов, описанных выше, в предмете догово ра можно, в частности, определить, кто именно разрабатывает р гламент создания системы — заказчик или исполнитель. Регламен или как его еще называют, календарный план, содержит сведен об объемах выполняемых работ и сроках их выполнения. Регламе должен предусматривать этапы выполнения работ и время на приемку. Нормальной практикой является разработка реглаМ* исполнителем с последующим утверждением его заказчиком-
Поскольку до разработки технического задания регламент не
У^ет быть определен, в договоре предусматривается срок на со-авление технического задания, затем срок на составление (уточ-рние) регламента. Обязательно укажите, что «с момента утверждения сторонами регламент является неотъемлемой частью договора».
Учтите, что договор на разработку интернет-сайта не предусматривает вопросы, связанные с размещением сайта в Сети или его технической поддержкой. Поэтому нет смысла включать эти вопросы в договор на разработку. Заключайте отдельные договоры на проектирование, разработку, хостинг и техническую поддержку (об этом уже говорилось выше).
Обязанностями заказчика, безусловно, являются:
• предоставление информации, необходимой для подготовки технического задания и регламента исполнителю;
• приемка и оплата работ исполнителя.
Проследите, чтобы в договоре было обозначено ваше право периодически знакомиться с результатами работ исполнителя. Вполне естественно, что исполнитель не имеет возможности ознакомить вас с результатами работ в любой момент, поэтому целесообразно обозначить вид и конкретные даты, предназначенные для ознакомления, или отметить, что они будут указаны в регламенте (календарном плане). В отдельных случаях вы можете договориться с исполнителем на включение в состав участников технологических совещаний наблюдателей или экспертов с вашей стороны. Исполнитель обязуется в течение определенного времени с момента получения аванса разработать техническое задание (технический проект) и регламент (календарный план), на основании КОТОРЫХ разработать сайт, а также осуществлять его гарантийное об-СлУЖивание.
Кроме того, стороны могут ограничить себя условиями соблюдения конфиденциальности, которая может распространяться не лько на финансовые условия договора, но, например, на сам факт Ь1полнения работ и их содержание. В некоторых случаях такое граничение является целесообразным, по крайней мере до окон-
Тельной сдачи работ и «официального открытия» сайта в Интернете
Р°к Действия вашего договора будет равен сроку исполнения
Язательств сторонами. Обратите особое внимание на порядок
°срочного расторжения договора. Если порядок оплаты преду-
тери авансированных средств в случае такого расторжения
вора. Проследите, чтобы удержание аванса было предусмотри договором только для случаев расторжения договора по иници тиве разработчика. Предусмотрите предварительное (письменно уведомление другой стороны о желании расторгнуть договор ц н забудьте указать срок предварительного уведомления.
Авторское право
В этой части уже говорилось об авторских правах, однако применительно к договору с разработчиком хотелось бы остановиться на практике более подробно. Все дело в том, что зачастую заказчик бывает неудовлетворен тем, что исполнитель, разрабатывая программное обеспечение как бы специально по вашему заказу, решительно отказывается передать вам исключительные права. Иногда заказчик пытается убедить исполнителя-разработчика в том, что раз программное обеспечение разрабатывается специально для него, то и права на него должны полностью принадлежать заказчику.
Если более внимательно ознакомиться с процессом разработки, то становится ясно, что доля новизны, вносимая в программное обеспечение разработчиком каждый раз, не очень высока. Как правило, разработчик использует те или иные программные модули, код которых был написан не специально для вас, а для десятка клиентов — ваших предшественников. Кроме того, разработчик заинтересован в том, чтобы иметь возможность использовать эти модули в дальнейшем.
Поэтому вам следует не столько запретить использование этих модулей впредь, сколько обеспечить свободное их использование вами, то есть предусмотреть возможность передачи вашего экземпляра программного обеспечения третьим лицам, право внесения изменений в написанный код и т.д.
Однако описанная выше ситуация характерна не для всех слу чаев. Когда разработчик реализует сложную и, главное, редкУ10 систему по вашему заказу (при этом она содержит оригинальн программные модули, написанные специально для вас), то в пер говорах имеет смысл занять жесткую позицию относительно редачи вам исключительных прав на те программные модули. к торые разрабатываются специально для вас. Оцените, насколь RT-.I гптпкьт ГЯМПГТП«ТРЛТ,НГ> ТТППКРГТМ гпанк Me^KAV гттеттиаЛЬНО Р
ботанным, уникальными «типовым», тиражируемым программ-тм обеспечением, предоставляемым разработчиком многим за-зчикам. Так, например, иногда для сайта, торгующего файлами , рмата .трЗ применяют без каких-либо существенных изменений программное обеспечение «обычного вещевого» интернет-магазина.
Что касается дизайна интернет-сайта, то тут двух мнений быть не может — дизайн каждого ресурса уникален; в этом заинтересованы все стороны: вы, разработчик, его прошлые и будущие клиенты. Поэтому исключительные права на дизайн сайта будут переданы вам разработчиком без каких-либо проблем. Разумеется, разработку дизайна вы поручите той компании, взгляды дизайнеров которой вам наиболее близки. Однако не забудьте указать в договоре, что вам будет представлено на выбор не менее трех или более (по вашему усмотрению) вариантов дизайна.
Все, что здесь было сказано относительно программного обеспечения, в полной мере можно отнести и к документации.
Порядок оплаты
Общий принцип прост: избегайте больших авансов. С другой стороны, аванс является принятой практикой. Таким образом, задача оптимизации сводится к определению приемлемого размера аванса. Обычно аванс составляет 20 — 30% от общей суммы оплаты за работы. Если общая сумма договора включает вознаграждение не только за разработку, но и за поддержку в течение какого-то вре-Мени, обратите внимание на то, чтобы сумма аванса рассчитывалась исходя из суммы за разработку.
Поскольку для систем средней сложности срок разработки составляет обычно от одного до трех месяцев и содержит несколько этапов работ, практикуется поэтапная оплата.
Обязательно свяжите в договоре моменты оплаты с ходом вы-°лнения работ. Вот один из приемлемых вариантов: аванс, выпол-ение первого этапа, приемка работ, выполнение второго этапа, РИемка, оплата за второй этап, выполнение заключительного эта-д' Приемка, оплата, аванс за поддержку,
Стоит иметь в виду, что иногда при разработке технического и регламента могут проявиться нюансы системы, приво-к усложнению и увеличению продолжительности разработ-
данию также неизбежно. Если подобная ситуация вероятна и смотря на наши рекомендации вы заключаете один договор и проектирование и на разработку, следует изначально предусм д реть составление отдельного соглашения, корректирующего щую стоимость работ по договору.
Порядок контропп над ходом выполнения раоот
Приемка каждого этапа должна сопровождаться подписанием акта приемки-сдачи работ. В договоре следует указать разумный срок в течение которого система (отдельный модуль) будет подвергнут тестированию заказчиком, после чего тот должен предоставить исполнителю либо подписанный акт приемки работ, относящихся к данному этапу, либо письменный отказ от приемки с указанием перечня недостатков системы.
Контроль сроков. Сложившаяся система подписания актов приемки-сдачи работ является достаточно эффективным механизмом контроля хода выполнения работ. Проследите за тем, чтобы в договоре были указаны сроки выполнения каждого этапа работ, сроки, отводящиеся на тестирование и приемку этапа заказчиком, сроки подписания акта приемки-сдачи (формулирование претензии в случае обнаружения недостатков). Общее правило: чем больше контрольных точек, тем сильнее контроль над ходом проекта. Самый неудачный вариант, когда контрольных точек всего две: один раз проверка осуществляется после составления технического задания, другой — после завершения тестирования всего проекта.
Нередко сроки разработки системы заранее неизвестны. Это касается сложных оригинальных систем. Однако договор о разработке такой системы должен содержать не собственно сроки разработки системы в целом, но механизм их определения. В частности, можно заранее сказать, сколько времени займет разработка технического задания. Разработчик в состоянии назвать срок, который ему потребуется, в любом случае с погрешностью 20 — 30%. Разумеется, самонадеянно утверждать, что данное правило применимо во всех случаях. Однако если ваш разработчик находится в затруднении даже относительно сроков подготовк технического задания, то, может быть, стоит обратиться к кому либо другому?
Хотелось бы упомянуть здесь же о любопытной оговорке «прй емка по умолчанию», которую приходилось видеть в договор3
разработчиков. Смысл ее состоит в том, что если был открытый публичный доступ к разработанному сай-го все работы исполнителя по созданию или этапу разработки емы автоматически считаются выполненными надлежащим С(Газом. Это равносильно подписанию заказчиком акта сдачи-° иемки работ. Смысл оговорки состоит в том, что таким образом оаботчик страхуется от длительного неподписания заказчиком финального акта сдачи-приемки, несмотря на то что продукт разработки фактически находится в эксплуатации.
Контроль качества. Чем выше цена вопроса, чем больше бюджет разработки, тем четче в договоре должны быть отражены
В соответствии с Гражданским кодексом РФ по договору стороны могут (и очень часто это используют) указать цены в условных единицах или в долларах США при оплате в рублях по соответствующему курсу. При этом возникает необходимость вести учет суммовых разниц, возникающих при изменении курса иностранной валюты или условной единицы. Таким образом, в каждом конкретном случае необходимо сначала проверить целесообразность использования условных единиц при установлении цены в договоре (влияние срока договора, цены, динамики курса и прочих факторов).
Что касается порядка оплаты работ, то Гражданский кодекс установил общее для всех правило, по которому заказчик производит оплату после выполнения всех работ в установленный срок и надлежащим образом. Однако на усмотрение сторон оставлена возможность избрать иной способ оплаты. Как показывает практика, при заключении договора стороны чаще всего выбирают поэтапную оплату работ. Договор подряда (выполнения работ, оказания услуг) в качестве неотъемлемой части обычно содержит приложение — календарный план, в котором указываются все этапы работ, сроки их выполнения и оплаты, цена каждого вида работ.
По соглашению сторон возможна и выдача исполнителю аванса или задатка с последующей поэтапной оплатой работ.
В данном случае хочется обратить внимание на различие в правовом значении задатка и аванса. Принято считать, что аванс — это сумма, которая уплачивается в счет денежного обязательства вперед и не носит обеспечительного характера, присущего задатку.
Подписание контракта: порядок оплаты
•При определении цены договора и порядка опла-•ты следует обратить внимание на ряд моментов, указанных ниже. , В отношении цены:
, • установление цены на каждый вид работ (услуг)
:, отдельно;
'• наличие или отсутствие НДС;
,"• определение цены в условных единицах.
В отношении порядка оплаты:
• поэтапная оплата работ в соответствии с календарным планом;
: • внесение предварительного аванса;
• оплата всех работ после их завершения.
Как правило, цена работы определяется путем составления сметы — неотъемлемой части договора. При этом отдельные виды работ (услуги и ма-;териальные ценности) должны иметь отдельное •Стоимостное выражение не только для удобства 5 расчета между сторонами, но и на случай необхо-I Димости их учета на разных бухгалтерских счетах. I Отдельной строкой в договоре также должен ; Ыть обязательно отражен НДС или же представ-I ны основания, по которым данный вид работ не °Длежит обложению этим налогом.
критерии качества получаемого продукта. Вопросы качества г> боты — крайне болезненная и для заказчика, и для исполните тема. Связано это в первую очередь с неопределенностью грани цы между «приемлемым» и «идеальным» качеством. В процесс переговоров о стоимости работ заказчиком может неоднократн декларироваться, что «нет предела совершенству» и «лучшее — враг хорошего». Однако в момент приемки выясняется, что «при. емлемое» для заказчика качество является «идеальным» для Ис. полнителя.
О качестве программ еще будет упомянуто более подробно в других частях этой книги. Здесь же необходимо упомянуть, что при составлении договора заранее должны оговариваться методы тестирования работ, поскольку тестирование разных частей системы может быть технологически сложной и потенциально конфликтной задачей. При подписании договора можно рекомендовать использовать понятие «профиля стандартов» (в крупных программных продуктах это едва ли не основное мерило «приемлемого» и «идеального» качества).
Профиль стандартов жизненного цикла программного средства — это совокупность нескольких базовых стандартов и других нормативных документов с четко определенным перечнем обязательных и факультативных возможностей. Крупные компании, как правило, ориентируются или на международные стандарты качества (см. часть 4), или на собственные нормативные документы, CASE-технологии. Следовательно, в договоре не стоит перечислять критерии, по которым будет проверяться качество. Достаточно сослаться на существующие стандарты или при составлении технического задания предусмотреть в числе проводимых работ порядок формирования и применения уникального профиля стандартов для выполняемого сайта. Кстати, именно по причине этой неопределенности при выборе подрядчика мы не рекомендовали объединение договоров на проектирование и разработку.
Ответственность сторон
Российское гражданское законодательство достаточно подроби регламентирует ответственность за неисполнение обязательс и позволяет указать в договоре, что «за неисполнение обяз тельств по настоящему Договору Стороны несут ответственное?
однако
учае неисполнения обязательств такое определение ответст-
ости, СКОрее всего, не принесет желаемого результата. Дело
M что зачастую определить ответственность за неисполнение
0 или иного обязательства по договору представляется крайне
блематичным. Ответственная сторона может иметь свое мне-
на счет неисполнения обязательства. В результате компромисс
может оказаться труднодостижимым делом.
Контроль
над ходом выполнения работ
Интересы заказчика охраняются действующим законодательством достаточно хорошо. В любое время заказчик может контролировать ход выполняемых работ, обусловленных договором. В ряде случаев это дает ему основание повлиять на ход исполнения договора или отказаться от нежелаемого результата.
Так, если исполнитель не приступил к выполнению своих обязательств своевременно или же выполняет заказанную работу слишком медленно, что делает невозможным достижение результата в установленные сроки, то заказчик имеет все права отказаться от исполнения договора или потребовать возмещения причиненных убытков. Если же в процессе выполнения работы станет очевидным, что работа не выполняется надлежащим образом, заказчик имеет право потребовать от исполнителя Устранения всех недостатков в установленный срок, если же этого не произойдет, исполнитель будет вынужден оплатить расходы заказчика, понесенные последним в связи с привлечением третьих лиц на Устранение данных неисправностей.
Кроме возможности заказчика самостоятельно
к°нтролировать процесс выполнения работы ис-
олнитель обязан предупредить заказчика и до
°лучения от него указаний приостановить ход
8Ып°лнения работ в следующих случаях:
непригодности или недоброкачественности предоставленных заказчиком материалов (оборудования, технической документации);
• возможных неблагоприятных для заказчика последствий выполнения его указаний о способе исполнения работы;
• иных обстоятельств, не зависящих от исполнителя, но приводящих к некачественному исполнению работ.
Если же исполнитель не уделит должного внимания вышеперечисленным обстоятельствам и не примет необходимые меры, то он теряет возможность ссылаться на данные обстоятельства в случае некачественного или просроченного выполнения обязательств.
Заказчик обязан уделить должное внимание принятию результатов работ, выполненных исполнителем. Как правило, в договоре устанавливается срок, в течение которого заказчик тестирует результаты работ, выявляет соответствующие недоработки или отклонения отданного задания и либо подписывает акт сдачи-приемки, либо предоставляет исполнителю аргументированный отказ с указанием на все недостатки, делающие невозможным прием данного результата.
Заказчик также имеет возможность предъявить претензии исполнителю и после приема результатов работ, если обнаружит недостатки и отступления от договора, которые не могли быть и не были выявлены в момент приемки (скрытые недостатки). Данный вопрос решается либо по согласованию сторон, либо по назначению экспертизы, устанавливающей причины возникновения недостатков и невозможности их выявления в процессе приемки. В заключение хочется отметить возможность установления в договоре гарантийного срока на результаты работ, в течение которого любые неисправности, не связанные с неправильной эксплуатацией, подлежат устранению исполнителем за свой счет.
ЕСЛИ же спор перейдет в судебные коридоры, то и тут возмо* ны неоднозначные трактовки условий договора со стороны суд Поэтому рекомендуем явно указывать ответственность за неиспол нение тех или иных обязательств.
Обязательства, а следовательно, и ответственность за неисполнение обязательств по договору разделяются на три группы:
• действия;
• сроки выполнения действий;
• права собственности на результаты действий.
Под действиями мы понимаем разработку, тестирование, установку программного обеспечения на рабочий веб-сервер, подготовку документации (со стороны подрядчика); оплату, участие в разработке технического задания и его утверждение, приемку результатов работ, подписание актов приемки-сдачи — со стороны заказчика.
Конкретизировать ответственность можно бесконечно. Разумным пределом такой конкретизации является явное указание степени ответственности для наиболее вероятных нарушений (нарушение сроков разработки программного обеспечения или документации, нарушение сроков сдачи-приемки результатов работ сторонами, нарушение сроков оплаты и прав на интеллектуальную собственность).
Разрешение споров и арбитраж. Сегодня для подобного рода договоров в принципе не требуется соблюдать претензионную процедуру разрешения спора, и в случае невыполнения обязательств можно обратиться в суд немедленно. Однако немедленное обращение в суд чревато неоправданными расходами и потерями времени, тем более если вы имеете дело с добросовестным контрагентом. Поэтому так или иначе вам придется использовать процедуру предъявления претензий. Предусмотрите претензионную процедуру разрешения споров в договоре изначально и опишите ее на столько подробно, чтобы у конкретных исполнителей не возника ло вопросов о том, что, в какие сроки и как именно они должн сделать.
Поскольку процесс разработки и согласования различных А талей (преимущественно технического свойства) предполагает А статочно интенсивное общение сторон, укажите непосредстве но в договоре лиц с той и другой стороны (включая контактную й _ формацию), ответственных за согласование такого рода детале
,ние договора
Приложения
Перечислите все приложения, существующие на момент подпи-ания договора, и укажите, что они являются его неотъемлемой частью. Таковыми являются, например, техническое задание, регламент (календарный план). Помимо этого зачастую к договору прилагается протокол (один или несколько) согласования договорной цены, в случае если указать окончательную стоимость проекта в момент подписания договора не представляется возможным. Если рассматривать весь процесс разработки вашего сайта от начала до конца с точки зрения договорной документации, то можно выделить несколько типов документов:
• предпроектные исследования. Иногда этот этап в схеме «заказчик—подрядчик» отсутствует вовсе или проявляется рудиментарно (например, подрядчик имеет большой опыт разработки именно таких систем, как ваша). Если у разработчика имеется готовое решение и задача этого этапа состоит в том, чтобы оценить, насколько разработки подрядчика удовлетворят ваши потребности, то этап может завершиться еще до подписания договора, в ходе переговоров. В завершение исследований стороны потенциального договора определяются с концепцией проекта. Концепция проекта как самостоятельный документ содержит наиболее принципиальные и самые общие требования к системе. Имеет смысл оформить концепцию проекта как приложение к договору на проектирование и разработку;
* проектная документация. Эта работа часто ведется совместными усилиями специалистами заказчика и подрядчика. В итоге стороны получают сначала техническое задание, а затем эскизный и технический проекты. Участие специалистов заказчика часто сводится к участию в разработке и приемке технического задания и уточнению эскизного проекта. Настоятельно рекомендуем оформлять техническое задание в качестве приложения к договору. В соответствии с этим документом будет осуществляться дальнейшая приемка работ. При подготовке технического задания следует быть очень внимательным, поскольку подрядчик может не признать недостатком отсутствие какой-либо функции системы в случае, если она не указана в этих документах. То же самое относится и к способу оеализации каждой функции системы. Как
можно более подробно указывайте в техническом задании вг требования к системе. Учтите, что работа ваших специали стов, участвующих в разработке технического задания, имеет юридические последствия.
По окончании разработки технического задания подписывается акт приемки-сдачи, после чего начинается собственно разработка технической части. Зачастую именно по окончании этого этапа разработчик готов назвать точную сумму договора. Если вы столкнулись с такой ситуацией, то, скорее всего, цена будет обсуждаться вами и разработчиком. По окончании переговоров подпишите протокол согласования договорной цены и приложите его к договору;
• акты об изменениях и акты приемки-сдачи. Обратите внимание на то, чтобы все изменения, вносимые в проектную документацию в ходе разработки (а такое нередко случается), были согласованы. Не стоит чрезмерно бюрократизировать эту процедуру; проследите за тем, чтобы для подобного рода согласований были определены конкретные специалисты с вашей стороны и со стороны разработчика. Принятие решений по вопросам, касающимся технической реализации, — их задача. Подписывайте акт приемки-сдачи после завершения работ и проверки результатов каждого этапа. Если порядок оплаты предполагает уплату заказчиком аванса, который будет постепенно расходоваться разработчиком, необходимо предусмотреть порядок сверки взаимной задолженности. Это можно делать как отдельным актом сверки задолженности, так и включать соответствующую информацию в акт приемки-сдачи работ;
1 рабочая документация. Разработку и сдачу соответствующей документации оптимально привязать к сдаче очередного этапа. Однако это не всегда возможно: не каждый разработчик готов осуществлять подготовку документации параллельно с разработкой; многие готовят документацию уже после того, как система готова к сдаче. Как бы то ни было, описание полученной системы — неотъемлемая часть продукта, равно как и собственно система. Получение документации на систему должно быть предусмотрено в договоре обязательно, пусть даже в завершение работ. Учтите, что в этом случае вы при" нимаете не только систему, но и описание к ней. Поэтому пре" дусмотрите несколько больший срок на финальные испытЗ"
ния для того, чтобы подвергнуть проверке и документацию. Своевременное получение документации чрезвычайно важно еще по одной причине. Обратите внимание на описание процесса досрочного расторжения договора. Если договором не предусмотрена поэтапная подготовка документации, проследите, чтобы в случае досрочного расторжения договора была подготовлена соответствующая документация к разработкам, осуществленным на момент расторжения договора. Иначе воспользоваться результатами разработок будет затруднительно;
гарантийная документация. Обязательно укажите в договоре срок, в течение которого разработчик будет бесплатно устранять (указать, в течение какого времени) недостатки в уже принятой и функционирующей системе. Определите в договоре как можно более конкретно форму заявки на гарантийное обслуживание, предусмотрите, как именно будут устраняться неисправности, потребует ли это перемещения оборудования к разработчику, какой максимальный срок устанавливается для устранения неисправностей системы. Так же, как и для других обязательств по договору, следует определить ответственность за невыполнение гарантийных обязательств. Наконец, определите предельно четко, что вообще считается неисправностью, в результате которой вы имеете право на гарантийное обслуживание. Зачастую в часть договора, касающуюся гарантийного обслуживания, вносятся оговорки относительно случаев, в которых заказчик не имеет права рассчитывать на гарантийное обслуживание. Как правило, в качестве таких случаев указываются: нарушение заказчиком целостности программы, утеря (уничтожение) программы, внесение в программу изменений. Еще одной причиной, которую разработчик, как правило, указывает в качестве препятствия для гарантийного обслуживания, является нарушение условий эксплуатации программного обеспечения — установка на непредусмотренное аппаратное обеспечение, эксплуатация с несовместимым программным обеспечением. Однако такое требование, на наш взгляд, может являться правомерным в случае, если требования к эксплуатации разработанного программного обеспечения были сформулированы разработчиком и вошли в состав документации, представленной заказчику, либо вообще оформлены
тельней, поскольку отказ от гарантийного обслуживания як ляется шагом, имеющим чисто договорные причины. Соответ ственно условия (текст) договора должны позволять эти при чины определить. Эксплуатационные требования не должнь противоречить условиям технического задания, в котором отражены возможности заказчика по созданию платформы для разрабатываемого программного обеспечения. Следовательно, эксплуатационные требования, заявленные разработчиком, не должны быть более жесткими по сравнению с требованиями, описанными в техническом задании. На этот момент следует обратить особое внимание;
• эксплуатационная документация. Иногда путают гарантийное обслуживание и поддержку. Так, например, для восстановления работоспособности системы бывает достаточно перегрузить веб-сервер. Это возможно, если некорректная работа системы обусловлена не ошибками в специально разработанном для вас программном обеспечении, а в платформе — в операционной системе или программном обеспечении сервера. Такие неисправности не будут бесплатно устраняться разработчиком по гарантии, поскольку они не связаны с ошибками в специальном программном обеспечении, им разработанном. Услуги по поддержке могут оказываться в различном объеме с соответствующей их оплатой. Ввиду того что суть этих услуг не связана с разработкой, целесообразно оформить их отдельным договором.
В отдельных случаях, когда разработка сайта не прекращается подписанием акта сдачи-приемки и подрядчик осуществляет доработку ресурса уже в процессе его эксплуатации исполнителем, становится необходимым ведение документации по управлению версией. Управление версией (конфигурацией) предполагает ведение журналов дефектов, фиксацию отдельных изменений, сбор статистики работы системы.
В заключение кратко сформулируем принципы, из которых следу ет исходить при поиске подрядчика и заключении договора на ра работку вашего сайта:
. не торопитесь договариваться с «подвернувшейся» студией — тщательно анализируйте ее портфолио, мнения клиентов и используемые технологии;
. проводя выбор подрядчика посредством конкурса, четко определите и формализуйте задачу и критерии оценки предложений, не забывая о деловой этике к «проигравшим»;
• оплачивайте работы по часам только в случае прочных деловых и по-настоящему «партнерских» отношений. В противном случае нужно исходить из политических решений — какой бюджет на разработку возможно выделить, какие продукты и по какой цене разработчик обязуется предложить заказчику в рамках бюджета;
• договор должен четко описывать все работы, которые будут выполняться. Ничего не оставляйте без внимания;
• текст договора должен быть понятен человеку, не владеющему специальной терминологией;
• лучше заключить несколько договоров на отдельные виды работ, чем свалить в кучу все сроки, обязательства в рамках одного «универсального» документа;
• при подготовке договора помните о том, что, возможно, придется продемонстрировать его суду. Дайте проверить договор опытному юристу, не рискуйте без необходимости и не переоценивайте собственные способности и опыт;
• договор нужен не для достижения договоренностей, а для их закрепления. Зачастую условия договора формулируются в подчеркнуто учтивых выражениях по отношению к заказчику, дабы не «отпугнуть» его. Вас не должен настораживать любой текст, который исчерпывающим образом фиксирует устраивающие вас условия. Бойтесь текста, содержащего смысловые пробелы.
Сведения, которые мы привели в настоящем разделе, не явля-
тся исчерпывающими и не могут быть применены во всех случа-
Х' Мы постарались описать лишь наиболее часто встречающиеся
°просы, возникающие в ходе поиска подрядчика и заключения
Договора.