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

Содержание

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

Согласно нормам 44-ФЗ образец технического задания по ГОСТУ заказчику разрабатывать не обязательно. Но на всех последующих этапах, начиная от разработки и подписания документации и заканчивая исполнением контракта, заказчик в большей или меньшей степени обращается к ТЗ. Особую значимость оно приобретает на этапе приемки продукции. Поэтому целесообразно иметь подобный документ и понимать основные правила и принципы его разработки.

Как правило, заказчик разрабатывает такое ТЗ, которое участнику дает полную картину о потребности в конкретной закупке.
Чаще всего оно состоит из следующих разделов.

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

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

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

Как обеспечить качество поставок?

В правоотношениях по контрактной системе под качественным товаром понимается товар, соответствующий договору. Общие требования к качеству товаров работ и услуг (ТРУ) прописаны в ст. 469, ГК РФ:

  • качество ТРУ должно соответствовать договору;

  • ТРУ должны соответствовать обязательным требованиям, а также предусмотренным договором повышенным требованиям;

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

  • допускается требовать соответствия товара образцу или изображению;

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

Рассмотрим некоторые нюансы.

Пригодность для конкретных целей.

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

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

* Федеральный закон от 26.07.2006 № 135-ФЗ «О защите конкуренции».

** Постановление Правительства РФ от 08.02.2017 № 145 «Об утверждении Правил формирования и ведения в единой информационной системе в сфере закупок каталога товаров, работ, услуг для обеспечения государственных и муниципальных нужд и Правил использования каталога товаров, работ, услуг для обеспечения государственных и муниципальных нужд».

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

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

Возникли сомнения – изучите подход контролирующих органов (регионального УФАС, центрального аппарата), посмотрите судебную практику.

Из чего состоит ТЗ

Общая информация

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

Статус текущего документа и конфиденциальность.

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

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

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

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

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

Информационная архитектура и интерфейс

  1. Структуру сайта. Это так называемые высокоуровневые прототипы.
  2. Шаблоны страниц. Низкоуровневые прототипы, описывающие непосредственно интерфейс сайта.
  3. Опись контента. Табличное описание содержания каждой страницы сайта.

Структура сайтаGarrett

  • Не жалейте места. Старайтесь располагать блоки так, чтобы они были отделены друг то друга. Это поможет читабельности карты.
  • Не мельчите. Прочитать текст, напечатанный 4 кеглем, в принципе можно, но это уже причина для ненависти.
  • Выравнивайте «квадратики» страниц относительно друг друга, выстраивая в линии. Это улучшит восприятие уровней вложенности страниц.
  • Не пересекайте линии. Старайтесь избегать большого количества пересечений линий связей. Если они пересекаются, то должны «перескакивать» одна над другой. Кто занимался черчением функциональных схем в университете, меня поймет.
  • Подписывайте карту. Подпишите саму карту, а также отдельные блоки. Это позволит меньше путаться в дальнейшем.
  • Почаще сохраняйте файл. Банально, но надо просто помнить об этом. Не стоит лишний раз вспоминать родственников разработчиков программы Visio, в сущности, они ни в чем не виноваты.

Пример карты сайта.Шаблоны страниц

  1. Перечень шаблонов. Выявляются основные типы страниц и описывается их использование.
  2. Типовой шаблон. Основные блоки. Описываются основные блоки страниц с целью уменьшить повторяемость информации.
  3. Описание каждого шаблона согласно перечня. Шаблоны отрисовываются в любом графическом пакете (Adobe Illustrator, Adobe InDesign, MS Visio и др.), а затем дополняются кратким описанием.

ОговоркаПример разворота из ТЗ с описанием шаблона интерфейса (вайрфрейма).Описание контента

Требования

  • Технические требования к системе;
  • Требования к персоналу;
  • Требования к надежности;
  • Требования к эргономике и технической эстетике;
  • Требования к защите информации от НСД;
  • Требования по сохранности информации при авариях;
  • Требования к видам обеспечения;
  • Требования к программным средствам;
  • Требования к информационному обеспечению;
  • Требования к техническим средствам;

Типовая форма технического задания на проектирование

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

В текстовой и табличной форме с пояснениями:

Скачать форму техзадания на проектирование в текстовой форме с пояснениями:

  • ТЗ в формате ворд (word) (docx)
  • ТЗ в формате pdf

Скачать форму техзадания на проектирование в табличной форме с пояснениями:

  • ТЗ в табличной форме в формате ворд (word) (docx)
  • ТЗ в табличном форме в формате pdf

В текстовой и табличной форме без пояснений:

Скачать форму техзадания на проектирование в текстовой форме без пояснений:

  • ТЗ без пояснений в формате ворд (word) (docx)
  • ТЗ без пояснений в формате pdf

Скачать форму техзадания на проектирование в табличной форме без пояснений:

  • ТЗ без пояснений в табличной форме в формате ворд (word) (docx)
  • ТЗ без пояснений в табличной форме в формате pdf

10 правил, написанных слезами разработчика

Техническое задание на доработку должно быть ТЗ на доработку Техническое задание не должно быть жадным. Яркий пример избыточности буквально из вчерашнего дня: клиент купил ERP одной известной российской компании, думая, что раз работает бухгалтерский учёт, то и ERP этого вендора будет хороша. ERP оказалась не то чтобы не очень сама по себе, но очень не подходящей бизнесу. А вот RegionSoft CRM со складским учётом и производством подходит. Есть решение: забыть про ERP, поплакать, интегрировать учёт 1С с новой CRM и радоваться удобной реализации. Но вбуханных денег жалко! И клиент требует интегрировать CRM с ERP. Мы и не такое делали, но зачем такая трата, зачем две относительно схожих системы? Техническое задание должно быть реалистичным и выполнимымНапример, RegionSoft CRM — десктопная программа, у нас нет клиента для браузера. Просить нас создать web-приложение для одной компании бессмысленно, это крупная разработка, она сейчас ведётся и не является возможной доработкой для одной компании. Нет, конечно, всё имеет свою цену, но опять же — в общем случае требование невыполнимое. Техническое задание должно быть подробным.например, расчёт дилерских бонусовДа, корпоративный софт выглядит примерно так, и в нём много важных мелочей Техническое задание должно быть однозначным и точным.благими намерениями устлана дорога в адВ этом году ты можешь снова загадать одно желание. Только, прошу, не трать его на то, что даже я не смогу выполнить, типа понятных бизнес-требований! Техническое задание должно быть написано на человеческом языке.

  1. Клиент пытается продемонстрировать свою техническую грамотность и городит конструкции типа: «имплементировать окно с хинтом в тело календаря с возможностью реакции на колл события…» вместо «в календаре должно всплывать окно, в котором можно отметить задачу как выполненную». Если у вас или вашего внутреннего эксперта нет навыков написания технических текстов, не гуглите — пишите обычными словами, мы их понимаем.
  2. ТЗ переполнено грамматическими ошибками. Нужно не только избавиться от расплывчатых описаний и метафор (из реального: «Чтобы компьютер не пищал, будто помирает в судорогах»), лишних слов, слов-паразитов. Проверяйте пунктуацию – зачастую ошибки в ней искажают смысл требования. Задание на проект – это документ и лексика в нём должна быть соответствующая, а грамотность — близкая к 100%.

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

Концепция автоматизации многопрофильного Холдинга в системе АУБ на платформе 1С

Это схема и обоснование концепции системы АУБ (Автоматизация Управления Бизнесом, авторская разработка) для автоматизации многопрофильного холдинга на платформе 1С.

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

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

Зачем составлять ТЗ для сайта?

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

Какие конкретные преимущества даёт обеим сторонам правильно подготовленное ТЗ для сайта? Мы подготовили для вас несколько аргументов в пользу составления тех.задания.

Что даёт ТЗ заказчику?

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

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

Что даёт ТЗ исполнителю?

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

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

Кто составляет ТЗ для сайта?

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

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

Раздел 6 «Порядок контроля и приемки системы» /п. 2.8 ГОСТ 34.602-89/

1. Испытания делятся на следующие виды:

  • Предварительные.
  • Опытная эксплуатация.
  • Приемочные.

2. Предварительные (а частично и приемочные) испытания в свою очередь делятся на:

  • Автономные (без интеграции со смежными системами).
  • Комплексные (в комплексе со смежными системами).

1. Предварительные автономные испытания частей системы.2. Предварительные автономные испытания системы в целом.3. Предварительные комплексные испытания.4. Опытная эксплуатация.5. Приемочные испытания.

  • Для предварительных и приемочных испытаний это «Программа и методика предварительных (приемочных) испытаний». Указания для составления документа содержатся сразу в двух стандартах. Вкратце — в ГОСТ 34.603-92 (п. 2.2.2 и 4.1) и более подробно — в РД 50-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов».
  • Для опытной эксплуатации предусматривается документ «Программа опытной эксплуатации», содержание которого приводится в п. 3.1 ГОСТ 34.003-90. Также следует прописать использование «Журнала опытной эксплуатации» (см. п. 3.2 ГОСТ 34.603-92), в который будут заноситься недостатки и результаты их устранения.

9.2. Подраздел 6.2. «Общие требования к приемке работ по стадиям» /п. 2.8.2 ГОСТ 34.602-89/

  1. На чьей территории и на чьем оборудовании будут проводиться испытания: заказчика или исполнителя.
  2. Общее описание, каким образом будут проводиться испытания (например, что будут проверяться документы, наличие элементов пользовательского интерфейса, отрабатываться сценарии).
  3. Список участников.
  4. Перечень документов, которыми оформляют результат испытаний:
    • Для предварительных и приемочных испытаний это протокол испытаний, в котором приводится перечень проверок и их результаты.
    • Для опытной эксплуатации — журнал опытной эксплуатации.

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

Все будет зависеть от шаблона, который вы выберете (чуть дальше я дам несколько ссылок на шаблоны/примеры), но есть базовые блоки, которые входят в техническое задание:

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

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

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал. Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

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

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

А что можно рассказать о требованиях? Заказчик должен помнить, что все требования делятся на два основных типа: специальные и функциональные. Функциональные требования являются в некоторой степени наглядными, образными. Это определенные изображения, элементы, зарисовки того, что заказчик хотел бы увидеть. Специальные же требования — жестко регламентированные, с указанием определенных задач и способов исполнения. Естественно, специальные должны значительно преобладать. В противном случае исполнитель может попросту не до конца понять, что же именно от него хотят.

Программное обеспечение представляет из себя самостоятельное исполняемое приложение. Формат базы данных совместим с ADO.

^

Пользователи работают с базой данных через системный интерфейс.

3.3.3. Требования к исходным кодам и языкам программирования

Дополнительные требования не предъявляются.

^

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

^

Требования к защите информации и программ не предъявляются.

3.5. Специальные требования

Специальные требования не предъявляются.^

4.1. Предварительный состав программной документации

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

  • техническое задание;
  • программу и методики испытаний;
  • руководство оператора;

^

5.1. Экономические преимущества разработки

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

^

6.1. Стадии разработки

Разработка должна быть проведена в три стадии:

  1. Разработка технического задания;
  2. Рабочее проектирование;
  3. Внедрение.

^

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

  • разработка программы;
  • разработка программной документации;
  • испытания программы.

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

^

На этапе разработки технического задания должны быть выполнены перечисленные ниже работы:

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

На этапе испытаний программы должны быть выполнены перечисленные ниже виды работ:

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

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

^

7.1. Виды испытаний:

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

7.2. Требования к приемке работы

При приёмке необходимо проверить соблюдение следующих условий:

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

От ИСПОЛНИТЕЛЯ

От ЗАКАЗЧИКА

Генеральный ДиректорООО «_____________»

________________

«__» __________ 2012 г.

«__» __________ 2012 г.

Похожие:

Техническое задание на разработку дизайн проекта помещения. Информация Техническое задание на разработку проектной документации для строительства зоопарка ПоложенияВ границах земельного участка ул. Подлесная, шоссе Космонавтов, ул. Малкова, Дзержинского района г. Перми
Техническое задание на разработку интернет-сайта структура документаИнформационная система, предоставляющая пользователям сети Интернет доступ к своему содержимому и функционалу в виде упорядоченного… Техническое задание на разработку веб-сайта «Объединение Российских Художников Аэрографии»Основной html контейнер, в который вставляются информационные блоки, должен быть полностью доступен для редактирования. Желательно…
Техническое задание на создание автоматизированной системы «Корпоративное хранилище данных»Гост 34. 602-89 Техническое задание на создание автоматизированной системы (пример) 2. Техническое задание на разработку исВ данном курсовом проекте приведен процесс выдачи пенсионного страхового свидетельства. Разработанная система предназначена для упрощения…
Техническое задание на разработку сайта журнала Настоящее тз представляет…Сайт моделируется с учетом ограничений современных систем контент-менеджмента (открытых WordPress, Joomla, LiveStreet и им подобных… Программа демонстрации алгоритмов обхода графовДанное техническое задание регламентирует разработку учебного программного продукта предназначенного, для наглядного представления…
Техническое задание включает в себя: наименование разработки, основание…Технико-рабочий проект: описание предметной области (объектная модель), управление объектами (события, диаграмма взаимодействия),… Проектирование программных средствЭтап проектирования подразумевает разработку архитектуры, разработку данных и процедурную разработку программных средств

Школьные материалы