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

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

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

Определение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сущность ТЗ

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

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

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

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

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

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

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

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

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

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

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

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

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

предмет ТЗ;

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

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

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

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

введение;

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

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

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

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

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

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

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

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

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

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

цель работы;

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

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

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

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

1. задачи НИР

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

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

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

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

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

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

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

Исполнитель

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Любые , в идеале, должны сопровождаться техническим заданием. Это, во-первых, четкое определение задачи, сроков и метода выполнения. Во-вторых, это документ, с помощью которого решаются все спорные моменты в будущем. Писать ТЗ или нет — дело, конечно, Ваше, лично мне ТЗ облегчает работу и общение с клиентом.

Получите 267 видеоуроков по 1С бесплатно:

Что должно содержать в себе техническое задание?

Тех. задание обязательно должно содержать в себе:

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

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

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

Примеры и образцы ТЗ для 1С

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

От автора : Как написать техническое задание на разработку сайта ? Тема достаточно обширная, и в рамках одной статьи ее сложно разобрать на все 100% (если вообще это возможно). Но общие положения, то, что нужно учесть, на что следует обратить внимание при составлении ТЗ, я постараюсь достаточно подробно изложить в данной статье.

Итак, ТЗ

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

Давайте проанализируем такой пример:

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

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

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

Что мы имеем. Исполнитель пункт ТЗ выполнил, а вы хотели совсем другой календарь. Вроде все в соответствии с ТЗ, никто не виноват, до конфликта не дошло, но самое главное потеряны время и деньги .

Это пример всего-то банального календаря.

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

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

Из каких пунктов обычно состоит ТЗ?

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

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

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

Поехали по пунктам.

Описание сайта

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

для кого – целевую аудиторию сайта :

• потенциальные покупатели
• продавцы продукции (магазины, интернет-магазины)
• сервисные центры
• партнеры (фирмы)
• потребители продукции (тот, кто уже купил)

Для чего нужен сайт :

• Для повышения имиджа компании
• Для увеличения продаж
• Для удобства клиентов

Тип сайта :

• Корпоративный
• Сайт – визитка
• Интернет магазин

Языковые версии :

• Английский
• Русский

Сайт должен решать какие-то задачи. Соответственно далее двигаемся по целям и задачам сайта.

Цели и задачи сайта

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

Потенциальные покупатели продукции .

Цель : привлечь больше покупателей и убедить сделать первую покупку, помочь сделать выбор.

Необходимо решить задачи :

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

• Дать информацию о салонах-магазинах
• Дать информацию о розничной торговой сети

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

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

Теперь перечисляем модули сайта.

Функционал сайта

Для того чтобы перечислить функционал сайта, нужно решить что ему необходимо:

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

После того, как все это описали, мы подбираемся к самому главному и интересному. Конечно, вся проделанная выше работа очень важна, но теперь становиться еще «жарче».

Описание функционала сайта

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

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

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

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

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

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

О компании

• история компании
• контакты
• отзывы

Новости

• события
• акции
• новое на сайте

Продукция

• каталог продукции
• релизы
• отзывы о продукции

Сервис

• служба сервиса
• гарантийное обслуживание
• послегарантийное обслуживание

Потребителю

• покупка и доставка
• пользование
• о сервисе

Магазинам и интернет магазинам

• фотографии продукции
• Часто задаваемые вопросы

Сервисным центрам

• Как стать сервисным центром
• Часто задаваемые вопросы

Партнерам

• приглашение к сотрудничеству
• часто задаваемые вопросы

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

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

Главное теперь описать логику работы.

Логика работы

Я описывать буду исходя из рисунка выше.

Верхняя часть сайта остается неизменной на каждой странице сайта. Новостная лента видна только на главной странице. На второстепенных страницах слева показываем подпункты меню того пункта, в котором в данный момент находимся (например если мы на странице «служба сервиса», то показываем ссылки на «гарантийное обслуживание», «послегарантийное обслуживание»). Соответственно и переходы по этим ссылкам ведут на соответствующие страницы. Здесь же, под подпунктами слева отображаем данные для связи с он-лайн консультантами (Skype, ICQ). Блок акции и релизы остаются на каждой странице. Подвал сайта отображается один и тот же на каждой странице.

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

Теперь подробно описываем каждый блок. Например «Новостная лента».

«Новостная лента» из 10-ти последних новостей. Каждая новость должна состоять из заголовка новости, даты публикации, краткого начала новости (4-5 строк) и ссылки «читать полностью». При нажатии на ссылку «читать полностью» попадаем на страницу новостей. Новость, на которую попали, отображается на месте основного содержимого. Включает также заголовок новости, дату публикации. Слева так же отображается новостная лента. Новости за прошлые месяцы и года попадают в архив. То есть под новостями за текущий месяц отображаем «архив за (такой-то месяц или год)». При нажатии на ссылку «архив за (такой-то месяц или год)» вниз выпадает список новостей за соответствующий месяц/год.

Примерно так описываем работу каждого блока. Не забываем про случай с календарем. И самое главное нужно расписать работу каталога товара. Здесь я даю вам задание : попробуйте продумать и описать, как будет работать каталог. Свои варианты присылайте на e-mail. Лучший мы опубликуем.

Что еще должно быть? Неплохо было бы указать совместимость.

Совместимость

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

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

Заключение

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

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

И не забывайте про задание!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Термины и сокращения	Определение
ПО	Программный продукт «Зарплата-Бюджет», который является объектом закупки
Заказчик	Государственное учреждение «Альфа»
Эксперт	Специалист, который обладает специальными знаниями в области бухгалтерского учета и налогообложения в бюджетной сфере, в кадровых и юридических вопросах, имеющий высшее профильное образование

3. Описание объекта закупки

В этом разделе необходимо наиболее полно и точно описать следующее.

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

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

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

Совет: Не стоит применять точные значения показателей. Лучше заменить их на условия с максимальными и (или) минимальными значениями, а также значениями, которые не могут меняться. То есть такие показатели, которые позволят участникам определить, соответствуют ли закупаемые товары (работы, услуги) установленным требованиям. Например, при закупке системного блока правильнее будет указать в техническом задании «Объем жесткого диска - не менее 500 Гб», а не «Объем жесткого диска - 500 Гб».

Об этом сказано в части 2 статьи 33 Закона № 44-ФЗ и разъяснено в письме Минэкономразвития России от 10 декабря 2014 г. № Д28и-2796.

2. Эксплуатационные характеристики (при необходимости).

3. Общее количество товаров (объем работ, услуг). Когда это сделать невозможно, заказчик может указать цену единицы работы (услуги).

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

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

6. Сроки и порядок поставки товара, выполнения работы, оказания услуги. В частности, нужно определить место поставки товара (выполнения работы, оказания услуги). При этом можно указать:

• конкретный адрес доставки;

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

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

7. Гарантийный срок и гарантийное обслуживание (ч. 4 ст. 33 Закона № 44-ФЗ). Гарантийный срок нужно установить в днях, месяцах и годах.

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

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

8. Другие характеристики, являющиеся важными при описании конкретного вида товара, работы, услуги. Так, при покупке товара в техническом задании заказчику обязательно нужно указать, что он должен быть новым и свободным от прав третьих лиц. То есть никто не использовал и не ремонтировал товар ранее. В противном случае заказчик рискует получить товар, бывший в употреблении. Об этом сказано в пункте 7 части 1 статьи 33 Закона № 44-ФЗ.

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

• обучение сотрудников;

• требования по монтажу и наладке;

• сервисное обслуживание;

• соответствие образцу и т. д.

Перечень сведений и требований может варьироваться в зависимости от каждого конкретного объекта закупки.

Пример описания объекта закупки

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

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

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

Совет: В качестве источника информации стоит использовать:

• ранее исполненные контракты,

• общедоступные источники (каталоги, прайсы, рекламные буклеты и др.),

• коммерческие предложения,

• информацию из Интернета.

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

Внимание! Если заказчик в документации о закупке укажет сведения, которые могут привести к ограничению количества участников, то возникнет риск понести административную ответственность. Так, на должностных лиц (контрактный управляющий, сотрудники контрактной службы) могут наложить штраф в размере 1 процента начальной (максимальной) цены контракта (НМЦК), но не менее 10 000 руб. и не более 50 000 руб. (ч. 4.1 ст. 7.30 КоАП РФ).

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

• указать средства труда, используемые при выполнении работ или услуг, но не в качестве предмета контракта. При этом обязательным условием является указание формулировки «или эквивалент»;

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

• приобрести запчасти или расходные материалы к машинам и оборудованию заказчика.

Об этом сказано в пункте 1 части 1 статьи 33 Закона № 44-ФЗ.

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

• по охране объекта при помощи средств охранно-пожарной сигнализации и

• по техническому обслуживанию самой сигнализации.

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

Это следует из части 3 статьи 17 Федерального закона от 26 июля 2006 г. № 135-ФЗ и разъяснено в письмах Минэкономразвития России от 10 марта 2015 г. № Д28и-442, ФАС России от 21 мая 2014 г. № АЦ/20578/14.

Поэтому при планировании закупки и составлении документации заказчику нужно проанализировать этот момент и при необходимости:

• разбить закупку на отдельные лоты,

• для каждого лота составить отдельное техническое задание.

4. Требования к поставщику (подрядчику, исполнителю)

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

Кроме того, в некоторых случаях Правительство РФ может установить дополнительные требования к участникам закупки, в частности, к наличию финансовых, материальных ресурсов, опыта работы, аналогичного предмету контракта (ч. 2 ст. 31 Закона № 44-ФЗ). Так, в постановлении Правительства РФ от 4 февраля 2015 г. № 99 есть дополнительные требования к участникам закупки на работы по сохранению объектов культурного наследия. Участник такой закупки должен представить сведения о контракте, который он исполнил без штрафных санкций в течение последних трех лет. Сумма такого контракта должна быть не менее 20 процентов НМЦК, на заключение которого проводят закупку.

Г О С У Д А Р С Т В Е Н Н Ы Й С Т А Н Д А Р Т С О Ю З А С С Р

Единая система программной документации	ГОСТ 19.201-78 (СТ СЭВ 1627-79)
ТЕХНИЧЕСКОЕ ЗАДАНИЕ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ И ОФОРМЛЕНИЮ
United system for program documentation. Technical specification for development. Requirements to contents and form of presentation

Постановлением Государственного комитета СССР по стандартам от 18 декабря 1978 г. № 3351 срок введения установлен

с 01.01. 1980 г.

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

Стандарт полностью соответствует СТ СЭВ 1627-79.

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляются в верхней части листа над текстом.

1.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78 .

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

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

1.4. Техническое задание должно содержать следующие разделы:

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

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

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

(Измененная редакция, Изм. № 1)

2.2. В разделе «Основания для разработки» должны быть указаны:

• документ (документы), на основании которых ведется разработка;
• организация, утвердившая этот документ, и дата его утверждения;
• наименование и (или) условное обозначение темы разработки.

(Измененная редакция, Изм. № 1)

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

2.4. Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:

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

(Измененная редакция, Изм. № 1)

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

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

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

2.4.4. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.

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

При необходимости должна обеспечиваться защита информации и программ.

(Измененная редакция, Изм. № 1)

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

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

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

(Введен дополнительно, Изм. № 1).

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

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

2.7. В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы.

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

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

Переиздание (Ноябрь 1987 г.) с Изменением № 1, утвержденным в июле 1981 г (ИУС 7-81)