Техническое задание на оформление. Техническое задание, пример

2 голоса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вообще, я очень рекомендую вам уделять внимание мелочам. Представьте, к вам приходит взмыленная женщина, наспех расстегивает огромную куртку так, что из нее торчит необъемного размера шарф. Достает из сумки сложенную в сто раз мятую писульку из 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 .

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

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

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

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

От автора: Как написать техническое задание (тз) на разработку сайта ? Тема достаточно обширная, и в рамках одной заметки ее сложно разобрать на все 100% (если вообще это возможно). Но общие положения, о том что нужно учесть и на что следует обратить сое внимание при составлении тз веб-сайта, я постараюсь изложить достаточно подробно.

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

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

Давайте проанализируем такой пример:

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

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

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

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

Это пример всего-то банального календаря.

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

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

Из каких пунктов обычно состоит техническое задание?

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

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

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

Поехали по пунктам.

Описание

Здесь можно в пару предложений написать о предприятии, чем занимается. Что – то типа вступление сделать.

для кого — целевую аудиторию:

потенциальные покупатели

продавцы продукции (магазины, интернет-магазины)

сервисные центры

партнеры (фирмы)

потребители продукции (тот, кто уже купил)

Для чего нужен сайт:

Для повышения имиджа компании

Для увеличения продаж

Для удобства клиентов

Корпоративный

Сайт – визитка

Интернет магазин

Языковые версии:

Английский

Сайт должен решать какие-то задачи. Соответственно далее двигаемся по целям и задачам.

Цели и задачи

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

Потенциальные покупатели продукции.

Цель: привлечь больше покупателей и убедить сделать первую покупку, помочь сделать выбор.

Необходимо решить задачи:

Дать качественную, исчерпывающую информацию о продукции, дополнительных услугах, гарантии, сервисе, методах выбора.

Дать информацию о салонах-магазинах

Дать информацию о розничной торговой сети

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

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

Теперь перечисляем модули.

Функционал сайта

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

Нужна ли регистрация

Нужен ли закрытый раздел (только для зарегистрированных пользователей)

Нужна ли форма обратной связи

И т.д. и т.п.

Современные тенденции и подходы в веб-разработке

Узнайте алгоритм быстрого роста с нуля в сайтостроении

После того, как все это описали, мы подбираемся к самому главному и интересному. Конечно, вся проделанная выше работа очень важна, но теперь становиться еще «жарче».

Описание функционала

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

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

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

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

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

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

о компании

история компании

контакты

продукция

каталог продукции

отзывы о продукции

служба сервиса

гарантийное обслуживание

послегарантийное обслуживание

потребителю

покупка и доставка

пользование

о сервисе

магазинам и интернет магазинам

фотографии продукции

Часто задаваемые вопросы

сервисным центрам

Как стать сервисным центром

Часто задаваемые вопросы

партнерам

приглашение к сотрудничеству

Часто задаваемые вопросы

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

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

Главное теперь описать логику работы.

Логика работы

Я описывать буду исходя из рисунка выше.

Верхняя часть (header) остается неизменной на каждой странице. Новостная лента видна только на главной странице. На второстепенных страницах слева показываем подпункты меню того пункта, в котором в данный момент находимся (например если мы на странице «служба сервиса», то показываем ссылки на «гарантийное обслуживание», «послегарантийное обслуживание»). Соответственно и переходы по этим ссылкам ведут на соответствующие страницы. Здесь же, под подпунктами слева отображаем данные для связи с он-лайн консультантами (Skype, ICQ). Блок акции и релизы остаются на каждой странице. Подвал (футер) отображается один и тот же на каждой странице.

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

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

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

Примерно так описываем работу каждого блока. Не забываем про случай с календарем. И самое главное нужно расписать работу каталога товара. Здесь я даю вам задание: попробуйте продумать и описать, как будет работать каталог. Свои варианты присылайте на e-mail. Лучший мы опубликуем.

Что еще должно быть? Неплохо было бы указать совместимость.

Совместимость

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

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

Заключение

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

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

И не забывайте про задание!

От автора : Как написать техническое задание на разработку сайта ? Тема достаточно обширная, и в рамках одной статьи ее сложно разобрать на все 100% (если вообще это возможно). Но общие положения, то, что нужно учесть, на что следует обратить внимание при составлении ТЗ, я постараюсь достаточно подробно изложить в данной статье.

Итак, ТЗ

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

Давайте проанализируем такой пример:

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

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

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

Что мы имеем. Исполнитель пункт ТЗ выполнил, а вы хотели совсем другой календарь. Вроде все в соответствии с ТЗ, никто не виноват, до конфликта не дошло, но самое главное потеряны время и деньги .

Это пример всего-то банального календаря.

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

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

Из каких пунктов обычно состоит ТЗ?

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

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

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

Поехали по пунктам.

Описание сайта

Здесь можно в пару предложений написать о предприятии, чем занимается. Что – то типа вступление сделать.

для кого – целевую аудиторию сайта :

• потенциальные покупатели
• продавцы продукции (магазины, интернет-магазины)
• сервисные центры
• партнеры (фирмы)
• потребители продукции (тот, кто уже купил)

Для чего нужен сайт :

• Для повышения имиджа компании
• Для увеличения продаж
• Для удобства клиентов

Тип сайта :

• Корпоративный
• Сайт – визитка
• Интернет магазин

Языковые версии :

• Английский
• Русский

Сайт должен решать какие-то задачи. Соответственно далее двигаемся по целям и задачам сайта.

Цели и задачи сайта

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

Потенциальные покупатели продукции .

Цель : привлечь больше покупателей и убедить сделать первую покупку, помочь сделать выбор.

Необходимо решить задачи :

Дать качественную, исчерпывающую информацию о продукции, дополнительных услугах, гарантии, сервисе, методах выбора.

• Дать информацию о салонах-магазинах
• Дать информацию о розничной торговой сети

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

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

Теперь перечисляем модули сайта.

Функционал сайта

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

• Нужны ли новости на сайте
• Нужен ли рекламный блок
• Нужна ли регистрация
• Нужен ли закрытый раздел сайта (только для зарегистрированных пользователей)
• Нужна ли форма обратной связи
• Нужен ли скрипт рассылки
• И т.д. и т.п.

После того, как все это описали, мы подбираемся к самому главному и интересному. Конечно, вся проделанная выше работа очень важна, но теперь становиться еще «жарче».

Описание функционала сайта

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

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

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

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

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

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

О компании

• история компании
• контакты
• отзывы

Новости

• события
• акции
• новое на сайте

Продукция

• каталог продукции
• релизы
• отзывы о продукции

Сервис

• служба сервиса
• гарантийное обслуживание
• послегарантийное обслуживание

Потребителю

• покупка и доставка
• пользование
• о сервисе

Магазинам и интернет магазинам

• фотографии продукции
• Часто задаваемые вопросы

Сервисным центрам

• Как стать сервисным центром
• Часто задаваемые вопросы

Партнерам

• приглашение к сотрудничеству
• часто задаваемые вопросы

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

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

Главное теперь описать логику работы.

Логика работы

Я описывать буду исходя из рисунка выше.

Верхняя часть сайта остается неизменной на каждой странице сайта. Новостная лента видна только на главной странице. На второстепенных страницах слева показываем подпункты меню того пункта, в котором в данный момент находимся (например если мы на странице «служба сервиса», то показываем ссылки на «гарантийное обслуживание», «послегарантийное обслуживание»). Соответственно и переходы по этим ссылкам ведут на соответствующие страницы. Здесь же, под подпунктами слева отображаем данные для связи с он-лайн консультантами (Skype, ICQ). Блок акции и релизы остаются на каждой странице. Подвал сайта отображается один и тот же на каждой странице.

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

Теперь подробно описываем каждый блок. Например «Новостная лента».

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

Примерно так описываем работу каждого блока. Не забываем про случай с календарем. И самое главное нужно расписать работу каталога товара. Здесь я даю вам задание : попробуйте продумать и описать, как будет работать каталог. Свои варианты присылайте на e-mail. Лучший мы опубликуем.

Что еще должно быть? Неплохо было бы указать совместимость.

Совместимость

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

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

Заключение

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

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

И не забывайте про задание!

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

В соответствии с п. 10 ст. 4 Закона № 223-ФЗ в документации о закупке должны быть указаны установленные заказчиком требования к качеству, техническим характеристикам товара, работы, услуги, к их безопасности, к функциональным характеристикам (потребительским свойствам) товара, к размерам, упаковке, отгрузке товара, к результатам работы и иные требования, связанные с определением соответствия поставляемого товара, выполняемой работы, оказываемой услуги потребностям заказчика.

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

Требования к формированию технического задания.

1. Согласно п. 2 ч. 1 ст. 3 Закона № 223-ФЗ при закупке ТРУ заказчики должны руководствоваться следующими принципами: равноправие, справедливость, отсутствие дискриминации и необоснованных ограничений конкуренции по отношению к участникам закупки.

2. Закон № 135-ФЗ «О защите конкуренции» (п. 2, ч. 1, ст. 17) гласит, что при проведении торгов запрещаются действия, которые приводят или могут привести к недопущению, ограничению или устранению конкуренции, в том числе запрещено создавать участнику торгов или нескольким участникам торгов преимущественные условия участия в торгах, в том числе путем доступа к информации, если иное не установлено законодательством.

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

Лучше, чтобы техническое задание формировал именно инициатор закупки, то есть тот, кто будет использовать предмет закупки. При этом специалисты по закупке обязательно контролируют и проверяют техническое задание на его соответствие антимонопольному законодательству (ст. 17 Закон № 135-ФЗ).

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

В техническом задании обязательно нужно указывать в качестве одного из требований, что товар должен быть новый. Поскольку Законом № 223-ФЗ это никак не регламентируется (в отличие от Закона № 94-ФЗ), то участники закупки вправе будут поставить бывший в употреблении товар в случае, если заказчик не укажет конкретно, что он должен быть новый.

Правильное техническое задание содержит:

• Описание ТРУ (функциональные характеристики и потребительские свойства).
• Количество, срок и место поставки.
• Комплектацию.
• Требование к расходам на эксплуатацию товара.
• Требования к качеству.
• Требования к монтажу и доставке.
• Требования к обучению персонала.
• Список передаваемой документации.
• Требования к остаточному сроку годности.
• Требования к объему и сроку предоставления гарантий.

Формируем лоты правильно.

В один лот лучше не включать:

• технологически и функционально не связанную продукцию (компьютеры и продукты);
• виды деятельности подлежащие лицензированию и не подлежащие (компьютеры и ПО).

Правила формирования лота.

1. Должно быть предусмотрено право участия по любому количеству лотов.

Если поставщик победил в одном лоте, то неправомерно ограничивать его участие в других лотах. Это будет признано ограничением конкуренции.

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

3. Победа в одном лоте не может быть обусловлена победой в другом лоте.

4. Договоры заключаются по всем лотам отдельно, или если один победитель - 1 договор на все лоты.

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

Популярные способы ограничения количества участников.

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

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

2. Включение в лот разнородной продукции.

3. Включение в лот кроме прочей продукции продукцию, подлежащую лицензированию.

4. Включение в лот «разнолицензируемой» продукции.

5. Требования по нескольким местам поставки.

6. Нереальные сроки.

7. Установление трудновыполнимых требований по предоставлению документов.

Правила определения качества продукции согласно ст. 469, 721 ГК РФ:

1. Поставщик обязан передать заказчику товар, качество которого соответствует договору.

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

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

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

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

Последствия некорректного составления технического задания:

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

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

Примеры требований в техническом задании:

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

Техническое задание на закупку ГСМ

Прежде, чем проводить закупку, нужно определить код по ОКДП, чтобы знать в какой форме нужно проводить закупку - в электронной или нет. В данном случае код номер 2320000, в постановление Правительства № 616 этот код не входит. Значит обязанности проводить закупку электронно нет. Тем не менее это очень удобно и можно это делать в том числе в электронной форме.

Предмет договора: поставка ГСМ или нефтепродуктов.

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

• наименование;
• характеристики;
• количество;
• выборка по заявкам;
• место поставки;
• способ поставки (оптом, по талонам или картам, за наличный расчет).

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

Способы поставки ГСМ:

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

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

Оплата за ГСМ:

2. Окончательный расчет:

• по факту передачи талонов;
• по факту зачисления на смарт-карту;
• по фактической поставке.

ТЗ на закупку транспортных услуг.

Объем транспортных услуг измеряется:

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

Это зависит от специфики организации и поставленных задач.

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

• наличие ОСАГО и страхования пассажиров;
• медицинский осмотр водителей перед началом работы, требования к поведению и внешнему виду водителей;
• виды транспортных средств;
• количество транспортных средств, необходимых заказчику одновременно;
• место оказания услуг - конкретный маршрут, либо указание на то, что маршрут определяется заказчиком непосредственно в ходе оказания транспортных услуг.

ТЗ на закупки услуг страхования

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

КАСКО - цена разная у разных поставщиков. Есть возможность оценивать этот фактор наряду с другими важными показателями.

В техническое задание включаем:

• количество объектов страхования;
• их наименования и точные характеристики;
• срок страхования;
• страховую сумму.

ОСАГО. Оценка заявок.

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

Качество услуг и квалификация участников:

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

КАСКО. Оценка заявок.

Критерии оценки: цена договора, качество услуг и (или) квалификация исполнителя.

Возможные показатели:

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

ТЗ на закупки услуг по охране

Специальные требования к участникам:

• юридическое лицо, которое в соответствии со своим уставом занимается оказанием охранных услуг, обязано иметь на это лицензию;
• охранная деятельность организаций не распространяется на объекты, подлежащие государственной охране (перечень утвержденпостановлением Правительства РФ от 14.08.1992 № 587).
• Законом РФ от 11.03.1992 № 2487-1 «О частной детективной и охранной деятельности в РФ» охрана имущества собственников отнесена к оказанию услуг лицами, осуществляющими частную детективную и охранную деятельность. Этот вид услуг не относится к исключительным полномочиям органов внутренних дел.

Охрана. Оценка заявок.

Можно установить следующие критерии оценки заявок:

Цена договора;

Опыт выполнения аналогичных услуг (не в годах, а в сумме договора), подтверждение этого опыта;

Квалификация (наличие группы быстрого реагирования, специального вооружения и т.д.).

ТЗ на закупки в сфере строительства

• Главным способом осуществления закупки является проведение конкурса (или запроса предложений).
• Авторский надзор лучше закупать у единственного поставщика.
• Лицензирование строительства заменено на допуск от СРО.
• Начальная цена договора определяется по сметным нормативам.
• ПСД должна быть в документации.
• Цена договора определяется путем пропорционального снижения всех позиций сметы на сделанную в ходе процедуры скидку.
• Смета в документации, договоре и актах должна совпадать по составу и объему работ.

Формирование лотов

Возможно ли совмещать изыскательские, проектные, строительные работы в одном лоте?

Согласно ст. 17 Закона № 135-ФЗ при проведении электронных торгов запрещаются действия, которые приводят или могут привести к недопущению, ограничению или устранению конкуренции, в том числе запрещено создавать участнику торгов или нескольким участникам торгов преимущественных условий участия в торгах.

• Проектные и изыскательские работы можно объединять в один лот.
• Не следует объединять в один лот строительные и проектные работы.
• Без ПСД невозможно определить окончательный объем строительных работ.
• При неизвестном объеме работ невозможно определить начальную цену.
• Требуются свидетельства о допуске от разных СРО.

Виды СРО (ст. 55.2 ГрК РФ)

1. Подготовка проектной документации объектов капитального строительства.

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

3. Инженерные изыскания объектов капитального строительства.

По всем трем видам ведутся отдельные реестры СРО, посмотреть их можно на сайте:www.gosnadzor.ru .

Перечень видов работ, требующих допуск СРО, определен приказом Минрегиона России от 30.12.2009г. № 624. Он вступил в силу с 01.07.2010 (до 01.07.2010 г. такой перечень был определен приказом Минрегиона России от 09.12.2008 № 274). Перечень содержит отдельные виды работ - только для особо опасных, технически сложных и уникальных объектов (ст. 48.1 ГрК РФ) и не включает в себя виды работ по подготовке проектной документации, по строительству, реконструкции, капитальному ремонту в отношении объектов, для которых не требуется выдача разрешения на строительство (ч. 17, ст. 51 ГрК РФ), а также в отношении ряда других объектов (п. 2 приказа Минрегиона России от 30.12.2009г. № 624).

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

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

Согласно ГК РФ виды работ по инженерным изысканиям, по подготовке проектной документации, по строительству, реконструкции, капитальному ремонту объектов капитального строительства, которые оказывают влияние на безопасность объектов капитального строительства, должны выполняться физическими или юридическими лицами, имеющими выданные саморегулируемой организацией свидетельства о допуске к таким видам работ. Иные виды работ могут выполнятся любыми лицами.

Техническое задание на строительство в случае закупки работ по капитальному ремонту, реконструкции, модернизации, техническому перевооружению, новому строительству должно содержать:

• Основу - проектную документацию с положительным заключением экспертизы.
• Особенности порядка приемки работ. Применение СниП 3.01.04-87 «Приемка в эксплуатацию законченных строительством объектов. Основные положения».
• Обязанность передать копии документов на применяемые материалы (сертификаты соответствия или декларации о соответствии).
• Обязанность обеспечить авторский надзор, строительный контроль, государственный строительный надзор.
• Перечни специального монтируемого оборудования.
• Если закупается текущий ремонт, тотехническое задание на строительство должно содержать:
• Основу - дефектные ведомости, ведомости объемов работ, локальные сметные расчеты (ЛСР), которые могут прикладываться к документации о закупке.
• Особенности приемки работ.
• Обязанность передать копии документов на применяемые материалы (сертификаты соответствия или декларации о соответствии. См. постановление Правительства № 982 от 01.12.2009 «Единые перечни продукции, подлежащей сертификации...»).

Кроме того, техническое задание на строительство может содержать:

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

Вопросы слушателей

Вопрос: Как быть если товар по санитарным правилам должен быть произведен в России?

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

Вопрос: Можно ли включить в техническое задание условие оплаты товара в рассрочку?

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

Вопрос: Можем ли мы устанавливать преференции поставщикам, предлагающим товары российского производства?

Ответ: Нет, на это вы права не имеете. Нельзя устанавливать ни преференции по стране производства, ни субъектам малого, среднего бизнеса. Это не ваша прерогатива. Это относится к компетенции Правительства РФ.

Вопрос: Можно ли АИ-92, АИ-80 и дизельное топливо закупать одним лотом?

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

Вопрос: Указанные в законе суммы 100 тыс. руб. и 500 тыс. руб. - это считать с НДС или без?

Ответ: Согласно указанной в договоре стоимости, которая обычно указывается с НДС.

Вопрос: Можно ли продлить поставки ГСМ дополнительным соглашением на 2014 год?

Ответ: С юридической точки зрения все дополнительные соглашения, согласно которым увеличивается объем поставляемых товаров, работ, услуг, являются новой сделкой. Вы можете заключить это дополнительное соглашение на поставку ГСМ в 2014 году. При этом нужно быть уверенными, что в вашем Положении о закупке прописаны основания для заключения этой сделки.

Вопрос: Что делать если водители заправляются на заправках за наличные по мере необходимости и у разных поставщиков?

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

Вопрос: При закупке ГСМ нет цены договора и количества закупаемого топлива, можно ли указывать лишь цену 1 литра топлива?

Ответ: Нельзя.

Вопрос: Если платежи одному и тому же поставщику ГСМ проходят регулярно 1-2 раза в месяц и суммы платежей менее 100 тысяч рублей, то можно ли расценивать эту закупку как закупку до 100 тыс. руб.?

Ответ: Лучше провести конкурентную процедуру и заключить договор на поставку большого количества топлива некоторыми партиями. Тогда ни у кого не возникнет вопросов к вам относительно соблюдения законодательства.

Вопрос: Можно ли сделать закупку ГСМ по количеству литров?

Ответ: Можно.

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

Ответ: В этом случае необходимо заключать новый договор.

Вопрос: Правильно ли оформлять заказ у единственного поставщика в договоре поставки, указав только общую сумму договора и ссылку на то, что поставка осуществляется по заявке с указанием конкретного объема и цены за ед.?

Ответ: Закупку у единственного поставщика правильно оформлять следующим образом. Если закупка больше 100 000 руб. или 500 000 руб., то нужно публиковать на сайте извещение, документацию и проект договора с указанием всех условий, предусмотренных Законом №223-ФЗ.

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс , найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

ГОСТ 34
ГОСТ 19
IEEE STD 830-1998
ISO/IEC/ IEEE 29148-2011
RUP
SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки

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

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” - это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 - IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:

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

Согласно стандарту техническое задание должно включать следующие разделы:

1. Введение

• 1. Назначение
• 2. Область действия
• 3. Определения, акронимы и сокращения
• 4. Ссылки
• 5. Краткий обзор

2. Общее описание

• 1. Взаимодействие продукта (с другими продуктами и компонентами)
• 2. Функции продукта (краткое описание)
• 3. Характеристики пользователя
• 4. Ограничения
• 5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)

• 1. Требования к внешним интерфейсам
  • 1. Интерфейсы пользователя
  • 2. Интерфейсы аппаратного обеспечения
  • 3. Интерфейсы программного обеспечения
  • 4. Интерфейсы взаимодействия
• 2. Функциональные требования
• 3. Требования к производительности
• 4. Проектные ограничения (и ссылки на стандарты)
• 5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
• 6. Другие требования

4. Приложения
5. Алфавитный указатель

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

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

• Презентацией Юрия Булуя Классификация требований к программному обеспечению и ее представление в стандартах и методологиях .
• Анализ требований к автоматизированным информационным системам. Лекция 11: Документирование требований .
• Правила составления Software requirements specification (читать вместе с комментариями)
• Примеры ТЗ и другой документации по разработке АС для МЭР
• ГОСТ-овский стиль управления . Статья Gaperton по правильной работе с ТЗ по ГОСТ
• Шаблоны документов для бизнес-аналитиков из