Как правильно оформить техзадание

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

Техническое задание «ТЗ» – это документ, который берется за основу при разработке любого проекта. И не важно, какой сложности и величины задание, оно всегда должно сопровождаться четким и понятным ТЗ. Это, в первую очередь, нужно заказчику, чтоб получить в результате именно то, что он хотел видеть. Но и исполнителю желательно всегда требовать четко изложенное задание, чтоб понимать, чего от него хотят. Многие игнорируют факт написания детального технического задания, что в последствии приводит к недопонимаю, спорам, конфликтам и ссорам.

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

Для чего ТЗ заказчику?

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

Для чего ТЗ исполнителю?

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

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

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

  • Общие положения технического задания

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

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

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

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

  • Функциональные требования

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

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

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

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

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

  • Ответственность

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

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

И в конце это статьи, хотелось бы дать несколько советов исходя из собственного опыта составления и получения технических заданий.

  1. Техническое задание должно быть детальное. Не бойтесь описывать каждый элемент, каждый пункт, каждую кнопку. Все-все-все максимально детально пишите. Не бойтесь показаться дотошным. Уж лучше что-то несколько раз повторить и разжевать, нежели потом доделывать, доплачивать, дорабатывать. Последнее техническое задание, которое я писал, касалось разработки сайта. Это был большой информационный проект. Сначала разработали дизайн, а потом на его основе описывал функциональное задание для программистов. Так вот, все ТЗ получилось на 54 страницы А4 11 шрифтом. Техническое задание шло как дополнение к основному договору, который тоже был на 7 страниц. Но хочу сказать, что даже в таком детальном ТЗ не все смог учесть, ведь в процессе разработки подписывали еще три дополнительных соглашения, которыми я вносил определенные корректировки в первоначальный вариант задания.
  2. Техническое задание должно быть четкое. Не нужно никакой воды. Все по делу. Если пишите о срока, то конкретную цифру, если о функционале, то перечень нужных вам функциональных решений и т.д.
  3. Ваше техническое задание – это не догма, а лишь один из возможных вариантов исполнения задач. Скажу честно, я не специалист в программировании. Да, я могу продумать структуру проекта, его функционал, какие-то технические решения, но всегда, составляя окончательный вариант ТЗ, советуюсь с исполнителями. Они могут что-то увидеть, высказать свое мнение, подсказать оптимальное решение исполнение.

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

Так же рекомендую прочитать:

Май 28, 2014 3:02 дп

Если Вам понравился опубликованный материал – поделитесь им с Вашими друзьями:

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

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

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

Проблема восприятия информации, вечная. Эффект “сломанного телефона”, частое явление. А что говорить о том, если ты просто не умеешь ставить задачу? Да, такое тоже бывает и с этим нужно как-то работать, но как? Для того чтобы результаты задач, которые вы ставите, соответствовали вашим ожиданиям, пишите техническое задание.

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

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

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

Для чего нужно техническое задание

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

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

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

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

Смотрите так же:  Предмет требования по заявлению

Разработка технического задания

Если мы говорим об игре “по-взрослому”, например, техническое задание на разработку мобильного приложения или сайта, то это отдельная работа, за которую платятся немалые деньги. Вы привлекаете человека, как правило, это бывший или действующий технический директор (Chief Technical Officer) и просите его помочь вам.

Наличие бороды необязательно

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

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

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

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

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

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

Почта, это прошлый век, подписывайтесь на наш telegram канал!

Примеры технического задания

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

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

Далее будут приведены примеры тех.задачний из интернета.

ТЗ на разработку интернет магазина

ТЗ на разработку мобильного приложения

ТЗ на сервисы/обновления

Если нужно больше образцов, просто погуглите.

Рекомендации и советы

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

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

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

Например для задачи “Кнопка лайк на сайте”:

  1. Описание: необходимо создать кнопку “Лайк” на нашем сайте.
  2. Назначение и цели: вовлечение пользователей, выдача/рейтинг материалов по кол-ву лайков.
  3. Требования: дизайн такой (пример: ссылка на что-то похожее), функционал (любой пользователь может оценить картинку и поставить лайк, система сайта учитывает кол-во лайков и меняет выдачу материалов), технологии (доступно на desktop и mobile версиях сайта).
  4. Описание работ: нарисовать 3 варианта макетов для кнопок (дата готовности: 01.10.17), разработать систему выдачи материалов по лайкам (дата: 14.10.17), тестирование функции (дата: 16.10.17), релиз (дата: 17.10.17)
  5. Приемка работ: пользователь нажимает на кнопку лайк, система засчитывает нажатие, выдача материалов меняется.
  6. Приложения: эскизы, наброски, примеры проектов, где работает похожая функция.

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

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

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

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

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

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

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

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

Что такое ТЗ и зачем оно нужно

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

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

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

Как составить ТЗ

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

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

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

  • обоснование строительства;
  • вид строительных работ (реконструкция, новое либо капитальное строительство или это ремонт: капитальный либо некапитальный);
  • все данные заказчика в полном объеме (ФИО либо название организации, юр. и факт. адрес, банковские реквизиты и т.п.);
  • особенности участка, на котором планируется проводить строительные работы;
  • требования к объекту строительства (его тип, назначение, количество этажей, площадь, условия пользования подземным пространством, а также готовых проектов;
  • очередность (порядок) строительства;
  • сроки начала и завершения строительных работ и срок сдачи объекта в эксплуатацию, что обязательно должно быть оговорено в договоре заказа;
  • характеристики качества возводимого объекта (по ГОСТу 54257-2010);
  • характер этапов проектирования;
  • разрешительная документация для строительства.

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

Рекомендуем к прочтению

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

Добавить комментарий Отменить ответ

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

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

ООО «Техническая документация»

разработка техдокументации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Первой автоматизированной системой, возможно, стала ветряная мельница. Вытащил стопор — «лопасти» вращаются, жернова молотят. «Нажатие одной кнопки» — 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 в виде htm-файла, затем просто открывается вордом и сохраняется в формате 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 Требования к применению в системе языков программирования высокого уровня

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Смотрите так же:  Как посчитать единовременное пособие по рождению

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дальше — применение связки.

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

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

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

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

  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. минимальное применение «тематических» ГОСТов.

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

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

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