Правила технического задания. Как правильно составить техническое задание: пошаговый алгоритм Как пишется тз
Важность технического задания при заказе сайта нельзя недооценивать. Так как часто по итогу получается так, что заказчик услуг недоволен результатом. Чаще всего так бывает, когда стороны пренебрегают составлением технического задания, и заказчик ограничивается формулировкой «удобный, красивый, функциональный».
Надо сказать, что техническое задание в принципе не должно касаться условий о дизайне, так как очень трудно оценить данный результат объективно. «Красота» — понятие исключительно субъективного характера, так же как и «удобство». Посему необходимо отнестись к ТЗ основательно и четко прописать все нюансы, чтобы по окончанию работы избежать спорных ситуаций.
Так же надо упомянуть, что хоть и техническое задание составляется от имени заказчика, но наиболее важное значение оно имеет для исполнителя, коим оно и создается. Текст его должен касаться исключительно технической части, разработан подробно и максимально конкретно. В конце его не лишним будет поместить фразу о том, что остальные моменты, которые не обговорены выше, будут выполнены по усмотрению исполнителя.
Содержание примера технического задания на разработку сайта
В целом, в качестве примера можно привести некую структуру технического задания, которой следует придерживаться для грамотного его составления.
Затем необходимо описать его функциональное назначение, которое должен включать те средства и инструменты, с помощью которых будут достигаться вышеназванные цели. В этом качестве называются разделы и страницы сайта, которые необходимы заказчику, в том числе корзина покупок, каталог и прочие.
Не лишним будет посвятить отдельный раздел расшифровке терминов, которыми оперируют стороны. Важно, чтобы все определения были поняты правильно и исключали двусмысленное понимание.
Самым важным разделом технического задания является указание заказчиком структуры сайта со всеми заголовками и списками. Они включают в себя все данные и сведения, которые должны быть учтены и отображаться. Например, вся информация, которая должна быть видна относительно конкретной новости, разделы, подразделы, ее темы, а так же различные списки, которые могут быть расположены на многих страницах, но в понятии заказчика отображены в различном виде.
Страницы с описательной частью так же должны быть подробно описаны, по возможности добавлена схема, которая будет достаточно наглядно отображать задуманное заказчиком.
Отдельным разделом должны быть упомянуты требования к надежности, то есть той нагрузки, которую должен выдерживать созданный сайт.
разработки (и не только), практические подготовки технического задания. Бо льшая часть уже готовых к применению логических элементов ТЗ приведены в конце статьи. Редакция от 20.06.2018.
Как писать техническое задание?!
Создан 05.02.2005 11:41:19
Твой мир пуст...
Кто печаль твою разделит?
«Как писать техническое задание?!» - из уст т. н. начинающего «технического писателя», далее по тексту - техписа. Вот она - страшная цена развала Союза и переход российской высшей школы на двухступенчатую систему образования.
Вернемся к вопросу. При «раскладке» получается:
- первый вопрос - «а зачем оно надо»;
- второй вопрос - какова должна быть структура разделов «Техническое задание»;
- третий вопрос - какие существуют способы подготовки текстов содержимого разделов технического задания?
Третий - самый сложный. Ответы на указанные вопросы появятся в ходе изложения.
Цели и задачи статьи
Цель статьи - облегчить жизнь совсем уж начинающим техписам.
Задачи статьи:
- дать ответы на поставленные вопросы;
- показать необходимый минимум практических подготовки текстов технического задания;
- дать начинающему техпису шанс:
- повысить собственный рейтинг;
- или окончательно уронить себя в глазах Большого Босса.
История
Все, что когда-либо производилось, производится и будет производиться, делится (условно, разумеется) на:
Первым () изделием, быть может, стал каменный топор. Или (рукотворный) глиняный черепок (), позволяющий зачерпнуть водички в ручейке.
Первым программным изделием, реализованным на «железном носителе», стал, возможно, «музыкальный автомат» с вращающимся диском, утыканным колышками. Колышки в определенное время ударяли по определенному камертону. Таким образом, мелодия оказывалась запрограммированной, «зашитой» на металлическом - настоящее программное изделие по, только что не, а кустарного производства. Увидеть это чудо чудное можно в Политехническом Музее г. Москвы.
Первой автоматизированной системой, возможно, стала ветряная мельница. Вытащил стопор - «лопасти» вращаются, жернова молотят. «Нажатие одной кнопки» - 100-процентная автоматизация.
История, леденящая душу
И наказал тогда царь () - построить мельницу, да такую, чтобы от силы ветра работала, круче, чем у короля аглицкого («хотелки» заказчика), да чтоб на зависть всем буржуям (соответствующую современному развития науки и и не уступающую аналогичным требованиям, предъявляемым к лучшим современным отечественным и зарубежным аналогам).
Приволокли опричники холопа государева, умепьца местного (), кинули царю-батюшке в ноги. Бился лбом умелец о пол каменный - дык, оно, конечно! Сделаем, твое величество, все безоговорочно, точно, в срок и в полном объеме!
Настало время, прибыл царь на мельницу (работ). Смотрит и диву дается - крылья крутятся, жернова жито молотят, мука сама собой в мешки сыплется! (Полное соответствие требованиям к функциям (задачам), выполняемым системой). Да возьми и запусти руку в мешок... (что не было предусмотрено ни, ни, поскольку не существовало таковых).
Побагровел царь - что ж, смерд, мельница сия муку непотребно мелет?! (Несоответствие производимой требованиям ГОСТ 7045-90 Мука ржаная хлебопекарная.). Схватили мужика опричники, да долбанули по буйной его головушке топором каменным. И кончил жизнь Левша под звуки «Реквиема» Моцарта из музыкального автомата...
Выводы
В стародавние времена в отношениях сторон, заказчика и исполнителя (разработчика), равноправия было маловато. Чем-то, само-собой, отношения регламентировались. Возможно, готовились берестяные грамоты - прообразы современных договоров. Вряд ли в подобных договорах можно было учесть все, даже качество помола. Да и не было общепризнанных, в широком смысле все аспекты взаимоотношений заказчика и исполнителя.
Издавались Указы, Распоряжения - «в университете московском студиозусам надобно на соломе сидеть, сморкаться в кулак, нос утирать пучком соломы. А нарушивших правила сии розгами драть нещадно» (или что-то в этом роде).
Равноправия нет и сейчас - кто платит, тот и заказывает музыку. А платит заказчик.
Примечание от 10.05.2014 г. - Но не все так печально Если действовать с умом, то можно запросто прогнуть любого заказчика, см. и.
Современное состояние
И было придумано то, что сделали танк...
из серии «Армейские приколы»
Устав от «заказчицкого» беспредела, собрались (в последнюю четверть двадцатого века) исполнители (разработчики), организовали «» и сделали танк - на структуру и (, если быть более точным) документа под названием «техническое задание». Следует отметить, что авторские коллективы состояли, как правило, из людей технически грамотных, мыслящих, смотрящих в далеко будущее.
Может быть, все было иначе, но танк, в целом, получился хорош - что подтверждается и представителями ГОССТАНДАРТа, и отзывами опытных разработчиков.
Техническое задание и его назначение
Большому Боссу, непосредственно взаимодействующему с заказчиком, техническое задание дает возможность избежать участи мастера-умельца (об этом ранее упоминалось неоднократно).
Для маааааааленького техписа, работающего на Большого Босса, разработка технического задания есть:
- средство заработать себе «таки на покушать»;
- способ показать, что техпис - не тварь дрожащая, а право имеет - способ вырасти в глазах Большого Босса.
Крайнее утверждение - палка о трех концах. Ах, ты умный, умеешь? Так на тебе еще работенки. А жалование поднимем. Когда-нибудь.
В любом случае способность грамотно разработать техническое задание (особенно - владение) - показатель высокой квалификации разработчика.
Считаем, что первый вопрос (в первом же приближении) закрыт.
ГОСТы на технические задания
Куст есть совокупность веток, произрастающих из одной точки.
Военная мудрость
После тяжких трудов (и страданий) увидели свет, как минимум, четыре документа, соответствующие весьма условному делению продуктов человеческой жизнедеятельности:
Примечания:
- Существуют и иные отечественные ГОСТы, содержащие требования к содержанию и оформлению документа «Техническое задание». Сей факт обусловен спецификой. Перечисленная четверка была и остается для большинства предметных областей;
- Техзадание было и остается основополагающим документом, той самой «точкой опоры», из которой все и произрастает.
Что общего в разделах перечисленных выше документов? Любое техническое задание должно содержать разделы, отражающие сведения:
- что надо сделать;
- для чего, с какой целью надо сделать это;
- где, в какой области применения, на каком объекте это должно решать задачи и выполнять свои функции;
- какие требования будут предъявлены к этому;
- какие работы потребуется выполнить, чтобы сделать это;
- каков порядок проведения и приемки-сдачи работ заказчику;
- как должно быть проведение работ;
- и, наконец, на основании каких нормативно-технических документов должны проводиться работы?
Такова обобщенная структура разделов технического задания. Второй вопрос считаем закрытым.
Потребовалось разработать техническое задание на изделие - пользуемся ГОСТ 2.114-95, поскольку ГОСТ 15.001 - кривой по жизни, а разделы технических условий (в целом) соответствуют разделам технического задания. Надо - открываем ГОСТ 34.602-89. На - ГОСТ 19.201-78.
Покажем необходимый минимум практических приемов, позволяющих даже самому начинающему техпису немедленно приступить к разработке содержимого разделов техзадания и достичь приемлемых результатов (отдельные готовые структурные элементы технического задания по ГОСТ 34.602-89 можно найти в «подвале» данной статьи).
Практические приемы
Практические приемы разработки технического задания буквально выстраданы на основе опыта взаимодействия с заказчиком как самого автора, так и его старших товарищей, за что низкий им поклон, почет и уважение (и ныне, и присно, и во веки веков. Аминь).
Самый первый прием - создание документа с ГОСТированной структурой разделов. Если Боссом поставлена задача разработки технического задания, положим, на автоматизированную систему, скачивается ГОСТ 34.602-89 в виде -файла, затем просто открывается вордом и в формате dot.
Электронные версии ГОСТов, хранящиеся на, в целом соответствуют официальным версиям. Сомнительные моменты всегда можно проверить путем сравнения, если не лень, конечно.
Примечание от 25.12.2011 г. - На Ростехрегулирования (protect.gost.ru) не так давно стали публиковать официальные версии ГОСТов, правда, далеко не в редактируемом формате...
Детализация
Детализация - один из основополагающих приемов. Кое-кто предпочитает наукообразный термин, заимствованный у буржуев - декомпозиция. Речь пойдет о детализации структуры разделов ГОСТов на техническое задание.
Вспомним родительское - «пока ты не разложишь все по-полочкам, «ничего у тебя не получится (мама)» или «ни хрена у тебя не выйдет (папа)». И мама, и папа, безусловно, были и остаются бесконечно правы. Несложную задачку по физике решить невозможно, пока векторы сил не будут разбросаны по осям. Тройной интеграл взять невозможно, пока не будут поочередно взяты интегралы по dx, dy и dz. За исключением случая, когда «интеграл настолько прост, что взять его можно даже без dx».
Произвольно выбранная цитата из ГОСТ 34.602-89:
Для системы приводят требования к применению в системе, языков взаимодействия и технических средств системы, а также требования к и декодированию, к языкам -, средствам описания (объекта автоматизации), к способам организации [из п. 2.6.3.3 ГОСТ 34.602-89]
Здо рово, да? Придется разгрести эту свалку. Итак, явным дроблением создаются дополнительные подпункты технического задания (это и можно, и нужно делать).
4.3.2.1 Требования к лингвистическому обеспечению системы
4.3.2.1.1 Требования к применению в системе языков программирования высокого уровня
(текст требования)
4.3.2.1.2 Требования к языкам взаимодействия пользователей и технических средств системы
(текст требования)
4.3.2.1.3 Требования к кодированию данных
(текст требования)
4.3.2.1.4 Требования к декодированию данных
(текст требования)
4.3.2.1.5 Требования к языкам ввода-вывода данных
(текст требования)
4.3.2.1.6 Требования к языкам манипулирования данными
(текст требования)
4.3.2.1.7 Требования к средствам описания предметной области (объекта автоматизации)
(текст требования)
4.3.2.1.8 Требования к способам организации диалога
(текст требования)
Увеличился объем технического задания? А стоит ли экономить бумагу? Имеется и еще одна военная мудрость, как бы грубо и двусмысленно она ни звучала: «больше бумаги - чище з@@@@ца». Требования к лингвистическому обеспечению стали выглядеть понятнее?
Примечание - Термины «понятность», «» (understandability) фигурируют сразу в нескольких ГОСТах. Вот квинтэссенция - «совокупность чего-то, характеризующая затраты усилий человека на понимание логической концепции этого чего-то».
После трансформирования сплошного текста в перечисление (, подразделы, подпункты) на понимание (хотя бы запоминание) логической структуры технического задания автору потребовалось меньше времени (и затрат усилий), поскольку подпункты стали явно «видны».
Детализация, детализация и еще раз детализация. До приемлемого (атомарного) уровня.
Шаблонное построение фраз
Следует взять на вооружение тот факт, что в каждом вопросе (правильно поставленном) - половина ответа. Допустим, необходимо сформулировать текст подпункта «Требования к применению в системе ». Итак:
4.3.2.1 Требования к применению в системе языков программирования высокого уровня
В системе должны быть (именно должны - это же!) применены перечисленные ниже языки программирования высокого уровня:
- язык C++;
- язык Pascal;
- и т.д.
Для тех, кто не прочувствовал, как построить фразу, слева приведена схема ее построения.
4.1.2 Требования к численности и квалификации персонала системы и режиму его работы
(детализируем - создаем подпункты 4.1.2.1, 4.1.2.2 и 4.1.2.3)
(правильно формулируем текст подпункта - отвечаем на вопрос, каким требованиям должна удовлетворять численность персонала)
Численность персонала должна удовлетворять требованиям :
- быть достаточной для реализации автоматизированных () системы во всех режимах работы системы;
4.1.2.2 Требования к квалификации персонала
Квалификация персонала должна обеспечивать эффективное функционирование технических и системы во всех режимах работы системы»
В, в решениях по квалификации персонала, можно будет указать, что, на основании опыта более сотни ранее разработанных аналогичных систем, персонал должен иметь образование не ниже трех классов церковно-приходской школы. Сие утверждение порадует заказчика. Можно будет воспользоваться сверхдешевой рабочей силой. Но об этом в следующих статьях.
4.1.2.3 Требования к режиму работы персонала
Режим работы персонала - трехсменный круглосуточный.
В подразделе предусмотрен также порядок подготовки персонала, контроля знаний и навыков. О составе - ни слова. И это правильно. Состав персонала, деление его на оперативный (), ремонтный и пр., определяется при проектировании системы. Хотя никто не может запретить добавить в техническое задание Требования к составу персонала. Пожалуй, не стоит.
Простенько, но со вкусом. Чистая практика, без глубокого погружения в языковые тонкости. Детализация плюс конктерных требований технического задания.
Формализация при подготовке текста технического задания
Возможно Двести Вариантов
Один из двухсот вариантов расшифровки аббревиатуры «ВДВ»
Вернемся к примеру из предыдущего подраздела статьи.
4.1.2.1 Требования к численности персонала
Численность персонала должна удовлетворять требованиям:
- быть достаточной для реализации автоматизированных системы во всех режимах работы системы;
- обеспечивать полную занятость персонала при реализации автоматизированных функций системы и т.д.
Лапша полнейшая, но формально все верно. Рекомендуется к применению, если невозможно конкретизировать какой-либо пункт технического задания. Если Большой Босс не будет, можно вежливо попросить его уточнить требования заказчика по данному пункту, дать более точную информацию. Это право техписа, не контактирующего непосредственно с заказчиком.
Можно добавить - «численность персонала уточняется на «Технический проект»». Большой Босс будет поражен такой осведомленностью техписа (даже если и сам ни черта не знает) в части стадий и автоматизированных систем. А если устно предложить Боссу добавить (потом) в к проекту фразу - «на основе опыта более сотни ранее разработанных подобных систем численность персонала должна составлять 10 штатных единиц» - Босс будет сражен наповал. Можно смело готовить Приказ о назначении техписа на должность системного аналитика (которая также отсутствует в общероссийском классификаторе). Или ждать, что подкинут дополнительную работенку, раз такой умный.
Примечание от 17.04.2018 г. - В ОКПДТР должность технического пейсателя тоже отсутствует. А должность укладчика текста так и осталась с прежних времен
Штампы и унификация при подготовке текста технического задания
Вы, бабы, красивы,
А я - без прикрас
Но, все же, мужчины
Уходят от вас...
Ю. Рыбчинский, «Две сестры»
текста техзадания достигается применением штампов. Прежде всего следует усвоить простую истину - никогда, ни в одном документе не следует называть вещи своими именами .
Положим, разрабатывается универсальный преобразователь энергии в энергию человеческого разума (Существование человеческого разума сомнительно. Разумно ли вешать на свою шею работу по созданию такого преобразователя? А вот рефлексы существуют объективно). Следует сразу, в разделе «Наименование изделия» обозвать этот самый преобразователь Изделием:
Наименование изделия - преобразователь энергии солнечного излучения в энергию человеческого разума (далее по тексту - Изделие ).
И, в тексте - Изделие, Изделие, Изделие...
Тоже самое относится к программным изделиям и автоматизированным системам. Наименование АС - автоматизированная система раздачи грубых кормов для крупного рогатого скота (далее по тексту - Система ).
И, в тексте - Система, Система, Система... Программа, Программа, Программа...
Итог - догнали и завалили сразу двух зайцев. Склонять-спрягать целую кучу слов не потребуется, да и читать построенное таким образом техническое задание будет проще.
Примечание от 05 февраля 2010 г. - При автоматизированной разработке техдокументации с применением single source приемлем как вариант со всякими склонениями-спряжениями, так и без них. К примеру, можно единожды создать переменную <ЗАО «Заказчик»> и вставлять в требуемые топики библиотеки документов - так иногда бывает удобнее.
Ниже - типовые перечни штампов, долго и успешно применяемых при разработке технических заданий (по основным разделам, выделено жирным):
- назначение системы - система предназначена для
решения перечисленных ниже задач:
- задачи такой-то (первой);
- задачи сякой-то (второй);
- и так далее.
- цели создания системы - целями создания системы являются
:
- увеличение скорости...;
- повышение точности...;
- уменьшение издержек...;
- снижение потребления...;
- улучшение показателей...;
- и так далее.
Любая цель всегда подразумевает положительную динамику , изменение каких-либо показателей в лучшую сторону. К примеру, цель - повышение благосостояния всего советского народа (но не коммунизм: коммунизм - это мишень!). Цель - повышение удовлетворенности заказчика. Исключение составляют:
- получение прибыли (в контексте технического задания);
- подписание заказчиком.
Встречаются еще и не такие фокусы. Пример из практики одного из самых маститых техписов (пример привел он сам, без всякого принуждения, в одном из техписовских форумов) - « позволяет ... программа выполняет ... программа делает ...». Милостивый государь, технический писатель! Программы еще нет, она еще не разработана, не, не, не, не и не сдана заказчику, поэтому еще ничего не позволяет, не делает и не выполняет. Что за непобедимая совковая привычка выдавать желаемое за действительное?!
- требования к функциям (задачам), выполняемым системой - системадолжна
перечисленных нижефункций
:
- в рамках первой задачи - выполнение функции такой-то, такой-то и еще какой-то;
- в рамках второй задачи - выполнение функции такой-то и пр.
Если функция (как и процесс) , тогда именно обеспечивать возможность выполнения указанной функции. Пользователь может убрать стопор - мельница начнет молоть муку. Но пользователь может стопор и не убрать. В указанном случае мельница (система) будет находиться в режиме ожидания (простоя).
Если функция (как и процесс) , тогда система должна именно обеспечивать выполнение функции. Функция автоматического запускается программными средствами системы (без участия персонала) по заданному расписанию и сливает базу данных на.
По части рамок задач. Задачи решаются , а функции выполняются . Чтобы решить задачу, надо выполнить ряд функций, процедур или операций. Иными словами - задача есть более крупный структурный элемент вопреки измышлениям.
В ГОСТ 34.003-90 поставлена впереди, задача является как бы частью функции. И это странно: еще в школе все решали задачки, вычисляя внутри них значения различных функций... И представьте себе, как дико звучала бы декларация: «Цель партии и правительства - повышение благосостояния всего советского народа. Ради достижения цели партия ставит перед собой функцию обеспечения к 2ххх году каждой семьи отдельной квартирой»... (Кстати, заниматься уборкой домов и квартир самостоятельно сейчас уже не модно и некогда особенно - для этого есть клининговые компании). Таким образом, функция является частью задачи, а не наоборот. Пусть даже вопреки священному ГОСТ 34.003-90.
Итак, пример.
В рамках задачи (или для решения задачи ) программные средства системыдолжны обеспечивать выполнение перечисленных нижефункций :
- автоматизированной функции
- автоматизированной функции сортировки записей в таблицах базы данных;
- функции автоматического резервирования базы данных.
И из предыдущего подраздела:
- должны быть ...;
- должна удовлетворять требованиям ..
В результате применения штампов тескт технического задания становится унифицированным и формализованным. Никаких прикрас . И заказчик-мужчина никуда не уйдет от вас, милые девушки-техписы, поскольку требования технического задания будут для него прозрачны .
Перечни и нумерация разделов
Перечни (маркированные или нумерованные списки) весьма уместны при подготовке текста технического задания. Нормальный человек способен воспринять (запомнить и безошибочно воспроизвести) от трех до девяти элементов перечня. Свыше девяти - признак гениальности.
В, пожалуй, число элементов перечня следует снижать. В техническом задании - необязательно. Следует помнить, что техническое задание с множеством иных документов, разрабатываемых на различных стадиях и этапах создания системы (да чего угодно).
Случай первый.
«В рамках задачи (или для решения задачи должны обеспечивать возможность выполнения перечисленных нижефункций :
- автоматизированной функции добавления записей в таблицы базы данных;
- автоматизированной функции удаления записей из таблиц базы данных;
Случай второй.
«4.3.2.1 В рамках задачи (или для решения задачи ) ведения базы данных программные средства системыдолжны обеспечивать возможность выполнения перечисленных нижефункций :
- автоматизированной функции добавления записей в таблицы базы данных;
- автоматизированной функции удаления записей из таблиц базы данных;
- автоматизированной функции сортировки записей в таблицах базы данных...;»
Отличия, казалось бы, невелики. Но!
В первом случае, в документе «Программа и методика испытаний», придется написать «методика проверки выполнения системой автоматизированной функции добавления записей в таблицы базы данных».
Во втором случае, всего-навсего - «методика проверки выполнения п. 4.3.2.1(1) технического задания».
В, в первом случае - «требования технического задания к выполнению автоматизированной функции добавления записей в таблицы базы данных выполнены». Во втором случае - «требования п. 4.3.2.1(1) технического задания выполнены». Есть разница?
Что касается многоуровневой нумерации разделов, подразделов, пунктов и подпунктов - на практике указанные требования в подавляющем большинстве случаев обязательны.
По списки следует «нумеровать» не цифрами, а буквами:
а) функция такая-то;
Вопрос принципиальный, поскольку ТЗ на АС (дополнение к ТЗ) до передачи его на утверждение должно быть проверено службой организации - разработчика ТЗ и, при необходимости, подвергнуто [из п. 8 прил. 1 ГОСТ 34.602-89]. Ведь если техническое задание разработано криво (по форме и по существу), кривыми будут проектные и эксплуатационные документы.
Чуть-чуть о. Если в ТЗ имеется подраздел «Метрологическое обеспечение...», то метрологическая экспертиза должна быть проведена по полной программе. Если указанный подраздел отсутствует, то метрологическая экспертиза сводится к проверке сокращений согласно ГОСТ 8.417. И только.
Связка «общие сведения, назначение и состав» в техническом задании
Связка «общие сведения, назначение и состав» прекрасно показала себя не только при разработке технического задания. Связка подойдет для любых нехудожественных текстов описательного характера.
Пример - Требования к числу уровней и степени централизации системы. Вот что можно написать в указанном подразделе технического задания?
Любой человек начнет рефлекторно просматривать разделы ГОСТа на техническое задание, пытаясь найти хоть какую-то зацепку. Человек с опытом сразу вспомнит о.
2.1 Назначение системы
Товарищ, непосредственно что-то там паяющий, налаживающий, всегда сможет подсказать техпису, для чего система создается. В рамках своей компетенции, разумеется. Системотехник или Босс скажут больше. Допустим,
Система должна обеспечивать решение (возможность решения) перечисленных ниже задач:
- задачи сбора данных с каких-то, допустим, датчиков;
- задачи обработки, хранения, отображения и пр. в центре сбора.
Вот и все. Немного фантазии, и раздел готов:
Система должна обладать иерархической структурой и включать в себя перечисленные ниже уровни иерархии:
- 1-й уровень - уровень сбора данных ;
- 2-й уровень - уровень консолидации данных (централизованная обработка, хранение и пр.).
Снова оба зайца - и наповал. И уровни иерархии перечислены, и степень централизации. А что дальше?
2.1.1 Уровень сбора данных
2.1.1.1 Общие сведения
Какие-то общие сведения. Можно, к примеру, написать, что уровень характеризуется территориальной распределенностью - любая водичка сойдет, если она приблизительно соответствует.
2.1.2.2 Назначение
Уровень сбора данных предназначен (еще один штамп):
- для передачи данных каких-то датчиков уровню консолидации по запросу (инициативе) крайнего (последнего);
- для протоколирования передачи данных в журнале событий (а если по ГОСТу, то в);
- еще для чего-то.
2.1.2.3 Состав
В состав уровня сбора данных должны входить:
- датчики такие-то;
- датчики еще какие-то.
В чем удобство использования связки «общие сведения, назначение и состав»? А невольно получается хорошо структурированное техническое задание - древовидное и иерархическое.
2.2.2.3.1 Датчики такие-то
2.2.2.3.1.1 Общие сведения (о таких-то датчиках)
2.2.2.3.1.2 Назначение (таких-то датчиков)
2.2.2.3.1.3 Состав (таких-то датчиков)
Главное - вовремя остановиться.
Предостережение
При разработке и наибольший интерес представляют перечисленные ниже:
- прежде всего - . Для таким является;
- , например и;
- , например;
- и, например;
- ряд других.
Не следует особенно увлекаться подобными «тематическими» ГОСТами, содержащими очень уж конкретные требования к. Характерная ошибка начинающих - «каналы связи должны удовлетворять требованиям ГОСТ такому-то». Это фатальная ошибка. Известно, что приемке-сдаче работ по созданию системы, изделия, программного изделия всегда предшествует проведение.
Допустим, Большой Босс, пораженный глубокими познаниями техписа, доверился оному, читать ничего не стал и черканул на титульном листе технического задания утверждающую (под УТВЕРЖДАЮ, в правом верхнем углу титульного листа). Заказчик, с гнусной ухмылкой, аккуратно поставил свою (под УТВЕРЖДАЮ, в левом верхнем углу). Все, техническое задание и внести в него или возможно только по дополнительному соглашению с заказчиком. Вот тут-то техпис и попал.
Настало время проведения испытаний системы (программы, изделия) на соответствие требованиям технического задания. Заказчик, само собой, потребует показать, что каналы связи соответствуют требованиям ГОСТа такого-то.
Что делать? Полбеды, если каналами связи занимался, готовый предоставить Большому Боссу. Босс отмажется перед заказчиком и техпис будет жить (до очередного прокола). Но неприятный осадок в душе Большого Босса останется навсегда. Повышения ждать не приходится.
Совсем беда, если сертификатов нет. Придется Боссу платить (не предусмотренные бюджетом) денежки органу, дабы заполучить вожделенный сертификат, предъявить заказчику и закрыть работу. Такую ошибку техпису могут и не простить.
Короче, писать надо примерно так, русским по белому:
«В качестве каналов связи могут быть применены (использованы):
- каналы связи -;
- каналы операторов сотовой связи;
- каналы операторов спутниковой связи;
- коммутируемые телефонные линии общего пользования;
- объекта заказчика;
- и так далее»
Ни в коем случае нельзя указывать скорость обмена данными канала связи, т.е. конкретику. Если канал связи будет реализован на базе Ethernet, а в техническом задании будет явно указана скорость обмена не ниже 1200 бит/с, заказчик имеет полное право заставить исполнителя провести испытания по полной программе. Даже в такой, явно абсурдной ситуации.
Заключение
Итак, вспомним еще разок ключевые моменты:
- подготовка технического задания импортом электронной версии требуемого ГОСТа;
- детализация - дробление больших по объему разделов технического задания на короткие простые подразделы;
- шаблонное построение предложений в разделах (подразделах и пр.) технического задания так, чтобы «в ответе оказывалась половина вопроса»;
- формализация содержимого тех разделов, где невозможно (или) давать конкретику;
- применение штампов;
- применение перечней (маркированных или нумерованных списков);
- применение связки «общие сведения, назначение и состав»;
- минимальное применение «тематических» ГОСТов.
В заключении можно дать ряд дополнительных советов:
- отыскать «рыбу» технического задания и, после критического ее осмысления, позаимствовать содержимое подходящих разделов (только не с известного всем ресурса закупки.гов.ру - там лежит чушь полнейшая);
- пользоваться документами;
- без стеснения задавать вопросы.
От
автора
: Как написать техническое
задание на разработку сайта
? Тема достаточно обширная,
и в рамках одной статьи ее сложно разобрать на все 100% (если вообще
это возможно). Но общие положения, то, что нужно учесть, на что
следует обратить внимание при составлении ТЗ, я постараюсь достаточно
подробно изложить в данной статье.
Итак, ТЗ
Техническое задание составляется для разработчика сайта. На ТЗ нужно ссылаться при составлении договора между заказчиком и исполнителем. Должна быть оговорена ответственность за невыполнение или некорректное выполнение пунктов и сроков ТЗ с обеих сторон. Но самое главное (на мой взгляд), для чего создается ТЗ, так это для ускорения процесса разработки сайта .
Давайте проанализируем такой пример:
Предположим, что Вам на сайте, где-нибудь с боку нужен календарь. Казалось мелочь. Но чем подробнее вы опишите функционал этого календаря, тем быстрее получите результат.
Тут немного поясню. Календарь календарю рознь. Есть календарь, который просто показывает числа по дням недели текущего месяца. Есть календарь с возможностью перелистывать месяцы. Есть календарь с возможностью перелистывать месяцы и года.
Предположим, вам нужен последний вариант календаря (с возможностью перелистывать месяцы и годы) с подсветкой текущей даты. Вы в ТЗ указали: «в боковой панели нужен календарь». Заказчик вам делает первый вариант календаря (просто показывает числа по дням недели текущего месяца).
Что мы имеем. Исполнитель пункт ТЗ выполнил, а вы хотели совсем другой календарь. Вроде все в соответствии с ТЗ, никто не виноват, до конфликта не дошло, но самое главное потеряны время и деньги .
Это пример всего-то банального календаря.
А если придется переделывать что-то серьезнее, на переработку чего времени требуется не полдня, как в случае с календарем? И у вас сайта нет, и заказчик возится с вами, хотя мог бы завершить ваш проект и начать новый.
Поэтому, чем подробнее вы опишите функционал каждого модуля сайта, тем быстрее получите результат. В этом должны быть заинтересованы обе стороны.
Из каких
пунктов обычно состоит ТЗ?
Давайте представим, что вы владелец некоторой компании или фирмы. Ваша компания занимается выпуском какой-либо продукции, и ее реализацией. У Вас есть покупатели. Вы сотрудничаете с продавцами (магазинами и интернет магазинами), сервисными центрами, потребителями продукции. Или же Вы делаете сайт для такой компании и Вам нужно написать ТЗ.
Независимо от того в какой роли Вы выступаете, первое, чем нужно заняться – это изучить структуру организации, то чем она занимается, номенклатуру, характеристики и вообще все, что связно с продукцией и с компанией. От того, насколько глубоко заказчик вникнет в суть происходящего на предприятии, зависит и то, что будет происходить на сайте. Поэтому тут задача обоюдная: заказчик должен как можно подробнее рассказать о предприятии, а исполнитель хорошенько вникнуть в суть происходящего.
Даже если вы сами пишете ТЗ для фирмы, которая будет делать сайт, неплохо это все прикинуть на листе бумаги.
Поехали по пунктам.
Описание
сайта
Здесь можно в пару предложений написать о предприятии, чем занимается. Что – то типа вступление сделать.
для кого – целевую аудиторию сайта :
- потенциальные покупатели
- продавцы продукции (магазины, интернет-магазины)
- сервисные центры
- партнеры (фирмы)
- потребители продукции (тот, кто уже купил)
Для чего нужен сайт :
- Для повышения имиджа компании
- Для увеличения продаж
- Для удобства клиентов
Тип сайта :
- Корпоративный
- Сайт – визитка
- Интернет магазин
Языковые версии :
- Английский
- Русский
Сайт должен решать какие-то задачи. Соответственно далее двигаемся
по целям и задачам сайта.
Цели и задачи сайта
В этом разделе ТЗ мы проходимся по всей целевой аудитории и описываем круг задач, которые должен для них решать сайт.
Потенциальные покупатели продукции .
Цель : привлечь больше покупателей и убедить сделать первую покупку, помочь сделать выбор.
Необходимо решить задачи :
- Дать информацию о салонах-магазинах
- Дать информацию о розничной торговой сети
Дать качественную, исчерпывающую информацию о продукции, дополнительных услугах, гарантии, сервисе, методах выбора.
Дать возможность задать вопрос посредством организации Online-консультирования потенциальных покупателей специалистами предприятия по вопросам выбора, покупки продукции.
Таким образом, проходимся по всей целевой аудитории. Если следовать нашему сайту, то описываем цели и задачи для продавцов продукции (магазины, интернет-магазины), сервисных центров, партнерам (фирмы), потребителям продукции. То есть то, что должен выполнять сайт конкретно для каждого из них.
Теперь перечисляем модули сайта.
Функционал сайта
Для того чтобы перечислить функционал сайта, нужно решить что ему необходимо:
- Нужны ли новости на сайте
- Нужен ли рекламный блок
- Нужна ли регистрация
- Нужен ли закрытый раздел сайта (только для зарегистрированных пользователей)
- Нужна ли форма обратной связи
- Нужен ли скрипт рассылки
- И т.д. и т.п.
После того, как все это описали, мы подбираемся к самому главному
и интересному. Конечно, вся проделанная выше работа очень важна,
но теперь становиться еще «жарче».
Описание функционала сайта
На данный момент мы знаем для кого сайт, какие цели и задачи он должен выполнять, его дополнительные функциональные возможности.
Настало то время, когда нужно всю собранную информацию привести в систему и красиво уложить в сайт. Чтобы облегчить задачу и не изобретать велосипед, можно посмотреть сайты схожей тематики. Что-то перенять у них, посмотреть и опробовать их функционал и то, что показалось неудобным, попытаться улучшить на своем сайте. В принципе, посмотреть сайты схожей тематики можно (а если нет опыта, то даже и нужно) в самом начале составления ТЗ.
Предлагаю начать с пунктов меню. В нем нужно отобразить основные страницы сайта и позаботиться о том, чтобы каждый из посетителей быстро нашел информацию для себя. А посетители – это наша целевая аудитория. Меню будет включать много пунктов, поэтому будет в виде выпадающего списка.
Для начала нужно рассказать о компании. Тут могут быть страницы о компании, история компании, контакты, отзывы.
Естественно должен быть пункт меню «продукция», с подпунктами «каталог продукции», «релизы», «отзывы о продукции».
В общем как расписывать надеюсь понятно. Представлю конечный вариант возможного меню для нашего сайта:
О компании
- история компании
- контакты
- отзывы
Новости
- события
- акции
- новое на сайте
Продукция
- каталог продукции
- релизы
- отзывы о продукции
Сервис
- служба сервиса
- гарантийное обслуживание
- послегарантийное обслуживание
Потребителю
- покупка и доставка
- пользование
- о сервисе
Магазинам и интернет магазинам
- фотографии продукции
- Часто задаваемые вопросы
Сервисным центрам
- Как стать сервисным центром
- Часто задаваемые вопросы
Партнерам
- приглашение к сотрудничеству
- часто задаваемые вопросы
С меню вроде разобрались. Теперь нужно расписать, что будет на каждой
странице и как это все в целом работает. Плюс предоставить приблизительный
макет сайта. Его можно нарисовать на листке бумаги карандашом, отсканировать
и прикрепить к ТЗ. Единственное, что скажу – не ограничивайте фантазию
дизайнера, набросайте в самом общем виде.
Эта часть меняется в зависимости от того, как вы хотите видеть вашу страницу. Может вверху не нужно столько баннеров, возможно вверху нужно указать контакты (адрес, телефон, факс), может в виде иконок «карта сайта», «главная», «контакты». Может, новости Вам слева не нужны, а «акции и релизы» показывать слева.
Главное теперь описать логику работы.
Логика работы
Я описывать буду исходя из рисунка выше.
Верхняя часть сайта остается неизменной на каждой странице сайта. Новостная лента видна только на главной странице. На второстепенных страницах слева показываем подпункты меню того пункта, в котором в данный момент находимся (например если мы на странице «служба сервиса», то показываем ссылки на «гарантийное обслуживание», «послегарантийное обслуживание»). Соответственно и переходы по этим ссылкам ведут на соответствующие страницы. Здесь же, под подпунктами слева отображаем данные для связи с он-лайн консультантами (Skype, ICQ). Блок акции и релизы остаются на каждой странице. Подвал сайта отображается один и тот же на каждой странице.
Примерно так описывается общая логика работы.
Теперь подробно описываем каждый блок. Например «Новостная лента».
«Новостная лента» из 10-ти последних новостей. Каждая новость должна состоять из заголовка новости, даты публикации, краткого начала новости (4-5 строк) и ссылки «читать полностью». При нажатии на ссылку «читать полностью» попадаем на страницу новостей. Новость, на которую попали, отображается на месте основного содержимого. Включает также заголовок новости, дату публикации. Слева так же отображается новостная лента. Новости за прошлые месяцы и года попадают в архив. То есть под новостями за текущий месяц отображаем «архив за (такой-то месяц или год)». При нажатии на ссылку «архив за (такой-то месяц или год)» вниз выпадает список новостей за соответствующий месяц/год.
Примерно так описываем работу каждого блока. Не забываем про случай с календарем. И самое главное нужно расписать работу каталога товара. Здесь я даю вам задание : попробуйте продумать и описать, как будет работать каталог. Свои варианты присылайте на e-mail. Лучший мы опубликуем.
Что еще должно быть? Неплохо было бы указать совместимость.
Совместимость
В этом пункте указываем, на каких операционных системах и в каких браузерах сайт должен одинаково хорошо смотреться. На какой версии, какого языка должен быть написан. Какая CMS используется. Это стоит указать, если Вы действительно понимаете, о чем говорите.
Если не владеете этими вопросами, то просто укажите браузеры, в которых сайт должен правильно отображаться. В остальном рассчитывайте на совесть исполнителя.
Заключение
В данной статье я не стремился показать, что именно так составляется ТЗ и никак иначе. Делайте так и проблем не будет. Составить качественное ТЗ – это скорее вопрос опыта. На первых парах составить грамотное ТЗ получиться далеко не у всех.
В этой статье я хотел показать принципы, по которым строится техническое задание, основные моменты на которые стоит обратить внимание. На сколько, мне это удалось, надеюсь узнать из ваших комментариев.
И не забывайте про задание!
«Сделать хотел грозу, а получил козу…», - думаете вы, принимая от разработчика новенький сайт. Вроде бы исполнителя подбирали по рекомендации. И портфолио у него внушает доверие. И работает не первый год. А сделал всё равно совсем не то, что представляли себе вы. И вот вы уже разочаровались в сайтостроителях и уверены, что вас окружают жулики и дилетанты.
Между тем, за результат любого делегирования отвечает не только исполнитель, но и заказчик.
Снизить риски и повысить вероятность получить интернет-ресурс вашей мечты поможет правильно составленное техническое задание на создание сайта.
Зачем нужно техзадание?
- Исполнителю грамотное ТЗ на разработку сайта поможет заранее оценить объём работы, её сложность и стоимость. Понять, справится ли он с такой задачей самостоятельно, или стоит взять помощников. А затем сделать именно то, чего от него ждёт заказчик.
- Заказчику техзадание даёт уверенность в том, что он задокументировал свои пожелания к будущему сайту, чётко обозначил сроки, в которые должен уложится исполнитель, прописал требования к работе сайта. И если результат окажется неудовлетворительным, можно предъявить обоснованную претензию: «Не соответствует ТЗ!»
Как выглядит техническое задание на сайт?
Ваше пожелание «блог с бесплатными материалами, страницей обо мне и контактами» исполнитель видит так:
Вы думаете, этого достаточно для создания сайта?
Вы получаете готовый сайт, и тут вдруг оказывается, что вы имели в виду вот это:
Нюансы описания очень важны
Чувствуете разницу? Формально здесь неправы обе стороны: вы не добавили подробности, исполнитель о них не спросил. Но он уже получил оплату и готов пропасть вместе с ней, а у вас недоделанный сайт, непредвиденные расходы и полное разочарование в специалистах по созданию сайтов.
Предлагаю не доводить дело до подобных крайностей, а подойти к составлению технического задания на сайт осознанно.
О чём пишут в техзадании?
Техническое задание на сайт - это подробный документ, описывающий процесс ваших взаимоотношений с исполнителем и результат его работы.
Для разработки больших и сложных сайтов требуется объёмное и сложное техзадание, для сайтов поменьше и ТЗ будет соответствующее.
Над крупным проектом обычно работает целая команда исполнителей. Их действия должны быть согласованными, и поэтому ТЗ для сайта будет достаточно массивным. Если вам не нужно большое количество специфических функций, если над вашим сайтом работает один разработчик (или в компании с дизайнером), документ будет проще. Но и у больших, и у маленьких ТЗ смысл один, и отвечать они должны на одни и те же вопросы:
- Для чего и для кого создаётся сайт?
- Чем он будет наполнен?
- Как это всё будет функционировать?
- Кто и как будет работать над проектом, кто за что отвечает?
- Что будет приниматься на выходе?
Основные разделы технического задания на разработку сайта
1. Информация о заказчике, то есть о вас
Предоставьте максимально подробные сведения. Укажите все источники, откуда разработчик может получить недостающие данные. Это могут быть листовки, афиши, электронные материалы, ссылки, контакты людей, которым можно задать вопросы.
2. Информация о проекте
Что это будет: сайт-визитка, интернет-магазин, корпоративный портал, электронная библиотека?
3. Целевая аудитория сайта
Это тот случай, когда вам понадобится . Если вы давно читаете наш блог, то поняли, что без этого инструмента в маркетинге, вообще, очень мало что можно сделать.
Вы решились на собственный сайт, но до сих пор не представляете себе в подробностях, кто ваш клиент? Значит, сейчас самое время составить его детальный портрет.
4. Цели и задачи, которые должен решать сайт для заказчика и для аудитории
Это, пожалуй, главный раздел ТЗ на разработку сайта. Вы должны чётко понимать, для чего вам нужен web-ресурс. Для повышения имиджа? Для прямых продаж? Вы хотите конвертировать посетителей в подписчиков с помощью сайта? Вы хотите сделать ресурс для привлечения потенциальных партнёров?
Указывайте прямое назначение вашего сайта.
Хорошо продумайте отдельные задачи веб-ресурса. Например, он должен предоставлять актуальную информацию о новостях рынка, демонстрировать вашу продукцию, позволять посетителям связываться с вами прямо со страниц сайта и так далее.
5. Рамки проекта (основной функционал)
На сайте может быть огромное количество функций: форма для регистрации пользователей, обратная связь, кнопки заказа, календарь поставок, новостная лента, каталог продукции с возможностью перехода в корзину, встроенный скрипт рассылки, закрытые разделы для клиентов - да что угодно! Каждая из этих функций в ТЗ на разработку вашего сайта должна быть прописана подробнейшим образом.
Таким образом, раздел «Рамки проекта» - что-то вроде оглавления, перечисление функций без их дотошного описания. Этот раздел понадобится вам на стадии поиска исполнителя. Он позволит потенциальному создателю вашего сайта увидеть общую картину и озвучить примерную цену, а вам систематизировать ваши пожелания по функционалу.
6. Структура (карта) сайта
Следующий пункт ТЗ для сайта расскажет исполнителю, какие страницы будут на вашем сайте, какие разделы и подразделы, как они будут друг с другом связаны, как они будут отображаться в меню сайта.
Структуру удобнее рисовать, чем описывать. В графическом виде легче продумать взаимосвязь областей сайта.
Схема взаимосвязей отдельных частей сайта
У нас в на эту тему есть вебинар «Система контента продающего сайта». И вот о структуре сайта, о взаимосвязи страниц и ссылках между ними мы там подробно рассказываем. Рекомендую! Картинка выше - из материалов этого вебинара.
7. Отдельные страницы
Пока вы рисуете карту сайта, каждая страница - это просто квадратик. Но исполнителю нужно понимать, что и в каком порядке на этом квадратике будет расположено (вспоминаем примеры таблиц в начале статьи). Какие там будут информационные блоки? На каждой ли странице будут меню, сайдбар (отдельный блок с навигацией) , футер (нижний блок) ? Хотите ли вы видеть на странице баннеры, картинки? Будут ли они статичные или движущиеся?
Чем подробнее вы опишите каждый элемент каждой страницы будущего ресурса, тем ближе результат на выходе окажется к вашим представлениям о сайте.
По сути на этом этапе создаётся . Об этом мы уже писали, если вам предстоит создание сайта, обязательно почитайте.
Вы можете создать прототип каждой страницы сайта, сопроводив его подробным словесным описанием. А можно сначала составить прототипы основных блоков, которые повторяются на каждой или на многих страницах, а потом разрабатывать отдельные страницы с использованием уже описанных блоков.
8. Требования к дизайну сайта
На этом этапе будьте аккуратны. Исходите из того, что дизайнер - профессионал. Не стоит прописывать каждый его шаг. Не рассказывайте: «Эту кнопочку сделай с переливом из синего в красный, а этот текст 12-м кеглем и чтоб мерцало» . Обозначьте основные пожелания. Например, покажите существующие сайты/баннеры/полиграфию, дизайн которых кажется вам подходящим. Расскажите о том, какие цвета вы предпочитаете. Скажем, вы хотите сделать сайт, посвящённый женским тренингам, дизайнер может «увидеть» его в розовых тонах, а вам нравится сиреневый и оранжевый. Общее описание пожеланий поможет найти компромисс между вашим видением и профессиональным взглядом дизайнера.
Обязательно предоставьте дизайнеру материалы для работы, если они у вас есть: логотип, кодировки фирменных цветов и шрифтов, уже готовые элементы фирменного стиля (полиграфию, баннеры и прочее).
С сайтами на движках типа WordPress или Joomla можно обойтись готовыми шаблонами (иногда даже бесплатными). Это снижает неопределённость: просто посмотрите шаблоны и выберите тот, который вам нравится. С точки зрения дизайна, некоторые из них бывают довольно странными, поэтому постарайтесь проконсультироваться со специалистом, - это всё равно выйдет дешевле, чем заказывать дизайн с нуля.
9. Рабочий функционал сайта
Не ленитесь и описывайте подробно работу всех функций. Выдайте исполнителю максимум информации. Помните, что он не обладает даром телепатии и может не догадаться, что вы хотите получить, когда пишете в техническом задании на сайт «форма подписки» или «календарь» .
Какая форма подписки? Как она выглядит? Как работает? Что за календарь? Показывает ли он только сегодняшнее число или весь последний месяц? Можно в нём листать страницы или нельзя? Этих нюансов исполнитель может не угадать, в итоге вы получите совсем не то, чего хотели. Деньги заплачены, проект соответствует ТЗ (вы же написали «календарь» - вот он), а вам придётся довольствоваться тем, что получилось, хотя это вовсе не то, чего хотелось, или переплачивать за изменения.
Не стесняйтесь исследовать другие сайты - конкурентов или даже компаний, чья деятельность не имеет к вам никакого отношения. Конкуренты могут подсказать реализацию нужных вам функций, на других рынках можно позаимствовать интересные решения, до которых пока не додумались конкуренты. Часто проще найти функцию на чужом сайте и дать исполнителю ссылку «это должно работать так», чем объяснять на пальцах.
Не забудьте и о том, что ваш сайт должен быть удобным не только для пользователя, но и для администратора. Современные системы управления сайтом обычно интуитивно понятны для администрирования. Но, если не знаете, на каком движке работает исполнитель, пропишите и функции администратора. Что он должен на сайте делать и как это должно быть реализовано.
Конечно, вы имеете полное право не знать, как будет работать какая-то функция. В этом случае попросите разработчика предложить вам варианты для согласования. Утвердите тот вариант, который вам подходит (в том числе по бюджету). Запомните: сначала рассмотреть и утвердить, затем уже делать.
10. Описание контента
Если вы заказываете контент одновременно с созданием сайта, и исполнитель у вас один (например, агентство), описание контента - это отдельное ТЗ копирайтеру. Если контент вы собираетесь создавать самостоятельно или заказать у другого исполнителя, разработчик сайта всё равно должен иметь представление о том, что в каком разделе будет размещено и как будет выглядеть. Где текст, где видео, как будут оформлены картинки, нужен ли предварительный просмотр статей, и каким он будет и так далее.
11. Технические требования
Сложный пункт для тех, кто мало понимает в сайтостроении. Если вы в этом разбираетесь и вам важно, на каком языке какой версии должен быть написан ваш ресурс, напишите об этом в техническом задании на создание сайта. Или у вас есть требования к дисковому пространству на хостинге.
Пример нашёлся на habrahabr.ru/post/140574/
Если не разбираетесь, включайте логику и здравый смысл. Подумайте, что скажет вам о том, что сайт работает корректно?
Например, ваш сайт должен:
- одинаково хорошо смотреться на мониторах разной ширины;
- адекватно отображаться в разных браузерах (каких именно?);
- открываться с мобильных устройств (или вы будете разрабатывать отдельную мобильную версию сайта?);
- уметь противостоять вирусам;
- иметь встроенный seo-функционал и так далее.
Пишите только о том, в чём вы уверены, или посоветуйтесь со специалистом. Даже платная консультация всегда дешевле, чем бесконечные доработки, некоторые из которых могут по масштабу оказаться практически равными полной переделке сайта.
В остальном придётся полагаться на совесть исполнителя.
Информация, которую я дала в статье, - мой опыт. Мне приходилось заказывать сайты с нуля и дорабатывать существующие. Первая версия сайта аzconsult.ru - один из самых маленьких проектов, с которыми я работала. Для крупных проектов есть нюансы, но не думаю, что они вам понадобятся.
Важно! Если у вас с исполнителем нет договора, и ваши отношения регламентируются только техническим заданием, обязательно добавьте коммерческую информацию: стоимость работ, график и способ оплаты, крайние сроки сдачи работы и промежуточные отчётные точки. Убедитесь, что эта информация предельно ясна и не может быть истолкована как-то иначе. Попросите исполнителя задать дополнительные вопросы.
После ответственной проработки ТЗ, ваши шансы получить хороший сайт будут высокими, а доработки после его сдачи в эксплуатацию - минимальными.
Если среди читателей есть профессиональные разработчики сайтов, пожалуйста, дополните статью, если вам покажется, что в ней чего-то не хватает или я о чём-то забыла.
Данный текст был создан сугубо ради существования постоянной ссылки, которую бы сам автор, да и все вы - могли бы смело отправлять своим будущим заказчикам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «А надо ли мне ваше ТЗ и вообще что это?»
Как говорится - «вместо тысячи слов», поскольку каждый раз евангелистить по 4-5 часов в скайпе на данную тему становится уже утомительным, а общемировая тенденция подсовывать под определение «Технического задания» откровенную ерунду с годами все только усиливается.
Проблема
Дело в том, что когда существует конкретный формат, а также четкое и внятное определение какого-либо термина, то все манипуляции и подмены его на собственные брифы, прототипы, на ходу придуманные опросники, описания и просто входящие заявки - выглядят, по меньшей мере, непрофессионально. Поэтому с научного определения нашего понятия и начинаем:
Техническое задание - исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования. Техническое задание является юридическим документом - как приложение включается в договор между заказчиком и исполнителем на проведение проектных работ и является его основой: определяет порядок и условия работ, в том числе цель, задачи, принципы, ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет. Все изменения, дополнения и уточнения формулировок ТЗ обязательно согласуются с заказчиком и им утверждаются. Это необходимо и потому, что в случае обнаружения в процессе решения проектной задачи неточностей или ошибочности исходных данных возникает необходимость определения степени вины каждой из сторон-участниц разработки, распределения понесенных в связи с этим убытков. Техническое задание, как термин в области информационных технологий – это юридически значимый документ, содержащий исчерпывающую информацию, необходимую для постановки задач исполнителям на разработку, внедрение или интеграцию программного продукта, информационной системы, сайта, портала либо прочего ИТ сервиса.
Переводим на понятный язык
1) ТехЗадание - оно ставит задачу. А значит оно должно идти перед прототипом, скетчем, тестом, дизайн-проектом, потому что любой майндмеп, диаграмма потоков данных, архитектура - это уже выполнение некой задачи, это ответ на вопрос. А до того, как сам вопрос еще не задан, не сформулирован и не подписан всеми сторонами - любой ответ будет априори неправильным, не так ли? Итак, начало любой работы над любым проектом - это постановка задачи, а не судорожный поиск набросков десятка вариантов ее решения.
2) Собственно из первого пункта логично вытекает и новый - сам текст ТЗ обязан начинаться с главы «Цели и задачи», четко формулирующей, какие бизнес-цели преследует вся эта очередная попытка повысить энтропию в мире. Бесцельное задание, которое не решает никаких проблем, не достигает ничего и делается «от скуки» - официально не считается Техническим Заданием, а с этого момента находится в статусе «обычная бумажка».
3) Как же вам понять, решает ли предложенная дизайн-концепция или интерактивный прототип, а то и готовый к употреблению сайт - вышеизложенную задачу бизнеса? Ничего не поделаешь, придется опять вернуться к определению: «определяет… ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет». То есть ТЗ без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия - быть не может. Бриф может, или прототип, или еще любая абсурдная бумажка, но только не ТехЗадание.
Отсюда делаем вывод, что в настоящем ТЗ обязательно должна быть глава «Порядок приемки и оценки», когда эти самые показатели берутся, замеряются, и стороны либо пожимают друг другу руки, либо отправляют проект на переделку.
4) ТехЗадание должно обязательно согласоваться с общим бизнес-планом заказчика, с его стратегией развития бизнеса и анализом сегмента рынка. Именно все это позволит установить правильные цели, вывести точные метрики, по которым затем адекватно провести приемку готового инфопродукта. Отсутствие у заказчика бизнес-плана автоматически гарантирует непрофессиональное выполнение Технического Задания.
Знает ли студия на аутсорсе бизнес-цели и измеримые показатели бизнеса лучше его владельца? Очевидно, что нет, а значит правильное ТЗ должно писаться представителями Заказчика, а не наемными работниками Исполнителя. Абсурд, когда исполнитель сам себе ставит задачу, затем сам себе придумывает способы ее оценки, и в конце сам же выставляет себе итоговую отметку за сделанную работу. В идеале такой «самодеятельности» быть не должно, хотя на практике повсюду именно так и происходит, в результате чего ТехЗадание и не оказывает нужной помощи проекту, слишком часто являясь по сути фиктивным документом. Не надо так.
5) Каждое внесение правок в готовое ТЗ должно стоить денег. Нельзя бесплатно и бесконечно править «Конституцию вашего проекта» только потому, что одна из сторон передумала, не выспалась, внезапно решила сэкономить и т.д. Цена каждого изменения в ТЗ должна также четко прописываться заранее в соответствующей главе.
Кстати, по идее точно также каждая правка в дизайне или внесение изменений в список страниц или функций должна иметь четкую цену, которая оплачивается заранее, до начала внесения данного изменения. Лично я предлагаю любую редактуру утвержденного ТЗ оценивать в 30% от всего бюджета проекта, но вы можете поступать иначе.
Стоит ли упоминать, что в ТЗ просто необходимо заранее указывать сроки и общий бюджет на разработку, а также список всех существующих ресурсов и ограничений? - Нет, это будет уж слишком очевидно.
Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? - написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.
Контрольные вопросы
А здесь перечислю ответы на самые часто встречающие вопросы от заказчиков:1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? - Да, даже несколько.
2) А что, в ТехЗадание не входит описание нужных страниц, количества кнопок, используемых библиотек, гайдлайнов и т.д.? - В само ТЗ нет, но в Приложения вы можете все это поместить, разумеется скорректировав все это с вышеописанными целями, ограничениями и способами дальнейшей оценки достигнутого результата. Размещайте хоть весь будущий контент, хоть описание типовых персонажей - но не вместо четкой постановки задачи, а уже после нее.
3) Так может оно мне такое и не нужно? - Возможно, сегодня тысячи сайтов делаются вообще без ТЗ, также, как тысячи людей в мире прекрасно живут, будучи слепыми от рождения. Но если вы хотите видеть - куда вы вообще движетесь, осознанно принимать решения и самостоятельно оценивать полученные результаты - то без ТЗ тут не обойтись.
4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? - Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.
5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? - Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) - то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL - уже нет.
6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? - Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» - установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь - обязательно.