Как оформляется техническое задание на проектирование. Техническое задание Как сделать техзадание под себя

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

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

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

Суть и понятие ТЗ заключается в следующем:

• Определение четких критериев выполнения работ по целям, задачам, срокам, результатам и т.д. Благодаря этому можно на любом этапе работ определить ошибки и устранить недочеты;
• Регулирование ответственности сторон, т.к. документ согласован и обоюдно принят. Иногда каждый этап работ согласовывается отдельно, чтобы в результате ошибок была четко определена степень вины каждой стороны, и в соответствии с этим распределены суммы убытков;
• Составляется на основе четких расчетов и научных исследований, поэтому практически исключает «провальность» мероприятий;
• Пишется в доступной форме, без использования сложной профессиональной терминологии, что делает его понятным простому обывателю. Это очень важный пункт, потому что несоблюдение определенных норм из-за недостатка информации, может повлечь санкции со стороны надзорных органов, ведь «незнание не освобождает от ответственности».

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

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

Со стороны заказчика:

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

Со стороны исполнителя:

• Спроектировать технический макет будущего объекта;
• Разработать план последовательности действий;
• Не принять предложение вовсе или отказаться от тех работ, которые не указаны в ТЗ или их невозможно выполнить.

С обеих сторон:

• Сократить количество неточностей и ошибок;
• Прийти к общему виду готового объекта;
• Совершить согласование работ после каждого пункта.

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

Структура и как правильно составить

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

• Список документов, необходимых для работы и изучения обеими сторонами;
• Технические параметры объекта, потребительские свойства и необходимость создания;
• Экономические данные;
• Порядок приемки работ и сдачи всего заказа.

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

Обратите внимание! Если индивидуальные разработки позволят улучшить показатели эффективности объекта, то их нужно согласовать с Госстандартом РФ и получить разрешение на применение. Но здесь речь не идет о тех требованиях, которые касаются охраны здоровья и природы, а также отвечают за безопасность – их менять нельзя!

Структура и состав документа будут утверждаться на основе типа проектируемой продукции. Но, в общем, ТЗ должно содержать следующую информацию:

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

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

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

Образец формы

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

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

Меня часто спрашивают: «Как правильно разработать техническое задание для автоматизированной системы?». Аналогичная тема постоянно обсуждается на различных форумах. Этот вопрос настолько широкий, что ответить в двух словах никак нельзя. Поэтому я решил написать большую статью на данную тему.

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

Для начала надо разобраться, какой в действительности вопрос интересует тех, кто спрашивает «Как разработать техническое задание?» Дело в том, что от того, для каких целей это делается, а также кем будет использоваться, будет сильно зависеть и подход к разработке технического задания. О каких вариантах я говорю:

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

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

  • Клиент имеет своих специалистов со своими взглядами, и они предъявляют конкретные требования к Техническому заданию;
  • Техническое задание разрабатывается для собственных разработчиков (клиенту все равно);
  • Техническое задание разрабатывается для передачи подрядчику (т.е. группе программистов, находящихся за штатом компании, или отдельному специалисту);
  • Между компаний и клиентом возникает непонимание в вопросе полученного результата, и компания вновь и вновь задается вопросом: «Как надо разрабатывать Техническое задание?». Возможно, последний случай кажется парадоксом, но это правда.
  • Возможны и другие, реже встречающиеся варианты;

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

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

Этот список может быть бесконечным. Говорю так уверенно от того, что уже 15 лет в профессиональной разработке программного обеспечения, а вопрос о Технических заданиях всплывает в любом коллективе разработчиков, с кем приходиться работать. Причины тому разные. Поднимая тему разработки Технического задания, я прекрасно отдаю себе отчет в том, что не смогу изложить ее на 100% для всех интересующихся темой. Но, попробую, как говорится «разложить все по полочкам». Те, кто уже знаком с моими статьями знают, что я не пользуюсь «копи-пастом» труда других людей, не перепечатываю чужие книги, не цитирую многостраничные стандарты и прочие документы, которые Вы и сами сможете найти в интернете, выдавая их за свои гениальные мысли. Достаточно набрать в поисковике «Как разработать Техническое задание» и Вы сможете прочитать много интересного, но, к сожалению, многократно повторяющегося. Как правило, те, кто любит умничать на форумах (попробуйте все-таки поискать!), сами никогда не делали толкового Технического задания, и непрерывно цитируют рекомендации ГОСТов по данному вопросу. А тем, кто действительно серьезно занимается вопросом, обычно некогда сидеть на форумах. Про ГОСТЫ, кстати, мы тоже поговорим. В разные годы своей работы мне приходилось видеть множество вариантов технической документации, составленной как отдельными специалистами, так и именитыми командами и консалтинговыми компаниями. Иногда еще я занимаюсь такой деятельностью: выделяю себе время и занимаюсь поиском информации на интересующую тему по необычным источникам (такой небольшой разведкой). В результате приходилось видеть документацию и по таким монстрам, как ГазПром, РЖД и много других интересных компаний. Конечно же, я соблюдаю политику конфиденциальности, несмотря на то, что эти документы попадают ко мне из общедоступных источников или безответственности консультантов (разбрасывают информацию по интернету). Поэтому сразу говорю: конфиденциальной информацией, которая принадлежит другим компаниям не делюсь, независимо от источников возникновения (профессиональная этика).

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

Первое, что мы сейчас сделаем, так это разберемся с тем, что за зверь такой, «Техническое задание».

Да, действительно существуют ГОСТы и стандарты, в которых предприняты попытки регламентировать эту часть деятельности (разработки программного обеспечения). Когда-то все эти ГОСТы были актуальны и активно применялись. Сейчас существуют разные мнения по поводу актуальности данных документов. Одни утверждают, что ГОСТы были разработаны очень дальновидными людьми и до сих пор актуальны. Другие говорят, что они безнадежно устарели. Возможно, кто-то сейчас подумал, что правда где-то по середине. Я бы ответил словами Гете: «Говорят, что между двумя противоположными мнениями находится истина. Ни в коем случае! Между ними лежит проблема». Так вот, между этими мнениями истины нет. Потому как ГОСТы не раскрывают практических проблем современной разработки, а те, кто их критикует, альтернативы (конкретной и системной) не предлагают.

Заметим, что в ГОСТе явно не дано даже определения, сказано лишь: «ТЗ на АС является основным документом, определяющим требования и порядок создания (развития или модернизации - далее создания) автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка при вводе в действие».

Если кому-то интересно, о каких ГОСТах я говорю, то вот они:

• ГОСТ 2.114-95 Единая система конструкторской документации. Технические условия;
• ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению;
• ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы.

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

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

Именно основное, но единственное. Настало время взяться за главное: разложить все «по полочкам», как и обещал.

Что необходимо знать о требованиях? Необходимо четко понимать, что все требования нужно разделять по видам и по свойствам. Сейчас мы научимся это делать. Для разделения требований по видам нам как раз поможет ГОСТ. Тот перечень видов требований, который там представлен, является хорошим образцом того, требования каких видов следует рассматривать. Например:

• Требования в функциональности;
• Требования к безопасности и правам доступа;
• Требования к квалификации персонала;
• …. И т.д. Вы можете прочитаете о них в упомянутом ГОСТе (а ниже я их тоже рассмотрю немного подробнее).

Думаю, для Вас очевидно, что ключевым фактором успешного Технического задания являются именно хорошо сформулированные требования к функциональности. Именно этим требованиям посвящено большинство работ и методик, о которых я говорил. Требования к функциональности – это 90% сложности работ по разработке Технического задания. Все остальное зачастую является «камуфляжем», который надет на эти требования. Если требования сформулированы плохо, то какой красивый камуфляж на них не натягивай, успешного проекта не выйдет. Да, формально все требования будут соблюдены (по ГОСТу J), ТЗ разработано, утверждено и подписано, деньги за него получены. И что? А дальше начнется самое интересное: что делать-то? Если это проект на ГосЗаказе, то проблем нет – там бюджет такой, что ни в какой карман не влезет, в процессе реализации (если она будет) все и будет выясняться. Именно таким образом и пилится большинство бюджетов проектов на ГосЗаказах (накалякали «ТЗ», слили десяток миллионов, а проект делать не стали. Все формальности соблюдены, виновных нет, новое авто возле дома. Красота!). Но ведь мы говорим о коммерческих организациях, где деньги считают, да и результат нужен другой. Поэтому давайте разбираться с главным, как разрабатывать полезные и работающие Технические задания .

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

1. Требование должно быть понятным ;
2. Требование должно быть конкретным ;
3. Требование должно быть тестируемым ;

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

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

• на каком языке (в смысле сложности понимания) должно быть написано техническое задание?
• Должны ли быть описаны в нем спецификации различных функций, алгоритмы, типы данных и прочие технические штуки?
• А что такое техническое проектирование, о котором, кстати, сказано и в ГОСТах, и как оно связано с Техническим заданием?

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

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

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

Что мы имеем на практике? Забавно наблюдать, когда директору приносят на согласование Техническое задание, которое изобилует технической терминологией, описанием типов данных и их значений, структуры базы данных и пр. Он, конечно, пытается вникнуть, раз надо утверждать, пытаясь найти между строк знакомые слова и не потерять цепочку бизнес-требований. Что, знакомая ситуация? И чем это заканчивается? Как правило, такое ТЗ утверждается, затем реализуется, а в 80% случаев потом совсем не соответствует факту выполненных работ, т.к. много чего решили изменить, переделать, неправильно поняли, не так думали и т.д. и т.п. А потом начинается сериал про сдачу работ. «А вот тут не так как нам надо», а «это у нас работать не будет», «это слишком сложно», «это неудобно» и т.д. Знакомо?!! Вот и мне знакомо, пришлось набить шишек в свое время.

Так что мы имеем на практике-то? А на практике мы имеем размытую границу между Техническим заданием и Техническим проектом. Она плавает между ТЗ и ТП в самых разных проявлениях. И это плохо. А получается так потому, что культура разработки стала слабой. Частично это связано с компетенциями специалистов, частично со стремлением сократить бюджеты и сроки (ведь документация занимает много времени - это факт). Есть и еще один важный фактор, влияющий на использование Технического проекта как отдельного документа: стремительное развитие средств быстрой разработки, а также методологий разработки. Но это отдельная история, чуть ниже несколько слов об этом скажу.

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

А нужно ли вообще техническое задание? А Технический проект?

Не перегрелся ли я? Разве такое возможно, вообще без Технического задания ? Представьте себе возможно (точнее, встречается), и у такого подхода есть много последователей, и их число увеличивается. Как правило, после того, как молодые специалисты начитаются книг про Scrum, Agile и прочие технологии быстрой разработки. На самом деле это замечательные технологии, и они работают, только в них не говорится дословно «не надо делать технических заданий». В них говорится «минимум бумаг», особенно ненужных, ближе к Заказчику, больше конкретики и быстрее к результату. Но фиксирование требований никто не отменял, и там это явно сказано. Как раз там требования и фиксируются исходя из трех замечательных свойств, о которых я говорил выше. Просто у некоторых людей так устроено сознание, что если можно что-то упростить, так давайте это упростим до полного отсутствия. Как сказал Эйнштейн «Сделай так просто, как возможно, но не проще этого» . Золотые ведь слова, ко всему подходят. Так что Техническое задание нужно, иначе успешного проекта Вам не видать. Другой вопрос, как составлять и что туда включать. В свете методологий быстрой разработки надо сосредоточиться только на требованиях, а весь «камуфляж» можно отбросить. В принципе, я с этим согласен.

А что же с Техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, т.е. по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ. Должен ли с ним знакомиться Заказчик? Если хочет, почему нет, но настаивать и утверждать данный документ нет никакой необходимости, он будет только сдерживать и мешать работать. Спроектировать систему до мелочей практически невозможно. В этом случае придется непрерывно вносить изменения в Технический проект, что занимает немало времени. А если организация сильно забюрократизирована, то вообще все нервы там оставите. Как раз о сокращении такого рода проектирования и идет речь в современных методологиях быстрой разработки, о которых я упоминал выше. Кстати, все они базируются на классическом XP (экстремальном программировании)- подходе, которому уже порядка 20 лет. Так что сделайте качественное Техническое задание, понятно Заказчику, а Технический проект используйте как внутренний документ, для взаимоотношений между архитектором системы и программистами.

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

Продолжим исследование вопроса: «Какие требования включать в Техническое задание?»

Формулирование требований к информационной системе. Структура Технического задания

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

Как и любую деятельность, формулирование требований можно (и нужно) разделить на этапы. Всему свое время. Это тяжелый интеллектуальный труд. И, если относится к нему с недостаточным вниманием, то результат будет соответствующий. По экспертным оценкам, стоимость затрат на разработку Технического задания может составлять 30-50%. Я придерживаюсь такого же мнения. Хотя 50 – пожалуй, перебор. Ведь Техническое задание – это еще не последний документ, который должен быть разработан. Ведь еще должно быть и техническое проектирование. Такой разброс обусловлен различными платформами автоматизации, подходами и технологиями, применяемыми проектными командами при разработке. Например, если речь идет о разработке на классическом языке типа С++, то без детального технического проектирования тут не обойтись. Если речь идет о внедрении системы на платформе 1С, то тут с проектированием ситуация несколько иная, как мы видели выше (хотя, при разработке системы «с нуля», она проектируется по классической схеме).

Несмотря на то, что формулировка требований является основной частью Технического задания , а некоторых случая она становиться единственным разделом ТЗ, следует обратить внимание на то, что это важный документ, и оформлять его следует соответственно. С чего начать? В первую очередь начать надо с содержания. Составьте содержание, а затем начните его разворачивать. Лично я делаю так: сначала набрасываю содержание, описываю цели, всю вводную информацию, а затем принимаюсь за основную часть – формулировку требований. Почему не наоборот? Не знаю, мне так удобнее. Во-первых, это гораздо меньшая часть времени (по сравнению с требованиями), во-вторых, пока описываешь всю вводную информацию, настраиваешься на главное. Ну это кому как нравится. Со временем у Вас выработается свой шаблон Технического задания. Для начала рекомендую в качестве содержания взять именно тот, что описан в ГОСТ. Для содержания он подходит отлично! Затем берем и начинаем описывать каждый раздел, не забывая про рекомендации следования трем свойствам: понятности, конкретности и тестируемости. Почему я на этом так настаиваю? Об этом в следующем разделе. А сейчас предлагаю все-такт пройтись по тем пунктам ТЗ, которые рекомендуются в ГОСТе.

1. общие сведения;
2. назначение и цели создания (развития) системы;
3. характеристика объектов автоматизации;
4. требования к системе;
5. состав и содержание работ по созданию системы;
6. порядок контроля и приемки системы;
7. требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
8. требования к документированию;
9. источники разработки.

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

Раздел 1. общие сведения.

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

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

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

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

ГОСТ расшифровывает перечень таких требований:

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

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

• Требования к квалификации . Возможно, разрабатываемая система потребует переподготовки специалистов. Это могут быть как пользователи будущей системы, так и IT-специалисты, которые будут нужны для ее поддержки. Недостаточное внимание к данному вопросу нередко перерастает в проблемы. Если квалификация имеющегося персонала явно недостаточна, лучше прописать требования к организации обучения, программе обучения, срокам и т.п.
• Требования к защите информации от несанкционированного доступа. Тут комментарии излишни. Это как раз и есть требования к разграничению доступа к данным. Если такие требования планируются, то их нужно расписать отдельно, как можно более детально по тем же правилам, что и функциональные требования (понятность, конкретность, тестируемость). Поэтому, можно эти требования включить и в раздел с функциональными требованиями
• Требования к стандартизации. Если существуют какие-либо стандарты разработки, которые применимы к проекту, они могут быть включены в требования. Как правила, такие требования инициирует IT-служба Заказчика. Например, у компании 1С есть требования к оформлению программного кода, проектированию интерфейса и пр.;
• Требования к структуре и функционированию системы. Тут могут быть описаны требования к интеграции систем между собой, представлено описание общей архитектуры. Чаще требования к интеграции выделяют вообще в отдельный раздел или даже отдельное Техническое задание, т.к. эти требования могут оказаться достаточно сложными.

Все остальные требования менее важны и можно их не описывать. На мой взгляд, они только утяжеляют документацию, и практической пользы несут немного. А Требования к эргономике описывать в виде общих требований очень сложно, лучше их перенести к функциональным. Например, может быть сформулировано требование «Получить информацию о цене товара нажав только одну кнопку». На мой взгляд, это все-таки ближе к конкретным функциональным требованиям, хоть и относится к эргономике.Требования к функциям (задачам), выполняемым системойВот он, тот самый главный и ключевой пункт, который будет определять успех. Даже если все остальной сделать на отлично, а этот раздел на «3», то и результат по проекту будет в лучшем случае на «3», а то и вообще проект провалится. Именно эти мы и займемся более детально во второй статье, которая войдет в 5-й выпуск рассылки. Именно к этому пункту относится «правило трех свойств требований», о которых я говорил.Требования к видам обеспечения

ГОСТ выделяет такие виды:

• Математическое
• Информационное
• Лингвистическое
• Программное
• Техническое
• Метрологическое
• Организационное
• Методическое
• и другие…

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

• Решения о том, на каком языке (или какой платформе) будет вестись разработка не принято;
• К системе предъявляются требования мультиязычного интерфейса (например, русский/английский)
• Для функционирования системы должно быть создано отдельное подразделения или приняты на работу новые сотрудники;
• Для функционирования системы у Заказчика должны произойти изменения в методиках работы и эти изменения должны быть конкретизированы и запланированы;
• Предполагается интеграция с каким-либо оборудованием и к нему предъявляются требования (например, сертификации, совместимости и пр.)
• Возможны другие ситуации, все зависит от конкретных целей проекта.

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

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

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

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

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

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

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

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

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

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

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

Подумайте, как будут представлены руководства пользователя.

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

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

Раздел 9. Источники разработки

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

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

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

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

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

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

Тестируемое ли это требование? Вроде бы простая вещь, но как ее проверять, если нет конкретики?

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

ЭргономичностьПрограмма должна иметь удобный интерфейсПризнаться, под данной формулировкой пришлось однажды подписаться самому – проблем потом было не сосчитать. Конечно же, подобных формулировок быть не должно. Тут нет не конкретики, ни возможность проверить это требование. Хотя, безусловно, понятное (субъективно). Тут переформулировать никак нельзя, надо подробно расписывать каждый элемент «удобности», раз Заказчик на этом настаивает. Например:

• Строки в документ должны добавляться как по нажатию на кнопку «Добавить», так и при нажатии на клавиши «insert», а также вводе пользователем части наименования;
• При просмотре списка товаров должна быть возможность поиска по наименованию, штрихкоду и артикулу;
• И пр.

Разграничение прав доступаДоступ к данным по прибыли должен быть доступен только финансовому директоруПонятно? Почти. Правда, прибыль бывает разная, надо уточнить.Конкретно? Конечно нет. Как это видится в реализации? Если речь идет о валовой прибыли, то значит необходимо ограничивать доступ к данным о стоимости закупки, т.к. в противном случае валовую прибыль вычислить не составит труда, поскольку данные о стоимости реализации известны широкому кругу лиц. К тому, что относится к правам доступа, надо относиться очень аккуратно. А если у менеджеров по продажам мотивация построена на валовой прибыли, так эти требования еще и противоречат друг другу, т.к. менеджеры никогда не смогут это проверить. Если уж включать такое требование, то нужно указывать конкретные отчеты и объекты системы, в которых указывать, какая часть данных должны быть доступна отдельным категориям лиц. И рассматривать каждый такой случай индивидуально.ПроизводительностьОтчет по продажам должен формироваться за 1 минуту.Да, понятно. И даже есть конкретное ограничение по времени: 1 минута. Но не известно, какая детализация при этом предполагается: по каждому товару, группам товаров, клиентам или как-то еще?Можно сформулировать примерно так: «Отчет по продажам в разрезе клиентов с детализацией до каждой товарной позиции (см. образец) должен выводится не более, чем за 1 минуту при условии, что количество товаров в выборке не превышает 5000 строк».

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

Чтобы в Техническом задании было больше конкретики, существует немало рекомендаций. Даже есть перечень слов, которые употреблять в Техническом задании не рекомендуется. Интересно об этом пишет К.Вигерс, в своей книге «Разработка требований к программному обеспечению». Приведу самые интересные и простые, на мой взгляд, рекомендации:

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

Все, что написано выше, это информация важная, но не самая. Как Вы помните, в начале статьи я это назвал термином «камуфляж», т.к. самое главное, что составит как минимум 90% времени и сложности работы над документом – это выявление и формулировка требований. А информацию о требованиях надо еще суметь собрать, структурировать и сформулировать. В этом, кстати, много общего между обследованием деятельности предприятий с последующим описанием бизнес-процессов. Но есть и важные различия. Одно из таких ключевых отличий – это наличия этапа построения прототипа будущей системы, или как его еще называют «модели информационной системы».

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

Виды работ при сборе требований к системе учета и информации для описания бизнес-процессов. Часть 2

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

Как обычно происходит в жизни:

Почему сложилась такая практика, как описано выше? Признаться, я не знаю. У кого ни спроси, никто не знает. При этом ситуация меняется не очень быстро, хотя на эту тему постоянно дискутируют, обмениваются опытом, пишут книги… Мне кажется, что одна из причин – низкое качество соответствующего образования. Может еще сказывается и тот факт, что много специалистов приходит вообще их другого бизнеса, и постигают все на практике, т.е. их опыт формируется в той среде, куда они попали. Об отношении ВУЗов и отсутствия их стремления быть ближе к реальности, тоже факт известный, но меня иногда удивляет их позиция. Например, у меня был случай, когда дипломница, талантливый специалист, хотела писать дипломную работу на платформе 1С (хорошую отраслевую разработку), но на кафедре ей сказали, что независимо от темы, на оценку «отлично» рассчитывать будет нельзя, т.к. 1С несерьезная система. Тут дело не в серьезности и объективности такого мнения, а в том, что примитивное задание на классическом языке программирования тут же считалось достойным оценки «отлично».

Давайте попробуем придать рассмотренному выше процессу более системный подход. Как он может тогда выглядеть?

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

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

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

Вот и добрались до вопроса «Что дальше?». Дальше будем рассматривать задачи описания бизнес-процессов и разработки Технического задания отдельно. Я не случайно рассматриваю эти задачи параллельно. Между ними действительно много общего, что я и хочу продемонстрировать. Сначала рассмотрим последовательность работ при описании бизнес-процессов.

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

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

Основное назначение технического задания — четко определить и зафиксировать требования к объекту закупки. При этом закон устанавливает, что наименование закупки указывается в соответствии с (ч. 4 ст. 23). Каталог утвержден Постановлением Правительства от 08.02.2017 № 145.

При наличии описания закупаемой продукции в КТРУ заказчик обязан:

• описывать объект закупки так, как это предусмотрено КТРУ;
• включить в описание письменное обоснование (если описание отличается от того, которое предусмотрено в КТРУ).

Утвержденными ПП от 05.06.2015 № 555 Правилами предусмотрена обязанность заказчика указывать наименование предмета закупки в процессе обоснования.

Формулировку требований заказчик составляет на основе правил описания объекта закупки (ст. 33). Выделим некоторые обязательные условия:

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

Что указать в техническом задании

• общая информация;
• информация о закупаемом объекте;
• требования к поставщикам;
• условия ;
• приложения (допускается по усмотрению заказчика).

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

1. Составить список терминов, определений и сокращений, которые будут использоваться в документе.

2. Предоставить полную информацию о заказчике:

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

3. Предусмотреть в информации о закупке сведения:

• или нет, а если да — права и обязанности каждого заказчика (ПП от 28.11.2013 № 1088);
• централизованная закупка, сведения об уполномоченном органе (ч. 1 ст. 26 закона № 44-ФЗ);
• привлечение экспертов, порядок их работы.

4. Перечислить сведения о госзакупке:

• способ определения поставщика (ч. 1 ст. 24);
• обоснование выбранного способа определения поставщика (ч. 5 ст. 24).

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

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

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

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

9. Привести желаемые результаты (какую проблему хочет решить заказчик) и цели госзакупки (ст. 13 44-ФЗ).

10. Указать источник финансирования.

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

12. Определить условия госзакупки (ч. 1 ст. 19).

13. Указать наименование и обоснование объекта госзакупки.

14. Максимально точно и детально описать объект госзакупки (ст. 33).

15. Определить экологические особенности закупаемого объекта.

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

17. Определить гарантийный срок и объем предоставляемых гарантий.

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

19. Обязать предоставлять подтверждение нового товара или потребности в товаре иного состояния.

20. Определить расходы на эксплуатацию.

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

22. Установить порядок поставки и приемки.

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

Образцы техзаданий для товаров, работ, услуг в 2019 году

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

Ниже представлен образец технического задания на поставку товара по 44-ФЗ.

Также образец техзадания на выполнение работ по ФЗ-44 вы можете найти в нашем материале о или системы .

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

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

Создан 05.02.2005 11:41:19

Твой мир пуст...

Кто печаль твою разделит?

«Как писать техническое задание?!» - из уст т. н. начинающего «технического писателя», далее по тексту - техписа. Вот она - страшная цена развала Союза и переход российской высшей школы на двухступенчатую систему образования.

Вернемся к вопросу. При «раскладке» получается:

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

Третий - самый сложный. Ответы на указанные вопросы появятся в ходе изложения.

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

Цель статьи - облегчить жизнь совсем уж начинающим техписам.

Задачи статьи:

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

История

Все, что когда-либо производилось, производится и будет производиться, делится (условно, разумеется) на:

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

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

Первой автоматизированной системой, возможно, стала ветряная мельница. Вытащил стопор - «лопасти» вращаются, жернова молотят. «Нажатие одной кнопки» - 100-процентная автоматизация.

История, леденящая душу

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

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

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

Побагровел царь - что ж, смерд, мельница сия муку непотребно мелет?! (Несоответствие производимой требованиям ГОСТ 7045-90 Мука ржаная хлебопекарная.). Схватили мужика опричники, да долбанули по буйной его головушке топором каменным. И кончил жизнь Левша под звуки «Реквиема» Моцарта из музыкального автомата...

Выводы

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

Издавались Указы, Распоряжения - «в университете московском студиозусам надобно на соломе сидеть, сморкаться в кулак, нос утирать пучком соломы. А нарушивших правила сии розгами драть нещадно» (или что-то в этом роде).

Равноправия нет и сейчас - кто платит, тот и заказывает музыку. А платит заказчик.

Примечание от 10.05.2014 г. - Но не все так печально Если действовать с умом, то можно запросто прогнуть любого заказчика, см. и.

Современное состояние

И было придумано то, что сделали танк...

из серии «Армейские приколы»

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

Может быть, все было иначе, но танк, в целом, получился хорош - что подтверждается и представителями ГОССТАНДАРТа, и отзывами опытных разработчиков.

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

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

Для маааааааленького техписа, работающего на Большого Босса, разработка технического задания есть:

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

Крайнее утверждение - палка о трех концах. Ах, ты умный, умеешь? Так на тебе еще работенки. А жалование поднимем. Когда-нибудь.

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

Считаем, что первый вопрос (в первом же приближении) закрыт.

ГОСТы на технические задания

Куст есть совокупность веток, произрастающих из одной точки.

Военная мудрость

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

Примечания:

1. Существуют и иные отечественные ГОСТы, содержащие требования к содержанию и оформлению документа «Техническое задание». Сей факт обусловен спецификой. Перечисленная четверка была и остается для большинства предметных областей;
2. Техзадание было и остается основополагающим документом, той самой «точкой опоры», из которой все и произрастает.

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

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

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

Потребовалось разработать техническое задание на изделие - пользуемся ГОСТ 2.114-95, поскольку ГОСТ 15.001 - кривой по жизни, а разделы технических условий (в целом) соответствуют разделам технического задания. Надо - открываем ГОСТ 34.602-89. На - ГОСТ 19.201-78.

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

Практические приемы

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

Самый первый прием - создание документа с ГОСТированной структурой разделов. Если Боссом поставлена задача разработки технического задания, положим, на автоматизированную систему, скачивается ГОСТ 34.602-89 в виде -файла, затем просто открывается вордом и в формате dot.

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

Примечание от 25.12.2011 г. - На Ростехрегулирования (protect.gost.ru) не так давно стали публиковать официальные версии ГОСТов, правда, далеко не в редактируемом формате...

Детализация

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

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

Произвольно выбранная цитата из ГОСТ 34.602-89:

Для системы приводят требования к применению в системе, языков взаимодействия и технических средств системы, а также требования к и декодированию, к языкам -, средствам описания (объекта автоматизации), к способам организации [из п. 2.6.3.3 ГОСТ 34.602-89]

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

4.3.2.1 Требования к лингвистическому обеспечению системы

4.3.2.1.1 Требования к применению в системе языков программирования высокого уровня

(текст требования)

4.3.2.1.2 Требования к языкам взаимодействия пользователей и технических средств системы

(текст требования)

4.3.2.1.3 Требования к кодированию данных

(текст требования)

4.3.2.1.4 Требования к декодированию данных

(текст требования)

4.3.2.1.5 Требования к языкам ввода-вывода данных

(текст требования)

4.3.2.1.6 Требования к языкам манипулирования данными

(текст требования)

4.3.2.1.7 Требования к средствам описания предметной области (объекта автоматизации)

(текст требования)

4.3.2.1.8 Требования к способам организации диалога

(текст требования)

Увеличился объем технического задания? А стоит ли экономить бумагу? Имеется и еще одна военная мудрость, как бы грубо и двусмысленно она ни звучала: «больше бумаги - чище з@@@@ца». Требования к лингвистическому обеспечению стали выглядеть понятнее?

Примечание - Термины «понятность», «» (understandability) фигурируют сразу в нескольких ГОСТах. Вот квинтэссенция - «совокупность чего-то, характеризующая затраты усилий человека на понимание логической концепции этого чего-то».

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

Детализация, детализация и еще раз детализация. До приемлемого (атомарного) уровня.

Шаблонное построение фраз

Следует взять на вооружение тот факт, что в каждом вопросе (правильно поставленном) - половина ответа. Допустим, необходимо сформулировать текст подпункта «Требования к применению в системе ». Итак:

4.3.2.1 Требования к применению в системе языков программирования высокого уровня

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

• язык C++;
• язык Pascal;
• и т.д.

Для тех, кто не прочувствовал, как построить фразу, слева приведена схема ее построения.

4.1.2 Требования к численности и квалификации персонала системы и режиму его работы

(детализируем - создаем подпункты 4.1.2.1, 4.1.2.2 и 4.1.2.3)

(правильно формулируем текст подпункта - отвечаем на вопрос, каким требованиям должна удовлетворять численность персонала)

Численность персонала должна удовлетворять требованиям :

• быть достаточной для реализации автоматизированных () системы во всех режимах работы системы;

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

Квалификация персонала должна обеспечивать эффективное функционирование технических и системы во всех режимах работы системы»

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

4.1.2.3 Требования к режиму работы персонала

Режим работы персонала - трехсменный круглосуточный.

В подразделе предусмотрен также порядок подготовки персонала, контроля знаний и навыков. О составе - ни слова. И это правильно. Состав персонала, деление его на оперативный (), ремонтный и пр., определяется при проектировании системы. Хотя никто не может запретить добавить в техническое задание Требования к составу персонала. Пожалуй, не стоит.

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

Формализация при подготовке текста технического задания

Возможно Двести Вариантов

Один из двухсот вариантов расшифровки аббревиатуры «ВДВ»

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

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

Численность персонала должна удовлетворять требованиям:

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

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

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

Примечание от 17.04.2018 г. - В ОКПДТР должность технического пейсателя тоже отсутствует. А должность укладчика текста так и осталась с прежних времен

Штампы и унификация при подготовке текста технического задания

Вы, бабы, красивы,

А я - без прикрас

Но, все же, мужчины

Уходят от вас...

Ю. Рыбчинский, «Две сестры»

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

Положим, разрабатывается универсальный преобразователь энергии в энергию человеческого разума (Существование человеческого разума сомнительно. Разумно ли вешать на свою шею работу по созданию такого преобразователя? А вот рефлексы существуют объективно). Следует сразу, в разделе «Наименование изделия» обозвать этот самый преобразователь Изделием:

Наименование изделия - преобразователь энергии солнечного излучения в энергию человеческого разума (далее по тексту - Изделие ).

И, в тексте - Изделие, Изделие, Изделие...

Тоже самое относится к программным изделиям и автоматизированным системам. Наименование АС - автоматизированная система раздачи грубых кормов для крупного рогатого скота (далее по тексту - Система ).

И, в тексте - Система, Система, Система... Программа, Программа, Программа...

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

Примечание от 05 февраля 2010 г. - При автоматизированной разработке техдокументации с применением single source приемлем как вариант со всякими склонениями-спряжениями, так и без них. К примеру, можно единожды создать переменную <ЗАО «Заказчик»> и вставлять в требуемые топики библиотеки документов - так иногда бывает удобнее.

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

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

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

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

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

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

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

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

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

В ГОСТ 34.003-90 поставлена впереди, задача является как бы частью функции. И это странно: еще в школе все решали задачки, вычисляя внутри них значения различных функций... И представьте себе, как дико звучала бы декларация: «Цель партии и правительства - повышение благосостояния всего советского народа. Ради достижения цели партия ставит перед собой функцию обеспечения к 2ххх году каждой семьи отдельной квартирой»... (Кстати, заниматься уборкой домов и квартир самостоятельно сейчас уже не модно и некогда особенно - для этого есть клининговые компании). Таким образом, функция является частью задачи, а не наоборот. Пусть даже вопреки священному ГОСТ 34.003-90.

Итак, пример.

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

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

И из предыдущего подраздела:

• должны быть ...;
• должна удовлетворять требованиям ..

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

Перечни и нумерация разделов

Перечни (маркированные или нумерованные списки) весьма уместны при подготовке текста технического задания. Нормальный человек способен воспринять (запомнить и безошибочно воспроизвести) от трех до девяти элементов перечня. Свыше девяти - признак гениальности.

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

Случай первый.

«В рамках задачи (или для решения задачи должны обеспечивать возможность выполнения перечисленных нижефункций :

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

Случай второй.

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

1. автоматизированной функции добавления записей в таблицы базы данных;
2. автоматизированной функции удаления записей из таблиц базы данных;
3. автоматизированной функции сортировки записей в таблицах базы данных...;»

Отличия, казалось бы, невелики. Но!

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

Во втором случае, всего-навсего - «методика проверки выполнения п. 4.3.2.1(1) технического задания».

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

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

По списки следует «нумеровать» не цифрами, а буквами:

а) функция такая-то;

Вопрос принципиальный, поскольку ТЗ на АС (дополнение к ТЗ) до передачи его на утверждение должно быть проверено службой организации - разработчика ТЗ и, при необходимости, подвергнуто [из п. 8 прил. 1 ГОСТ 34.602-89]. Ведь если техническое задание разработано криво (по форме и по существу), кривыми будут проектные и эксплуатационные документы.

Чуть-чуть о. Если в ТЗ имеется подраздел «Метрологическое обеспечение...», то метрологическая экспертиза должна быть проведена по полной программе. Если указанный подраздел отсутствует, то метрологическая экспертиза сводится к проверке сокращений согласно ГОСТ 8.417. И только.

Связка «общие сведения, назначение и состав» в техническом задании

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

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

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

2.1 Назначение системы

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

Система должна обеспечивать решение (возможность решения) перечисленных ниже задач:

1. задачи сбора данных с каких-то, допустим, датчиков;
2. задачи обработки, хранения, отображения и пр. в центре сбора.

Вот и все. Немного фантазии, и раздел готов:

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

1. 1-й уровень - уровень сбора данных ;
2. 2-й уровень - уровень консолидации данных (централизованная обработка, хранение и пр.).

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

2.1.1 Уровень сбора данных

2.1.1.1 Общие сведения

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

2.1.2.2 Назначение

Уровень сбора данных предназначен (еще один штамп):

1. для передачи данных каких-то датчиков уровню консолидации по запросу (инициативе) крайнего (последнего);
2. для протоколирования передачи данных в журнале событий (а если по ГОСТу, то в);
3. еще для чего-то.

2.1.2.3 Состав

В состав уровня сбора данных должны входить:

1. датчики такие-то;
2. датчики еще какие-то.

В чем удобство использования связки «общие сведения, назначение и состав»? А невольно получается хорошо структурированное техническое задание - древовидное и иерархическое.

2.2.2.3.1 Датчики такие-то

2.2.2.3.1.1 Общие сведения (о таких-то датчиках)

2.2.2.3.1.2 Назначение (таких-то датчиков)

2.2.2.3.1.3 Состав (таких-то датчиков)

Главное - вовремя остановиться.

Предостережение

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

• прежде всего - . Для таким является;
• , например и;
• , например;
• и, например;
• ряд других.

Не следует особенно увлекаться подобными «тематическими» ГОСТами, содержащими очень уж конкретные требования к. Характерная ошибка начинающих - «каналы связи должны удовлетворять требованиям ГОСТ такому-то». Это фатальная ошибка. Известно, что приемке-сдаче работ по созданию системы, изделия, программного изделия всегда предшествует проведение.

Допустим, Большой Босс, пораженный глубокими познаниями техписа, доверился оному, читать ничего не стал и черканул на титульном листе технического задания утверждающую (под УТВЕРЖДАЮ, в правом верхнем углу титульного листа). Заказчик, с гнусной ухмылкой, аккуратно поставил свою (под УТВЕРЖДАЮ, в левом верхнем углу). Все, техническое задание и внести в него или возможно только по дополнительному соглашению с заказчиком. Вот тут-то техпис и попал.

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

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

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

Короче, писать надо примерно так, русским по белому:

«В качестве каналов связи могут быть применены (использованы):

1. каналы связи -;
2. каналы операторов сотовой связи;
3. каналы операторов спутниковой связи;
4. коммутируемые телефонные линии общего пользования;
5. объекта заказчика;
6. и так далее»

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

Заключение

Итак, вспомним еще разок ключевые моменты:

1. подготовка технического задания импортом электронной версии требуемого ГОСТа;
2. детализация - дробление больших по объему разделов технического задания на короткие простые подразделы;
3. шаблонное построение предложений в разделах (подразделах и пр.) технического задания так, чтобы «в ответе оказывалась половина вопроса»;
4. формализация содержимого тех разделов, где невозможно (или) давать конкретику;
5. применение штампов;
6. применение перечней (маркированных или нумерованных списков);
7. применение связки «общие сведения, назначение и состав»;
8. минимальное применение «тематических» ГОСТов.

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

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

При разработке любого проекта. Как оформляется этот документ? Об этом будет рассказано в статье.

Техническое задание - что это такое?

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

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

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

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

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

Зачем техническое задание исполнителю?

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

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

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

Начало составления документа

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

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

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

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

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

Ответственность и отчетность

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

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

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

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

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

Просто стоит запомнить несколько простых правил:

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

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

Стоит напомнить и о том, насколько важно сверяться с нормами: будь то ГОСТ, нормативные или правовые акты, локальные акты и т. д.