Как самим написать техническое задание. Техническое задание

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

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

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

По своему объему ТЗ может быть достаточно большим документом. Web-компании часто предлагают помощь по составлению ТЗ отдельной услугой, как правило 10-20% от стоимости всей разработки сайта.

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

Чем детализированнее ТЗ (в разумных пределах конечно), тем лучше для обеих сторон — как для клиента, так и для исполнителя работы. В выигрыше так сказать оба:
— клиент будет уверен, что все задуманное им в проекте четко прописано и должно быть реализовано в соответствии с ТЗ.
— исполнитель – застрахован от множества мелких или крупных корректировок и доработок, опять же опираясь на то самое ТЗ.

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

• Простая истина — чем сложнее проект, тем детализирование должно быть ТЗ.
• Среди возможных вариантов можно назвать ТЗ, описывающее главные страницы интерфейса со всей совокупностью элементов на ней и описанием их поведения. Или же это может быть лаконичное описание нескольких страниц для сайта-визитки и т.п.
• В ТЗ для программиста не должен упоминаться дизайн элементов или звучать пожелания по дизайну. Задание все-таки для программиста..
• Описания задач в отдельных частях ТЗ должны быть граничными. Что это значит? Нужно четко обозначать конец конкретного пункта задания. В ТЗ не должно быть абстрактных фраз типа «должна быть удобная навигация». Это все субъективные признаки – одним удобно, другим не удобно и понять выполнен ли данный пункт бывает сложно из-за нечеткости положений ТЗ. Т. е. это необходимо контролировать.
• Для несложных сайтов, где нужно описать какой-нибудь функциональный модуль, чтобы заново не изобретать велосипед, нужно проанализировать сайты с похожим функционалом, так сказать, провести анализ конкурентов; сохранить гиперссылки на страницы с требуемыми элементами интерфейса и функциями, и включить их в ТЗ с расширенными пояснениями о том, что именно делать. Также необходимо в обязательном порядке снять скриншоты с нужных страниц на случай, если сайт через время будет не доступен. При этом можно ставить свои пометки на изображениях (благо средств сейчас много для этого — Clip2net, Joxi, Awesome Screenshot и прочие).
• Если дизайна для страниц нету или он не так важен в рамках какого-то проекта, скажем, заказчик решил сэкономить на дизайне админ-панели сайта, в этом случае программист вполне может использовать прототипы.

Справка

Прототип — это графическая схема размещения элементов интерфейса. Грубо говоря, нарисованная в специальной программе страница со всеми элементами.

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

Из популярных можно выделить:
— среди бесплатных: iPlotz, MockFlow, Mockup Builder, Cacoo;
— среди платных: Creately, ProtoShare, Adobe Fireworks,Axure . Возможностей в общем много - выбирай, осваивай, рисуй…

Общая структура ТЗ. От абстракции к конкретике

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

1. Общая информация о сайте.
2. Функциональное назначение сайта.
3. Понятия и термины
4. Описание модулей сайта
5. Функциональные характеристики
6. Описание страниц.
7. Резервирование и надежность.
8. Хостинг для сайта.

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

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

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

4. Описание модулей сайта
Этот раздел включает список модулей, которые используются на сайте. Это вполне например может быть упоминаемая выше форма обратной связи (ФОС). Но, что очень важно — нельзя просто писать «Должна присутствовать ФОС». Каждая сущность требует определения своих атрибутов! В данном случае атрибуты могут быть такими:

• Поле «Ваш имя»;
• Поле «Ваш е-mail»;
• Поле «Ваш вопрос»;
• Поле ввода капчи для защиты от спам-роботов.

И все это должно быть четко прописано, что бы потом не возникло вопросов: «…а где перечень выбора категории вопроса? » или что-то в этом роде.

5. Функциональные характеристики
Сюда можно отнести, например, список браузеров, где сайт должен корректно отображаться и работать. Например, некоторые заказчики могут требовать, что бы их сайт работал корректно и в небезызвестном Internet Explorer 6, что бы не терять хоть и небольшую, но долю возможных посетителей.
Если планируется делать высоконагруженный сайт – это тоже нужно указывать. Высоконагруженный сайт требует другого подхода при разработке и по настройке сервера.

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

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

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

Остальные страницы

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

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

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

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

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

Удачных Вам проектов и человеческого взаимопонимания!

Одно из главных условий успешной закупки - правильно составленное техническое задание.

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

Оно несет пользу для обеих сторон.

Заказчику это поможет подробно описать объект закупки и приобрести именно те товары (работы, услуги), которые нужны.

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

Кто составляет

Техническое задание составляют сотрудники контрактной службы или контрактный управляющий в составе документации о закупке (п. 3 ч. 4 ст. 38 Федерального закона от 5 апреля 2013 г. № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд», далее - Закон № 44-ФЗ).

Совет: Если заказчик планирует приобрести специфические товары (работы, услуги), то к составлению технического задания стоит привлечь тех сотрудников, у которых есть специальные знания по объекту закупки. Это поможет четко отразить потребности заказчика, избежать жалоб и исключить разночтения при допуске участников. Также это оградит от поставки ненужного по сути товара.

Как составить (форма и структура)

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

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

Совет: Начинать готовить техническое задание стоит заранее. Это снизит риск того, что будут нарушены сроки публикации документации о закупке в ЕИС. Ведь контрактной службе (контрактному управляющему) необходимо от нескольких дней до нескольких недель, чтобы составить качественное техническое задание в зависимости от технической сложности объекта закупки.

Совет: Когда составляете техническое задание, имеет смысл руководствоваться:

• ГОСТами. Например, при создании автоматизированной системы - ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»;

• методическими указаниями (рекомендациями) учредителя. Например, Минкультуры России разработало Методические указания по порядку разработки технического задания при проведении закупок в рамках целевой программы «Культура России (2012-2018 годы)» (письмо Минкультуры России от 25 января 2013 г. № 446-01-56/10-НМ).

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

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

В этом разделе стоит указать такие данные заказчика:

• наименование;

• место нахождения заказчика;

• график работы.

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

Также в этот раздел можно включить информацию о совместной или централизованной закупке, а также о привлечении эксперта (экспертной организации).

2. Общая информация о закупке

Здесь стоит указать:

• полное наименование объекта закупки,

• выбранный способ определения поставщика (подрядчика, исполнителя),

• источник финансирования.

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

Термины и сокращения

Определение

ПО

При этом заказчику при описании технических и качественных характеристик необходимо использовать стандартные показатели (требования, условные обозначения и терминологию). Для этого нужно руководствоваться обязательными требованиями, в частности, ГОСТами, СНиПами, гражданским законодательством (ст. 469, 721 ГК РФ). Например, требования к качеству пищевых продуктов установлены в Федеральном законе от 2 января 2000 г. № 29-ФЗ.

Техническое задание важно и исполнителю, и клиенту. Исполнителю оно помогает лучше понять, что хочет заказчик, застраховаться от внезапных «хотелок» со стороны клиента, ускорить работу по выполнению задачи. Клиенту - рассказать точно о том, что он хочет, упростить контроль качества, получить точную стоимость услуги. Мы расскажем о том, как правильно составить ТЗ и что с ним потом делать.

Что такое техническое задание

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

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

• разработке приложений;
• проектировании дома;
• написании текстов и другие.

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

Как составить техническое задание: структура ТЗ на сайт

Прежде чем приступать к работе:

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

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

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

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

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

Опишите сайт

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

Если у проекта есть конкретная целевая аудитория, опишите ее. Это поможет создать ресурс, который понравится клиентам - например, использовать подходящие выражения в статьях или дизайн, который нравится молодежи или представителям старшего поколения.

Расскажите о структуре

Без представления о структуре невозможно разработать нормальный сайт. Распишите, какие страницы будут на сайте, и покажите уровни их вложенности. Сделать это можно разными способами:

• Схемой
• Таблицей
• Списком

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

Пример простейшей структуры в виде блок-схемы

Опишите, что будет на каждой из страниц

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

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

Пример прототипа главной страницы сайта: все просто, удобно, понятно

Выдвините требования к дизайну

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

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

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

Опишите требования к инструментам, коду, хостингу, домену

Это нужно, чтобы заранее знать, с какими инструментами можно работать, а с какими - нет. Опишите отдельным блоком:

• На какой должен находиться сайт - Вордпресс, Джумла, Модэкс и так далее
• Какой язык программирования можно использовать - PHP, JavaScript, HTML, другие
• На каком хостинге и в какой доменной зоне должен располагаться сайт, какое доменное имя можно использовать
• Какую программную платформу можно использовать - .NET, OpenGL, DirectX
• И так далее

Если клиент не понимает ничего в используемых терминах - объясните, чем отличается Вордпресс от Модэкса, PHP от HTML, домен в зоне.ru от домена в зоне.com. Вместе составьте требования так, чтобы они устроили клиента.

Уточните требования к работе сайта

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

• Приемлемую для вас скорость загрузки сайтов или стандартное значение - 1–5 секунд
• Кроссбраузерность - распишите, в каких браузерах сайт должен открываться
• Адаптивность - укажите размеры экранов, под которые должен подстраиваться дизайн, и используемые устройства
• Устойчивость к нагрузкам - сколько человек должно находиться на сайте одновременно, чтобы он не «лег»
• Устойчивость к хакерским и dDos-атакам: сайт должен выдержать небольшие атаки

Распишите сценарии работы сайта

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

Пример простейшего сценария работы сайта

Уточните, кто занимается контентом.

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

• - не меньше 95% по Адвего, Текст.ру, Контент.Вотч
• Тошноте (заспамленности)- не более 10% по Адвего иди 65% по Текст.ру
• Баллам по Главреду - не менее 6,5 или 7 баллов

Конечно, разные сервисы - не панацея, но они минимизируют риск того, что он будет «водянистым» или переспамленным. Кроме того, так появляются точные критерии оценки качества текстов.

Укажите сроки

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

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

Запомните: в каждом ТЗ должны быть несколько основных блоков:

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

Пример составления ТЗ на программное обеспечение

Нужно создать ПО. Технические требования - ниже.

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

Что должно делать ПО: после ввода ключевого слова находит статьи на сайтах, которые внесены заранее в качестве авторитетных источников, выводит список совпадений в таком формате:

• Линк
• Название статьи
• Лид-абзац

Если больше 10 совпадений, нужно разделить на страницы - по 10 на каждой.

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

Сроки : до 15.09.2018.

Естественно, это ТЗ можно улучшить - мы предоставили его в качестве примера. А как вы считаете, как можно доработать техническое задание, чтобы оно стало еще понятнее, проще, удобнее?

Определение содержания проекта, разработка ТЗ

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

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

Определение

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

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

ГОСТ 25123-82. Машины вычислительные и системы обработки данных. Техническое задание. Порядок построения, изложения и оформления.

ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

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

В говорится, что ТЗ позволяет:

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

заказчику - осознать, что именно ему нужно;

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

исполнителю - спланировать выполнение проекта и работать по намеченному плану;

заказчику - требовать от исполнителя соответствия продукта всем условиям, оговорённым в ТЗ;

исполнителю - отказаться от выполнения работ, не указанных в ТЗ;

заказчику и исполнителю - выполнить попунктную проверку готового продукта (приёмочное тестирование - проведение испытаний );

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

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

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

ТЗ выполняет четыре основных функции:

Юридическая. ТЗ является юридическим документом, и в виде приложения включается в договор между заказчиком и исполнителем.

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

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

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

Сущность ТЗ

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

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

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

Работа над ТЗ - сложный и ответственный этап, так как многие данные ещё не известны. Успех выполнения проекта по мнению специалистов на 50 -70% зависит от квалифицированного выполнения этапа разработки ТЗ.

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

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

ТЗ согласуется с заказчиком или разрабатывается совместно.

Несмотря на свою важность, содержание и структура ТЗ практически не регламентирован нормативными документами.

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

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

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

Ниже приведены примеры структуры ТЗ из различных источников.

Например ТЗ может содержать разделы :

предмет ТЗ;

цели проводимой работы;

требования к отчету;

порядок организации работы;

Пример из вышеупомянутого ГОСТ 19.201-78.

введение;

основания для разработки;

назначение разработки;

требования к программе или программному изделию;

требования к программной документации;

технико-экономические показатели;

стадии и этапы разработки;

порядок контроля и приемки;

в техническое задание допускается включать приложения.

Следующий пример ТЗ на оказание консультационных услуг

общие положения;

цель работы;

квалификационные требования к кандидатам.

Пример ТЗ на выполнение научно-исследовательской работы «Разработка концепции, стратегии развития и технико-экономического обоснования создания технико-внедренческого парка в г. Перми» (далее - НИР)

основание для выполнения НИР

исполнитель и соисполнители

1. задачи НИР

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

   основные требования к проведению НИР

   календарный план выполнения НИР

   предполагаемое использование результатов выполнения НИР

   порядок сдачи-приемки результатов НИР

Пример структуры шаблона ТЗ на выполнение НИОКР

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

Исполнитель

Сроки проведения работ

Цель выполнения работ

Результаты НИОКР

Разрабатываемая продукция

Технические требования

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

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

Требования по видам обеспечения (если применимо)

Требования по стандартизации, унификации, совместимости с сопрягаемыми объектами и взаимозаменяемости.

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

Требования надежности (если применимо)

Требования по безотказности и долговечности.

Требования по эргономике и технической эстетике (если применимо)

Требования к эксплуатации, удобству технического обслуживания и ремонтопригодности (если применимо)

Требования к устойчивости к внешним воздействиям (если применимо)

Требования к эксплуатационным показателям (если применимо)

Требования по сертификации

Прочие требования и специальные требования по отраслям

Требования к патентной чистоте и патентоспособности

Требования к документации

Порядок приемки работ.

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

Особенности разработки ТЗ инновационного проекта

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

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

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

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

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

Если каталог требований составляется на «языке клиентов», то расширенное ТЗ – на «языке предприятия». Расширенное ТЗ должно включать помимо традиционных пунктов (объем работ, отчетность, исходные данные, требования к параметрам и т.д.) и некоторые элементы бизнес-плана по проекту (предполагаемая политика ценообразования, планируемая доля рынка, планируемые обороты и т.д.).

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

В состав расширенного ТЗ могут включаются:

1. Описание проекта

2. Рыночные и экономические цели проекта

3. Временные параметры

4. Технические параметры

5. Производственные параметры

8. Требования к дизайну и эргономике

9. Нормы и предписания

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

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

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

Рассмотрим местоТЗ в структуреинновационного процесса в организации (внедрение инноваций в организации) согласно .

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

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

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

Когда ТЗ как документ утвержден, осуществляется планирование работ по проекту.

В большинстве крупных организаций внутрифирменные отношения «пользователь-отдел IT» неизбежны, особенно при создании рабочих приложений, необходимых пользователю на постоянной основе. Сложность этих отношений может быть обусловлена многими факторами, но чаще всего это непонимание, возникающее из-за того, что стороны говорят на разных «языках» с различной терминологией. Пользователь понимает, что он хочет, но не может это сформулировать, IT-специалист понимает пользователя, но опасается, что результат выйдет иным, чем видит это первый. Чаще всего проблема начинается с того, что именно пользователь не готов к диалогу: он требует «чтобы работало», «отчет одной кнопкой», «чтобы за минуту выводилось», «чтобы даты в Excel не вылезали» и прочее. При этом его совершенно не интересует, каким образом это делается и какие механизмы работают. На заявления о нагрузке на сервер, просьбы нарисовать схему желаемого результата, обсудить пути решения пользователь не реагирует, полагая, что настоящий профессионал со всем справится. Результаты такого непонимания вредят всему производственному процессу: затягиваются сроки решения задач, возникают ошибки и пробелы в системах, которые нужны пользователю, страдает перегруженный неверными действиями сервер, скорость работы снижается.

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

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

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

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

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

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

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

8. Если ваши подчиненные также будут пользоваться созданным приложением, постарайтесь им самостоятельно объяснить особенности работы с приложением – это избавит IT-специалиста от необходимости сто раз объяснять одно и то же.

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

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