Примеры написания тех заданий для разработки по. Образцы технических заданий

• Recovery Mode

Данный текст был создан сугубо ради существования постоянной ссылки, которую бы сам автор, да и все вы - могли бы смело отправлять своим будущим заказчикам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «А надо ли мне ваше ТЗ и вообще что это?»

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

Проблема

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

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

Переводим на понятный язык

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

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

3) Как же вам понять, решает ли предложенная дизайн-концепция или интерактивный прототип, а то и готовый к употреблению сайт - вышеизложенную задачу бизнеса? Ничего не поделаешь, придется опять вернуться к определению: «определяет… ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет». То есть ТЗ без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия - быть не может. Бриф может, или прототип, или еще любая абсурдная бумажка, но только не ТехЗадание.

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

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

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

5) Каждое внесение правок в готовое ТЗ должно стоить денег. Нельзя бесплатно и бесконечно править «Конституцию вашего проекта» только потому, что одна из сторон передумала, не выспалась, внезапно решила сэкономить и т.д. Цена каждого изменения в ТЗ должна также четко прописываться заранее в соответствующей главе.

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

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

Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? - написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.

Контрольные вопросы

1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? - Да, даже несколько.

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

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

4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? - Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.

5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? - Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) - то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL - уже нет.

6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? - Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» - установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь - обязательно.

Доброго времени суток, уважаемые читатели. Работать над созданием сайта с заказчиком всегда трудно. Клиент, как правило, хочет либо «что-то крутое», либо «ничего необычного, пусть будет как у всех». Абстрактные понятия, согласитесь. Если это ваш первый заказ, то вы даже можете обрадоваться подобным словам: «Круто, мне дают свободу творчества, я могу сделать все что пожелаю». Скажу по опыту, ничего подобного!

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

План действий по работе с заказчиком

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

• Первое общение.

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

Постарайтесь каким-то образом мотивировать человека посмотреть информацию, чтобы он имел более четкое представление о том, что он хочет от вас.

• Подготовка и первый бриф.

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

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

• Составление и подписание технического задания.

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

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

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

• Разработка и прием.

После того как вы подписали все, можно приступать к реализации проекта.

Чего не должно быть в ТЗ, а что там быть обязано

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

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

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

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

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

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

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

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

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

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

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

Выглядит оно так:

1. Глоссарий
2. Общие положения
3. Предмет разработки
4. Назначение документа
5. Требования к графическому дизайну сайта
6. Требования к дизайну сайта
7. Порядок утверждения дизайн-концепции
8. Функциональные требования
9. Требования к представлению сайта
10. Требования к системе управления сайтом
11. Требования к разделению доступа
12. Требования к видам обеспечения
13. Требования к информационному обеспечению
14. Требования к программному обеспечению
15. Требования к техническому обеспечению
16. Требования к лингвистическому обеспечению
17. Требования к эргономике и технической эстетике
18. Требования к приемке-сдаче проекта
19. Требования к наполнению информацией
20. Требования к персоналу
21. Порядок предоставления дистрибутива
22. Порядок переноса сайта на технические средства заказчика

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

Глоссарий

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

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

Общие положения

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

Предмет разработки

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

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

Назначение документа

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

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

Требования к графическому дизайну сайта

Требования к дизайну сайта

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

Порядок утверждения дизайн-концепции

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

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

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

Будьте внимательны. Это важный пункт, в котором лучше написать больше. Например, у вас должен быть раздел «Похожие новости». Что вы будете делать: прописывать алгоритм, который будет вычислять какие статьи наиболее близки по теме, дадите список последних пяти статей, добавленных на сайт, или у автора текста будет возможность вставить ссылки в этот блок самостоятельно?

Требования к представлению сайта

1. Структура сайта: описываем какие категории (рубрики) будут на сайте.
2. Главная страница: лучше всего со схематической картинкой и описанием основных элементов.
3. Внутренние страницы: тоже что и в предыдущем пункте. Схема и описание внутренних страничек.

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

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

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

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

Требования к разделению доступа

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

Требования к видам обеспечения

Требования к информационному обеспечению

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

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

Вы обязуетесь выложить изображения только в формате gif или jpg, а страницы не будут превышать определенного веса. Кстати, отличный пункт. Потом, если заказчик выпучит глаза и скажет, что ему нужно что-то другое, можно показать этот пункт и сказать: «Ну вы же сами про вес подписали, ничего не знаю, все это невозможно!».

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

Требования к программному обеспечению

1. Тут речь идет о хостинге или серверах. Так как мой блог ориентирован на создателей, которые работают на Таймвебе (https://timeweb.ru ) – все очень просто. Если вы не из «наших», то нужно смотреть на технические характеристики. Например, кто-то очень умный делает крутой сайт, а потом пытается подключить его к хостингу, а технические характеристики настолько завышены, что ни один хостинг в России не справляется. Пункт нужный, но не для новичков в сфере разработки.
2. Здесь мы описываем будет ли портал иметь мобильную версию, адаптирован под портативные устройства или сможет открываться только через Google Chrome, а любые искривления в других браузерах нас вообще не волнуют.

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

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

Требования к эргономике и технической эстетике

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

Требования к приемке-сдаче проекта

Требования к наполнению информацией

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

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

Требования к персоналу

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

Порядок предоставления дистрибутива

Что вы отдадите заказчику, когда работа будет выполнена: логин, пароль, туда-сюда.

Набиваем цену технического задания

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

В этом документе должно впечатлять все! Если вы собираетесь переслать его для предварительного ознакомления по почте, то обязательно используется формат PDF. И клиенту вероятно не захочется мучить себя правками и о вас он будет думать, как о профессионале. Мелочь, а значительная. Для преобразования вордовского документа можно использовать сервис https://smallpdf.com/ru/ .

Не забудьте вставить фоном логотип собственной компании или вашего бренда, а также вставить контакты. Быстро и качественно их можно оформить на сайте https://logaster.ru .

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

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

СКАЧИВАЕМ ШАБЛОН ТЗ

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

Помните закон Мерфи? Если вас могут понять неправильно, вас обязательно поймут неправильно. Это справедливо не только в общении между людьми, но и в создании сайтов. Клиент хотел второй «Фейсбук», а получил форум юных собаководов. Разработчик не угадал хотелку заказчика - потратил время впустую.

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

Статья будет полезна:

• Всем, кто имеет отношение к созданию сайтов: разработчикам, дизайнерам, верстальщикам.
• Менеджерам проектов.
• Руководителям диджитал-студий.
• Предпринимателям, которые планируют заказать разработку сайта.

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

Что такое техзадание и зачем оно нужно

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

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

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

Польза для клиента:

• Понять, за что он платит деньги, и каким будет сайт. Можно сразу увидеть структуру, понять, что и как будет работать. Прикинуть, все ли устраивает. Если нет - без проблем поменять еще до начала разработки.
• Увидеть компетентность исполнителя. Если техзадание понятное и четкое - доверие к разработчику повышается. Если там написана каша - возможно, стоит бежать и не оглядываться.
• Застраховаться от недобросовестности исполнителя. Когда сайт готов, его можно проверить по техническому заданию. Есть несоответствия? Разработчик обязан их исправить. Если вы сотрудничаете официально и заключали договор - можно даже принудить через суд.
• Упростить замену исполнителей. Если клиент и разработчик повздорили и разбежались, создание сайта может сильно затянуться. Когда есть подробное техзадание, его можно передать новой команде - она втянется в работу в разы быстрее.
• Узнать стоимость разработки сложного продукта. Оценить точные сроки и стоимость разработки сложного веб-сервиса сходу нельзя. Сначала нужно понять, как будет работать сервис, и какие в нем будут функции. Для этого и нужно подготовить техзадание.

Польза для исполнителя:

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

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

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

Техзадание составляет исполнитель

Вообще техзадание может составить кто угодно. «Нужен сайт-визитка для стоматологической клиники» - это уже техзадание. Но будет ли оно выполнять свои функции? Вряд ли.

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

Это не значит, что клиент исчезает и появляется в самом конце, чтобы написать: «Збс, одобряю». Он тоже должен участвовать в процессе:

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

Пишите однозначно и точно

Этот совет вытекает из главной цели техзадания - «Убедиться, что клиент и исполнитель правильно поняли друг друга».

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

Посмотрите. Кто-то ведь посчитал этот дизайн красивым и разрешил использовать на своем сайте:

То же самое - с невнятными формулировками, которые ничего сами по себе не значат:

• Сайт должен понравиться заказчику. А если у него будет плохое настроение?
• Сайт должен быть удобным. Что это значит? Удобным для чего?
• Сайт должен выдерживать большие нагрузки. 10 тысяч посетителей? Или 10 миллионов?
• Качественный экспертный контент. Ну, вы поняли.

Проверяйте, нет ли в тексте неоднозначностей. Если есть - перепишите. Ваши формулировки должны быть четкими и точными:

• Сайт должен загружаться быстро → Любая страница сайта должна иметь больше 80 баллов в Google PageSpeed Insights.
• Большие нагрузки → 50 тысяч посетителей одновременно.
• На главной странице выводится список статей → На главной странице выводится список последних 6 опубликованных статей.
• Минималистичный удобный интерфейс подписки → Поле «Оставьте e-mail» и кнопка «Подписаться» → *нарисованный эскиз*.

С формулировками разобрались, давайте пробежимся по структуре.

Укажите общую информацию

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

А еще стоит указать цель сайта и описать его функционал в двух словах - чтобы не получить интернет-магазин вместо блога.

Поясните сложные термины

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

Опишите инструменты и требования к хостингу

Представьте, что вы 2 месяца делали крутой сайт. Каждый этап согласовывали с клиентом - он в восторге. И вот пришло время сдавать работу. Вы показываете админку, а клиент кричит: «Это что такое? Модэкс?! Я думал, вы сделаете на «Вордпрессе»!»

Чтобы таких проблем не было, опишите используемые инструменты, движки и библиотеки. Заодно укажите требования к хостингу. Мало ли, вы сделаете на PHP - а у клиента сервер на.NET.

Перечислите требования к работе сайта

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

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

Укажите структуру сайта

До начала отрисовки дизайна и верстки вам нужно согласовать с клиентом структуру сайта.

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

Можно показать структуру списком, можно нарисовать блок-схему. Как вам удобнее.

Это один из важнейших этапов работы на сайтом. Структура - это фундамент. Если она неудачная - сайт получится кривой.

Объясните, что будет на каждой странице

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

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

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

Распишите сценарии использования сайта

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

• Действие пользователя.
• Ответное действие сайта.
• Результат.

Конечно, если вы делаете стандартную визитку или лендинг, писать сценарии не нужно. Но если на сайте будут какие-то интерактивные сервисы - очень желательно.

Подробнее о сценариях использования читайте в «Википедии ».

Определите, кто отвечает за контент

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

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

Указать, что весь контент должен быть уникальный, - это полезно. Еще одна защита клиента от недобросовестных исполнителей.

Опишите дизайн (если сможете)

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

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

Вместо вывода: структура техзадания

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

• Информация о компании и целевой аудитории, цели и задачи сайта.
• Глоссарий терминов, которые могут быть непонятны клиенту.
• Технические требования к верстке и работе сайта.
• Описание используемых технологий и список требований к хостингу.
• Подробная структура сайта.
• Прототипы страниц или описания элементов, которые должны на них быть.
• Сценарии использования нестандартного интерфейса (опционально).
• Список контента, который делает разработчик.
• Требования к дизайну (опционально).

• Правила составления Software Requirements Specification. SRS - следующая ступень эволюции техзадания. Нужна для больших и сложных проектов.
• Стандарты и шаблоны ТЗ на разработку ПО. Описания разных ГОСТов и методологий создания технических заданий.

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

Комментарии разработчиков

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

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

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

Крупные заказчики часто просят очень подробные ТЗ, в которых описана каждая кнопка. Небольшие компании наоборот не любят дотошные документы на 100 страниц. Долго читать и легко упустить что-то важное. Чаще мы делаем лаконичные ТЗ на 10–15 страниц.

Мы указываем:

• Информацию о компании и цель сайта.
• Требования к дизайну, цветовую гамму.
• Используемые технологии и CMS.
• Кто занимается контентом - мы или клиент.
• Структуру сайта вплоть до каждой страницы.
• Описания каждой страницы. Мы не делаем прототипы, но указываем, какие элементы должны быть на странице, и как они должны работать.

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

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

Тема 3.

ОПРЕДЕЛЕНИЕ ПРОЕКТА

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

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

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

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

ЭТАП 1: РАЗРАБОТКА ТЕХНИЧЕСКОГО ЗАДАНИЯ

Разработка технического задания (ТЗ ) готовит почву для разработки плана проекта. Техническое задание - это определение конечного резуль­тата или цели вашего проекта - товара или услуги для вашего заказчика. Основной целью здесь является как можно более четкое определение про­межуточных результатов работы для конечного пользователя и концент­рация (в единое целое) планов проекта. Хотя разработка технического за­дания является фундаментально важной, руководители проектов крупных корпораций с хорошим менеджментом часто поверхностно относятся к данному этапу.

Исследования показывают, что плохая разработка технического зада­ния является наиболее частой преградой на пути к успеху проекта. Изуче­ние проекта строительства большого нефтеперерабатывающего завода, проведенное Смитом и Таккером, показало, что плохая разработка техни­ческого задания и нечеткое определение основных составляющих проек­та самым отрицательным образом сказались на его стоимости и графике работ. Пинто и Слевин доказали, что четкое определение целей больше, чем на 50% предопределяет успех на стадии формулирования концепции, планирования и выполнения проекта. Эшли и другие продемонстрирова­ли, что у выдающихся, успешных проектов были четко разработаны тех­нические задания и определены составляющие работы. Анализ Познера выявил, что, по мнению 60% респондентов-управляющих проектами, ос­новной проблемой является отсутствие четких целей.

В ходе работы с более, чем 1400 управляющими проектами в США и Канаде Гобелай и Ларсон установили, что около 50% проблем планирова­ния связаны с нечетким техническим заданием и постановкой целей. Все эти результаты указывают на прямую зависимость успеха проекта от чет­кого определения его ТЗ. Четкое ТЗ заставляет как заказчика, так и всех участников проекта концентрироваться на целях проекта.

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

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

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

Перечень вопросов по ТЗ:

1. Цели проекта.

2. Промежуточные результаты работы.

3. Контрольные точки.

4. Технические требования.

5. Ограничения и исключения.

6. Проверка выполнения работы совместно с клиентом.

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

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

3. Контрольные точки. Контрольная точка - это значительное ме­роприятие в процессе работы над проектом, которое происходит в определенный момент времени. График контрольных точек отра­жает только основные сегменты работы; он показывает первую, приблизительную оценку затрат времени, стоимости и необходи­мых ресурсов для проекта. Этот график составляется с использо­ванием промежуточных результатов работы, как основы для опре­деления основных сегментов работы и конечной даты. Например, испытания проведены и полностью выполнены к 1 июля этого года. Контрольные точки должны быть естественными и важными точ­ками контроля. Они должны быть понятны всем участникам про­екта. График контрольных точек должен установливать, какие ос­новные подразделения организации будут отвечать за основные сегменты работы и обеспечивать проект необходимыми ресурса­ми и специалистами.

4. Технические требования. Обычно товар или услуга для того, что­бы хорошо работать, должны отвечать техническим требованиям. Например, техническим требованием к ПК может быть способ­ность работать от сети переменного тока в 120 вольт или от посто­янного тока в 240 вольт без адаптеров. Еще одним известным при­мером является способность системы 911 определить местонахож­дение и номер телефона звонящего.

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

6. Проверка выполнения работы совместно с заказчиком. Кон­трольный список вопросов ТЗ проекта заканчивается совместной с заказчиком проверкой выполнения работы. Основной проблемой является понимание и согласие заказчика с ожидаемыми результа­тами. Получает ли заказчик в виде промежуточных результатов то, что он хочет? Указывает ли определение проекта ключевые достиже­ния, сметы, сроки и требования к выполнению работ? Рассматрива­ются ли вопросы ограничений и исключений? Обсуждение всех этих вопросов крайне необходимо во избежание недопонимания.

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

©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-02-16

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

Что такое техническое задание

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

Кроме прочего, в состав этого документа может входить список требований, касающихся тестирования (применимо к разработке программного обеспечения).

Его применяют в своей работе строители, мастера, выполняющие ремонтные работы, программисты, дизайнеры и многие другие специалисты.

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

Особенности техзадания

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

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

Назначение технического задания

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

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

Как правило, готовый продукт проходит этап проверки, тестирования или испытания. Если его характеристики отличаются от запланированных, он может быть отправлен на доработку или исполнителю может быть отказано в оплате (это оговаривается, когда составляют техническое задание работы).

Состав ТЗ: требования к функциональности

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

Образцом требований различных видов становится большинство ГОСТов. Они регулируют процесс составления ТЗ для строительства крупных объектов и других ответственных работ. В них обычно перечисляют такие требования:

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

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

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

Характеристика требований

В отличие от многочисленных видов требований, свойств для их характеристики намного меньше:

• Понятность.
• Конкретность.
• Тестируемость.

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

Техническое задание - это не технический проект

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

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

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

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

Структура технического задания

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

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

• Указание общих сведений.
• Описание назначения и цели, ради достижения которой планируется создание или развитие системы.
• Характеристики объектов, подлежащих автоматизации.
• Изложение требований к системе.
• Состав и содержание мероприятий и работ, применяемых для создания системы.
• Описание того, как должен проходить контроль создания и процедура приемки готовой системы.
• Перечень требований к работам, которые будут проводиться с объектом автоматизации для его подготовки.
• Порядок ведения документации.
• Указание источников разработки.

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

Зачем составлять ТЗ для ремонта комнаты

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

По этой причине техническое задание на ремонт становится одним из важнейших этапов, так как позволяет:

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

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

Какие пункты включает техзадание для ремонта комнаты

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

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

2. Характеристика пола: объем работ, которые нужно выполнить на этом участке. Здесь можно подробно указать, что именно необходимо выполнить мастерам:

• Демонтировать пришедшее в негодность покрытие, плинтуса и черновые полы (тип и квадратура).
• Нанести выравнивающую, разделительную стяжку и термоизоляцию (площадь и высота материалов).
• При необходимости установить систему «теплый пол» (тип и высота конструкции).
• Нанести стяжку над нагревательными кабелями (около 30-50 мм).
• Подготовить поверхность к укладке плитки, ламината, ковролина или другого материала (характер расположения элементов).
• Установить плинтус (указывают количество погонных метров, а также все внутренние и внешние уголки).

3. Работы с потолком:

• Очистить от побелки или обоев (площадь в метрах квадратных).
• Выровнять шпатлевкой (площадь).
• Нанести штукатурку (квадратура и средняя толщина).
• Если требуется установить потолок из гипсокартона, нужно указать его тип, квадратуру и высоту. Для многоуровневых моделей требуется приложить чертеж.
• Зашпаклевать и покрасить потолок (площадь, цвет).

4. Что требуется проделать со стенами:

• Очистить от предыдущего слоя обоев или другого покрытия (площадь).
• Отбить штукатурку.
• Заштукатурить стены (с армированием или без него). Здесь необходимо указать не только общую квадратуру стен, но и толщину слоя. Длину используемых откосов приводят в погонных метрах.
• Зашпаклевать стены.
• Указать, сколько в комнате наружных углов, чтобы можно было подсчитать длину перфорированного уголка.

5. Параметры окна:

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

6. Характеристики двери:

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

7. Работы с электрическими сетями:

• Перечень работ (установка, замена,
• Необходимость прокладки телефонных или интернет-кабелей.
• Приложить схему.

8. Мероприятия по монтажу отопительных систем и кондиционеров:

• Установка, перенос, замена или просто покраска отопительного прибора.
• Демонтаж традиционного прибора и установка системы «теплые полы».
• Обозначить на схеме место расположения кондиционера и трассы. Уточнить, как будет проведено его питание от электросети.

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

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

Главной задачей этого мероприятия становится получение информации о состоянии помещения и более точного описания предстоящих ремонтных работ.

При обследовании комнаты обращают внимание на главные параметры и выполняют следующие действия:

• Проверяют правильность геометрии.
• Изучают горизонтальность потолка (есть ли наклоны, перепады). Это помогает определить тип отделки и дает понятие о будущей высоте комнаты.
• Проверяют вертикальность стен и правильность углов. Если понадобится их выравнивать, мастерам следует знать, какие материалы применить и в каком количестве их требуется закупить.
• Проверка горизонтальности пола. Зачастую полы приходится полностью менять (особенно если предусмотрен монтаж отопительной системы под ними), поэтому следует заранее определить, объем работ.

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

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

Эта информация позволяет оценить уровень трудовых и финансовых затрат. Техзадание должно содержать чертежы будущих работ.

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

Главная » Дети » Примеры написания тех заданий для разработки по. Образцы технических заданий