Расскажите для чего необходимо тз исполнителю
Составление технического задания по 44‑ФЗ: особенности и правила
Техническое задание — важнейшая часть документации, и это одно из условий успешной закупки. Чем четче вы пропишите техническое задание и чем больше требований предъявите к поставщику и товару, тем более качественный товар получите.
Вопрос правильного составления технического задания важен не только для заказчиков, но и для поставщиков поскольку техническое задание является тем документом, на основании которого они делают выводы, стоит ли им участвовать в тендере или нет.
Что такое техническое задание и где оно используется
Техническое задание — это документ, в котором заказчик описывает объект закупки, то есть требования, которые он предъявляет к закупаемым товарам, работам или услугам. Как правило, техническое задание — это либо приложение к контракту или договору, либо часть документации, в которой изложено, что конкретно приобретается по договору.
Важно!
Термин «техническое задание» — не единственно возможный, а лишь наиболее часто используемый. Другие допустимые названия: «техническая часть», «спецификация», «проектно-сметная документация» и т.п. Федеральный закон от 5.04.2013 № 44-ФЗ раздел документации о закупке, в котором заказчик описывает объект закупки, определяет как «описание объекта закупки».
Независимо от употребляемого термина, важно, чтобы требования к закупаемым товарам, работам и услугам были конкретными, понятными и не противоречили законодательству — 44-ФЗ, 223-ФЗ и 135-ФЗ.
Техническое задание используется:
В соответствии с ч. 2 ст. 33 Федерального закона от 05.04.2013 № 44-ФЗ в техническом задании должны быть указаны показатели, позволяющие определить соответствие закупаемых товаров, работ, услуг установленным заказчиком требованиям. При этом указываются максимальные и (или) минимальные значения таких показателей, а также значения показателей, которые не могут изменяться. Это необходимо для того, чтобы не ограничивалась конкуренция. К товару нельзя определить определенный вес, размер, габариты, мощность. Должны быть максимальные и минимальные значения. А уже потенциальный участник попытается поставить товар, характеристики которого входят в этот диапазон. При этом в ст. 33 также сказано, что есть показатели, которые не могут изменятся.
Правила формирования технического задания
Эксперт по тендерам и ведущий вебинара «Правила составления технических заданий в рамках закона 44-ФЗ и требования к их содержанию» Олег Бируля рассказывает, на что заказчику следует обратить внимание при составлении технического задания:
Особенности подготовки технического задания
В описание объекта закупки не должны включаться требования или указания:
Нельзя в рамках описания объекта закупки предъявлять требования к товарам, информации, работам и услугам при условии, что такие требования влекут за собой ограничение количества участников закупки. Законодатель не расписывает, какие условия и какие требования влекут за собой ограничения, он просто обращает внимание на то, что нельзя предъявлять требования, которые ведут за собой ограничение количества участников закупки, то есть нарушают конкуренцию. Исключение составляют лишь случаи, когда нет другого способа, обеспечивающего более точное и четкое описание характеристик объекта закупки.
Найдите все закупки благодаря умному поиску
В определенных случаях 44-ФЗ допускает указание в конкурсной документации товарных знаков — в случае если при выполнении работ, оказании услуг предполагается использовать товары, поставки которых не являются предметом контракта. При этом обязательным условием является включение в описание объекта закупки слов «или эквивалент». Допустим, предметом контракта является строительство. Разумеется, в рамках строительства используются строительные материалы — например, цемент, клей, кирпич определенных марок. Но поскольку цемент, клей, кирпич не являются предметом контракта, то заказчик, закупая, по сути, работу с использование материалов, может предъявить требования к материалам, то есть указать, что ему нужен цемент, клей, кирпич определенной торговой марки. Но со словами «или эквивалент».
Есть ряд исключений, когда слова «или эквивалент» не пишутся:
В описании объекта закупки должны использоваться, если это возможно, стандартные показатели, требования, условные обозначения, терминология, касающаяся технических и качественных характеристик объекта закупки, которые установлены в соответствии с техническими регламентами, стандартами и иными требованиями.
Ст. 33 44-ФЗ разрешает в описание объекта закупки включать спецификации, планы, чертежи, эскизы, фотографии, результаты работ, тестирования, требования в отношении проведения испытаний, методов испытаний, упаковки в соответствии с требованиями гражданского кодекса РФ, маркировки, этикеток, подтверждения соответствия (стандарту, ТУ или др.), процессов и методов производства и др.
Документация должна содержать изображение поставляемого товара (если есть требование о соответствии поставляемого товара изображению).
Документация должна содержать информацию о месте, датах начала и окончания, порядке и графике осмотра участниками закупки образца или макета товара, на поставку которого заключается контракт (при наличии требования о соответствии поставляемого товара образцу или макету товара). Например, если госзаказчик пишет в документации, что поставляемый товар должен соответствовать определенному макету, то он должен указать, по какому адресу расположен макет, чтобы все потенциальные участники закупки могли в определенное время ознакомиться с ним.
Поставляемый товар должен быть новым. То есть речь идет о товаре, который не был в употреблении, в ремонте, не был восстановлен, у которого не была осуществлена замена составных частей и не были восстановлены потребительские свойства. Однако законодатель делает важную оговорку: «в случае если иное не предусмотрено описанием объекта закупки». То есть если заказчик указывает в техническом задании, что ему нужен товар не новый, то он может его получить.
Документация о закупке должна содержать показатели, позволяющие определить соответствие закупаемых товара, работы, услуги потребностям заказчика (указываются максимальные (или) минимальные значения таких показателей, а также значения показателей, которые не могут изменяться. Но если будет указан конкретный показатель, под который попадает только одна марка, значит, будет нарушена конкуренция.
При необходимости в техническом задании устанавливаются требования к гарантийному сроку товара, работы или услуги и объему предоставления гарантий их качества; к гарантийному обслуживанию товара; к расходам на эксплуатацию товара; к обязательности осуществления монтажа и наладки товара; к обучению лиц, осуществляющих использование и обслуживание товара.
В случае определения поставщика новых машин и оборудования заказчик устанавливает в документации о закупке требования к предоставлению гарантии производителя и (или) поставщика данного товара и к сроку действия такой гарантии. Предоставление такой гарантии осуществляется вместе с данным товаром.
В документацию о закупке нельзя включать следующие требования:
Исключения составляют случаи, когда возможность установления таких требований к участнику закупки предусмотрена настоящим законом.
Закон ввел новые инструменты регламентации качества: техническое регулирование, технический регламент, международный стандарт, национальный стандарт, оценка соответствия, декларирование соответствия, знак обращения на рынке и др. Их заказчик тоже может использовать при формировании описания объекта закупки.
Специфические вопросы регулируют другие законы. Так, например, при закупке пищевых продуктов госзаказчик должен ориентироваться на Федеральный закон от 02.01.2000 №29-ФЗ. Особенности описания объектов закупок по государственному оборонному заказу могут устанавливаться Федеральным законом от 29.12.2012 № 275-ФЗ.
Антимонопольное законодательство
В ст. 17 Федерального закона от 26.07.2006 № 135-ФЗ говорится, что при проведении торгов, запроса котировок цен на товары, запроса предложений запрещаются действия, которые приводят или могут привести к недопущению, ограничению или устранению конкуренции. Это следующие действия:
Не пропустите новые публикации
Подпишитесь на рассылку, и мы поможем вам разобраться в требованиях законодательства, подскажем, что делать в спорных ситуациях, и научим больше зарабатывать.
Техническое задание: для чего оно нужно
Техническое задание – это перечень сведений о проекте, включающий персональную информацию (сведения о заказчике, назначение проекта и т.п.), техническую информацию (формат издания, вид бумаги и т.п.), а также конкретные пожелания заказчик к дизайну и работе в целом (образцы исходных материалов, примеры нравящихся макетов, необходимые сроки выполнения и т.п.).
Техническое задание необходимо обеим сторонам – и заказчику, и исполнителю. Заказчику составление ТЗ поможет ясно определить цели и задачи проекта, подумать о стратегии, вспомнить о допущенных в прошлом ошибках (если уже имелся подобный опыт), а также решить, что он, собственно, ждет от исполнителя. Помимо всего прочего, такое ТЗ поможет заказчику упорядочить все свои мысли, идеи и требования в одном документе, чтобы не упустить что‑то важное. Не секрет, что прежде чем приступать к какой‑либо работе – ее надо бы как следует обдумать, составить план действий, а только потом начинать делать. Кроме того, сначала надо определиться с тем, что необходимо сделать, а потом уже пытаться оценить этот объем работ.
Исполнителю же ТЗ нужно в качестве исходной информации по проекту. Только ознакомившись с проектом посредством подобного ТЗ, можно делать выводы о реальном объеме работы, а значит и о ее стоимости, а также сроках выполнения. Кроме того, ТЗ используется в процессе подготовки к работе над проектом или во время его выполнения. От полноты предоставленной заказчиком информации, проработки деталей зачастую зависит и итоговый результат.
ТЗ удобно тем, что вся информация о проекте собрана в одном месте, ее не надо искать по разным источникам – аськам, личкам и почтам, вспоминать телефонные или личные переговоры, рыться в Интернете или получать очередное письмо от заказчика «Я забыл вчера вам сказать еще одну важную вещь по проекту…». Безусловно, настоящее ТЗ может существовать только в письменном виде.
Чем ТЗ отличается от брифа?
По своей сути – почти ничем. Как объясняют нам яндексы и википедии, «бриф – это краткая письменная форма согласительного порядка между планирующими сотрудничать сторонами, в которой прописываются основные параметры». Но в среде фрилансеров по устоявшейся традиции брифом чаще называют анкету с вопросами, касающимися проекта, которая высылается заказчику. Т.е. говоря простым языком, ТЗ – это заполненный бриф. У любого профи в загашнике найдутся и примеры удачных ТЗ, и разные брифы на все случаи жизни.
Как заказчики аргументируют свой отказ от оформления ТЗ?
За годы работы на фрилансе я слышала множество разных мнений от работодателей по поводу того, нужно ли вообще ТЗ для успешной работы. При этом приводятся разные доводы – серьезные или не очень. И эти аргументы зачастую сводятся к тому, что ТЗ – это якобы ненужная вещь, отнимающая время, а профи обязан и так разбираться в проекте с лету и без лишних вопросов.
При этом всегда странно, что заказчик, обращающийся к профессионалу, почему‑то начинает диктовать ему свои условия работы вместо того, чтобы прислушаться к мнению специалиста, который уже «собаку съел» на подобных проектах и по идее лучше знает, что и как необходимо делать.
Итак, что говорят / пишут некоторые заказчики в ответ на просьбу составить ТЗ на проект.
«Я не умею составлять ТЗ»
В принципе это высказывание принимается как оправдание для заказчиков, которые до этого ни разу в жизни не пытались заказать работу у фрилансера-профессионала. Их растерянность понятна. Но в этом случае на помощь приходит бриф – т. е. тот самый опросник, который обычно в наличии у каждого специалиста. Его можно выслать заказчику с просьбой всего лишь аккуратно и подробно ответить на каждый вопрос. Большинство работодателей охотно идут на подобный шаг, ведь гораздо удобнее писать ТЗ не с нуля, а воспользовавшись грамотным шаблоном или образцом с перечнем необходимых вопросов. А кто может лучше знать о своем проекте и ответить на вопросы по нему, чем не заказчик, его задумавший?
«Мне некогда заниматься писаниной»
Подобный ответ вызывает удивление: что, разве у заказчика нет времени на СВОЙ ЖЕ проект и на то, чтобы донести максимум информации до исполнителя для получения необходимого ему же самому результата? Может быть, и проект этот не так уж важен и нужен, чтобы никак нельзя было потратить на составление ТЗ некоторое время? Словом, такой подход к работе со стороны заказчика как минимум выглядит несколько безответственно. Все‑таки выполнение проекта – это дело не только исполнителя, заказчик тоже должен активно участвовать в нем и всячески помогать. Категорический отказ заказчика от составления ТЗ может являться первым сигналом к тому, что с таким работодателем, возможно, сотрудничество станет не самым приятным.
«У нас все просто, поэтому ТЗ не нужно. Давайте я вам лучше позвоню и быстренько расскажу, что нам надо / Приезжайте к нам в офис на собеседование, и мы все обсудим»
Как показывается практика, под этой «простотой» может скрываться на самом деле все, что угодно, особенно если заказчик слабо разбирается в тонкостях работы исполнителя. А попытка заказчика уклониться от письменного ТЗ может в итоге вызвать большие проблемы с проектом у исполнителя – например, дикое количество правок и бесконечных переделок (ведь точная задача толком не была сформулирована и нигде не зафиксирована). Кроме того, важные условия и моменты лучше не обсуждать устно, а если и обсуждать, то обязательно потом их дублировать письменно: ведь обговоренные детали можно забыть, на них нельзя сослаться, перечитать, процитировать. Заказчик может не упомянуть что‑то крайне важное, а исполнитель может какие‑то слова не так расслышать. И все это может привести к проблемам типа «Почему вы это не сделали, я ведь вам говорил! – Нет, вы мне такого не говорили!» Поэтому я предпочитаю общаться с заказчиками через почту, ICQ или Skype. Поездке на собеседования в офис все равно необходимо предварить ознакомление хотя бы с общим ТЗ. Неприятно будет, приехав к заказчику, узнать, что предлагаемая ими работа тебе совсем не подходит. К тому же любой проект можно организовать полностью удаленно, а очное общение заказчика и фрилансера 100 %-ного результата вовсе не гарантирует.
«Вы сначала назовите цены, а ТЗ я пришлю выбранному исполнителю»
Категоричный запрос от заказчика типа «нужна верстка книги, цена и только потом я расскажу подробности» или просто без деталей «меня интересует верстка каталога, цена» – это довольно частое явление. Тот факт, что исполнитель сначала должен узнать подробности по проекту, вникнуть в него, понять, каков объем работы, а только потом называть соответствующие цены, – почему‑то некоторые заказчики упорно игнорируют. Правда, некоторых из таких работодателей больше интересует факт низкой стоимости, а не качество исполнения работы, поэтому они и начинают общение со всеми кандидатами именно с вопроса цены. Кто меньше предложит, того и… А вот чем руководствуются исполнители, которые не видя материалов и не зная деталей по проекту, сходу называют какие‑то цифры и суммы – мне непонятно. Возможно, это новички, пока не очень разбирающиеся в теме и стремящиеся урвать проект. Кстати, «вилка цен» на какой‑либо тип проекта, которую тоже так любят спрашивать заказчики, реально может колебаться в десятки раз – не думаю, что ответ типа «от 1 000 до 100 000 руб.» может кого‑то устроить.
«Наш прошлый исполнитель всегда работал без всяких ТЗ и все было нормально»
Я, например, не могу отвечать за действия и работу других людей. И не знаю ни уровень мастерства того человека, ни манеру его работы. Кроме того, не факт, что ТЗ действительно вообще никакого не было – хотя бы в разрозненном виде в нескольких письмах как ответы на вопросы или при общении по аське. А может быть, прежний исполнитель обладает телепатией и навыком чтения мыслей заказчиков на расстоянии? 🙂 В этом случае, действительно, никакое ТЗ ему не нужно было вовсе.
«Ну вы же дизайнер-профессионал, вам виднее, что и как делать. Предложите свой вариант, а мы посмотрим»
Эдакий льстящий исполнителю ответ. Но если вникнуть в суть – видимо, тут тоже имеется в виду, что исполнитель должен быть ясновидящим, чтобы без какой‑либо информации приступить к работе и выдать всем устраивающий заказчика результат. Кстати, зачастую сначала работодателем говорится «делайте все на свое усмотрение», а потом «ой, мы думали, что это будет выглядеть по‑другому». А может, заказчик просто ленивый или необязательный по жизни человек и пытается увильнуть от своей части работы? Но чем в итоге может кончится работа без ТЗ – понятно: куча правок, переделок, затянувшиеся сроки и даже прекращение работы над проектом с формулировкой «исполнитель упорно не понимает того, что надо заказчику». Оно нам надо?
Поэтому, уважаемые заказчики, пожалуйста, не думайте, что техническое задание лишь прихоть исполнителя и не ленитесь подробно заполнить бриф на ваш же проект. И помните, что качественно составленное ТЗ – это залог успешного выполнения работы. А коллегам-фрилансерам советую не браться за проект без ТЗ, ну или во всяком случае попытаться оформить его совместно с заказчиком: такой подход к работе тоже имеет место быть.
Как писать ТЗ: инструкция по составлению грамотного техзадания
Что такое техническое задание
Техническое задание — это то, с чего начинается качественный функциональный продукт. По крайней мере, если таковым является само ТЗ. Если документ будет составлен непрофессионально и без должного внимания, результат окажется соответствующим.
Учитывая характер целевой аудитории блога и общие тренды, скорее всего, имеет смысл описывать технические задания конкретно на цифровые продукты. Во многом так и будет, но нельзя забывать, что и самые обычные, «аналоговые», продукты тоже требуют документации. Они требовали её ещё до появления самого интернета. Поэтому для расширения кругозора и для пользы представителей нецифровых отраслей, стоит приводить отсылки и к оффлайн-проектам.
Для чего нужно техническое задание?
Техническое задание не менее значимо, чем юридический акт, в деле закрепления прав и обязанностей сторон — заказчика и исполнителя.
Фактически это инструкция для разработчиков, конструкторов и других непосредственных создателей конечного продукта. Но по сути техническое задание, определяя жёсткие требования к каждой детали, делает сотрудничество заказчика и исполнителя безопаснее и комфортнее.
Когда каждая мелочь регламентирована, всё на своих местах, все при своих полномочиях и обязанностях, остаётся мало пространства для нечестного манёвра и недопонимания. Идеально, когда его вообще не остаётся.
Более того, конкретное и целостное техническое задание — это первый шаг к качественному результату. Чтобы продукт работал чётко, без сбоев, да и просто безопасно — это тоже периодически стоит на повестке — все его элементы должны быть продуманы. Тщательно и скрупулезно.
Техническое задание — основа как простых односложных продуктов, так и высоконагруженных систем. В каждом случае сценарии функционирования должны быть предусмотрены. Любое действие пользователя должно быть предугадано, и ответом на него должен быть полезный результат.
Именно для того, чтобы работа с конечным продуктом вызывала положительный отклик пользователя и решала его задачи, необходимо проработать идею и детали проекта на самой ранней стадии.
Кто должен составлять техническое задание
Чтобы понять, как составить техзадание, важно определиться с тем, кто именно это будет делать. На этот вопрос нет однозначного ответа — ТЗ для задачи может составить заказчик или исполнитель, в отдельных случаях — это совместная работа.
Заказчик
В этом случае исполнитель будет четко понимать, что и когда ему потребуется делать. В результате получится точно рассчитать стоимость работ и срок, отведенный на их выполнение. Однако иногда составитель ТЗ не понимает того, что именно должен предоставить им исполнитель, из-за чего с составлением ТЗ возникают проблемы.
Исполнитель
Исполнитель, занимающийся составлением ТЗ, присылает заказчику бриф с вопросами по задаче. Так специалист выясняет цель работы и свою пользу для клиента. После этого проходит интервью, и в режиме диалога стороны уточняют рабочие нюансы. Исполнитель изучает конкурентов и целевую аудиторию, чтобы добавить эту информацию в техническое задание.
Такой способ составления ТЗ удобен, когда заказчик полностью доверяет исполнителю, а исполнитель достаточно компетентен, чтобы разобраться в задаче самостоятельно.
Совместно
Совместное формулирование ТЗ начинается с того, что заказчик озвучивает исполнителю требования относительно будущего задания. Подрядчик, в свою очередь, предлагает, как улучшить проект, и только после этого составляется техническое задание. Этот способ, как и предыдущий, работает на доверии, этичности и профессионализме сторон.
Как составить техническое задание
Главные требования к техническому заданию — это продуманность и полнота. Так как составители не всегда способны им следовать, были разработаны общие стандарты разработки ТЗ.
В вакансиях на должность системного аналитика или технического писателя можно встретить требование: знание ГОСТ 19 и ГОСТ 34. Из названия легко понять, что это общегосударственные стандарты, образцы разработки технических заданий на территории России.
Эти два ГОСТа имеют отношение только к программным комплексам — к сайтам, приложениям и системам автоматизации. Другие ТЗ придется писать по совершенно другим правилам.
ГОСТ 19 был введён в 1980 году. Учитывая, что основные принципы программного обеспечения почти не поменялись, документ еще не утратил своей актуальности. Это можно сравнить со строительством зданий: меняются материалы и конструкции, но общие понятия — фундамент, стены, перекрытия — сохраняются.
Согласно тексту Постановления, согласно которому принят данный стандарт, назначение его следующее: «Устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения».
Само техническое задание должно содержать следующие пункты:
Более новый стандарт — ГОСТ 34, но он новее всего на 10 лет. То есть, введён с 1 января 1990 года.
Формулировка назначения выглядит так: «Распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания…».
Текст технического задания строится по структуре:
Разумеется, за прошедшее время подходы были пересмотрены. Введены новые правила и рекомендации. Сами ГОСТы перешли в разряд базовой опорной точки, а конечный результат остаётся на усмотрение составителей. Тем не менее, при работе с госзаказчиками необходимо брать за основу именно ГОСТ.
ISO/IEC/IEEE 29148
Разработанный Международной организацией по стандартизации ISO, данный современный стандарт пригоден для использования помимо всего прочего в международных проектах.
Последняя редакция — ISO/IEC/IEEE 29148:2018, но, к сожалению, она отсутствует в открытом доступе, поэтому возьмём за основу предыдущую, от 2011 года.
По аналогии с ГОСТами, стандарт содержит два раздела. Один из них, SyRS — System Requirements Specification — определяет общие требования к построению систем, их принципам и характеру взаимодействия пользователя с ними. По похожей схеме составлен ГОСТ 34.
SRS — Software Requirements Specifitaion — по аналогии с ГОСТ 19, содержит требования к конечному программному продукту.
Общая схема строится следующим образом:
Порядок документирования требований
Выйдем немного за пределы тематики и скажем несколько слов о том, из чего состоит весь процесс документального сопровождения продукта. Ведь он не ограничивается техническим заданием. Сложность сопроводительной документации растёт вместе со сложностью и масштабом продукта.
Разработка лендинга на Тильде или запуск таргетированной рекламы Вконтакте радикально отличаются от создания высоконагруженной биллинговой системы банка. Если первые два продукта способен создать один человек, то последний может потребовать команды из нескольких десятков специалистов из многих областей.
В основном, уместен в контексте продуктов низкой и средней сложности. Например, небольшой сайт, воронка продаж или даже копирайтинг.
Бриф обращён к заказчику и не предполагает жёстких финальных требований или детального описания результата. Выверенной должна быть только структура опросника. В него могут входить такие пункты, как:
Вопросов на которые отвечает заказчик, может быть до 20–30, но не более, иначе это становится большой нагрузкой. Задача брифа в том, чтобы получить общее направление для обсуждения.
Такой опрос удобно разместить на сайте, если он не сложный. Его можно запрограммировать или дать ссылку на Google формы. Либо просто разместите кнопку обратного звонка, чтобы задать вопросы и проконсультировать клиента прямо в режиме реального времени по телефону.
Виджет обратного звонка, как инструмент, подходит не только для созвонов с партнерами, но и для клиентского сервиса. Это всплывающее окно предлагает указать контактный номер,по которому перезвонит сотрудник поддержки. С виджетом обратного звонка от Calltouch вы можете собирать заявки даже в нерабочее время, а также записывать и тегировать звонки.
Виджет обратного звонка для сайта
Технико-коммерческое предложение
Здесь речь заходит о действительно крупных проектах. В противном случае нецелесообразно прилагать излишние усилия к созданию подобных документов.
ТКП разрабатывается в рамках маркетинговых мероприятий, когда продукт предлагается потенциальным заказчиком. Если у вас есть собственная концепция, готовая к внедрению или масштабированию, на её основе можно сделать предложение.
Документ содержит не просто идею и общее описание, но некоторые технические подробности. На их основе заказчику удобнее принимать решение, так как он сразу может увидеть, насколько характеристики продукта согласуются с той инфраструктурой, которая есть в наличии.
Бесполезно предлагать промышленные системы вентиляции маленьким кофейням. В других случаях помещение может отвечать требованиям, но электроснабжение окажется несовместимым с требованиями оборудования по питанию.
Технические требования
Если в ТКП требования приводятся самые основные, для ознакомления, то при заинтересованности заказчика с ним составляются уже более детализированные перечни требований.
Техническое задание
Собственно, предмет статьи. Предварительные сведения даны в предыдущих пунктах, а ценные советы ждут вас в следующем разделе.
Технический проект
Этап «живого» проектирования продукта. Здесь начинаются активные действия по разработке решений согласно ТЗ. В ходе работы уточняются и проясняются отдельные нюансы, требования, доработки.
В соответствии с практическими наработками, составляются новые задания и требования — частные технические задания по отдельным подсистемам (ЧТЗ).
Эксплуатация
Важно помнить, что после сдачи проекта стороны распределяют между собой обязанности по поддержанию работоспособности системы. Это тоже должно быть прописано — например, в техническом задании, если не предусмотрено другого порядка.
Перед эксплуатацией и во время неё создаются различные регламенты, описания сервисов, инструкции. Актуализируются текущие версии документов.
Когда условия работы или технологии модифицируются, приходится вносить правки в документы и внедрять изменения в продукт.
Рекомендации по составлению ТЗ
Правильное ТЗ составляют по универсальному шаблону. Он формируется из следующих элементов.
Дайте подрядчику общую информацию
Подрядчик должен понимать, чем занимается компания и кто ваша целевая аудитория. Так исполнитель сможет глубже вникнуть в поставленную задачу и избежать элементарных ошибок. При озвучивании идеи важно отметить конкурентные преимущества и особенности проекта.
Покажите конкурентов
ТЗ должно содержать ссылки на похожие проекты с дополнительным описанием. Это поможет исполнителю оценить удачные примеры чужих разработок и избежать характерных проблем при реализации. Кроме того, выявление чужих особенностей позволяет создать собственное уникальное решение.
Распишите сценарии использования продукта
Сценарий нужен для понимания принципа работы продукта. Например, если область работы касается IT, сценарий отвечает на вопрос «Как будет вести себя пользователь?» и дает понимание главных функций сайта.
Ведите историю правок
В начале документа создайте таблицу со столбцами “дата”, “описание”, “автор”. В ней записывается история изменений документа, благодаря которой легко понять, на каком этапе возникло то или иное требование, дополнение, противоречие.
Составляйте список терминов и сокращений
Это правило грамотного подхода к формированию документа. Основной текст предваряется словарём, в котором записаны специальные термины, не являющиеся общеупотребимыми. Особенно уделите внимание тем аббревиатурам и словам, которые применяются только в данному проекту.
Прописывайте каждую деталь
Сайт — это не только код, но и мощности, на которых он работает. В первую очередь, определите, на каком сервере будет размещён сайт, какие у него параметры: ёмкость, оперативная память и другие.
Пропишите периодичность и порядок оплаты сервера — передаст ли заказчик обязанность бухгалтерии или же вы будете получать ежемесячную абонентскую плату, из которой сами должны распределять средства на те или иные нужды.
Позаботьтесь о пользователях. Продумайте, какими браузерами и устройствами они пользуются, какое у них разрешение. Адаптируйте сайт, если речь идёт о нём, под различные технические характеристики устройств.
Не оставляйте белых пятен. При наведении на рисунок, он скрывается? Хорошо, но уточните — он уезжает влево? Становится прозрачным? С какой скоростью? Как он появляется опять? Малейшая деталь без чёткой логики ставит разработчиков и весь процесс в тупик.
Опишите требования к проверке проекта
На этапе составления техзадания продумайте чек-лист, по которому заказчику будет понятна степень успешности реализованного проекта. Так можно быстро оценить проделанную работу и не забыть о значимых нюансах.
Бывают случаи, когда исполнитель работает за фиксированную плату и некий процент от продаж. Например, вы заказали на таких условиях настройку таргетированной рекламы у фрилансера. Чтобы честно оценить его работу, вам поможет сервис сквозной аналитики от Calltouch. Он формирует отчет о результатах рекламных кампаний: сколько было звонков и заявок, и сколько из них привели к оформлению заказа. Вам не придется высчитывать KPI — итоги работы наглядно отражены в личном кабинете.
Сквозная аналитика
Когда ТЗ не нужно
Техническое задание требуется не каждому продукту. Иногда достаточно предпроектного исследования, чтобы изучить потребности клиентов вместе с аналитиком. После этого следует решать, есть ли необходимость в ТЗ.
Зачастую более гибкие методологии, работающие на создание продукта, позволяют успешно и оперативно использовать ресурсы компании. Например, сначала формируется маленький прототип, который тестируют, и на основании обратной связи от клиентов корректируют до полноценного продукта.
Выводы
Техническое задание — важный этап подготовки к работе над проектами. Его составление помогает заказчику сформулировать суть задачи, а исполнителю дает понять, как ее выполнить. Составить ТЗ может заказчик, исполнитель или заказчик вместе с исполнителем. Выбор варианта сотрудничества зависит от сложности работ и навыков специалиста.