Как писать техническое задание на программу по ГОСТ 19.201-78?
Создан 15.02.2010 15:50:53
Примечание от 11.06.2014 г. - Уважаемые дамы и господа! Наверное, в каждом втором-третьем из ваших технических заданий на программы, тем или иным образом оказавшихся в руках автора, содержатся аутентичные тексты из настоящей статьи. Это здорово и чертовски приятно, но следует учитывать тот факт, что прошло почти десятилетие с момента первой статьи, а за это время многое изменилось, особенно в части. Из песни, конечно, слов не выкинешь, но настройтесь на креатив и выдумывайте какие-нибудь более современные ее аранжировки. И не забывайте о том, что это , а не «» документ.
Техническое задание в соответствии с на листах формата 11 и 12 по ГОСТ 2.301-68, как правило, без заполнения листа. Номера листов (страниц) проставляются в верхней части листа над [из п. 1.1 ГОСТ 19.201-78]
Лист утверждения и титульный лист
Лист и титульный лист оформляют в соответствии с ГОСТ 19.104-78.
Информационную часть (и), лист регистрации изменений допускается в документ не включать [из п. 1.2 ГОСТ 19.201-78]
Указанной возможностью следует воспользоваться. Меньше слов – меньше вопросов.
Изменения и дополнения
Для внесения или дополнений в техническое задание на последующих или выпускают дополнение к нему. и дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания [из п. 1.3 ГОСТ 19.201-78]
Учесть все детали на начальных невозможно, поэтому на практике указанный подход применяется весьма часто. В «Стадии и этапы разработки» следует явно указать возможность внесения изменений и дополнений в техническое задание: «Содержимое разделов настоящего технического задания может быть изменено и дополнено по согласованию с заказчиком».
Состав разделов технического задания
Техническое задание должно содержать следующие:
- введение;
- основания для;
- назначение разработки;
- к или;
- требования к;
- технико-экономические показатели;
- порядок и;
- в техническое задание допускается включать приложения.
В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них [из п. 1.4 ГОСТ 19.201-78]
Любые манипуляции с разделами - строго по с.
Отдельные подразделы технического задания могут подействовать на условного заказчика, как красная тряпка на быка. Заказчика, даже условного, раздражать не следует. В спорных подразделах будут рассмотрены пути поиска компромиссных решений. Ключевые позиции, в которых уступка заказчику равносильна затягиванию петли на шее исполнителя, будут также откомментированы с обоснованием жесткой позиции исполнителя.
Чтобы излишне не отягощать ход повествования, в качестве будем использовать реальную программу с, обеспечивающую возможность выполнения нескольких шаблонных функций. Пусть такой программой станет несложный.
Введение
В разделе «Введение» указывают, краткую характеристику области применения или и объекта, в котором используют программу или программное изделие [из п. 2.1 ГОСТ 19.201-78]
Основное правило работы с – детализация, дробление текста на структурные единицы, - разделы, подразделы, пункты и подпункты, см. статью «» документа будет иметь четкую структуру, способствующую легкому требуемого материала. Текст документа станет структурированным и удобным для чтения. Создаем подразделы:
Наименование программы
Наименование программы – «Текстовый редактор для работы с файлами формата rtf».
Краткая характеристика области применения
Программа предназначена к применению в профильных подразделениях на объектах заказчика.
Содержимое отдельных пунктов не всегда очевидно. При затруднениях следует подходить формально. документ можно будет в ходе технического задания с заказчиком.
Основания для разработки
В разделе «Основания для разработки» должны быть указаны:
- документ (документы), на основании которых ведется разработка;
- , этот документ, и дата его утверждения;
- и (или) условное обозначение темы разработки.
[из п. 2.2 ГОСТ 19.201-78]
Основание для проведения разработки
Основанием для проведения разработки является Договор (письмо и т.д.) № 666 от 32 мартобря 2004 года (входящий № такой-то от такого-то). Договор утвержден Директором ФГУП «Спецтяжмонтажстройсельхозавтоматика» Ивановым Петром Ивановичем, именуемым в дальнейшем Заказчиком, и утвержден Генеральным директором ОАО «Суперсофт» Блюмкинсом Иваном Ароновичем, именуемым в дальнейшем Исполнителем, такого-то мартобря 2004.
Удобно воспользоваться разделом «Общие сведения» , поскольку разработчик имеет полное право дополнять и удалять разделы технического задания на свое усмотрение. В то же время сведения, указанные выше, содержатся в договоре. Следует ли приводить их в техническом задании – зависит от конкретного случая.
Наименование и условное обозначение темы разработки
Наименование темы разработки – «Разработка текстового редактора для работы с файлами формата rtf». Условное обозначение темы разработки (шифр темы) – «РТФ-007»
Назначение разработки
В разделе «Назначение разработки» должно быть указано и эксплуатационное назначение или [из п. 2.3 ГОСТ 19.201-78]
Функциональное назначение
Функциональным назначением программы является предоставление пользователю возможности работы с текстовыми документами в формате rtf.
В подразделе должно быть указано «укрупненное» функциональное назначение программы. Детали – перечень функций и т.д. – будут приведены ниже, в соответствующих разделах.
Эксплуатационное назначение может трактоваться достаточно широко. Где, как, кем, с чем должна эксплуатироваться программа?
Резина одного типоразмера может успешно экслуатироваться на Жигулях и Волгах, но не на КаМАЗе. По причине отсутствия. И наоборот. Но для каждого конкретного типоразмера резины можно определить ее эксплуатационное назначение.
Применим формальный подход:
Эксплуатационное назначение
Программа должна эксплуатироваться в профильных подразделениях на объектах заказчика. должны являться сотрудники профильных подразделений объектов заказчика.
Два крайних предложения - не в тему. При проведении переговоров с реальным заказчиком подраздел будет откорректирован.
Требования к программе или программному изделию
Раздел «Требования к программе или программному изделию» должен содержать следующие подразделы:
- требования к функциональным характеристикам;
- требования к;
- требования к составу и параметрам;
- требования к и;
- требования к и;
- требования к и;
- специальные требования.
[из п. 2.4 ГОСТ 19.201-78]
Если существуют стандарты, содержащие общие (технические) требования к программе, или, к примеру, «ГОСТ 12345-67. Автоматизированные информационно-измерительные системы. Общие (технические) требования», разработка технического задания существенно упрощается. Большая часть содержимого указанного стандарта просто переписывается в техническое задание.
Требования к составу выполняемых функций
Программа должна обеспечивать возможность выполнения перечисленных ниже функций:
- функции создания нового (пустого) файла;
- функции открытия (загрузки) существующего файла;
- функции редактирования открытого (далее - текущего) файла путем ввода, содержимого файла с применением стандартных;
- функции редактирования текущего файла с применением;
- функции файла с исходным;
- функции сохранения файла с именем, отличным от исходного;
- функции отправки содержимого текущего файла электронной почтой с помощью внешней клиентской почтовой программы;
- функции вывода оперативных справок в (подсказок);
- функции;
- функции отображения названия программы, версии программы, копирайта и комментариев разработчика.
Клише «обеспечивать возможность выполнения» применимо к современным программным средствам, разработанным с использованием графического пользовательского интерфейса. Указанные программные средства большей частью «простаивают» (idle), ожидая. Применение клише - шаблонного построения фраз - детально расписано в статье «».
Требования к организации входных данных
программы должны быть организованы в виде отдельных файлов формата rtf, соответствующих RFC... Файлы указанного формата должны размещаться () на локальных или съемных, согласно требованиям операционной системы.
Любой иного, но с расширением rtf, открываться не должен.
Файлы http://domain.net/file.rtf или ftp://domain.net/file.rtf открываться не должны. Если файловая система отформатирована как FAT32, файлы с локального или съемного, отформатированного, к примеру, в формате ext3, открываться не должны.
Требования к организации выходных данных
Требования те же, что и к организации выходных данных. Тот самый случай, когда следует объединить оба пункта технического задания.
Требования к временным характеристикам
Требования к временным характеристикам программы не предъявляются.
Следует уточнить, предъявляет ли заказчик требования к быстродействию программы, к примеру, за какое время программа должна стартовать, открывать и закрывать файлы заданного объема. Если заказчик укажет конкретные цифры, следует подстраховаться и заложить в требованиях к составу и параметрам технических средств стоимостью от $2500. Правда, такую сумму придется обосновывать. Если временные характеристики для заказчика не принципиальны, следует обязательно написать об отказе от требований к временным характеристикам, см. формулировку выше.
Требования к надежности
В подразделе «Требования к надежности» должны быть указаны требования к обеспечению функционирования (обеспечения, контроль входной и выходной информации, после и т.п.) [из п. 2.4.2 ГОСТ 19.201-78]
– штука тонкая и очень опасная. Но перечень функций и видов их, согласно п. 1.3.2. , обязан составить заказчик и согласовать с исполнителем.
Скорее всего, дождаться от заказчика чего-либо вразумительного не удастся. Стоит разъяснить заказчику, что надежное функционирование программы зависит не столько от исполнителя, сколько от надежности технических средств и, а также предложить заказчику ряд жестких мер для повышения и.
Требования к обеспечению надежного (устойчивого) функционирования программы
Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением заказчиком совокупности организационно-технических мероприятий, перечень которых приведен ниже:
- организацией бесперебойного питания технических средств;
- использованием программного обеспечения;
- регулярным выполнением рекомендаций Министерства труда и социального развития РФ, изложенных в Постановлении от 23 июля 1998 г. «Об утверждении межотраслевых типовых норм времени на работы по сервисному обслуживанию ПЭВМ и оргтехники и сопровождению программных средств»;
- регулярным выполнением требований ГОСТ 51188-98. Защита инфоpмации. Испытания пpогpаммных сpедств на наличие.
К списку можно добавить еще несколько десятков. В ходе первичного согласования технического задания заказчик, скорее всего, начнет проявлять склонность к компромиссу.
Возможен более гуманный подход. Под надежностью (правда, системы, по тому же ГОСТу) можно считать выполнение некой i-той функции в течение конкретного интервала времени. Предложим заказчику считать критерием надежной работы программы следующий показатель: заказчик в течение часа 100 раз открывает и закрывает файл. Если в указанном интервале времени программа не даст, считаются выполненными.
Если заказчик, наконец, убедился, что надежность зависит не столько от исполнителя, сколько от надежности технических средств и операционной системы, и махнул рукой – в разделе обязательно следует написать такую фразу:
Требования к обеспечению надежного (устойчивого) функционирования программы не предъявляются.
Время восстановления после отказа
Вызванного сбоем электропитания технических средств (иными внешними факторами), не фатальным сбоем (не крахом) операционной системы, не должно превышать стольких-то минут при условии соблюдения технических и программных средств. Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем (крахом) операционной системы, не должно превышать времени, требуемого на устранение технических средств и переустановки программных средств.
Перечень аварийных ситуаций ситуаций также составляет заказчик и согласовывает с исполнителем. Фактически, это время на перезагрузку операционной системы, если отказ не фатален, не вызван крахом операционной системы или выходом из строя технических средств.
Отказы из-за некорректных действий оператора
Отказы программы возможны вследствие при взаимодействии с операционной системой. Во избежание возникновения отказов программы по указанной выше причине следует обеспечить работу пользователя без предоставления ему административных.
Условия эксплуатации
В подразделе «Условия эксплуатации» должны быть указаны (, относительная влажность и т.п. для выбранных типов), при которых должны обеспечиваться заданные характеристики, а также, необходимое количество и персонала [из п. 2.4.3 ГОСТ 19.201-78]
Очень опасный подраздел для тех, кто делает первые шаги в разработке технического задания.
Климатические условия эксплуатации
Климатические условия эксплутатации, при которых должны обеспечиваться заданные характеристики, должны удовлетворять требованиям, предъявляемым к техническим средствам в части условий их эксплуатации.
Программа будет прекрасно работать от плюс 5 до плюс 35 °C при относительной влажности 90 % и атмосферном давлении 462 мм.рт.ст., поскольку такие условия приблизительно соответствуют условиям эксплуатации современных компьютеров непромышленного исполнения. Но как только в техническом задании окажется конкретика и задание будет утверждено, заказчик получает отличный шанс заставить исполнителя провести в полном объеме за счет исполнителя.
Много лет тому назад автор статьи, в силу молодости и неукротимого желания отстоять свою позицию (в техническом задании, в частности), «попал на климатику», причем «попал конкретно» (так, со слов Путина, выражается просвещенная интеллигенция), на довольно крутом «железе». Автор статьи мигом усвоил, что такое «показать кузькину мать» и «где раки зимуют». Упаси Вас господь «попадать на климатику»!
Примечание от 10.02.2011 г. - По иронии судьбы специалисты «Технической документации» не так давно снова «попали на климатику», а точнее - провели разработку программы и методики испытаний на воздействие внешних факторов , по и подготовили, открыв для себя еще одно. Не зря говорят, что история развивается по восходящей спирали...
Требования к видам обслуживания
Программа не требует проведения каких-либо видов.
Виды обслуживания следует позаимствовать из подраздела «Требования к обеспечению надежного (устойчивого) функционирования».
Если заказчик в ходе согласования технического задания сошлется на отсутствие или желание проводить все виды обслуживания собственными силами, имеет смысл предложить разработку технического задания на за отдельные деньги отдельным договором. Откажется – следует считать программу.
Требования к численности и квалификации персонала
Минимальное количество персонала, требуемого для работы программы, должно составлять не менее 2 штатных единиц – системный администратор и пользователь программы – оператор.
Системный администратор должен иметь высшее профильное образование и компании-производителя операционной системы. В перечень задач, выполняемых системным администратором, должны входить:
- задача поддержания технических средств;
- задачи установки (инсталляции) и поддержания работоспособности системных программных средств – операционной системы;
- задача установки (инсталляции) программы.
Пользователь программы (оператор) должен обладать практическими навыками работы с операционной системы.
Персонал должен быть аттестован на II квалификационную группу по электробезопасности (для работы с конторским оборудованием).
При отсутствии самой ключевой фразы в утвержденном техническом задании заказчик вправе затребовать от исполнителя разработку руководства по эксплуатации графического пользовательского интерфейса операционной системы, мотивируя тем, что оператор «не справляется» с программой.
Персонал, не имеющий II квалификационной группы по электробезопасности, не имеет права даже близко подходить к и конторскому оборудованию.
Требования к составу и параметрам технических средств
В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав с указанием их основных технических характеристик [из п. 2.4.4 ГОСТ 19.201-78]
Следует подбирать не хуже той, на которой будет производиться разработка. Логично затребовать, чтобы технику предоставил заказчик не позднее указанного срока. Речь идет, разумеется, о компьютере.
В состав технических средств должен входить IBM-совместимый персональный компьютер (ПЭВМ), включающий в себя:
- процессор Pentium-1000 с тактовой частотой, ГГц - 10, не менее;
- материнскую плату с FSB, ГГц - 5, не менее;
- оперативную память объемом, Тб - 10, не менее;
- и так далее…
Требования к информационной и программной совместимости
В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и решения, и, используемым программой.
При необходимости должна обеспечиваться и [из п. 2.4.5 ГОСТ 19.201-78]
Требования к информационным структурам и методам решения
Иформационная структура файла должна включать в себя текст, содержащий, предусмотренную спецификацией формата rtf.
Требования к информационным структурам (файлов) на входе и выходе, а также к методам решения не предъявляются.
Требования к исходным кодам и языкам программирования
Исходные коды программы должны быть реализованы на C++. В качестве интегрированной программы должна быть использована среда Borland C++ Buider.
Требования к программным средствам, используемым программой
Используемые программой, должны быть представлены лицензионной локализованной версией операционной системы такой-то. Допускается применение пакета обновления такого-то.
Требования к защите информации и программ
Требования к и программ не предъявляются.
Подобных требований следует избегать, если нет особого желания разработать что-то вроде концепции обеспечения информационной безопасности согласно Обеспечить некоторый уровень и программ возможно, обеспечить безопасность невозможно. Заказчик, скорее всего, это осознает и проявлять настойчивость не станет.
Требования к маркировке и упаковке
В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке, варианты и способы упаковки [из п. 2.4.6 ГОСТ 19.201-78]
Программа поставляется в виде программного изделия - на дистрибутивном (внешнем) носителе (компакт-диске). Речь идет, разумеется, о маркировке и упаковке дистрибутивного.
Требование к маркировке
Программное изделие должно иметь маркировку с обозначением компании-разработчика, типа (наименования), номера версии, порядкового номера, даты изготовления и номера Госстандарта России (если таковой имеется). Маркировка должна быть нанесена на программное изделие в виде наклейки, выполненной полиграфическим способом с учетом требований ГОСТ 9181-74.
Качество маркировки проверяется самыми изощренными способами – сначала пытаются смыть маркировку водой, затем бензином и прочими органическими растворителями. Пусть полиграфическое предприятие несет ответственность за некачественную маркировку. Задача исполнителя - прикрыться сертификатом соответствия (затребовать сертификат у полиграфистов).
Требования к упаковке
Упаковка программного изделия должна осуществляться в упаковочную тару ().
Именно предприятия-изготовителя (поставщика). Исполнитель не может и не должен нести ответственность большую, чем предприятие-изготовитель (поставщик) тары.
Условия упаковывания
Упаковка программного изделия должна проводиться в закрытых вентилируемых помещениях при температуре от плюс 15 до плюс 40 °С и относительной влажности не более 80 % при отсутствии агрессивных примесей в окружающей среде.
Заказчик получит программное изделие надлежащего внешнего вида. В случае возврата программного изделия (по) в ненадлежащем виде (наличие царапин, трещин и прочих) исполнитель сможет предъявить претензии в части нарушения заказчиком условий упаковывания и не принять программное изделие.
Порядок упаковки
Подготовленные к упаковке программные изделия укладывают в тару, представляющую собой коробки из картона гофрированного (ГОСТ 7376-89 или ГОСТ 7933- 89) согласно чертежам предприятия-изготовителя тары.
Программное изделие упаковывается с применением чехлов из водонепроницаемой пленки с обязательным наличием химически неагрессивных влагопоглотителей (силикагеля).
Для заполнения свободного пространства в упаковочную тару укладываются прокладки из гофрированного картона или пенопласта.
должна быть уложены в потребительскую тару вместе с программным изделием.
На верхний слой прокладочного материала укладывается - упаковочный лист и ведомость упаковки.
Потребительская тара должна быть оклеена лентой клеевой 6-70 по ГОСТ 18251-87.
Упакованные в потребительскую тару программные изделия должны быть уложены на поддон, стянуты лентой для предотвращения потери формы груза и упакованы в полиэтиленовую пленку М 0,2 для защиты от попадания влаги.
В коробку поддона должна быть вложена товаросопроводительная документация, в том числе упаковочный лист согласно ГОСТ 25565-88.
Габариты грузового места должны быть не более 1250 820 1180 мм.
Масса НЕТТО - не более 200 кг.
Масса БРУТТО - не более 220 кг.
Приведен порядок упаковки из ранее разработанного документа на какие-то технические средства. Выглядит несколько необычно в контексте программного изделия. Говоря простым русским языком - полнейший стёб, но требования есть и остаются требованиями.
Требования к транспортированию и хранению
В подразделе «Требования к транспортированию и хранению» должны быть указаны для условия, места, условия хранения, условия складирования, в различных условиях [из п. 2.4.7 ГОСТ 19.201-78]
В подразделе приведены условия транспортирования и хранения из ранее разработанного документа на какие-то технические средства. Это касается и требований к порядку упаковки. Выглядит несколько необычно в контексте программного изделия.
Заказчик не вправе нарушать условий транспортирования и хранения. Исполнитель сможет отказать заказчику в возврате программного изделия, утверждая, что ненадлежащий внешний вид программного изделия является следствием несоблюдения условий транспортирования и хранения.
Условия транспортирования и хранения
Допускается транспортирование программного изделия в транспортной таре всеми видами транспорта (в том числе в отапливаемых герметизированных отсеках самолетов без ограничения расстояний). При перевозке в железнодорожных вагонах вид отправки - мелкий малотоннажный.
При транспортировании и хранении программного изделия должна быть предусмотрена защита от попадания и. Не допускается кантование программного изделия. Климатические условия транспортирование приведены ниже:
- температура окружающего воздуха, °С - от плюс 5 до плюс 50;
- , кПа - такое-то;
- относительная влажность воздуха при 25 °С - такая-то.
Специальные требования
Программа должна обеспечивать взаимодействие с пользователем () посредством, разработанного согласно рекомендациям компании-производителя операционной системы.
Разработчики настоящего стандарта смотрели в будущее. Не существовало в те годы программ с графическим пользовательским интерфейсом.
Требования к программной документации
В разделе «Требования к программной документации» должен быть указан предварительный состав и, при необходимости, специальные требования к ней [из п. 2.5а ГОСТ 19.201-78]
Предварительный состав программной документации
В состав программной документации должны входить:
Программа и методика испытаний потребуется, чтобы показать заказчику, что разработанная исполнителем программа соответствует требованиям согласованного и утвержденного технического задания. После проведения совместных (приемо-сдаточных) испытаний заказчик и исполнитель подпишут. И, тем самым, работа будет закрыта, условия договора выполнены.
Допускается объединять отдельные виды эксплуатационных документов (за исключением и). Необходимость указывается в. Объединенному документу присваивают и обозначение одного из объединяемых документов. В объединенных документах должны быть приведены сведения, которые необходимо включать в каждый объединяемый документ [из п. 2.6 ГОСТ 19.101-77]
Но тем, кто впервые занялся разработкой программной документации, лучше придерживаться принципа «мухи отдельно, котлеты отдельно».
Технико-экономические показатели
В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая, предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами [из п. 2.5 ГОСТ 19.201-78]
Ориентировочная экономическая эффективность не рассчитываются. Предполагаемое число использования программы в год – 365 сеансов работы на одном рабочем месте.
Положим, заказчик оснащает программой десяток рабочих мест. Исполнитель потребовал за разработку $1000. Заказчик мог бы установить на рабочие места программный продукт третьей фирмы, стоимостью $500 за дистрибутив и по $100 за лицензию на каждое рабочее место.
Экономические преимущества разработки
Экономические преимущества разработки в сравнении с лучшими отечественными и зарубежными аналогами составит:
число рабочих мест | разработка | экономические преимущества |
|
Виды испытаний
должны проводиться на объекте заказчика в сроки…
Приемосдаточные испытания программы должны проводиться согласно разработанной (не позднее такого-то срока) исполнителем и согласованной заказчиком «Программы и методики испытаний».
Ход проведения приемо-сдаточных испытаний заказчик и исполнитель документируют в.
Общие требования к приемке работы
На основании протокола испытаний исполнитель совместно с заказчиком акт приемки-сдачи программы в эксплуатацию.
Приложения
В приложениях к техническому заданию, при необходимости, приводят:
- перечень и других работ, обосновывающих разработку;
- схемы, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
- другие источники разработки.
[из п. 2.8 ГОСТ 19.201-78]
Если есть, почему не привести. И обязательно выложить перечень ГОСТов, на основании которых должна проводиться разработка. Например:
- ГОСТ 19.201-78. Техническое задание, требования к содержанию и оформлению;
- и так далее..
Выводы
Настоящий стандарт, несмотря на свой немалый возраст, позволяет разработать полноценное техническое задание на современную программу с графическим пользовательским интерфейсом. Разработчики ГОСТ 19.201-78 смотрели в будущее и учли практически все аспекты, касающиеся разработки программных средств.
Что осталось неучтенным? Сроки, объемы и этапы финансирования? Техническое задание всегда разрабатывается на основании Договора, письма, и т.д. Указанные сведения должны быть отражены в Договоре.
Каковы спорные моменты? Отсутствие в стандарте конктретных требований, положим, к пользовательскому интерфейсу? Разработчиками стандарта предусмотрен раздел «Специальные требования», возможность добавления новых разделов, допустим, разделов «Дополнительные требования» или «Требования к интерфейсу».
- ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению
Данный текст был создан сугубо ради существования постоянной ссылки, которую бы сам автор, да и все вы - могли бы смело отправлять своим будущим заказчикам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «А надо ли мне ваше ТЗ и вообще что это?»
Как говорится - «вместо тысячи слов», поскольку каждый раз евангелистить по 4-5 часов в скайпе на данную тему становится уже утомительным, а общемировая тенденция подсовывать под определение «Технического задания» откровенную ерунду с годами все только усиливается.
Проблема
Дело в том, что когда существует конкретный формат, а также четкое и внятное определение какого-либо термина, то все манипуляции и подмены его на собственные брифы, прототипы, на ходу придуманные опросники, описания и просто входящие заявки - выглядят, по меньшей мере, непрофессионально. Поэтому с научного определения нашего понятия и начинаем:
Техническое задание - исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования. Техническое задание является юридическим документом - как приложение включается в договор между заказчиком и исполнителем на проведение проектных работ и является его основой: определяет порядок и условия работ, в том числе цель, задачи, принципы, ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет. Все изменения, дополнения и уточнения формулировок ТЗ обязательно согласуются с заказчиком и им утверждаются. Это необходимо и потому, что в случае обнаружения в процессе решения проектной задачи неточностей или ошибочности исходных данных возникает необходимость определения степени вины каждой из сторон-участниц разработки, распределения понесенных в связи с этим убытков. Техническое задание, как термин в области информационных технологий – это юридически значимый документ, содержащий исчерпывающую информацию, необходимую для постановки задач исполнителям на разработку, внедрение или интеграцию программного продукта, информационной системы, сайта, портала либо прочего ИТ сервиса.
Переводим на понятный язык
1) ТехЗадание - оно ставит задачу. А значит оно должно идти перед прототипом, скетчем, тестом, дизайн-проектом, потому что любой майндмеп, диаграмма потоков данных, архитектура - это уже выполнение некой задачи, это ответ на вопрос. А до того, как сам вопрос еще не задан, не сформулирован и не подписан всеми сторонами - любой ответ будет априори неправильным, не так ли? Итак, начало любой работы над любым проектом - это постановка задачи, а не судорожный поиск набросков десятка вариантов ее решения.
2) Собственно из первого пункта логично вытекает и новый - сам текст ТЗ обязан начинаться с главы «Цели и задачи», четко формулирующей, какие бизнес-цели преследует вся эта очередная попытка повысить энтропию в мире. Бесцельное задание, которое не решает никаких проблем, не достигает ничего и делается «от скуки» - официально не считается Техническим Заданием, а с этого момента находится в статусе «обычная бумажка».
3) Как же вам понять, решает ли предложенная дизайн-концепция или интерактивный прототип, а то и готовый к употреблению сайт - вышеизложенную задачу бизнеса? Ничего не поделаешь, придется опять вернуться к определению: «определяет… ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет». То есть ТЗ без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия - быть не может. Бриф может, или прототип, или еще любая абсурдная бумажка, но только не ТехЗадание.
Отсюда делаем вывод, что в настоящем ТЗ обязательно должна быть глава «Порядок приемки и оценки», когда эти самые показатели берутся, замеряются, и стороны либо пожимают друг другу руки, либо отправляют проект на переделку.
4) ТехЗадание должно обязательно согласоваться с общим бизнес-планом заказчика, с его стратегией развития бизнеса и анализом сегмента рынка. Именно все это позволит установить правильные цели, вывести точные метрики, по которым затем адекватно провести приемку готового инфопродукта. Отсутствие у заказчика бизнес-плана автоматически гарантирует непрофессиональное выполнение Технического Задания.
Знает ли студия на аутсорсе бизнес-цели и измеримые показатели бизнеса лучше его владельца? Очевидно, что нет, а значит правильное ТЗ должно писаться представителями Заказчика, а не наемными работниками Исполнителя. Абсурд, когда исполнитель сам себе ставит задачу, затем сам себе придумывает способы ее оценки, и в конце сам же выставляет себе итоговую отметку за сделанную работу. В идеале такой «самодеятельности» быть не должно, хотя на практике повсюду именно так и происходит, в результате чего ТехЗадание и не оказывает нужной помощи проекту, слишком часто являясь по сути фиктивным документом. Не надо так.
5) Каждое внесение правок в готовое ТЗ должно стоить денег. Нельзя бесплатно и бесконечно править «Конституцию вашего проекта» только потому, что одна из сторон передумала, не выспалась, внезапно решила сэкономить и т.д. Цена каждого изменения в ТЗ должна также четко прописываться заранее в соответствующей главе.
Кстати, по идее точно также каждая правка в дизайне или внесение изменений в список страниц или функций должна иметь четкую цену, которая оплачивается заранее, до начала внесения данного изменения. Лично я предлагаю любую редактуру утвержденного ТЗ оценивать в 30% от всего бюджета проекта, но вы можете поступать иначе.
Стоит ли упоминать, что в ТЗ просто необходимо заранее указывать сроки и общий бюджет на разработку, а также список всех существующих ресурсов и ограничений? - Нет, это будет уж слишком очевидно.
Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? - написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.
Контрольные вопросы
А здесь перечислю ответы на самые часто встречающие вопросы от заказчиков:
1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? - Да, даже несколько.
2) А что, в ТехЗадание не входит описание нужных страниц, количества кнопок, используемых библиотек, гайдлайнов и т.д.? - В само ТЗ нет, но в Приложения вы можете все это поместить, разумеется скорректировав все это с вышеописанными целями, ограничениями и способами дальнейшей оценки достигнутого результата. Размещайте хоть весь будущий контент, хоть описание типовых персонажей - но не вместо четкой постановки задачи, а уже после нее.
3) Так может оно мне такое и не нужно? - Возможно, сегодня тысячи сайтов делаются вообще без ТЗ, также, как тысячи людей в мире прекрасно живут, будучи слепыми от рождения. Но если вы хотите видеть - куда вы вообще движетесь, осознанно принимать решения и самостоятельно оценивать полученные результаты - то без ТЗ тут не обойтись.
4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? - Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.
5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? - Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) - то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL - уже нет.
6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? - Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» - установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь - обязательно.
Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс , найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):
ГОСТ 34
ГОСТ 19
IEEE STD 830-1998
ISO/IEC/ IEEE 29148-2011
RUP
SWEBOK, BABOK и пр.
ГОСТ 34
ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.Согласно ГОСТ 34 техническое задание должно включать следующие разделы:
1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки
При разработке ТЗ для государственных проектов Заказчики, как правило, требуют соблюдение именно этого стандарта.
ГОСТ 19
“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” - это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:
1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.
Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.
IEEE STD 830-1998
Достаточно хорошее определение стандарта 830-1998 - IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:Описывается содержание и качественные характеристики правильно составленной спецификации требований к программному обеспечению (SRS) и приводится несколько шаблонов SRS. Данная рекомендуемая методика имеет своей целью установление требований к разрабатываемому программному обеспечению, но также может применяться, чтобы помочь в выборе собственных и коммерческих программных изделий.
Согласно стандарту техническое задание должно включать следующие разделы:
1. Введение
- 1. Назначение
- 2. Область действия
- 3. Определения, акронимы и сокращения
- 4. Ссылки
- 5. Краткий обзор
- 1. Взаимодействие продукта (с другими продуктами и компонентами)
- 2. Функции продукта (краткое описание)
- 3. Характеристики пользователя
- 4. Ограничения
- 5. Допущения и зависимости
- 1. Требования к внешним интерфейсам
- 1. Интерфейсы пользователя
- 2. Интерфейсы аппаратного обеспечения
- 3. Интерфейсы программного обеспечения
- 4. Интерфейсы взаимодействия
- 2. Функциональные требования
- 3. Требования к производительности
- 4. Проектные ограничения (и ссылки на стандарты)
- 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
- 6. Другие требования
5. Алфавитный указатель
На самом деле новичку достаточно трудно понять, что должно содержаться в данных разделах по вышеприведенной структуре (как и в случае с ГОСТом), поэтому нужно читать сам стандарт, который . , правда, на англ. языке.
Ну а кто дочитал до конца - тому бонус: пример ТЗ, который я писал много лет назад (сейчас уже просто аналитиком давно не работаю, да и другие более удачные примеры запрещает открывать на всеобщее обозрение NDA).
- Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях .
- Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований .
- Правила составления Software requirements specification (читать вместе с комментариями)
- Примеры ТЗ и другой документации по разработке АС для МЭР
- ГОСТ-овский стиль управления . Статья Gaperton по правильной работе с ТЗ по ГОСТ
- Шаблоны документов для бизнес-аналитиков из
Что такое техническое задание? Как его делать и для чего оно нужно? Примеры, образцы, советы и рекомендации.
Казалось бы, как здорово, когда тебя понимают с полуслова. Выдал несколько фраз и вот оно, как раз то, что ты себе представлял. К сожалению, это так не работает.
Проблема восприятия информации, вечная. Эффект “сломанного телефона”, частое явление. А что говорить о том, если ты просто не умеешь ставить задачу? Да, такое тоже бывает и с этим нужно как-то работать, но как? Для того чтобы результаты задач, которые вы ставите, соответствовали вашим ожиданиям, пишите техническое задание.
Что такое техническое задание
Техническое задание (или ТЗ) – документ, в котором содержатся требования заказчика к продуктам или услугам, которые предоставляет исполнитель. Простыми словами: хочу так и так, чтобы семь взаимно перпендикулярных линий было, да еще и часть красным цветом, а часть бесцветным нарисуйте (видео про эту тему в конце материала, советую посмотреть).
Конструкторское бюро
Документ этот может занимать, как одну страницу А4, так и целый том, все зависит от задач и пожеланий которые в него входят. К примеру, вы можете написать техническое задание на небольшой landing page (одностраничный сайт) или же на сложное программное обеспечение с машинным обучением и прочими фишками.
Для чего нужно техническое задание
- Чтобы ставить задачу исполнителям.
- Чтобы подробно описать то, что хочется получить в конце.
- Чтобы согласовать порядок работ.
- Чтобы оценить и принять работу после реализации.
- Чтобы…(добавьте свои варианты в комментариях).
На самом деле, назначений и плюсов технического задания гораздо больше, чем в списке выше. Для меня лично, основная задача, которую решает ТЗ, это реализация того, что мне нужно, с минимальными отклонениями от ожиданий (моих ожиданий).
Благодаря ТЗ вы всегда можете спросить про сроки реализации, деньги и соответствие заявленным характеристикам конечного продукта или услуги.
По факту, это серьезный документ, который составляется заказчиком и исполнителем. Вплоть до того, что прописываются неустойки и обязательства сторон. Существует целый ряд ГОСТ-ов, более подробно читайте на Хабре .
Разработка технического задания
Если мы говорим об игре “по-взрослому”, например, техническое задание на разработку мобильного приложения или сайта, то это отдельная работа, за которую платятся немалые деньги. Вы привлекаете человека, как правило, это бывший или действующий технический директор (Chief Technical Officer) и просите его помочь вам.
Наличие бороды необязательно
В зависимости от объемов проекта/задач этот человек собирает все ваши “хотелки”, переводит их в технический язык, может быть готовит эскизы (как должно приблизительно выглядеть) и отдает вам готовый документ. Далее вы этот документ передаете исполнителям (команде внутри вашей компании или на аутсорс), договариваетесь по деньгам, срокам и приступаете к работе.
Совет: технический директор должен быть в вашей команде, в противном случае вы скорее всего не заметите чего-то в процессе реализации. У вас попросту не хватит на все знаний. Кто участвовал в написании ТЗ, тот и проверяет.
Из чего состоит техническое задание
Все будет зависеть от шаблона, который вы выберете (чуть дальше я дам несколько ссылок на шаблоны/примеры), но есть базовые блоки, которые входят в техническое задание:
- Описание проекта/задачи. Кратко пишем, что за проект или задача, которую нужно выполнить.
- Назначение и цели. Какие цели стоят перед проектом.
- Требования. Дизайн, функции, технологии, которые необходимы.
- Описание работ. Что, когда и как будет выполнено.
- Порядок контроля и приемки. Как будут приниматься работы, что можно считать выполненным.
- Приложения. Эскизы, наброски, прототипы.
Стоимость работ обычно выносится в отдельное приложение к договору, но бывает, когда стороны прописывают суммы и в самом техническом задании.
Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал . Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…
Примеры технического задания
Несмотря на то, что разработка технического задания процесс сложный, но весьма интересный. Ваша задача, воссоздать картину конечного результата, а потом описать ее по частям.
Пример одного из моих ТЗ на апдейт приложения Smart TV. Задания на более сложные и комплексные продукты составлялись уже с помощью коллег из тех.департамента. Не стесняйтесь обращаться за помощью к своим соратникам, вовлекайте их в процесс как можно чаще. И не забывайте давать обратную связь! Нет ничего хуже, чем вложить силы и время во что-либо без информации о результатах. Расскажите, как пригодился совет человека в вашей работе, в противном случае, это игра в одни ворота.
ТЗ на разработку интернет магазина
ТЗ на разработку мобильного приложения
ТЗ на сайт
ТЗ на сервисы/обновления
Если нужно больше образцов, просто погуглите.
Главная рекомендация, это делать. Беда в том, что лень-матушка одолевает каждого и сопротивляться ей не просто. Соберите всю волю в кулак и начинайте писать техническое задание, просто пишите и не останавливайтесь. Не переживайте, что не получается “идеально”, открою тайну, такого и не бывает. Просто пишите, с каждым разом будет получаться лучше и лучше.
Вот так надо
Мои первые зачатки по написанию ТЗ начали появляться несколько лет назад. Я работал с дизайнерами и ставил задачу на создание креативов для рекламных кампаний. Бессвязное хочу это и это превращалось в кучу потраченного времени и объяснений. Со временем постановка задач начала превращаться в какие-то смысловые блоки, а потом уже и в подобие технического задания.
Например для задачи “Кнопка лайк на сайте”:
- Описание: необходимо создать кнопку “Лайк” на нашем сайте.
- Назначение и цели: вовлечение пользователей, выдача/рейтинг материалов по кол-ву лайков.
- Требования: дизайн такой (пример: ссылка на что-то похожее), функционал (любой пользователь может оценить картинку и поставить лайк, система сайта учитывает кол-во лайков и меняет выдачу материалов), технологии (доступно на desktop и mobile версиях сайта).
- Описание работ: нарисовать 3 варианта макетов для кнопок (дата готовности: 01.10.17), разработать систему выдачи материалов по лайкам (дата: 14.10.17), тестирование функции (дата: 16.10.17), релиз (дата: 17.10.17)
- Приемка работ: пользователь нажимает на кнопку лайк, система засчитывает нажатие, выдача материалов меняется.
- Приложения: эскизы, наброски, примеры проектов, где работает похожая функция.
Оставляйте для себя те разделы и части структуры, которые нужны под ваши задачи. К примеру, шестой блок “Приложения” можно описать в функциональных требованиях. Основной совет: так или иначе описать задачу по структуре тех.задания. Таким образом, вы не упустите важные моменты и избавите себя от лишних вопросов, а коллегам упростите жизнь.
Ну вот
Мы и разобрали что такое техническое задание и как его делать. Теперь у вас появилась способность четко и понятно ставить задачи, доносить свои мысли до других людей и экономить время на дополнительные объяснения. Надеюсь, теперь вы знаете, что со всем этим делать.
Павел Молянов 
Помните закон Мерфи? Если вас могут понять неправильно, вас обязательно поймут неправильно. Это справедливо не только в общении между людьми, но и в создании сайтов. Клиент хотел второй «Фейсбук», а получил форум юных собаководов. Разработчик не угадал хотелку заказчика - потратил время впустую.
В этом гайде я расскажу, что и зачем нужно писать в техзадании. Заодно покажу, как писать не надо, чтобы создание ТЗ не обернулось потраченным впустую временем.
Статья будет полезна:
- Всем, кто имеет отношение к созданию сайтов: разработчикам, дизайнерам, верстальщикам.
- Менеджерам проектов.
- Руководителям диджитал-студий.
- Предпринимателям, которые планируют заказать разработку сайта.
Чтобы материал получился дельный, я собрал комментарии нескольких разработчиков, дизайнеров, проект-менеджеров и владельцев диджитал-студий. Самые ценные добавил в конец статьи. Поехали разбираться.
Что такое техзадание и зачем оно нужно
Техническое задание - это документ, в котором зафиксированы требования к сайту. Чем четче и подробнее расписаны эти требования, тем лучше все участники процесса понимают, каким он должен быть. А значит, растет шанс того, что все останутся довольны результатом.
Главная цель технического задания: убедиться, что клиент и исполнитель правильно поняли друг друга.
Пользы от технического задания много. Для каждой стороны она своя.
Польза для клиента:
- Понять, за что он платит деньги, и каким будет сайт. Можно сразу увидеть структуру, понять, что и как будет работать. Прикинуть, все ли устраивает. Если нет - без проблем поменять еще до начала разработки.
- Увидеть компетентность исполнителя. Если техзадание понятное и четкое - доверие к разработчику повышается. Если там написана каша - возможно, стоит бежать и не оглядываться.
- Застраховаться от недобросовестности исполнителя. Когда сайт готов, его можно проверить по техническому заданию. Есть несоответствия? Разработчик обязан их исправить. Если вы сотрудничаете официально и заключали договор - можно даже принудить через суд.
- Упростить замену исполнителей. Если клиент и разработчик повздорили и разбежались, создание сайта может сильно затянуться. Когда есть подробное техзадание, его можно передать новой команде - она втянется в работу в разы быстрее.
- Узнать стоимость разработки сложного продукта. Оценить точные сроки и стоимость разработки сложного веб-сервиса сходу нельзя. Сначала нужно понять, как будет работать сервис, и какие в нем будут функции. Для этого и нужно подготовить техзадание.
Польза для исполнителя:
- Понять, что хочет заказчик. Клиенту задают десятки вопросов, показывают примеры, предлагают решения. Затем записывают все в единый документ и согласовывают. Если все окей - ура, вы поняли правильно.
- Застраховаться от внезапных хотелок клиента. Иногда попадаются заказчики, которые хотят поменять задачу на полпути. Если вы согласовали и подписали ТЗ, вам не страшно подобное. В случае чего, даже суд будет на вашей стороне.
- Показать свою компетентность. Классно подготовленное техзадание покажет клиенту экспертность разработчиков. Если компания сомневалась, доверять ли вам разработку сайта, сомнения с большой вероятностью развеются.
- Заработать деньги. Некоторые студии и разработчики предлагают составление ТЗ как отдельную услугу.
- Облегчить и ускорить процесс разработки . В хорошем ТЗ указаны структура сайта, необходимые функции и элементы на каждой странице. Когда все требования уже перед глазами - остается только задизайнить и написать код.
Теперь давайте разберемся, как составить хорошее техзадание, которое выполняет все эти функции.
Техзадание составляет исполнитель
Вообще техзадание может составить кто угодно. «Нужен сайт-визитка для стоматологической клиники» - это уже техзадание. Но будет ли оно выполнять свои функции? Вряд ли.
Хорошее ТЗ всегда составляет исполнитель: проект-менеджер или разработчик. Очевидно, что веб-разработчик понимает в создании сайтов больше, чем владелец кафе или стоматологической клиники. Поэтому описывать проект придется ему.
Это не значит, что клиент исчезает и появляется в самом конце, чтобы написать: «Збс, одобряю». Он тоже должен участвовать в процессе:
Конечно, заказчик может набросать свой вариант ТЗ. Возможно, это ускорит процесс создания конечного техзадания. А возможно, получится мусор, который втихаря выкинут на помойку.
Пишите однозначно и точно
Этот совет вытекает из главной цели техзадания - «Убедиться, что клиент и исполнитель правильно поняли друг друга».
В техническом задании не должно быть качественных прилагательных: красивый, надежный, современный. Их нельзя однозначно понять. У каждого свои понятия красоты и современности.
Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:
То же самое - с невнятными формулировками, которые ничего сами по себе не значат:
- Сайт должен понравиться заказчику. А если у него будет плохое настроение?
- Сайт должен быть удобным. Что это значит? Удобным для чего?
- Сайт должен выдерживать большие нагрузки. 10 тысяч посетителей? Или 10 миллионов?
- Качественный экспертный контент. Ну, вы поняли.
Проверяйте, нет ли в тексте неоднозначностей. Если есть - перепишите. Ваши формулировки должны быть четкими и точными:
- Сайт должен загружаться быстро → Любая страница сайта должна иметь больше 80 баллов в Google PageSpeed Insights.
- Большие нагрузки → 50 тысяч посетителей одновременно.
- На главной странице выводится список статей → На главной странице выводится список последних 6 опубликованных статей.
- Минималистичный удобный интерфейс подписки → Поле «Оставьте e-mail» и кнопка «Подписаться» → *нарисованный эскиз*.
С формулировками разобрались, давайте пробежимся по структуре.
Укажите общую информацию
Все члены команды должны правильно понимать, чем занимается компания и кто ее целевая аудитория. Чтобы никто не запутался, это лучше прописать в самом начале техзадания.
А еще стоит указать цель сайта и описать его функционал в двух словах - чтобы не получить интернет-магазин вместо блога.
Поясните сложные термины
Первое правило техзадания - оно должно быть понятно всем, для кого предназначено. Если вы собираетесь использовать термины, которые может не понять ваша клиентка - владелица магазина детских игрушек - обязательно поясните их. Понятным языком, а не копипастой из «Википедии».
Опишите инструменты и требования к хостингу
Представьте, что вы 2 месяца делали крутой сайт. Каждый этап согласовывали с клиентом - он в восторге. И вот пришло время сдавать работу. Вы показываете админку, а клиент кричит: «Это что такое? Модэкс?! Я думал, вы сделаете на «Вордпрессе»!»
Чтобы таких проблем не было, опишите используемые инструменты, движки и библиотеки. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP - а у клиента сервер на.NET.
Перечислите требования к работе сайта
Сайт должен работать во всех браузерах актуальных версий и на всех типах устройств. Да, это очевидно для любого разработчика и любого заказчика. Но лучше написать, чтобы защитить клиента от недобросовестно выполненной работы.
Сюда же напишите требования к скорости загрузки сайта , устойчивости к нагрузкам, защите от хакерских атак и подобным вещам.
Укажите структуру сайта
До начала отрисовки дизайна и верстки вам нужно согласовать с клиентом структуру сайта.
Пообщайтесь с заказчиком, выясните, что ему надо. Соберите разработчиков, сеошников, маркетологов, главреда - и решите, какие страницы нужны на сайте. Подумайте, как они будут связаны между собой, с какой на какую можно перейти.
Можно показать структуру списком, можно нарисовать блок-схему. Как вам удобнее.
Это один из важнейших этапов работы на сайтом. Структура - это фундамент. Если она неудачная - сайт получится кривой.
Объясните, что будет на каждой странице
Клиент должен понять, зачем нужна каждая страница и какие элементы на ней будут. Есть два способа это показать.
Прототип - более наглядный и однозначный способ. Исполнитель рисует эскизы каждой страницы и прилагает их к техзаданию. Клиент видит, как будет выглядеть интерфейс его будущего сайта и говорит, что ему нравится, а что стоит изменить.
Перечисление элементов - ленивая альтернатива прототипу. Просто напишите, какие блоки должны быть на странице, и что они делают.
Распишите сценарии использования сайта
Если вы делаете какой-то нестандартный интерфейс, просто показать структуру и эскизы страниц недостаточно. Важно, чтобы вся команда исполнителей и клиент поняли, как посетители будут пользоваться сайтом. Для этого отлично подходят сценарии. Схема сценария очень простая:
- Действие пользователя.
- Ответное действие сайта.
- Результат.
Конечно, если вы делаете стандартную визитку или лендинг, писать сценарии не нужно. Но если на сайте будут какие-то интерактивные сервисы - очень желательно.
Подробнее о сценариях использования читайте в «Википедии ».
Определите, кто отвечает за контент
Одни разработчики делают сайт сразу с контентом. Другие ставят рыбу. Третьи могут написать тексты, но за дополнительную плату. Договоритесь об этом на берегу и зафиксируйте в техзадании, какой контент вы должны подготовить.
Придумать объективные критерии оценки качества текстов довольно сложно. Лучше не пишите ничего, чем «Качественный, интересный и продающий контент, полезный для целевой аудитории». Это мусор, он никому не нужен.
Указать, что весь контент должен быть уникальный, - это полезно. Еще одна защита клиента от недобросовестных исполнителей.
Опишите дизайн (если сможете)
Как и в с случае с текстом, объективные критерии оценки дизайна сайта придумать сложно. Если вы с клиентом договорились о цветовой гамме - напишите ее. Если у него есть брендбук, в котором прописаны шрифты, - укажите и их.
Писать про красивый и современный дизайн не надо. Это ничего не значит, не имеет силы и вообще фу.
Вместо вывода: структура техзадания
Для разных задач структура ТЗ будет своя. Глупо делать одинаковые технические задания для новой социальной сети и лендинга по оптовой продаже моркови. Но в целом вам нужны такие разделы:
- Информация о компании и целевой аудитории, цели и задачи сайта.
- Глоссарий терминов, которые могут быть непонятны клиенту.
- Технические требования к верстке и работе сайта.
- Описание используемых технологий и список требований к хостингу.
- Подробная структура сайта.
- Прототипы страниц или описания элементов, которые должны на них быть.
- Сценарии использования нестандартного интерфейса (опционально).
- Список контента, который делает разработчик.
- Требования к дизайну (опционально).
- Правила составления Software Requirements Specification. SRS - следующая ступень эволюции техзадания. Нужна для больших и сложных проектов.
- Стандарты и шаблоны ТЗ на разработку ПО. Описания разных ГОСТов и методологий создания технических заданий.
Это конец той части, которую писал я. Но есть и другая - комментарии специалистов, которые помогали делать гайд. Почитайте, это тоже интересно.
Комментарии разработчиков
Я пообщался с несколькими разработчиками, чтобы узнать, как они составляют техзадания. Передаю микрофон им.
В первую очередь ТЗ нужно клиенту - чтобы он понял, каким будет его сайт, и на что уходят деньги. Если что-то сделано не так - он может сослаться на ТЗ и попросить переделать.
ТЗ составляет менеджер проекта после общения с клиентом и обсуждения задачи с дизайнером.
Крупные заказчики часто просят очень подробные ТЗ, в которых описана каждая кнопка. Небольшие компании наоборот не любят дотошные документы на 100 страниц. Долго читать и легко упустить что-то важное. Чаще мы делаем лаконичные ТЗ на 10–15 страниц.
Мы указываем:
- Информацию о компании и цель сайта.
- Требования к дизайну, цветовую гамму.
- Используемые технологии и CMS.
- Кто занимается контентом - мы или клиент.
- Структуру сайта вплоть до каждой страницы.
- Описания каждой страницы. Мы не делаем прототипы, но указываем, какие элементы должны быть на странице, и как они должны работать.
Последние 2 раздела - самые важные. Именно они обеспечивают понимание, какие будет сайт и как он будет работать.
Очень важный момент - нельзя просто отдать техзадание разработчикам и надеяться, что они все сделают хорошо. ТЗ - это список требований к сайту, оно не может заменить общение. Важно убедиться, что каждый член команды понимает общую цель, а не просто выполняет задачи на потоке. Если что-то непонятно - надо объяснить, обсудить, дать подробные комментарии.
