Составление технического задания на выполнение работ. Как правильно составить техзадание. Основные рекомендации

Тема 3.

ОПРЕДЕЛЕНИЕ ПРОЕКТА

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

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

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

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

ЭТАП 1: РАЗРАБОТКА ТЕХНИЧЕСКОГО ЗАДАНИЯ

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

Исследования показывают, что плохая разработка технического зада­ния является наиболее частой преградой на пути к успеху проекта. Изуче­ние проекта строительства большого нефтеперерабатывающего завода, проведенное Смитом и Таккером, показало, что плохая разработка техни­ческого задания и нечеткое определение основных составляющих проек­та самым отрицательным образом сказались на его стоимости и графике работ. Пинто и Слевин доказали, что четкое определение целей больше, чем на 50% предопределяет успех на стадии формулирования концепции, планирования и выполнения проекта. Эшли и другие продемонстрирова­ли, что у выдающихся, успешных проектов были четко разработаны тех­нические задания и определены составляющие работы. Анализ Познера выявил, что, по мнению 60% респондентов-управляющих проектами, ос­новной проблемой является отсутствие четких целей.

В ходе работы с более, чем 1400 управляющими проектами в США и Канаде Гобелай и Ларсон установили, что около 50% проблем планирова­ния связаны с нечетким техническим заданием и постановкой целей. Все эти результаты указывают на прямую зависимость успеха проекта от чет­кого определения его ТЗ. Четкое ТЗ заставляет как заказчика, так и всех участников проекта концентрироваться на целях проекта.

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

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

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

Перечень вопросов по ТЗ:

1. Цели проекта.

2. Промежуточные результаты работы.

3. Контрольные точки.

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

5. Ограничения и исключения.

6. Проверка выполнения работы совместно с клиентом.

1. Цели проекта. Первым этапом в определении ТЗ является опреде­ление основных целей для удовлетворения потребностей клиента. Например, в результате глубокого анализа рынка компания, зани­мающаяся компьютерными программами, решает разработать про­грамму, способную автоматически переводить с английского на русский. Проект должен быть выполнен за три года при затратах, не превышающих $1,5 млн. Или такой проект - спроектировать и выпустить полностью портативную систему термической перера­ботки вредных отходов за 13 месяцев при затратах, не превышаю­щих $13 млн.

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

3. Контрольные точки. Контрольная точка - это значительное ме­роприятие в процессе работы над проектом, которое происходит в определенный момент времени. График контрольных точек отра­жает только основные сегменты работы; он показывает первую, приблизительную оценку затрат времени, стоимости и необходи­мых ресурсов для проекта. Этот график составляется с использо­ванием промежуточных результатов работы, как основы для опре­деления основных сегментов работы и конечной даты. Например, испытания проведены и полностью выполнены к 1 июля этого года. Контрольные точки должны быть естественными и важными точ­ками контроля. Они должны быть понятны всем участникам про­екта. График контрольных точек должен установливать, какие ос­новные подразделения организации будут отвечать за основные сегменты работы и обеспечивать проект необходимыми ресурса­ми и специалистами.

4. Технические требования. Обычно товар или услуга для того, что­бы хорошо работать, должны отвечать техническим требованиям. Например, техническим требованием к ПК может быть способ­ность работать от сети переменного тока в 120 вольт или от посто­янного тока в 240 вольт без адаптеров. Еще одним известным при­мером является способность системы 911 определить местонахож­дение и номер телефона звонящего.

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

6. Проверка выполнения работы совместно с заказчиком. Кон­трольный список вопросов ТЗ проекта заканчивается совместной с заказчиком проверкой выполнения работы. Основной проблемой является понимание и согласие заказчика с ожидаемыми результа­тами. Получает ли заказчик в виде промежуточных результатов то, что он хочет? Указывает ли определение проекта ключевые достиже­ния, сметы, сроки и требования к выполнению работ? Рассматрива­ются ли вопросы ограничений и исключений? Обсуждение всех этих вопросов крайне необходимо во избежание недопонимания.

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

©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-02-16

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

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

1. Каскадная модель.

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

В каскадной модели стадии создания СЭД идут одна за другой, результаты одной стадии перерастают в результаты следующей. При этой модели возврат на предыдущую стадию достаточно проблематичен и требует переработки и переосмысления многих постулатов проекта. Именно по этой методологии построены российские ГОСТы.

2. Итерационная модель.

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

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

Какой из этих подходов правильный - зависит от конкретного проекта (объема задач проекта) и от пожеланий заказчика.

Тем не менее, независимо от выбранной модели разработки, в каждой из них есть стадия формирования требований к создаваемой СЭД. Эта стадия и правила создания самого ТЗ описаны в российском законодательстве, а именно в ГОСТах 34-й серии. Основные документы - ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание авто­матизированной системы и РД 50-34.698-90. Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов.

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

Состав технического задания

Согласно ГОСТ 34.602-89, основными разделами ТЗ являются:

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

2. Назначение и цели создания (развития) системы.

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

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

5. Состав и содержание работ по созданию системы.

6. Порядок контроля и приемки системы.

7. Требования к составу и содержанию работ по подготов­ке объекта автоматизации к вводу системы в действие.

8. Требования к документированию.

9. Источники разработки.

Все эти разделы могут быть разбиты на подразделы и могут включать приложения, которые приводятся в конце документа и оформляются как приложения к ТЗ. Такой же состав имеет и ЧТЗ, которое может создаваться при итерационном подходе в больших проектах для уточнения требований. ТЗ на СЭД должно оформляться на листах формата А4 по ГОСТ 2.301-68* без рамки, основной надписи и дополнительных граф к ней.

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

Титульный лист ТЗ содержит следующие реквизиты:

Гриф «Утверждаю»;

Полное наименование СЭД;

Наименование документа (в нашем случае - «Техническое задание» и «Частное техническое задание»);

Код документа;

Количество листов;

Место составления документа.

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

Код ТЗ на СЭД - это обозначение конструкторского документа, которое присваивается заказчиком или разработчиком документа согласно ГОСТ 2.201-80**. Код состоит из следующих частей: первые 4 символа - код организации-разработчика, следующие 6 символов - код классификационной характери­стики, следующие 3 цифры - порядковый регистрационный номер. Например, номер ТЗ может выглядеть так:

ЦНТП. 425180.048.

Особенности написания некоторых разделов ТЗ

Раздел «Общие сведения » должен включать сведения о заказчике и возможном исполнителе работ, о способе определения исполнителя, бюджете, из которого финансируется создание СЭД, и примерных сроках и этапах проведения работ по созданию СЭД.

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

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

Например, целью внедрения СЭД может быть сокращение сроков согласования договоров до 1 рабочего дня по всем филиалам компании.

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

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

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

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

2. Требования к функциям (задачам), выполняемым систе­мой, должны содержать описание функционала подсистем (модулей) СЭД.

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

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

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

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

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

7. Требования к администрированию системы с описанием ролей и обязанностей администраторов системы.

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

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

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

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

Раздел «Требования к документированию» описывает общие правила составления рабочей документации к системе и может ссылаться на корпоративные стандарты или ГОСТы.

Раздел «Источники разработки » является заключительным и перечисляет документы, которые послужили основой для разработки системы и принятия тех или иных технических решений.

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

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

* ARIS (англ. Architecture of Integrated Information Systems) – принадлежащие компании Software AG методология и тиражируемый программный продукт
для моделирования бизнес-процессов организаций.
** UML (англ. Unifi ed Modeling Language) – язык графического описания для объектного моделирования в области разработки программного обеспечения; был создан для определения, визуализации, проектирования и документирования в основном программных систем.

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

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

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

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

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

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

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

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

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

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

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

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

Кто должен составлять техзадание

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

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

Структура технического задания

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

Структура документа ТЗ:

1. Оглавление
2. История изменений
3. Терминология
4. Общие сведения о проекте (назначение, цели и задачи проекта)
5. Требования к проекту (функциональные, пользовательские, общие и другие требования)
6. Требования к видам обеспечения
7. Требования к документированию
8. Стадии и этапы разработки
9. Порядок контроля и приемки проекта
10. Дополнительные материалы

Рассмотрим подробнее каждый пункт структуры.

Понятно из названия, перечень всех частей технического задания.

2. История изменений

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

3. Терминология

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

4. Общие сведения о проекте

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

5. Требования к проекту

Один из самых объемных и также основной пункт в техзадании. В нем описываются абсолютно все требования к проекту, такие как:

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

6. Требования к видам обеспечения

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

7. Требования к документированию

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

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

8. Стадии и этапы разработки

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

9. Порядок контроля и приемки проекта

В этом разделе описывается порядок приема проекта, система тестов.

10. Дополнительные материалы

В дополнительные материалы могут входить разного рода документы, которые могут быть использованы в процессе разработки. Это могут быть ссылки на ресурсы, материалы, которые могут быть полезны исполнителю.

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

1. Желательно по максимуму использовать графические материалы. Часто бывает так, что одна схема или диаграмма может заменить несколько страниц текста.
2. Не использовать расплывчатых, двусмысленных описаний. Все должно быть описано четко и понятно.
3. Описание проекта должно быть логически связным и не иметь противоречий.
4. Необходимо указывать абсолютно все данные и требования, даже те, которые на первый взгляд могут показаться абсурдными. Такими данными могут быть поля в форме регистрации, формат даты в статье и прочее.
5. При указании сроков, необходимо учитывать, что неотъемлемой частью разработки является тестирование и исправление ошибок, поэтому в очень короткие сроки можно не вложится.
6. После выбора исполнителя необходимо совместно просмотреть ТЗ, возможно появятся новые вопросы или дополнения.

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

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

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

Определение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сущность ТЗ

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

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

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

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

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

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

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

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

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

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

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

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

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

предмет ТЗ;

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

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

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

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

введение;

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

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

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

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

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

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

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

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

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

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

цель работы;

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

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

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

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

1. задачи НИР

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

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

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

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

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

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

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

Исполнитель

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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