Итак, техническое задание, сокращенно ТЗ, уже довольно давно служит для формального описания того, что мы собственно хотим видеть в конечном продукте. Не является исключением и ТЗ для разработки web-ресурса. По своей сути - это база для разработки сайта. В нем указываются все положения, прямо или косвенно касающиеся сайта.
ТЗ, как правило, прилагается к основному договору на работы по созданию web-ресурса, т. к. включает полный перечень всех работ для обязательного выполнения дабы исключить возможные споры между клиентом и исполнителем, которые как известно все-равно время от времени возникают.
Есть мнение некоторых “побитых” опытом людей, что ТЗ надо писать так, как будто с ним вы будете присутствовать на суде и использовать его в качестве защиты. Может это и крайность, но тем не менее - повод лишний раз задуматься о важности хорошо написанного и детализированного ТЗ .
По своему объему ТЗ может быть достаточно большим документом. Web-компании часто предлагают помощь по составлению ТЗ отдельной услугой, как правило 10-20% от стоимости всей разработки сайта.
Составление ТЗ как правило выполняют руководитель проекта или непосредственно программист при участии заказчика, который предоставляет основную информацию.
Чем детализированнее ТЗ
(в разумных пределах конечно), тем лучше для обеих сторон — как для клиента, так и для исполнителя работы. В выигрыше так сказать оба:
— клиент будет уверен, что все задуманное им в проекте четко прописано и должно быть реализовано в соответствии с ТЗ.
— исполнитель – застрахован от множества мелких или крупных корректировок и доработок, опять же опираясь на то самое ТЗ.
Существует мнение, что без ТЗ можно обойтись. Например, один из доводов — задача слишком творческая, что бы уложить ее в рамки ТЗ. Такое мнение, скорее всего, скрывает нехватку опыта и профессионализма в данной области. Считаю такое мнение ошибочным, так как почти все в сайтостроении можно формализовать и представить в ТЗ и составить его – это скорее дело опыта.
Справка
Прототип — это графическая схема размещения элементов интерфейса. Грубо говоря, нарисованная в специальной программе страница со всеми элементами.
Существует много софта для прорисовки прототипов, включая как декстопные приложения, так и онлайн-сервисы, а также расширения для браузеров с более скромными возможностями. Софт как с бесплатной лицензией так и с платной.
Из популярных можно выделить:
— среди бесплатных: iPlotz, MockFlow, Mockup Builder, Cacoo;
— среди платных: Creately, ProtoShare, Adobe Fireworks,Axure . Возможностей в общем много - выбирай, осваивай, рисуй…
Одна из возможных структур сайта, подчеркну возможных, может выглядеть примерно так:
1. Общая информация о сайте
Здесь достаточно несколько предложений для того что бы ввести в курс дела, что за сайт или модуль будет разрабатываться и его цель в общем. Пишется вольным стилем.
2. Функциональное назначение сайта
Тут краткий перечень того, какими техническими средствами или инструментами должен обладать сайт, исходя из общей цели. Поясню на примере. Для сайта-визитки это может быть банально, форма обратной связи, перечень основных страниц, например с «о компании», «контакты» и прочие.
3. Понятия и термины
Этот раздел должен гарантировать понимание обеими сторонами специфических для данной предметной области понятий, которые важны для понимания и разработки сайта. Могут вводиться обеими сторонами.
4. Описание модулей сайта
Этот раздел включает список модулей, которые используются на сайте. Это вполне например может быть упоминаемая выше форма обратной связи (ФОС). Но, что очень важно — нельзя просто писать «Должна присутствовать ФОС». Каждая сущность требует определения своих атрибутов! В данном случае атрибуты могут быть такими:
И все это должно быть четко прописано, что бы потом не возникло вопросов: «…а где перечень выбора категории вопроса? » или что-то в этом роде.
5. Функциональные характеристики
Сюда можно отнести, например, список браузеров, где сайт должен корректно отображаться и работать. Например, некоторые заказчики могут требовать, что бы их сайт работал корректно и в небезызвестном Internet Explorer 6, что бы не терять хоть и небольшую, но долю возможных посетителей.
Если планируется делать высоконагруженный сайт – это тоже нужно указывать. Высоконагруженный сайт требует другого подхода при разработке и по настройке сервера.
Также в функциональные характеристики входит наличие или отсутствие мобильной версии сайта, но это, как правило, либо уходит в отдельный раздел данного ТЗ либо вообще отдельно пишется.
6. Описание страниц сайта
Это довольно обширный пункт, где прорисовуются все страницы сайта и пишутся комментарии к их работе.
Также может приводиться общая структура страниц сайта. Так называемые «высокоуровневые» прототипы. Например, для простого сайта-каталога это может быть:
Для каждой конкретной страницы могут рисоваться прототипы с подробными комментариями по каждому из элементов интерфейса с их поведением.
Страницы, используемые для админ-панели обычно уазываются отдельно от спубличных страниц. Эти два раздела в свою очередь могут группироваться в свои отдельные подразделы. Здесь стоит следить, чтобы прототипы не конфликтовали с их описанием, и не возникало никаких противоречий. Примером прототипа определенной страницы сайта может быть:
Остальные страницы
Последние два раздела ТЗ мы не будет рассматривать детально, скажу вкратце, что одно из требований к надежности может включать настройку резервного копирования БД.
Требования к хостингу может включать доступную физическую память для сайта, пропускную способность канала, поддержку используемой базы данных и ряд других требований, предъявляемых для корректной работы сайта.
В конец ТЗ в обязательном порядке нужно внести информацию о том, что все работы, не описанные в настоящем ТЗ, выполняется по усмотрению программиста по очевидным причинам. Это наша «маленькая гарантия» от возможных доработок и переделок, выходящих за рамки ТЗ.
Выводы: Надо сказать, что такая структура разделов ТЗ не претендует на всю полноту (по крайней мере для больших стратегических проектов), но основные моменты все же охватывает.
Надо подчеркнуть, что всё вышеизложенное является только рекомендациями, основанными на опыте людей, работающих в сфере сайтостроения и никак не является жестким требованием, предъявляемым к написанию ТЗ.
Удачных Вам проектов и человеческого взаимопонимания!
Подписаться на рассылку Павел Молянов 
Помните закон Мерфи? Если вас могут понять неправильно, вас обязательно поймут неправильно. Это справедливо не только в общении между людьми, но и в создании сайтов. Клиент хотел второй «Фейсбук», а получил форум юных собаководов. Разработчик не угадал хотелку заказчика - потратил время впустую.
В этом гайде я расскажу, что и зачем нужно писать в техзадании. Заодно покажу, как писать не надо, чтобы создание ТЗ не обернулось потраченным впустую временем.
Статья будет полезна:
Чтобы материал получился дельный, я собрал комментарии нескольких разработчиков, дизайнеров, проект-менеджеров и владельцев диджитал-студий. Самые ценные добавил в конец статьи. Поехали разбираться.
Техническое задание - это документ, в котором зафиксированы требования к сайту. Чем четче и подробнее расписаны эти требования, тем лучше все участники процесса понимают, каким он должен быть. А значит, растет шанс того, что все останутся довольны результатом.
Главная цель технического задания: убедиться, что клиент и исполнитель правильно поняли друг друга.
Пользы от технического задания много. Для каждой стороны она своя.
Польза для клиента:
Польза для исполнителя:
Теперь давайте разберемся, как составить хорошее техзадание, которое выполняет все эти функции.
Вообще техзадание может составить кто угодно. «Нужен сайт-визитка для стоматологической клиники» - это уже техзадание. Но будет ли оно выполнять свои функции? Вряд ли.
Хорошее ТЗ всегда составляет исполнитель: проект-менеджер или разработчик. Очевидно, что веб-разработчик понимает в создании сайтов больше, чем владелец кафе или стоматологической клиники. Поэтому описывать проект придется ему.
Это не значит, что клиент исчезает и появляется в самом конце, чтобы написать: «Збс, одобряю». Он тоже должен участвовать в процессе:
Конечно, заказчик может набросать свой вариант ТЗ. Возможно, это ускорит процесс создания конечного техзадания. А возможно, получится мусор, который втихаря выкинут на помойку.
Этот совет вытекает из главной цели техзадания - «Убедиться, что клиент и исполнитель правильно поняли друг друга».
В техническом задании не должно быть качественных прилагательных: красивый, надежный, современный. Их нельзя однозначно понять. У каждого свои понятия красоты и современности.
Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:
То же самое - с невнятными формулировками, которые ничего сами по себе не значат:
Проверяйте, нет ли в тексте неоднозначностей. Если есть - перепишите. Ваши формулировки должны быть четкими и точными:
С формулировками разобрались, давайте пробежимся по структуре.
Все члены команды должны правильно понимать, чем занимается компания и кто ее целевая аудитория. Чтобы никто не запутался, это лучше прописать в самом начале техзадания.
А еще стоит указать цель сайта и описать его функционал в двух словах - чтобы не получить интернет-магазин вместо блога.
Первое правило техзадания - оно должно быть понятно всем, для кого предназначено. Если вы собираетесь использовать термины, которые может не понять ваша клиентка - владелица магазина детских игрушек - обязательно поясните их. Понятным языком, а не копипастой из «Википедии».
Представьте, что вы 2 месяца делали крутой сайт. Каждый этап согласовывали с клиентом - он в восторге. И вот пришло время сдавать работу. Вы показываете админку, а клиент кричит: «Это что такое? Модэкс?! Я думал, вы сделаете на «Вордпрессе»!»
Чтобы таких проблем не было, опишите используемые инструменты, движки и библиотеки. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP - а у клиента сервер на.NET.
Сайт должен работать во всех браузерах актуальных версий и на всех типах устройств. Да, это очевидно для любого разработчика и любого заказчика. Но лучше написать, чтобы защитить клиента от недобросовестно выполненной работы.
Сюда же напишите требования к скорости загрузки сайта , устойчивости к нагрузкам, защите от хакерских атак и подобным вещам.
До начала отрисовки дизайна и верстки вам нужно согласовать с клиентом структуру сайта.
Пообщайтесь с заказчиком, выясните, что ему надо. Соберите разработчиков, сеошников, маркетологов, главреда - и решите, какие страницы нужны на сайте. Подумайте, как они будут связаны между собой, с какой на какую можно перейти.
Можно показать структуру списком, можно нарисовать блок-схему. Как вам удобнее.
Это один из важнейших этапов работы на сайтом. Структура - это фундамент. Если она неудачная - сайт получится кривой.
Клиент должен понять, зачем нужна каждая страница и какие элементы на ней будут. Есть два способа это показать.
Прототип - более наглядный и однозначный способ. Исполнитель рисует эскизы каждой страницы и прилагает их к техзаданию. Клиент видит, как будет выглядеть интерфейс его будущего сайта и говорит, что ему нравится, а что стоит изменить.
Перечисление элементов - ленивая альтернатива прототипу. Просто напишите, какие блоки должны быть на странице, и что они делают.
Если вы делаете какой-то нестандартный интерфейс, просто показать структуру и эскизы страниц недостаточно. Важно, чтобы вся команда исполнителей и клиент поняли, как посетители будут пользоваться сайтом. Для этого отлично подходят сценарии. Схема сценария очень простая:
Конечно, если вы делаете стандартную визитку или лендинг, писать сценарии не нужно. Но если на сайте будут какие-то интерактивные сервисы - очень желательно.
Подробнее о сценариях использования читайте в «Википедии ».
Одни разработчики делают сайт сразу с контентом. Другие ставят рыбу. Третьи могут написать тексты, но за дополнительную плату. Договоритесь об этом на берегу и зафиксируйте в техзадании, какой контент вы должны подготовить.
Придумать объективные критерии оценки качества текстов довольно сложно. Лучше не пишите ничего, чем «Качественный, интересный и продающий контент, полезный для целевой аудитории». Это мусор, он никому не нужен.
Указать, что весь контент должен быть уникальный, - это полезно. Еще одна защита клиента от недобросовестных исполнителей.
Как и в с случае с текстом, объективные критерии оценки дизайна сайта придумать сложно. Если вы с клиентом договорились о цветовой гамме - напишите ее. Если у него есть брендбук, в котором прописаны шрифты, - укажите и их.
Писать про красивый и современный дизайн не надо. Это ничего не значит, не имеет силы и вообще фу.
Для разных задач структура ТЗ будет своя. Глупо делать одинаковые технические задания для новой социальной сети и лендинга по оптовой продаже моркови. Но в целом вам нужны такие разделы:
Это конец той части, которую писал я. Но есть и другая - комментарии специалистов, которые помогали делать гайд. Почитайте, это тоже интересно.
Я пообщался с несколькими разработчиками, чтобы узнать, как они составляют техзадания. Передаю микрофон им.
В первую очередь ТЗ нужно клиенту - чтобы он понял, каким будет его сайт, и на что уходят деньги. Если что-то сделано не так - он может сослаться на ТЗ и попросить переделать.
ТЗ составляет менеджер проекта после общения с клиентом и обсуждения задачи с дизайнером.
Крупные заказчики часто просят очень подробные ТЗ, в которых описана каждая кнопка. Небольшие компании наоборот не любят дотошные документы на 100 страниц. Долго читать и легко упустить что-то важное. Чаще мы делаем лаконичные ТЗ на 10–15 страниц.
Мы указываем:
Последние 2 раздела - самые важные. Именно они обеспечивают понимание, какие будет сайт и как он будет работать.
Очень важный момент - нельзя просто отдать техзадание разработчикам и надеяться, что они все сделают хорошо. ТЗ - это список требований к сайту, оно не может заменить общение. Важно убедиться, что каждый член команды понимает общую цель, а не просто выполняет задачи на потоке. Если что-то непонятно - надо объяснить, обсудить, дать подробные комментарии.
Данный текст был создан сугубо ради существования постоянной ссылки, которую бы сам автор, да и все вы - могли бы смело отправлять своим будущим заказчикам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «А надо ли мне ваше ТЗ и вообще что это?»
Как говорится - «вместо тысячи слов», поскольку каждый раз евангелистить по 4-5 часов в скайпе на данную тему становится уже утомительным, а общемировая тенденция подсовывать под определение «Технического задания» откровенную ерунду с годами все только усиливается.
Дело в том, что когда существует конкретный формат, а также четкое и внятное определение какого-либо термина, то все манипуляции и подмены его на собственные брифы, прототипы, на ходу придуманные опросники, описания и просто входящие заявки - выглядят, по меньшей мере, непрофессионально. Поэтому с научного определения нашего понятия и начинаем:
Техническое задание - исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования. Техническое задание является юридическим документом - как приложение включается в договор между заказчиком и исполнителем на проведение проектных работ и является его основой: определяет порядок и условия работ, в том числе цель, задачи, принципы, ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет. Все изменения, дополнения и уточнения формулировок ТЗ обязательно согласуются с заказчиком и им утверждаются. Это необходимо и потому, что в случае обнаружения в процессе решения проектной задачи неточностей или ошибочности исходных данных возникает необходимость определения степени вины каждой из сторон-участниц разработки, распределения понесенных в связи с этим убытков. Техническое задание, как термин в области информационных технологий – это юридически значимый документ, содержащий исчерпывающую информацию, необходимую для постановки задач исполнителям на разработку, внедрение или интеграцию программного продукта, информационной системы, сайта, портала либо прочего ИТ сервиса.
1) ТехЗадание - оно ставит задачу. А значит оно должно идти перед прототипом, скетчем, тестом, дизайн-проектом, потому что любой майндмеп, диаграмма потоков данных, архитектура - это уже выполнение некой задачи, это ответ на вопрос. А до того, как сам вопрос еще не задан, не сформулирован и не подписан всеми сторонами - любой ответ будет априори неправильным, не так ли? Итак, начало любой работы над любым проектом - это постановка задачи, а не судорожный поиск набросков десятка вариантов ее решения.
2) Собственно из первого пункта логично вытекает и новый - сам текст ТЗ обязан начинаться с главы «Цели и задачи», четко формулирующей, какие бизнес-цели преследует вся эта очередная попытка повысить энтропию в мире. Бесцельное задание, которое не решает никаких проблем, не достигает ничего и делается «от скуки» - официально не считается Техническим Заданием, а с этого момента находится в статусе «обычная бумажка».
3) Как же вам понять, решает ли предложенная дизайн-концепция или интерактивный прототип, а то и готовый к употреблению сайт - вышеизложенную задачу бизнеса? Ничего не поделаешь, придется опять вернуться к определению: «определяет… ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет». То есть ТЗ без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия - быть не может. Бриф может, или прототип, или еще любая абсурдная бумажка, но только не ТехЗадание.
Отсюда делаем вывод, что в настоящем ТЗ обязательно должна быть глава «Порядок приемки и оценки», когда эти самые показатели берутся, замеряются, и стороны либо пожимают друг другу руки, либо отправляют проект на переделку.
4) ТехЗадание должно обязательно согласоваться с общим бизнес-планом заказчика, с его стратегией развития бизнеса и анализом сегмента рынка. Именно все это позволит установить правильные цели, вывести точные метрики, по которым затем адекватно провести приемку готового инфопродукта. Отсутствие у заказчика бизнес-плана автоматически гарантирует непрофессиональное выполнение Технического Задания.
Знает ли студия на аутсорсе бизнес-цели и измеримые показатели бизнеса лучше его владельца? Очевидно, что нет, а значит правильное ТЗ должно писаться представителями Заказчика, а не наемными работниками Исполнителя. Абсурд, когда исполнитель сам себе ставит задачу, затем сам себе придумывает способы ее оценки, и в конце сам же выставляет себе итоговую отметку за сделанную работу. В идеале такой «самодеятельности» быть не должно, хотя на практике повсюду именно так и происходит, в результате чего ТехЗадание и не оказывает нужной помощи проекту, слишком часто являясь по сути фиктивным документом. Не надо так.
5) Каждое внесение правок в готовое ТЗ должно стоить денег. Нельзя бесплатно и бесконечно править «Конституцию вашего проекта» только потому, что одна из сторон передумала, не выспалась, внезапно решила сэкономить и т.д. Цена каждого изменения в ТЗ должна также четко прописываться заранее в соответствующей главе.
Кстати, по идее точно также каждая правка в дизайне или внесение изменений в список страниц или функций должна иметь четкую цену, которая оплачивается заранее, до начала внесения данного изменения. Лично я предлагаю любую редактуру утвержденного ТЗ оценивать в 30% от всего бюджета проекта, но вы можете поступать иначе.
Стоит ли упоминать, что в ТЗ просто необходимо заранее указывать сроки и общий бюджет на разработку, а также список всех существующих ресурсов и ограничений? - Нет, это будет уж слишком очевидно.
Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? - написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.
1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? - Да, даже несколько.
2) А что, в ТехЗадание не входит описание нужных страниц, количества кнопок, используемых библиотек, гайдлайнов и т.д.? - В само ТЗ нет, но в Приложения вы можете все это поместить, разумеется скорректировав все это с вышеописанными целями, ограничениями и способами дальнейшей оценки достигнутого результата. Размещайте хоть весь будущий контент, хоть описание типовых персонажей - но не вместо четкой постановки задачи, а уже после нее.
3) Так может оно мне такое и не нужно? - Возможно, сегодня тысячи сайтов делаются вообще без ТЗ, также, как тысячи людей в мире прекрасно живут, будучи слепыми от рождения. Но если вы хотите видеть - куда вы вообще движетесь, осознанно принимать решения и самостоятельно оценивать полученные результаты - то без ТЗ тут не обойтись.
4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? - Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.
5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? - Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) - то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL - уже нет.
6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? - Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» - установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь - обязательно.
Общие положения. Это нужно для того, чтобы исполнитель понимал, что он делает. В общих положениях могут быть прописаны характеристики оборудования, на котором должна выполняться работа, разъяснения спорных моментов, глоссарий и т.п.
Второй пункт - это четко сформулированные цели, которых нужно достичь в процессе работы. Написание этого раздела поможет заказчику понять, чего он действительно хочет, а исполнителю - впоследствии предложить решения описанных проблем.
Третий пункт - это требования, которые заказчик предъявляет к выполнению задания. Без этого пункта не обходится ни одно техническое задание. В нем должно быть четко прописано, что именно, и в какой срок хочет получить заказчик. Не нужно думать, что опуская сроки выполнения задания вы даете "свободу" исполнителю. Работать в условиях неизвестности очень сложно.
Техническое задание не должно быть слишком расплывчатым - ведь исполнитель может понять его неверно или не так, как требуется заказчику. В то же время, техническое задание не должно быть слишком подробным - в любом проекте должно быть место творчеству. Кроме того, если вы досконально знаете, как должен выглядеть ваш сайт, журнал или прибор - что мешает сделать вам его самому?
Видео по теме
Источники:
Вы хотите создать собственный интернет-магазин, и прежде, чем обратиться в специализированную компанию, решили продумать техническое задание. Это вполне возможно сделать своими силами. Вот несколько советов на тему, из каких компонентов состоит техзадание.
Вам понадобится
Инструкция
Цели . Это очень важный раздел, посвятите его обдумыванию для того, чтобы четко сформулировать цели вашего ресурса. Например, если вы задумали создать интернет-магазин, объясните будущему исполнителю, с помощью чего вы собираетесь прибыль. Это поможет исполнителю предложить вам решения, которые смогут по максимуму претворить в жизнь поставленные вами цели.
Целевая аудитория. Опишите в этом разделе аудиторию, которую вы рассчитываете привлечь. Это может не только помочь с выбором сервисов, но и в разработке дизайна.
Функциональные требования. Требования принципиально можно разделить на функциональные и не функциональные/специальные. Функциональные требования лучше описать в виде примеров их использования.
Стандарты. Опишите стандарты возможностей использования, например стандарты серии WAI, удобства использования, например, ISO/TR 16982:2002, а также другие стандарты общего назначения.
Системные требования. Перечислите системные требования, какие операционные системы должны поддерживаться, требования к памяти. Также сюда могут войти требования по отказоустойчивости, например, возможность восстановления системы после сбоя.
Производительность. В данном разделе опишите, какое количество пользователей может одновременно работать на сайте, или в определенный отрезок времени. Также, стоит отметить, каким именно инструментом будет производиться определение производительности.
Безопасность. В данном разделе опишите необходимые методы шифрования данных, способы их передачи и хранения.
Пользовательский интерфейс. Опишите способ отображения элементов пользовательского интерфейса.
Видео по теме
Обратите внимание
Техническое задание обязательно должно быть детализированным. Между представлением (идеей) проекта и техзаданием очень большая разница.
Полезный совет
Перед началом работы с исполнителем оговорите терминологию – иначе, вы можете одним и тем же словом называть разные вещи. Подобная несогласованность может привести к путанице и повредить работе над проектом.
Источники:
Ни одна работа или проект, выполняемые по заказу, не могут производиться без технического задания на данные конкретные разработки. В этом документе заказчик ставит перед исполнителем задачи по созданию или разработке продукта и указывает технические характеристики, которым должен соответствовать продукт, порядок и сроки выполнения данной работы. Любое техническое задание, независимо от предмета разработки, должно иметь общие компоненты или подразделы.
Инструкция
В структуру обязательно включите раздел «Общие положения». В них оговорите используемые в техническом задании и дайте их смысловую расшифровку – приведите глоссарий. Это позволит исполнителю и заказчику разговаривать на одном и исключит двоякое толкование основных понятий и определений.
Включите в техническое задание раздел «Цели », в котором четко сформулируйте цели и задачи проекта. Грамотно изложенные цели проекта помогут исполнителю понять, что именно требуется Заказчику и выбрать те пути и методы решения поставленной задачи, которые приведут к поиску самого оптимального решения.
Изложите функциональные к разработке. Здесь же можно отразить и специальные требования. Функциональные требования целесообразно изложить в виде вариантов использования или применения результатов данного проекта. В специальных требованиях укажите стандарты, которым должна соответствовать разработка, требования по отказоустойчивости, производительности или безопасности. Если речь идет о программном продукте, укажите системные требования, и требования к пользовательскому интерфейсу.
В разделе «Допущения и ограничения», который, обычно, заполняется исполнителем, оговариваются конечные параметры и характеристики, что позволяет не увеличивать стоимость работ по проектированию до бесконечности и довести его до логического завершения. В этом разделе перечислите функциональные возможности и задачи, которые выходят за рамки проекта, технические ограничения, зависимости от непредсказуемых обстоятельств и внешних условий, которые могут изменить принятые обязательства.
В разделе «Риски» отразите факторы, которые могут повлиять на сроки исполнения работы или ее стоимость.
Видео по теме
Если в рабочей деятельности вам часто приходится иметь дело со сторонними специалистами или поручать выполнение заданий другим сотрудникам, то для успеха дела вам необходимо научиться грамотно составлять техническое задание. Конечно, в каждой сфере могут быть свои особенности, но существуют общие рекомендации для составления технического задания.
Инструкция
Написание ТЗ – начало любого , ведь результат напрямую зависит от поставленных целей. Техническое может быть как основным документом, регламентирующим отношения между заказчиком и подрядчиком, так и приложением к . В любом случае, максимально подробно опишите, что вы хотите получить в результате выполнения работы. Это может быть цель, продукция, услуга, задача. Напишите, какие задачи решает или выполняет заказываемый продукт.
Чтобы представление о достигаемой цели заказчика совпадало с видением исполнителя, необходимо детально, буквально по пунктам, описать ход выполнения работ. Указывайте все, что считаете важным и необходимым для понимания процесса. Избегайте двусмысленностей и неоднозначных трактовок. Для обеих сторон перечень и ход работ должен быть ясным и понятным.
Пропишите исходные материалы, которые потребуются для выполнения работы, их формат, а также каким образом и в какие сроки эти «исходники» будут переданы исполнителю. Все эти данные необходимо прописать до подписания , чтобы проект «не буксовал» из-за нехватки нужных материалов со стороны заказчика.
Обозначьте четкие сроки выполнения заданий. Это необходимо для того, чтобы обе стороны могли планировать свою деятельность, согласно своим возможностям и ожиданиям второй стороны. При написании технического задания держите в уме некий запас времени, ведь в процессе выполнения сроки могут сдвинуться из-за дополнительных согласований или обсуждений.
Важно в процессе составления ТЗ указать пожелания заказчика, особо понравившиеся примеры подобных работ, дополнительные требования, маркетинговую информацию или данные проведенного исследования. Исполнитель или разработчик будет четче понимать поставленные перед ним задачи, что приведет обе стороны к совместному успеху.
Видео по теме
Обратите внимание
Помните, при выполнении всех требований и задач, указанных в ТЗ, исполнитель вправе считать проект законченным. Во избежание споров и разногласий по срокам, видам и качеству работ или услуг, как можно подробнее излагайте информацию.
Полезный совет
В творческих проектах целесообразно давать исполнителю простор для фантазии и креатива. Для продуктивной работы избегайте жестких рамок и приветствуйте появление новых идей.
Источники:
Архитектурное проектирование – важный этап любого строительства, в том числе и ремонта жилой квартиры. Если вы хотите, чтобы работа архитектора максимально соответствовала ожидаемым и желаемым результатам, уделите время грамотному и вдумчивому составлению проектного задания, которое должно включать полный список требований к архитектору и его работе.
Инструкция
Перепланировка может включать в себя снос некоторых стен, не являющихся несущими, изменение размеров и формы жилых комнат, а также изменение местоположения дверей, замена электропроводки, газового оборудования, и других подобных параметров. Если же вы хотите поменять функциональное помещений, поменяв местами , вам придется легализовать не перепланировку, а реконструкцию.
Когда разрешение на перепланировку будет получено, договор с надежным и сертифицированным архитектором. В некоторых случаях архитектурная фирма за дополнительную плату может провести все необходимые действия по легализации и утверждению перепланировки в квартире самостоятельно, сэкономив ваше время.
В любом случае, согласовать проект необходимо своевременно – в противном случае в будущем, при различных операциях с недвижимостью, вы столкнетесь с проблемой, вызванной незаконной перепланировкой, не согласованной с БТИ. Кроме того, при незаконной перепланировке вы рискуете нарушить определенные строительные нормы – в том числе, нормы пожарной безопасности.
В задание для будущего проекта должны быть включены все нюансы, которые вы хотите видеть в ремонте, а также важные параметры, касающиеся вашего помещения – жилая площадь, электроснабжение и размещение розеток и выключателей, система освещения, которую вы хотите получить, наличие телевидения и радио, стилизация интерьера, его концепция и желаемые элементы, цветовая гамма оформления квартиры, предпочтения по мебели и аксессуарам, и так далее. Чем больше пунктов будет указано в задании, и чем подробнее оно будет составлено, тем более полученный интерьер будет соответствовать вашим ожиданиям.
Написание и оформление технического задания своими силами может стать необходимостью в том случае, если требуется создать некий продукт, а бюджет не очень большой. Еще одной причиной написания технического задания (ТЗ) может стать желание предварительно изучить заказ, который вы собираетесь сделать компании-разработчику. Например, требуется создать сайт, и вы хотите для себя прояснить все пункты, на основе которых его будет конструировать фирма-исполнитель.
Инструкция
Сначала составьте полный список составляющих технического задания, и начинайте его заполнять – так будет проще свести воедино все важные пункты и не пропустить ни одного.
Начинается оформление ТЗ с наименования Заказчика. Внесите в этот пункт полную информацию о фирме.
Затем внесите полные данные о компании-Исполнителе.
Следующий пункт очень важен: укажите четкие сроки выполнения заказа - дату начала и дату его завершения.
Затем укажите, каков бюджет проекта, его смета.
После этого распишите техническую сторону сайта. Если у вас есть познания в программировании это сделать будет достаточно просто, если нет – распишите основные параметры, а об остальных посоветуйтесь со специалистами компании – Исполнителя. Затронем некоторые из них.
Цели сайта. От этого будет зависеть дальнейшая разработка структуры, сервисы и услуги сайта.
На какую аудиторию он рассчитан. В этом пункте опишите, какого рода посетителей вы хотите привлечь на свой ресурс – возрастную категорию, социальный статус, финансовый порог. Это повлияет на дизайн ресурса и его сервисы. Например, если вы открываете интернет-магазин, это поможет определиться с порядком расчетов за приобретенный товар.
Функциональные и специальные требования. Функциональные удобнее привести в виде примеров того, как их будут использовать, а специальные оформить списком – это могут быть возможности подписки, специальных рассылок и др.
Стандарты. Этот пункт лучше обсудить с исполнителем или продвинутым другом-программистом.
Системные требования. Сюда войдут сведения о том, к каким операционным системам ваш сайт должен быть дружественным, насколько велики будут ресурсы его памяти, учесть возможность быстрого восстановления после сбоев.
Производительность. Этот пункт о том, сколько посетителей одновременно сможет принять ваш сайт и каким образом их будут «пересчитывать».
Безопасность. Очень важный раздел. Опишите, как потребуется шифровать данные, как они будут передаваться и храниться.
Полезный совет
Техническое задание обязательно должно расписано очень подробно. Иначе это будет не ТЗ, а просто описание общей идеи.
Источники:
Техническое задание - ключевой документ в процессе разработки программного обеспечения. Корректное ТЗ позволяет избежать множества ошибок и лишней работы. Состав его может меняться в зависимости от задачи, однако можно выделить универсальные компоненты.
Инструкция
Общие положенияВводный раздел, в котором определите основные положения, опишите используемую терминологию, он необходим для того, чтобы заказчик и не испытывали трудностей в понимании технического задания. Укажите информацию о заказчике и исполнителе, опишите документы, на основании которых принято решение о разработке программы.
ЦелиВ этом разделе укажите основные задачи, на выполнение которых направлен проект. Важно четко определить цели, которые реализует разрабатываемый продукт. Опишите предполагаемую аудиторию, которая будет работать с программой.
Функциональные требованияОсновной компонент технического задания. В этом разделе опишите функционал разрабатываемого программного обеспечения, варианты его использования, пользовательский интерфейс. Опишите структуру программы в функциональных требованиях.
Специальные требованияПеречислите все специальные требования и стандарты. Укажите технические требования: версию операционной системы, объем памяти и т.д. Требования по производительности, требования к защите информации от несанкционированного доступа, отказоустойчивости, надежности, эргономике опишите в этом разделе.
Видео по теме
Полезный совет
Избегайте избыточной и недостаточной детализации технического задания. Слишком подробные требования могут привести к отсутствию гибкости системы - внести какие-либо доработки будет очень сложно. Недостаточная детализация технического задания приведет к ряду ошибок, а так же к большому количеству лишней работы.
Будьте предельно внимательны при составлении технического задания - в дальнейшем это поможет решить спорные моменты с заказчиком.
Техническое задание, или ТЗ, – это документ, подробно описывающий все пожелания и требования заказчика к проекту. Составление его позволяет избежать недомолвок и разногласий в процессе взаимодействия клиента и исполнителя. Кроме того, нередко грамотно составленное ТЗ сокращает сроки, необходимые для выполнения задачи.
Создание технического задания выступает одним из первых и чрезвычайно важных этапов большинства проектов. Четкое и правильно составленное техзадание (ТЗ) позволяет внести ясность в отношения заказчика и исполнителя, сформулировать требования к характеристикам будущего объекта, а также становится основанием для проверки выполненной работы.
Общее определение этого термина выглядит следующим образом: техническое задание - это специальный документ, разработанный заказчиком и утвержденный исполнителем, в котором изложены требования, параметры и основные эксплуатационные характеристики проекта, объекта или системы.
Кроме прочего, в состав этого документа может входить список требований, касающихся тестирования (применимо к разработке программного обеспечения).
Его применяют в своей работе строители, мастера, выполняющие ремонтные работы, программисты, дизайнеры и многие другие специалисты.
Техническое задание - это документ, который разрабатывается профессионалом, хорошо разбирающимся в специфике конкретного вида работ. От того, насколько подробно будут описаны ожидания заказчика, зависит успех всего мероприятия. Другими словами, техническое задание - это инструкция для работников, которая позволяет сопоставить конечный результат с запланированным.
Нередко сам процесс составления инструкции позволяет заказчику понять, каким он хотел бы видеть выполненный проект. Это связано с тем, что необходимость постановки конкретных целей стимулирует его к изучению возможностей и ограничений, присущих данному типу деятельности. Многие заказчики, осознавая недостаток информации, незнание профессиональных терминов и отсутствие специальных знаний, предпочитают нанять специалиста для разработки технического задания.
Как ни парадоксально, но такой подход позволяет достичь максимально слаженной работы, ведь каждый выполняет то, что хорошо умеет: заказчик знает, что хочет получить в итоге, автор технического задания переводит эти сведения в понятные исполнителю данные, а мастер имеет возможность работать по четкой инструкции.
Эта задание, выполняет важную функцию: она помогает разрешить возможные спорные ситуации. Будучи изложенными в письменном виде, требования к проекту или объему работ становятся ориентиром для обеих сторон. Исполнитель имеет право не выполнять ту работу, которая не указана в техническом задании. Для дополнительных действий необходима новая инструкция.
Вместе с тем заказчик защищен от неполного или неправильного выполнения задания, так как может проверить его характеристики и параметры по каждому отдельному пункту ТЗ.
Как правило, готовый продукт проходит этап проверки, тестирования или испытания. Если его характеристики отличаются от запланированных, он может быть отправлен на доработку или исполнителю может быть отказано в оплате (это оговаривается, когда составляют техническое задание работы).
Все требования, указанные в техническом задании, можно классифицировать по видам и свойствам.
Образцом требований различных видов становится большинство ГОСТов. Они регулируют процесс составления ТЗ для строительства крупных объектов и других ответственных работ. В них обычно перечисляют такие требования:
Список требований, сгруппированных по видам, довольно длинный, их разнообразие обусловлено различными целями проектов.
Чаще всего требования, касающиеся функциональности, выступают ядром, вокруг которого разрабатывается каждое техническое задание. Система остальных технических условий и инструкций становится своеобразным «камуфляжем», надетым на эти требования. При неудачной формулировке основного задания, даже самый лучший «камуфляж» не спасет положение, и проект будет провален.
В отличие от многочисленных видов требований, свойств для их характеристики намного меньше:
Последнее свойство не может быть отделено от первых двух, так как понятные и конкретные требования могут быть воплощены и протестированы. Однако если нет никакого способа проверить результат, то можно утверждать, что требования не обладают одним из двух первых свойств.
Существует много мнений о том, какая степень детализации должна быть использована при разработке техзадания.
Иногда его составляют с использованием специфических терминов и большим количеством нюансов, понятных только специалистам. Недостатком такого подхода становится то, что заказчик, утверждая данное ТЗ, не вполне понимает, что получит в качестве готового продукта. Поэтому процесс тестирования, проверки и приема работы может затягиваться, а проект многократно отправляется на доработку и усовершенствования.
Сторонники другого метода настаивают на том, что проект технического задания должен быть максимально простым и понятным. Этот документ может включать отраслевую терминологию, понятную заказчику, но указания технических аспектов, связанных с реализацией проекта, допускать не стоит. В сфере разработки программного обеспечения адаптацией требований заказчика в пункты техзадания занимается бизнес-аналитик, но не программист (конечно, если он не выполняет обязанности и того, и другого).
Техническим проектом называется документация, в которой подробно описан порядок реализации пунктов ТЗ. Вот здесь термины, аббревиатуры и профессиональные понятия просто необходимы. Их не видит заказчик (эти слова ему могут ни о чем не говорить), текст читает мастер, который будет заниматься проектом, и ему необходимы точные и конкретные данные: размеры, параметры, качества, характеристики. составляет архитектор системы.
Чтобы облегчить составление и выполнение технического задания, его разрабатывают по определенной системе.
Как правило, вначале, в вводной части, излагают цель и назначение проекта. Далее следует перечисление разделов, требований и их расшифровка. Чтобы понять, как выглядит ТЗ для автоматизированной системы, можно рассмотреть структуру, рекомендуемую ГОСТом 34.602-89:
Такое техническое задание (образец которого содержит развернутое описание всех пунктов) охватывает большинство аспектов проекта, но при необходимости может быть дополнено уточняющими пунктами.
Процесс капитального ремонта внутренних помещений - дело не такое простое, как может показаться на первый взгляд. Это не только смена обоев и покраска батарей, речь идет об исправлении нарушенной геометрии, устранении архитектурных недостатков, внесение коррективов в планировку, оснащение и усовершенствование комнат.
По этой причине техническое задание на ремонт становится одним из важнейших этапов, так как позволяет:
Как и в примере с техзаданием для автоматизации систем, посредник между заказчиком и мастерами-исполнителями составляет техническое задание. Проведение мероприятий по воплощению запланированных работ осуществляется на основании технического проекта, он разрабатывается по пунктам ТЗ.
Для ремонта каждого помещения составляется уникальное техническое задание. Образец наиболее распространенной структуры этого документа приведен далее.
1. Название и назначение комнаты. Это необходимо, так как специфика помещения требует соблюдения определенных правил при его оформлении (гостиная, спальня, кабинет).
2. Характеристика пола: объем работ, которые нужно выполнить на этом участке. Здесь можно подробно указать, что именно необходимо выполнить мастерам:
3. Работы с потолком:
4. Что требуется проделать со стенами:
5. Параметры окна:
6. Характеристики двери:
7. Работы с электрическими сетями:
8. Мероприятия по монтажу отопительных систем и кондиционеров:
Все специалисты сходятся во мнении о том, что обследование комнаты является обязательным этапом при составлении ТЗ для ее ремонта. При этом процедура должна проводиться не только до разработки техзадания, но и в процессе составления.
Главной задачей этого мероприятия становится получение информации о состоянии помещения и более точного описания предстоящих ремонтных работ.
При обследовании комнаты обращают внимание на главные параметры и выполняют следующие действия:
Чтобы избежать неопределенности и предусмотреть все возможные нюансы, при обследовании пол разбирают в нескольких местах и делают выводы из увиденного.
Полученные в результате обследования данные сопоставляют с проектом, типом финишных материалов и подготовительными работами, которые необходимы для их монтажа.
Эта информация позволяет оценить уровень трудовых и финансовых затрат. Техзадание должно содержать чертежы будущих работ.
Изложенный работы по ремонту комнаты не является типовым. В зависимости от объема работ, он может выглядеть совершенно по-другому, быть короче или включать более подробные данные.
