Эволюция веб-проекта — что не забыть предусмотреть в ТЗ. Пример технического задания сайта на битрикс
Типовой шаблон технического задания на разработку сайта / Хабр
Во многих студиях нет единого формата ТЗ, у нас его тоже не было. Просмотрев множество различных форматов и ГОСТов, мы выбрали самые значимые пункты и разработали типовой шаблон ТЗ для нашей компании. Возможно, это будет полезно и другим студиям, т.к. если мы все будем работать по единым стандартам плюсы очевидны как для студий, так и для заказчиков.
Структура технического задания: 1. Термины, используемые в техническом задании 2. Общие положения 2.1. Название сайта 2.2. Наименование предприятий (объединений) разработчика и заказчика (пользователя) сайта и их реквизиты 2.3. Перечень документов, на основании которых создается сайт 2.4. Состав и содержание работ по созданию системы 2.5. Порядок оформления и предъявления заказчику результатов работ по созданию сайта 3. Назначение и цели создания сайта 3.1. Цели создания сайта 3.2. Задачи, решаемые при помощи сайта 4. Требования к сайту и программному обеспечению 4.1. Требования к программному обеспечению сайта 4.2. Общие требования к оформлению и верстке страниц 4.3. Требования к численности и квалификации персонала обслуживающего сайт 4.4. Требования к системе администрирования 5. Структура сайта 6. Языковые версии сайта 7. Группы пользователей 8. Дизайн сайта 9. Навигация по сайту 9.1. Основное навигационное меню 9.2. Дополнительная навигация по сайту 10. Описание страниц сайта 10.1. Описание статических страниц 10.2. Описание динамических страниц 11. Функционал сайта 12. Контент и наполнение сайта 12.1. Формат предоставления материалов для сайта 13. Дополнительная информация 14. Порядок контроля и приемки работ 15. Реквизиты и подписи сторон
P.S. Данное ТЗ не претендует на единый формат, это не догма. Мы с удовольствием учтем все комментарии и замечания хабраюзеров.
Скачать шаблон ТЗ в формате .doc
habr.com
Техническое задание (тз) на разработку сайта
От автора: Как написать техническое задание (тз) на разработку сайта? Тема достаточно обширная, и в рамках одной заметки ее сложно разобрать на все 100% (если вообще это возможно). Но общие положения, о том что нужно учесть и на что следует обратить сое внимание при составлении тз веб-сайта, я постараюсь изложить достаточно подробно.
Итак, техническое задание на разработку сайта
Техническое задание составляется для разработчика. На тз нужно ссылаться при составлении договора между заказчиком и исполнителем. Должна быть оговорена ответственность за невыполнение или некорректное выполнение пунктов и сроков с обеих сторон. Но самое главное (на мой взгляд), для чего создается техническое задание, так это для ускорения процесса разработки проекта.
Предположим, что Вам на сайте, где-нибудь с боку нужен календарь. Казалось мелочь. Но чем подробнее вы опишите его функционал, тем быстрее получите результат.
Тут немного поясню. Есть календарь, который просто показывает числа по дням недели текущего месяца. А есть с возможностью перелистывать месяцы. Есть календарь с возможностью перелистывать месяцы и года.
Современные тенденции и подходы в веб-разработке
Узнайте алгоритм быстрого профессионального роста с нуля в сайтостроении
Узнать подробнее
Предположим, вам нужен последний вариант (с возможностью перелистывать месяцы и годы) с подсветкой текущей даты. Вы в техническом задании указали: «в боковой панели нужен календарь». Вам делают первый вариант (просто показывает числа по дням недели текущего месяца).
Что мы имеем. Исполнитель пункт тз выполнил, а вы хотели совсем иное. Вроде все в соответствии, никто не виноват, до конфликта не дошло, но самое главное потеряны время и деньги.
Это пример всего-то банального календаря.
А если придется переделывать что-то серьезнее, на переработку чего времени требуется не полдня, как в случае с календарем? Исполнитель возится с вами, хотя мог бы завершить ваш проект и начать новый.
Поэтому, чем подробнее вы опишите функционал каждого модуля, тем быстрее получите результат. В этом должны быть заинтересованы обе стороны.
Из каких пунктов обычно состоит техническое задание?
Давайте представим, что вы владелец некоторой компании или фирмы. Ваша компания занимается выпуском какой-либо продукции, и ее реализацией. У Вас есть покупатели. Вы сотрудничаете с продавцами (магазинами и интернет магазинами), сервисными центрами, потребителями продукции. Или же Вы делаете ресурс для такой компании и Вам нужно написать техническое задание.
Независимо от того в какой роли Вы выступаете, первое, чем нужно заняться перед составлением технического задания на создание дизайна сайта – это изучить структуру организации, то чем она занимается, номенклатуру, характеристики и вообще все, что связно с продукцией и с компанией. От того, насколько глубоко заказчик вникнет в суть происходящего на предприятии, зависит и то, что будет происходить на ресурсе. Поэтому тут задача обоюдная: заказчик должен как можно подробнее рассказать о предприятии, а исполнитель хорошенько вникнуть в суть происходящего.
Даже если вы сами пишете техническое задание для фирмы, которая будет делать Ваш проект, неплохо это все прикинуть на листе бумаги.
Поехали по пунктам.
Описание
Здесь можно в пару предложений написать о предприятии, чем занимается. Что – то типа вступление сделать.
Далее тут указываем:
для кого — целевую аудиторию:
потенциальные покупатели
продавцы продукции (магазины, интернет-магазины)
сервисные центры
партнеры (фирмы)
потребители продукции (тот, кто уже купил)
…
Для чего нужен сайт:
Для повышения имиджа компании
Для увеличения продаж
Для удобства клиентов
…
Тип:
Корпоративный
Сайт – визитка
Интернет магазин
…
Языковые версии:
Английский
Русский
…
Сайт должен решать какие-то задачи. Соответственно далее двигаемся по целям и задачам.
Цели и задачи
В этом разделе технического задания мы проходимся по всей целевой аудитории и описываем круг задач, которые должен для них решать сайт.
Потенциальные покупатели продукции.
Цель: привлечь больше покупателей и убедить сделать первую покупку, помочь сделать выбор.
Необходимо решить задачи:
Дать качественную, исчерпывающую информацию о продукции, дополнительных услугах, гарантии, сервисе, методах выбора.
Дать информацию о салонах-магазинах
Дать информацию о розничной торговой сети
Дать возможность задать вопрос посредством организации Online-консультирования потенциальных покупателей специалистами предприятия по вопросам выбора, покупки продукции.
Таким образом, проходимся по всей целевой аудитории. Также описываем цели и задачи для продавцов продукции (магазины, интернет-магазины), сервисных центров, партнерам (фирмы), потребителям продукции. То есть то, что должен выполнять сайт конкретно для каждого из них.
Теперь перечисляем модули.
Функционал сайта
Для того чтобы перечислить функционал, нужно решить что ему необходимо:
Нужен ли рекламный блок
Нужна ли регистрация
Нужен ли закрытый раздел (только для зарегистрированных пользователей)
Нужна ли форма обратной связи
Нужен ли скрипт рассылки
И т.д. и т.п.
Современные тенденции и подходы в веб-разработке
Узнайте алгоритм быстрого профессионального роста с нуля в сайтостроении
Узнать подробнееПосле того, как все это описали, мы подбираемся к самому главному и интересному. Конечно, вся проделанная выше работа очень важна, но теперь становиться еще «жарче».
Описание функционала
На данный момент мы знаем для кого сайт, какие цели и задачи он должен выполнять, его дополнительные функциональные возможности.
Настало то время, когда нужно всю собранную информацию привести в систему и красиво уложить. Чтобы облегчить задачу и не изобретать велосипед, можно посмотреть ресурсы схожей тематики. Что-то перенять у них, посмотреть и опробовать их функционал и то, что показалось неудобным, попытаться улучшить на своем проекте. В принципе, посмотреть сайты схожей тематики можно (а если нет опыта, то даже и нужно) в самом начале составления технического задания.
Предлагаю начать с пунктов меню. В нем нужно отобразить основные страницы и позаботиться о том, чтобы каждый из посетителей быстро нашел информацию для себя. А посетители – это наша целевая аудитория. Меню будет включать много пунктов, поэтому будет в виде выпадающего списка.
Для начала нужно рассказать о компании. Тут могут быть страницы о компании, история компании, контакты, отзывы.
Далее может идти вкладка «новости». Подпункты могут быть «события», «акции», «новое».
Естественно должен быть пункт меню «продукция», с подпунктами «каталог продукции», «релизы», «отзывы о продукции».
В общем как расписывать надеюсь понятно. Представлю конечный вариант возможного меню:
о компании
история компании
контакты
отзывы
новости
события
акции
новое
продукция
каталог продукции
релизы
отзывы о продукции
сервис
служба сервиса
гарантийное обслуживание
послегарантийное обслуживание
потребителю
покупка и доставка
пользование
о сервисе
магазинам и интернет магазинам
фотографии продукции
Часто задаваемые вопросы
сервисным центрам
Как стать сервисным центром
Часто задаваемые вопросы
партнерам
приглашение к сотрудничеству
Часто задаваемые вопросы
С меню вроде разобрались. Теперь нужно расписать, что будет на каждой странице и как это все в целом работает. Плюс предоставить приблизительный макет. Его можно нарисовать на листке бумаги карандашом, отсканировать и прикрепить к техническому заданию. Единственное, что скажу – не ограничивайте фантазию дизайнера, набросайте в самом общем виде.
Эта часть меняется в зависимости от того, как вы хотите видеть вашу страницу. Может вверху не нужно столько баннеров, возможно вверху нужно указать контакты (адрес, телефон, факс), может в виде иконок «карта сайта», «главная», «контакты». Может, новости Вам слева не нужны, а «акции и релизы» показывать слева.
Главное теперь описать логику работы.
Логика работы
Я описывать буду исходя из рисунка выше.
Верхняя часть (header) остается неизменной на каждой странице. Новостная лента видна только на главной странице. На второстепенных страницах слева показываем подпункты меню того пункта, в котором в данный момент находимся (например если мы на странице «служба сервиса», то показываем ссылки на «гарантийное обслуживание», «послегарантийное обслуживание»). Соответственно и переходы по этим ссылкам ведут на соответствующие страницы. Здесь же, под подпунктами слева отображаем данные для связи с он-лайн консультантами (Skype, ICQ). Блок акции и релизы остаются на каждой странице. Подвал (футер) отображается один и тот же на каждой странице.
Примерно так описывается общая логика работы.
Теперь в нашем тз на разработку сайта, подробно описываем каждый обозначенный блок сайта. Например «Новостная лента».
«Новостная лента» из 10-ти последних новостей. Каждая новость должна состоять из заголовка новости, даты публикации, краткого начала новости (4-5 строк) и ссылки «читать полностью». При нажатии на ссылку «читать полностью» попадаем на страницу новостей. Новость, на которую попали, отображается на месте основного содержимого. Включает также заголовок новости, дату публикации. Слева так же отображается новостная лента. Новости за прошлые месяцы и года попадают в архив. То есть под новостями за текущий месяц отображаем «архив за (такой-то месяц или год)». При нажатии на ссылку «архив за (такой-то месяц или год)» вниз выпадает список новостей за соответствующий месяц/год.
Примерно так описываем работу каждого блока. Не забываем про случай с календарем. И самое главное нужно расписать работу каталога товара. Здесь я даю вам задание: попробуйте продумать и описать, как будет работать каталог. Свои варианты присылайте на e-mail. Лучший мы опубликуем.
Что еще должно быть? Неплохо было бы указать совместимость.
Совместимость
В этом пункте нашего технического задания на создание сайта указываем, на каких операционных системах и в каких браузерах вебсайт должен одинаково хорошо смотреться. На какой версии, какого языка должен быть написан. Какая CMS используется. Это стоит указать, если Вы действительно понимаете, о чем говорите.
Если не владеете этими вопросами, то просто укажите браузеры, в которых сайт должен правильно отображаться. В остальном рассчитывайте на совесть исполнителя.
Заключение
В данной статье я не стремился показать, что именно так составляется тз и никак иначе. Делайте так и проблем не будет. Составить качественное техническое задание на разработку сайта – это скорее вопрос опыта. На первых парах составить грамотное техническое задание получиться далеко не у всех.
В этой статье я хотел показать пример и принципы, по которым строится образец технического задания на разработку дизайна и логики веб сайта, а также основные моменты на которые стоит обратить внимание. На сколько, мне это удалось, надеюсь узнать из ваших комментариев.
И не забывайте про задание!
Автор: Бернацкий Андрей
E-mail: [email protected]
"Киберсант-вебмастер" — самый полный курс по сайтостроению в рунете!
P.S. Хотите опубликовать интересный тематический материал и заработать? Если ответ «Да», то жмите сюда.
Современные тенденции и подходы в веб-разработке
Узнайте алгоритм быстрого профессионального роста с нуля в сайтостроении
Узнать подробнее
Хотите узнать, что необходимо для создания сайта?
Посмотрите 3-х минутное видео и у Вас будет четкий пошаговый план по созданию сайта с нуля!
Смотреть видеоwebformyself.com
Эволюция веб-проекта — что не забыть предусмотреть в ТЗ
Зачем терять время на разговоры о качестве?
Вам нужно в короткие сроки запустить веб-проект, вы выбираете платформу Битрикс или другой фреймворк, подрядчика/интегратора (либо делаете силами собственных программистов), делаете веб-сайт и в час X посетители начинают пользоваться веб-решением. Зачем отвлекаться на вопросы качества интеграции, если веб-проект запущен и цель, казалось бы, достигнута? Сайт доступен для клиентов, проект реализован почти в срок и уложился в бюджет, премии получены… :-) Многие просто не задумываются о дальнейшем развитии веб-проекта. А некоторые категории менеджеров откровенно преследуют цель запустить веб-решение в срок и им попросту «наплевать» на качество и дальнейшую судьбу веб-сайта (проект можно попросту передать другому менеджеру).Быстро или правильно?
Часто веб-проект продолжают активно развивать после запуска, добавлять новые сервисы, стараясь держаться «на гребне волны» и учитывать пожелания Пользователей. Если веб-проект был реализован «слишком быстро» или «недостаточно квалифицированными специалистами» вас ожидают следующие риски:Вдруг оказывается сложно, долго и дорого добавлять контент веб-сайта
Контент веб-решения будет меняться, с разной скоростью. Для изменения телефона в футере вдруг оказывается нужно привлекать программиста. Для добавления новостей можно пользоваться админкой, но чтобы добавить изображение к новости опять нужен программист, т.к. изображение ломает верстку и т.п. Вам было бы проще, если бы контент веб-проекта управлялся через админку сотрудниками без технической квалификации.Дорого настраивать функционал
Нередко после запуска веб-сайта его нужно немного донастроить. Например, поиграть числом слов в анонсе новости, после которых ставится троеточие. Или числом новостей в ленте новостей на главной странице. Вы ищите настройку, но вам говорят, что нужно привлекать программиста. Вы хотите изменить название пункта меню, поменять их местами, добавить описание веб-страницы и ключевые слова — но вам не предоставили такую возможность и снова нужно арендовать ресурсы разработчиков.Опасно и сложно добавлять новый функционал и менять существующий
Когда вы хотите добавить новый функционал, разработчики говорят, что это сделать очень сложно и долго, придется много чего переписывать и потом тестировать. А все протестировать не получится и нужно будет несколько дней отвечать на вопросы Пользователей о критических ошибках и потери данных.Сложно разделить доступ к разным разделам админки веб-решения
Вы хотите чтобы новости добавлял один сотрудник, контент страниц — другой, цены в каталоге — третий, а пароли менял только администратор веб-решения. Может оказаться, что вам сделали только один уровень доступа — «все или ничего» — все администраторы или гости.Опасно обновлять платформу
Платформа Битрикс, на базе которой разработано веб-решение, постоянно развивается, добавляются новые возможности. Вы хотите их использовать в своем веб-проекте и поддерживать систему в свежем актуальном состоянии. Но может оказаться так, что обновлять платформу веб-решения — опасно, т.к. из-за нарушения стандартов интеграции разработчики внесли изменения в ядро системы и обновление может сломать веб-сайт.Вышеперечисленные и другие риски возникают из-за игнорирования требований к качеству интеграции решений на Битрикс. Проект будет запущен быстро, а вот его поддержка и развитие может в данном случае превратиться в сущий ад.
Как же «выжать» максимум пользы из Битрикс и интеграторов веб-решения?
Прежде всего нужно хорошо уяснить для себя, как менеджера веб-проекта, выгодные вам возможности платформы, предоставляемые «из коробки», которые позволяют: — Добавлять/менять контент веб-проекта без привлечения технических специалистов — «Донастраивать» функционал веб-сайта: редактировать меню, настройки списков и т.п. — Постоянно добавлять к веб-решению новые «фичи», развивать сайт быстро и уверенно, не отставая от конкурентов — Организовать эффективную работу сотрудников с веб-решением, разделив их права, настроив при необходимости различные бизнес-процессы (в т.ч. модерации и т.п.) — Оперативно добавлять в свое веб-решение новые возможности платформы через систему обновлений, не отставая от современных веб-технологий и конкурентов.Редактирование страницы «над сайтом»
Редактирование свойств страницы
Редактирование текста «в подвале» сайта
Редактирование телефона
Управление меню
Управление числом новостей на странице
Данные полезные возможности, предоставляемые платформой, полезно отразить в ТЗ на разработку.
Смотрим под капот? Иногда
В этой точке вы знаете важные с точки зрения поддержки и развития возможности платформы, прописали их в ТЗ, тщательно проверите их выполнение и с большой вероятностью получите управляемое вами и вашими сотрудниками, веб-решение. Но рано успокаиваться. Снаружи все может выглядеть красиво и управляемо, менеджеры сайта и посетители довольны, но при увеличении нагрузки и/или объема данных в веб-проекте (увеличился размер каталога, число посетителей, заказов и т.п.) система может начать «тормозить». Есть мнение, что задачу производительности веб-решения можно эффективно решить «в лоб» — путем увеличения серверных мощностей (переехать на более «мощный» хостинг, купить новый сервер и т.п.). К сожалению, это не всегда работает. Часто гораздо проще и дешевле снизить данный риск на этапе разработки веб-решения, путем включения пункта в ТЗ под названием «Нагрузочное тестирование». Платформа Битрикс имеет множество полезных инструментов для аудита производительности, от проверки «мощности» серверного оборудования до анализа скорости работы веб-страниц проекта под нагрузкой и контроля качества работы программистов. Тема большая и интересная, но с позиции эффективного снятия риска в стиле «тычком пальцем в глаз» нужно просто… провести нагрузочное тестирование перед вводом решения в эксплуатацию. Проще всего провести нагрузочное тестирование с использованием инструмента «Настройки/Производительность/Панель производительности/Масштабируемость»: Для создания более реалистичного и комплексного сценария нагрузки целесообразно применить инструменты типа Jmeter. Немало практических примеров организации и проведения нагрузочного тестирования веб-проектов можно найти на нашем сайте.Итоги
Если веб-проект нужно не только «быстро запустить», но и «дешево» поддерживать и эффективно развивать, постарайтесь предусмотреть в ТЗ, чтобы «по максимуму» использовались встроенные возможности платформы Битрикс (в т.ч. технологии «Эрмитаж»): веб-решение было управляемым без привлечения технических специалистов, расширяемым без риска «все нужно переписывать с нуля», а платформу/ядро веб-проекта можно было обновлять в любое время для получения нового функционала. А чтобы веб-сайт «не завис» при увеличении нагрузки и/или объема данных — предусмотрите в ТЗ проведение нагрузочного тестирования на приближенным к реальным объемам тестовых данных.С уважением, руководитель направления контроля качества интеграции и внедрений Александр Сербулhabr.com
Редактирование сайта - доработка готового шаблона
Что из себя представляет услуга «редактирование сайта»?
Данная услуга позволяет заказчику заказать внесение изменений в шаблон и функционал сайта. Например, редактирование сайта включает в себя доработки и изменения меню, шапки сайта, макета шаблона, добавление блоков с фото товаров, блока с опросом, баннеров и флеш видео и прочее. На услуги по доработке заключается договор, в приложении к которому разрабатывается техническое задание (ТЗ), в котором детально отражены все технические аспекты будущих доработок, соответственно мы выполняем работы и несем за них ответственность, заказчик принимает работы, если есть какие то замечания мы их устраняем. Также мы гарантируем, что ничего не «сломаем», т.е не нарушим функциональность, да и работоспособность сайта в целом. В итоге вы получаете полный комплекс выполненных работ со всеми необходимыми и закрывающими бухгалтерскими документами.Рассмотрим пример услуги, оформленной в виде технического задания:
Техническое задание на выполнение доработок сайта
1. Доработка бокового меню после сделанных изменений в каталоге. Пояснение от заказчика: «Мы переставили местами группы в каталоге, а значки, которые должны соответствовать каждой группе, остались на месте. Вот их надо переставить.» 2. Доработка шапки шаблона сайта – вставка блока текста со слоганом компании. Пояснение от заказчика: «Под поисковой строкой (именно в этом блоке, который виден на всех страницах мы хотим вставить свой слоган.» 3. Доработка и верстка шаблона - размещение одного блока с фото товаров, блока с опросом и одного флеш видео-баннера. Пояснение от заказчика: «Нас очень интересует заполнение боковых полей, которые так же будут одинаковыми на всех страницах. Например, здесь мы предполагаем разместить блоки с фото товаров, которые мы хотим постоянно демонстрировать, блок с опросом (где вопрос и варианты ответов). От компании партнера нам периодически приходят небольшие видео-баннеры, их мы тоже хотим разместить на полях. Примеры в приложении.» 4. Вид макета сайта с доработками:
Пояснения к макету: На рисунке пункт 1 – показана порядковая нумерация картинок меню, те картинки у которых фактическая нумерация не совпадает с тем ее положением где она реально должна находиться, их нужно переставить. Пункт 2 – место размещения слогана Пункт 3 – правая боковая колонка с блоком фото, флеш видео и опроса. Общая ширина макета увеличивается на ширину новой правой колонки (ширина правой колонки будет такой же, как и ширина у левой, т.е 210рх), соответственно ширина шапки сайта и его нижняя часть (подвал) увеличивается на такую же величину. В блоке опроса будет использоваться шаблон по умолчанию (.default). У блока опроса название опроса заголовком на фоне (цвет bb1322) по форме как кнопка «оформить заказ». В шапке сайта Логотип и корзину можно отодвинуть, но чтобы эти промежутки между логотипом и телефоном и между авторизацией и корзиной не очень бросались в глаза. Пусть уж крайние элементы шапки не будут вровень с границами макета, но "подрастащить", их надо. Подвал можно не трогать. Шапка добавляемых блоков должна выглядеть как кнопка "Оформить заказ" у корзины. Цвет bb1322 как на макете. Макет должен быть выровнен по центру как на макете снизу: 
Еще статьи:
Разработка и создание веб-сайтаИспользовать преимущества Сети – это грамотный подход опытного руководителя. Сейчас невозможно вообразить жизнь современного человека без интернета, что вносит коррективы в рекламную сферу. Даже небольшой книжный магазинчик...
Профессиональная разработка корпоративных сайтовСоздание корпоративных сайтов – это задача, требующая особого подхода к вопросам дизайна, пользовательского интерфейса и панели навигации. Незаменимыми составляющими подобного проекта являются простота, удобство и привле...
Спектр услуг от веб-студийВ настоящее время нет проблем при создании собственного проекта, есть множество различных веб-ресурсов, организаций, готовых помочь в этом деле. Данная сфера деятельности становится все популярнее, поскольку многие понимают,...
webbakery.ru
Техническое задание на сайт
Итак, принятие решения о создании сайта позади. Осталось самое главное – получить то, что нужно. Хотелось бы отметить, что при создании сайта нас интересует не только уникальный и красочный дизайн, а также его функциональность и возможность модифицирования. Перед началом работ стоит задать себе несколько вопросов. Можно ли создать сайт, который хочется без ТЗ (технического задания)? Нужно писать ТЗ подробно, или можно что-то там не указывать?
Конечно, самое простое – возложить все на плечи разработчиков, но полученный результат часто никого не удовлетворяет. А может быть и так, что ваше представление о сайте, объяснения его функционала и понимание разработчика расходятся, как в море корабли. Вот именно для того, чтобы избежать такой ситуации – составляется ТЗ для сайта, или задание с описанием всех пожеланий к сайту.
Как поможет техническое задание при создании сайта?
Допустим вы даёте такое задание для создание интернет-магазина: "Сайт должен содержать: каталог, корзину, форму заказа товара, раздел доставки, страницу о нас и контактную информацию".Исполнитель, получив такую входящую информацию, создаёт интернет-магазин и его разделы по тому своему стандарту. Через некоторое время у вас появляются новые пожелания, которые сформировались на базе того, что вы увидели в интернете. Соответственно, возникают разногласия, между вами и исполнителем. Кроме того, на выходе получается разница между вашими ожиданиями и виденьем разработчика. В итоге у нас возникла конфликтная ситуация, с одной стороны, нужно принять то, что есть, а с другой стороны, исполнителю нужно снова дорабатывать интернет-магазин.
Задача технического задания – максимально снизить конфликтные ситуации и формализовать этапы разработки. Не менее важным следствием из технического задания является прозрачность оплаты этапов разработки и стоимости доработки. В любом случае, даже если ТЗ выполнено с идеальной точностью получить именно тот результат, который вам необходим, всегда сложно.
Какие задачи нужно описывать в ТЗ?
Задания на разработку могут быть противоречивыми. Одни способны привести к ожидаемому результату, а другие наоборот замедлить процесс разработки. Чем больше условий изложено в ТЗ, тем выше стоимость заказа и больше срок разработки. Найдите среди всех задач минимально необходимое ядро и начните разработку интернет-магазина с него. Лучше всего составить ТЗ с учетом нескольких правил и по нему создать сайт, а затем заказывать доработку необходимых задач.
Почему так? Во-первых, оплата процесса разработки будет максимальна прозрачна и осуществляться частями. Во-вторых, сроки разработки будут меньше на каждом этапе, а значит более гибкими в планировании. Постараемся сформулировать правила способные помочь вам в составлении ТЗ. Не стоит считать нижеизложенные правила абсолютными – всегда есть место отклонениям.
Правило первое
ТЗ должно содержать описание необходимого набора задач, но не все задачи нужно прописывать очень подробно.
Техзадание входит в состав договора со своим регламентом работ, описывающим, что должно быть выполнено и за какой срок. Указывайте дополнительно для каждой задачи моменты, по которым в дальнейшем выясняется, сделана задача из ТЗ или нет.
Приведем примеры не конкретных описаний задачи: этот раздел разместить справа страницы. Или к примеру, этот элемент выделяем красным цветом, который нравится всем.
Очень сложно прописывать в ТЗ создание дизайна сайта и его элементов. Можно чётко описать цветовую схему интернет-магазина, нарисовать блок-схему размещения элементов, но на бумаге нельзя передать эмоциональное восприятие цветов и элементов картинки. Даже в том случае, если дизайн был "воистину шикарным" – другим людям он может не нравиться.
Правило второе
Чётко формулируйте опорные пункты задач вашего ТЗ.
Формулировать условия в задании необходимо четко, без размытых выражений. Например, сайт должен быть удобным. А как именно должно быть "удобно"?
Чтобы избежать доработок, а соответственно потраченного времени и денег, нужно написать в ТЗ так: на сайте пользователь должен иметь возможность осуществлять заказ без регистрации, или у менеджеров в интернет-магазине должна быть возможность выгрузки прайс-листа.
Кроме того, в техническом задании должны присутствовать описание разделов сайта, статических страниц, описание меню сайта, описание работы корзины товаров, страницы оформления заказа. Формулировка ТЗ должна указать, что именно нужно делать исполнителю.
Правило третье
Исполнитель выполняет не оговоренные условия ТЗ (технического задания) по своему усмотрению.
Не считайте это правило чересчур категоричным, ведь оно защищает исполнителя от вмешательства во все параметры работы Заказчика. Вы исполнителя и нанимаете за его профессиональные навыки, а значит как именно сделать работу не прописанную в ТЗ решает исполнитель.
Этот пункт не относится абсолютно ко всем не прописанным требованиям в ТЗ, исполнитель при работе по техническому заданию может постоянно держать с вами связь. Совместные коммуникации заказчика и исполнителя во время работы над проектом – одна из важных составляющих вашей работы.
Правило четвертое
Пишите ТЗ таким образом, чтобы у исполнителя после прочтения не возникло слишком много уточняющих вопросов. Техническое задание можно разделить на несколько отсеков: общие сведения; назначение и цели создания (развития) системы; характеристика объектов автоматизации; требования к системе; состав и содержание работ по созданию системы; порядок контроля и приемки системы; требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие; требования к документированию; источники разработки.
ТЗ разрабатывает разработчик системы с участием заказчика на основании технических требований (заявки, тактико-технического задания и т. п.). Таким образом, ТЗ может быть разработано исполнителем только совместно с представителями с уполномоченными представителями заказчика, которые могли бы сообщить Ответчику вышеперечисленные, самые основные, базисные характеристики разрабатываемой автоматизированной системы, без которых невозможны разработка и создание системы.
1) Общие сведения
Описание терминов и определений. В данном разделе должно быть расписано все так, чтобы стало ясно, что исполнитель и заказчик имеют в виду одно и то же. Причем определения и термины могут быть не только прописаны в ТЗ заказчиком, но и озвучены исполнителем, например, заказчик упустил в условиях какой-либо важный пункт, возможно, по забывчивости, а может, по незнанию.
При этом не обязательно при объяснении того, зачем нужен хостинг, рассказывать, как устроен и работает сервер. А уточнить, что означает "процесс работы с сайтом" нужно обязательно – ведь это может означать все что угодно, начиная от периода времени, когда зашли и вышли с сайта, и заканчивая любым другим объяснением.
2) Назначение и цели создания (развития) системы
Безусловно, основной целью каждого сайта можно считать заработок, неважно от чего: продажи товара, кликов по рекламе и т.д. Но, перед тем как заработать, всегда имеет наличие еще один аспект – сам способ заработка. Как вариант, можно прописать в ТЗ это назначение – прибыль, а можно немного углубиться – если это сайт-визитка, то его назначением станет широкая реклама, магазина – продажа товара и другое.
3) Функциональность
В этом разделе описываются способы, с помощью которых хочется достигнуть цели создания. Проще говоря, технические средства и разделы, которые обязательно должен содержать сайт и как должны они работать.
Довольно часто многие заканчивают на этих трех пунктах разделы ТЗ, и это неверно, так как эти пункты – всего лишь вводная часть!
4) Список важных пунктов (характеристика объектов автоматизации)
Данный раздел можно заранее назвать самым главным во всем ТЗ, причем он не обязательно состоит из множества пунктов, но написать его достаточно трудно.
Здесь необходимо расписать, что должно быть на сайте. Рассмотрим на примере добавления новостей. Одна новость включает в себя несколько пунктов – заголовок или название, сам текст и время публикации – практически так, на составные пункты нужно разложить различные добавляемые разделы. Перечислить все пункты необходимо для того, чтобы в дальнейшем не исправлять сайт и его работу.
Разложив на составляющие разделы сайта, возможно, в дальнейшем захочется добавить еще что-нибудь. Например, три пункта новостей дополнить еще одним – анонсом, небольшим текстом, который отображается в общем списке новостей. Разработчик добавляет в таблицу еще одно поле – анонс, тип: текст, и еще одно поле ввода текста при выкладывании новой новости или редактирования старых. Такая доработка считается небольшой. Но что если заказчиком забыт такой пункт, как категория новости? Ведь исполнителю придется в этом случае заняться добавлением таблицы категорий, раздела в админке и т.д.
Из этого получается, что выяснить отсутствие категорий лучше во время написания ТЗ, а не строения сайта. Важность основных данных заключается в том, что исходя из них – определяются сроки выполнения.
5) Описание страниц (состав и содержание работ по созданию системы)
В этот раздел необходимо внести все страницы, которые должны быть на сайте, с описанием, что будет на страницах. В этом же разделе заказчик может указать, какой именно должен быть тот или иной элемент – не в смысле внешнего вида или цвета, а в смысле его работы: открываться в новой странице, появляться выезжающим окошком и тому подобные нюансы работы.
Если разработчик по совместительству пишет вам контент, то вносить в этот раздел описание контента не нужно. Описание функционала и содержания страницы – это разные вещи, поэтому и описываем их в разных разделах.
Если планируется создание сайта с разделением на публичную часть (доступную для всех) и закрытую часть (кабинет пользователя), то раздел разбейте на две группы – кабинет пользователя и публичная часть. Обязательно распишите права доступа к каждому разделу сайта.Есть ещё три пункта, которые нужно включить в ТЗ.
6) Хостинг сайта
Для создания сайта, на который в дальнейшем планируется высокая нагрузка требует определенной настройки сервера, бэкапов и написания кода. Такой момент, как высокая нагрузка на сайт, должен оговариваться вначале, а не в конце работы.
Хостинг может выбираться владельцем сайта самостоятельно или рекомендоваться исполнителем, чтобы избежать спорных ситуаций, в этом разделе нужно указать требования к свободному пространству на диске, памяти, библиотеке, интерпретатору, ftp, pop, smtp, внешним программам и всему остальному, что важно для основного проекта.
Есть и другие ситуации, например, заказчик владеет некоторым количеством сайтов, имеющим один хостинг… решает заказать еще один сайт, находит студию, дает ей ТЗ, но не обращает внимание на то, что студия пишет на Django, а когда дело доходит до выкладки сайта на хостинг, заказчик естественно выбирает тот, на котором у него работают остальные сайты. Но его "любимый" хостинг работает с PHP, и тут возникает разногласие, итог которого – исправление сделанной работы на PHP. Таких нюансов может быть миллион, и учитывать их лучше в самом начале, чтобы видеть заказанный сайт в назначенный срок, а не после дней/недель/месяцев исправлений и доработок.
7) Размещение контента на сайте
Разработчики сайтов редко занимаются написанием текстов, хотя такие варианты не исключены. Если заказчик желает, чтобы на новый сайт был выложен или написан контент, то в этом разделе и должно быть указано, что именно и куда должно быть добавлено – текст или изображения. Дополнительно, если требуется поиск картинок самостоятельно или их предварительное изменение (уменьшение/увеличение) – так же прописывается заранее.
8) Сдача результата исполнителем и прием заказчиком
В этом разделе описываются условия оплаты за сделанную работу – в этом случае варианты указываются, исходя из собственных соображений. Заказчик может прописать свои условия или же согласиться на те, которые озвучены исполнителем, написаны на сайте студии, занимающейся разработкой и тому подобные варианты.
Желаем вам хороших сайтов и удачных проектов!
absgroups.ru
