Как составить техническое задание

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

Как составить техническое задание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

Как составить техническое задание — НалогОбзор.Инфо

Как составить техническое задание

Одно из главных условий успешной закупки – правильно составленное техническое задание.

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

Оно несет пользу для обеих сторон.

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

Участник с помощью технического задания сможет точно понять объект закупки и оценить свою возможность удовлетворить требования заказчика.

Кто составляет

Техническое задание составляют сотрудники контрактной службы или контрактный управляющий в составе документации о закупке (п. 3 ч. 4 ст. 38 Федерального закона от 5 апреля 2013 г. № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд», далее – Закон № 44-ФЗ).

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

Как составить (форма и структура)

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

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

  • общую информацию о заказчике;
  • общую информацию о закупке;
  • информацию об объекте закупки;
  • требования к поставщику (подрядчику, исполнителю).

Совет: Начинать готовить техническое задание стоит заранее. Это снизит риск того, что будут нарушены сроки публикации документации о закупке в ЕИС. Ведь контрактной службе (контрактному управляющему) необходимо от нескольких дней до нескольких недель, чтобы составить качественное техническое задание в зависимости от технической сложности объекта закупки.

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

  • ГОСТами. Например, при создании автоматизированной системы – ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы»;
  • методическими указаниями (рекомендациями) учредителя. Например, Минкультуры России разработало Методические указания по порядку разработки технического задания при проведении закупок в рамках целевой программы «Культура России (2012–2018 годы)» (письмо Минкультуры России от 25 января 2013 г. № 446-01-56/10-НМ).

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

1. Общая информация о заказчике

В этом разделе стоит указать такие данные заказчика:

  • место нахождения заказчика;

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

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

2. Общая информация о закупке

Здесь стоит указать:

  • полное наименование объекта закупки,
  • выбранный способ определения поставщика (подрядчика, исполнителя),

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

Термины и сокращения Определение
ПО Программный продукт «Зарплата-Бюджет», который является объектом закупки
Заказчик Государственное учреждение «Альфа»
Эксперт Специалист, который обладает специальными знаниями в области бухгалтерского учета и налогообложения в бюджетной сфере, в кадровых и юридических вопросах, имеющий высшее профильное образование

3. Описание объекта закупки

В этом разделе необходимо наиболее полно и точно описать следующее.

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

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

Для этого нужно руководствоваться обязательными требованиями, в частности, ГОСТами, СНиПами, гражданским законодательством (ст. 469, 721 ГК РФ).

Например, требования к качеству пищевых продуктов установлены в Федеральном законе от 2 января 2000 г. № 29-ФЗ.

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

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

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

Например, при закупке системного блока правильнее будет указать в техническом задании «Объем жесткого диска – не менее 500 Гб», а не «Объем жесткого диска – 500 Гб».

Об этом сказано в части 2 статьи 33 Закона № 44-ФЗ и разъяснено в письме Минэкономразвития России от 10 декабря 2014 г. № Д28и-2796.

2. Эксплуатационные характеристики (при необходимости).

3. Общее количество товаров (объем работ, услуг). Когда это сделать невозможно, заказчик может указать цену единицы работы (услуги).

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

5. Требования к безопасности объекта закупки.

6. Сроки и порядок поставки товара, выполнения работы, оказания услуги. В частности, нужно определить место поставки товара (выполнения работы, оказания услуги). При этом можно указать:

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

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

7. Гарантийный срок и гарантийное обслуживание (ч. 4 ст. 33 Закона № 44-ФЗ). Гарантийный срок нужно установить в днях, месяцах и годах.

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

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

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

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

В противном случае заказчик рискует получить товар, бывший в употреблении. Об этом сказано в пункте 7 части 1 статьи 33 Закона № 44-ФЗ.

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

  • требования по монтажу и наладке;
  • соответствие образцу и т. д.

Перечень сведений и требований может варьироваться в зависимости от каждого конкретного объекта закупки.

Пример описания объекта закупки

В соответствии с планом-графиком ГУ «Альфа» закупка партии бумаги для офисной техники запланирована на май 2016 года. При подготовке к проведению электронного аукциона контрактный управляющий А.С. Глебова приступила к подготовке документации о закупке, в частности, составила техническое задание.

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

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

Совет: В качестве источника информации стоит использовать:

  • ранее исполненные контракты,
  • общедоступные источники (каталоги, прайсы, рекламные буклеты и др.),
  • коммерческие предложения,

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

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

Так, на должностных лиц (контрактный управляющий, сотрудники контрактной службы) могут наложить штраф в размере 1 процента начальной (максимальной) цены контракта (НМЦК), но не менее 10 000 руб. и не более 50 000 руб. (ч. 4.

1 ст. 7.30 КоАП РФ).

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

  • указать средства труда, используемые при выполнении работ или услуг, но не в качестве предмета контракта. При этом обязательным условием является указание формулировки «или эквивалент»;
  • приобрести товары, необходимые для взаимодействия с товарами, используемыми заказчиком (например, обновление установленного программного обеспечения);
  • приобрести запчасти или расходные материалы к машинам и оборудованию заказчика.

Об этом сказано в пункте 1 части 1 статьи 33 Закона № 44-ФЗ.

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

  • по охране объекта при помощи средств охранно-пожарной сигнализации и
  • по техническому обслуживанию самой сигнализации.

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

Это следует из части 3 статьи 17 Федерального закона от 26 июля 2006 г. № 135-ФЗ и разъяснено в письмах Минэкономразвития России от 10 марта 2015 г. № Д28и-442, ФАС России от 21 мая 2014 г. № АЦ/20578/14.

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

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

4. Требования к поставщику (подрядчику, исполнителю)

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

Кроме того, в некоторых случаях Правительство РФ может установить дополнительные требования к участникам закупки, в частности, к наличию финансовых, материальных ресурсов, опыта работы, аналогичного предмету контракта (ч. 2 ст. 31 Закона № 44-ФЗ). Так, в постановлении Правительства РФ от 4 февраля 2015 г.

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

Сумма такого контракта должна быть не менее 20 процентов НМЦК, на заключение которого проводят закупку.

Источник: http://NalogObzor.info/publ/dogovornoe_pravo/zakupki/kak_sostavit_tekhnicheskoe_zadanie/72-1-0-3105

Техническое задание (тз) на разработку сайта

Как составить техническое задание

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

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

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

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

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

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

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

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

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

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

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

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

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

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

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

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

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

Описание

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

Далее тут указываем:

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

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

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

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

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

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

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

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

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

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

Тип:

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

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

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

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

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

Цели и задачи

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

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

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

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

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

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

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

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

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

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

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

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

Нужны ли новости

Нужен ли рекламный блок

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

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

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

Нужен ли скрипт рассылки

И т.д. и т.п.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

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

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

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

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

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

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

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

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

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

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

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

о компании

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

контакты

отзывы

новости

продукция

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

релизы

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

сервис

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

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

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

потребителю

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

пользование

о сервисе

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

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

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

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

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

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

партнерам

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

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

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

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

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

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

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

Верхняя часть (header) остается неизменной на каждой странице. Новостная лента видна только на главной странице.

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

Здесь же, под подпунктами слева отображаем данные для связи с он-лайн консультантами (Skype, ICQ). Блок акции и релизы остаются на каждой странице. Подвал (футер) отображается один и тот же на каждой странице.

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

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

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

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

При нажатии на ссылку «архив за (такой-то месяц или год)» вниз выпадает список новостей за соответствующий месяц/год.

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

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

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

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

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

Заключение

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

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

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

Бернацкий Андрей

E-mail: contact@webformyself.com

«Киберсант-вебмастер» — самый полный курс по сайтостроению в рунете!

P.S. Хотите опубликовать интересный тематический материал и заработать? Если ответ «Да», то жмите сюда.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

Источник: https://webformyself.com/kak-napisat-tz-na-razrabotku-sajta/

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

Как составить техническое задание

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

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

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

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

Как понять, сколько нужно лидов и по какой цене? Как разработать сильный оффер? Как составить таблицу KPI?

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

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

Реклама

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как правильно составить техзадание. Основные рекомендации

Как составить техническое задание

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

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

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

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

Кто должен составлять техзадание

Иногда приходится слышать мнение, что ТЗ должен составлять непосредственно исполнитель.

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

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

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

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

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

Структура документа ТЗ:

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

Рассмотрим подробнее каждый пункт структуры.

1. Оглавление

Понятно из названия, перечень всех частей технического задания.

2. История изменений

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

3. Терминология

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

4. Общие сведения о проекте

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

5. Требования к проекту

Один из самых объемных и также основной пункт в техзадании. В нем описываются абсолютно все требования к проекту, такие как:

  • требования к функционированию проекта;
  • требования к надежности;
  • требования к исполнительному персоналу;
  • требования к патентной чистоте;
  • требования к стандартизации;
  • требования к конфиденциальности;
  • требование к безопасности;
  • и другие …

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

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

7. Требования к документированию

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

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

8. Стадии и этапы разработки

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

9. Порядок контроля и приемки проекта

В этом разделе описывается порядок приема проекта, система тестов.

10. Дополнительные материалы

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

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

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

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

Основные рекомендации

  1. Желательно по максимуму использовать графические материалы. Часто бывает так, что одна схема или диаграмма может заменить несколько страниц текста.
  2. Не использовать расплывчатых, двусмысленных описаний. Все должно быть описано четко и понятно.
  3. Описание проекта должно быть логически связным и не иметь противоречий.
  4. Необходимо указывать абсолютно все данные и требования, даже те, которые на первый взгляд могут показаться абсурдными. Такими данными могут быть поля в форме регистрации, формат даты в статье и прочее.
  5. При указании сроков, необходимо учитывать, что неотъемлемой частью разработки является тестирование и исправление ошибок, поэтому в очень короткие сроки можно не вложится.
  6. После выбора исполнителя необходимо совместно просмотреть ТЗ, возможно появятся новые вопросы или дополнения.

Источник: https://valerykoretsky.com/blog/terms-of-reference/

Про закон
Добавить комментарий