Как сделать простое техническое задание и не потерять деньги и нервы / Хабр

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

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

Что было раньше

Мы небольшая региональная компания, занимающаяся заказной веб-разработкой, которая, как и многие другие, в самом начале бралась за проекты, не особо представляя как их делать. Но подобный “вынужденный рост” крайне положительно сказался на членах команды, благодаря огромному желанию развиваться, и помог прокачать и скилы, и голову. Разработка становилась все качественнее, но техническое задание оставалось на самом низком уровне. Как и большинство начинающих студий, мы использовали обычный описательный подход к ТЗ: какие страницы, что должно отображаться, некоторые технические моменты, да и все, пожалуй.

На многих проектах это выливалось в следующие проблемы:

1. Описан внешний вид, но не принцип работы. Простой пример с корзиной интернет-магазина. В ТЗ было написано “Кнопка “Оформить заказ”. Но что должно произойти, когда пользователь нажал на эту кнопку? По каким правилам формируется номер заказа? Какой статус ему присваивается? Куда идет переадресация? А если один из товаров раскупили, пока пользователь оформлял заказ? На эти и многие другие вопросы в ТЗ ответов не было, а ведь это лишь один небольшой элемент. Подобные неописанные моменты приводили к спорам с Заказчиком, сильному выходу из бюджета и прочим неприятным последствиям.
2. Отсутствие переиспользуемых блоков. На многих сайтах есть одинаковые блоки, используемые в разных местах, например, превью товара. Но данный блок в результате описывался в каждой странице. Это очень плохо по нескольким причинам. Во-первых, при необходимости изменения надо вносить сразу в нескольких местах, можно что-то упустить и будет несоответствие. Во-вторых, даже при одинаковых элементах в превью, заказчик может потребовать сделать их по-разному, что влечет за собой дополнительные затраты.
3. ТЗ не коррелирует с задачами для команды. Чем дальше постановка задачи от реальности, тем ниже будет качество на выходе. Это еще одна проблема, которую хотелось решить.
   

Новый подход

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

ТЗ состоит из следующих разделов:

1. Введение
2. Статика
3. Динамика
4. Задачи
5. Административная панель
6. Общие технические требования

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

Введение и подготовка к реализации

• Кратко описываем проект, его цели, ЦА, оставляем ссылки на предпроектную аналитику.
• Описываем процесс инициализации проекта: настройку окружения для разработчиков и подход к разработке концепции дизайна для дизайнеров.
• Принципы адаптивности или разбиения на версии. Последнее время в своей работе мы придерживаемся следующего принципа — “адаптивь все, что адаптивится”. Иначе говоря, в начале работы над ТЗ мы понимаем, какой сложный функционал нам нужен (или может понадобиться в ближайшем будущем) и вместе с дизайнером и front-end разработчиком придумываем способы его заадаптивить. При новом подходе отрицательных результатов еще не было, поэтому отдельные версии описывать не приходилось.

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

Статика

Как мы все знаем, страницы могут содержать либо статическую информацию, либо динамическую, присылаемую с сервера. Подразделы статики — страницы проекта. Каждую страницу мы разбиваем на блоки. Если блок статический, то мы описываем его суть и вид контента. Например, описание одного из блоков страницы “О компании” может выглядеть так. “Основные преимущества компании. 5-6 иконок с описаниями.” Это очень краткое, но достаточное для точной оценки описание блока. При описании статики главная цель — задать четкие рамки. Сделать адаптив иконок не составит труда, а с графиком или таблицей все не так просто и однозначно. Но при этом нам не важно какие именно будут иконки и подписи к ним.

Если же страница содержит блок, который можно “вынести за скобки”, то в месте его интеграции мы пишем “Интегрируется функционал “NAME”, а сам функционал описываем в разделе “Динамика”.

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

Динамика

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

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

Задачи

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

Административная панель

Здесь описываем структуру, модели и поля. Разбиение идет по разделам, например, “Товары”, “Каталог”, “Заказы” и т.д. Описываем что разные роли пользователей могут просматривать, что редактировать.

Общие технические требования

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

1. SEO-требования к тегам и микроразметке
2. Правила транслитерации
3. Ручное и автоматическое тестирование
4. Поддерживаемые браузеры
5. …

Новые версии

При описании новых версий необходимо вносить изменения в существующие элементы. Мы рассматривали следующие способы описания доработок: в начале каждого из разделов (Статика, Динамика, АП) писать “Доработка функционала “NAME”, либо сделать отдельный раздел “Доработки”, в котором в кучу будут свалены сразу все изменяющиеся задачи. Пока остановились на втором варианте, но это связано скорее удобством на конкретных проектах. В других условиях лучше подойдет первый способ.

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

Пример

Давайте для наглядности разберем структуру ТЗ на основе упрощенной страницы раздела каталога.

Статика

Страница “Раздел каталога”

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

Интегрируется следующий функционал:

1. “Хлебные крошки”
2. “Дерево каталога”
3. “Фильтрация. Общие положения”
4. “Фильтрация. Текст”
5. “Фильтрация. Текст и изображение”
6. “Фильтрация. Диапазон”
7. “Сортировка. По умолчанию”
8. “Сортировка. По возрастанию цены“
9. “Сортировка. По убыванию цены”
10. “Превью товара. Плитка”
11. “Пагинация. Постраничная”
12. “Текстовый блок”. Интегрируется в виде блока для SEO-текста перед подвалом сайта

URL: /c/1745-name, где 1745- id текущей категории каталога, а name — транслитерированное название этой категории.

Динамика

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

Функционал “Фильтрация. Общие положения”

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

• выпадающий список закрывается, а фильтр применяется. В текущем разделе остаются только товары, соответствующие текущим активным фильтрам
• название кнопки фильтра приобретает вид: “Название фильтра: K”, где K — количество выбранных значений фильтра, если их 2 или больше, или “Название фильтра: значение”, если было выбрано одно значение.
• цвет кнопки фильтра меняется на вид используемого фильтра
• в значениях других фильтров остаются только варианты, удовлетворяющие текущим активным фильтрам. Если в одном из неактивных фильтров остается одно значение, его кнопка приобретает вид неактивной, а название выводится в формате “Название фильтра: значение”
• у всех активных фильтров после названия добавляется крестик, при клике на который сбрасывается только этот фильтр
• пагинация сбрасывается

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

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

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

Выбранные фильтры добавляются в URL посредством query-параметров.

Функционал “Превью товара. Плитка”

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

1. Цена (целое число в рублях РФ)
2. Название товара
3. Метка “В магазине” или “С витрины”
4. Изображение
5. Размер
6. Кнопка “В корзину” (Интеграция функционала “Добавить в корзину”)
7. Кнопка “В избранное” (Интеграция функционала “Добавить в избранное”)

При клике на любую область превью, кроме кнопки “В корзину” осуществляется переход на страницу товара.

На одной строке должно помещаться 3-4 плитки с превью товара.

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

Административная панель

Одна страница требует большого количества разделов АП, опишу один из них.

Товар

Список всех товаров с фильтрацией. При редактировании/добавлении товара доступны следующие поля:

1. Название (текст)
2. Бренд (радио)
3. Изображения
4. Цена (целое число)
5. Описание (текстовый блок)
6. Тип (магазин/витрина, радио)
7. Состояние. Значение включает в себя Название (текст) и Пояснение (текст).
8. Статус. Возможны варианты:
   
   1. на продаже
   2. на модерации
   3. на доработке
   4. отклонен
   5. продан
   6. не прошел проверку
   7. отменен Продавцом
9. Размер с бирки (необязательное). Текстовое поле без валидации
10. …

Полей более 30 и, дабы не раздувать статью, опустим их.

Выводы

Плюсы нового подхода:

1. Полнота. Данное ТЗ позволяет однозначно описывать требования, что является основным и необходимым параметром любого ТЗ.
2. Понятность. Около половины наших клиентов не имеют на своей стороне технического специалиста и сталкиваются с разработкой впервые. Поэтому очень важно было сделать ТЗ максимально понятным и читаемым. И у нас получилось! Даже технически не подкованные клиенты понимают, как оно устроено, могут спокойно его читать и давать отличную обратную связь.
3. Молекулярность. ТЗ полностью соответствует нашим требованиям к разбиению на отдельные элементы, что значительно упрощает и решает проблемы, описанные выше. Блоки ТЗ напрямую соответствуют задачам, которые выполняются разработчиками, что было встречено на ура. Также ТЗ отлично ложится на дизайн-систему (про нее статья выйдет уже на следующей неделе).
4. Простота оценки и конфигурации сметы. Хорошо описанные и разбитые задачи стало просто и приятно оценивать. Если во время оценки мы понимаем, что требования неполные, то дописываем их. Под каждый проект (этап) делаем гугл таблицу, в которой заказчик может попробовать разные конфигурации проекта и определить наиболее подходящий для себя вариант по цене/функционалу.
5. Взаимодействие с заказчиками поднялось на новый уровень. Внесенные изменения позволяют четко определить границы проекта. Если необходимо внести изменения относительно ТЗ, это оценивается как новая задача, хотя при старом подходе это вызывало много споров.
6. Рентабельность. Т.к. это в первую очередь бизнес, данный показатель наравне с предыдущим является одним из самых важных. Детальная проработка позволила свести количество плохо оцененных задач к минимуму. Ни по одному из проектов, реализуемых по новому подходу, не было превышения бюджета.

Минусы:

1. Внесение доработок. На одном из проектов было необходимо ввести статусы товаров. В итоге получилось огромное количество доработок по 2-3 строчки. Нельзя это назвать явным минусом, т.к. полното требований в приоритете, но и идеальным данных подход назвать нельзя.
2. Сложность восприятия при автоматизации бизнес-процессов. Если взять бизнес-процессы некоторых компаний от момента продажи до получения товара покупателем, не всегда есть возможность (или необходимость на первых этапах) покрыть весь процесс за счет Статики, Динамики и АП, т.к. многие задачи выполняются вручную, обсуждаются с клиентами по телефону и т.д. Это немного усложняет восприятие ТЗ в чистом виде, и требует дополнительного описания процессов.
3. Стоимость и время разработки. Продавать ТЗ, конечно, стало сложнее, ведь далеко не все при первом контакте с разработкой готовы платить за него 10-20% от проекта при том что многие наши конкуренты берут за него 10-20 тыс. Но подобная работа сполна окупается при реализации, снижая риски проекта и улучшая качество.

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

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

Мы настолько довольны результатом, что решили отказаться от стандартных тасктрекеров в пользу доработки Google Docs для полноценной работы с задачами на основе ТЗ. Если опыт будет удачным, напишем об этом отдельную статью. А пока ждем от вас объективную критику и советы, с надеждой, что кому-то эта статья помогла).

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

Павел Молянов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если пройтись по зарубежным сайтам с запросом «product requirements document», то можно найти креативные и убедительные статьи про то, что техническое задание (ТЗ, PRD) умерло. Отчасти с этим нужно согласиться — при разработке продукта с нуля прототипирование выглядит гораздо интереснее и эффективнее, чем тома записей заказчика, порой ну очень непрофессиональные. Однако, если речь идёт о доработке базовой системы, то дело принимает совершенно другой оборот. Мы сталкиваемся и с доработкой, и с заказной разработкой, поэтому на ТЗ собаку съели, если повар нам не врёт. В общем, сегодня — о тех самых классических технических заданиях, которые пишутся на доработку купленного и установленного программного обеспечения. Короче, о наболевшем.

Грани взаимодействия

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

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

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

Возможности — если кратко, то это то, что реально может сделать вендор (исполнитель). Рассмотрим на примере нашей RegionSoft CRM . Клиент покупает систему и составляет техническое задание на доработку: нужно создать интеграцию с сайтом и привязку событий в CRM к номеру заказа интернет-магазина. Это реально исполнимое требование, у нас есть ресурс и возможность сделать это. А ещё нужно разработать и прикрутить к CRM CMS, систему управления контентом сайта. Теоретически мы это можем, но у нас нет возможности это сделать дёшево, а у клиента нет возможности заплатить нам столько, чтобы мы перекинули на задачу человеческие и временные ресурсы. В итоге от этого требования заказчик отказывается — да и CMS ему не особо нужна, всё и так хорошо. Но о «жадности» ТЗ- позже.

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

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

Сбор и анализ требований

Это очень важный внутрикорпоративный процесс, в ходе которого выясняется, чего хотят от программы (здесь и далее возьмём CRM, но методы работают и с другими типами софта) потенциальные пользователи. Если вы обратитесь к крупному вендору типа SAP или системному интегратору, то с высокой долей вероятности вам предложат воспользоваться услугами бизнес-консультанта (он же персональный менеджер, он же аккаунт-менеджер, он же «теперь ваш представитель в нашей компании»). На самом деле, в большинстве случаев это обычный вышколенный продажник, у которого две задачи: накрутить стоимость проекта и не дать вам сорваться с крючка.

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

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

Есть очень простая схема сбора требований.

1. Создайте рабочую группу из руководителей и опытных специалистов подразделений, которые будут пользоваться CRM. Расскажите о решении, которое предполагается выбрать, предоставьте доступ к демо-версии.
2. Члены рабочей группы должны передать информацию сотрудникам и запросить у них пожелания к новой программе в абсолютно свободной форме. Если кто-то из сотрудников никогда не сталкивался с подобным софтом и не готов говорить в аспекте будущего использования, нужно попросить его описать свои периодические задачи, это универсальный подход.
3. Затем каждое подразделение устанавливает, чего нет в CRM или чему она не соответствует, и агрегирует информацию.
4. Рабочая группа анализирует собранные требования, проверяет и исключает пересечения. Например, нередко отдел продаж и отдел маркетинга заказывают один и тот же отчёт, но в требованиях могут по-разному называться поля и сущности, хотя данные за ними стоят одинаковые. Соответственно, нужно придти к единой форме.
5. Рабочая группа формирует список требований и расставляет приоритеты. На этом этапе можно подключить вендора, поскольку он отвечает за ресурсы. Например, можно попросить создать пользовательский отчёт для RegionSoft CRM, а можно заказать интеграцию с сайтом. Это совершенно разные по срокам задачи, здесь очень важен приоритет.

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

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

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

• Выявление — определение требований, поиск проблем, которые необходимо решить.
• Анализ — разбор требований, выделение ключевых потребностей, обобщение.
• Адаптация — оценка требований в контексте возможностей CRM и существующих бизнес-процессов.
• Документирование — формальное и подробное описание требований, согласование ТЗ.
• Общение с вендором (разработчиком) — итеративное взаимодействие с вендором по поводу доработок согласно составленному ТЗ.
• Реализация — работа вендора над созданием необходимой функциональности. Лучше, если вендор будет постоянно на связи с заказчиком — так продукт на выходе будет наиболее точно соответствовать видению клиента.
• Тестирование — проверка функциональности сотрудниками вендора, внутренними экспертами клиента и конечными пользователями с целью установления соответствия доработки и ТЗ, работоспособности системы с изменениями.

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

Уровень бизнеса — самый глобальный уровень, на котором решаются сложные и приоритетные задачи. К этому уровню можно отнести интеграции, доработки и моделирование бизнес-процессов, разработку новых функциональных модулей. Как правило, это ресурсоёмкая разработка, с серьёзными консультациями и тесной совместной работой с заказчиком. Например, в своё время в RegionSoft CRM такой заказной доработкой были складской учёт, касса и производство. Постепенно изменения вошли в релиз, а позже позволили создать новый продукт для оптовых, розничных магазинов и гипермаркетов — RegionSoft Retail .

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

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

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

Уровень технологии — последний в списке, но по важности и сложности опережающий остальные. Это могут быть требования клиента, связанные с платформой, операционной системой или устройствами. Например, запрос сборки под MacOS. Очень здорово, если такие требования постепенно перерастут в релизы, но иметь их фиксы обязательно. Именно из запросов клиентов на этом уровне мы сделали сборку RegionSoft CRM под MacOS и добавили удалённый доступ по технологии TRM как временное решение редкого, но существующего запроса мобильной версии.

Анатомия технического задания проста, во всяком случае в виде скелета. Обязательные части технического задания помогают заказчику сосредоточиться на проблеме и сформулировать задачу правильно, а исполнителю — понять, что же от него хотят. Кстати, о понимании. Конечно, в начале поста мы немного слукавили, отрицая бизнес-консультантов как класс. Дело вот в чём: каждый вендор работает на рынке по несколько лет (мы сейчас не о CRM-однодневках), а то и десятков лет, а значит имеет набор кейсов практически по каждой отрасли. Соответственно, и инженеры, и программисты, и продажники знакомы со спецификой внедрения в каждом типе компании. Но опять-таки, важно ориентироваться именно на свой бизнес.

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

Приведу пример. В одной компании внедряли CRM, предполагалась работа на довольно большом массиве данных (несколько десятков миллионов записей в месяц, несколько сотен тысяч записей в день). Начальник отдела продаж запросил отчёт по выгрузке этих записей с периодичностью «ежедневно». Естественно, что такой отчёт при одновременной работе сотни пользователей нагружал систему — были найдены решения по оптимизации процесса. Уже в ходе работы выяснилось, что продажник перестраховался и отчёт нужен ему только по итогам месяца, и то его можно запускать по расписанию ночью. Стоит ли говорить, что время и деньги были потрачены зря.

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

Что должно делать? Самый информативный блок — в нём описываются требования, ожидания от системы. И вот тут случаются тем самые перлы, чудеса и коллизии, которые впору отправлять на башорг, и которые ну очень усложняют жизнь. Причина одна — пользователь не знает, чего он хочет, что нужно сделать. Есть ещё маленькая подпричина — пользователь не может сформулировать требования. И тут задача разработчика (рабочей группы, аналитика, если он есть) помочь сформулировать потребность верно, выбрать целесообразное требование, вписать задачу в контекст работы системы. В этом же блоке нужно упомянуть ожидаемый результат.

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

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

1. Описание требования каждого механизма и каждой функциональности
2. Описание реализации данной функциональности
3. Стоимость работ по каждому из этапов в отдельности
4. Общая стоимость работ по данному техническому заданию
5. Сроки исполнения работ с разбивкой по этапам и указанием очерёдности
6. Описание условий установки и тестирования доработки
7. Оговорки об исчерпывающем характере технического задания и иные условия

10 правил, написанных слезами разработчика

Техническое задание на доработку должно быть ТЗ на доработку , а не 300-страничным описанием CRM, которая необходима клиенту. Перед составлением требований следует внимательно ознакомиться с интерфейсом системы, её возможностями, документацией — скорее всего, большая часть «хотелок» уже есть в базовой поставке. Вторым шагом я бы рекомендовал обратить внимание на встроенные инструменты доработки (дизайнеры отчётов, конфигураторы и проч.) — возможно, нужные изменения сможет внести штатный программист (во многих компаниях они есть).

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

Яркий пример избыточности буквально из вчерашнего дня: клиент купил ERP одной известной российской компании, думая, что раз работает бухгалтерский учёт, то и ERP этого вендора будет хороша. ERP оказалась не то чтобы не очень сама по себе, но очень не подходящей бизнесу. А вот RegionSoft CRM со складским учётом и производством подходит. Есть решение: забыть про ERP, поплакать, интегрировать учёт 1С с новой CRM и радоваться удобной реализации. Но вбуханных денег жалко! И клиент требует интегрировать CRM с ERP. Мы и не такое делали, но зачем такая трата, зачем две относительно схожих системы?

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

Например, RegionSoft CRM — десктопная программа, у нас нет клиента для браузера. Просить нас создать web-приложение для одной компании бессмысленно, это крупная разработка, она сейчас ведётся и не является возможной доработкой для одной компании. Нет, конечно, всё имеет свою цену, но опять же — в общем случае требование невыполнимое.

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

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

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

Да, корпоративный софт выглядит примерно так, и в нём много важных мелочей

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

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

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

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

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

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

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

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

   Заповеди закончились, теперь отповедь

   Кроме перечисленных правил, есть ещё несколько вещей, о которых стоит рассказать. Речь идёт о целях, планах и ожиданиях — всех тех оставляющих, которые делают проект успешным, а отношения вендора и клиента почти дружескими.

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

   
   Наконец он нашёл время закончить ТЗ. Но, увы, вокруг не осталось разработчиков, чтобы его реализовать.

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

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

   Исходите из объективной необходимости изменений и расширений — выше я писал, что разработчик не исчезает и готов внести изменения и дополнения по вашим требованиям в любой момент. Поэтому не пытайтесь создать CRM/ERP мечты сразу, не требуйте от вендора кнопку «Всё работает, пока я пью кофе» — поработайте в системе, определите критичные для вас замечания и приступайте к сбору требований и составлению ТЗ.

   О технических заданиях можно писать бесконечно, это настоящий генератор не только мемов и баек, но и головной боли. Можно рассказать о приоритетах и правилах оформления, о ГОСТе 1989 года, который делает ТЗ бесчеловечным, о стандартах IEEE, которые немного лучше, о прототипах и дополняющих их ТЗ. Но в конце хотелось бы ограничиться одним, самым главным правилом: техническое задание — не норма права, не ГОСТ и не догма, поэтому, если можно улучшить — улучшайте, можно упростить — упрощайте, можно сделать изящно и чтобы всем нравилось — делайте. Уверен, никто после такого не ткнёт носом в ТЗ и не скажет, что там такого не написано. Или почти никто.

   Весь декабрь мы даём скидки на RegionSoft CRM и весь софт собственной разработки. С 1 по 15 декабря — 15% и крутые условия рассрочки и аренды. У нас не бывает -70% и -90%, потому что мы держим экономически обоснованную цену на лицензии, а не берём её с потолка.

   Ну а если вам нужна CRM-система (с доработкой или без), то заходите на наш сайт , там много о CRM, её преимуществах и прочем корпоративном софте.

   И да, мы всегда ищем партнёров, которые готовы продавать CRM и другие продукты, дорабатывать и продавать CRM, продавать софт и обучать пользователей. Разделение доходов честное и выгодное партнёру. Покажем, расскажем, научим. Пишите на [email protected]

   Слайды, слайды. Комиксы взяты с http://www.modernanalyst.com/ и из Pinterest. Если есть лучший перевод — будем рады его внести в пост.

Если пройтись по зарубежным сайтам с запросом «product requirements document», то можно найти креативные и убедительные статьи про то, что техническое задание (ТЗ, PRD) умерло. Отчасти с этим нужно согласиться — при разработке продукта с нуля прототипирование выглядит гораздо интереснее и эффективнее, чем тома записей заказчика, порой ну очень непрофессиональные. Однако, если речь идёт о доработке базовой системы, то дело принимает совершенно другой оборот. Мы сталкиваемся и с доработкой, и с заказной разработкой, поэтому на ТЗ собаку съели, если повар нам не врёт. В общем, сегодня — о тех самых классических технических заданиях, которые пишутся на доработку купленного и установленного программного обеспечения. Короче, о наболевшем.

Грани взаимодействия

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

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

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

Возможности — если кратко, то это то, что реально может сделать вендор (исполнитель). Рассмотрим на примере нашей RegionSoft CRM . Клиент покупает систему и составляет техническое задание на доработку: нужно создать интеграцию с сайтом и привязку событий в CRM к номеру заказа интернет-магазина. Это реально исполнимое требование, у нас есть ресурс и возможность сделать это. А ещё нужно разработать и прикрутить к CRM CMS, систему управления контентом сайта. Теоретически мы это можем, но у нас нет возможности это сделать дёшево, а у клиента нет возможности заплатить нам столько, чтобы мы перекинули на задачу человеческие и временные ресурсы. В итоге от этого требования заказчик отказывается — да и CMS ему не особо нужна, всё и так хорошо. Но о «жадности» ТЗ- позже.

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

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

Сбор и анализ требований

Это очень важный внутрикорпоративный процесс, в ходе которого выясняется, чего хотят от программы (здесь и далее возьмём CRM, но методы работают и с другими типами софта) потенциальные пользователи. Если вы обратитесь к крупному вендору типа SAP или системному интегратору, то с высокой долей вероятности вам предложат воспользоваться услугами бизнес-консультанта (он же персональный менеджер, он же аккаунт-менеджер, он же «теперь ваш представитель в нашей компании»). На самом деле, в большинстве случаев это обычный вышколенный продажник, у которого две задачи: накрутить стоимость проекта и не дать вам сорваться с крючка.

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

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

Есть очень простая схема сбора требований.

1. Создайте рабочую группу из руководителей и опытных специалистов подразделений, которые будут пользоваться CRM. Расскажите о решении, которое предполагается выбрать, предоставьте доступ к демо-версии.
2. Члены рабочей группы должны передать информацию сотрудникам и запросить у них пожелания к новой программе в абсолютно свободной форме. Если кто-то из сотрудников никогда не сталкивался с подобным софтом и не готов говорить в аспекте будущего использования, нужно попросить его описать свои периодические задачи, это универсальный подход.
3. Затем каждое подразделение устанавливает, чего нет в CRM или чему она не соответствует, и агрегирует информацию.
4. Рабочая группа анализирует собранные требования, проверяет и исключает пересечения. Например, нередко отдел продаж и отдел маркетинга заказывают один и тот же отчёт, но в требованиях могут по-разному называться поля и сущности, хотя данные за ними стоят одинаковые. Соответственно, нужно придти к единой форме.
5. Рабочая группа формирует список требований и расставляет приоритеты. На этом этапе можно подключить вендора, поскольку он отвечает за ресурсы. Например, можно попросить создать пользовательский отчёт для RegionSoft CRM, а можно заказать интеграцию с сайтом. Это совершенно разные по срокам задачи, здесь очень важен приоритет.

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

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

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

• Выявление — определение требований, поиск проблем, которые необходимо решить.
• Анализ — разбор требований, выделение ключевых потребностей, обобщение.
• Адаптация — оценка требований в контексте возможностей CRM и существующих бизнес-процессов.
• Документирование — формальное и подробное описание требований, согласование ТЗ.
• Общение с вендором (разработчиком) — итеративное взаимодействие с вендором по поводу доработок согласно составленному ТЗ.
• Реализация — работа вендора над созданием необходимой функциональности. Лучше, если вендор будет постоянно на связи с заказчиком — так продукт на выходе будет наиболее точно соответствовать видению клиента.
• Тестирование — проверка функциональности сотрудниками вендора, внутренними экспертами клиента и конечными пользователями с целью установления соответствия доработки и ТЗ, работоспособности системы с изменениями.

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

Уровень бизнеса — самый глобальный уровень, на котором решаются сложные и приоритетные задачи. К этому уровню можно отнести интеграции, доработки и моделирование бизнес-процессов, разработку новых функциональных модулей. Как правило, это ресурсоёмкая разработка, с серьёзными консультациями и тесной совместной работой с заказчиком. Например, в своё время в RegionSoft CRM такой заказной доработкой были складской учёт, касса и производство. Постепенно изменения вошли в релиз, а позже позволили создать новый продукт для оптовых, розничных магазинов и гипермаркетов — RegionSoft Retail .

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

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

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

Уровень технологии — последний в списке, но по важности и сложности опережающий остальные. Это могут быть требования клиента, связанные с платформой, операционной системой или устройствами. Например, запрос сборки под MacOS. Очень здорово, если такие требования постепенно перерастут в релизы, но иметь их фиксы обязательно. Именно из запросов клиентов на этом уровне мы сделали сборку RegionSoft CRM под MacOS и добавили удалённый доступ по технологии TRM как временное решение редкого, но существующего запроса мобильной версии.

Анатомия технического задания проста, во всяком случае в виде скелета. Обязательные части технического задания помогают заказчику сосредоточиться на проблеме и сформулировать задачу правильно, а исполнителю — понять, что же от него хотят. Кстати, о понимании. Конечно, в начале поста мы немного слукавили, отрицая бизнес-консультантов как класс. Дело вот в чём: каждый вендор работает на рынке по несколько лет (мы сейчас не о CRM-однодневках), а то и десятков лет, а значит имеет набор кейсов практически по каждой отрасли. Соответственно, и инженеры, и программисты, и продажники знакомы со спецификой внедрения в каждом типе компании. Но опять-таки, важно ориентироваться именно на свой бизнес.

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

Приведу пример. В одной компании внедряли CRM, предполагалась работа на довольно большом массиве данных (несколько десятков миллионов записей в месяц, несколько сотен тысяч записей в день). Начальник отдела продаж запросил отчёт по выгрузке этих записей с периодичностью «ежедневно». Естественно, что такой отчёт при одновременной работе сотни пользователей нагружал систему — были найдены решения по оптимизации процесса. Уже в ходе работы выяснилось, что продажник перестраховался и отчёт нужен ему только по итогам месяца, и то его можно запускать по расписанию ночью. Стоит ли говорить, что время и деньги были потрачены зря.

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

Что должно делать? Самый информативный блок — в нём описываются требования, ожидания от системы. И вот тут случаются тем самые перлы, чудеса и коллизии, которые впору отправлять на башорг, и которые ну очень усложняют жизнь. Причина одна — пользователь не знает, чего он хочет, что нужно сделать. Есть ещё маленькая подпричина — пользователь не может сформулировать требования. И тут задача разработчика (рабочей группы, аналитика, если он есть) помочь сформулировать потребность верно, выбрать целесообразное требование, вписать задачу в контекст работы системы. В этом же блоке нужно упомянуть ожидаемый результат.

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

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

1. Описание требования каждого механизма и каждой функциональности
2. Описание реализации данной функциональности
3. Стоимость работ по каждому из этапов в отдельности
4. Общая стоимость работ по данному техническому заданию
5. Сроки исполнения работ с разбивкой по этапам и указанием очерёдности
6. Описание условий установки и тестирования доработки
7. Оговорки об исчерпывающем характере технического задания и иные условия

10 правил, написанных слезами разработчика

Техническое задание на доработку должно быть ТЗ на доработку , а не 300-страничным описанием CRM, которая необходима клиенту. Перед составлением требований следует внимательно ознакомиться с интерфейсом системы, её возможностями, документацией — скорее всего, большая часть «хотелок» уже есть в базовой поставке. Вторым шагом я бы рекомендовал обратить внимание на встроенные инструменты доработки (дизайнеры отчётов, конфигураторы и проч.) — возможно, нужные изменения сможет внести штатный программист (во многих компаниях они есть).

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

Яркий пример избыточности буквально из вчерашнего дня: клиент купил ERP одной известной российской компании, думая, что раз работает бухгалтерский учёт, то и ERP этого вендора будет хороша. ERP оказалась не то чтобы не очень сама по себе, но очень не подходящей бизнесу. А вот RegionSoft CRM со складским учётом и производством подходит. Есть решение: забыть про ERP, поплакать, интегрировать учёт 1С с новой CRM и радоваться удобной реализации. Но вбуханных денег жалко! И клиент требует интегрировать CRM с ERP. Мы и не такое делали, но зачем такая трата, зачем две относительно схожих системы?

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

Например, RegionSoft CRM — десктопная программа, у нас нет клиента для браузера. Просить нас создать web-приложение для одной компании бессмысленно, это крупная разработка, она сейчас ведётся и не является возможной доработкой для одной компании. Нет, конечно, всё имеет свою цену, но опять же — в общем случае требование невыполнимое.

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

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

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

Да, корпоративный софт выглядит примерно так, и в нём много важных мелочей

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

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

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

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

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

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

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

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

   Заповеди закончились, теперь отповедь

   Кроме перечисленных правил, есть ещё несколько вещей, о которых стоит рассказать. Речь идёт о целях, планах и ожиданиях — всех тех оставляющих, которые делают проект успешным, а отношения вендора и клиента почти дружескими.

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

   
   Наконец он нашёл время закончить ТЗ. Но, увы, вокруг не осталось разработчиков, чтобы его реализовать.

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

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

   Исходите из объективной необходимости изменений и расширений — выше я писал, что разработчик не исчезает и готов внести изменения и дополнения по вашим требованиям в любой момент. Поэтому не пытайтесь создать CRM/ERP мечты сразу, не требуйте от вендора кнопку «Всё работает, пока я пью кофе» — поработайте в системе, определите критичные для вас замечания и приступайте к сбору требований и составлению ТЗ.

   О технических заданиях можно писать бесконечно, это настоящий генератор не только мемов и баек, но и головной боли. Можно рассказать о приоритетах и правилах оформления, о ГОСТе 1989 года, который делает ТЗ бесчеловечным, о стандартах IEEE, которые немного лучше, о прототипах и дополняющих их ТЗ. Но в конце хотелось бы ограничиться одним, самым главным правилом: техническое задание — не норма права, не ГОСТ и не догма, поэтому, если можно улучшить — улучшайте, можно упростить — упрощайте, можно сделать изящно и чтобы всем нравилось — делайте. Уверен, никто после такого не ткнёт носом в ТЗ и не скажет, что там такого не написано. Или почти никто.

   Весь декабрь мы даём скидки на RegionSoft CRM и весь софт собственной разработки. С 1 по 15 декабря — 15% и крутые условия рассрочки и аренды. У нас не бывает -70% и -90%, потому что мы держим экономически обоснованную цену на лицензии, а не берём её с потолка.

   Ну а если вам нужна CRM-система (с доработкой или без), то заходите на наш сайт , там много о CRM, её преимуществах и прочем корпоративном софте.

   И да, мы всегда ищем партнёров, которые готовы продавать CRM и другие продукты, дорабатывать и продавать CRM, продавать софт и обучать пользователей. Разделение доходов честное и выгодное партнёру. Покажем, расскажем, научим. Пишите на [email protected]

   Слайды, слайды. Комиксы взяты с http://www.modernanalyst.com/ и из Pinterest. Если есть лучший перевод — будем рады его внести в пост.

От того, насколько точно составлено техническое задание на доработку 1С, напрямую зависит, будут ли решены поставленные перед разработчиками задачи. Вместе с тем при работе с таким документом существуют некоторые сложности. В широком понимании в ТЗ прописаны нормы при создании и модернизации автоматизированной системы (АС), а также порядок работ. Сюда же входит и свод стандартов запуска проекта. Это понимание роли технического задания продиктовано требованиями ГОСТ 19.201-78 и 34.602-89, согласно которым ведется разработка ТЗ для 1С. Есть и другое толкование значения этого документа, более приближенное к практике.

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

Каким должно быть ТЗ?

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

Основные ошибки в техническом задании на разработку 1С

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

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

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

После просмотра заказчиком образец ТЗ на доработку 1С может измениться и не всегда в лучшую сторону. Это в свою очередь обычно мешает программистам правильно воспринимать информацию. Особенно это касается специалистов с небольшим опытом. На этом этапе часто возникают следующие ошибки:

1. Требования разных разделов противоречат друг другу.
2. Формулировки оказываются неточными.
3. Местами информация излишне детализирована.

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

Как избежать ошибок при разработке ТЗ?

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

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

Основные правила при составлении технического задания на разработку отчета и других элементов 1С:

1. ТЗ создается совместно исполнителем и заказчиком.
2. К работе программистов должны предъявляться только объективные требования. Для успешной разработки проекта субъективное видение заказчика должно быть сведено к минимуму.
3. Нужно подробно описывать результат, который нужен заказчику. При этом в примере технического задания на разработку конфигурации 1С необходимо прописывать все параметры, по которым должен работать элемент. Иначе результат может сильно отличаться от желаемого.
4. Риски исполнителя и заказчика должны быть примерно равны и сведены к минимуму.
5. Нельзя применять термины, которые используются в деловом общении и не применяются в конкретной отрасли.

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

Опасность неверного составления ТЗ

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

​ТЗ для блогера — первый шаг к успешной рекламе

12 июн. ・ 13 898 просмотров ・ 0 комментариев

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

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

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

Как составить ТЗ для рекламы у блогера?

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

Вот 10 важных пунктов для составления ТЗ блогеру:

1. Расскажите о продукте. Можно кратко описать рекламную кампанию, однако необходимо дать ссылки на ресурсы с более подробной информацией.

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

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

4. Выберите, какой вид контента будет максимально эффективным для рекламы вашего продукта или услуги. На этом этапе важно понять, в каком формате будет интеграция. Это может быть фото, видео или текст. В зависимости от этого нужно подбирать соцсеть. Если говорить про ТЗ для блогеров в Инстаграм, то вы можете выбрать пост, сторис, прямой эфир или все вместе.

5. Напишите о концепции компании и её целевой аудитории. Это поможет блогеру попасть в нужную ЦА, сделав акцент на правильных вещах и ценностях. Если у вас есть брендбук, то обязательно покажите его исполнителю.

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

7. Укажите желаемый объём текста для публикации. Учитывайте, что в каждой соцсети есть ограничения на максимальное количество символов в посте. В Instagram можно опубликовать только 2 тыс. символов, а на YouTube до 5 тыс.

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

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

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

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

Особенности написания ТЗ для блогеров из разных соцсетей

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

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

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

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

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

Чтобы облегчить себе жизнь, многие компании вообще не работают с блогерами напрямую и не занимаются составлением ТЗ. Они просто обращаются в различные агентства, которые делают эту работу за них. Например, в России популярностью пользуется платформа Perfluence.

3 ошибки, которые нужно избегать при составлении ТЗ

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

1. Нет конкретики. Исполнитель не может догадаться о том, как вы представляете результат интеграции. Поэтому постарайтесь добавить больше конкретики, описав все нюансы тезисно. Часто рекламодатель не составляет четкое ТЗ, а потом выражает недовольство и требует доработки. Цените время блогера и свои нервы, добавляйте больше конкретики.
2. Много ограничений. Чтобы аудитория поверила и купила, важна максимальная вовлеченность. Иногда рекламодатели настолько ограничивают блогера в его творческом полете, что в результате реклама получается без души и не приносит ожидаемого результата. Чтобы избежать данной проблемы, нужно учитывать все важные нюансы, но при этом стараться оставить простор для творчества. Помните, блогер лучше знает свою аудиторию и подход к ней.
3. Слишком маленькие сроки. Если вы хотите получить качественный контент за один день, то ваши ожидания явно завышенные. Старайтесь ставить адекватные сроки на подготовку материалов.

Нюансы при работе с блогерами по ТЗ

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

СОВЕТ. Перед тем, как обозначит точную дату и время публикации, запросите у блогера статистику за последнее время. По количеству лайков и репостов будет понятно, какое время является наиболее подходящим.

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

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

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

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

Успешных рекламных интеграций!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробно я об этом уже писал на Cossa. Коротко. Если делать ТЗ до дизайна, то устанете вносить изменения в этот документ, и потратите кучу сил/денег/времени/сотрудников/заказчиков. Поэтому мы в qb.digital перешли на относительно новую для рынка схему, когда ТЗ делается уже после утверждения дизайна. Таким образом, техническое задание у нас не диктует требования к дизайну, потому что у него на то нет компетенции, а фиксирует дизайн. Тут же возникает резонный вопрос: «А по чему рисуется дизайн?». Отвечаем: по концептуальному описанию, функциональному описанию и прототипам.

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

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

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

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

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

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

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

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

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

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

даем подробную инструкцию — ROMI center

Сегодня разберёмся с таким термином, как техническое задание. Что это такое? Как его правильно разработать? На что стоит обязательно обратить внимание? Ответ на эти вопросы важен, ведь именно от того, как составлено техзадание, во многом зависит результат работы. 

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

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

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

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

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

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

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

О стандартах написания технических заданий

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

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

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

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

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

ТЗ на разработку ПО обязательно должно включать в себя такие пункты:

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

ГОСТ 34 принят на 10 лет позднее описанного выше стандарта. Нельзя сказать, что он сильно отличается от предшественника, но свои особенности у него точно есть. Пример оформления ТЗ согласно этому документу выглядит следующим образом:

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

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

Что касается составления заданий для международных проектов, то здесь применяется стандарт  ISO/IEC/IEEE 29148:2018, разработка которого принадлежит Международной организации по стандартизации ISO. Как и в случае с ГОСТами, тут есть опорные пункты по составлению полного и качественного технического задания. Задание международного образца включает:

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

Общие рекомендации для составления понятного ТЗ

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

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

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

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

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

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

Что может помочь при составлении технического задания

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

Бриф

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

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

Наименование организации	_________________
Контактное лицо	_________________
Телефон, email контактного лица	_________________
Сфера услуг, оказываемых компанией	_________________
Геолокация оказываемых услуг / доставки товаров	_________________
Сайт компании	_________________
Целевая аудитория	_________________
Главные конкуренты на рынке	_________________
Цели и задачи сайта (визитка, презентация, каталог)	_________________
Разделы сайта (контакты, магазин, блог и пр.)	_________________
Как часто планируются обновления контента сайта	_________________
Мультиязычность сайта (в случае необходимости укажите языки)	_________________
Характеристика дизайна сайта (лаконичный / серьёзный / яркий и т.д.)	_________________
Впечатление, которое должен произвести ресурс на пользователя	_________________
Есть ли у компании фирменный стиль и логотип (приложите ссылки на файлы)	_________________
Нужны ли на сайте анимированные элементы	_________________
Интеграция систем онлайн-оплаты	_________________
Магазин	_________________
Архив	_________________
Email рассылка	_________________
Форма обратной связи	_________________
Новости	_________________
Отзывы	_________________
Другое (укажите необходимые дополнительные функции сайта)	_________________
Требуется ли регистрация домена	_________________
Требуется ли регистрация сайта на хостинге	_________________
Необходимо ли место на сайте для рекламных баннеров	_________________
Необходима ли раскрутка сайта ресурсами исполнителя	_________________
Сроки выполнения	_________________
Бюджет	_________________
Сроки проверки заказа	_________________
По мере готовности передать готовую работу (контакты)	_________________

Коммерческое предложение

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

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

Какую информацию обязательно стоит включить в коммерческое предложение?

• Информацию о компании: название, сфера деятельности, направления работы. С какого года вы работаете на рынке? Какие услуги предоставляете? 
• Выгода для клиента. Как продукт отличается от прочих аналогичных? Сколько довольных клиентов у компании? Какие условия доставки? В данном пункте эффектно будут выглядеть чёткие цифры, которые дадут понять клиенту, почему нужно выбрать именно вас.
• Цена. Обязательный блок с ценами стоит оформить наиболее прозрачным и удобным к восприятию образом. Учтите все вариации комплектации продукта, чтобы максимально подробно донести информацию до заказчика.
• Технические характеристики продукта. Срок эксплуатации, комплектация и так далее.
• Условия взаимодействия. Гарантия, доставка, возврат товара, контакты.

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

Грамотное ТЗ – залог  хорошего результата. Помните об этом и присматривайтесь к мелочам!

Как составить тз копирайтеру — подробная инструкция и образец тз

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

Содержание статьи:

Как составить ТЗ копирайтеру — предисловие:

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

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

Дополнительно:
Если вы не знаете с какой биржей копирайтинга начать работать, рекомендую прочитать эту статью: Обзор биржи TEXT.RU

Что считается техническим заданием в копирайтинге

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

• Цель, которой должен соответствовать готовый материал.
• Задачи, которые ему предстоит выполнять.
• Критерии, которым должен соответствовать материал.
• Требования к оформлению и стилистике текста.
• Другие важные нюансы.

Техническое задание – это скелет всего текста.

Как исполнитель, я встретила на своём пути множество разных технических заданий. И могу сказать, что хорошее (чёткое и конкретное) ТЗ увеличивает вероятность получения идеального текста на 50%. Почему?

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

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

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

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

№1: Структурированность или «скажем нет каше в техническом задании»! 

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

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

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

№2: Системность.

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

№3: Реальные для исполнения требования. 

Часто сталкиваюсь с ТЗ, где заказчик предъявляет к тексту требования, которые либо нереально исполнить, либо при исполнении которых страдает качество текста. Сердце кровью обливается, когда приходится вписывать в текст неорганичные ключи, которые не только режут слух, но и игнорируются поисковыми системами. Или когда из-за установленного низкого процента спама теряется исходный смысл предложения, потому что приходится заменять нужное слово его далёкими синонимами.

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

№4: Конкретность и однозначность.

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

№5: Опрятное оформление.

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

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

Что нужно учитывать в ТЗ для копирайтера

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

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

• Цель текста. Какие функции должен выполнять конечный материал? Увеличивать продажи, использоваться для почтовых рассылок или привлекать трафик на сайт? Цель текста – это не то, о чём должен умалчивать заказчик. Её нужно включить ТЗ, и, чем конкретнее – тем лучше.

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

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

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

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

• Текстовые ключи. Достаточно неоднозначный вопрос. С одной стороны, вы можете включить в ТЗ нужные вам ключи. Но, c другой стороны, не стоит перегибать палку и указывать частоту каждого ключа (например 1%).

• Уникальность. Ещё один спорный момент. Указывать процент желаемой оригинальности нужно обязательно. Однако, какой? Если вы до сих пор думаете, что 100% оригинальность выведет текст в ТОП-10 в поиске, то вы ошибаетесь. Система поисковиков давно изменилась, и на ранжирование материала влияют совсем другие характеристике.

  А вот тексту 100% оригинальность может повредить. Исполнитель будет вынужден изгаляться, чтобы добиться этого процента, а качество текста будет страдать. Я считаю, что оригинальность – это очень гибкий и индивидуальный критерий. Возьмём, например, тексты с юридической тематикой. В них невозможно добиться 100% оригинальности без искажения смысла. А разве законы можно искажать?

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

• Академическая тошнота и тошнота по слову. Опять-таки, индивидуальные критерии. Лучше ставить их на основании текстовых анализов, а не наугад. Тогда показатели будут адекватными. Как правило, это до 10% академическая тошнота, и до 5% тошнота по слову. Классическая же тошнота, которая все ещё мелькает в ТЗ, никакой роли не играет. Поэтому указывать её в тех. задании необходимости нет.

• Структура текста. В идеале,структура текста должна быть написана либо CEO-специалистом, либо специалистом в конкретной теме. Если такой возможности нет, то, потратьте время на анализ текста конкурентов и на сбор наиболее частых поисковых запросов по теме будущего текста. Это поможет собрать конкурентоспособную структуру текста (подробнее об этом читайте в статье «Что такое SEO статьи«).

• Сроки. Указывайте исполнителю реальные сроки. И не забывайте, что для написания качественного текста, его вычитки и редактуры нужно немало времени. Ставя категорично маленькие сроки, вы рискуете получить сырой материал. По хорошему нужен срок в 2-3 дня (минимум), в идеале конечно 4-5 дней.

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

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

Что нужно исключить из ТЗ для копирайтера

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

• Повышенную эмоциональность. Включайте в ТЗ только чёткие требования без какой-либо эмоциональной окраски.

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

• Угрозы. «Если вы не сделаете так, то я не приму заказ, и вообще откажусь от сотрудничества!» — подобное тоже не нужно включать в ТЗ. Я никогда не возьмусь за заказ с таким тех. заданием. И не потому, что мне страшно. А потому что это показывает токсичность, надменность и несговорчивость заказчика, и отталкивает от него.

• Не относящиеся к сути информация. Я утрирую: не нужно указывать, какого вы знака зодиака и сколько у вас детей. Пишем только конкретно и по делу.

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

Техническое задание для копирайтера образец

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

Тема (h2): Как похудеть в домашних условиях

Тип текста:
Статья будет размещена на информационном сайте про тренировки и питание

Цель статьи:
Статья нужна для привлечения трафика на сайт. Она должна дать исчерпывающий ответ на вопрос читателя, и мотивировать его оформить подписку на рассылку.

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

Объем текста: 
От 8000 до 10000 символов без пробелов.

Ключи: 
1. как похудеть женщине
2. худеть в домашних условиях
3. как сбросить вес
4. упражнения для похудения женщине

Уникальность: 
От 90% по text.ru

Структура: (Соблюдение обязательно).
— Введение
1. Причины появления лишнего веса
2. Худеем дома с помощью правильного питания
3. Комплекс упражнений для похудения в домашних условиях
4. Обёртывания, как способ борьбы с лишним весом
— Заключение

Сроки сдачи: 4 дня.

Оформление: 
Готовую статью присылать в документе word. Текст должен быть разделён на небольшие абзацы (3-4 предложения в каждом), содержать нумерованные списки, цитаты.

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

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

Заключение

Надеюсь, в этой статье вы нашли ответы на все интересующие вас вопросы. Как я говорила выше, техническое задание для копирайтера – это 50% успеха. И самое главное то, что составить его не трудно, а вот результат от правильного тз вас обрадует.

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

На этом все. Если статья оказалась для вас полезной — сохраните ее к себе. Если вам есть что добавить — пишите в комментарии.

Как Пишется Техническое Задание на Проектирование

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

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

• Техническое задание
• Эскизный проект
• Технический проект
• Рабочий проект

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

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

Идеально было бы, что ТЗ отражало все насущные проблемы и указывало бы, какой вид проектных работ нужен заказчику. Составить техническое задание на проектирование можно:

• На эскизное проектирование
• На архитектурное проектирование
• На инженерное проектирование
• На конструктивное проектирование отдельных элементов металлоконструкций и т. .

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

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

Мы предлагаем своим заказчикам составить техническое задание на проектирование, в соответствии с условиями договора подряда. Поэтому, прежде чем начать заполнять бланк ТЗ, нужно предусмотреть общие данные (район строительства, расположение сторон света, климатические особенности), а затем приступать к оформлению раздела, где будет раскрыта вся информация о будущем быстровозводимом здании, сооружении, элементах ЛМК, конструктивных и архитектурных формах, а также об инженерных коммуникациях, ландшафтном дизайне, благоустройстве территории и т. . Этот раздел с общими данными, как правило, содержит в себе следующую информацию:

• Обоснование строительства
• Вид строительства (новое, капитальное, некапитальное, капитальный ремонт, реконструкция или т. . )
• Полные данные о заказчике
• Сведения об особенностях земельного участка, выделенного под возведение здания (сооружения)
• Требования к возводимому объекту (тип, назначение, этажность, условия использования типовых (готовых) проектов, площадь строительства, использования подземного пространства)
• Очередность строительства
• Сроки начала и завершения строительства, с датой сдачи объекта в эксплуатации, которая должна совпадать с договорными условиями
• Качественные характеристики быстровозводимого здания (по условиям ГОСТ 54257-2010)
• Характеристика стадий проектирования
• Наличие разрешительной документации для строительства

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

Обращайтесь!

Составление технического задания на проектирование Рассчитать

стоимость проектирования

Оставить заявку на услуги экспертизы или проектирования

Ответы на самые важные вопросы по экспертизе или проектирования

Запрос коммерческого предложения

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

Звоните на номер:

или заполните форму

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

Звоните на номер

1. Какие документы необходимы для того, чтобы создать техническое задание
2. Порядок составления технического задания
3. Что входит в состав технического задания на проектирование?
4. Заказать составление технического задания на проектирование

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

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

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

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

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

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

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

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

• Площадь.
• Этажность.
• Применяемые материалы.
• Форма здания.
• Оригинальные особенности объекта.

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

Что входит в состав технического задания на проектирование?

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

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

Отдельно упоминается информация, являющаяся требованиями к проектированию:

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

Заказать составление технического задания на проектирование

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

Поэтому сделать заказ на составление технического задания могут многие компании и частные лица.

Пример технического задания на проектирование скачать образец

Система наружной ливневой канализации запроектирована из двухслойных профилированных труб из высокомодульного полиэтилена КОРСИС DN160-400 мм SN8 и SN16 (под дорогами) по ТУ 2248-001-73011750-2005. На сети канализации устанавливаются смотровые, узловые и поворотные канализационные колодцы и дождеприемные колодцы типа ДМ диаметром 1000 – 1500 из сборных железобетонных элементов серии 3. 9001-1-14 по т. п. 902-09-46. 88. Для монтажа системы ливневой канализации применяются фасонные части с размерами раструба и уплотнительными кольцами, соответствующими требованиями ТУ 2248-001-73011750-2005. Внутренние сети — магистрали и стояки предусмотреть из стальных водогазопроводных оцинкованных обыкновенных труб диаметром 100-15мм по ГОСТ 3262-75*, подводки к приборам — из полипропиленовых труб диаметром 16 мм по ТУ 2248-032-00284581-98. Трубопроводы водоснабжения на 2 этаже проложить под потолком, подводки к приборам предусмотреть над полом каждого этажа.

По периметру здания через 60-70м предусмотреть установку поливочных кранов диаметром 25 мм. Групповые щиты выполнить навесного и напольного испол­нения в корпусах с классом защиты не менее IP20. В техни­ческих и влажных помещениях предусмотреть установку щи­тов классом защиты не менее IP44. В качестве устройств защиты групповых кабелей, отходящих от щитов, применить автоматические выключатели.

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

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

Техническое задание на проектирование дома

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

1. Вам придется потратить приличную сумму на проектирование дома. В некоторых случаях стоимость проекта доходит до 3-5% от стоимости дома, что отпугивает потенциальных владельцев домов;
2. Когда задание на выполнение работы по составлению проекта передано специалистам, далеко не всегда вы сможете быстро увидеть результат работы. Некоторые компании, не ценя времени своего клиента, могут предоставить готовый проект лишь спустя несколько месяцев.

Готовый проект зданияСмета по материалам для строительства

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

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

Разработка технического задания на проектирование

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

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

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

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

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

Стандарты и шаблоны для ТЗ на разработку ПО

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

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

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

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

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

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

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

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

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

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

Мы предлагаем своим заказчикам составить техническое задание на проектирование, в соответствии с условиями договора подряда. Поэтому, прежде чем начать заполнять бланк ТЗ, нужно предусмотреть общие данные (район строительства, расположение сторон света, климатические особенности), а затем приступать к оформлению раздела, где будет раскрыта вся информация о будущем быстровозводимом здании, сооружении, элементах ЛМК, конструктивных и архитектурных формах, а также об инженерных коммуникациях, ландшафтном дизайне, благоустройстве территории и т. д. Этот раздел с общими данными, как правило, содержит в себе следующую информацию:Главное знать с чего начать и чем закончить, то есть определить основные критерии проектирования (в том числе цели, задачи и ожидаемые результаты). Составить техническое задание на проектирование нужно перед выполнением проектных работ и приложить его к договору подряду, как отдельное приложение, согласованное обеими сторонами. Форма ТЗ — произвольная, правда, есть кое-какие принципы оформления.

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

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

Если вы хотите узнать, как решить именно Вашу проблему – звоните по бесплатному телефону 8 800 350-84-13 доб. 504 (консультация бесплатно)

• Обоснование строительства
• Вид строительства (новое, капитальное, некапитальное, капитальный ремонт, реконструкция или т. д. )
• Полные данные о заказчике
• Сведения об особенностях земельного участка, выделенного под возведение здания (сооружения)
• Требования к возводимому объекту (тип, назначение, этажность, условия использования типовых (готовых) проектов, площадь строительства, использования подземного пространства)
• Очередность строительства
• Сроки начала и завершения строительства, с датой сдачи объекта в эксплуатации, которая должна совпадать с договорными условиями
• Качественные характеристики быстровозводимого здания (по условиям ГОСТ 54257-2010)
• Характеристика стадий проектирования
• Наличие разрешительной документации для строительства

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

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

Заметки ГИПа

При этом, термин РП имел вполне нормальное логичное объяснение — это проектная и рабочая документация в одном флаконе (разрабатывается одновременно). Например, для капитального ремонта незачем разделять проектирование на стадии, а сразу разработать все что требуется, тем более что ПД капитального ремонта не идет на Государственную экспертизу. И тут некоторые Заказчики идут на хитрость. Например, ОАО «Газпром разработал внутренний документ «Линейная часть магистральных газопроводов.

Общие технические требования к проектной документации для капитального ремонта», в котором ввел новый термин для проектной документации — «ПД КР (проектная документация капитального ремонта), которая разрабатывается в одну стадию (ООО «Трансэнергострой участвовал в разработке данного документа). Сами понимаете, что эксперты бывают разные и требования могут выходить очень далеко за рамки проектной документации. А еще, если Заказчик прописывает в ЗП сбор всех необходимых исходных данных, в том числе ТУ, ТТ, то даже если Заказчик сам виноват в их неполучении или невыполнении, то неполучение положительного заключения ГЭ по данной причине вполне можно вменить Подрядчику (типа не «обеспечил, недособрал, или собрал не то», с чем можно «пройти ГЭ»). Был у меня такой прецедент. Меняем задвижку, ПИРы (проектно-изыскательские работы) практически копейки, но в ЗП прописано сделать по Постановлению 87, хотя эксплуатанту (строителю) это вообще не нужно (это никому не нужно), но генпроектировщик (большая проектная организация; ведомственный институт крупной Компании; неадекватный отдел экспертизы, в худшем виде штампующий армейские традиции самой Компании) прицепился, и не отвяжешься.

Что, будем судиться с крупной Компанией ТЭК? Так себе дороже, рынок потеряешь и репутацию заодно, хотя 100 раз можешь быть и прав…Вот такие нюансы… Особенности технического регулирования в области обеспечения безопасности зданий и сооружений и связанных с ними процессов проектирования (включая изыскания), строительства, эксплуатации и утилизации (сноса) устанавливаются Градостроительным кодексом РФ, Техническим регламентом о безопасности зданий и сооружений (Федеральный закон от 30. 12. 2009 № 384-ФЗ), принятыми в соответствии с техническим регламентом о безопасности зданий и сооружений национальными стандартами (ГОСТами) и сводами правил (СП), а также другими нормативными документами.

Кто выдает техническое задание на проектирование

Одежда 10 очаровательных звездных детей, которые сегодня выглядят совсем иначе Время летит, и однажды маленькие знаменитости становятся взрослыми личностями, которых уже не узнать. Миловидные мальчишки и девчонки превращаются в с… Знаменитости 25 ошибок, которые люди неосознанно совершают в постели Вам не нужно шампанское или шелковые простыни, чтобы наслаждаться своей сексуальной жизнью. Постарайтесь избегать этих распространенных ошибок, и ваши… Сексуальность Никогда не делайте этого в церкви! Если вы не уверены относительно того, правильно ведете себя в церкви или нет, то, вероятно, поступаете все же не так, как положено. Вот список ужасных…Что это Техническое задание разрабатывается заказчиком, но достаточно часто в процессе участвует и создатель-проектировщик.

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

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

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

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

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

---

Читайте на сайте «Россия-Украина»:

Внимание!

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

---

Рекомендуем ознакомиться с материалами сайта

Техническое задание [Бесплатный шаблон]

Должно быть время для нового шаблона!

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

• Записывать в письменной форме, что моя Руководящая группа фактически должна делать, чтобы установить «основные правила» для этой группы и их встреч. Это помогает им сосредоточиться на работе, не вдаваться в детали и помогает им и другим серьезно относиться к проекту.
• Для определения того, что должен делать конкретный рабочий поток по проекту. Это полезно, когда кто-то руководит техническим потоком работы, а затем другие нити берут на себя другие. Это почти сокращенная версия Документа об инициировании проекта или Устава проекта, поскольку она касается определенного набора лиц и задач. Мне это нравится, потому что это помогает им и мне увидеть, какова их конкретная роль и обязанности, которые входят в их компетенцию.

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

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

Что входит в документ о техническом задании? Я рада, что вы спросили.

Прочтите, что я добавлю.

Общая информация

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

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

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

Введение в проект

Начните документ ToR для вашего проекта с краткого вводного текста о том, о чем проект.

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

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

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

Цели и результаты

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

• Убедитесь, что все результаты выполнены вовремя, в пределах затрат и с качеством
• Убедитесь, что работа обеспечена достаточными ресурсами в соответствии с общим планом проекта / ресурсов
• Оцените риски и убедитесь, что соответствующие меры по их снижению приняты
• Решите все проекты высокого уровня проблемы, передаваемые для решения соответствующим группам управления по мере необходимости
• Поднимайте и анализируйте изменения, влияющие на проект, включая основные этапы, объем результатов, затраты и выгоды
• Обеспечение соответствия корпоративным политикам и протоколам, влияющим на проект
• Управляйте зависимостями проекта
• Возьмите на себя ответственность за коммуникацию по проекту на местном уровне
• Сделать / внести критические изменения Решения о том, идти / не идти
• Сформулировать планы рабочего потока, включая результаты, разработку, тестирование, внедрение и обмен информацией.

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

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

Ключевые ресурсы / роли и обязанности

Перечислите названия ключей и за что они отвечают.Это легко сделать в виде таблицы.

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

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

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

1. Обзор хода проекта, этапов, рисков и проблем
2. Результаты для утверждения или принятия решений
3. В центре внимания особые вопросы для обсуждения или эскалации
4. AOB

Организационная структура рабочего потока

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

Подход

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

Вехи

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

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

Бюджет

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

Включите заявление вроде:

Ориентировочный бюджет для этого рабочего потока / группы составляет xxx. Это покрывает xxx. Бюджетные предположения включены в PID, а полные цифры подробно описаны в бизнес-модели проекта.

Прочие примечания

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

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

Как получить шаблон

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

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

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

PIN-код для последующего чтения:

Написание деловых документов: «Техническое задание»

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

При предоставлении информации о причине / цели отчета в Техническом задании будет указана сфера охвата отчета. Самый простой способ представить себе «объем» — это определить, что должно быть в отчете, а в некоторых случаях то, что НЕ обязательно должно быть в отчете. Следовательно, область может рассматриваться как границы отчета.

Это может помочь вам включить следующие ингредиенты в Ваше техническое задание:

• Начните с написания «Цель этого отчета — . . . «или» Объем этого отчета. . . «
• В своем Техническом задании вы должны предоставить обзор наиболее важных руководящих принципов, которые были даны вам при написании отчета. Например, эти рекомендации могут касаться:
  • сроки отчета i.е. ежемесячный, ежеквартальный, отчет о проделанной работе, отчет о завершении проекта
  • конкретные требования отчета даны
  • спонсор отчета, т. Е. Лицо или организация, которые заказали проект или расследование, о котором был написан отчет
• Если ваш документ является академическим произведением, он Вы можете сообщить об этом читателю в своем Техническом задании.

Техническое задание не должно быть длинным. Для отчета объемом 5-6 стр. абзаца из 3-4 предложений хватит.

Техническое задание обычно находится в начале отчета.

Как написать рекомендательное письмо (с примерами)

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

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

Что такое рекомендательное письмо?

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

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

Типы справочных писем

Профессиональные ссылки

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

Характерные / личные данные

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

Академические ссылки

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

Перед написанием рекомендательного письма

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

Лучше отказаться от написания рекомендации, чем написать отрицательную рекомендацию для человека.

Запрос информации на письмо

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

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

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

Что включать в рекомендательное письмо

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

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

Как написать рекомендательное письмо

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

Приветствие

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

Первый абзац

Первый абзац рекомендательного письма объясняет вашу связь с человеком, которого вы рекомендуете, включая то, как вы его знаете, как давно вы его знаете и почему вы имеете право написать рекомендательное письмо от его имени. Обязательно укажите название компании, работы, учебного заведения или возможности, на которую претендует человек.Например: «Я был руководителем Джеймса Смита в компании XYZ в течение последних пяти лет. Я рад рекомендовать его на должность главного бухгалтера в компании ABC».

Второй абзац (и третий, и четвертый)

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

Закрытие письма

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

Подпись

Завершите письмо своей подписью от руки, после которой введите свое имя. Если это электронное письмо, просто укажите свое имя и контактную информацию.

Длина буквы, формат и шрифт

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

• Длина: Рекомендательное письмо должно состоять более чем из одного или двух абзацев; такое короткое письмо предполагает, что вы либо плохо знаете этого человека, либо не полностью его поддерживаете. Однако вы хотите, чтобы письмо было кратким и сосредоточилось на нескольких ключевых моментах, поэтому не пишите более одной страницы. Три или четыре абзаца, объясняющие, как вы знаете этого человека и почему вы его рекомендуете, — это подходящая длина.
• Формат: Рекомендательное письмо должно быть через один интервал с пробелом между абзацами.Используйте поля размером около 1 дюйма для верхнего, нижнего, левого и правого края страницы и выровняйте текст по левому краю (выравнивание для большинства документов).
• Шрифт: Используйте традиционный шрифт, например Times New Roman, Arial или Calibri. Размер шрифта должен быть от 10 до 12 пунктов, чтобы его было легко читать. Регулировка размера шрифта — хороший способ сохранить письмо на одной странице.

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

Образец рекомендательного письма

Вы можете использовать этот пример справочного письма в качестве модели. Загрузите шаблон (совместимый с Google Docs и Word Online) или прочтите текстовую версию ниже.

@ Баланс 2020

Мелисса Брэдли
123 Business Rd.
Business City, NY 54321
555-555-5555
[email protected]

9 июля 2020 г.

Jim Lee
Human Resources
Sabre Marketing & PR
321 Business Ave.
Business City, NY 12345

Уважаемый Мистер.Ли,

Я очень рад рекомендовать Сару Джонс на должность менеджера по цифровому маркетингу в Sabre Marketing & PR. Как директор по маркетингу в A&B Media, я имел удовольствие работать руководителем Сары, когда она работала здесь в качестве партнера по маркетингу. Ответственная, пунктуальная и очень яркая Сара была одним из лучших талантов в A&B Media, и я полностью поддерживаю ее квалификацию и набор навыков.

Меня постоянно впечатляли знания, которые она принесла, и ее стремление оставаться на вершине последних достижений в этой области.Сара сочетает в себе острые аналитические способности с сильной интуицией, и я всегда знал, что могу положиться на нее, чтобы уложиться в сроки и превзойти наши ожидания. За два года работы с нами она добилась множества достижений, от увеличения нашего участия в социальных сетях на 20%, до снижения показателя отказов нашего веб-сайта на 10% и до увеличения рентабельности инвестиций в цифровые кампании на 15%.

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

С учетом сказанного, я полностью уверен в своей рекомендации и считаю, что Сара отлично подойдет для Sabre Marketing & PR. Если вы хотите подробнее рассказать о моем опыте работы с Сарой, напишите мне по адресу [email protected] или позвоните мне по телефону 555-555-5555.

С уважением,

Мелисса Брэдли
Директор по маркетингу, A&B Media

Расширять

MyCommittee.com — Техническое задание

Разработка технического задания

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

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

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

Название комитета

Официальное название комитета или группы

Тип

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

Назначение

Опишите цель комитета (чем будет заниматься комитет, почему он был создан)

Область применения

Четко опишите, что входит и не входит в компетенцию комитета

Полномочия

Опишите полномочия комитета по принятию решений (решает, утверждает, рекомендует и т. Д.).)

Членство

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

Организация встреч

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

Отчетность

Опишите, кому комитет будет отчитываться, в каком формате, как часто

Ресурсы и бюджет

Опишите доступные ресурсы (люди, комнаты, оборудование и т. Д.).) доступны для комитета, Опишите средства, доступные для комитета

Результаты работы

Опишите запрошенный / требуемый результат работы комитета

Обзор

Укажите периодичность пересмотра ТЗ и дату следующего пересмотра

Техническое задание Образец

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

Техническое задание для краткосрочного персонала категории специалистов (специальные контракты) **

Место службы: Косово
Должность: Менеджер программы
Классификация: Должностное лицо, уровень P4 (Шкала окладов ООН для Специалисты)
Тип назначения: 6 месяцев с возможностью продления
Работая под непосредственным руководством главы миссии (CoM) МОМ в Косово, сотрудник
будет отвечать за реализацию Программы обучения Корпуса защиты Косово (KPCT).
В частности, он / она будет:
1. Руководить и координировать общую реализацию учебных модулей KPC.
2. Управлять, направлять и контролировать персонал МОМ, участвующий в обучении КЗК, включая консультативные группы руководства
(ВСУ), персонал подразделений МОМ и передвижных технических консультантов КПК.
3. Тесно координировать учебные мероприятия с КЗК. Поддерживать контакты с руководством КЗК
на уровне центрального и регионального штаба.
4. Развивать и поддерживать тесное сотрудничество с Миссией
временной администрации Организации Объединенных Наций в Косово (МООНК) и Силами для Косово (СДК) как на уровне Технической рабочей группы
, так и в повседневной работе.
5. Определите и установите связь с другими агентствами и организациями, предоставляющими помощь и услуги
целевой группе бенефициаров.
6. Предоставлять периодические отчеты, оценки и статистические отчеты на всех необходимых уровнях.
7. Другие задачи в рамках полномочий сотрудника, определенные главой миссии МОМ в Косово.
Требуется образование
· Высшее образование, предпочтительно в области политических или социальных наук, международных отношений, права или эквивалентное
образование и подготовка в соответствии с перечисленными задачами
Требуется техническая компетенция
· Способность налаживать связи с правительственными и дипломатическими органами в качестве а также с
международными организациями
· Хорошие знания в области реализации программ и знакомство с финансовой и деловой сферой
Администрация
· Опыт гражданской защиты и готовности к стихийным бедствиям
· Способность наставничества и наставничества
· Большой опыт в институциональной сфере и наращивании потенциала
Личные / межличностные навыки требуется
· Способность контролировать и руководить персоналом
· Выносливость, решительность, целеустремленность и адаптируемость на рабочем месте
** Это образец для иллюстрации того, как разработать техническое задание.Он не обязательно отражает текущую деятельность руководителя этого проекта.
7
· Отличные коммуникативные навыки и навыки ведения переговоров
· Стремление к результатам и навыки эффективного управления ресурсами
· Опыт работы в регионе Балкан, представляющий особый интерес
· Понимание сложной социально-политической среды, особенно постконфликтных ситуаций
· Чуткость к другие культуры и приверженность развитию межэтнического сотрудничества и толерантности

· Способность работать в тяжелых условиях, сохраняя при этом осведомленность о безопасности
· Гибкость и сосредоточенность на процессах и их улучшениях
· Способность работать эффективно и гармонично с коллегами из разных культур и профессионалов
опыт
· Способность эффективно руководить командой для достижения желаемых целей.
Условия труда
§ Должен быть в состоянии работать в экстремальных условиях и в чрезвычайных ситуациях
Языки
§ Глубокое знание английского языка, рабочее знание французского и / или одного из региональных языков
является преимуществом

In Если у вас есть какие-либо вопросы, ознакомьтесь с часто задаваемыми вопросами о приеме на работу в ООН или отправьте мне отзыв по адресу [email protected] или

Стивен Уайт, генеральный директор Uncareer.net

Образец шаблона рекомендательного письма (бесплатный пример Word)

Как написать рекомендательное письмо

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

Если вы уверены, что можете написать положительное профессиональное рекомендательное письмо, выполните следующие действия:

1. Освежите память о человеке. Например, спросите HR, каково их точное звание, когда они работали в вашей команде и как долго они там оставались. Проконсультируйтесь со своими записями, чтобы узнать, есть ли о них полезные примечания.
2. Запишите два-три качества, которые характеризуют этого человека. Если вы можете вспомнить конкретные примеры, подтверждающие эти качества, также укажите их в рекомендательном письме.
3. Подумайте о конкретном опыте общения с этим человеком. Особенно в тех случаях, когда они показали положительный настрой или знания. Если возможно, включите в письмо один пример.
4. Используйте наш шаблон рекомендательного письма, чтобы сформировать свой собственный формат рекомендательного письма.

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

Вот наш шаблон рекомендательного письма:

Уважаемый [ вставьте имя ],

Я пишу, чтобы порекомендовать [ employee_name ]. [ He / She / They ] работал с нами в [ company_name ] в качестве [ employee_job_title ] и [ сообщил мне / работал со мной ] в моей должности как [ введите название должности ].

Как сотрудник, [ employee_name ] всегда был [ качество вставки ]. В течение [ его / ее / их ] времени в моей команде [ он / она / они ] сумел [ вставить пример ].

Я всегда уделял особое внимание [ качество вставки ] среди членов моей команды, и [ employee_name ] никогда не подводил. Примером было, когда [ вставить пример ].

С

[ Employee_name ] приятно работать, и я без колебаний найму [ его / ее / их ] снова.

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

Спасибо,

[ Ваше имя и подпись ]

Как использовать этот формат рекомендательного письма:

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

Вот пример рекомендательного письма на основе нашего шаблона:

Уважаемый мистер Скайуокер,

Я пишу, чтобы порекомендовать Лею Томпсон. Она работала со мной в Acme Inc. в качестве старшего менеджера по продукции и подчинялась мне в моей должности вице-президента по разработке.

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

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

Лея приятно работать — командный игрок с позитивным и решительным настроем.Я без колебаний найду ее снова, если представится такая возможность.

Если у вас возникнут дополнительные вопросы, свяжитесь со мной по телефону +10000000.

Спасибо,

Сара Лонг

Вице-президент по разработке, Acme Inc.

Шаблон технического задания комитета

— Co-op Tools

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

Имя:

[Официальное название комитета или рабочей группы]

Участников:

• [Имя , роли / обязанности (например, председатель, секретарь, казначей, отчет перед советом директоров) — контактная информация]

Целей:

1. [первичный]
2. [вторичный]

Отчетность

• [Требуются конкретные результаты / запрашиваются у комитета]

Область применения / юрисдикция

[Каковы границы ответственности и полномочий данной подгруппы? Что им нужно решить и что находится за пределами их сферы интересов? Что они могут решить и что требует утверждения вышестоящей инстанции?]

Указания совета директоров / ведущей группы

[Первоначальные указания и предложения от правления и / или более широкой группы]

Ресурсы и бюджет

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

Управление

[Техника принятия решений, например консенсус, 2/3 или большинство голосов, полномочия председателя и т. д. Отношения полномочий внутри группы и с большей организацией.]

Дополнительные примечания

• Отношения с другими комитетами
• Как будет осуществляться общение вне собраний, например список рассылки, Skype, Slack
• Где будет храниться общая информация, такая как планы и контактная информация
• Соответствующие политики / подзаконные акты
• Порядок предоставления отчетности организации
• История комитета
• График встреч и / или другие важные сроки
• Информация о конкретных проектах комитетов

Ваш комитет должен использовать рамки обратной связи

Считаете ли вы сложным расставлять приоритеты и достигать договоренностей на заседаниях комитета?

Рамки обратной связи делают это легко и быстро, с надежными результатами…

.