Заказ на разработку фирменного стиля, дизайна упаковки, логотипа или сайта всегда сопровождается составлением и оформлением соответствующей документации - договора, брифа и технического задания (ТЗ). Создание ТЗ - это первый этап совместной работы заказчика и исполнителя.
Один из самых распространенных способов снижения затрат и сокращения бюджета проекта - самостоятельное написание ТЗ (технического задания) .
Однако без определенного опыта достаточно сложно составить грамотное ТЗ, которое будет понятно как исполнителю, так и заказчику.
В техническом задании необходимо точно и четко описать требования к объекту работ, установить технические параметры, назначение объекта, подготовить состав нужной проектной документации, определить сроки и порядок выполнения работ.
Прежде чем приступить к разработке технического задания необходимо провести исследования, предварительные расчеты, собрать исходную информацию.
Создание ТЗ - это сложный процесс, который лучше отдать на выполнение профессионалам, кроме того у вашего «королевского бренда» есть более важные и приоритетные задачи, чем написание технического задания.
Техническое задание это
Техническое задание - это основополагающий документ всего проекта и взаимоотношений заказчика с исполнителем, который позволяет четко определить порядок работ, обязанности сторон и сроки выполнения проекта.
От того насколько правильно, точно и четко составлено техническое задание для исполнителя будут зависеть сроки выполнения и успех проекта в целом.
Виды ТЗ (технического задания)
Техническое задание - первый шаг на пути к реализации любого проекта. Можно выделить бесчисленное множество видов технического задания на выполнение работ:
- техническое задание на разработку сайта;
- техническое задание на разработку логотипа;
- техническое задание на разработку программы;
- техническое задание на разработку фирменного стиля;
- техническое задание на разработку дизайна;
- техническое задание на разработку названия компании;
- техническое задание на продвижение сайта и т.д.
Независимо от того, кого Вы выбрали на роль исполнителя проекта - фрилансера или брендинговое агентство, до начала работы над проектом необходимо проанализировать и обработать большие объемы разнородной информации. Изучить данные касательно целей и задач проекта, стратегических и текущих целей компании, требований к объекту работ, пожеланий заказчика, сроков сдачи готового проекта и ожидаемых результатов. Далее необходимо собрать эту информацию воедино, структурировать данные и предоставить исполнителю в форме технического задания.
Как правило, разработка ТЗ - это задача руководителя проекта. Никто кроме заказчика не опишет наилучшим образом идеи, принципы работы, цели проекта и деятельность компании. Данное описание по возможности должно быть максимально понятным и подаваться в форме общего рассказа о компании, ее бренде.
Структура технического задания
Структура технического задания (форма технического задания) выглядит следующим образом:
1. Цели проекта
В ТЗ необходимо указать каких целей хочет добиться компания, используя результаты завершенного проекта. Такими целями, к примеру, могут быть: выпуск нового товара, проведение ребрендинга компании или торговой марки, проведение рекламной кампании и т.д.
2. Описание компании заказчика
- Сфера деятельности и масштабы компании, ее миссия и позиции на рынке;
- Описание портфеля брендов компании - с какими торговыми марками работает фирма;
- Список главных компаний-конкурентов;
- Перечень основных конкурентных преимуществ компании и УТП (уникальное торговое предложение).
3. Описание ситуации и последних тенденций рынка
, для которого разрабатывается бренд
- Ценовой сегмент продукта или услуг компании;
- Портрет потребителя (возраст, пол, географические данные, социальный уровень целевой аудитории);
- Тактические и стратегические маркетинговые цели компании (на период от 1 до 3 лет);
- Модель поведения потребителя и описание ситуаций, при которых потребитель совершает покупку;
- Описание основных характеристик существующего бренда, его концепции позиционирования, слогана, маркетинговых коммуникаций, необходимое в случае проведения ребрендинга.
4. Референсы
Перечень примеров аналогичных работ, которые нравятся заказчику в контексте данного проекта.
5. Требования
В данном разделе необходимо прописать все технические и функциональные требования к проекту. А также требования и пожелания заказчика к графике, тексту, цветовой гамме, к стилю, шрифтам,
Основное назначение технического задания — четко определить и зафиксировать требования к объекту закупки. При этом закон устанавливает, что наименование закупки указывается в соответствии с (ч. 4 ст. 23). Каталог утвержден Постановлением Правительства от 08.02.2017 № 145.
При наличии описания закупаемой продукции в КТРУ заказчик обязан:
- описывать объект закупки так, как это предусмотрено КТРУ;
- включить в описание письменное обоснование (если описание отличается от того, которое предусмотрено в КТРУ).
Утвержденными ПП от 05.06.2015 № 555 Правилами предусмотрена обязанность заказчика указывать наименование предмета закупки в процессе обоснования.
Формулировку требований заказчик составляет на основе правил описания объекта закупки (ст. 33). Выделим некоторые обязательные условия:
- указание на эквивалент;
- обоснованность регламентами или иными нормативными документами;
- наличие спецификаций, планов, чертежей, эскизов, изображений (при необходимости);
- новое состояние товара (если нет иной потребности у заказчика);
- требования в отношении , предоставлении гарантии.
Что указать в техническом задании
- общая информация;
- информация о закупаемом объекте;
- требования к поставщикам;
- условия ;
- приложения (допускается по усмотрению заказчика).
Этапы составления технического задания
1. Составить список терминов, определений и сокращений, которые будут использоваться в документе.
2. Предоставить полную информацию о заказчике:
- наименование (официальное название организации с указанием организационно-правовой формы);
- адрес (организации или подразделения, которое отвечает за госзакупку);
- режим рабочего дня в соответствии с внутренним трудовым распорядком.
3. Предусмотреть в информации о закупке сведения:
- или нет, а если да — права и обязанности каждого заказчика (ПП от 28.11.2013 № 1088);
- централизованная закупка, сведения об уполномоченном органе (ч. 1 ст. 26 закона № 44-ФЗ);
- привлечение экспертов, порядок их работы.
4. Перечислить сведения о госзакупке:
- способ определения поставщика (ч. 1 ст. 24);
- обоснование выбранного способа определения поставщика (ч. 5 ст. 24).
5. Перечислить требования к участникам: деловая репутация, наличие у них производственных мощностей.
6. Указать исходные условия: справочная, производственная, опытная информация, которые оказывают влияние при исполнении контракта. Например, что обслуживать закупаемую технику возможно только в утренние часы.
7. Привести сведения об особенностях производственного процесса или архитектурного объекта заказчика, которые повлияют на процесс исполнения контракта. Например, при составлении технического задания на может понадобиться указать, что при доставке необходим подъем на третий этаж вручную из-за отсутствия лифта.
8. Указать точное местоположение объекта, а при необходимости — его полное описание. Это может потребоваться, например, для проектирования инженерных коммуникаций или для точного расчета стоимости ремонта.
9. Привести желаемые результаты (какую проблему хочет решить заказчик) и цели госзакупки (ст. 13 44-ФЗ).
10. Указать источник финансирования.
11. Установить для участников требование соблюдать определенную нормативно-правовую базу, в том числе относящуюся к предмету контракта, условиям исполнения, срокам, гарантийным обязательствам.
12. Определить условия госзакупки (ч. 1 ст. 19).
13. Указать наименование и обоснование объекта госзакупки.
14. Максимально точно и детально описать объект госзакупки (ст. 33).
15. Определить экологические особенности закупаемого объекта.
16. Уточнить объем закупаемых товаров, а также периодичность и срок поставки.
17. Определить гарантийный срок и объем предоставляемых гарантий.
18. Установить требования к упаковке, маркировке, какие условные и специальные обозначения должны быть на ней.
19. Обязать предоставлять подтверждение нового товара или потребности в товаре иного состояния.
20. Определить расходы на эксплуатацию.
21. Определиться, нужны ли монтаж и наладка.
22. Установить порядок поставки и приемки.
23. Указать на необходимость провести испытания, обучение лиц, которые будут использовать закупаемый товар.
Образцы техзаданий для товаров, работ, услуг в 2019 году
Помните, что универсальный образец технического задания по ФЗ-44 не разработан к каждой закупке требуется индивидуальный подход. Только так можно учесть все потребности и особенности заказчика. В качестве ориентира вы можете использовать этот пример технического задания по 44-ФЗ (образец).
Ниже представлен образец технического задания на поставку товара по 44-ФЗ.
Также образец техзадания на выполнение работ по ФЗ-44 вы можете найти в нашем материале о или системы .
Люди по-разному трактуют события и явления, иначе видят решения задач. В ситуациях, когда есть четкий план, любая неправильная трактовка может привести к неожиданным результатам, и скорее всего, вы получите не то что хотели.
Если по написанному вами ТЗ люди делают то что вы хотите получить, и в процессе работы вы не тратите лишних сил на дополнения и переформулирование собственных мыслей - значит вы умеете круто ставить задачи, и у вас есть чему поучиться.
Если даже после прочтения ТЗ исполнитель делает что-то не так, значит, вам нужно пересмотреть свой подход к постановке задач. Даже самый крутой исполнитель, которого вы нанимаете на проект, сделает не то что вам нужно, если вы составили для него плохое техническое задание.
Чтобы написать хорошее ТЗ, вам необходимо представить себя на месте человека, которому оно адресовано. Проиллюстрируем эту мысль.
Мы делаем видеоролики, и пару месяцев назад для нас было в новинку привлекать к работе иллюстраторов. Первые наши технические задания порождали череду вопросов со стороны исполнителя, и нам приходилось созваниваться и объяснять человеку что мы имеем ввиду в таком-то и таком-то пункте. В какой-то момент мы устали, устал иллюстратор. Это был повод задуматься.
Как нам кажется, проблема заключалась в том, что мы формулировали задание слишком общими фразами, что давало иллюстратору повод додумывать и тратить время на поиски не профильной для него информации.
Что было плохо:
- Мы писали список требований к иллюстрациям для анимации, не сопроводив эти требования примерами с картинками и видео. Это был просто текст вроде: “старайтесь рисовать гнущиеся элементы таким образом, чтобы энкор поинты суставов совпадали друг с другом”. Из-за того что мы поленились это проиллюстрировать, наш иллюстратор сделал то что нужно только с третьего раза.
- Мы насыщали ТЗ слишком большим количеством примеров. Иллюстратор буквально тонул в изобилии работ, которые нам нравятся. Не было четкого стилистического ориентира.
- Много текста. Мы писали лишнюю информацию о проекте. Эта информация никак не могла помочь иллюстратору сделать его работу.
- Раскадровка с недостаточными пояснениями о том что будет происходить в слайде.
- Доступность ТЗ только онлайн, на Гугл Диске.
- Мы не имели четкого представления для кого пишем это ТЗ. Мы не вошли в роль этого человека для нашего проекта.
Конечно, можно предположить что человек, нанятый на проект, сам по себе такой, недогадливый и недалекий. Эту мысль мы откидываем сразу. Цель ТЗ - не проверять интеллектуальные способности человека и не играть с ним в угадайку. Когда вы нанимаете кого-то на проект, как правило, это не самые глупые люди, правда? Вы же видели предыдущие работы человека, вы общались с ним перед началом проекта.
Проанализировав свои ошибки, мы поменяли подход к написанию технического задания. Наш последний проект получился очень легким на подъем, во многом это благодаря тому, что мы стали четче и обдуманнее ставить задачи. Мы значительно меньше времени стали тратить на дополнительные объяснения. ТЗ состояло из 43 страниц. Возможно, мы немного перестарались, но первые слова иллюстратора, после прочтения нового ТЗ, были такими:
Суть нашего нового подхода к написанию ТЗ свелась к следующему:
1. Очень кратко и емко нужно описать для кого этот проект, какие задачи нужно решить по окончанию проекта, и какую конкретную задачу решает человек, которого вы нанимаете на проект. Таким образом, он не будет работать вслепую, понимание “что” и “зачем” позволит ему предложить вам лучшие решения.
2. Сопроводить исполнителя всеми необходимыми материалами, которые нужны для работы: референсы, картинки и видео с объяснениями. Наш последний проект был посвящен работе кухонного прибора. В сети без проблем можно найти тысячи статей, картинок и видео о его работе. Мы сэкономили время иллюстратору и собрали самые очевидные и понятные картинки и видео. Это заняло у нас 15 минут. Но мы уверены что сэкономили гораздо больше времени на работу.
3. По пунктам четко и кратко написать все что требуется сделать, чтобы считать работу завершенной.
4. Любые технические требования теперь мы иллюстрируем и записываем видео . Тут важно побольше задавать вопросов себе: что в нашем пайплайне может быть непонятно? Что может породить дополнительные вопросы?
5. Теперь мы скидываем не только текст в формате Гугл Докс, но еще ссылку на скачивание PDF версии ТЗ, чтобы в случае неполадок с интернетом, ТЗ было под рукой.
Некоторые из этих вещей могут показаться естественными, однако осознание этой естественности пришло с опытом. Надеемся что информация в этой статье была полезна. Хотелось бы в комментариях услышать о ваших пониманиях идельного ТЗ.
Как закупить то, что нужно именно вам, не нарушая антимонопольное законодательство? Залог успеха в этом деле - грамотно составленное техническое задание. Читайте в статье, какие неявные нарушения совершают заказчики.
В общем случае при составлении закупочного ТЗ заказчик должен следить за полной безликостью описываемого объекта, то есть в нем не должно быть никаких требований и даже намеков на конкретные товарные знаки, производителей или даже страну происхождения товара.
На самом деле, грамотно подготовить описание объекта закупки, техническое задание по 44-ФЗ, без наличия специальных знаний в конкретной области довольно непросто. Некоторые заказчики даже создают закупку на оказание услуг по подготовке техзаданий. Но и самостоятельно это сделать вполне реально, если внимательно изучить требования к объектам закупки, сопоставить со своими потребностями и точно следовать правилам описания объекта закупки по 44-ФЗ.
Нужно иметь в виду, что в маркировке изделий зашифрованы некоторые характеристики. К примеру, техническим заданием предусмотрен материал «плитка тротуарная» с маркировкой «Классико 1КО.4», техзаданием никаких требований к толщине плитки не предъявлено. Согласно расшифровке маркировки, её толщина составляет 4 см. (последняя цифра маркировки указывает на толщину в смантиметрах). Однако, при исполнении контакта выяснилось, что требовалась плитка толщиной 6 см. От толщины плитки зависит нагрузка, которую она может выдержать. Неграмотно составленное техзадание привело к закупке материала, который не удовлетворяет необходимым требованиям. Поэтому нужно тщательно проверить маркировку всех материалов в техническом задании и указать все основные, важные требования к материалам.
Желательно не копировать описание товаров с различных сайтов . Информация в описании может не быть достоверной и окажется, что заявленным требованиям не соответствует ни один товар. Существует большая вероятность, что под данное описание подходит единственный товар. Это может расцениваться как ограничение конкуренции.
Все требования к характеристикам не должны иметь двусмысленное толкование. Иначе будет очень много запросов на разъяснение. Зачастую бывает так, что при множестве запросов, заказчик не может успеть в установленные сроки ответить на них по существу и времени на корректировку технического задания может не оказаться. На основании этого, иногда заказчик в разъяснении указывает, что достаточно подачи одного лишь согласия, без указания на материалы. В свою очередь, это снижает шансы закупить именно то, что необходимо, так из заявки не видно какие материалы будут использованы при исполнении работ.
Инструкцию по подготовке заявки лучше составлять уже после описания требований к техническим характеристикам. Инструкция должна не запутывать участника, а конкретизировать требования технического задания, во избежание множества запросов от участников. Несоответствие технического задания инструкции, создающее препятствие для подготовки заявки, может спровоцировать направление жалоб в УФАС потенциальными участниками закупки.
Какие ещё требования важно указать в техзадании:
- К гарантийному сроку товара, работы, услуги и (или) объему предоставления гарантий их качества. Заказчик в техническом задании должен установить гарантийный срок не менее, гарантийного срока производителя.
- К гарантийному обслуживанию товара.
- К расходам на эксплуатацию товара.
- К обязательности осуществления монтажа и наладки товара.
- К обучению лиц, осуществляющих использование и обслуживание товара.
Главные правила
- При подготовке документации о закупке обратите внимание на коды Общероссийского классификатора продукции (ОКПД2), относящиеся к объекту закупки. Необходимо чтобы использованный код совпадал с конкретным объектом закупки.
- Помимо положений 44-ФЗ, разрабатывая техзадание следует иметь в виду также требования иных правовых актов, антимонопольных органов, технических норм и стандартов (ГОСТ, ТУ, СНиП и т.д.).
- Товары и материалы, запрашиваемые заказчиком в техническом задании, должны соответствовать объекту закупки и сметной документации (если такая имеется).
- При закупке на строительный подряд необходимо также приложить дефектную ведомость, смету, а в случае капитального строительства (реконструкции, капитального ремонта) также необходимо приложить и проектную документацию.
- Указывайте, что хотите закупить новые товары и материалы (т.е. они не использовались, не находились в ремонте, реставрации, не были восстановлены). Иначе, заказчик может получить б/у товары.
Распространенные вопросы
Вопрос:
Можно ли прописывать на поставку запасных частей указание «оригинальных»?
Ответ:
Можно, если речь идет о продукте, стоящем на гарантии, либо присутствует необходимость обеспечения взаимодействия таких товаров с товарами, используемыми заказчиком, а также в случае закупок запасных частей и расходных материалов к машинам и оборудованию.
Вопрос:
Обязательно ли прописывать идентификационный код закупки в техническое задание?
Ответ:
Идентификационный код закупки указывается в плане закупок, плане-графике, извещении об осуществлении закупки, приглашении принять участие в определении поставщика (подрядчика, исполнителя), осуществляемом закрытым способом, документации о закупке, в контракте, а также в иных документах, предусмотренных настоящим Федеральным законом. В ТЗ его указывать не обязательно.
Вопрос:
Нужно приобрести прибор для научных исследований к уже имеющейся системе из 3-х приборов одного производителя. Необходимо полное совмещение всего в работе. Эквивалент не желателен. Можно не писать эквивалент и указать производителя? Система тонко настраиваемая и дорогая.
Ответ:
Если Ваш случай подходит под «…за исключением случаев несовместимости товаров, на которых размещаются другие товарные знаки, и необходимости обеспечения взаимодействия таких товаров с товарами, используемыми заказчиком…) - можно, в других случаях — нельзя.
Вопрос:
Можно ли в техзадании по капремонту указать узкие показатели, например, цвет стен с конкретным колером, приложить пример композиции из гипсокартона на потолке, конкретную коллекцию плитку без эквивалента, ссылаясь на эстетические предпочтения?
Ответ:
При формировании технического задания заказчики должны руководствоваться требованиями статьи 33 Закона № 44-ФЗ. Цвет стен — это выбор заказчика, это его потребность, не ограничивающая число поставщиков. Макет, эскиз композиции из гипсокартона на потолке — это также потребность заказчика, все исполнители смогут повторить приведённый в документации макет. Коллекция плитки без эквивалента — это нарушение пункта 1 статьи 33 Закона № 44-ФЗ: «Документация о закупке может содержать указание на товарные знаки в случае, если при выполнении работ, оказании услуг предполагается использовать товары, поставки которых не являются предметом контракта. При этом обязательным условием является включение в описание объекта закупки слов «или эквивалент».
Согласно ГОСТу, настоящий стандарт (переизданный в ноябре 1987 г.) устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
Надо быть предельно внимательным и осторожным, создавая его, т.к. зачастую умело (и грамотно) составленное ТЗ определяет успех всей работы. Именно ТЗ согласовывается с Заказчиком, который обычно стремится внести как можно больше противоречивых и завышенных требований. Задача же Исполнителя – наоборот, облегчить себе жизнь. Но после того, как подписи с обеих сторон поставлены, переигрывать что-либо поздно.
Общие положения
Техническое задание оформляют на листах формата А4 и/или А3, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.Для внесения изменений и дополнений в техническое задние на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания.
Техническое задание должно содержать следующие разделы:
- наименование и область применения;
- основание для разработки;
- назначение разработки;
- технические требования к программе или программному изделию;
- технико-экономические показатели;
- стадии и этапы разработки;
- порядок контроля и приемки;
- приложения.
Раздел: Наименование и область применения
В разделе Наименование и область применения указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.В разделе Основание для разработки должны быть указаны:
- документ (документы), на основании которых ведется разработка;
- организация, утвердившая этот документ, и дата его утверждения;
- наименование и (или) условное обозначение темы разработки.
Раздел: Назначение разработки
В разделе Назначение разработки должно быть указано функциональное и эксплуатационное назначение программы или программного изделия. Ограничиться здесь можно одной-двумя фразами. Главное – четко определить, для чего нужна эта программа.Например: Программа представляет собой ядро автоматизированного рабочего места (АРМ) разработчика непрерывных линейных систем автоматического управления (САУ), позволяющее пользователю решать задачи анализа простых моделей.
Раздел: Технические требования к программе или программному изделию
В этом разделе должны содержаться следующие подразделы:- требования к функциональным характеристикам;
- требования к надежности;
- условия эксплуатации;
- требования к составу и параметрам технических средств;
- требования к информационной и программной совместимости;
- требования к маркировке и упаковке;
- требования к транспортированию и хранению;
- специальные требования.
Раздел:Требования к функциональным характеристикам.
Здесь должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т.п.Например : Программа должна позволять … вычислять … строить… создавать …
Исходные данные: текстовый файл с заданной …
Выходные данные: графическая и текстовая информация - результаты анализа системы…; текстовые файлы - отчеты о … диагностика состояния системы и сообщения о всех возникших ошибках.
Требования к надежности. Должны быть указаны требования к обеспечению надежного функционирования (обеспечение устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.).
Здесь "выгадать" что-то сложно. В лучшем случае может пройти вариант, при котором ваша программа работает только с абсолютно корректными данными. Обычно Заказчик на это не идет, но попробовать можно.
Например: Программа должна работать с заданной расширенной матрицей инциденций исследуемого графа в соответствии с алгоритмом функционирования, выдавать сообщения об ошибках при неверно заданных исходных данных, поддерживать диалоговый режим в рамках предоставляемых пользователю возможностей.
Условия эксплуатации. Должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.
С этим пунктом сложностей обычно не возникает. К сожалению, пункт о профессиональности пользователя Заказчиком подразумевается обязательно. Это, конечно, лишний повод придраться к вашей программе. Впрочем, здесь можно ограничиться фразами вида "Условия эксплуатации программы совпадают с условиями эксплуатации ПЭВМ IBM PC и совместимых с ними ПК", "Программа должная быть рассчитана на непрофессионального пользователя." и т.п.
Требования к составу и параметрам технических средств. Указывают необходимый состав технических средств с указанием их технических характеристик.
Здесь главное – ничего не забыть и все предусмотреть, с одной стороны (а то подсунут какой-нибудь IBM PC/XT с монохромным дисплеем и без мыши), а с другой – не переборщить с повышенными требованиями, иначе Заказчик найдет более покладистого Исполнителя.
Например: Необходимо наличие IBM PC - совместимого ПК с графическим адаптером EGA (VGA). Необходимое дисковое пространство – не менее 600 Кб, объем свободной оперативной памяти - не менее 400 Кб. Желательно наличие драйвера EMS и манипулятора типа "мышь".
Требования к информационной и программной совместимости. Особенности те же, что и в предыдущем пункте. Здесь должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования. При необходимости должна обеспечиваться защита информации и программ.
Например: Программа должна работать автономно под управлением ОС MS DOS версии не ниже 3.3. Базовый язык программирования - Turbo Pascal 6.0.
Требования к маркировке и упаковке и требования к транспортированию и хранению являются достаточно экзотическими. В общем случае здесь указывают требования к маркировке программного изделия, варианты и способы упаковки. А в требованиях к транспортированию и хранению должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.
Специальные требования – это весьма ответственная вещь. Их лучше, по возможности, всячески избегать. И заявить об этом сразу.
Например: Специальных требований к временным характеристикам программы не предъявляется. Специальных требований к емкостным характеристикам программы не предъявляется.
Технико-экономические показатели. Этот самый сложный для программиста пункт есть далеко не всегда. Он нужен прежде всего тогда, когда вашей целью является обоснование огромной эффективности и важности выполняемой работы. На Заказчика этот пункт действует, обычно, очень хорошо. По крайне мере, это лучшее обоснование сроков и денежных сумм разработки.
В этом разделе должны быть указаны: ориентировочная экономическая эффективность, предполагаемая годовая потребность (например: предполагаемое число обращений к комплексу в целом в год - 365 сеансов работы), экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами.
Помимо этого, желательно привести определение как сметной стоимости разработки программы, так и определение трудоемкости программирования.
Стадии и этапы разработки (об этом подробнее будет сказано ниже) устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, сроки разработки и определяют исполнителей.
Здесь описываются стандартные этапы. Главное – грамотно определиться со сроками. По возможности, старайтесь равномерно распределить этапы по срокам (и суммам). Помните, что не все проекты доживают до последней стадии. А отчеты должны быть по каждому этапу. Помните также, что больше всего времени займет рабочий проект. Если вы не успеете сделать в срок документацию, то Заказчик имеет полное право вообще не принять работу со всеми вытекающими последствиями.
Основными и непременными стадиями и этапами являются само техническое задание, эскизный проект, технический и рабочий проекты.
Эскизный проект. На этой стадии детально разрабатываются структуры входных и выходных данных, определяется форма их представления. Разрабатывается общее описание алгоритма, сам алгоритм, структура программы. Разрабатываются план мероприятий по разработке и внедрению программы.
Технический проект. Содержит разработанный алгоритм решения задачи а также методы контроля исходной информации. Здесь же разрабатываются средства обработки ошибок и выдачи диагностических сообщений, определяются формы представления исходных данных и конфигурация технических средств.
Рабочий проект. На этой стадии осуществляется программирование и отладка программы, разработка программных документов, программы и методики испытаний. Подготавливаются контрольно-отладочные примеры. Окончательно оформляются документация и графический материал. Обычно указывается, что в ходе разработки программы должна быть подготовлена следующая документация:
Oтекст программы;
Oописание программы;
Oпрограмма и методика испытаний;
Oописание применения;
Oруководство пользователя.
Это - стандартные требования. Если Заказчик соглашается с тем, что можно представить не весь этот список, то это означает несерьезность его намерений в отношении вас и вашего продукта.
Графического материала может и не быть. Особенно тогда, когда вы не собираетесь докладывать о результатах своей работы. Но для серьезных проектов этот пункт обязателен.
Например: В ходе разработки программы должен быть подготовлен следующий графический материал:
Oтехнико-экономические показатели;
Oструктура программы;
Oформат представления входных данных программы;
Oобщая схема алгоритма (2 листа);
oосновные вычислительные алгоритмы;
oпример работы программы.
В разделе Порядок контроля и приемки должны быть указаны виды испытаний и общие требования к приемке работы. Если возможно, то в этом пункте укажите, что "контроль и приемка разработки осуществляются на предоставляемой Заказчиком технике", иначе вас могут обязать принести технику с собой.
Например: Контроль и приемка разработки осуществляются на основе испытаний контрольно-отладочных примеров. При этом проверяется выполнение всех функций программы.
В Приложениях к техническому заданию, при необходимости, приводят:
перечень научно-исследовательских и других работ, обосновывающих разработку;
Схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке;
Другие источники разработки.
