Техническое задание: полное руководство шаблон (уникальный)

Что это и зачем нужно

Неважно, кто будет исполнителем сайта – Вы сами, Ваш родственник, фрилансеры за скромную оплату, специализированная компания за огромную сумму денег…

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

Техническое задание (коротко “ТЗ”) – это документ, который максимально подробно и однозначно отражает требования к Вашему будущему сайту.

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

ТЗ на создание сайта – как закон, не должно допускать трактовок и разночтений.

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

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

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

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

Кто пишет ТЗ

Кто должен составлять техническое задание на разработку сайта? На этот вопрос есть только два варианта ответа: заказчик или исполнитель.

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

Ваши цели:

1. Понять, какой именно сайт Вам нужен;
2. Зафиксировать бюджет (иначе Вам потом выставят счёт, мама не горюй);
3. Контролировать разработчика (сроки, объём работ, функционал, переделки и т.д.).

Цель разработчика:

1. Понять и с первой попытки удовлетворить заявленные Вами пожелания;
2. Избежать бесплатных доработок и корректировок.

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

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

Бриф на разработку сайта

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

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

ТЗ на разработку сайта можно составить только на основе Ваших пожеланий и никак иначе.

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

Бриф – это анкета с вопросами о содержании, дизайне, технических возможностях Вашего будущего сайта.

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

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

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

Либо в графе “Дополнительная информация” обязательно укажите все Ваши пожелания, не вошедшие в ответы на вопросы. Если эта графа отсутствует, просто допишите их в конце брифа. Главное не оставлять недосказанности.

Как определить цветовую гамму

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

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

Не лишним будет немного изучить вопрос восприятия цвета в рекламе. Или обратиться в Google за помощью.

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

Секрет. Подкрутит первые отзывы, оценки и прочие поведенческие факторы на Вашем сайте и тогда остальные пользователи будут к Вам более лояльны. Рекомендуем для накрутки TaskPay, сами им пользуемся. Кликайте -> TaskPay

Iso/iec/ieee 29148

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

Последняя редакция — ISO/IEC/IEEE 29148:2022, но, к сожалению, она отсутствует в открытом доступе, поэтому возьмём за основу предыдущую, от 2022 года.

По аналогии с ГОСТами, стандарт содержит два раздела. Один из них, SyRS — System Requirements Specification — определяет общие требования к построению систем, их принципам и характеру взаимодействия пользователя с ними. По похожей схеме составлен ГОСТ 34.

SRS — Software Requirements Specifitaion — по аналогии с ГОСТ 19, содержит требования к конечному программному продукту.

Общая схема строится следующим образом:

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

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

To be или проектирование новых бизнес-процессов и пользовательских сценариев

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

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

Пользовательское требование руководителя дивизиона:

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

Возможные сценарии на основе этого требования:

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

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

Вход в кабинет на сайте

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

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

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

Выделение минимального набора сценариев для запуска

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

Пример MVP:

Личные кабинеты:

Примеры сценариев руководителя дивизиона:

Примеры сценариев дилера:

Для чего нужно техническое задание?

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

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

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

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

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

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

Интервью с заинтересованными лицами, постановка бизнес-целей

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

Такие проблемы нам были озвучены:

Таким образом, целями работы стали:

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

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

На первой встрече с нашим заказчиком мы также:

Узнали, что:

Получили:

Познакомились с:

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

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

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

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

Исследование предметной области

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

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

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

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

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

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

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

Коротко о главном

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

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

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

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

Кстати. Создайте собственный сайт через конструктор за один день и без программистов. В арсенале готовые шаблоны, мобильная версия, корзина, платежи и еще 10 инструментов. Кликайте и тестируйте -> InSales (по промокоду “inscale” 30 дней бесплатно).

Опишите требования к проверке проекта

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

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

Ошибки при написании тз

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

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

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

1. Нет ограничений во времени

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

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

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

2. Утрата данных доступа

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

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

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

Поэтому запомните, что данные доступа к хостингу и доменному имени – это Ваши личные данные.

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

Кстати. Интегрируете CRM-систему с Вашим сайтом, чтобы посетители сайта сразу попадали к Вам в базу, так Вы не потеряете ни одного клиента. К тому же там много фишек, которые помогут сделать из сайта просто бомбу продаж и еще автоматизировать бизнес-процессы. Кликайте -> Мегаплан

3. Отсутствие наглядности

Принцип “лучше 1 раз увидеть, чем 100 раз услышать” работает здесь на полную. В одни и те же слова заказчик и исполнитель могут вкладывать разный смысл.

И наверное эта ошибка вообще должна стоять на первом месте нашего хит-парада, так как такая картина происходит постоянно: “Хочу абстракцию”, – пишет заказчик, подразумевая нечто подобное (пример на картинке ниже)

“Ок, держите”, – говорит разработчик. И предлагает заказчику абстракцию следующего вида.

И попробуй потом докажи, что Ваша абстракция абстрактнее его. Каждый прав, никто не виноват.

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

4. Качественные прилагательные

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

Например, красивый (кто-то может быть ещё красивее или страшнее), умный, современный и т.п. Это слова-табу. Их нельзя однозначно понять. У каждого субъективное представление о красоте и современности.

Только конкретика. Например, “На два тона светлее”, “Смещаем на 5 сантиметров” или “Острые углы у кнопки”.

5. “На усмотрение разработчика”

Об этот коварный пункт спотыкаются многие. Заполняя бриф или составляя тз на дизайн сайта, не оставляйте в нём пробелов.

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

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

Но тут возникает другая проблема, он может сделать реально как надо, а Вам не понравится чисто субъективно. И всё будет как в известном для многих разработчиков анекдоте:

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

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

Например, этот дизайн кому-то показался красивым, и он использовал его на своем сайте:

То же самое относится и к невнятным формулировкам. Например:

Обязательно проверьте текст: в нем не должно быть неоднозначных формулировок. В противном случае ТЗ придется переписать. Все мысли следует сформулировать четко и точно. Например:

Полевые исследования

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

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

Порядок документирования требований

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

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

Предпроектное проектирование

Этот пункт является неотъемлемой частью технического задания на создание сайта, хотя фактически он к нему не относится.

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

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

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

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

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

Каждый лист – отдельная страница сайта (или экран одностраничника). Либо можно воспользоваться простыми офисными программами вроде Microsoft World или Microsoft Excel.

Лично мы при разработке landing page используем специальные программные продукты.

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

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

Интересно. Не забудьте установить на сайт систему комментирования. Так пользователи смогут делиться своим мнением и даже подталкивать к покупкам других посетителей (а еще это положительно влияет на SEO). Кликайте и узнавайте подробнее -> Сackle

Проектирование автоматизированной системы работы с дилерами

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

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

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

«Конечно, добавим», — ответим мы и обязательно предложим сделать это правильно.

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

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

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

Прописывайте каждую деталь

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

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

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

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

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

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

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

Пример структуры кабинета дилера, * отмечена версия MVP:

1. Страница авторизации*

2. Рабочий стол*

3. Моя компания

а) Профиль*

б) Договор и дополнения*

в) Коммерческие условия*

г) О компании*

– сотрудники*

– склады*

– территория работы*

– контракты других производителей*

– специализированные подразделения*

– требования и преимущества*

д) Грузополучатели*

е) Объекты*

4. Каталог

а) Список товаров

б) Корзина

в) Оформление заказа

5. Заказы и платежи

а) Мои заказы

– заказы

– отгрузки

б) Мои платежи

в) Дебиторская задолженность

5. Продвижение

а) POS-материалы

б) Акции

в) Бонусы

6. Сдать отчет*

7. Помощь*

8. Настройки*

9. Контакты*

10. Уведомления*

а) Автоматические уведомления*

б) Сообщения*

в) Написать сообщение*

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

Вот так могут быть заданы права:

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

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

Структура данных всегда представлена в виде схемы

Технико-коммерческое предложение

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

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

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

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

Технические особенности

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

Для работы личного кабинета нашего заказчика были необходимы каталог товаров и данные дилеров (контрагентов). Все это хранится в системе «1С: Предприятие». Структура каталога не оптимальна, использовать ее неудобно (интуитивно не понятно, в какой категории находится товар, а ведь дилеру теперь придется искать его самостоятельно), данные не всегда заполнены (нет описаний, перепутаны фасовки).

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

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

В результате этапа исследования у нас, как правило, есть:

1. Сформулированные руководством цели и задачи для создания личных кабинетов;

2. Общее понимание и детальное описание бизнес-процессов, которые будут автоматизированы в результате их создания;

3. Список пользовательских требований от каждого типа пользователей личного кабинета;

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

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

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

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

Отрывок из технического задания:

3.1.1.1.1. Склады

Основная часть страница включает следующие элементы:

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

– название (адрес) склада;

– город, в котором расположен склад;

– площадь склада (кв.м.);

– отметка принадлежности склада компании. Если стоит эта отметка, данные площади склада учитываются в статистической информации о складах в Личном кабинете сотрудника. Площадь складов, у которых не стоит данная отметка, в этой статистике не учитывается;

– дополнительная информация: текст с описанием склада.

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

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

2. Форма добавления нового склада со следующими полями, * отмечены обязательные для заполнения поля:

– название (адрес) склада (текстовая строка)*;

– город склада (текстовая строка) *;

– собственный склад (чекбокс)*;

– площадь склада, м2 (число)*;

– дополнительная информация (текстовое поле).

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

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

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

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

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

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

Функциональные требования

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

Пользовательское требование руководителя дивизиона:

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

Функциональные требования, которые из него вытекают:

1. Видеть общую информацию по отгрузкам дилерам своего дивизиона с возможностью множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) конкретного товара;

г) региона/города;конкретного менеджера;

д) конкретного дилера.

2. Устанавливать и менять план отгрузок на месяц для каждого менеджера дивизиона.

3. Видеть план компании по отгрузкам для дилеров своего дивизиона с возможностью множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) региона/города;

в) группы товаров (ССС, СЦС, ГСП, ПГП);

г) конкретного товара;

д) конкретного менеджера;

е) конкретного дилера.

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

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) конкретного товара;

г) региона/ города;конкретного менеджера;

д) конкретного дилера.

5. Видеть общую информацию о вторичных продажах дилеров своего дивизиона с возможностью множественного и одновременного выбора:

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) региона/города;

г) конкретного менеджера;

д) конкретного дилера.

6. Указывать, сколько дилеров предоставили информацию

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

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) региона/дивизиона и города;

г) конкретного менеджера;

д) конкретного дилера.

8. Видеть общую информацию о дебиторской задолженности дилеров своего дивизиона с возможностью множественного и одновременного выбора срока задолженности:

а) общая;

б) не более 14 дней;

в) 15-30 дней;

г) 31-45 дней;

д) 46-60 дней;

е) больше 61 дня.

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

а) периода времени (неделя, месяц, год);

б) региона/города;

в) конкретного менеджера;

г) конкретного дилера.

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

а) периода времени (неделя, месяц, год);

б) группы товаров (ССС, СЦС, ГСП, ПГП);

в) конкретного товара;

г) региона/города;

д) типа транспорта;

е) конкретного менеджера;

ж) конкретного дилера.

В итоге:

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

Наш заказчик получил:

1. Личный кабинет для дилеров компании с возможностями:

– самостоятельно собрать и оформить заказ продукции компании, видеть статусы обработки и поставки на склад,

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

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

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

2. Личные кабинеты сотрудников компании с возможностями:

– планировать продажи дилерам с учетом актуальной информации о наличии товара на складе предприятия,

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

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

– контролировать работу собственных сотрудников, получать отчеты о выполнении ими плана,

– хранить и обрабатывать результаты маркетинговых акций

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

Вывод: структура тз

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

1. Информацию о компании и целевой аудитории, целях и задачах сайта;

2. Глоссарий терминов, непонятных заказчику;

3. Требования к верстке и работе сайта;

4. Описание применяемых технологий и список требований к хостингу;

5. Подробную структуру сайта;

6. Прототипы страниц и описания содержащихся на сайте элементов;

7. Сценарии использования интерфейса, если он нестандартный;

8. Список контента;

9. Требования к дизайну (в общих чертах).