Техническое задание: нюансы и советы

Техническое задание на объект

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

Техническое задание на проектирование разрабатывается на основании ГОСТ 15.001-88 и оформляют в соответствии с общими требованиями к текстовым конструкторским документам по ГОСТ 2.105-68

Техническое задание — это основной исходный документ для разработки продукции, содержащий технико-экономические требования к продукции, определяющие ее потребительские свойства и эффективность применения, перечень документов требующих совместного рассмотрения, порядок сдачи и приемки результатов разработки. Техническое задание на проектирование разрабатывается на основании ГОСТ 15.001-88 и оформляют в соответствии с общими требованиями к текстовым конструкторским документам по ГОСТ 2.105-68.

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

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

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

· установить общую цель создания технической системы;

· установить общие требования к проектируемой системе;

· определить этапы создания системы и сроки их выполнения;

· провести предварительный расчет затрат на создание системы.

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

1) наименование и область применения;

2) код изделия;

3) основания для разработки;

4) цель и технико-экономическое обоснование;

5) источники для разработки;

6) этапы разработки и запуска производства;

7) технические требования.

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

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

Основанием для разработки является маркетинговые исследования и выход нового стандарта.

В разделе «Цель и технико-экономическое обоснование разработки» указывают:

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

2.

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

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

Название сценария: Создание рекламного места

Роль: Администратор

Пример функционального требования:

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

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

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

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

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

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

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

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

Частота контакта – количество уникальных пользователей, посмотревших рекламный баннер определенное число раз. Например, частота контакта 5 – количество уникальных пользователей, каждый из которых посмотрел данный рекламный баннер не менее 5 раз. Частота контакта 1 = Охват.

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

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

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

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

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

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

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

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

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

Что дает сторонам каждый раздел ТЗ:

Раздел ТЗ

+ Для Заказчика

+ Для Разработчика

Осознание задач, которые решает проект или его доработка

Понимание сути задачи

Представление о том, каким будет готовый продукт

Уверенность в правильном понимании конечного результата

Ориентирование в сроках работ и получения планируемых результатов

Оценка трудозатрат и потребности в ресурсах

Определение более-менее точной суммы затрат и планирование бюджета

Согласованный учет всех работ проекта

Подробное описание работ и каждого этапа реализации проекта

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

Оценка результата работ

Проверка работы проекта по программе тестирования на соответствие требованиям задания

Возможность удостовериться в бесперебойной работе проекта и в его соответствии требованиям ТЗ

Планирование затрат на обслуживание и представление о дальнейшей поддержке проекта

Выполнение работ с учетом обслуживания проекта в перспективе

Планируемые доработки проекта

Доработка в соответствии с новыми потребностями

Описание задачи

В этом блоке мы ставим задачу и описываем ее нюансы:

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

Объясните это заказчику.
Если вы ведете с клиентом разговор о числе успешно выполненных заявок, нужно определять конкретные цифры, притом лучше всего в формате «было/стало».
Грамотное внедрение CRM-системы отличается от непродуманного тем, что здесь принимаются во внимание промежуточные результаты и намечаются точки роста, понятные обеим сторонам. Отразите это в КП.

Основные проблемы проекта внедрения CRM-системы

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

Недостаточный контроль на этапе запуска

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

Использование старых инструментов

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

Такие переписки не фиксируются в системе, что может привести к потере важной информации

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

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

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

Отсутствие регламентов

Из-за отсутствия регламентов вы можете столкнуться с большим количеством ошибок со стороны персонала: «не туда нажал», «не понял, как создать заявку» и тому подобное.

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

• Как правильно работать с карточками.
• Как создавать и вести сделки.
• Как назначать задачи.
• Как использовать инструменты.
• Как отправлять письма и общаться с клиентом из карточки.
• Как формировать отчеты.

Скупость при покупке лицензии

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

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

Игнорирование необходимости обучения

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

Отсутствие личного примера

Сотрудники уважают руководителя за то, что он отзывчив и хочет развиваться вместе с командой

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

Безуспешные попытки внедрения

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

Излишняя самостоятельность

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

Когда следует подключить специалиста:

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

Саботаж менеджеров

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

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

Нерегулярная работа в CRM

Чтобы понять, насколько система эффективна, ее нужно использовать постоянно

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

Отсутствие роста продаж

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

ГОСТ 19 для Технического задания

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

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

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

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

В разделе 2 «Основания для разработки» должны быть указаны:

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

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

Раздел 4 «Требования к программе или программному изделию» должен содержать следующие подразделы:

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

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

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

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

В подразделе 4.4 «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.

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

При необходимости должна обеспечиваться защита информации и программ.

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

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

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

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

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

В разделе 8 «Порядок контроля и приёмки» должны быть указаны виды испытаний и общие требования к приёмке работы.

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

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

Кто должен составлять ТЗ

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

Рассмотрим на примерах, чем будут различаться их задания.

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

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

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

• перечень страниц сайта;

• краткое описание блоков страниц;

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

• информацию о ссылках и переходах;

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

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

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

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

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

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

Итак, техническое задание, вне зависимости от выбранного ГОСТа, всегда включает следующие основные сведения по разрабатываемому ПО:

1) наименование – полное и краткое названия, условное обозначение разрабатываемого ПО; 2) назначение – то, для чего, в какой области и с какой целью разрабатывается ПО; 3) основание для разработки – документы, на основании которых производится разработка ПО; 4) функции – перечень и описание функций разрабатываемого ПО; 5) структура – описание архитектуры и компонентов разрабатываемого ПО; 6) пользовательский интерфейс – в современном мире обязателен; 7) надежность, безопасность, условия эксплуатации и проч. важные требования;  документация – какая документация, в каком объеме и в соответствии с какими требованиями ГОСТов будет также разработана; 9) стадии и этапы разработки – что и в какой последовательности разрабатывается; 10) порядок контроля и приемка – как именно будет происходить сдача разработанного ПО Заказчику.

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

Существует несколько ГОСТов, регламентирующих разработку ТЗ в нашей области: это ГОСТ 34.602 (автоматизированные системы) и ГОСТ 19.201 (программное обеспечение). Документы, выполненные по этим стандартам, значительно отличаются как по наполнению, так и по содержанию. Оба стандарта представлены на нашем корпоративном портале в разделе Библиотека, вы можете самостоятельно ознакомиться с ними более подробно.

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

Наименование документа	Наименование стандарта ГОСТ	Стоимость разработки	Срок выполнения	Пример выполнения
ТЗ на программное обеспечение	ГОСТ 19.201	60-180 тыс. руб.	2-6 недель	Пример
ТЗ на автоматизированную систему	ГОСТ 34.602	60-180 тыс. руб.	2-6 недель	Пример

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

Возможно, вас также заинтересует:

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

Что такое CRM-система и какие задачи бизнеса решает

CRM — Customer Relationship Management — переводится как «управление отношениями с клиентами». Это программа, которая помогает бизнесу не терять заявки, хранить историю работы с клиентами и упрощает процесс продаж.

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

CRM-система нужна бизнесу, чтобы решать такие задачи:

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

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

Можно фильтровать по менеджеру — CRM покажет, с какими клиентами он работает

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

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

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

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

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

В CRM-системы часто встроен календарь и планер, куда можно вносить все плановые коммуникации c клиентами

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

Участники проекта

Заказчик	Менеджер проекта	Разработчики
Ставит задачу	Ставит задачу разработчикам	Выполняют задание в соответствии с ТЗ
Согласовывает ТЗ	Контролирует ход работы и расставляет приоритеты
Принимает работу	Осуществляет взаимодействие с заказчиком и разработчиком
Тестирует выполненную работу (если нет тестировщиков)

Если проект большой, дополнительно могут добавиться участники:

• Product Manager
• Руководитель проекта
• Спонсор проекта
• Тестировщики
• Технические писатели
• Кураторы
• Пользователи/потребители (например, для финального тестирования)
• И др.

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