- Что такое техническое задание
- Что такое техническое задание и как его разрабатывать
- Iso/iec/ieee 29148
- Ведите историю правок
- Дайте подрядчику общую информацию
- Заказчик
- Исполнитель
- Как составить техническое задание
- Когда тз не нужно
- Контрольные вопросы
- Кто должен составлять техническое задание
- Опишите требования к проверке проекта
- Переводим на понятный язык
- Покажите конкурентов
- Порядок документирования требований
- Проблема
- Прописывайте каждую деталь
- Распишите сценарии использования продукта
- Рекомендации по составлению тз
- Совместно
- Составляйте список терминов и сокращений
- Технико-коммерческое предложение
- Технические требования
- Технический проект
- Техническое задание
- Эксплуатация
- Выводы
Что такое техническое задание
Техническое задание — это то, с чего начинается качественный функциональный продукт. По крайней мере, если таковым является само ТЗ. Если документ будет составлен непрофессионально и без должного внимания, результат окажется соответствующим.
Учитывая характер целевой аудитории блога и общие тренды, скорее всего, имеет смысл описывать технические задания конкретно на цифровые продукты. Во многом так и будет, но нельзя забывать, что и самые обычные, «аналоговые», продукты тоже требуют документации.
Что такое техническое задание и как его разрабатывать
Рассмотрим что же такое техническое задание, для чего его разрабатывают и в соответствии с какими требованиями.
ТЗ – основополагающий документ, которым руководствуются разработчики и проектировщики, приступая к разработке нового изделия. Оно определяет основные направления разработки: конструкции и принципа работы будущего изделия. ТЗ заявляет, с одной стороны, о потребностях общества в новых изделиях, с другой – о технических и технико-экономических характеристиках изделия.
Техническое задание является начальным этапом работ и составляется на все разработки и виды работ, необходимые для создания нового изделия. Оно может предшествовать научно-исследовательским и опытно-конструкторским работам (НИОКР) по разработке средств механизации и автоматизации, отдельных узлов и систем, технологии, измерительных средств, средств контроля и других изделий (выполнение работы, оказание услуги, промышленный комплекс, прибор, машина, аппарат, система управления, информационная система, нормативная документация (например, стандарт) и т. д.).
Требования, включаемые в ТЗ, должны основываться на современных достижениях науки и техники, на итогах выполненных научно-исследовательских и экспериментальных работ. ТЗ должно устанавливать следующие показатели разрабатываемого изделия:
— основное назначение, технические и тактико-технические характеристики, уровень стандартизации и унификации;
— технико-экономические показатели;
— патентно-правовые показатели;
— специальные требования к изделию и др.
В технических заданиях оговариваются этапы разработки и сроки выполнения каждого этапа, сроки разработки в целом. Качество ТЗ обеспечивается объемом и полнотой сбора материалов, необходимых для разработки. При разработке используются следующие материалы:
— научно-техническая информация;
— патентная информация;
— характеристика рынка сбыта;
— характеристика производства, на котором изделие будет изготавливаться (технологическая оснащенность, квалификация кадров, технологическая дисциплина, уровень организации труда и др.).
При разработке ТЗ разработчик учитывает информацию об аналогичной продукции, содержащуюся в базах данных (общероссийской и региональных), созданных в Госстандарте России на основе каталожных листов продукции.
Техническое задание разрабатывается, как правило, организацией-разработчиком изделия. Сформулировать задачу максимально полно и грамотно, обосновать необходимость её решения – главная цель ТЗ. Исполнитель выполняет его в контакте с заказчиком. Обязанность заказчика – предъявить разработчику исходные данные для разработки изделия.
ТЗ разрабатывают и утверждают в порядке, установленном заказчиком и разработчиком. К разработке ТЗ могут привлекаться другие заинтересованные организации (предприятия): изготовитель, торговая (посредническая) организация, страховая организация, организация-проектировщик, монтажная организация и др.
Для подтверждения отдельных требований к продукции, в том числе требований безопасности, охраны здоровья и окружающей среды, а также оценки технического уровня продукции, ТЗ может быть направлено разработчиком или заказчиком на экспертизу (заключение) в сторонние организации. Решение по полученным заключениям принимают разработчик и заказчик до утверждения ТЗ.
К техническому заданию прилагаются схемы и эскизы по конструкции будущего изделия, а для технологических разработок – технологические и технико-экономические показатели существующего производства. Техническое задание должно содержать максимум информации, облегчающей работу над изделием и сокращающей сроки разработки.
Несмотря на всю свою важность, содержание ТЗ мало регламентировано нормативными документами. Требования к содержанию и порядку построения документа зависят от направления разработки и содержатся в следующих документах:
ГОСТ Р 15.201-2000. Система разработки и постановки продукции на производство (СРПП). Продукция производственно-технического назначения. Порядок разработки и постановки продукции на производство (приведены общие требования и краткие рекомендации по разработке).
ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению (кратко изложено содержание ТЗ);
ГОСТ 34.602-89. Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы (достаточно подробно изложены состав и содержание ТЗ);
ГОСТ 25123-82. Машины вычислительные и системы обработки данных. Техническое задание. Порядок построения, изложения и оформления (приведен порядок построения ТЗ). Обобщая требования этих стандартов, порядок построения, изложения и оформления ТЗ можно свести к последовательности, представленной в таблице ниже.
Раздел | Перечень рассматриваемых вопросов |
Наименование и область применения (использования) | Наименование и условное обозначение продукции. Краткая характеристика области техники, в которой предполагается использование продукции. Возможность использования разрабатываемой продукции для поставки на экспорт |
Основание для разработки | Полное наименование документа, на основании которого разрабатывают продукцию (договор, контракт и т.п.). Организация, утвердившая этот документ и дата его утверждения. Наименование и условное обозначение темы разработки |
Цель и назначение разработки | Эксплуатационное и функциональное назначение и перспективность продукции |
Источники разработки | Перечень научно-исследовательских и экспериментальных работ. Перечень экспериментальных образцов или макетов |
Технические (тактико-технические) требования | Состав продукции и требования к его устройству. Показатели назначения. Требования к надежности. Требования к технологичности. Требования к уровню унификации и стандартизации. Требования безопасности. Эстетические и эргономические требования. Требования к патентной чистоте. Требования к составным частям продукции, сырью, исходным и эксплуатационным материалам. Условия эксплуатации (использования). Требования к маркировке и упаковке. Требования к транспортированию и хранению. Специальные требования. Дополнительные требования (например, требования к оснащению изделий устройствами для обучения персонала (тренажерами, другими устройствами аналогичного назначения) и документацией на них, требования к сервисной аппаратуре, стендам для проверки изделия и его элементов. |
Экономические показатели | Ориентировочная экономическая эффективность и срок окупаемости затрат. Лимитная цена. Предполагаемая годовая потребность в продукции. Экономические преимущества разрабатываемой продукции по сравнению с аналогами |
Стадии и этапы разработки | Стадии разработки, этапы работ и сроки их выполнения (сроки, указываемые в техническом задании, являются ориентировочными, основные сроки указываются в плане работ или в договоре); предприятие-изготовитель разрабатываемого изделия; перечень документов, представляемых на экспертизу, а также стадии, на которых она проводится, и место проведения |
Порядок контроля и приемки | Перечень конструкторских документов, подлежащих согласованию и утверждению, и перечень организаций, с которыми следует согласовывать документы. Общие требования к приемке работ на стадиях разработки; число изготавливаемых опытных образцов продукции |
Приложение к техническому заданию | Перечень научно-исследовательских и других работ, обосновывающих необходимость проведения разработки. Чертежи, схемы, описания, обоснования, расчеты и другие документы, которые должны быть использованы при разработке. Перечень заинтересованных организаций, с которыми согласовывают конкретные технические решения в процессе разработки продукции. Перечень нового технологического оборудования, необходимого для выпуска новой продукции |
Допускается уточнять содержание разделов, вводить новые разделы или объединять некоторые из них.
В ТЗ рекомендуется предусматривать следующие положения:
— прогноз развития требований на данную продукцию на предполагаемый период ее выпуска;
— рекомендуемые этапы модернизации продукции с учетом прогноза развития требований;
— соответствие требованиям стран предполагаемого экспорта с учетом прогноза развития этих требований;
— характеристики ремонтопригодности;
— возможность замены запасных частей без применения промышленной технологии;
— доступность и безопасность эффективного использования продукции инвалидами и гражданами пожилого возраста (для соответствующей продукции, предусмотренной законодательством Российской Федерации).
Техническое задание оформляют в соответствии с общими требованиями к текстовым конструкторским документам по ГОСТ 2.105-95 (ЕСКД. Общие требования к текстовым документам) на листах формата А4 , как правило, без рамки и основной надписи. Номера листов (страниц) проставляют в верхней части листа над текстом.
Значения показателей, норм и требований указывают, как правило, с предельными отклонениями или максимальным и минимальным значениями. Если эти показатели, нормы, требования однозначно регламентированы НТД, в ТЗ следует приводить ссылку на эти документы или их разделы, а также дополнительные требования, учитывающие особенности создаваемой системы. Если конкретные значения показателей, норм и требований не могут быть установлены в процессе разработки ТЗ, следует сделать запись о порядке установления и согласования этих показателей, норм и требований: «Окончательное требование (значение) уточняется в процессе … и согласовывается протоколом с … на стадии …».
На любом этапе разработки продукции при согласии заказчика и разработчика в ТЗ или документ, его заменяющий, могут быть внесены изменения и дополнения, не нарушающие условия выполнения обязательных требований. Согласование и утверждение дополнений к ТЗ проводят в порядке, установленном для самого ТЗ. Изменения к ТЗ не допускается утверждать после представления изделия на приемо-сдаточные испытания. Регистрация, учет и хранение ТЗ и дополнений к нему проводят в соответствии с требованиями ГОСТ 2.501-88 (ЕСКД. Правила учета и хранения).
В качестве ТЗ может быть использован иной документ, содержащий необходимые и достаточные требования для разработки продукции и взаимопризнаваемый заказчиком и разработчиком. В случае инициативной разработки продукции ТЗ (или заменяющий его документ), базируется на результатах исследования рынка продукции, а также патентных исследований по ГОСТ Р 15.011- 96 (СРПП. Патентные исследования. Содержание и порядок проведения)
Не допускается включать в ТЗ требования, которые противоречат законам Российской Федерации и обязательным требованиям.
Составление технического задания (ТЗ) – сложная и ответственная задача: многие данные ещё не известны, но то, как задание будет составлено, способно облегчить или затруднить последующее проектирование. Не зря считается, что грамотное ТЗ – это половина успеха в решении задачи, а время, затраченное на подготовку ТЗ – одно из лучших вложений, которые можно сделать в период проектирования.
Iso/iec/ieee 29148
Разработанный Международной организацией по стандартизации ISO, данный современный стандарт пригоден для использования помимо всего прочего в международных проектах.
Последняя редакция — ISO/IEC/IEEE 29148:2022, но, к сожалению, она отсутствует в открытом доступе, поэтому возьмём за основу предыдущую, от 2022 года.
По аналогии с ГОСТами, стандарт содержит два раздела. Один из них, SyRS — System Requirements Specification — определяет общие требования к построению систем, их принципам и характеру взаимодействия пользователя с ними. По похожей схеме составлен ГОСТ 34.
SRS — Software Requirements Specifitaion — по аналогии с ГОСТ 19, содержит требования к конечному программному продукту.
Общая схема строится следующим образом:
- Введение. Назначение продукта или системы, содержание, обзор функций и пользователей.
- Системные требования. Требования к юзабилити и производительности системы, состоянию, физическим характеристикам, окружению и безопасности, правилам. Для приложений — требования к внешним интерфейсам, к производительности, структуре БД, функциям и юзабилити.
- Тестирование и проверка. Процедуры тестирование по каждому из пунктов предыдущего раздела.
- Приложения. Термины, схемы, история правок.
Ведите историю правок
В начале документа создайте таблицу со столбцами “дата”, “описание”, “автор”. В ней записывается история изменений документа, благодаря которой легко понять, на каком этапе возникло то или иное требование, дополнение, противоречие.
Дайте подрядчику общую информацию
Подрядчик должен понимать, чем занимается компания и кто ваша целевая аудитория. Так исполнитель сможет глубже вникнуть в поставленную задачу и избежать элементарных ошибок. При озвучивании идеи важно отметить конкурентные преимущества и особенности проекта.
Заказчик
В этом случае исполнитель будет четко понимать, что и когда ему потребуется делать. В результате получится точно рассчитать стоимость работ и срок, отведенный на их выполнение. Однако иногда составитель ТЗ не понимает того, что именно должен предоставить им исполнитель, из-за чего с составлением ТЗ возникают проблемы.
Исполнитель
Исполнитель, занимающийся составлением ТЗ, присылает заказчику бриф с вопросами по задаче. Так специалист выясняет цель работы и свою пользу для клиента. После этого проходит интервью, и в режиме диалога стороны уточняют рабочие нюансы. Исполнитель изучает конкурентов и целевую аудиторию, чтобы добавить эту информацию в техническое задание.
Такой способ составления ТЗ удобен, когда заказчик полностью доверяет исполнителю, а исполнитель достаточно компетентен, чтобы разобраться в задаче самостоятельно.
Как составить техническое задание
Главные требования к техническому заданию — это продуманность и полнота. Так как составители не всегда способны им следовать, были разработаны общие стандарты разработки ТЗ.
В вакансиях на должность системного аналитика или технического писателя можно встретить требование: знание ГОСТ 19 и ГОСТ 34. Из названия легко понять, что это общегосударственные стандарты, образцы разработки технических заданий на территории России.
Эти два ГОСТа имеют отношение только к программным комплексам — к сайтам, приложениям и системам автоматизации. Другие ТЗ придется писать по совершенно другим правилам.
Когда тз не нужно
Техническое задание требуется не каждому продукту. Иногда достаточно предпроектного исследования, чтобы изучить потребности клиентов вместе с аналитиком. После этого следует решать, есть ли необходимость в ТЗ.
Зачастую более гибкие методологии, работающие на создание продукта, позволяют успешно и оперативно использовать ресурсы компании. Например, сначала формируется маленький прототип, который тестируют, и на основании обратной связи от клиентов корректируют до полноценного продукта.
Контрольные вопросы
А здесь перечислю ответы на самые часто встречающие вопросы от заказчиков:
1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? — Да, даже несколько.
2) А что, в ТехЗадание не входит описание нужных страниц, количества кнопок, используемых библиотек, гайдлайнов и т.д.? — В само ТЗ нет, но в Приложения вы можете все это поместить, разумеется скорректировав все это с вышеописанными целями, ограничениями и способами дальнейшей оценки достигнутого результата.
3) Так может оно мне такое и не нужно? — Возможно, сегодня тысячи сайтов делаются вообще без ТЗ, также, как тысячи людей в мире прекрасно живут, будучи слепыми от рождения. Но если вы хотите видеть — куда вы вообще движетесь, осознанно принимать решения и самостоятельно оценивать полученные результаты — то без ТЗ тут не обойтись.
4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умеюмне некогдапросто не хочу его делать сам. Как же быть? — Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки.
Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.
5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? — Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) — то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL — уже нет.
6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? — Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа.
Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» — установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз:
Кто должен составлять техническое задание
Чтобы понять, как составить техзадание, важно определиться с тем, кто именно это будет делать. На этот вопрос нет однозначного ответа — ТЗ для задачи может составить заказчик или исполнитель, в отдельных случаях — это совместная работа.
Опишите требования к проверке проекта
На этапе составления техзадания продумайте чек-лист, по которому заказчику будет понятна степень успешности реализованного проекта. Так можно быстро оценить проделанную работу и не забыть о значимых нюансах.
Бывают случаи, когда исполнитель работает за фиксированную плату и некий процент от продаж. Например, вы заказали на таких условиях настройку таргетированной рекламы у фрилансера. Чтобы честно оценить его работу, вам поможет сервис сквозной аналитики от Calltouch.
Переводим на понятный язык
1) ТехЗадание — оно ставит задачу. А значит оно должно идти перед прототипом, скетчем, тестом, дизайн-проектом, потому что любой майндмеп, диаграмма потоков данных, архитектура — это уже выполнение некой задачи, это ответ на вопрос. А до того, как сам вопрос еще не задан, не сформулирован и не подписан всеми сторонами — любой ответ будет априори неправильным, не так ли?
2) Собственно из первого пункта логично вытекает и новый — сам текст ТЗ обязан начинаться с главы «Цели и задачи», четко формулирующей, какие бизнес-цели преследует вся эта очередная попытка повысить энтропию в мире. Бесцельное задание, которое не решает никаких проблем, не достигает ничего и делается «от скуки» — официально не считается Техническим Заданием, а с этого момента находится в статусе «обычная бумажка».
3) Как же вам понять, решает ли предложенная дизайн-концепция или интерактивный прототип, а то и готовый к употреблению сайт — вышеизложенную задачу бизнеса? Ничего не поделаешь, придется опять вернуться к определению: «определяет… ожидаемые результаты и сроки выполнения.
То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет». То есть ТЗ без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия — быть не может. Бриф может, или прототип, или еще любая абсурдная бумажка, но только не ТехЗадание.
Отсюда делаем вывод, что в настоящем ТЗ обязательно должна быть глава «Порядок приемки и оценки», когда эти самые показатели берутся, замеряются, и стороны либо пожимают друг другу руки, либо отправляют проект на переделку.
4) ТехЗадание должно обязательно согласоваться с общим бизнес-планом заказчика, с его стратегией развития бизнеса и анализом сегмента рынка. Именно все это позволит установить правильные цели, вывести точные метрики, по которым затем адекватно провести приемку готового инфопродукта. Отсутствие у заказчика бизнес-плана автоматически гарантирует непрофессиональное выполнение Технического Задания.
Знает ли студия на аутсорсе бизнес-цели и измеримые показатели бизнеса лучше его владельца? Очевидно, что нет, а значит правильное ТЗ должно писаться представителями Заказчика, а не наемными работниками Исполнителя. Абсурд, когда исполнитель сам себе ставит задачу, затем сам себе придумывает способы ее оценки, и в конце сам же выставляет себе итоговую отметку за сделанную работу.
5) Каждое внесение правок в готовое ТЗ должно стоить денег. Нельзя бесплатно и бесконечно править «Конституцию вашего проекта» только потому, что одна из сторон передумала, не выспалась, внезапно решила сэкономить и т.д. Цена каждого изменения в ТЗ должна также четко прописываться заранее в соответствующей главе.
Кстати, по идее точно также каждая правка в дизайне или внесение изменений в список страниц или функций должна иметь четкую цену, которая оплачивается заранее, до начала внесения данного изменения. Лично я предлагаю любую редактуру утвержденного ТЗ оценивать в 30% от всего бюджета проекта, но вы можете поступать иначе.
Стоит ли упоминать, что в ТЗ просто необходимо заранее указывать сроки и общий бюджет на разработку, а также список всех существующих ресурсов и ограничений? — Нет, это будет уж слишком очевидно.
Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? — написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.
Покажите конкурентов
ТЗ должно содержать ссылки на похожие проекты с дополнительным описанием. Это поможет исполнителю оценить удачные примеры чужих разработок и избежать характерных проблем при реализации. Кроме того, выявление чужих особенностей позволяет создать собственное уникальное решение.
Порядок документирования требований
Выйдем немного за пределы тематики и скажем несколько слов о том, из чего состоит весь процесс документального сопровождения продукта. Ведь он не ограничивается техническим заданием. Сложность сопроводительной документации растёт вместе со сложностью и масштабом продукта.
Разработка лендинга на Тильде или запуск таргетированной рекламы Вконтакте радикально отличаются от создания высоконагруженной биллинговой системы банка. Если первые два продукта способен создать один человек, то последний может потребовать команды из нескольких десятков специалистов из многих областей.
Проблема
Дело в том, что когда существует конкретный формат, а также четкое и внятное определение какого-либо термина, то все манипуляции и подмены его на собственные брифы, прототипы, на ходу придуманные опросники, описания и просто входящие заявки — выглядят, по меньшей мере, непрофессионально. Поэтому с научного определения нашего понятия и начинаем:
Техническое задание — исходный документ на проектирование технического объекта (изделия). ТЗ устанавливает основное назначение разрабатываемого объекта, его технические характеристики, показатели качества и технико-экономические требования, предписание по выполнению необходимых стадий создания документации (конструкторской, технологической, программной и т. д.) и её состав, а также специальные требования. Техническое задание является юридическим документом — как приложение включается в договор между заказчиком и исполнителем на проведение проектных работ и является его основой: определяет порядок и условия работ, в том числе цель, задачи, принципы, ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет. Все изменения, дополнения и уточнения формулировок ТЗ обязательно согласуются с заказчиком и им утверждаются. Это необходимо и потому, что в случае обнаружения в процессе решения проектной задачи неточностей или ошибочности исходных данных возникает необходимость определения степени вины каждой из сторон-участниц разработки, распределения понесенных в связи с этим убытков. Техническое задание, как термин в области информационных технологий – это юридически значимый документ, содержащий исчерпывающую информацию, необходимую для постановки задач исполнителям на разработку, внедрение или интеграцию программного продукта, информационной системы, сайта, портала либо прочего ИТ сервиса.
Прописывайте каждую деталь
Сайт — это не только код, но и мощности, на которых он работает. В первую очередь, определите, на каком сервере будет размещён сайт, какие у него параметры: ёмкость, оперативная память и другие.
Пропишите периодичность и порядок оплаты сервера — передаст ли заказчик обязанность бухгалтерии или же вы будете получать ежемесячную абонентскую плату, из которой сами должны распределять средства на те или иные нужды.
Позаботьтесь о пользователях. Продумайте, какими браузерами и устройствами они пользуются, какое у них разрешение. Адаптируйте сайт, если речь идёт о нём, под различные технические характеристики устройств.
Не оставляйте белых пятен. При наведении на рисунок, он скрывается? Хорошо, но уточните — он уезжает влево? Становится прозрачным? С какой скоростью? Как он появляется опять? Малейшая деталь без чёткой логики ставит разработчиков и весь процесс в тупик.
Распишите сценарии использования продукта
Сценарий нужен для понимания принципа работы продукта. Например, если область работы касается IT, сценарий отвечает на вопрос «Как будет вести себя пользователь?» и дает понимание главных функций сайта.
Рекомендации по составлению тз
Правильное ТЗ составляют по универсальному шаблону. Он формируется из следующих элементов.
Совместно
Совместное формулирование ТЗ начинается с того, что заказчик озвучивает исполнителю требования относительно будущего задания. Подрядчик, в свою очередь, предлагает, как улучшить проект, и только после этого составляется техническое задание. Этот способ, как и предыдущий, работает на доверии, этичности и профессионализме сторон.
Составляйте список терминов и сокращений
Это правило грамотного подхода к формированию документа. Основной текст предваряется словарём, в котором записаны специальные термины, не являющиеся общеупотребимыми. Особенно уделите внимание тем аббревиатурам и словам, которые применяются только в данному проекту.
Технико-коммерческое предложение
Здесь речь заходит о действительно крупных проектах. В противном случае нецелесообразно прилагать излишние усилия к созданию подобных документов.
ТКП разрабатывается в рамках маркетинговых мероприятий, когда продукт предлагается потенциальным заказчиком. Если у вас есть собственная концепция, готовая к внедрению или масштабированию, на её основе можно сделать предложение.
Документ содержит не просто идею и общее описание, но некоторые технические подробности. На их основе заказчику удобнее принимать решение, так как он сразу может увидеть, насколько характеристики продукта согласуются с той инфраструктурой, которая есть в наличии.
Бесполезно предлагать промышленные системы вентиляции маленьким кофейням. В других случаях помещение может отвечать требованиям, но электроснабжение окажется несовместимым с требованиями оборудования по питанию.
Технические требования
Если в ТКП требования приводятся самые основные, для ознакомления, то при заинтересованности заказчика с ним составляются уже более детализированные перечни требований.
Технический проект
Этап «живого» проектирования продукта. Здесь начинаются активные действия по разработке решений согласно ТЗ. В ходе работы уточняются и проясняются отдельные нюансы, требования, доработки.
В соответствии с практическими наработками, составляются новые задания и требования — частные технические задания по отдельным подсистемам (ЧТЗ).
Техническое задание
Собственно, предмет статьи. Предварительные сведения даны в предыдущих пунктах, а ценные советы ждут вас в следующем разделе.
Эксплуатация
Важно помнить, что после сдачи проекта стороны распределяют между собой обязанности по поддержанию работоспособности системы. Это тоже должно быть прописано — например, в техническом задании, если не предусмотрено другого порядка.
Перед эксплуатацией и во время неё создаются различные регламенты, описания сервисов, инструкции. Актуализируются текущие версии документов.
Когда условия работы или технологии модифицируются, приходится вносить правки в документы и внедрять изменения в продукт.
Выводы
Техническое задание — важный этап подготовки к работе над проектами. Его составление помогает заказчику сформулировать суть задачи, а исполнителю дает понять, как ее выполнить. Составить ТЗ может заказчик, исполнитель или заказчик вместе с исполнителем. Выбор варианта сотрудничества зависит от сложности работ и навыков специалиста.
