Техническое задание (ТЗ) на создание АС: ключевые аспекты разработки

Юлий Минькин, директор по развитию проектного офиса

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

Разработка технического задания (ТЗ) — это ключевая стадия любого проекта создания автоматизированной системы (АС). Этот документ настолько важен, что ему посвящен отдельный стандарт ГОСТ 34.602—2020 «Техническое задание на создание автоматизированной системы».

Согласно ГОСТ: «ТЗ на АС является основным документом, определяющим требования и порядок создания автоматизированной системы, в соответствии с которым проводится разработка АС и ее приемка».

Почему не обойтись без разработки ТЗ

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

Почему не стоит экономить на составлении проектной документации.

Путаница в проектной документации: разбираем что такое ТЗ.

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

Рассмотрим эти критерии более подробно и приведем примеры проектов, для которых ТЗ особенно важно.

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

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

Реальный взгляд на Scrum: ограничения в применении.

Подходит ли SCRUM для внедрения комплексных систем, таких как 1С:ERP?

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

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

Место разработки ТЗ в проектной технологии

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

Стадии создания АС.

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

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

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

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

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

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

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

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

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

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

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

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

Цитата из ГОСТ 34.602—2020 "Техническое задание на создание автоматизированной системы".

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

Структура ТЗ по ГОСТ 34.602—2020

ГОСТ 34.602-2020 «Техническое задание на создание автоматизированной системы» — это стандарт, который распространяется на автоматизированные системы (АС), предназначенные для автоматизации различных видов деятельности (управление, проектирование, исследования и т. п.), включая их сочетания.

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

В настоящее время этот стандарт имеет рекомендательный характер и широко используется в IT-сообществе для формализации требований к автоматизированной системе.

Ниже приведу структуру и краткое содержание этого документа:

Структура Технического задания, согласно ГОСТ 34.602—2020.

1. Общие сведения о системе: указывается полное наименование системы, её условное обозначение и шифр, наименование предприятий разработчика и заказчика, перечень документов, регламентирующих создание системы, плановые сроки выполнения работ, источники финансирования и порядок оформления результатов.
2. Цели и назначение создания АС: приводят наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС, и указывают критерии оценки достижения целей создания АС; указывают вид автоматизируемой деятельности применительно к объекту автоматизации в целом.

Характеристика объектов автоматизации: приводятся основные сведения об объекте автоматизации или ссылки на документы, содержащие такие

1. сведения; сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.
2. Требования к АС: приводятся требования к структуре АС, требования к функциям (задачам), выполняемым АС, а также требования к видам обеспечения АС» (математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и др.).
3. Состав и содержание работ по АС: перечисляются очереди, стадии, этапы и виды работ, необходимые для создания системы, с указанием сроков их выполнения.
4. Порядок разработки автоматизированной системы: приводят порядок организации разработки АС; перечень документов и исходных данных для разработки АС; перечень документов, предъявляемых по окончании соответствующих этапов работ; порядок проведения экспертизы технической документации; перечень макетов (при необходимости), порядок их разработки, изготовления, испытаний, необходимость разработки на них документации, программы и методик испытаний; порядок разработки, согласования и утверждения плана совместных работ по разработке АС; порядок разработки, согласования и утверждения программы работ по стандартизации; требования к гарантийным обязательствам разработчика; порядок проведения технико-экономической оценки разработки АС.
5. Порядок контроля и приёмки системы: указывают виды, состав и методы испытаний АС и ее составных частей, общие требования к приемки работ, статус приемочной комиссии.
6. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие: перечисляются мероприятия, необходимые для подготовки объекта к внедрению системы, и требования к их выполнению.
7. Требования к документированию: определяются требования к составу, содержанию, оформлению и управлению документацией по проекту.
8. Источники разработки: указываются документы и стандарты, на основе которых разрабатывается техническое задание.

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

Причины по которым не составляют ТЗ

Некоторые IT-специалисты и заказчики могут испытывать опасения или нежелание составлять ТЗ по нескольким причинам:

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

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

Преимущества разработки ТЗ

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

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

1. ТЗ предоставляет четкую и однозначную формулировку целей и требований каждой очереди и проекта в целом. Это обеспечивает общее понимание задач среди всех участников проекта – от разработчиков до заказчиков. Конкретизация требований и ожиданий в начале проекта помогает избежать недопонимания и ошибок в будущем, что, в свою очередь, сокращает время и затраты на исправление и доработку проекта.
2. Определение точных границ проекта. ТЗ помогает определить, какие функции и характеристики должна иметь система, а также устанавливает рамки, в которых должно происходить развитие проекта. Это позволяет избежать "разрастания" проекта, когда дополнительные задачи непредвиденно добавляются в ходе его реализации, увеличивая сроки и бюджет.
3. Улучшение коммуникации и координации внутри команды. ТЗ служит общим референсом для всех участников проекта, обеспечивая, что каждый член команды понимает свои задачи и ответственность. Это способствует эффективной командной работе и сокращает время, затрачиваемое на устранение недопониманий и конфликтов.
4. ТЗ служит основой для оценки прогресса и качества выполнения проекта. С четко определенными целями и требованиями, заказчики и управляющие проектом могут более эффективно отслеживать ход работ и принимать своевременные меры при отклонении от плана. Также ТЗ помогает в оценке конечного продукта, обеспечивая, что результат соответствует первоначально заложенным требованиям и ожиданиям.
5. Составление ТЗ может снизить риски проекта. Определение потенциальных проблем и сложностей на раннем этапе дает возможность разработать стратегии их минимизации или полного устранения. Это снижает вероятность неожиданных задержек и дополнительных затрат в ходе проекта.

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

Заключение

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

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

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

Свои вопросы и комментарии по теме пишите под статьей или отправляйте нам напрямую. Контакты для связи с нами:

Telegram

Проектный офис erp.lab@1cbit.ru