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

Как составить техническое задание и получить то, что нужно

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

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

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

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

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

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

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

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

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

Устоявшейся практики нет — как договоритесь с подрядчиком.

Заказчик делает сам

Например, гендиректор студии архитектурной фотографии «АрхФото» Анатолий Шостак называет идеальным заказом ситуацию, когда заказчик сразу присылает подробное ТЗ и просит оценить работы.

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

Анатолий Шостак
Гендиректор «АрхФото»

Совместная работа

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

Техзадание полностью делает исполнитель

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

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

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

Сколько стоит заказать ТЗ

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

Основатель компании по разработке информационных систем Work Solutions Максим Мул при заказе ТЗ рекомендует ориентироваться на 10-20 % от общей стоимости разработки продукта.

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

Максим Мул
Основатель Work Solutions

Если речь про IT-задачи, например, интеграцию между информационными системами, внедрение CRM, разработку дополнительного функционала ПО или приложения по API, то не стоит рассчитывать на ТЗ стоимостью меньше 50 000 руб., считает гендиректор компании «Информатика и Сервис» Владимир Севрук.

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

Владимир Севрук
Гендиректор компании «Информатика и Сервис»

Платные подробные ТЗ применяют и в других сферах. Например, в архитектурной фотографии.

У нас есть более сложная форма ТЗ — мы называем ее «сценарий». Для сценария мы проводим предварительные съемки, прописываем и согласовываем все ракурсы с заказчиком, прорабатываем целевую аудиторию и рассчитываем тайминг каждого кадра с учетом движения солнца. И все это ещё до начала чистовой работы.

Анатолий Шостак
Гендиректор «АрхФото»

За составление такого подробного сценария в «АрхФото» берут деньги. В зависимости от сложности проекта и требований заказчика сценарий иногда стоит дороже самой съемки. Зато благодаря ТЗ заказчик еще до начала работ понимает, что получит в итоге, говорит Анатолий Шостак.

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

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

Пишите однозначно

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

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

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

Алексей Орлов
Руководитель проектов компании «Рексофт»

Стоит попробовать любые пожелания сводить к количественным требованиям.

Дайте подрядчику общую информацию

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

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

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

Максим Болотов
Гендиректор INOSTUDIO

Помогите разобраться в терминах и нюансах

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

Можно ввести отдельный раздел в виде словаря с расшифровкой или пояснять по ходу документа.

Покажите конкурентов

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

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

Максим Болотов
Гендиректор INOSTUDIO

Уточните важные технические требования

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

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

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

Распишите сценарии использования продукта

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

Если речь про IT-продукты, можно прописывать сценарии по такому шаблону:

Опишите требования к проверке проекта

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

Например, для интернет-магазина это может быть:

Чем подробнее и длиннее чек-лист, тем лучше.

Двигайтесь от общего к частному

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

Шаблоны и примеры ТЗ

Универсального шаблона технического задания нет — требования будут отличаться в зависимости от отрасли и типа проекта.

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

Если планируете заказать IT-продукт, можно использовать за основу госстандарты. Например:

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

Когда ТЗ не нужно

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

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

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

Вместо ТЗ выгоднее сначала сделать предпроектное обследование, изучить реальные потребности клиентов, вместе с аналитиком подрядчика. А затем решать, нужно ли ТЗ вообще.
Может быть, выгоднее и эффективнее выполнять бизнес-задачу, например, с помощью SCRUM. Действуя небольшими итерациями в 1-2 недели, анализируя результат и постепенно дополняя требования.

Владимир Севрук
Гендиректор компании «Информатика и Сервис»

Кратко — универсальные советы по составлению ТЗ

Составляя ТЗ самостоятельно или с подрядчиком, придерживайтесь следующих правил:

Не пропустите новые публикации

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

Источник

Составляем техническое задание для закупок по 44-ФЗ

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

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

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

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

Чем отличается техзадание от описания объекта заказа

Техзадание входит в состав закупочной документации, а описание объекта госзакупки, в свою очередь, является обязательной частью ТЗ. Но какие-либо требования к техническому заданию по 44-ФЗ не установлены, а вот описание предмета торгов регламентируется законодательными нормативами (ст. 33 44-ФЗ).

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

Базируется составление технического задания по 44-ФЗ на государственных стандартах (ГОСТ) формирования и ведения программной документации. Но заказчик не обязан использовать форму ТЗ по ГОСТу. Это вспомогательная мера, которая упрощает разработку корректных закупочных документов. Межгосударственные стандарты используются в зависимости от отраслевой принадлежности организации-заказчика или специфичности приобретаемых товаров, работ или услуг.

Требования к техзаданию

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

Установлены общие рекомендации к структуре. Бланк состоит из разделов, описывающих сводную информацию о госзаказе, данные об объекте торгов, требования к потенциальным исполнителям, существенные условия госконтракта и дополнительные сведения. В процессе формирования ТЗ специалисты вправе воспользоваться всеми открытыми и доступными для пользователей сервисами. К ним относятся:

В техническом задании прописывают наименование объекта госзаказа, основные требования и условия к нему. Название предмета заказа приводится на основании действующего каталога товаров, работ, услуг (КТРУ) (утв. ПП РФ № 145 от 06.02.2017). Изучив искомую позицию в КТРУ, специалист заказчика описывает объект госзаказа в строгом соответствии с конкретной строкой каталога.

В случае несовпадения прописанных в КТРУ характеристик и описания заказчика ответственный специалист приводит письменное обоснование, указывая требуемое наименование закупаемого объекта (правила, закрепленные постановлением правительства № 555 от 05.06.2015). В техническом задании описывается конечный результат закупки в части товаров, работ и услуг, учитывающий все потребности заказчика. Формирование описательной части нормируется статьей 33 44-ФЗ. Эти правила учитывают и при разработке всего техзадания:

Как составить техническое задание: пошаговая инструкция

Разработка должна происходить поэтапно, так как техническое задание состоит из нескольких разделов. Инструкция, как подготовить техзадание на аукцион по 44-ФЗ, чтобы выиграть в части оптимального поставщика и качественных товаров, работ, услуг:

Источник

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

Система разработки и постановки продукции на производство

Требования к содержанию и оформлению

System of products development and launching into manufacture. Technical assignment. Requirements to contents and form of presentation

Дата введения 2017-09-01

Предисловие

Цели, основные принципы и общие правила проведения работ по межгосударственной стандартизации установлены ГОСТ 1.0 «Межгосударственная система стандартизации. Основные положения» и ГОСТ 1.2 «Межгосударственная система стандартизации. Стандарты межгосударственные, правила и рекомендации по межгосударственной стандартизации. Правила разработки, принятия, обновления и отмены»

Сведения о стандарте

1 РАЗРАБОТАН Федеральным государственным унитарным предприятием «Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении» (ВНИИНМАШ)

2 ВНЕСЕН Федеральным агентством по техническому регулированию и метрологии

3 ПРИНЯТ Межгосударственным советом по стандартизации, метрологии и сертификации (протокол от 25 октября 2016 г. N 92-П)

За принятие проголосовали:

Краткое наименование страны по МК (ИСО 3166) 004-97

Сокращенное наименование национального органа по стандартизации

Минэкономики Республики Армения

4 Приказом Федерального агентства по техническому регулированию и метрологии от 14 марта 2017 г. N 135-ст межгосударственный стандарт ГОСТ 15.016-2016 введен в действие в качестве национального стандарта Российской Федерации с 1 сентября 2017 г.

6 ПЕРЕИЗДАНИЕ. Июль 2020 г.

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

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

1 Область применения

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

2 Нормативные ссылки

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

ГОСТ 2.001 Единая система конструкторской документации. Общие положения

ГОСТ 2.102 Единая система конструкторской документации. Виды и комплектность конструкторских документов

ГОСТ 2.103 Единая система конструкторской документации. Стадии разработки

ГОСТ 2.105 Единая система конструкторской документации. Общие требования к текстовым документам

ГОСТ 2.116 Карта технического уровня и качества продукции

ГОСТ 2.118 Единая система конструкторской документации. Техническое предложение

ГОСТ 2.119 Единая система конструкторской документации. Эскизный проект

ГОСТ 2.120 Единая система конструкторской документации. Технический проект

ГОСТ 2.301 Единая система конструкторской документации. Форматы

ГОСТ 2.601 Единая система конструкторской документации. Эксплуатационные документы*

* В Российской Федерации действует ГОСТ Р 2.601-2019.

ГОСТ 3.1001 Единая система технологической документации. Общие положения

ГОСТ 3.1102 Единая система технологической документации. Стадии разработки и виды документов. Общие положения

ГОСТ 14.201 Обеспечение технологичности конструкции изделий. Общие требования

ГОСТ 15.012 Система разработки и постановки продукции на производство. Патентный формуляр

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

ГОСТ 27.003 Надежность в технике. Состав и общие правила задания требований по надежности

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

ГОСТ 16504 Система государственных испытаний продукции. Испытания и контроль качества продукции. Основные термины и определения

ГОСТ 19433 Грузы опасные. Классификация и маркировка

ГОСТ 21964 Внешние воздействующие факторы. Номенклатура и характеристики

ГОСТ 28934 Совместимость технических средств электромагнитная. Содержание раздела технического задания в части электромагнитной совместимости

3 Термины и определения

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

3.1 техническое задание (ТЗ): Исходный технический документ для проведения работы, устанавливающий требования к создаваемому изделию (его СЧ или КИМП) и технической документации на него, а также требования к объему, срокам проведения работы и форме представления результатов.

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

3.3 разработчик: Предприятие (организация, объединение, юридическое или физическое лицо), осуществляющее разработку продукции в установленном порядке.

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

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

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

[ГОСТ 27.002-89, пояснение к термину «Надежность»]

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

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

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

3.10 рабочая конструкторская документация (РКД): Совокупность конструкторских документов, предназначенных для изготовления, контроля, приемки, поставки, эксплуатации и ремонта изделия.

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

4 Сокращения

В настоящем стандарте применены следующие сокращения:

Источник