Кто пишет тз. Техническое задание согласно госту. Требования к программному обеспечению

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

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

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

Нормативная база

Основными нормативными документами, регламентирующими правила подготовки и оформления ТЗ, являются:

• межгосударственный стандарт ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы» (далее – ГОСТ 34.602-89), который распространяется на автоматизированные системы для автоматизации различных видов деятельности (управление, проектирование, исследование и т.п.), включая их сочетания, и устанавливает состав, содержание, правила оформления документа «Техническое задание на создание (развитие или модернизацию) системы»;
• государственный стандарт ГОСТ 19.201-78 «Единая система программной документации. Техническое задание. Требования к содержанию и оформлению» (далее – ГОСТ 19.201-78). Стандарт устанавливает порядок построения и оформления ТЗ на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.

ГОСТ 34.602-89 предназначен для разработчиков автоматизированных систем, ГОСТ 19.201-78 – для разработчиков программных средств.

Обратите внимание! Согласно п. 1 ст. 46 Федерального закона от 27.12.2002 № 184-ФЗ «О техническом регулировании» (в ред. от 03.12.2012) со дня вступления в силу данного закона впредь до вступления в силу соответствующих технических регламентов требования к продукции или к продукции и связанным с требованиями к продукции процессам проектирования (включая изыскания), производства, строительства, монтажа, наладки, эксплуатации, хранения, перевозки, реализации и утилизации, установленные нормативными правовыми актами Российской Федерации и нормативными документами федеральных органов исполнительной власти, носят рекомендательный характер и подлежат обязательному исполнению только в части, соответствующей целям:

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

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

Состав ТЗ на АС

Согласно п. 2.1 ГОСТ 34.602-89 ТЗ на АС содержит следующие разделы, которые могут быть разделены на подразделы:

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

В ТЗ на АС могут включаться приложения.

Правила оформления ТЗ на АС по ГОСТ 34.602-89

Правилам оформления ТЗ на АС в ГОСТ 34.602-89 посвящен небольшой раздел, в котором даны указания по правилам нумерации листов, оформления титульного листа и дополнений к документу.

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

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

При необходимости на титульном листе ТЗ на АС допускается помещать установленные в отрасли коды, например: гриф секретности, код работы, регистрационный номер ТЗ и др.

Форма титульного листа ТЗ на АС приведена в Приложении 2 к ГОСТ 34.602-89 (Пример 1).

Пример 1

Форма титульного листа ТЗ на АС

______________________________________________________. наименование организации – разработчика ТЗ на АС УТВЕРЖДАЮ Руководитель (должность, наименование предприятия – заказчика АС) УТВЕРЖДАЮ Руководитель (должность, наименование предприятия – разработчика АС) Личная подпись Расшифровка подписи наименование вида АС ________________________________________________________ наименование объекта автоматизации ________________________________________________________ сокращенное наименование АС ТЕХНИЧЕСКОЕ ЗАДАНИЕ На ____ листах Действует с СОГЛАСОВАНО Руководитель (должность, наименование согласующей организации) Личная подпись Расшифровка подписи

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

■ Оформление последнего листа ТЗ на АС. Форма последнего листа ТЗ на АС, на котором помещают подписи разработчиков и должностных лиц, участвующих в согласовании и рассмотрении проекта ТЗ на АС, приведена в Приложении 3 к ГОСТ 34.602-89 (Пример 2).

Пример 2

Форма последнего листа ТЗ на АС

_________________________________________

(код ТЗ)

СОСТАВИЛИ

	Должность исполнителя	Фамилия, имя, отчество

СОГЛАСОВАНО

Наименование организации, предприятия	Должность	Фамилия, имя, отчество

Согласно п. 3.2 ГОСТ 34.602-89 ТЗ на АС оформляется в соответствии с требованиями межгосударственного стандарта ГОСТ 2.105-95 «Единая система конструкторской документации . Общие требования к текстовым документам», устанавливающего общие требования к выполнению текстовых документов на изделия машиностроения, приборостроения и строительства.

Правила оформления текстовой части ТЗ на АС по ГОСТ 2.105-95

Согласно п. 3.1 ГОСТ 2.105-95 текстовые документы подразделяют на документы, содержащие, в основном, сплошной текст (технические условия, паспорта, расчеты, пояснительные записки, инструкции и т.п.), и документы, содержащие текст, разбитый на графы (спецификации, ведомости, таблицы и т.п.). Текстовые документы выполняют в бумажной форме и (или) в форме электронного документа.

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

Требования к текстовым документам, содержащим в основном сплошной текст, подробно изложены в четвертом разделе ГОСТ 2.105-95. Рассмотрим основные положения этого раздела.

■ Построение документа. В п. 4.1 ГОСТ 2.105-95 приведены подробные инструкции по нумерации и расположению разделов, подразделов, пунктов и подпунктов.

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

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

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

Если раздел или подраздел состоит из одного пункта, он также нумеруется.

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

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

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

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

Обратите внимание: переносы слов в заголовках не допускаются.

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

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

В п. 4.2 ГОСТ 2.105-95 приведены правила изложения текста документов . Эти правила адресованы в основном разработчикам ТЗ на АС, однако некоторые из них полезно знать всем работникам, чья деятельность связана с составлением и оформлением документов.

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

– применять обороты разговорной речи, техницизмы, профессионализмы;

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

– применять произвольные словообразования;

– применять сокращения слов, кроме установленных правилами русской орфографии, соответствующими государственными стандартами, а также в данном документе;

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

В соответствии с подп. 4.2.4 ГОСТ 2.105-95 в тексте документа, за исключением формул, таблиц и рисунков, не допускается:

– применять математический знак минус (–) перед отрицательными значениями величин (следует писать слово «минус»);

– применять знак «Ø» для обозначения диаметра (следует писать слово «диаметр»);

– применять без числовых значений математические знаки, например > (больше), < (меньше), = (равно), ≥ (больше или равно), ≤(меньше или равно), ≠ (не равно), а также знаки № (номер), % (процент).

Если в тексте приводится ряд числовых значений, выраженных в одной и той же единице физической величины, то ее указывают только после последнего числового значения, например: 1,50 ; 1,75 ; 2,00 м .

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

От 1 до 5 мм.

От плюс 10 до минус 40 °С.

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

Наш совет. Чтобы не допустить отделение единицы измерения физической величины от ее числового значения, используйте неразрывный пробел: после числового значения вместо клавиши «пробел» нажмите сочетание клавиш «Ctrl + Shift + пробел ».

В подп. 4.2.21 ГОСТ 2.105-95 разъясняется, что примечания следует помещать непосредственно после текстового, графического материала или в таблице, к которым относятся эти примечания, и печатать с прописной буквы с абзаца. Если примечание одно, то после слова «Примечание» ставится тире и примечание печатается тоже с прописной буквы. Одно примечание не нумеруют. Несколько примечаний нумеруют по порядку арабскими цифрами. Примечание к таблице помещают в конце таблицы над линией, обозначающей окончание таблицы.

Примеры оформления примечаний:

Примечание – ________________________________________________________

Примечания

1. __________________________________________________________________

2. __________________________________________________________________

Обратите внимание! Согласно подп. 4.6.2 ГОСТ 2.105-95 примеры, которые приводятся в тексте документа, размещают, нумеруют и оформляют так же, как и примечания (подп. 4.2.21 ГОСТ 2.105-95).

Правила оформления иллюстраций и приложений приведены в п. 4.3 ГОСТ 2.105-95.

■ Иллюстрации , за исключением иллюстраций приложений, следует нумеровать арабскими цифрами сквозной нумерацией. Если рисунок один, то он обозначается: Рисунок 1 . Иллюстрации каждого приложения обозначают отдельной нумерацией арабскими цифрами с добавлением перед цифрой обозначения приложения, например: Рисунок А.3 . Мелкие иллюстрации, которые размещены непосредственно в тексте и на которые в дальнейшем нет ссылок, допускается не нумеровать.

Допускается нумеровать иллюстрации в пределах раздела. В этом случае номер иллюстрации состоит из номера раздела и порядкового номера иллюстрации, разделенных точкой, например: Рисунок 1.1 .

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

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

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

Приложения обозначают заглавными буквами русского алфавита, начиная с А, за исключением букв Ё, З, Й, О, Ч, Ь, Ы, Ъ. Допускается обозначение приложений буквами латинского алфавита, за исключением букв I и О. Если в документе одно приложение, оно обозначается «Приложение А».

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

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

■ Таблицы. Их построению посвящен п. 4.4 ГОСТ 2.105-95. Это наиболее полное и подробное описание правил создания и оформления таблиц в текстовых документах из тех, с которыми автору приходилось встречаться.

Рассмотрим наиболее важные правила из тех, что приведены в п. 4.4 ГОСТ 2.105-95.

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

Таблица 1 – если в документе одна таблица;

Таблица В.1 – если таблица приведена в приложении В.

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

Обратите внимание! В тексте документа должны быть приведены ссылки на все таблицы документа , при ссылке следует писать слово «таблица» с указанием ее номера.

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

Обратите внимание! Разделять заголовки и подзаголовки боковика и граф диагональными линиями не допускается.

Таблицу, в зависимости от ее размера, помещают под текстом, в котором впервые дана ссылка на нее, или на следующей странице, а при необходимости – в приложении к документу.

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

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

Обратите внимание! В соответствии с Изменением № 1, введенным в действие приказом Ростехрегулирования от 22.06.2006 № 117-ст, при подготовке текстовых документов с использованием программных средств (например, приложения MS Word или MS Excel) надпись «Продолжение таблицы» допускается не указывать .

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

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

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

Для сокращения текста заголовков и подзаголовков граф отдельные понятия заменяют буквенными обозначениями, установленными ГОСТ 2.321-84 «ЕСКД. Обозначения буквенные» (переиздан в марте 2002 г.), или другими обозначениями, если они пояснены в тексте или приведены на иллюстрациях, например D – диаметр , Н – высота , L – длина .

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

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

■ Сноски. Их оформление регламентировано п. 4.5 ГОСТ 2.105-95.

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

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

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

2 голоса

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

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

План действий по работе с заказчиком

Вы находите клиента. Он готов заплатить деньги, а вы приступить к работе. С чего же начать и как действовать?

• Первое общение.

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

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

• Подготовка и первый бриф.

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

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

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

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

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

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

• Разработка и прием.

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

Чего не должно быть в ТЗ, а что там быть обязано

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

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

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

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

И не забывайте про подпись. Все серьезно, заказчик должен это понимать.

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

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

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

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

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

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

Выглядит оно так:

1. Глоссарий
2. Общие положения
3. Предмет разработки
4. Назначение документа
5. Требования к графическому дизайну сайта
6. Требования к дизайну сайта
7. Порядок утверждения дизайн-концепции
8. Функциональные требования
9. Требования к представлению сайта
10. Требования к системе управления сайтом
11. Требования к разделению доступа
12. Требования к видам обеспечения
13. Требования к информационному обеспечению
14. Требования к программному обеспечению
15. Требования к техническому обеспечению
16. Требования к лингвистическому обеспечению
17. Требования к эргономике и технической эстетике
18. Требования к приемке-сдаче проекта
19. Требования к наполнению информацией
20. Требования к персоналу
21. Порядок предоставления дистрибутива
22. Порядок переноса сайта на технические средства заказчика

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

Глоссарий

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

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

Общие положения

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

Предмет разработки

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

Задумайтесь, каким образом клиент будет зарабатывать деньги, какова его цель. Если это интернет-магазин, то он должен заниматься продажами, если корпоративный сайт, то здесь любят красивую фразу: «повышение лояльности к бренду», информирование о деятельности компании и так далее.

Назначение документа

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

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

Требования к графическому дизайну сайта

Требования к дизайну сайта

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

Порядок утверждения дизайн-концепции

В этой части вы опять запугиваете клиента, пользуясь юридическими терминами. Рассказываете о том, что собираетесь предоставить ему дизайн сайта в виде картинки, сделанной в Фотошопе. Он обязан его посмотреть в указанный срок. По истечение которого предоставить вам правки, а вы в свою очередь еще подумаете, а не олень ли он, и будете согласовывать и разбираться в том, насколько эти изменения логичны и будете ли вы браться за «исправление».

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

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

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

Требования к представлению сайта

1. Структура сайта: описываем какие категории (рубрики) будут на сайте.
2. Главная страница: лучше всего со схематической картинкой и описанием основных элементов.
3. Внутренние страницы: тоже что и в предыдущем пункте. Схема и описание внутренних страничек.

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

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

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

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

Требования к разделению доступа

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

Требования к видам обеспечения

Требования к информационному обеспечению

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

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

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

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

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

1. Тут речь идет о хостинге или серверах. Так как мой блог ориентирован на создателей, которые работают на Таймвебе (https://timeweb.ru ) – все очень просто. Если вы не из «наших», то нужно смотреть на технические характеристики. Например, кто-то очень умный делает крутой сайт, а потом пытается подключить его к хостингу, а технические характеристики настолько завышены, что ни один хостинг в России не справляется. Пункт нужный, но не для новичков в сфере разработки.
2. Здесь мы описываем будет ли портал иметь мобильную версию, адаптирован под портативные устройства или сможет открываться только через Google Chrome, а любые искривления в других браузерах нас вообще не волнуют.

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

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

Требования к эргономике и технической эстетике

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

Требования к приемке-сдаче проекта

Требования к наполнению информацией

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

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

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

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

Порядок предоставления дистрибутива

Что вы отдадите заказчику, когда работа будет выполнена: логин, пароль, туда-сюда.

Набиваем цену технического задания

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

В этом документе должно впечатлять все! Если вы собираетесь переслать его для предварительного ознакомления по почте, то обязательно используется формат PDF. И клиенту вероятно не захочется мучить себя правками и о вас он будет думать, как о профессионале. Мелочь, а значительная. Для преобразования вордовского документа можно использовать сервис https://smallpdf.com/ru/ .

Не забудьте вставить фоном логотип собственной компании или вашего бренда, а также вставить контакты. Быстро и качественно их можно оформить на сайте https://logaster.ru .

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

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

СКАЧИВАЕМ ШАБЛОН ТЗ

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

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

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

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

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

• Исполнителю грамотное ТЗ на разработку сайта поможет заранее оценить объём работы, её сложность и стоимость. Понять, справится ли он с такой задачей самостоятельно, или стоит взять помощников. А затем сделать именно то, чего от него ждёт заказчик.
• Заказчику техзадание даёт уверенность в том, что он задокументировал свои пожелания к будущему сайту, чётко обозначил сроки, в которые должен уложится исполнитель, прописал требования к работе сайта. И если результат окажется неудовлетворительным, можно предъявить обоснованную претензию: «Не соответствует ТЗ!»

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

Ваше пожелание «блог с бесплатными материалами, страницей обо мне и контактами» исполнитель видит так:

Вы думаете, этого достаточно для создания сайта?

Вы получаете готовый сайт, и тут вдруг оказывается, что вы имели в виду вот это:

Нюансы описания очень важны

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

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

О чём пишут в техзадании?

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

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

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

• Для чего и для кого создаётся сайт?
• Чем он будет наполнен?
• Как это всё будет функционировать?
• Кто и как будет работать над проектом, кто за что отвечает?
• Что будет приниматься на выходе?

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

1. Информация о заказчике, то есть о вас

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

2. Информация о проекте

Что это будет: сайт-визитка, интернет-магазин, корпоративный портал, электронная библиотека?

3. Целевая аудитория сайта

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

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

4. Цели и задачи, которые должен решать сайт для заказчика и для аудитории

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

Указывайте прямое назначение вашего сайта.

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

5. Рамки проекта (основной функционал)

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

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

6. Структура (карта) сайта

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

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

Схема взаимосвязей отдельных частей сайта

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

7. Отдельные страницы

Пока вы рисуете карту сайта, каждая страница - это просто квадратик. Но исполнителю нужно понимать, что и в каком порядке на этом квадратике будет расположено (вспоминаем примеры таблиц в начале статьи). Какие там будут информационные блоки? На каждой ли странице будут меню, сайдбар (отдельный блок с навигацией) , футер (нижний блок) ? Хотите ли вы видеть на странице баннеры, картинки? Будут ли они статичные или движущиеся?

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

По сути на этом этапе создаётся . Об этом мы уже писали, если вам предстоит создание сайта, обязательно почитайте.

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

8. Требования к дизайну сайта

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

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

С сайтами на движках типа WordPress или Joomla можно обойтись готовыми шаблонами (иногда даже бесплатными). Это снижает неопределённость: просто посмотрите шаблоны и выберите тот, который вам нравится. С точки зрения дизайна, некоторые из них бывают довольно странными, поэтому постарайтесь проконсультироваться со специалистом, - это всё равно выйдет дешевле, чем заказывать дизайн с нуля.

9. Рабочий функционал сайта

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

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

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

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

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

10. Описание контента

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

11. Технические требования

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

Пример нашёлся на habrahabr.ru/post/140574/

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

Например, ваш сайт должен:

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

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

В остальном придётся полагаться на совесть исполнителя.

Информация, которую я дала в статье, - мой опыт. Мне приходилось заказывать сайты с нуля и дорабатывать существующие. Первая версия сайта аzconsult.ru - один из самых маленьких проектов, с которыми я работала. Для крупных проектов есть нюансы, но не думаю, что они вам понадобятся.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кроме того, есть ряд ГОСТов, например, 19.201-78, в которых прописано, что и в каком виде должно содержаться в подобном документе.

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

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

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

Так как же составить ТЗ, по которому в итоге получится именно то, что было заложено его автором(-ами), а не то, что «умеет типовой функционал конфигурации»?

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

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

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

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

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

4. Ссылки на популярные решения . Зачастую, для всех, к примеру, менеджеров по продажам компании, фраза «функционал ведения сделок» означает примерно одно и то же, но для сотрудников подрядчика эта фраза не значит ровным счетом ничего. Но добавьте пару слов в эту фразу, и из варианта «карточка сделки, аналогичная таковой в Битрикс24(или 1С:CRM)» уже понятно, чего примерно ожидает от этой самой карточки Заказчик.

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

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