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

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

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

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

• Коммерческая организация решила внедрить у себя автоматизированную систему. Она не имеет собственной 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 «Требования к системе», а конкретно мы будет формулировать требования из соображений понятности, конкретности и тестируемости.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

разработки (и не только), практические подготовки технического задания. Бо льшая часть уже готовых к применению логических элементов ТЗ приведены в конце статьи. Редакция от 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. минимальное применение «тематических» ГОСТов.

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

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

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

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

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

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

• разработке приложений;
• проектировании дома;
• написании текстов и другие.

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

Как составить техническое задание: структура ТЗ на сайт

Прежде чем приступать к работе:

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

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

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

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

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

Опишите сайт

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

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

Расскажите о структуре

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

• Схемой
• Таблицей
• Списком

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

Опишите, что будет на каждой из страниц

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

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

Выдвините требования к дизайну

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

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

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

Опишите требования к инструментам, коду, хостингу, домену

Это нужно, чтобы заранее знать, с какими инструментами можно работать, а с какими - нет. Опишите отдельным блоком:

• На какой должен находиться сайт - Вордпресс, Джумла, Модэкс и так далее
• Какой язык программирования можно использовать - PHP, JavaScript, HTML, другие
• На каком хостинге и в какой доменной зоне должен располагаться сайт, какое доменное имя можно использовать
• Какую программную платформу можно использовать - .NET, OpenGL, DirectX
• И так далее

Если клиент не понимает ничего в используемых терминах - объясните, чем отличается Вордпресс от Модэкса, PHP от HTML, домен в зоне.ru от домена в зоне.com. Вместе составьте требования так, чтобы они устроили клиента.

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

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

• Приемлемую для вас скорость загрузки сайтов или стандартное значение - 1–5 секунд
• Кроссбраузерность - распишите, в каких браузерах сайт должен открываться
• Адаптивность - укажите размеры экранов, под которые должен подстраиваться дизайн, и используемые устройства
• Устойчивость к нагрузкам - сколько человек должно находиться на сайте одновременно, чтобы он не «лег»
• Устойчивость к хакерским и dDos-атакам: сайт должен выдержать небольшие атаки

Распишите сценарии работы сайта

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

Уточните, кто занимается контентом.

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

• - не меньше 95% по Адвего, Текст.ру, Контент.Вотч
• Тошноте (заспамленности)- не более 10% по Адвего иди 65% по Текст.ру
• Баллам по Главреду - не менее 6,5 или 7 баллов

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

Укажите сроки

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

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

Запомните: в каждом ТЗ должны быть несколько основных блоков:

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

Пример составления ТЗ на программное обеспечение

Нужно создать ПО. Технические требования - ниже.

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

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

• Линк
• Название статьи
• Лид-абзац

Если больше 10 совпадений, нужно разделить на страницы - по 10 на каждой.

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

Сроки : до 15.09.2018.

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

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

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

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

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

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

Конструкторское бюро

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ТЗ на сайт

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

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

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

Вот так надо

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

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

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

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

Ну вот

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