Корпоративный веб-сайт на 100%. Требуйте от сайта большего! - Роман Овчинников

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

♦ Настройки произвольного количества маршрутов или статусов при движении документа

♦ Настройка прав и правил движения документа (например, право перехода из статуса «черновик» в статус «согласовано» имеют только пользователи ролей «главный редактор» и «администратор»)

♦ Синхронизация и, наоборот, блокировка работы над документами

♦ Поддержка различных кодировок (например, Win-1251, UTF-8 и др.)

♦ Сохранение истории всех изменений

♦ Настройка различных правил документооборота для разных типов данных (статей, файлов) или разных разделов данных (о компании, каталог продукции)

♦ Поддержка системы оповещения о различных действиях над документом (например, «о внесении изменений», «о факте публикации»)

♦ Автоматическое создание версий документа на установленных этапах, возможность отката документа к определенному состоянию

♦ Использование специальных поисковых инструментов

74. Документация

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

Документы на стадии разработки

Обратите внимание, что еще при заказе веб-сайта вам должны быть предоставлены:

♦ Договор на разработку веб-системы

♦ Календарный план

♦ Бюджет

♦ Техническое задание

♦ Договор на поставку (лицензирование) программного обеспечения

Ключевыми являются два документа – договор и техническое задание.

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

Договор на разработку должен фиксировать все основные аспекты взаимодействия подрядчика и заказчика и может иметь следующую структуру:

♦ Предмет договора (наименование предоставляемой услуги, перечень приложений, условия вступления договора в силу и т. д.)

♦ Прочие условия (максимально возмещаемый ущерб, параметры использования электронных коммуникаций и т. д.)

♦ Ответственность сторон и регламент (условия выплаты неустоек, механизмы пролонгации, условия расторжения договора и т. д.)

♦ Форс-мажор

♦ Стоимость и условия оплаты (стоимость исполнения работ, схема оплаты и т. д.)

♦ Терминология

♦ Права и обязанности сторон (указание исполняемых работ, условия привлечения сторонних подрядчиков, правила обмена проектной информацией, распределение авторских прав и т. д.)

♦ Конфиденциальность информации (условия соблюдения конфиденциальности, способы защиты информации, срок действия режима конфиденциальности и т. д.)

♦ Реквизиты и подписи сторон

Вся истина в ТЗ

Техническое задание (ТЗ) на разработку веб-системы обычно оформляется как приложение к основному договору. Объем ТЗ, составляемого серьезным разработчиком, может доходить до 60–80 листов и включать несколько сотен параметров.

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

Структура технического задания может выглядеть следующим образом:

♦ Общая информация

• Общая информация о заказчике

• Общая информация о проекте

• Общие вопросы обслуживания

♦ Требования к информационной инфраструктуре

• Общее устройство системы

• Роли

• Доменные имена

• Карта фронт-офиса

• Объемы и форматы информации

• Многоязычность

• Учет требований поисковых систем

♦ Календарный план выполнения работ с указанием ответственности сторон

♦ Требования к технической инфраструктуре

• Требования к программноаппаратной платформе

• Требования к используемым технологиям

• Требования к хостинговой площадке

• Требования к производительности

• Требования к безопасности

♦ Требования к интерфейсу

• Требования к дизайнерскому решению

• Предоставляемые заказчиком визуальные компоненты

• Требования к навигации, шрифтам, сетке форматирования

♦ Требования к мультимедийным элементам

• Перечень

• Формат

• Условия работы

♦ Регламент выполнения работ на этапах проектирования, разработки, тестирования, документирования и обучения, запуска веб-сайта и гарантийного обслуживания

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

Документация на стадии поддержки и развития

Документированию подлежит не только стадия разработки, но и стадия поддержки и развития. На ней обычно поставляются:

♦ Договор о поддержке , определяющий условия предоставления соответствующей услуги

♦ Документ о передаче логинов и паролей

♦ Руководство по администрированию (документ, фиксирующий требования к программно-технологическим аспектам системы, – таким, как режимы работы серверов, настройки шлюзов, протоколы обмена данными и т. д.)

♦ Руководство разработчика (документ, описывающий программные составляющие системы – классы, функции, бизнес-логика и т. п.)

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