Как писать ТЗ: инструкция по составлению грамотного техзадания

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

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

Как составляется ТЗ на тендер

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

• государственные стандарты;
• рекламу и каталоги;
• публичные оферты;
• исполненные контракты;
• официальные информационные источники уполномоченных органов и др.

Ситуация: вправе ли заказчик ограничить место оказания услуг определенной территорией или расстоянием

Да, вправе, если это необходимо, чтобы эффективно удовлетворить потребности.Заказчики закупают товары, работы, услуги при наименьших затратах бюджетных средств. В то же время нельзя ограничивать конкуренцию – необоснованно снижать число участников закупок. Вывод основан на принципах обеспечения конкуренции и эффективности закупок, которые закреплены в статьях 8 и 12 Закона № 44-ФЗ. Если необходимо получить результаты закупки на определенной территории, требование к месту оказания услуг обоснованно, ведь заказчик минимизирует, например, транспортные расходы. Позицию подтверждают специалисты антимонопольных служб (решения Краснодарского УФАС от 09.01.2017 № 407-Т/2016, Хакасского УФАС от 11.05.2018 № 40/КС).

Если ограничиваете территорию или расстояние, дайте участникам точные ориентиры. К примеру, заказчик в техническом задании написал: «Удаленность загородного лагеря от города – не менее трех километров». Из формулировки непонятно, какой город имеет в виду заказчик. ФАС решила, что заказчик описал объект закупки с нарушением (решение, предписание Брянского УФАС от 18.05.2018 № 78).

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

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

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

Как распознать качественное ТЗ

• С первых страниц понятно, какую функцию выполняет приложение

Попросите постороннего человека прочитать ТЗ и описать приложение в общих чертах. У него это должно легко получиться.

• Перечислены поддерживаемые устройства и операционные системы

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

• Детально описаны все экраны и кнопки

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

• К каждому экрану нарисована схема

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

• Не используются отсылки к сторонним продуктам при описании функций

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

• Прописано поведение приложения для нестандартных ситуаций

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

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

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

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

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

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

• Материалы с описанием аналогов (прототипов) разрабатываемой системы.
• Материалы, описывающие общую идею системы. Нередко данные документы составляют на предпроектных стадиях и именно на них обычно содержатся ссылки в разделе «Характеристики объекта автоматизации».
• Материалы по разработке проекта: перечень используемых ГОСТов серии 34, используемые стандарты по проектному управлению.
• Материалы, связанные с осуществлением основного процесса: перечень законов, стандартов, внутренних регламентов и приказов, устанавливающие правила осуществления автоматизируемых процессов.
• Материалы и стандарты, содержащие требования к общей и информационной безопасности.

Почему разработка технического задания так важна

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

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

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

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

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

А нужно ли вообще техническое задание? А Технический проект?

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

А что же с Техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, т.е. по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ. Должен ли с ним знакомиться Заказчик? Если хочет, почему нет, но настаивать и утверждать данный документ нет никакой необходимости, он будет только сдерживать и мешать работать. Спроектировать систему до мелочей практически невозможно. В этом случае придется непрерывно вносить изменения в Технический проект, что занимает немало времени. А если организация сильно забюрократизирована, то вообще все нервы там оставите. Как раз о сокращении такого рода проектирования и идет речь в современных методологиях быстрой разработки, о которых я упоминал выше. Кстати, все они базируются на классическом XP (экстремальном программировании)- подходе, которому уже порядка 20 лет. Так что сделайте качественное Техническое задание, понятно Заказчику, а Технический проект используйте как внутренний документ, для взаимоотношений между архитектором системы и программистами.

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

Процесс создания техзадания

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

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

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

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

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

Надеюсь, с помощью этой статьи написать Техническое задание вам будет немножко легче!

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

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

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

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

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

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

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

Сроки: до 15.09.2018.

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

1. определить верхнюю планку финансовых возможностей;
2. назначить ответственного за сбор сведений и подготовку документации (обычно эти вопросы решает начальник технического отдела или главный инженер организации);
3. определить достаточность первичных документов (планов помещений, проектов, чертежей, эскизов и т.д.), на основании которых будет составляться техническое задание. В качестве первичных документов могут выступать предписания контролирующих органов, в частности санитарно-эпидемиологических служб, противопожарных инспекций, служб по охране труда, экологическому надзору, административно-технических инспекций. Также первичными документами для составления технических заданий могут быть постановления суда;
4. определить ориентировочные сроки проведения ремонтных работ, поскольку в разные сезоны перечень материалов, применяемых при строительстве, может изменяться;
5. создать реестр соответствующих инструкций по возможности применения тех или иных строительных материалов с учетом требований различных проверяющих инстанций. Так, противопожарные инспекции запрещают или ограничивают (допуская использование только в определенных помещениях) применение определенных видов строительных материалов, например легковоспламеняемых или сильно токсичных при горении. У санитарно-эпидемиологических служб другие «запретные приоритеты», представители Ростехнадзора «забракуют» строительные материалы, не обеспечивающие надежность конструкций, и т.д.;
6. определить организацию или сотрудника (идеально, если в штате бюджетного учреждения есть квалифицированный сметчик), которые будут «трансформировать» технические задания в проектно-сметную документацию, выполненную в ТЕР . Именно в таком виде смета впоследствии будет проверяться в соответствующих инстанциях, а затем в зависимости от суммы выставляться на открытый электронный аукцион или котировку.

Как упростить процесс составления техзадания

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

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

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

Бритва Оккама в данном случае говорит о том что наиболее простое решение — наиболее верное. Если нет веских причин для усложнения.

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

Иногда она может расширяться некоторыми полезными артефактами (разделами):

• Цели — описать не только то что надо сделать, но и для чего мы это делаем? Чтобы что? Это бывает полезно для повышения качества результатов.
• Снимки, фото, звуки, примеры — бывает полезно добавить в задание снимок ошибки (например когда мы делаем сайт) или пример/фото того как это сделано у кого-то еще.

Разработчики часто жалуются на то что Заказчики не могут написать хорошее ТЗ. А без внятного ТЗ как известно результат ХЗ.

Как мне кажется причина не в том что Заказчик не может написать хорошее ТЗ, а в том что никто не понимает что это такое. В том числе сам Разработчик.

И даже если Разработчик поймет что такое ТЗ, то для написания ТР снова нужны усилия и ответственность. А если лень то получаем рост Риска получить в результате не то что ожидали + Конфликт.

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

Основные тезисы:

• Заказчик пишет ТЗ, оно может быть коротким, на салфетке из кафе, и содержать 3-4 пункты ключевых требований
• ТР — пишет Разработчик, оно может быть длинным, его цель сформулировать, согласовать и зафиксировать задание и предлагаемое решение.
• Только пара из ТЗ и ТР позволяет получить взаимопонимание между Заказчиком и Разработчиком.
• Иногда можно отказаться от ТР, но надо хорошо понимать когда это можно делать и последствия

Похожие записи:

• Единое пособие с 1 января 2023 года в Крыму
• Как покупать билеты на электричку по социальной карте
• Субсидия на погашение ипотечного кредита в 2023 году