Здравствуйте, в этой статье мы постараемся ответить на вопрос: «Как писать ТЗ: инструкция по составлению грамотного техзадания». Если у Вас нет времени на чтение или статья не полностью решает Вашу проблему, можете получить онлайн консультацию квалифицированного юриста в форме ниже.
За формирование ТЗ отвечает контрактная служба (контрактный управляющий). При этом к составлению техзадания рекомендуется привлечь юристов и экспертов, имеющих необходимый опыт в конкретной области закупок. Документ с ТЗ утверждается руководителем заказчика или другим уполномоченным лицом.
Ситуация: зависят ли требования к техническому заданию от способа закупки
Нет, требования к техническому заданию не зависят от способа закупки. Заказчик обязан включить в документацию электронного конкурса, электронного аукциона, электронного запроса предложений описание объекта закупки согласно положениям статьи 33 Закона № 44-ФЗ. При этом никаких дополнительных требований к описанию объекта закупки в зависимости от конкурентной процедуры в Законе № 44-ФЗ нет. Вывод следует из пункта 1 части 1 статьи 54.3, пункта 1 части 1 статьи 64, пункта 2 части 2 статьи 82.2, пункта 2 части 6 статьи 83.1 Закона № 44-ФЗ.
При закупке у единственного поставщика формировать описание объекта закупки не нужно, так как нет обязанности составлять извещение и документацию (ст. 33, ч. 3 ст. 93 Закона № 44-ФЗ).
Комментарии разработчиков
Техзадание есть всегда, без него не бывает работы. «Мне нужен интернет-магазин» — это уже техзадание. Проблема в том, что это очень расплывчатое ТЗ, оно не дает никакого понимания. Задача проект-менеджера — собрать необходимую информацию, продумать решение, создать сайт у себя в голове. А потом описать его в документе.
В каждом ТЗ обязательно должны быть указаны:
- цель сайта;
- требования к серверу;
- описание работы сайта и отдельных его элементов;
- используемые технологии и библиотеки;
- макет дизайна интерфейса;
- структуру и логику внутренних переходов;
- роли и сценарии работы с сайтом для каждой из них;
- архитектуру базы данных (опционально).
Клиент должен четко представлять свой сайт в законченном варианте, его внешний вид и дальнейшую стратегию развития. Техническое задание не должно указывать разработчикам «как им делать, что делать и какой код вставить» — это в корне неправильно. В общих чертах нужно описывать, какой сайт должен быть, а не как его делать. Как минимум потому что заказчик чаще всего не обладает должной экспертизой.
Что касается подхода, мы всегда прислушиваемся к мнению клиента, но бывают моменты, когда понимаем, что так делать не стоит. В этом случае стараемся переубедить заказчика, опираясь на экспертные данные. В целом, мы приветствуем любое видение клиентов.
Как мы готовим техзадание:
- анализируем ТЗ, присланное клиентом;
- изучаем прототип и дизайн-макет сайта;
- на основе полученных данных начинаем подбирать функциональные модули для сайта, которые будут использоваться 100 % и которые, возможно, потребуется использовать;
- прописываем элементы, которые будут нужны при работе с интерфейсом;
- исходя из этих данных и оценки «веса» сайта, вычисляем подходящие системные требования к хостингу сайта;
А нужно ли вообще техническое задание? А Технический проект?
Не перегрелся ли я? Разве такое возможно, вообще без Технического задания? Представьте себе возможно (точнее, встречается), и у такого подхода есть много последователей, и их число увеличивается. Как правило, после того, как молодые специалисты начитаются книг про Scrum, Agile и прочие технологии быстрой разработки. На самом деле это замечательные технологии, и они работают, только в них не говорится дословно «не надо делать технических заданий». В них говорится «минимум бумаг», особенно ненужных, ближе к Заказчику, больше конкретики и быстрее к результату. Но фиксирование требований никто не отменял, и там это явно сказано. Как раз там требования и фиксируются исходя из трех замечательных свойств, о которых я говорил выше. Просто у некоторых людей так устроено сознание, что если можно что-то упростить, так давайте это упростим до полного отсутствия. Как сказал Эйнштейн «Сделай так просто, как возможно, но не проще этого». Золотые ведь слова, ко всему подходят. Так что Техническое задание нужно, иначе успешного проекта Вам не видать. Другой вопрос, как составлять и что туда включать. В свете методологий быстрой разработки надо сосредоточиться только на требованиях, а весь «камуфляж» можно отбросить. В принципе, я с этим согласен.
А что же с Техническим проектом? Данный документ весьма полезный и не утратил свою актуальность. Более того, часто без него просто не обойтись. Особенно, если речь идет о передаче работ по разработке на сторону, т.е. по принципу аутсорсинга. Если этого не сделать, есть риск узнать много нового о том, как должна выглядеть система, которую Вы задумалиJ. Должен ли с ним знакомиться Заказчик? Если хочет, почему нет, но настаивать и утверждать данный документ нет никакой необходимости, он будет только сдерживать и мешать работать. Спроектировать систему до мелочей практически невозможно. В этом случае придется непрерывно вносить изменения в Технический проект, что занимает немало времени. А если организация сильно забюрократизирована, то вообще все нервы там оставите. Как раз о сокращении такого рода проектирования и идет речь в современных методологиях быстрой разработки, о которых я упоминал выше. Кстати, все они базируются на классическом XP (экстремальном программировании)- подходе, которому уже порядка 20 лет. Так что сделайте качественное Техническое задание, понятно Заказчику, а Технический проект используйте как внутренний документ, для взаимоотношений между архитектором системы и программистами.
Интересная деталь по поводу технического проектирования: некоторые средства разработки, устроенные по принципу предметной ориентированности (типа 1С и аналогичных) предполагают, что проектирование (имеется ввиду процесс документирования) требуется только на действительно сложных участках, где требуется взаимодействие между собой целых подсистем. В простейшем случае, например создать справочник, документ, достаточно лишь правильно сформулированных бизнес-требований. Об этом говорит и стратегия бизнеса этой платформы в части подготовки специалистов. Если посмотреть на экзаменационный билет специалиста (именно так он называется, а не «программиста»), то Вы увидите, что там присутствуют лишь бизнес-требования, а как их реализовать на программном языке это и есть задача специалиста. Т.е. ту часть задачи, которую призван решать Технический проект, специалист должен решить «в голове» (речь идет о задачах средней сложности), причем здесь и сейчас, следуя определенным стандартам разработки и проектирования, которые формирует опять же компания 1С для своей платформы. Таким образом, из двух специалистов, результат работы которых внешне выглядит одинаково, один может экзамен сдать, а второй нет, т.к. грубо нарушил стандарты разработки. Т.е заведомо предполагается, что специалисты должны обладать такой квалификацией, чтобы типичные задачи проектировать самостоятельно, без привлечения архитекторов системы. И такой подход работает.
На самом деле, соблюдение четких правил при составлении ТЗ не требуется. Разные компании и предприниматели оформляют задания по-разному. Вопрос в преследуемых целях.
Кто-то за пару предложений излагает ключевую мысль и надеется, что работник сам додумает остальное:
Нужно написать небольшой текст на тему «Душевые кабины». Текст должен быть для людей. Без переспама.
А кто-то описывает все в деталях и структурирует каждый аспект:
Нужно написать текст на тему «Душевые кабины» объемом 3500 знаков. Уровень спама – до 55%, уровень воды не более 18%, уникальность – от 90%. Слово «душевые» использовать не более 15 раз. Избегать стоп-слов (и, или, но, а).
Далее мы рассмотрим пункты, которые входят в базовый шаблон ТЗ.
В чём польза ТЗ для заказчика
Техзадание — это инструмент, и как любой инструмент, оно должно помогать разработке цифрового решения.
Понимание бюджета. При оценке нешаблонных цифровых решений не получится сразу сказать, сколько оно будет стоить. Сначала нужно определиться, что нужно разработать — сайт, приложение, сервис или портал. Потом понять, как решение будет работать и какие функции выполнять. И только на основе полученной информации определить сроки и бюджет. Техзадание как раз решает эту задачу.
Структурирование информации. Компания приходит за разработкой с конкретными требованиями к цифровому продукту. Причём требования могут составлять разные подразделения — команда маркетинга, аналитики, коммерции и технических специалистов. И у каждого подразделения будут свои задачи. Все эти требования цифровое решение должно объединять и выполнять. Благодаря ТЗ вся полученная информация выстраивается в чёткие требования и фиксируется в документе.
Определение компетентности подрядчиков. Если клиент видит понятное и структурированное техзадание, то с подрядчиком можно продолжить сотрудничество. Если видит неразбериху и не понимает, что в документе описано, то это заставляет задуматься о надёжности компании-разработчика. Через техзадание можно «прощупать» подрядчика и оценить его компетентность.
Пример составления ТЗ на программное обеспечение
Нужно создать ПО. Технические требования — ниже.
Описание: программа для поиска статей по ключевому слову на всех авторитетных сайтах, адреса авторитетных сайтов прописывать нужно вручную.
Что должно делать ПО: после ввода ключевого слова находит статьи на сайтах, которые внесены заранее в качестве авторитетных источников, выводит список совпадений в таком формате:
- Линк
- Название статьи
- Лид-абзац
Если больше 10 совпадений, нужно разделить на страницы — по 10 на каждой.
Технические требования: язык программирования — любой, не принципиально. Главное, чтобы программу потом можно было доработать и вывести в качестве онлайн-сервиса. В идеале сервис должен искать за 10 секунд.
Сроки: до 15.09.2018.
Техническое задание содержит описание ролей и основных пользовательских сценариев в разрабатываемой системе.
В случае с системой баннерной рекламы, мы выделим такой сценарий как создание рекламного места пользователем в роли Администратор.
Название сценария: Создание рекламного места
Роль: Администратор
Пример функционального требования:
«После добавления новой площадки в системе, администратор должен создать связанные с ней рекламные места. При создании рекламного места должны указываться площадка, тип места, поддерживаемый формат баннеров, размер, частота показов (для статических мест). После создания рекламного места оно становится доступным для менеджеров, размещающих рекламу.
Каждое созданное рекламное место получает универсальный идентификатор, который используется системой управления сайтом в запросе на показ баннеров. Для этого требуется внести соответствующие изменения в код страницы сайта».
Техническое задание содержит требования к интеграции разрабатываемой системы с другими внешними и внутренними системами, используемыми заказчиком.
В контексте технического задания на баннерную систему, это – интеграция с системами управления сайтом компании, биллинга, аутентификации и хранения данных пользователей.
«Система баннерной рекламы связана с тремя внешними модулями, функционирующими в окружении компании: системой управления сайтом компании, системой биллинга и системой аутентификации и хранения данных пользователей». Каждый показ баннера сопровождается запросом от системы управления сайтом к баннерной системе. Эти системы, кроме того, используют общие идентификаторы площадок и рекламных мест, а также согласованные имена параметров таргетирования».
В техническое задание мы обычно включаем глоссарий, разъясняющий значения специальных терминов, используемых в документе. Очень важно точно определить значение терминов, которые в дальнейшем используются в документе.
«Размещение (единица размещения, строка медиаплана) – это сущность, объединяющая баннер, который необходимо показывать, рекламное место, на котором будет показан баннер, а также правила показа. Правила показа определяют период размещения, параметры таргетирования, лимиты размещения, веса и т.п. Фактически, все рекламные кампании состоят из размещений».
Частота контакта – количество уникальных пользователей, посмотревших рекламный баннер определенное число раз. Например, частота контакта 5 – количество уникальных пользователей, каждый из которых посмотрел данный рекламный баннер не менее 5 раз. Частота контакта 1 = Охват.
Техническое задание — исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования.
Техническое задание также используется при создании творческого объекта ( видео ролик, статья, графическое изображение).
Можно сказать, что ТЗ — документ, в котором описывается, ЧТО нужно заказчику, в отличие от последующей проектной документации, в которой акцент переносится на ответ на вопрос, КАК этого достичь.
Техническое задание является юридическим документом — как приложение включается в договор между заказчиком и исполнителем на проведение проектных работ и является его основой: определяет порядок и условия работ, в том числе цель, задачи, принципы, ожидаемые результаты и сроки выполнения.
Все изменения, дополнения и уточнения формулировок ТЗ обязательно согласуются с заказчиком и им утверждаются. Это необходимо и потому, что в случае обнаружения в процессе решения проектной задачи неточностей или ошибочности исходных данных возникает необходимость определения степени вины каждой из сторон-участниц разработки, распределения понесенных в связи с этим убытков.
Очень важный, и при этом часто описываемый часто формально раздел. Хотя, на мой взгляд, это самый важный раздел ТЗ, без него мы просто не понимаем, о чем вообще создаваемая система.
Давайте сначала определим, что такое «объект автоматизации». Если мы автоматизируем склад или завод, отдел бухгалтерии, то все понятно. А если, например, создаем новую социальную сеть, то объекта как бы и нет. Но на самом деле, под объектом скорее имеются в виду автоматизируемые процессы. И даже в случае со складом мы же автоматизируем не сам склад (как можно автоматизировать хранение коробок?), а складские процессы.
Если выполнять данный раздел формально, то он будет очень похож на описание назначения системы, и в ТЗ появится еще одно озеро воды, но так и не будет понятно, а что должна делать система.
В данном разделе следует приводить:
- Описание заказчика: виды деятельности заказчика, количество филиалов, сотрудников. Конечно, характеризовать заказчика нужно в той части, которая непосредственно касается создаваемой системы.
- Сведения о пользователях системы: виды пользователей, какую роль играет система для разных пользователей.
- Описание автоматизируемых объектов. Например, если мы автоматизируем склад, до должны описать, какой он площади, сколько проходов, какая ширина проходов, какие стеллажи, имеется ли отдельная зона сборки, сколько работает человек и какие у них обязанности. Тогда мы поймем, что конкретно автоматизируем, как должен выглядеть складской процесс, и какое оборудование используется.
- Описание автоматизируемых процессов. Конечно, не стоит в ТЗ расписывать процессы подробно. Но привести общие сценарии — обязательно. Только тогда нам становится ясно, какие должны иметься функции.
- Перечень документов, в которых приводится подробное описание объекта автоматизации.
Вроде бы формальный раздел, но очень полезный. Представьте себе ситуацию, когда вы помните, что при разработке ТЗ читали какую-то статью, и вам по каким-либо причинам надо ее найти, например, что-то уточнить или обосновать свои решения. Но вы совершенно не помните ни ее названия, ни где она содержалась. Поэтому, когда я использую какие-нибудь полезные материалы, обязательно заношу их в список. И в тексте ставлю сноску с указанием источника.
Если источников много, то следует разбивать их на подразделы, например:
- Материалы с описанием аналогов (прототипов) разрабатываемой системы.
- Материалы, описывающие общую идею системы. Нередко данные документы составляют на предпроектных стадиях и именно на них обычно содержатся ссылки в разделе «Характеристики объекта автоматизации».
- Материалы по разработке проекта: перечень используемых ГОСТов серии 34, используемые стандарты по проектному управлению.
- Материалы, связанные с осуществлением основного процесса: перечень законов, стандартов, внутренних регламентов и приказов, устанавливающие правила осуществления автоматизируемых процессов.
- Материалы и стандарты, содержащие требования к общей и информационной безопасности.
5.1 ТЗ является неотъемлемой частью контракта (договора), заключаемого между заказчиком работы (далее — заказчик), головным исполнителем, исполнителями СЧ работы, исполнителями работ по разработке КИМП.
При разработке ТЗ учитывается информация об аналогичной продукции, содержащейся в различных базах данных.
5.2 Утверждает ТЗ заказчик. Разработку и согласование ТЗ осуществляет заказчик или разработчик, исходя из статуса заказчика, источника финансирования и условий рынка сбыта.
Разработку, согласование и утверждение ТЗ в случае инициативной разработки осуществляет разработчик в установленном у него порядке.
При инициативной разработке, по усмотрению разработчика, отдельные требования и порядок изложения ТЗ могут быть исключены или объединены.
5.3 Согласованное и утвержденное ТЗ является обязательным документом для организаций заказчика, головного исполнителя (исполнителя) работы (СЧ работы, работ по разработке КИМП).
Для подтверждения отдельных требований к продукции, в том числе требований безопасности, охраны здоровья и окружающей среды, а также оценки технического уровня продукции, ТЗ может быть направлено разработчиком или заказчиком на экспертизу (заключение) в сторонние организации. Решения по полученным заключениям принимают разработчик и заказчик до утверждения ТЗ.
5.4 При выполнении работ по созданию изделий, в которых предусматривают использование средств вычислительной техники, разработка математического, информационно-лингвистического и программного обеспечения может быть выделена в отдельную (самостоятельную) часть работы. В этом случае разработку и оформление ТЗ на СЧ работы осуществляют с учетом требований ГОСТ 19.201 и ГОСТ 34.602.
5.5 При необходимости может проводиться метрологическая экспертиза ТЗ.
5.6 ТЗ обозначается как приложение к контракту (договору). Его учет (регистрация), хранение, изменение и передача осуществляются в качестве составной части контракта.
ТЗ поможет организовать работу с несколькими подрядчиками или безболезненно сменить исполнителя
Вполне нормальная ситуация, когда над компонентами сайта или программы работают разные подрядчики. Грамотно составленное техническое задание — гарантия того, что части, реализованные разными исполнителями, стыкуются без проблем.
Пример — верстка сайта одним исполнителем, а его натяжка на CMS —другим. Опытный верстальщик посмотрит в ТЗ, увидит, что web-ресурс будет работать на «Битриксе» и сверстает макет с учетом особенностей этой системы управления контентом. Бекэндеру останется натянуть на движок готовую верстку. В противном случае есть вероятность того, что интеграция на CMS затянется: придется обращаться к фронтендеру для доработки каких-то моментов, которые не устраивают бекэнд разработчика, либо придумывать последнему какие-то «костыли», не прибавляющие коду лаконичности, а сайту скорости.
Случается, что в самом разгаре работ приходится менять подрядчика (причины могут быть разными, зависящими, как от заказчика, так и от исполнителя). Если у вас есть грамотно составленное ТЗ, новый подрядчик быстро войдет в курс дела и реализует все именно так, как было задумано. Если работать с несколькими исполнителями без единого технического задания, может получиться, как в известном мультфильме.
Техническое задание для разработчиков это своеобразный рецепт приготовления успешного продукта . Об этом говорит сайт https://intellect.icu . Успешный продукт — тот, который легко поддерживать, можно развивать и менять, он не развалиться при смене разработчика и приносит прибыль в любом ее виде. Вы хотите, чтобы ваш проект был полноценным? Отлично. Напишите для этого хороший рецепт. Классическими ингредиентами (по международному стандарту IEEE-830) служат:
- Концептуальная модель
- Функциональная карта
- Путь пользователя
- Пользовательский интерфейс
- Программные интерфейсы
- Нефункциональные требования
Варианты определения спецификации
- Конструкторский документ, содержащий перечень составных частей, входящих в специфицируемое изделие, а также других конструкторских документов, относящиеся к этому изделию и к его неспецифицируемым составным частям (ГОСТ Р 2.106-2019).
- Точное описание потребностей, которые необходимо удовлетворить, и важных требуемых характеристик (Свод знаний по управлению проектами).
- Документ, обеспечивающий точное описание системы для целей ее разработки или валидации (ISO/IEC 2382-20:1990).
- Документ, который полно описывает элемент проекта или его интерфейсы в терминах требований (к функциям, производительности, ограничениям и устройству), а также условия приемки и процедуры проверки требований (IEEE Std 1220-2005).
- Один из основных документов технической конструкторской документации (на изделие, продукты и т. д.) — выполняемый обычно в виде таблицы, в которой указываются название изделия, его составные части и элементы, материал, из которого они изготовляются, масса и др. данные (Большой энциклопедический словарь).
- Детальная инструкция по выполнению работы или по использованию материалов в проекте; инструкция, которая в точности описывает, как что-то изготовить (Merriam-Webster Dictionary).
Что Вы получаете в результате составления технического задания на разработку ПО?
Правильно составленное техническое задание – это фундамент и основа проекта, без которого невозможно осуществить цель работы, желания и требования заказчика. На ТЗ будет выстраиваться вся дальнейшая работа.
Среди преимуществ ТЗ на разработку ПО для клиента:
- Информирование исполнителя. Разработчик должен иметь четкое представление о специфике деятельности организации, проблематике и задачах от руководства, которые решаются посредством внедрения разрабатываемого ПО.
- Учет разногласий и противоречий. В ходе устных переговоров между заказчиками и исполнителями часто возникают определенные разногласия. У клиента есть свое представление о результатах проекта, у разработчика свое представление о корректности выполнения всех поставленных задач. Поэтому, все критерии оценки проводимой работы должны быть полностью прозрачными, чтобы озвучиваемые мнения и идеи трактовались одинаково правильно для обеих сторон.
- Юридические гарантии. Кроме договора и приложений, ТЗ наделяется юридической силой. После того как все условия сделки будут оговорены, заключается официальный договор.
Техническое задание важно для каждого участника выполняемого проекта по разработке, а также модернизации и внедрению ПО.
Техническое задание программного обеспечения оказалось поверхностным?
Итак, техническое задание, вне зависимости от выбранного ГОСТа, всегда включает следующие основные сведения по разрабатываемому ПО:
1) наименование – полное и краткое названия, условное обозначение разрабатываемого ПО;
2) назначение – то, для чего, в какой области и с какой целью разрабатывается ПО;
3) основание для разработки – документы, на основании которых производится разработка ПО;
4) функции – перечень и описание функций разрабатываемого ПО;
5) структура – описание архитектуры и компонентов разрабатываемого ПО;
6) пользовательский интерфейс – в современном мире обязателен;
7) надежность, безопасность, условия эксплуатации и проч. важные требования;
8) документация – какая документация, в каком объеме и в соответствии с какими требованиями ГОСТов будет также разработана;
9) стадии и этапы разработки – что и в какой последовательности разрабатывается;
10) порядок контроля и приемка – как именно будет происходить сдача разработанного ПО Заказчику.