http://shop-site-to-buy-fullz.ru Стадия разработки и утверждения технического задания. Порядок разработки технического задания. Версии и названия файлов

Стадия разработки и утверждения технического задания. Порядок разработки технического задания. Версии и названия файлов

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

Участники согласования рассматривают направленные на согласование документы и принимают решение о результате согласования в течение срока, установленного Порядком:

Не позднее 15 рабочих дней с момента получения ТЗ/ТУ на первоначальное рассмотрение;

Не позднее 10 рабочих дней с момента получения ТЗ/ТУ на повторное рассмотрение (после устранения выданных замечаний).

Общий/предельный срок согласования и утверждения ТЗ/ТУ не должен превышать 103 рабочих дня.

Согласование ТЗ/ТУ оформляется визой согласования или указанием реквизитов письма о согласовании ТЗ/ТУ участником согласования на титульном листе. Направление письма о согласовании ТЗ/ТУ участником согласования в адрес ответственного за организацию согласования обязательно, за исключением случаев согласования с НА КРЭА технических заданий, требующих дальнейшего утверждение в ЦА КРЭА.

Согласование с условиями (например, "согласовано с замечаниями", "согласовано при учете замечаний") не допускается.

Замечания к ТЗ/ТУ с сопроводительным письмом направляются ответственному за организацию согласования с указанием ФИО, контактного телефона и электронного адреса автора замечаний (рекомендуемая форма реестра замечаний приведена в приложении N 1 к настоящему Порядку).

Реестр замечаний направляется в не редактируемом формате PDF с приложением версии в редактируемом формате.

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

Согласование ТЗ/ТУ, доработанных по измененным требованиям, осуществляется всеми участниками согласования.

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

Что и как

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

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

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

1. Предварительное изучение брифа/задачи

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

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

2. Проведение встречи

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

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

Ответы фиксируйте рядом с вопросами, перечитывайте их.

Если ответ так и не получен (бывает, что заказчик абстрактно отвечает на вопрос, и в итоге ответа нет), задайте вопрос снова, изменив формулировку. Например, «я представляю себе этот функционал так… Верно я вас понимаю? Это совпадает с вашим видением?»

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

3. Разработка концепции

Концепция обычно содержит краткие тезисы будущего ТЗ, а именно:

  • Цели и задачи;
  • Назначение;
  • Роли;
  • Структура;
  • Содержание;
  • Список возможностей (в виде сервисов - кратко).
  • Порой концепция содержит подробное описание бизнес-идеи, для понимания, чем выигрышен проект.
Всегда разрабатывайте концепцию - набросок будущего проекта. Зачастую это позволяет сократить риски, а также расставить все точки над i и для вас, и для заказчика.

4. Уточнение требований

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

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

Даже если все кажется понятным и очевидным, нужно задать вопрос, верно ли вы понимаете. Это сократит кучу времени и нервов. Даже говоря о простых новостях, не стоит забывать, что есть понятия «частота публикации», кто обновляет, какие материалы могут быть в новостях, etc. От ответов на подобные вопросы может кардинально меняться структура страницы и приоритетность информации.

5. Утверждение ТЗ

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

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

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

Трудности и как избежать

1. Срыв сроков

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

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

2. Цена-сроки-объем работ

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

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

4. Старайтесь фиксировать все, о чем договариваетесь

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

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

5. Презентуйте результат

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

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

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

Ментальные карты

Техника Mind Maps. Разрабатывайте ТЗ при помощи ментальных карт. Суть процесса состоит в том, что вы изначально рисуете будущий проект в виде схемы. Вы делите продукт на сущности, понятия; при этом в каждом пункте дерева не должно быть больше 3-4 слов. Подобная схема быстро считывается всеми участниками проекта, легко изменять и дополнять дерево. Существует множество программ для разработки таких карт.

Версии и названия файлов

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

По опыту удобно делать названия и версии следующего вида:

NameProject.0.1.doc ,

Где NameProject - название проекта,

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

1 - версия, которую вы создаете внутри компании (отдела).

Например, вы отправили клиенту версию 0.1, при этом работаете над ТЗ дальше. Вы создаете версию 0.2, потому что это изменение, но уже ваши внутренние или внутри компании. Вы получаете комментарии от клиента и создаете еще более новую версию - 1.3.

Если документов несколько (например, концепция, ТЗ), добавьте тип документа в название документа - NameProject.Concept.0.1.

Структура

Имейте четкую структуру ТЗ. При сборе информации, а также разработке документа, следуйте ей. В зависимости от ожиданий заказчика существует 4 альтернативы для выбора шаблона технического задания. Это может быть ГОСТ, IEEE, Корпоративный шаблон, ваш собственный шаблон (или шаблон компании, в которой вы работаете).

Форматирование

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

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

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

Согласно на стадии «Техническое задание», включающее только один этап 3.1 «Разработка и утверждение технического задания на создание АС» проводят разработку, оформление, согласование и утверждение технического задания на АСОИУ и, при необходимости, технических заданий на части АСОИУ. Разработка технического задания осуществляется в соответствии с ГОСТ 34.602 .

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

Дополнительно могут быть разработаны ТЗ на части АСОИУ: на подсистемы АСОИУ, комплексы задач АСОИУ и т. п. в соответствии с требованиями ; на комплектующие средства технического обеспечения и программно-технические комплексы в соответствии со стандартами ЕСКД и СРПП; на программные средства в соответствии со стандартами ЕСПД; на информационные изделия в соответствии с ГОСТ 19.201 и НТД, действующей в ведомстве заказчика АСОИУ.

ТЗ на АСОИУ содержит следующие разделы, которые могут быть разделены на подразделы:

1) общие сведения;

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

3) характеристика объектов автоматизации;

4) требования к системе;

5) состав и содержание работ по созданию системы;

6) порядок контроля и приемки системы;

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

8) требования к документированию;

9) источники разработки.

Порядок разработки, согласования и утверждения ТЗ на создание АСОИУ.

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

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

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

В разделе «Характеристики объекта автоматизации» целесообразно ссылаться на приведенные в приложениях к техническому заданию результатов обследования объекта автоматизации. Это могут быть карты бизнес- процессов, IDEF 0 , DFD диаграммы. Чтобы не усложнять процесс чтения документа, громоздкие схемы лучше выносить в приложения.

В подразделе «Требования к системе в целом» указывают требования к структуре и функционированию системы. Как правило, АСОИУ включает образующие ее подсистемы и их виды обеспечения.

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

1) элементы функциональной структуры АСОИУ (подсистемы АС); автоматизированные функции и (или) задачи (комплексы задач); совокупности действий (операций), выполняемых при реализации автоматизированных функций только техническими средствами (автоматически) или только человеком;

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

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

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

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

В разделе «Порядок контроля и приемки системы» указывают виды, состав, объем и методы испытаний системы согласно ГОСТ 34.603-92 .

В разделе «Состав и содержание работ по созданию (развитию) системы» должен содержать перечень стадий и этапов работ по созданию системы в соответствии с ГОСТ 24.601 . Отметим, что указание сроков зависит от модели жизненного цикла АСИОУ и возможно параллельное выполнение.

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

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

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

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

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

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

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

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

Заказчику:

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

Подрядчику:

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

Всем сторонам:

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