Главная Вирусы

Тз на доработку программы 1с 8 снабжение. Как грамотно составить техническое задание программисту. Сроки действия договоров

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

Чем сложнее задача, тем подробнее должно быть ТЗ. Когда я участвовала в больших проектах, я видела техзадания и на 30 страниц.

Гурам Сипки, основатель диджитал-студии Udix Media

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

ТЗ составляет менеджер проекта после общения с клиентом и обсуждения задачи с дизайнером.

Крупные заказчики часто просят очень подробные ТЗ, в которых описана каждая кнопка. Небольшие компании наоборот не любят дотошные документы на 100 страниц.

Пример технического задания на доработку сайта

Общие сведения

Наименование автоматизированной системы

«АС СБЫТ»

Заказчик

Исполнитель

Основание для выполнения работ

Плановые сроки начала и окончания работ по созданию системы

Начало работ: 01.09.2010

Окончание работ: 31.12.2010

Назначение и цели создания системы

Назначение системы

Разрабатываемая автоматизированная система предназначена для автоматизации процессов сбыта предприятия..

Цели создания системы

Цели создания автоматизированной системы

Целями разработки «АС СБЫТ»являются:

3. Характеристика объекта автоматизации

3.1 Бизнес процессы предприятия

3.1. 1 Бизнес процесс «Заключение договора»

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

Техническое задание (коротко “ТЗ”) – это документ, который максимально подробно и однозначно отражает требования к Вашему будущему сайту.

Сайт создают именно на основе ТЗ. Чем более подробным и однозначным оно будет, тем больше Ваш новый сайт будет соответствовать Вашим ожиданиям.

ТЗ на создание сайта – как закон, не должно допускать трактовок и разночтений.

Всё, что не прописано в ТЗ разработчик делает на своё усмотрение.

· Руководство администратора;

· Руководство контент-менеджера;

· Руководство по инсталляции;

· Руководство программиста.

2.20. Организация и проведение обучения специалистов Следственного комитета при прокуратуре Российской Федерации

Предъявляются следующие требования к обучению:

· Исполнитель должен провести обучение сотрудников Следственного комитета при прокуратуре Российской Федерации в составе не более 10 чел.

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

· Помещение для обучения предоставляется Заказчиком.

· Место и время обучения должно быть согласовано с Заказчиком.

Обучение должно проводиться по всей функциональности Системы.

В рамках обучения необходимо осуществить информационное наполнение одного пилотного сайта Кольца сайтов Следственного комитета при прокуратуре Российской Федерации.

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

Важно

В процессе внедрения Исполнитель должен оказывать помощь Заказчику в рамках Графика внедрения.

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

6.2.Порядок дальнейшего сопровождения задач АС «СБЫТ».

После сдачи ПО в эксплуатацию, дополнительные доработки и пожелания Заказчика могут быть реализованы по согласованному с Заказчиком ТЗ.

В ТЗ должна быть указана трудоемкость и стоимость работ по реализации дополнительных требований.

6.2.2. Исполнитель обязуется поддерживать телефонную «горячую линию» по сопровождению программного обеспечения.

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

Это ключевая информация для разработчика (вендора), однако именно на этапе сбора требований возникает самое большое число коллизий, ошибок, излишних запросов и проч.

Сюда можно отнести требования к различного рода сортировкам, интеграциям с чатом, возможностям телефонии.

Внимание

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

Уровень технологии - последний в списке, но по важности и сложности опережающий остальные.

Это могут быть требования клиента, связанные с платформой, операционной системой или устройствами. Например, запрос сборки под MacOS.

Microsoft World или Microsoft Excel.

Лично мы при разработке landing page используем специальные программные продукты.

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

По теме: Прототипирование сайта: создание, инструменты и программы.

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

ЛАЙФХАКИ ПО СОСТАВЛЕНИЮ ТЗ

Эти пункты в равной степени относятся как к заполнению брифа, так и к составлению технического задания.

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

1.

Убедиться, что клиент и исполнитель правильно поняли друг друга».

В техническом задании не должно быть качественных прилагательных: красивый, надежный, современный. Их нельзя однозначно понять. У каждого свои понятия красоты и современности.

Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:

То же самое - с невнятными формулировками, которые ничего сами по себе не значат:

Сайт должен понравиться заказчику. А если у него будет плохое настроение?
Сайт должен быть удобным. Что это значит? Удобным для чего?
Сайт должен выдерживать большие нагрузки. 10 тысяч посетителей? Или 10 миллионов?
Качественный экспертный контент. Ну, вы поняли.

Проверяйте, нет ли в тексте неоднозначностей. Если есть - перепишите.

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

Чтобы таких последствий избежать, Вам необходимо техническое задание на разработку сайта.

ОНО МНЕ НАДО?!

Неважно, кто будет исполнителем сайта – Вы сами, Ваш родственник, фрилансеры за скромную оплату, специализированная компания за огромную сумму денег…

Техническое задание на сайт должно быть.

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

Анатомия технического задания

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

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

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

Например, RegionSoft CRM - десктопная программа, у нас нет клиента для браузера. Просить нас создать web-приложение для одной компании бессмысленно, это крупная разработка, она сейчас ведётся и не является возможной доработкой для одной компании.

Полное и краткое наименования информационной Системы

Полное наименование системы – официальный интернет-сайт Следственного комитета при прокуратуре Российской Федерации.

Краткое наименование системы – «Сайт СКП», «Система», «Сайт».

1.2. Наименование заказчика системы и его реквизиты

Наименование: Следственный комитет при прокуратуре Российской Федерации

Место нахождения: г.

Инфо

Москва, Технический переулок, дом 2

Фактический адрес: А

Контактное лицо Заказчика:

Телефон: (4, (4;

Адрес электронной почты

1.3. Перечень документов, на основе которых создается Система

Государственный контракт №________________ от ___ ___________ 2010 г.

1.4.

Плановые сроки начала и окончания работ по созданию Системы

Определяются в соответствии с Договором.

2. Требования к системе

2.1.

Дата платежа

НомерПлатежа

Номер платежа в платежной системе

Сумма платежа

Выбрать строки файла передачи данных
Начать цикл по строкам файла передачи данных
Прочитать строку файла передачи данных
Получить из строки файла передачи данных код договора
Найти по коду соответствующий элемент в справочнике «Договоры контрагентов», если элемент не найден, то выдать сообщение « Не найден договор с кодом …»
Если элемент найден, то добавить строку в таблицу значений, где: «Договор» — найденный элемент, «Дата» — «Data_plat», «НомерПлатежа» — «Nomer_plat», «Сумма» — «Summa_plat»
После получения последний строки файла передачи данных окончить цикл
Для каждой строки таблицы значения создать документ «Платежное ордер поступление денежных средств».

Заполняя бриф или составляя тз на дизайн сайта, не оставляйте в нём пробелов.

Вы должны понимать, что “На усмотрение разработчика” означает “что хочу, то и ворочу” или же “Всё, что не оговорено, выполняется на усмотрение исполнителя”. И поверьте, это не просто лазейка, а целое окно в Европу для разработчика.

И конечно, так происходит не всегда.

Если Вам попался грамотный специалист, то можно не волноваться за результат.

Но тут возникает другая проблема, он может сделать реально как надо, а Вам не понравится чисто субъективно. И всё будет как в известном для многих разработчиков анекдоте:

КОРОТКО О ГЛАВНОМ

Вы точно не пожалеете о времени, потраченном на составление и согласование технического задания для создания сайта или лендинга.

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

При нажатии на тот или иной округ должно переходить на страницу с текстовым описанием данного округа.

· Блок «Блог Председателя» — должен представлять собой список из трех последних тем, созданных в блоге в виде названия темы и даты ее публикации. Название темы будет являться ссылкой, при нажатии которой должно перевести на страницу блога с описанием данной темы. Также в данном блоке должно размещаться видео, которое можно воспроизвести, не покидая главную страницу. У видео должна быть ссылка «Комментарии», представляющая собой количество комментариев к данному видеоизображению. Ссылка «Комментарии» должна вести на страницу блога с комментариями к представленному видео.

Нижний колонтитул должен содержать поле для поиска, информацию об авторских правах и т. д.

2.3.

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

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

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

Если отдельные пункты вызывают затруднения, то не стесняйтесь задавать разработчику вопросы по типу “Что это значит?”, “Как это повлияет на работу моего сайта?”, так как не все разработчики под одним понимают то же самое, что и Вы.

Либо в графе “Дополнительная информация” обязательно укажите все Ваши пожелания, не вошедшие в ответы на вопросы.

Если эта графа отсутствует, просто допишите их в конце брифа.

VK, Google, Facebook.

3.2.2 В личном кабинете в разделе заказы добавить поле для добавления промо-кода.

3.2.3 Вместо страницы, которая приходит пользователю после запроса на восстановление пароля (вида name.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=) сделать страницу (вида name.com/login/forgot/сhange_password=yes&lang=ru&USER_CHECKWORD=), которая будет отображать контент сайта, будет иметь поле «Email при регистрации», контрольная строка, новый пароль, подтверждение пароля, кнопка отправить данные.

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

3.2.5 Добавить вывод сообщения о том, что пароль не соответствует параметрам без-опасности при регистрации нового пользователя.

Автоматизированная система «СБЫТ». Техническое задание На листахДействует с «__» ____________ 2010 г.

» _» ______________ 2010 г.

Постепенно изменения вошли в релиз, а позже позволили создать новый продукт для оптовых, розничных магазинов и гипермаркетов - RegionSoft Retail.

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

Если там написана каша - возможно, стоит бежать и не оглядываться.

Застраховаться от недобросовестности исполнителя. Когда сайт готов, его можно проверить по техническому заданию. Есть несоответствия? Разработчик обязан их исправить. Если вы сотрудничаете официально и заключали договор - можно даже принудить через суд.
Упростить замену исполнителей. Если клиент и разработчик повздорили и разбежались, создание сайта может сильно затянуться. Когда есть подробное техзадание, его можно передать новой команде - она втянется в работу в разы быстрее.
Узнать стоимость разработки сложного продукта. Оценить точные сроки и стоимость разработки сложного веб-сервиса сходу нельзя. Сначала нужно понять, как будет работать сервис, и какие в нем будут функции.

Имеется root-доступ, собственные IP-адреса, порты, правила фильтрования и таблицы маршрутизации.

Google PageSpeed Insights - это бесплатный сервис рекомендаций для веб-сайтов по ускорению отображения страницы в браузере пользователя (https://developers.google.com/speed/pagespeed/insights/).

Поисковая оптимизация (или SEO) - комплекс мер по внутренней и внешней оптимизации для поднятия позиций сайта в результатах выдачи поисковых систем по определённым запросам пользователей.

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

Внутренняя оптимизация сайта - это оптимизация текста, URL-адресов, редактирование структуры сайта, перелинковка, проверка ответов сервера.

Имеющиеся материалы Ссылки на понравившиеся сайты, а также буклеты, журналы, фотографии – что угодно, а может быть у Вас есть готовый бренд-бук. Прилагается отдельным архивом. Минимальное разрешение и устройства отображения В этом пункте укажите, с каких устройств предполагается просматривать сайт – ПК, ноутбуков, смартфонов… Мониторы ПК от 19 до 27 дюймов; Ноутбуки от 15,6 до 17,3 дюйма; Смартфоны от 3,5 до 6 дюймов; Планшеты от 7 до 12 дюймов Нужна ли мобильная версия? Да ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ Примерный набор модулей (для пользователей) В этом разделе нужно перечислить все функциональные возможности, которые Вы хотите видеть на сайте.

Это может быть корзина, фильтры каталога по разным параметрам, возможность сделать онлайн-заказ, оставить заявку на обратный звонок, подписаться на рассылку и любые другие опции Фильтры каталога по цене, по алфавиту, по производителю.
CRUпtCj9B:s»XVжб╟▌╤└u╟J_■Е╘Dj»J■╛EХHJя(гTT┬Пб╟▌╤└u╟╛#╜┘al+Кa Кqяk3┴i≈²&F╒#┐╜╙┐█ц╜IWA▓BOЬ└vOЗб╟▌╤└u╟╛#╜┘al+КaXG[ б:ьVжб╟▌╤└u╟╛#╜┘al+КaXG[ б:ьVжб╟▌╤└u╟╛#╜┘al+КaXG[ б:ьVжб╟▌╤└u╟╛#╜│ц&V█7┬м3aqNYJy╕°Vжб╟▌╤└u╟╛#╜┘al+КaXG[ б:ьVжб╟▌╤└u╟╛#╜┘al+КaXG[ б:ьVжб╟▌╤└u╟╛#╜┘al+КaXG[ б:ьVжб╟▌╤└u╟╛#╜┘al+КaXG[ б:ьVжб╒▀┬y╥XuF≈≈K&ОQТё╦▒’%[н╓≥Lк"[Ц{б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~у╚б╖~у╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚б╖~ы╚бD’═\┘*NлkZ⌡┐©Tw╦|╒T⌠ZZA╙┼r≤⌠ьЧ≈Д7и$╔≥ Ы∙?ЬjЛ?Ч╜∙╤SQ≥╒°еHФх═с┬├6ыCЫиЪ╖Bl╢╡LэOь/РЯE∙rrмVC╪┬7┴+iSo(╦°rБ╒┴■Е4СЦг┬╨ з╖ ┘╤m°с÷Уm╦Wыmdр’%R^&╔gt╖yхDА]zт╪L╝i▌▀s_2╫J)Э+Ч©OлM²K%j ┼╖`СsА≈K▐ф²Yч▐Hd╟Fг╬lн∙╥е#⌡и<ТC▐╡И&d╨JГ!─Sj║·K,s┼#m ╓⌡JГн IOLЬ©h?ОeН╡▐┌ъHЙmwд$©aЗ$ёу°Н≤gт.bZ┐}Э1црn▄т≈фГ?TA<э:р▓T<кГ║2ic╖▀Иqf⌠Pсс▀32нЫ╘▌n-«÷0i╦▓Q:⌠^%5#⌡Н⌡│ вЬ└%N╙Оtб}8яца╨з≤[╖┐╕■╡╒4╞▄G√≥оЖNa╡vсM╔)9╘д≈ib╕╝■ i├{≈²5╨∙∙╣ф╒▓Цz²┌Ф╤I√HaО2┬б=└Б╦F∙P»гЙz&╔Р3{ ёS÷_н_g7⌡г$Н╜чk┐(ЗQэH▓З╨?.

Если пройтись по зарубежным сайтам с запросом «product requirements document», то можно найти креативные и убедительные статьи про то, что техническое задание (ТЗ, PRD) умерло. Отчасти с этим нужно согласиться - при разработке продукта с нуля прототипирование выглядит гораздо интереснее и эффективнее, чем тома записей заказчика, порой ну очень непрофессиональные. Однако, если речь идёт о доработке базовой системы, то дело принимает совершенно другой оборот. Мы сталкиваемся и с доработкой, и с заказной разработкой, поэтому на ТЗ собаку съели, если повар нам не врёт. В общем, сегодня - о тех самых классических технических заданиях, которые пишутся на доработку купленного и установленного программного обеспечения. Короче, о наболевшем.

Грани взаимодействия

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

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

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

Возможности - если кратко, то это то, что реально может сделать вендор (исполнитель). Рассмотрим на примере нашей RegionSoft CRM . Клиент покупает систему и составляет техническое задание на доработку: нужно создать интеграцию с сайтом и привязку событий в CRM к номеру заказа интернет-магазина. Это реально исполнимое требование, у нас есть ресурс и возможность сделать это. А ещё нужно разработать и прикрутить к CRM CMS, систему управления контентом сайта. Теоретически мы это можем, но у нас нет возможности это сделать дёшево, а у клиента нет возможности заплатить нам столько, чтобы мы перекинули на задачу человеческие и временные ресурсы. В итоге от этого требования заказчик отказывается - да и CMS ему не особо нужна, всё и так хорошо. Но о «жадности» ТЗ- позже.

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

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

Сбор и анализ требований

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

Он находится здесь уже целый час и даже не притронулся к белой маркерной доске. Он не настоящий системный аналитик

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

Есть очень простая схема сбора требований.

Создайте рабочую группу из руководителей и опытных специалистов подразделений, которые будут пользоваться CRM. Расскажите о решении, которое предполагается выбрать, предоставьте доступ к демо-версии.
Члены рабочей группы должны передать информацию сотрудникам и запросить у них пожелания к новой программе в абсолютно свободной форме. Если кто-то из сотрудников никогда не сталкивался с подобным софтом и не готов говорить в аспекте будущего использования, нужно попросить его описать свои периодические задачи, это универсальный подход.
Затем каждое подразделение устанавливает, чего нет в CRM или чему она не соответствует, и агрегирует информацию.
Рабочая группа анализирует собранные требования, проверяет и исключает пересечения. Например, нередко отдел продаж и отдел маркетинга заказывают один и тот же отчёт, но в требованиях могут по-разному называться поля и сущности, хотя данные за ними стоят одинаковые. Соответственно, нужно придти к единой форме.
Рабочая группа формирует список требований и расставляет приоритеты. На этом этапе можно подключить вендора, поскольку он отвечает за ресурсы. Например, можно попросить создать пользовательский отчёт для RegionSoft CRM, а можно заказать интеграцию с сайтом. Это совершенно разные по срокам задачи, здесь очень важен приоритет.

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

Анатомия технического задания

Выявление - определение требований, поиск проблем, которые необходимо решить.
Анализ - разбор требований, выделение ключевых потребностей, обобщение.
Адаптация - оценка требований в контексте возможностей CRM и существующих бизнес-процессов.
Документирование - формальное и подробное описание требований, согласование ТЗ.
Общение с вендором (разработчиком) - итеративное взаимодействие с вендором по поводу доработок согласно составленному ТЗ.
Реализация - работа вендора над созданием необходимой функциональности. Лучше, если вендор будет постоянно на связи с заказчиком - так продукт на выходе будет наиболее точно соответствовать видению клиента.
Тестирование - проверка функциональности сотрудниками вендора, внутренними экспертами клиента и конечными пользователями с целью установления соответствия доработки и ТЗ, работоспособности системы с изменениями.

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

Уровень бизнеса - самый глобальный уровень, на котором решаются сложные и приоритетные задачи. К этому уровню можно отнести интеграции, доработки и моделирование бизнес-процессов, разработку новых функциональных модулей. Как правило, это ресурсоёмкая разработка, с серьёзными консультациями и тесной совместной работой с заказчиком. Например, в своё время в RegionSoft CRM такой заказной доработкой были складской учёт, касса и производство. Постепенно изменения вошли в релиз, а позже позволили создать новый продукт для оптовых, розничных магазинов и гипермаркетов - RegionSoft Retail .

Уровень пользователя или группы пользователей. На этом уровне реализуются задачи по доработке существующего интерфейса. Например, пользователь может захотеть, чтобы при наведении курсора на клиента появлялось окошко со номером и статусом последнего заказа или существовал кастомный отчёт с особой группировкой данных. Доработки на этом уровне занимают меньше времени, но их может быть много - например, несколько требований от отдела маркетинга, логистики и технической поддержки.

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

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

Уровень технологии - последний в списке, но по важности и сложности опережающий остальные. Это могут быть требования клиента, связанные с платформой, операционной системой или устройствами. Например, запрос сборки под MacOS. Очень здорово, если такие требования постепенно перерастут в релизы, но иметь их фиксы обязательно. Именно из запросов клиентов на этом уровне мы сделали сборку RegionSoft CRM под MacOS и добавили удалённый доступ по технологии TRM как временное решение редкого, но существующего запроса мобильной версии.

Анатомия технического задания проста, во всяком случае в виде скелета. Обязательные части технического задания помогают заказчику сосредоточиться на проблеме и сформулировать задачу правильно, а исполнителю - понять, что же от него хотят. Кстати, о понимании. Конечно, в начале поста мы немного слукавили, отрицая бизнес-консультантов как класс. Дело вот в чём: каждый вендор работает на рынке по несколько лет (мы сейчас не о CRM-однодневках), а то и десятков лет, а значит имеет набор кейсов практически по каждой отрасли. Соответственно, и инженеры, и программисты, и продажники знакомы со спецификой внедрения в каждом типе компании. Но опять-таки, важно ориентироваться именно на свой бизнес.

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

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

Зачем? Обоснование необходимости доработки и его место в бизнес-процессе. Этот пункт больше нужен самому заказчику, но и вендору нелишне знать, какие ещё процессы будут затронуты. Иногда это помогает найти альтернативное решение.

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

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

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

Описание реализации данной функциональности

Стоимость работ по каждому из этапов в отдельности

Общая стоимость работ по данному техническому заданию

Сроки исполнения работ с разбивкой по этапам и указанием очерёдности

Описание условий установки и тестирования доработки

Оговорки об исчерпывающем характере технического задания и иные условия

10 правил, написанных слезами разработчика

Техническое задание на доработку должно быть ТЗ на доработку , а не 300-страничным описанием CRM, которая необходима клиенту. Перед составлением требований следует внимательно ознакомиться с интерфейсом системы, её возможностями, документацией - скорее всего, большая часть «хотелок» уже есть в базовой поставке. Вторым шагом я бы рекомендовал обратить внимание на встроенные инструменты доработки (дизайнеры отчётов, конфигураторы и проч.) - возможно, нужные изменения сможет внести штатный программист (во многих компаниях они есть).

Техническое задание не должно быть жадным. Нередко бизнес переоценивает свои возможности или желает получить «всё и сразу». Такой подход не оправдан ни с точки зрения денег, ни с точки зрения бизнеса. Вендор, как правило, существует не пару недель (в случае RegionSoft - 15 лет), и к нему можно обратиться и через некоторое время, когда вы уже реально поймёте, чего в CRM не хватает.

Яркий пример избыточности буквально из вчерашнего дня: клиент купил ERP одной известной российской компании, думая, что раз работает бухгалтерский учёт, то и ERP этого вендора будет хороша. ERP оказалась не то чтобы не очень сама по себе, но очень не подходящей бизнесу. А вот RegionSoft CRM со складским учётом и производством подходит. Есть решение: забыть про ERP, поплакать, интегрировать учёт 1С с новой CRM и радоваться удобной реализации. Но вбуханных денег жалко! И клиент требует интегрировать CRM с ERP. Мы и не такое делали, но зачем такая трата, зачем две относительно схожих системы?

Техническое задание должно быть реалистичным и выполнимым - как по требованиям, так и по срокам. Здесь важно прислушиваться к мнению вендора, поскольку он точно знает, какое время уйдёт на ту или иную задачу. Поверьте, разработчику не выгодно тянуть время и накручивать срок - ему выгодно завершить как можно больше проектов и сделать это хорошо, чтобы не получить удар по репутации. Что касается реалистичности, то избежать просьб допилить CRM до уровня системы управления коллайдером просто: следует включать в требования то, что действительно нужно на данный момент и в обозримом будущем.

Не нужно путать с ситуацией, когда речь идёт о заказной разработке и в корне меняется идея и логика работы приложения, фактически спонсируется создание нового программного обеспечения «под себя». Но это другая история.

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

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

Да, корпоративный софт выглядит примерно так, и в нём много важных мелочей

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

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

Техническое задание должно быть написано на человеческом языке. И это важно, нет, ВАЖНО. Выделю две ситуации, когда проблемы с языком приводят к затягиванию реализации проекта.

Клиент пытается продемонстрировать свою техническую грамотность и городит конструкции типа: «имплементировать окно с хинтом в тело календаря с возможностью реакции на колл события…» вместо «в календаре должно всплывать окно, в котором можно отметить задачу как выполненную». Если у вас или вашего внутреннего эксперта нет навыков написания технических текстов, не гуглите - пишите обычными словами, мы их понимаем.
Техническое задание не должно быть жалобной книгой. Нужно решать проблему, а не описывать её, уделяя внимание шрифтам и забывая об описании требований. ТЗ должно содержать не только саму проблему, но и её решение на уровне осмысления - далее разработчик уже решит её на уровне кода. Сравните «отдел продаж плохо планирует, теряет цифры, уже год боремся» и «необходимо создать отчёт, который будет сохранять значения плана и факта продаж ежемесячно, в разрезе групп номенклатуры» .
Техническое задание должно уметь смотреть в будущее. Ну не совсем оно, а люди, стоящие за ним. Если известно, что в скором времени будут происходить изменения в бизнес-процессах, это нужно обязательно учитывать, чтобы не платить за доработку дважды.
Техническое задание не должно быть бюрократичным. Если вы хоть раз составляли этот документ, то наверняка ощущали, как тяжело избежать соблазна скатиться в бюрократию, наворотить вводных слов, строгих оборотов и описать каждый пункт как статью Уголовного кодекса (желательно с наказанием всем за нарушение). Бюрократические формулировки маскируют неполное понимание целей создания ТЗ. Ответственность вендора прописана в договоре, там же написан бюджет. Не стоит переносить эти моменты в техническое задание.
Техническое задание должно быть техническим заданием. Звучит парадоксально, но часто вместо ТЗ мы читаем письма, жалобы, договоры, заново написанную инструкцию к CRM или протокол совещания. Конечно, работать по такому документу невозможно. Для того, чтобы не уйти от формы и содержания, воспользуйтесь старой школьной уловкой: рассмотрите термин по словам. Техническое - значит, диктует доработку, технику, направлено на решение задачи посредством изменения ПО. Вот о задаче в контексте ПО и нужно говорить. Задание - значит, постановка вопроса, проблемы, без советов, подсказок и предварительных оценок. Просто формулировка задачи.
Заповеди закончились, теперь отповедь
Кроме перечисленных правил, есть ещё несколько вещей, о которых стоит рассказать. Речь идёт о целях, планах и ожиданиях - всех тех оставляющих, которые делают проект успешным, а отношения вендора и клиента почти дружескими.
Техническое задание нужно писать быстро , даже если перед вами стоит задача автоматизации процессов сотового оператора или крупного гипермаркета. Это связано с тем, что технологии развиваются с огромной скоростью и даже та система, которую вы внедряете, за полгода-год может пережить мажорный релиз (а иногда и два), получить новую функциональность. Возможно, придётся пересмотреть необходимость доработок и начать процесс заново.

Наконец он нашёл время закончить ТЗ. Но, увы, вокруг не осталось разработчиков, чтобы его реализовать.
Клиент не знает о стеке и технических ограничениях. И знать не должен - это задача вендора, именно он оценивает работы после составления технического задания. Заказчику не стоит углубляться в технологии и на каждой запятой спрашивать, сможет ли вендор сделать ту или иную вещь. Составьте комплексное ТЗ и разработчик выберет подходящую архитектуру - нередко даже лучшую, чем вы могли подумать.
Оценить бюджет и избежать неприятных сюрпризов - едва ли не совместная задача номер один. Не стоит дёргать вендора и требовать от него примерной оценки работ (ну хоть приблизительно, навскидку, на глазок, а как у других, ну в проектах такого типа, а по опыту, ну так, в пределах погрешности). Полная оценка бюджета возможна только после прочтения, анализа и окончательного утверждения технического задания. Если ваш разработчик поступает иначе - готовьтесь к тому, что доработка обойдётся минимум в два раза дороже.
Исходите из объективной необходимости изменений и расширений - выше я писал, что разработчик не исчезает и готов внести изменения и дополнения по вашим требованиям в любой момент. Поэтому не пытайтесь создать CRM/ERP мечты сразу, не требуйте от вендора кнопку «Всё работает, пока я пью кофе» - поработайте в системе, определите критичные для вас замечания и приступайте к сбору требований и составлению ТЗ.
О технических заданиях можно писать бесконечно, это настоящий генератор не только мемов и баек, но и головной боли. Можно рассказать о приоритетах и правилах оформления, о ГОСТе 1989 года, который делает ТЗ бесчеловечным, о стандартах IEEE, которые немного лучше, о прототипах и дополняющих их ТЗ. Но в конце хотелось бы ограничиться одним, самым главным правилом: техническое задание - не норма права, не ГОСТ и не догма, поэтому, если можно улучшить - улучшайте, можно упростить - упрощайте, можно сделать изящно и чтобы всем нравилось - делайте. Уверен, никто после такого не ткнёт носом в ТЗ и не скажет, что там такого не написано. Или почти никто.
Весь декабрь мы даём скидки на RegionSoft CRM и весь софт собственной разработки. С 1 по 15 декабря - 15% и крутые условия рассрочки и аренды. У нас не бывает -70% и -90%, потому что мы держим экономически обоснованную цену на лицензии, а не берём её с потолка.
Ну а если вам нужна CRM-система (с доработкой или без), то заходите на наш сайт , там много о CRM, её преимуществах и прочем корпоративном софте.
И да, мы всегда ищем партнёров, которые готовы продавать CRM и другие продукты, дорабатывать и продавать CRM, продавать софт и обучать пользователей. Разделение доходов честное и выгодное партнёру. Покажем, расскажем, научим. Пишите на [email protected]
Слайды, слайды. Комиксы взяты с http://www.modernanalyst.com/ и из Pinterest. Если есть лучший перевод - будем рады его внести в пост.

С точки зрения ГОСТов*, в которых регламентирована деятельность по разработке программного обеспечения и автоматизированных систем (АС) – это основной документ, определяющий требования и порядок развития или модернизации (далее – создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие.

*ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению;
ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

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

Зачем нужно техническое задание

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

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

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

Кто разрабатывает техническое задание

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

Типовые ошибки при разработке технического задания

Документ базируется на ГОСТ 34.602-89, дающий формализованную структуру, но не имеющий четких требований к изложению разделов и пунктов. Эта особенность стандарта - его сила и его слабость. Свобода изложения может привести к тому, что требования разделов (особенно функциональные):

Излагаются не системно, без привязки к какой-либо структуре (модули системы, бизнес-процессы);
Дублируются;
Относятся к различным уровням детализации.

Допущение ошибок при составлении технического задания приводит к увеличению стоимости и продолжительности проекта. Основная задача технического задания – оформить требования заказчика в понятном и возможном к реализации формате.

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

Излишняя детализация;
Требования, противоречащие друг другу;
Неточные формулировки.

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

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

Как избежать ошибок при составлении ТЗ

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

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

Руководствоваться нужно следующими правилами:

Формирование ТЗ – это совместная работа исполнителя и заказчика;
Риски исполнителя должны быть минимизированы и не должны превышать аналогичные для заказчика (иначе это приведет к увеличению стоимости проекта);
Требования формируются объективными, использование субъективного виденья заказчика не рекомендуется;
Не допускается использование терминов, принятых в широком деловом общении, но противоречащих принятым в отрасли и стандарте;
Основное внимание уделяется описанию результатов, требуемых заказчиком. Например, заказчику необходимо получать отчет о движении товара в соответствующих аналитических разрезах, тогда в ТЗ должны быть подробно описаны параметры отчета (строки, аналитика, период, за который составляется отчет) и источники данных для его формирования. Самое главное здесь – не допустить расширенного толкования технического задания, иначе, если вы не указали период или источник данных, конечный результат может сильно отличаться от требований заказчика, а доработка потребует дополнительных средств и времени.

Разработка, например, «правильного» ТЗ программисту 1С, подразумевает полное погружение в тему, знание всех ее аспектов и тонкостей. ТЗ должно давать ответ не только на вопрос «что должен сделать программист», но в первую очередь – «какие задачи должна решать система 1С:Предприятие после выполнения работ». Требования должны быть сформулированы подробно, но без лишней информации. Это уменьшит вероятность появления неточностей и ошибок. Именно поэтому привести универсальный пример технического задания 1С не представляется возможным – каждый случай ТЗ на разработку 1С уникален.

Многие сталкиваются с тем, что достаточно сложно объяснить коротко и ясно то, что мы хотим в повседневной жизни. А уж когда надо дать задание специалисту написать программу для организации или ИП с учетом особенностей и собственных пожеланий по функционалу, то можно вообще «зависнуть».

Кто должен писать ТЗ?

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

Для чего необходимо техзадание?

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

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

Составлять ТЗ или нет - решает каждый для себя, но это точно не будет лишним: упростит общение с клиентом и придаст работе деловой и конкретный характер.

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

1. Цель/Задача. Сформулировать то, что должно быть реализовано в конечном итоге.

2. Описание. Вкратце изложить содержание планируемых доработок.

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

4. Оценка работы. Данный пункт очень важен - в нем нужно описать трудозатраты.

Еще два важных момента: есть утвержденные стандарты к написанию ТЗ - ГОСТы. Сейчас они редко используются, но некоторые клиенты могут по старинке просить использовать и их.

И второе, когда сдается работа может возникнуть и такое - «а мы же вроде как просили Вас сделать то-то и тогда-то...». Есть вероятность, что придется все начать делать с самого начала.

Поэтому, повторимся, что грамотно составленное ТЗ будет полезно как для заказчика, так и для исполнителя.

Пример ТЗ для программиста

Техническое задание 1С на доработку внешней обработки

Цель
Необходимо настроить выгрузку данных из 1С в АРМ банка.

Описание

В связи с переходом организации на конфигурацию 1С «Зарплата и кадры государственного учреждения» требуется разработка других обработок, которые осуществляли бы аналогичный функционал на новой конфигурации.

Выгрузка данных должна основываться на документах «ЗаявкаНаОткрытиеЛицевыхСчетовСотрудников» и «ВедомостьНаВыплатуЗарплатыВБанк».

Исходные данные

Имеющаяся обработка к конфигурации 1С «Зарплата бюджетного учреждения», осуществляющая выгрузку данных из документа «ЗаявкаНаОткрытиеЛицевыхСчетовСотрудников» и других справочников и регистров в файл DBF обмена данными с АРМ банка установленного образца.

Обработка выгружает данные в поля TAB_N, NAME, SERNUM, PASSCODE, PDAT, PWHR, BIRTHDAY, POSTINDEX, COUNTRY, CITY, STREET, REGION, BUILDING, CORP, FLAT, BPLACE, CITIZEN соответствующую информацию из конфигурации 1С, предварительно занесённую в указанный документ и другие учётные таблицы. Выгружаются табельный номер, ФИО сотрудника, его паспортные и адресные данные, день рождения и гражданство.

Способ реализации

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

Оценка работы

Потребуется 5 рабочих дней работы программиста.

ТЕХНИЧЕСКОЕ ЗАДАНИЕ
НА МОДЕРНИЗАЦИЮ САЙТА

Екатеринбург

1. Основания для разработки Сайта. 3

1.1. Полное и краткое наименования информационной Системы.. 3

1.2. Наименование заказчика системы и его реквизиты.. 3

1.3. Перечень документов, на основе которых создается Система. 3

1.4. Плановые сроки начала и окончания работ по созданию Системы.. 3

2. Требования к системе. 4

2.1. Модернизация официального интернет-сайта Следственного комитета при прокуратуре Российской Федерации (далее – Сайт СКП). 4

2.2. Главная страница. 5

2.3. Типовая внутренняя страница. 8

2.4. Требования к модулю размещения новостных сообщений. 9

2.5. Требования к модулю формирования и отображения списка документов. 11

2.6. Требования к модулю отображения списков (каталог) 11

2.7. Блог. 13

2.8. Фотогалерея. 16

2.9. Видеоплеер. 16

2.10. Метки. 16

2.11. Требования к модулю сбора и аналитики данных о статистике посещений интернет-сайта 16

2.12. Требования к модулю поиска. 17

2.13. Требования к модулю «Официальные лица». 18

2.14. Требования к модулю «Карта сайта». 20

2.15. Требования к модулю «Сбор обращений пользователей». 20

2.16. Требования к управлению ресурсом.. 21

2.17. Требования к техническому обеспечению.. 22

2.18. Требования к унификации и стандартизации . 22

2.19. Разработка эксплуатационной документации. 22

2.20. Организация и проведение обучения специалистов Следственного комитета при прокуратуре Российской Федерации. 23

3. Кольцо сайтов. 24

3.1. Общие требования. 24

3.2. Текстовая страница. 25

3.3. Новости. 26

3.4. Вопросы и ответы.. 28

3.5. Архив файлов. 29

3.6. Форма сбора обращений. 30

3.7. Карта сайта. 30

3.8. Требования к механизму создания и удаления сайтов. 31

3.10. Требования к дизайну. 31

3.11. Требования к языковой поддержке. 31

3.12. Развитие единой программной платформы сайта СКП.. 31

3.13. Требования к результатам проведенных работ. 32

1. Основания для разработки Сайта

1.1. Полное и краткое наименования информационной Системы

Краткое наименование системы – «Сайт СКП», «Система», «Сайт».

1.2. Наименование заказчика системы и его реквизиты

Наименование: Следственный комитет при прокуратуре Российской Федерации

Место нахождения: г. Москва, Технический переулок, дом 2

Фактический адрес: А

Контактное лицо Заказчика:

Телефон: (4, (4;

Адрес электронной почты

1.3. Перечень документов, на основе которых создается Система

Государственный контракт №________________ от ___ ___________ 2010 г.

1.4. Плановые сроки начала и окончания работ по созданию Системы

Определяются в соответствии с Договором.

2. Требования к системе

2.1. Модернизация официального интернет-сайта Следственного комитета при прокуратуре Российской Федерации (далее – Сайт СКП)

В рамках модернизации необходимо осуществить:

· Редизайн главной страницы Сайта СКП, в том числе должна быть осуществлена перегруппировка существующих блоков на Главной странице;

· Создание отдельного блока на Главной странице «высказывания представителей власти и СМИ, о работе Следственного комитета». Раздел должен быть реализован в виде датированного списка с возможностью прикрепления картинок;

· Настройку шрифтов предлагаемых Системой по умолчанию для различных типов текста: для заголовков и основного текста;

· Реализацию возможности замены графических элементов соответствующим текстом (в случае отключенной возможности на стороне пользователя загрузки картинок);

· Оптимизация страниц Сайта СКП по объему данных;

· Адаптацию Сайта СКП к новому дизайну;

· Оптимизацию безопасности кода с целью предотвращения возможных внешних атак;

· Актуализацию главного меню, включая следующие изменения:

Создать раздел «О Следственном комитете»;

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

Создать раздел «Блог Председателя»;

В разделах с большим объемом текста («Интервью», «Публикации» и «Нормативная база») упорядочить информацию по годам.

Структура сайта центрального аппарата

· Главная

· О комитете (текстовая страница)

· Руководство (модуль «Каталог»)

Ø Список руководителей (подраздел каталога)

o Описание должностного лица (текстовая страница)

· Структура (текстовая страница)

· Нормативная база (текстовая страница)

· Новости (модуль «Новости»)

Ø Список новостей (подраздел)

o Описание новости (текстовая страница)

· Правовая информация (текстовая страница)

· Служба в системе (текстовая страница)

· Противодействие коррупции (модуль «Каталог»)

Ø Мероприятия и документы

o Список мероприятий (подраздел)

§ Описание мероприятия (текстовая страница)

Ø Расследование преступлений коррупционной направленности

o Список событий (подраздел)

§ Описание события (текстовая страница)

· Блог (модуль «Блог»)

· Версия для слабовидящих (модуль «Версия для слабовидящих»)

· Порядок рассмотрения обращений и приема граждан (текстовая страница)

· Следственные органы по субъектам РФ (текстовая страница)

· Печатные издания (модуль «Каталог»)

Ø Вестник СКП № 4 (подраздел)

Ø Вестник СКП № 3 (подраздел)

o Описание номера (текстовая страница)

· СМИ о Следственном Комитете (модуль «Новости»)

Ø Список публикаций (подраздел)

o Описание публикации (текстовая страница)

· Взаимодействие со СМИ (модуль «Каталог»)

Ø Список подразделов (подраздел каталога)

o Описание подраздела (текстовая страница)

· Интервью (модуль «Новости»)

Ø Список интервью (подраздел)

o Описание интервью (текстовая страница)

· Карта сайта (модуль «Карта сайта»)

2.2. Главная страница

Помимо идентификационных элементов и элементов дизайна главная страница сайта должна содержать следующие элементы:

· Главное меню

Главное меню сайта - постоянный элемент каждой страницы сайта. Меню должно иметь следующие ссылки:

ü О комитете

ü Руководство

ü Структура

ü Нормативная база

ü Новости

ü Правовая информация

ü Служба в системе

ü Противодействие коррупции

Сетка главной страницы представлена на рис. 1.

Актуально" в системе администрирования, то есть, если этот флаг взведен, то новость поместится в блок "Актуально" и находится там, пока этот флаг не снимут.

· Блок «Высказывания представителей власти и СМИ» - должен представлять собой датированный список с ФИО представителя власти или СМИ, его должности, изображением и цитатой.

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

· Блок «Следственные органы по субъектам РФ» - должен представлять собой флэш-изображение карты России с разделением по федеральным округам. При нажатии на тот или иной округ должно переходить на страницу с текстовым описанием данного округа.

· Блок «Блог Председателя» - должен представлять собой список из трех последних тем, созданных в блоге в виде названия темы и даты ее публикации. Название темы будет являться ссылкой, при нажатии которой должно перевести на страницу блога с описанием данной темы. Также в данном блоке должно размещаться видео, которое можно воспроизвести, не покидая главную страницу. У видео должна быть ссылка «Комментарии», представляющая собой количество комментариев к данному видеоизображению. Ссылка «Комментарии» должна вести на страницу блога с комментариями к представленному видео.

Нижний колонтитул

Нижний колонтитул должен содержать поле для поиска, информацию об авторских правах и т. д.

2.3. Типовая внутренняя страница

Сетка типовой внутренней страницы представлена на рис. 2

Рис. 2. Типовая внутренняя страница.

Назначение:

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

2.4. Требования к модулю размещения новостных сообщений

Модуль размещения сообщений должен обеспечить:

· размещение новостных сообщений на интернет-сайтах, публикуемых в хронологическом порядке (новостных лент);

· вывод на страницах интернет-сайтов список новостей и их полные тексты;

· поиск по архиву новостей;

· экспорт новостей в формат RSS 2.0.

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

Модуль должен представлять собой двухуровневую архитектуру, представленную в виде списка всех новостей и описание каждой новости.

Список новостей должен быть представлен в виде названия новости и даты ее публикации (рис. 3)

https://pandia.ru/text/78/390/images/image005_109.jpg" width="646" height="525 src=">

Рис. 4. Сетка страницы «описание новости».

2.5. Требования к модулю формирования и отображения списка документов

Модуль формирования и отображения списка документов должен позволять:

· организовывать публикацию документов на страницах сайта в виде списка с возможностью постраничного разбиения и сортировкой по дате публикации;

· администратору и контент-менеджеру интернет-сайтов выполнять следующее:

o просматривать список документов,

o добавлять новые документы,

o редактировать и удалять добавленные документы.

2.6. Требования к модулю отображения списков (каталог)

Модуль отображения списков должен обеспечить:

· отображение на страницах интернет-сайтов форматированных списков (список вакансий , список филиалов, список часто задаваемых вопросов и ответов на них и т. д.) в виде перечня ссылок на страницы элементов списка;

· предоставление администраторам и контент-менеджерам интернет-сайтов следующих функциональных возможностей:

o редактировать, добавлять и удалять элементы списка;

o создавать новые списки элементов;

o удалять существующие списки.

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

Рис. 5. Сетка подраздела каталога.

При нажатии на название одного из подразделов, должно открываться описание этого подраздела в виде внутренней типовой страницы .

Сетка «описание подраздела» представлена на рис. 6

https://pandia.ru/text/78/390/images/image008_83.jpg" width="625" height="526">

Рис. 7. Сетка страницы «список тем в блоге».

При нажатии на одну из тем должна открываться страница с полным описанием темы и комментариями к ней (рис. 8)

2.8. Фотогалерея

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

2.9. Видеоплеер

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

2.10. Метки

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

2.11. Требования к модулю сбора и аналитики данных о статистике посещений интернет-сайта

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

· ведение учета статистики в режиме онлайн и работу с данными непосредственно на сайте;

· проведение сбора и обсчета статистических данных при открытии посетителем каждой страницы без размещения кнопок, имиджей или дополнительного программного кода в теле страницы;

· выделение потоков посетителей по одному из критериев:

o список ссылающихся сайтов;

o поисковая система;

o страницы, на которые пришли;

o дополнительные параметры: страна, пользователь, IP-сеть и другие.

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

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

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

· анализ посещаемости сайта на общем графике по дням с представлением данных: хиты, сессии, посетители, хосты, новые посетители, события, избранное;

· анализ сводной статистики сайта, представляющей данные за прошедшие периоды следующих типов:

o события;

o посетители (новых, всего, добавивших в избранное, онлайн);

o Топ 10 наиболее активных типов событий на сайте;

o Топ 10 ссылающихся сайтов;

o Топ 10 наиболее популярных сегодня поисковых фраз;

o Топ 10 наиболее активных поисковых роботов за день.

· анализ ссылающихся сайтов; возможность анализа динамики по дням; учет встроенного модуля поиска как поисковой машины со всеми инструментами анализа;

· автоматическое определение запросов поисковых систем и роботов для пополнения таблицы поисковых машин;

· анализ динамики событий по дням и представление результатов в виде круговой диаграммы;

· анализ динамики событий по дням и представление в виде графика типов событий.

2.12. Требования к модулю поиска

Модуль поиска должен обеспечивать поиск страниц интернет-сайтов, содержащих заданные пользователем ключевые слова. Должно быть реализовано выполнение следующих функций:

· выполнение поиска как на выбранном интернет-сайте, так и по кольцу сайтов с учетом русской морфологии ;

· выполнение поиска одновременно в статическом наполнении сайта и динамической информации (новости, статьи, фотографии)

· использование языка запросов при формировании поискового запроса;

· использование логических операторов для сложных поисковых запросов;

· автоматическая индексация всех документов сайтов, которые публикуются через веб-интерфейс в виде статических HTML-страниц или через модули информационных блоков;

· сортировка результатов поиска.

2.13. Требования к модулю «Официальные лица»

Модуль «официальные лица» должен обеспечивать:

· ведение справочника официальных лиц следственных органов по субъектам Российской Федерации (уровень руководителя и заместителей руководителя территориального органа Следственного комитета при прокуратуре Российской Федерации).

· хранение информации о руководстве следственных органов по субъектам Российской Федерации в составе:

o должность,

o фотография,

o биография,

o датированный список (лента) публикаций и выступлений.

Модуль должен представлять собой иерархическую структуру подчиненности должностных лиц (рис. 9)

https://pandia.ru/text/78/390/images/image011_72.jpg" width="646" height="614 src=">

Рис. 10. Сетка страницы «описание должностного лица».

2.14. Требования к модулю «Карта сайта»

2.15. Требования к модулю «Сбор обращений пользователей»

Модуль должен обеспечивать функциональные возможности по сбору обращений граждан Российской Федерации с помощью специализированной формы, размещаемой на интернет-сайтах следственных органов:

· отправка результатов заполнения формы на e-mail ответственному сотруднику;

· сохранение данных формы в базе данных ;

· обеспечение защиты от автоматического заполнения формы путем ввода контрольного графического кода.

Сетка страницы с формой обращения пользователей представлена на рис. 11

Рис. 11. Сетка страницы «форма обращения».

Страница должна представлять собой форму, с расположенными на ней полями для заполнения «ФИО», «E-mail», «№ телефона», «Адрес» и «Текст сообщения». При заполнении этих полей, защитного кода и нажатии кнопки отправить информация должна отправляться в базу данных, а на E-mail сотрудника, ответственного за прием заявок, должно отправляться соответствующее письмо. Затем на экране в этом же окне пользователю должен представляться номер заявки, которую он отправил.

2.16. Требования к управлению ресурсом

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

· Единый интерфейс администрирования и управления наполнением интернет-сайтов;

· Редактирование информационного наполнения разделов и страниц выбранного интернет-сайта с помощью графического редактора;

· Управление разделами меню выбранного интернет-сайта;

· Управление структурой выбранного интернет-сайта;

· Ведение интерактивной карты разделов интернет-сайтов;

· Размещение новостных сообщений имеющих четкую привязку по времени;

· Ведение архива новостных сообщений, с возможностью поиска по дате публикации всех интернет-сайтов;

· Поиск информации по интернет-сайтам;

· Публикация документов на интернет-сайтах;

· Помещение для обучения предоставляется Заказчиком.

· Место и время обучения должно быть согласовано с Заказчиком.

Обучение должно проводиться по всей функциональности Системы.

3. Кольцо сайтов

Все функциональные возможности системы должны быть реализованы в рамках отдельных программных модулей за счет развития существующей платформы Сайта СКП. Совместное функционирование различных модулей Интернет-сайтов должно обеспечиваться ядром программного компонента «Кольцо сайтов». Модули, обеспечивающие заданные функциональные возможности, должны подключаться отдельно для каждого из интернет-сайтов, входящих в кольцо сайтов. Все программные модули, реализующие сервисы интернет-сайтов, должны использовать общие принципы функционирования вне зависимости от сайта, входящего в кольцо сайтов.

В качестве ядра программного компонента «Кольцо сайтов» должны использоваться программные компоненты интернет-сайта Следственного комитета при прокуратуре Российской Федерации

3.1. Общие требования

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

· Кольцо сайтов должно обеспечивать одновременное бесперебойное функционирование интернет-сайтов следственных органов Следственного комитета при прокуратуре Российской Федерации по субъектам Российской Федерации;

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

· Проектирование и разработка программных средств Кольца сайтов должно осуществляться с использованием принципов и подходов модульной архитектуры программных решений;

· Интернет-сайты кольца сайтов должны предоставлять доступ к информационным ресурсам следственных органов по субъектам Российской Федерации и возможность размещения регионально-привязанных информационных материалов;

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

Интернет-сайты кольца сайтов должны включать следующие типы информационных страниц:

· текстовые страницы;

· новостная лента;

· вопросы и ответы;

· архив файлов;

· формы сбора обращений;

· карта сайта.

3.2. Текстовая страница

Сетка типовой текстовой страницы представлена на рис. 12

Рис. 12. Сетка типовой внутренней текстовой страницы.

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

3.3. Новости

Сетка страницы ленты новостей представлена на рис. 13

Рис. 13. Сетка страницы «лента новостей».

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

При нажатии на название одной из новостей должна открываться страница с полным описанием новости (рис. 14)

Рис. 14. Сетка страницы «Описание новости».

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

3.4. Вопросы и ответы

Сетка страницы «вопросы и ответы» представлена на рис. 15

Рис. 15. Сетка страницы «Вопросы и ответы».

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

3.5. Архив файлов

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

https://pandia.ru/text/78/390/images/image018_31.jpg" width="646" height="505">

Рис. 17. Сетка страницы «Форма обращения».

3.7. Карта сайта

Модуль «Карта сайта» должен обеспечивать отображение информации о структуре разделов выбранного интернет-сайта.

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

3.8. Требования к механизму создания и удаления сайтов

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

3.9. Требования к информационному обеспечению

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

3.10. Требования к дизайну

Для интернет-сайтов входящих в состав кольца сайтов должен быть разработан единый дизайн страниц и элементов управления, соответствующий стилевой направленности и цветовому решению интернет-сайта Следственного комитета при прокуратуре Российской Федерации. Дизайн должен быть согласован с Заказчиком и предусматривать принадлежность интернет-сайта к соответствующему субъекту Российской Федерации.

Дизайн интернет-сайтов должен соответствовать современным требованиям к дизайну сайтов. Цветовая гамма кольца сайтов должна быть согласована с Заказчиком в рамках создания системы.

Дизайн интернет-сайтов кольца сайтов должен отвечать следующим стилевым характеристикам: строгий, деловой, лаконичный, эргономичный, информативный.

3.11. Требования к языковой поддержке

Интерфейсы кольца сайтов должны быть выполнены на русском и английском языках . Административные интерфейсы кольца сайтов должны быть выполнены только на русском языке.

3.12. Развитие единой программной платформы сайта СКП

В рамках развития необходимо осуществить:

· Информационное наполнение одного пилотного сайта кольца сайтов в объеме, достаточном для проверки всей функциональности Системы, которое должно быть осуществлено в рамках проведения обучения;

· Проведение опытной эксплуатации;

· Ввод в промышленную эксплуатацию.

3.13. Требования к результатам проведенных работ

1. программные средства Кольца Сайтов Следственного комитета при прокуратуре Российской Федерации

2. эксплуатационную документацию в следующем составе:

· Программа и методика испытаний;

· Руководство администратора;

· Руководство контент-менеджера;

· Руководство по инсталляции;

· Руководство программиста.

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

Статьи по теме