Контрольная работа по "Интернет-маркетингу2

8. Порядок приемки-передачи  выполненных работ. Здесь может  оговариваться создание комиссии по приемке выполненных работ и указываться ее состав.

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

10. Состав документации. Как правило, обязательно только  краткое Руководство пользователя. Для крупных сайтов могут потребоваться  и другие документы: Руководство  администратора сайта, Руководство администратора электронного магазина или торговой площадки, Руководство системного администратора и т.д.

11. Обратная связь.  Указываются полные координаты  разработчика и лица, ответственные за контакты с заказчиком.

Оценка технического задания

Оценить качество оформления полученного документа. Техническое задание представляет собой формальный (реже неформальный), хорошо оформленный (желательно в соответствии с государственным стандартом) документ длиной 10 и более страниц. Если оно короткое (2-3 страницы) либо плохо оформлено, студия не очень-то опытна. Документ должен быть хорошо структурирован, легко читаться и не содержать грубых грамматических ошибок. Техническое задание составляется в настоящем времени, т.е. пишется «Сайт содержит то-то и то-то», а не «сайт будет содержать» или «сайт должен содержать». В техническое задание не включаются явно рекламные тексты и общие рассуждения, раздувающие объем документа.

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

В то же время не следует ждать, что разработчик будет заранее бесплатно расписывать все подробности и проводить полное обследование предприятия до заключения договора. В техническом задании только упоминаются и перечисляются необходимые моменты. Немногие из разделов технического задания занимают больше 1-2 абзацев. В соответствии с требованиями государственных стандартов каждый раздел должен начинаться с новой страницы. Вот почему правильно оформленное техническое задание состоит из полутора-двух десятков страниц, на большинстве которых заполнено всего несколько строк. В «правильном» техническом задании должно быть порядка 15000-20000 знаков или 2000-2500 слов.

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

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

Организация выбора разработчика

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

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

Сразу отсеются разработчики, которые не ответили, или уже по ответам видно, что с ними не стоит иметь дела. Ответы на мелкие вопросы должны поступать в течение суток за вычетом выходных (если только ответы находятся в голове у менеджеров и не требуют поисков и обсуждений либо если перерывы в переписке оговаривались). А вот на подготовку качественного технического задания может уйти время, и здесь критерий «скорости» не вполне работает. Однако, неделя – вполне достаточный срок для подготовки технического задания на разработку корпоративного сайта. Не принимать к рассмотрению типовое техническое задание, сплошь состоящее из общих фраз, которые можно легко отнести к любому сайту, и в котором не перечислены заявленные требования.

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

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

Заключение  договора с разработчиком

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

1. Наличие подробного  плана-графика выполнения работ,  в котором каждый этап сдается  не реже чем 1 раз в 2-3 недели.

2. Гарантийный срок, на  протяжении которого замеченные дефекты устраняются бесплатно. Обычно этот срок составляет от 3 до 12 месяцев.

3. Ответственность за  нарушение сроков со стороны  разработчика должна составлять  не менее 0,5% суммы договора  за каждый день опоздания по  его собственной вине. Разумеется, право разработчика – оговорить при этом, что в случае задержки предоставления предприятием необходимой информации срок отодвигается на число дней задержки, а также потребовать от предприятия взаимной ответственности за задержку оплаты выполненных работ.

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

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

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

7. Документация по использованию сайта и программ. В ней должно быть достаточно подробно описано, как рядовой компьютерно грамотный пользователь без помощи разработчика или программиста может совершать действия по обновлению сайта. Не забыть, что обновление сайта на крупном предприятии вполне может быть децентрализованным. Например, на сайте банка курсы валют может ежедневно вводить валютный отдел, процентные ставки по депозитам и кредитам – соответственно депозитный и кредитный отдел и т.д. (Пытаться централизовать сбор и обновление большого объема часто обновляемых данных обычно не стоит, т.к. это может привести к задержкам и сбоям с их публикацией). Средствами нерегулярного обновления вполне могут являться любительские подручные инструменты типа FTP-доступа через простую знакомую программу (Windows Commander, FAR и т.п.), о чем должно быть сказано в документации. Однако если обновление ведется часто, то необходимо включить в техническое задание на разработку сайта специальные администраторские формы обновления (как их называют на жаргоне, «админки»), которые должны быть описаны в документации. Кроме того, ответственный за сайт может самостоятельно разместить (или, как говорят дизайнеры, «залить») сайт на компьютере хостинг-провайдера, а также изменить, добавить, удалить любую информацию на сайте без помощи разработчика.

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

Не нежно беспокоиться за юридические тонкости договора, если на предприятии есть юрист, который изучит договор и, как говорится, «расставит запятые». В противном случае нужно обратить внимание на то, чтобы ответственность за нарушение сроков была равной. Если разработчик находится в другой стране, то обязательно указать, что в случае, если согласие не достигнуто, все противоречия решаются в хозяйственном суде (арбитраже) местности заказчика. Если это не указано, то претензии всегда рассматриваются в местном суде в соответствии с юридическим адресом разработчика, и в случае конфликтов придется многократно выезжать в зарубежную командировку.

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

Цена

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

Цена договора может  основываться на плановых либо фактических  затратах времени и материальных затратах, с полной или частичной предоплатой или без нее (оплата по факту).

Существует следующий  способ управления затратами: выполнить  предоплату 20-25% и ждать первых результатов; если понравится – платить дальше и т.д.

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

Как рассчитать цену? Для  этого широко используется почасовая  ставка. В целом по отрасли накладные  расходы нередко достигают 200%. Это  означает, что для обеспечения  производственному персоналу (дизайнерам, программистам) заработной платы в 200-300 долл «чистыми» на него должно приходиться хотя бы 800-900 долл безналичных денежных поступлений.

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

Не слушать экономистов крупных предприятий о якобы чрезмерно большой величине накладных расходов в 200%: мол, таких высоких процентов не может быть, и 40-50% - это якобы максимум. Спросите у этих экономистов, каковы, по их мнению, должны быть расходы по разовым работам. Ведь накладные расходы крупных белорусских промышленных предприятий по изготовлению уникальных товаров малыми партиями по разовым заказам нередко составляют 2000-2500%.

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