Оформление по ТЗ что это?

Как оформляется техническое задание на проектирование

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

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

Что это

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

Суть и понятие ТЗ заключается в следующем:

• Определение четких критериев выполнения работ по целям, задачам, срокам, результатам и т.д. Благодаря этому можно на любом этапе работ определить ошибки и устранить недочеты;
• Регулирование ответственности сторон, т.к. документ согласован и обоюдно принят. Иногда каждый этап работ согласовывается отдельно, чтобы в результате ошибок была четко определена степень вины каждой стороны, и в соответствии с этим распределены суммы убытков;
• Составляется на основе четких расчетов и научных исследований, поэтому практически исключает «провальность» мероприятий;
• Пишется в доступной форме, без использования сложной профессиональной терминологии, что делает его понятным простому обывателю. Это очень важный пункт, потому что несоблюдение определенных норм из-за недостатка информации, может повлечь санкции со стороны надзорных органов, ведь «незнание не освобождает от ответственности».

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

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

Со стороны заказчика:

• Понять, как действовать на основе имеющихся ресурсов и технических знаний;
• Требовать четкого исполнения всех пунктов документа от исполнителя.

Со стороны исполнителя:

• Спроектировать технический макет будущего объекта;
• Разработать план последовательности действий;
• Не принять предложение вовсе или отказаться от тех работ, которые не указаны в ТЗ или их невозможно выполнить.

С обеих сторон:

• Сократить количество неточностей и ошибок;
• Прийти к общему виду готового объекта;
• Совершить согласование работ после каждого пункта.

Структура и как правильно составить

Примерная форма технического задания на проектирование

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

• Список документов, необходимых для работы и изучения обеими сторонами;
• Технические параметры объекта, потребительские свойства и необходимость создания;
• Экономические данные;
• Порядок приемки работ и сдачи всего заказа.

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

Структура и состав документа будут утверждаться на основе типа проектируемой продукции. Но, в общем, ТЗ должно содержать следующую информацию:

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

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

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

Образец формы

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

№	Перечень требований и основных данных	Описание
1.	Основа для создания и проектирования	Целевая программа на федеральном уровне Программа субъектов РФПрограмма муниципалитетовСоздание по решению Президента РФ, правительства РФ и других уполномоченных органовПо инициативе компании-застройщика
2.	Разновидность постройки	Новое строение РеконструируемоеПредназначенное для капитального ремонта или текущего
3.	Этапы проектирования	Здесь перечисляются стадии работ  по проектированию: создание проектатребуемая документациярабочий макетэскизный макет и т.д.
4.	Рассматриваемые варианты работ	Прописывается информация о работах для сравнения или проводимых конкурсах по выбору проектных решений
5.	Финансовые источники	Средства из федерального бюджета РегиональногоМуниципальногоВнебюджетные средства
6.	Условия работ, требующие особого внимания	Описать такие условия или дать рекомендации по их преодолению
7.	Технические параметры объекта	Предоставляется подробная информация о возможностях здания, назначения, технических характеристиках (этажность, кол-во подъездов) и т.д. Все что требуется для понимания социально- экономической значимости
8.	Данные по встроенным помещениям	Если площади жилых домов планируется частично отдать под общественные или другие организации, то этот пункт нужно заполнить
9.	Качественные показатели здания, говорящие об экологической безопасности, конкурентоспособности и целесообразности	Здесь указываются все данные о постройке технически значимых объектов производства, размещения его отдельных блоков, технологии их постройки, расстановки оборудования
10.	Требования по используемым материалам и правильным размещениям площадей разного назначения сооружения	Прописываются данные по правильному размещению отдельно взятых площадей, а также описывается материал работ, который более эффективен в том или ином участке
11.	Требования по архитектурно- культурным работам	Описывается планируемые работы по благоустройству прилежащих территорий
12.	Требования инженерно- технического плана	Описать системы вентиляции, канализации, водопровода и пр.
13.	Требования по стадийному вводу в эксплуатацию объекта	Указывается информация по каждому объекту комплекса, его отдельных частей. Необходима информация по срокам, условиям сдачи и вводу в эксплуатацию
14.	Требования по разработке природоохранных мер	Здесь описывается влияние объекта постройки на экологическую обстановку и окружающую среду
15.	Требования по предоставлению условий для отдельных групп граждан	Данные по элементам конструкций, предназначенных для инвалидов, стариков и детей.
16.	Требования по безопасности и охране труда	Расписываются материалы по теме охраны труда и здоровья работников будущего строения. Подходит для зданий промышленного назначения.
17.	Требования по санитарно- эпидемиологическим нормам	Описать документы для проверяющих организаций: Роспотребнадзор, СЭС и т.д.
18.	Требования по противопожарной безопасности	Описание соответствия номам пожарной безопасности
19.	Требования по материалам для демонстрации	Заполняется в случае использования 3D макетов и презентаций
20.	Дополнительные требования	Специальные требования, внесенные самим заказчиком по необходимости, но в рамках существующих норм

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

Источник: http://MirBlankov.ru/tz-na-proektirovanie/

Как составить техзадание и донести суть задачи исполнителю

Распространено заблуждение, что если человек обладает большой базой знаний о чем-либо (SEO, PPC, программирование и так далее), он способен написать хорошее техническое задание. Опыт свидетельствует о другом: знания и опыт специалиста при составлении техзадания значения не имеют.

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

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

Каждая задача — решение вопроса

Не знаете, какую проблему решаете — техзадание будет наполнено противоречивой информацией.

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

Проработайте техзадание так, чтобы минимизировать появление этих сложностей. Думайте о том, что произойдет после выполнения задачи.

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

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

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

Разработка смысловых блоков

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

Например, SEO-специалисту часто приходится писать техническое задание для формирования фильтров интернет-магазинов. Это сложно: нужно создать страницы с контентом и UTM-метками, учесть, как эти страницы будут оптимизированы.

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

1. Вводная часть. Общее описание и оглавление. Что нужно будет сделать.2. Внешний вид фильтров. Как фильтры должны выглядеть в дизайне сайта.3. Требования к страницам. 3.1. Подробное описание принципов формирования URL. 3.2. Требования к страницам фильтров.

В частности, следует написать о предоставлении возможности редактирования тегов, метатегов, публикации текстов и внедрении атрибута canonical.4. Формирование метатегов. Детальное описание алгоритма, по которому нужно формировать метатеги с учетом последовательности выбора фильтров.5. Рекомендации по размещению текстов на страницах фильтров.6.

Скрытие прямых URL для фильтров четвертого уровня вложенности и выше.

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

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

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

Требования к тексту и оформлению

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

В тексте не должно быть вводных слов, метафор и отступлений от темы. Всё четко и по делу.

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

Не должно быть специфических терминов и сокращений без расшифровки.

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

Если возникает сомнение, что исполнитель может истрактовать вашу мысль по-своему, добавьте максимально подробные примеры и иллюстрации.

Ранее мы уже рассказали, как сделать красивый скриншот.

Для проектирования примеров интерфейсов можно использовать сервис Moqups.

Вставляйте скриншоты и макеты в техзадание в виде картинок, а не ссылок на картинки.

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

Выводы

1. Перед постановкой технического задания заполните таблицу с двумя столбцами: «какую проблему я хочу решить», «как ее можно решить».
2. Разбейте текст техзадания на смысловые блоки.
3. При написании текста убирайте всю «воду».
4. Внедряйте как можно больше иллюстраций и примеров.

Как только вы составили техзадание, обязательно спросите себя: «Всё ли в нём будет понятно исполнителю?».

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

Источник: https://netpeak.net/ru/blog/kak-sostavit-tekhzadanie-i-donesti-sut-ispolnitelyu

10 заповедей технического задания (с толкованием)

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

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

Форматы ТЗ перерабатывались, перерабатываются и будут перерабатываться. Формулировки переписываются, какие-то разделы вымарываются, новые добавляются. Толщина документа непостоянна, как ветер мая.

А потому, когда меня в один момент попросили прочитать доклад о техническом задании для сотрудников агентства, я растерялся. А про что читать? Рассказывать незаконченную историю становления технического задания? Разъяснить текущий формат, который к вечеру я захочу подправить?

Пройди интенсивную программу профессиональной переподготовки в области проектного менеджмента, чтобы сделать эффективными:

• Себя.
• Свою команду.
• Любой проект.

Уже через пару месяцев онлайн-обучения про тебя будут говорить: «Воу, этот человек действительно шарит в управлении проектами».

Реклама

Из этих вопросов и родились «10 заповедей о техническом задании». Я посмотрел на ТЗ не как на документ (артефакт), а как на часть процесса производства, и все стало ясно.

1. ТЗ — обязательный документ при создании любого продукта

Миф о том, что для простых проектов ТЗ не нужно, не выдерживает критики. Нужно! И для простого, и для сложного. Просто для простых проектов пишите простое ТЗ, а для сложных — сложное, если вы верите, что для ТЗ такая градация существует в принципе.

2. ТЗ описывает продукт, но не проект

ТЗ должно отвечать на вопрос «Что делаем?», но не «Как делаем?».

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

3. ТЗ не является договором

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

4. ТЗ описывает не только функциональные требования, но и интерфейс

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

5. ТЗ составляет только обладающий соответствующей компетенцией специалист

Звучит просто, а реализуется сложно.

Я не верю в клиентские ТЗ. Я не верю в ТЗ, которые пишут менеджеры. Кто же его пишет?

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

6. ТЗ разрабатывается после этапа дизайна, но до начала верстки

Подробно я об этом уже писал на Cossa. Коротко. Если делать ТЗ до дизайна, то устанете вносить изменения в этот документ, и потратите кучу сил/денег/времени/сотрудников/заказчиков. Поэтому мы в qb.

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

Тут же возникает резонный вопрос: «А по чему рисуется дизайн?». Отвечаем: по концептуальному описанию, функциональному описанию и прототипам.

7. ТЗ не терпит правок после его утверждения

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

8. ТЗ может править только его автор или обладающий компетенцией специалист

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

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

9. ТЗ должно описывать, как минимум, текущую версию продукта

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

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

И когда возникнет вопрос «А как это работает?» (а он, поверьте, возникнет), то ответить на него не сможет никто.

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

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

Я видел много проектов, которые превращались в ад только потому, что кто-то или не читал ТЗ, или читал его невнимательно, или читал, но не понял.Добивайтесь чёткого понимания ТЗ у себя любыми силами.

В нашей компании мы проводим две презентации документации (про формат могу отдельно рассказать, если интересно) — внутреннюю для команды проекта и внешнюю для заказчика.

Источник: https://www.cossa.ru/234/125799/

Почему без ТЗ – ХЗ | ТЗ на разработку сайта

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

Зачем и кому нужно техническое задание?

Действительно, зачем? Требования клиента услышаны и записаны. Встреча заканчивается одобрительными кивками с улыбками на лице. Гармония. Полное понимание. После составления сметы и озвучивания конечного бюджета проекта.

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

Используя все свое дипломатическое искусство, пытается объяснить, что входит, а что не входит в обязанности компании и почему получились такие цифры. Напряжение нарастает.

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

Обычно digital-агентство пишет техническое задание до начала разработки ресурса. Подтвержденное на первом этапе техническое задание, по ходу работы может корректироваться. Как правило, в нем прорабатываются важные моменты, формируется единое видение проекта заказчика и веб-студии.

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

Из чего стоит техническое задание на разработку сайта

Каким же образом решает разногласия техническое задание, что в нем такого особенного написано? Давайте разберем по пунктам.

Начнем с небольшого экскурса в историю. В далеком 1978 году, советские умы, создали и написали ГОСТ 19.201-78 ТЗ на программное обеспечение, через 9 лет появился еще один любопытный документ ГОСТ 34.602-89 ТЗ на автоматизированную систему. И внимание.

До сих пор эти ГОСТы никто не отменял, и во многом написанные сейчас технические задания схожи с тем, что предлагают эти документы. Более чем двадцатипятилетний период, разделяющий современных разработчиков и авторов документов, конечно, внес свои коррективы. Но для выполнения государственных заказов некоторые компании до сих пор пользуются ГОСТОМ 34.

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

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

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

Крепкая основа понимания заказчика и исполнителя. Важно объяснять не все узкоспециализированные термины, а именно те, которые используются в работе.

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

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

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

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

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

На составление одного технического задания для проекта в среднем тратится от 2 до 4 рабочих дней. Нередко дополнительно привлекается веб-аналитик, который делает техническое задание более полным.

Оформление ТЗ

Допустим, необходимая информация собрана. Осталось ее оформить и преподнести заказчику. Лучше это сделать при личной встрече, предварительно отправив документ заказчику для ознакомления.

Заказчик вносит правки в документ и утверждает его. Как правило, после этого стадия предпроекта завершается, и web-студия приступает к работе.

При возникновении дополнительных работ, компания-разработчик сообщает об этом компании-заказчику, поясняя причину возникших доработок.

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

Мы никогда не разрабатываем сайтов без технических заданий. Наши сайты работают и соответствуют требованиям заказчиков.

Наши проекты

Источник: https://machineheads.ru/blog/pochemu-bez-tz-khz-/

Как правильно составить техническое задание: пошаговый алгоритм

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

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

Многие игнорируют факт написания детального технического задания, что в последствии приводит к недопонимаю, спорам, конфликтам и ссорам.

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

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

Также я расскажу, почему заказчику и исполнителю желательно не работать на добром слове, а все оформлять документально.

Для чего ТЗ заказчику?

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

Техническое задание – это документ, по которому вы будете принимать выполненную работу. И если что-то сделано не так, что-то не доработано, что-то выполнено не в полном объеме, то вы всегда можете указать на пункт из технического задания, и обосновать свою претензию о доработке сданного проекта.

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

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

Для чего ТЗ исполнителю?

В первую очередь, это ваш ориентир на то, что нужно сделать. Часто заказчики что-то додумывают в процессе разработки, стараясь навязать Вам выполнение лишних задач. Вы хотите работать бесплатно? Уверен, что нет. Уточняйте, что сумма, оговорена в самом начале, касалась исключительно объема работ указанного в техническом задании. Все что более – оплачивается отдельно.

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

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

С чего начать составление грамотного технического задания

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

• Общие положения технического задания

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

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

Чтоб не получилось путаницы, сразу расставьте все на свои места.

Рекомендуем прочитать: «Что такое вендинговый бизнес и как его начать?»

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

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

Даже если исполнитель работает над малой частью проекта, то он должен полностью понимать его структуру, задачи, цели, технические решения.

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

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

• Функциональные требования

Все требования к заказчику можно разделить на два типа: функциональные и специальные. Функциональные требование – это те варианты исполнения, которые вы хотите видеть у себя.

Если говорить на примере интернет сайта, то вы должны предоставить исполнителю примеры функциональных решений с других проектов, которые Вам нравятся, и которые вы хотите видеть у себя.

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

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

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

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

Также должен быть отчет по факту выполненных работ. Что было сделано, сколько на это потрачено времени, с какими трудностями столкнулся исполнитель и т.д.

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

Как составить техническое задание: советы из личного опыта

И в конце это статьи, хотелось бы дать несколько советов исходя из собственного опыта составления и получения технических заданий.

1. Техническое задание должно быть детальное. Не бойтесь описывать каждый элемент, каждый пункт, каждую кнопку. Все-все-все максимально детально пишите. Не бойтесь показаться дотошным. Уж лучше что-то несколько раз повторить и разжевать, нежели потом доделывать, доплачивать, дорабатывать. Последнее техническое задание, которое я писал, касалось разработки сайта. Это был большой информационный проект. Сначала разработали дизайн, а потом на его основе описывал функциональное задание для программистов. Так вот, все ТЗ получилось на 54 страницы А4 11 шрифтом. Техническое задание шло как дополнение к основному договору, который тоже был на 7 страниц. Но хочу сказать, что даже в таком детальном ТЗ не все смог учесть, ведь в процессе разработки подписывали еще три дополнительных соглашения, которыми я вносил определенные корректировки в первоначальный вариант задания.
2. Техническое задание должно быть четкое. Не нужно никакой воды. Все по делу. Если пишите о срока, то конкретную цифру, если о функционале, то перечень нужных вам функциональных решений и т.д.
3. Ваше техническое задание – это не догма, а лишь один из возможных вариантов исполнения задач. Скажу честно, я не специалист в программировании. Да, я могу продумать структуру проекта, его функционал, какие-то технические решения, но всегда, составляя окончательный вариант ТЗ, советуюсь с исполнителями. Они могут что-то увидеть, высказать свое мнение, подсказать оптимальное решение исполнение.

Вот, пожалуй, и все, что я хотел рассказать в этой статье. Составить техническое задание не так уж и сложно, если четко понимать чего вы хотите от исполнителя. Можете еще раз перечитать мои советы, и применить их к конкретно вашему случаю. Удачи!

ПОДПИСАТЬСЯ НА НАШ КАНАЛ 

ПОДПИСАТЬСЯ НА НАШ VIULY КАНАЛ 

Тут дают 10 токенов VIU за подтвержденую регистрацию

Вступить в закрытый  Телеграм Чат

С уважением проект Анатомия Бизнеса

Рубрики:

Май 28, 2014 3:02 дп

Если Вам понравился опубликованный материал – поделитесь им с Вашими друзьями:

Источник: http://biz-anatomy.ru/vse-stati/poznavatelno/kak-pravilno-sostavit-texnicheskoe-zadanie-poshagovyj-algoritm

Что такое ТЗ и что нужно учесть в техническом задании

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

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

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

На основании ТЗ принимаются или отклоняются претензии Заказчика к качеству работы Исполнителя, оплачивается готовая работа, оформляется акт приема-передачи.

bikeriderlondon / Shutterstock.com

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

В настоящем документе приводится полный набор требований по реализации сайта.

Заказчик и Исполнитель соглашаются

Подпись Заказчика и Исполнителя в настоящем документе подтверждает их согласие с нижеследующими фактами и условиями:

1. Исполнитель подготовил и разработал настоящий документ, именуемый Техническое Задание (ТЗ), который содержит перечень требований к выполняемым работам.
2. Заказчик согласен со всеми положениями настоящего ТЗ.
3. После утверждения ТЗ все предыдущие договоренности теряют силу и действуют только пункты данного ТЗ.
4. Заказчик не вправе требовать от Исполнителя в рамках текущего Договора выполнения работ либо оказания услуг, прямо не описанных в настоящем ТЗ.
5. Исполнитель выполняет только работы, указанные в данном ТЗ.
6. Все что выходит за рамки пунктов данного ТЗ, Заказчиком оплачивается дополнительно, на основании утвержденных сторонами дополнений к данному ТЗ.
7. Исполнитель приступает к выполнению работ по ТЗ, после: письменного утверждения ТЗ, получения всей необходимой информации указанной в ТЗ, получения необходимых материалов заказчика и выполнения пунктов оплаты.
8. Заказчик берет на себя обязательства, по завершению принять работу в течении 3-5 рабочих дней, оплатить работы по данному ТЗ в указанные в нем сроки, в случае если работы выполнены в полном объеме и в соответствии с ТЗ.
9. Заказчик не вправе требовать от Исполнителя соблюдения каких-либо форматов и стандартов, если это не указано в настоящем ТЗ.
10. Все работы по созданию сайта ведется на собственном хостинге Исполнителя. После завершения всех работ, переносится на реальный сервер для тестирования.
11. По окончанию работ, Исполнитель предоставляет консультации по администрированию в течение 5 рабочих дней, но не более получаса в день. Дополнительное время оплачивается отдельно, согласно действующих тарифов Исполнителя.
12. Все неоднозначности, выявленные в настоящем ТЗ после его подписания, подлежат двухстороннему согласованию между Сторонами. В процессе согласования могут быть разработаны дополнительные требования, которые оформляются дополнительным соглашением к Договору и оцениваются соответствующим образом.
13. Положения данного документа являются обязательными для разработчиков после его утверждения в установленном порядке.
14. ТЗ является средством верификации выполненных работ.

Статья по теме:  Яндекс.Школа вебмастеров

Далее подробно описывается назначение сайта и механику его функционирования. Особое внимание надо уделить таким пунктам как:

Совместимость с браузерами

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

• Internet Explorer (версия 8 и выше);
• Mozilla Firefox (версия 3 и выше);
• Google Chrome  (версия 4 и выше);
• Opera (версия 10 и выше).

 Требования к компоновке страниц сайта

Текст должен быть читаем. Согласно статистике, минимальное экранное разрешение мониторов пользователей составляет 1024×768 пикселей. При таком разрешении все тексты на сайте должны выглядеть понятно и хорошо видны без использования горизонтальной полосы прокрутки. При разрешении, меньшем, чем 1024×768 появится горизонтальная полоса прокрутки.

Сайт также должен иметь ограничения и на максимальный размер, чтобы хорошо выглядеть на мониторах с высоким разрешением. Поэтому максимальная ширина сайта будет 1280×1024.

 Требования к изменению содержимого сайта

Для удаленного администрирования (добавления, редактирования и удаления текстовой и графической информации) может использоваться бесплатная система управления контентом сайта (CMS), например WordPress. Но можно использовать и UMI.

CMS (она более удобна пользователю для редактирования сайта, но сложнее для разработчика). Поэтому, если Заказчик пожелает использовать UMI.CMS, стоимость внедрения оговаривается отдельно, после утверждения дизайна.

Ориентировочно она будет дороже на 50% от стоимости программирования.

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

Резюме

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

Вплоть до того что написать как открывается картинка во всплывающем окне, в какой она будет рамочке и будет ли она открываться с каим-то дополнительным эффектом.

Так как очень часто заказчики, еще при создании сайта норовят вносить правки в текст, картинки и тому подобное, что собственно относится к совершенно другому этапу, который называется «Наполнение сайта» или «Обновление сайта».

Статья по теме:  Декларация !important в CSS

Но если кто-то не хочет заморачиваться с подобной технической документацией, а просто ему нужно в кратчайшие сроки (за 1 день!) получить готовый сайт, в стоимость которого входит хостинг с установленной системой управления сайтом, то вариант от, предлженный TotalCAN возможно будет самое то. У них создать сайт можно всего за 139 долларов!

Источник: https://fortress-design.com/chto-takoe-tz-i-chto-nuzhno-uchest-v-tehnicheskom-zadanii/