Большинство заказчиков очень поверхностно относятся к созданию технического задания (ТЗ) на проект. Именно в этом корень многих проблем. Поэтому давайте разберем подробно какие проблемы решает ТЗ и как необходимо его составлять.
Нужно ли создавать ТЗ?
- программисты по-своему понимают как надо делать систему;
- выявляются новые детали, которые требуют дополнительного времени и бюджета;
- требования меняются по ходу проекта (очередная гениальная идея от заказчика, которая требует немедленной реализации).
Экономия на создании ТЗ в итоге оборачивается большими дополнительными расходами на переработки системы.
В некоторых случаях это доходит до того, что все наработки бросаются. Делается новое решение с нуля, с новой командой в надежде, что теперь-то все будет по-другому.
Скорее всего, по-другому не будет — заказчик ведь тот же. Если он не сделал верных выводов относительно процесса разработки, то история повторится.
Что важно знать при создании технического задания
ТЗ нужно как заказчику, так и разработчику. Заказчик получит в точности, что он хочет, что он прописал и согласовал в ТЗ. Исполнитель четко понимает, что ему нужно сделать. Ни больше, ни меньше.
Техническое задание на проектирование. Как правильно написать?
ТЗ должно быть понятно обеим сторонам и содержать все значимые детали по реализации задачи.
Если заказчик не понимает ТЗ, то как он собирается принимать работы по нему?
Если не описаны какие-то детали, то каждый будет домысливать по-своему, а это прекрасная почва для конфликтов, недопонимания и других возможных проблем на проекте.
Не нужно писать ТЗ сразу целиком на большую систему. Дело в том, что пока вы его допишете, некоторые требования уже нужно будет менять/актуализировать. В процессе реализации могут возникнуть новые идеи.
Автор ТЗ, увидев реализацию, понимает, что это не совсем то, и начинает перекраивать требования, что дико всех нервирует (особенно разработчиков). Ведь это может кардинально затронуть структуру базы данных или архитектуру приложения.
Лучший вариант — написать базовое ТЗ на первую простую версию программы и отдельно написать план развития программы.
В плане развития программы будут просто обозначены основные направления развития без детальных требований. В итоге в ТЗ будет детально описано, что необходимо реализовать в краткосрочной перспективе. Также у разработчиков будет понимание, что в будущем заказчик хочет видеть в системе в общих чертах.
ТЗ пишет технарь в соавторстве с заказчиком. Если создание ТЗ поручили одному программисту, то получится очень точное техническое задание на систему, которой никто не будет пользоваться. Программа формально будет корректно работать, но при этом абсолютно бесполезна для бизнеса.
Если за ТЗ берется заказчик, человек от бизнеса, то выходит несвязанная каша: важные детали опущены, нет структуры приложения, и написано такое ТЗ не техническим языком (а ведь ТЗ, по сути это руководство к действию для разработчиков, что нужно реализовать в итоге).
Как составить техническое задание для разработки мобильного приложения?
Хороший вариант — ТЗ пишет технарь по обратной связи от заказчика. Заказчик определяет, что хочет реализовать в терминах бизнес-процессов и ролей, а специалист IT переносит это в плоскость интерфейса программы, структуры данных, связей между сущностями и т.д.
ТЗ — это совместная работа двух сторон.
Иногда встречаются ситуации, когда одна сторона начинает предъявлять претензии другой по поводу «почему вы не предупредили или не заметили этот подвох». В этом случае надо четко разделять зоны ответственности.
Заказчик отвечает за то, чтобы определить, что мы хотим сделать. А исполнитель отвечает за то, как мы пройдем этот путь. Если направление изначально неверно выбрано, то никакие тактические действия уже не исправят ситуацию. В этом смысле работа заказчика в проекте гораздо важнее работы исполнителя.
На практике довольно часто вижу ситуацию, что заказчик очень поверхностно понимает, что он хочет видеть в проекте и ждет, что исполнитель ему предложит варианты, а он выберет (то ли это влияние ЕГЭ, то ли сказки об Илье Муромце, где камень ограничивает ему выбор движения).
ТЗ — это отличное место для заказчика заявить, что он хочет видеть в проекте. Исполнитель должен развить ваше видение в понятный простой интерфейс с правильной структурой данных.
ТЗ лучше писать с будущим исполнителем системы. Так вы сэкономите на ознакомлении команды разработки с бизнес-логикой. Будет более точное понимание проекта и его нюансов.
Если вы — заказчик, то имеет смысл сначала в произвольной форме изложить своими словами суть проекта в виде концепции проекта. Здесь вы можете посмотреть шаблон концепции веб-проекта.
ТЗ — основание для договора. ТЗ определяет, что нужно сделать, и это является основанием для договора об оказании услуг по разработке.
На основе ТЗ создается смета работ и определяются сроки.
Заказчика-дилетанта очень легко узнать по его желанию определиться с точным бюджетом на ранней стадии, когда есть только «Нужно сделать аналог Авито».
Хороший вариант построения работы между подрядчиком и заказчиком — это работа по этапам, где каждый этап состоит из ТЗ, сметы на этап и срока.
Плохо написанное ТЗ или его отсутствие полностью разрушает эту схему работы:
- невозможно определить детально смету, разработчик будет перезакладываться там, где требования написаны общими словами (например, «интеграция 1С»);
- сроки скорее всего не будут выдержаны, т.к. в ходе работ появятся новые неучтенные требования;
- очень сложно будет принимать работы. Будут постоянные споры, что входит / не входит в состав работ.
ТЗ — это рабочий документ, а не формальность. ТЗ создается не для красоты или по прихоти исполнителя. Оно должно быть написано максимально быстро и минимальными усилиями, но при этом содержать все ключевые значимые требования к системе, которые позволят реализовать то, что заказчику в итоге было необходимо реализовать.
На создание ТЗ есть ГОСТЫ. Но имеет ли смысл им следовать? Множество требований просто не актуальны (они созданы более 30 лет назад), документы очень громоздкие, создание подобных ТЗ — это отдельный большой проект.
Считаю, что ТЗ должно решать главную задачу, а не быть формально правильным с точки зрения внешнего стандарта.
Главная задача ТЗ — глубоко понять, что нужно заказчику, корректно зафиксировать это на бумаге и поскорее приступить к реализации.
ТЗ как описание ЧТО + КАК. ТЗ не обязательно должно содержать чисто описание «что нужно реализовать».
В некоторых случаях целесообразно сразу в этом документе проработать и вопрос «как» — детали проектирования системы.
Это расходится с подходом, когда определение требований намеренно отделяется от реализации. ТЗ получается более универсальным, когда реализация может быть любой. Но нам от этого ни тепло, ни холодно. У нас другие задачи — понять, что хочет заказчик и реализовать систему в минимальные сроки.
Все, что не вошло в ТЗ, оплачивается отдельно. ТЗ имеет свои рамки.
Все, что выходит за рамки ТЗ, является дополнением к заданию, на которое должна составляться новая смета отдельно.
Логика простая — изначально смета составляется на основе того, что написано в ТЗ. Если там это не описано, то почему оно должно быть оплачено как бы в рамках ТЗ? В некоторых случаях сталкивался с таким откликом: «Это вы забыли это включить в ТЗ, поэтому это ваша недоработка».
Во-первых, ТЗ пишется совместно, заказчик его читает и согласовывает перед запуском в работу. Такие заявления от заказчика является, мягко говоря, некорректными. Роль заказчика в проекте должна быть активной и направляющей, но никак не пассивно ожидающей, ведомой.
Во-вторых, если работа не описана в ТЗ, значит не учтена в смете, т.е. изначально не заложена в бюджет.
Как мы создаем ТЗ для сайтов на Falcon Space
Далее мы рассмотрим наш вариант создания ТЗ — документа проектирования системы на Falcon Space.
В конце статьи вы найдете ссылку на шаблон документа проектирования, который вы можете взять за основу описания вашей системы.
Немного предыстории. Ранее мы использовали более полный шаблон ТЗ, где было множество дополнительных разделов с терминами, «стандартными требованиями», которые кочевали из одного документа в другой. На практике подобные «пухлые» документы только усложняли чтение и размывали фокус на проекте. Все же основная цель — это именно реализация системы, а не ввести заказчика в религиозный трепет перед 100 страницами описания его проекта, где основа описана на 10–20 листах.
Сейчас мы используем максимально сокращенный вариант, который позволяет понять, что заказчику нужно получить на выходе. И при этом документ написан детально в значимых требованиях.
Давайте пройдемся по разделам нашего шаблона.
Общие сведения о создаваемой системе. Раздел дает понимание исполнителю (зачастую и заказчику) для чего стоит делать систему, и в чем заключается ее ключевая особенность.
Кто ваш пользователь? Здесь мы определяем, кто является пользователем системы и для каких целей он ее использует. Зная эту информацию, можно правильно делать акценты. Если пользователь пришел в систему, чтобы зарабатывать деньги, ему, как правило, наплевать на эстетику вашего дизайна и на ваши уникальные иконки. Ему важно, как можно быстрее сделать свои задачи и не ошибиться с заполнением данных.
Профилей пользователя может быть несколько. Мы называем их ролями (директор, оператор, кассир и т.д.)
Какие задачи решает пользователь? Кратко определитесь со спектром задач пользователя. Этот список дает возможность быстро вникнуть в суть системы и ее назначение.
Как потребитель решает свою задачу сейчас без системы? Какую добавленную ценность будет давать система для пользователя?
Потребитель и раньше мог обходиться без нее? Зачем ему переходить на нее, если и так все хорошо без нее можно делать? Должен быть весомый стимул (внутренний или внешний). Не понимая стимула пользователя, вы просто сделаете еще никому не нужную систему.
Почему такой упор идет на пользователя? Да потому что именно он будет работать в вашей системе.
Именно пользователь определяет успех системы. Нет пользователя — нет системы.
Закройте все потребности пользователя, и ваша система будет на коне. Можно сюда еще много вопросов добавить относительно пользователя, но важно выдержать баланс — вам нужно знать, кто ваш пользователь, и что ему нужно. При этом важно добавлять только те вопросы, которые будут влиять на решения по интерфейсу системы, а не все подряд.
Роли и объекты системы. Детальнее определитесь с ролями: кто есть ваши пользователи, каковы их возможности в системе.
Определите основные объекты в системе. Это могут быть Заказы, Товары, Клиенты и прочее. Для каждого объекта определите какую информацию вы хотите хранить в системе. Это могут быть характеристики клиента, лог действий, статусы и т.д. Подобное описание позволит в дальнейшем учесть все необходимые нюансы при создании структуры базы данных.
Необязательно сразу все учесть с первого раза. В ходе работы над другими блоками, вы в любом случае будете что-то дописывать.
Действуйте итеративно, опишите базово, двигайтесь дальше и дописывайте возможности по ходу появления новой информации.
Определите основные бизнес-процессы. Начните с главных.
Учитывайте следующие моменты по описанию процессов:
- Опишите базовую последовательность действий. В случае сложных процессов с ветвлениями логики можно сделать блок-схему.
- Используйте артефакты. Артефакт — это некий вещественное доказательство, что очередное действие было совершено. Это может быть запись в журнале, документ, уведомление, клеймо (минутка для шутки).
- Не усложняйте излишне новый процесс. Лучше внедрить сначала простой процесс, а потом постепенно его шлифовать и видоизменять по необходимости. Сложно описанный процесс сложно реализовать, сложно внедрять в практику и переделывать.
- Укажите для процесса, что является фактором, триггером и результатом на выходе. Триггер запускает процесс, актор (actor) выполняет основную работу в процессе, результат — это артефакт на выходе после выполнения всех действий процесса.
В плане описания процессов гораздо важнее по сути описать их верно, нежели сама форма. Это может быть простой список последовательных действий.
Не увлекайтесь инструментами проектирования процессов. Чем проще форма описания, тем проще менять эти процессы, тем проще их читать другим участникам проекта, тем больше количество людей в проекте может их изучить.
Если мудреную современную нотацию в проекте понимаете только вы, то толку от такого описания нет никакого. Более того, будет существенный вред. В проекте как бы есть хорошее описание процессов, но его по факту никто не использует.
Также в этом разделе имеет смысл описать ключевые ограничения бизнес-логики, на которые следует обратить внимание исполнителям (например, что Сотрудник может быть привязан к одному Управлению).
Структура проекта и требования к страницам. Это самый важный для исполнителя раздел. Именно здесь мы описываем, что конкретно надо реализовать на страницах приложения.
Первое — опишите структуру страниц по ролям в виде таблицы. Есть неавторизованная область (куда может зайти любой желающий) и кабинет для каждой роли. Для каждой страницы укажите URL и краткое описание. Данная таблица является картой всего проекта, неким скелетом приложения.
После определения структуры приложения описываем каждую страницу более детально. Мы используем для разработки нашу платформу Falcon Space, а это определяет наш способ создания страниц (размещения компонентов). Мы сразу указываем более точно привязку к нашим компонентам в требованиях страниц — это ускоряет процесс выполнения задач. Не нужно дополнительно расписывать как реализовывать ту или иную функциональность, т.е. создавать дополнительный документ комментариев к ТЗ для разработчика)
Описание каждой страницы может содержать следующие элементы:
- Что выводим на странице: таблицы, формы, какие колонки, какие кнопки будут доступны, будут ли модальные формы, подтаблицы, комментарии. Максимально детально и конкретно.
- Действия управляющих кнопок. Как должна работать та или иная кнопка. Что меняется в состоянии объектов. Что выводится пользователю в случае успеха/провала операции. Какие проверки надо сделать и т.д.
- Ограничения доступа. Кто имеет доступ к странице. Есть ли специфические ограничения доступа (не просто по роли, а, например, только автор задачи может менять ее дедлайн).
Любая неточность или неконкретность в описании страниц — повод для будущего спора заказчика с исполнителем.
Поэтому старайтесь все описывать понятным простым языком, но при этом максимально конкретно.
Интеграции с внешними системами. Необходимо определить перечень внешних систем, с которыми должна быть выполнена интеграция.
В отношении каждой интеграции необходимо определить следующие моменты:
- Какие данные необходимо передавать между системами и в каких направлениях. Не нужно писать просто «интеграция всего и вся». Вам нужны конкретные данные, именно их и надо определить. Желательно определить точный формат самих данных, не просто передача Товара, а передача в виде такой-то JSON структуры.
- В каком формате и по какому протоколу будут передаваться данные. Например, с помощью GET запросов по HTTPS протоколу с использованием формата JSON.
- Лучше заранее определиться может ли внешняя система интегрироваться с вашей, т.е. определить ее возможности по интеграции, и от этого необходимо строить свой API взаимодействия с этой системой.
- API — это дополнительный фактор неопределенности в проекте. В случае интеграции с неизвестной системой в ТЗ имеет смысл на первом этапе заложить просто проработку прототипа API для понимания основных возможностей интеграции. В противном случае, если заказчик хочет все и сразу, разработчик должен перезакладываться на эти риски возникающих проблем из-за третьей стороны (внешнего поставщика API).
Возможные расширения сайта в будущем. Это план будущих возможных улучшений программы. Это могут быть различные интеграции, новые модули или кабинеты.
Данная информация позволяет понять разработчику, что ему следует ожидать в будущем в отношении развития системы. Это страхует нас от риска, что где-то посередине проекта выяснится, что оказывается критически важную возможность проблематично реализовать на данном решении.
Проектирование базы данных. Это элемент реализации системы. Здесь прописывается начальная структура базы данных — таблицы со столбцами, отношения таблиц, индексы, ключи и прочее.
Почему это сделать хорошо на раннем этапе? В этом случае можно показать внешнему специалисту структуру БД и получить некий фидбек. Проблемы неверной структуры БД очень критичны. Поэтому исправлять их лучше всего на самых начальных этапах, когда сама база еще не создана, или когда данных в базе мало.
Техническому специалисту база данных расскажет об основных объектах системы и взаимосвязи этих объектов. Полезно также текстом описать ключевые связи, например, Товар может принадлежать различным Категориям, Категории могут быть вложены друг в друга на 3 уровня т.д.
Заключение
Как составить ТЗ: даем подробную инструкцию
Сегодня разберёмся с таким термином, как техническое задание. Что это такое? Как его правильно разработать? На что стоит обязательно обратить внимание? Ответ на эти вопросы важен, ведь именно от того, как составлено техзадание, во многом зависит результат работы.
Если задачи сформулированы не точно, то и выполнены они будут соответствующим образом. Видение исполнителя далеко не всегда соответствует видению заказчика, поэтому в статье мы расскажем о том, как правильно формулировать свои требования и пожелания.
Почему разработка технического задания так важна
Нельзя недооценивать важность ТЗ. На самом деле этот документ по значимости можно сравнить с договором, в котором прописаны обязанности всех участников сделки.
Техническое задание на разработку того или иного проекта можно назвать инструкцией по выполнению работы. Поскольку структура ТЗ подразумевает перечисление всех условий процесса и деталей результата, то сотрудничество становится более понятным, комфортным и безопасным как для заказчика, так и для исполнителя.
Происходит это потому, что в ТЗ детально описывается каждый нюанс, подробно разъясняется каждая мелочь. Как итог – пространства для ошибки, неверного действия или обмана практически не остается, ведь любое нерегламентированное действие будет считаться нарушением инструкции.
Но даже не это является главным преимуществом полноценного ТЗ, а то, что профессиональный подход гарантирует качественный итог. Чтобы в результате получить продукт, который будет отличаться бесперебойной работой и отвечать всем нормам и требованиям, важно остановиться на деталях, всё тщательно просчитать и продумать. А основные требования к техническому заданию как раз подразумевают скрупулезное отношение ко всем рабочим моментам.
Ошибочно считать, что подобный подход применяется исключительно при выполнении сложных процессов. Даже самые простые задания требуют чётких инструкций, а все ходы должны быть просчитаны на три шага вперед. Именно поэтому написание ТЗ является обязательным этапом любой работы.
О стандартах написания технических заданий
Как писать ТЗ часто не знают даже те, кому по роду своей деятельности регулярно приходится ставить определенные задачи перед исполнителями. Главными требованиями здесь являются продуманность, чёткость и полная передача нужной информации. Но, не имея должного опыта, сложно реализовать задуманное, опираясь исключительно на заявленные требования. Для написания полноценного задания, необходимо знать стандарты разработки ТЗ, которые считаются общепринятыми и применяются во всех сферах деятельности.
В некоторых профессиях от кандидатов при трудоустройстве даже требуют знания ГОСТ 34 и/или ГОСТ 19. Например, это относится к таким профессиям как технический автор или системный аналитик. Речь идет о государственных стандартах, которые успешно применяются как образец оформления и составления ТЗ.
Важно отметить, что указанные выше ГОСТы относятся непосредственно к программным комплексам, поэтому применять их можно как шаблон технического задания на разработку ПО и тому подобных продуктов.
Для многих станет настоящей неожиданностью то, что ГОСТ 19 действует с 1980 года. Но, поскольку модель программного обеспечения не подвергалась значительным изменениям, актуальность этого стандарта не теряется и сегодня.
В этой сфере деятельности, как и в большинстве других, есть свои азы и основы, которые остаются неизменными даже с течением времени и развитием новых технологий.
ТЗ на разработку ПО обязательно должно включать в себя такие пункты:
- Вступление
- Основа для разработки ПО
- Сфера применения
- Ключевые требования к ПО
- Обязательные требования к документации и к программе
- Технико-экономические показатели
- Этапы работы и их очередность
- Сроки и особенности приемки и контроля готового ПО
- Приложения
ГОСТ 34 принят на 10 лет позднее описанного выше стандарта. Нельзя сказать, что он сильно отличается от предшественника, но свои особенности у него точно есть. Пример оформления ТЗ согласно этому документу выглядит следующим образом:
- Общая информация о системе
- Назначение системы
- Информация об объектах, для которых создается система
- Ключевые требования к готовому продукту
- Этапы выполнения работы и особенности каждого этапа
- Порядок приемки готового продукта
- Этапы подготовки системы к вводу в действие
- Требования к программной документации
- Источники разработки
Нельзя сказать, что современные ТЗ пишутся исключительно по этим образцам – время внесло свои корректировки и появилось множество новых правил и рекомендаций. Но эти документы точно можно использовать как базу на проектирование ГОСТ-совместимого технического задания. Полностью следовать перечисленным требованиям необходимо исключительно в случае взаимодействия с государственными структурами.
Что касается составления заданий для международных проектов, то здесь применяется стандарт ISO/IEC/IEEE 29148:2018, разработка которого принадлежит Международной организации по стандартизации ISO. Как и в случае с ГОСТами, тут есть опорные пункты по составлению полного и качественного технического задания. Задание международного образца включает:
- Описание системы или продукта. Для кого предназначен объект и что пользователь может в нём делать.
- Технические характеристики: производительность программы, интерфейс, безопасность и так далее.
- Описание этапов тестирования.
- Приложения и история изменений проекта.
Общие рекомендации для составления понятного ТЗ
Даже зная ГОСТы, разбираясь в требованиях и понимая, что такое инструкция по написанию хорошего ТЗ и как её использовать, без практического опыта сложно сделать все с первого раза именно так, как запланировано. Если составление технического задания требуется не для государственной системы и не для официальной иностранной организации, совсем не обязательно следовать ГОСТам. Можно дополнить ТЗ элементами, которые сделают жизнь заказчика и исполнителя гораздо проще.
Во многом советы от специалистов в сфере разработки ТЗ дублируют пункты ГОСТов, однако тут есть и дополнительные детали, которые точно помогут приблизить реальный результат к желаемому.
1. История правок – обязательно сделайте таблицу, в которой будут прописаны все изменения в документе и причины правок. Указывайте дату и автора идеи. Это поможет увидеть слабые места и сформировать устойчивый алгоритм действий на будущее.
2. Словарь – все термины, сокращения и аббревиатуры должны быть внесены в отдельный список. Неважно, будут ли эти слова применяться в дальнейших проектах или же используются только в этом ТЗ.
3. Уделяйте внимание мелочам – в результате выполнения работ по составленному техническому заданию должен получиться идеальный продукт, готовый для работы.
Последний пункт особенно важен и требует внимания. Ряд деталей может ускользнуть из вида из-за того, что какие-то из моментов покажутся заказчику очевидными и включенными в работу по умолчанию. Данное мнение может быть субъективным и исполнитель не всегда обладает таким же видением. При написании технического задания стоит абстрагироваться от оценочных суждений, расписав каждый пункт максимально подробно. К примеру, если составляется ТЗ для разработки сайта, то оно должно содержать не только технические моменты, но и такие нюансы, как оплата сервера, адаптация юзабилити под пользователя, для мобильных устройств и тому подобное.
Что может помочь при составлении технического задания
Теперь, когда мы разобрались с обязательными пунктами, которые должно содержать техническое задание, поговорим о других документах, призванных помочь в его составлении. В небольших компаниях и на ряде проектов эти элементы даже могут заменить ТЗ, так как представляют собой пошаговые инструкции с исчерпывающей информацией.
Бриф
Главный опросник, который заполняет заказчик перед началом работы. Если создать список вопросов грамотно, то можно и вовсе избежать подписания дополнительных инструкций. Так как бриф в данном случае будет являться полноценным планом работ. Во многом сложность заполнения инструкции зависит от специфики заказа. Так, составление задачи на разработку полноценного интернет-магазина будет содержать куда больше пунктов, чем бриф на создание рекламного баннера.
Приведем для примера бриф на разработку сайта. Он поможет стать отличным фундаментом для начала работы.
Бриф на разработку сайта
| Наименование организации | _________________ |
| Контактное лицо | _________________ |
| Телефон, email контактного лица | _________________ |
| Сфера услуг, оказываемых компанией | _________________ |
| Геолокация оказываемых услуг / доставки товаров | _________________ |
| Сайт компании | _________________ |
| Целевая аудитория | _________________ |
| Главные конкуренты на рынке | _________________ |
| Цели и задачи сайта (визитка, презентация, каталог) | _________________ |
| Разделы сайта (контакты, магазин, блог и пр.) | _________________ |
| Как часто планируются обновления контента сайта | _________________ |
| Мультиязычность сайта (в случае необходимости укажите языки) | _________________ |
| Характеристика дизайна сайта (лаконичный / серьёзный / яркий и т.д.) | _________________ |
| Впечатление, которое должен произвести ресурс на пользователя | _________________ |
| Есть ли у компании фирменный стиль и логотип (приложите ссылки на файлы) | _________________ |
| Нужны ли на сайте анимированные элементы | _________________ |
| Интеграция систем онлайн-оплаты | _________________ |
| Магазин | _________________ |
| Архив | _________________ |
| Email рассылка | _________________ |
| Форма обратной связи | _________________ |
| Новости | _________________ |
| Отзывы | _________________ |
| Другое (укажите необходимые дополнительные функции сайта) | _________________ |
| Требуется ли регистрация домена | _________________ |
| Требуется ли регистрация сайта на хостинге | _________________ |
| Необходимо ли место на сайте для рекламных баннеров | _________________ |
| Необходима ли раскрутка сайта ресурсами исполнителя | _________________ |
| Сроки выполнения | _________________ |
| Бюджет | _________________ |
| Сроки проверки заказа | _________________ |
| По мере готовности передать готовую работу (контакты) | _________________ |
Коммерческое предложение
Описание услуг или продукта в данном случае оформляется наиболее подробным образом. Презентация содержит не только описание товара, но и технические характеристики, стоимость и прочие условия взаимодействия с клиентом.
Прочитав такое коммерческое предложение, потенциальный заказчик сразу же видит все условия сделки и выгоду сотрудничества. На основе имеющихся данных ему проще принять решение о работе или сравнить компанию с другими исполнителями.
Какую информацию обязательно стоит включить в коммерческое предложение?
- Информацию о компании: название, сфера деятельности, направления работы. С какого года вы работаете на рынке? Какие услуги предоставляете?
- Выгода для клиента. Как продукт отличается от прочих аналогичных? Сколько довольных клиентов у компании? Какие условия доставки? В данном пункте эффектно будут выглядеть чёткие цифры, которые дадут понять клиенту, почему нужно выбрать именно вас.
- Цена. Обязательный блок с ценами стоит оформить наиболее прозрачным и удобным к восприятию образом. Учтите все вариации комплектации продукта, чтобы максимально подробно донести информацию до заказчика.
- Технические характеристики продукта. Срок эксплуатации, комплектация и так далее.
- Условия взаимодействия. Гарантия, доставка, возврат товара, контакты.
И бриф, и коммерческое предложение станут отличными помощниками для старта взаимодействия по тому или иному проекту. В ряде случаев вполне уместно разместить данные документы на сайт. Так заинтересованный заказчик сразу сможет сделать выводы о рациональности сотрудничества.
Грамотное ТЗ – залог хорошего результата. Помните об этом и присматривайтесь к мелочам!
Источник: romi.center
Что такое ТЗ?
Техническое задание, или ТЗ — это документ, фиксирующий требования к проекту. Главное условия хорошего технического задания — четко прописанные характеристики итогового результата.
В документе должны быть четко описаны функции и требования к системе. На основании этого документа подрядчик выстроит план работ и оценит их стоимость.
Зачем писать техническое задание на внедрение CRM?
Допустим, вы прекрасно знаете, какие функции вам нужны, и можете рассказать обо всех характеристиках будущей системы. Не поленитесь их записать!
Устные формулировки могут трактоваться по-разному, а в ходе длительной работы, могут еще и меняться.
На первый взгляд кажется, что составление технического задания тормозит процесс и оттягивает момент начала работы. На самом деле ТЗ позволяет:
- Отказаться от лишних функций системы и сэкономить деньги
- Контролировать работу подрядчика
- Рассчитать бюджет и управлять им.
- Управлять сроками внедрения.
Главная цель ТЗ, сделать это внедрение CRM управляемым, а результат предсказуемым.
Кто должен писать техническое задание на внедрение CRM?
Единственно верного ответа нет. Никто не знает лучше заказчика, какие именно функции ему нужны. Однако заказчик редко может переложить свои задачи на язык технических специалистов.