Техническое задание на создание личного кабинета сайте

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

Техническое задание на создание личного кабинета сайте

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям.

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

Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

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

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

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

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

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

Хорошее ТЗ дает маленький diff, плохое ТЗ — большой. Однако, есть очень важный момент: тех. задание не должно и не может свести diff к нулю! Поясню почему. И diff и ТЗ имеют свою стоимость, причем стоимость нужно понимать более широко, чем просто деньги. Это деньги, время, потраченные нервы, испорченные отношения и т.д.

Стоимость diff — это стоимость изначально неоговоренных доработок, стоимость ТЗ — это, собственно, стоимость ТЗ. Чем более подробное и детализированное техническое задание, тем выше его стоимость, но тем меньше величина и стоимость diff-а, и наоборот. Если рассматривать две крайности, когда тех. задания просто нет, нет совсем, т.е.

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

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

Отсюда важный вывод: ТЗ должно хорошо описывать проект, но не более того.

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

2. Что в нем должно быть и чего нет. Формулировки

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

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

3.1 Общие слова

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

программист должен взять ТЗ, и у него не должно возникнуть ни одного вопроса, а первый вопрос, который он мог бы задать — это: «а про что сайт делать будем?» Раздел «Общие слова» в вольной форме и отвечает на этот вопрос.

3.2 Эксплуатационное. назначение

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

Остановимся на шаг раньше, непосредственно перед «подзаработать деньжат».

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

3.3 Функциональное назначение

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

Например, для интернет магазина это каталог товаров, корзина заказа, страницы с информацией о доставке, возврате и о компании.

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

3.4 Термины и определения

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

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

Например, заказчик говорит: «Сеанс работы с сайтом стоит 100 тугриков». Фраза «сеанс работы с сайтом» — претендент на описание. Этот термин может означать продолжительность времени от входа на сайт до выхода, или же период работы пока на счету пользователя не закончатся деньги. Т.е. нам нужно точно знать, что такое «Сеанс работы».

Ошибочное понимание такого простого термина может создать реальную проблему.

3.5 Данные и списки

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

Данные

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

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

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

Для примера, та же самая новость:

  • Заголовок
  • Текст
  • Дата публикации

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

Добавить его не проблема: нужно в таблицу добавить поле «анонс» типа «текст» и дополнительное поле ввода в создании/редактировании новости. Доработка несложная. А теперь, допустим, выясняется, что забыли добавить атрибут «Категория новости».

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

Списки

Как подсказывает Кэп, новость — это новость, а список новостей — это список новостей. Зачем это описывать? Допустим мы должны отобразить на главной странице «последние новости». Вот последние новости, это как раз такой список.

А что есть «последние новости»? Это уже можно понять по разному, это могут быть последние 5 новостей, а может это новости за последние 24 часа? Приведенный пример прост, его недорого исправить и при сдаче проекта. Но есть более тяжелые случаи. Например, заказчик хочет свой сайт с коллективными блогами, типа своего хабра.

И он хочет, что бы на странице, где отображается одна статья, сбоку был список «похожих статей». Что такое похожие статьи? Этот вопрос требует отдельного разбирательства и описания. И не обратив внимания на этот список мы рискуем уже достаточно серьёзно. Т.е.

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

Техническое задание (тз) на разработку сайта

Техническое задание на создание личного кабинета сайте

От автора: Как написать техническое задание (тз) на разработку сайта? Тема достаточно обширная, и в рамках одной заметки ее сложно разобрать на все 100% (если вообще это возможно). Но общие положения, о том что нужно учесть и на что следует обратить сое внимание при составлении тз веб-сайта, я постараюсь изложить достаточно подробно.

Итак, техническое задание на разработку сайта

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

Давайте проанализируем такой пример:

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

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

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

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

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

Это пример всего-то банального календаря.

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

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

Из каких пунктов обычно состоит техническое задание?

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

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

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

Поехали по пунктам.

Описание

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

Далее тут указываем:

для кого — целевую аудиторию:

потенциальные покупатели

продавцы продукции (магазины, интернет-магазины)

сервисные центры

партнеры (фирмы)

потребители продукции (тот, кто уже купил)

Для чего нужен сайт:

Для повышения имиджа компании

Для увеличения продаж

Для удобства клиентов

Тип:

Корпоративный

Сайт – визитка

Интернет магазин

Языковые версии:

Сайт должен решать какие-то задачи. Соответственно далее двигаемся по целям и задачам.

Цели и задачи

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

Потенциальные покупатели продукции

Цель: привлечь больше покупателей и убедить сделать первую покупку, помочь сделать выбор.

Необходимо решить задачи:

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

Дать информацию о салонах-магазинах

Дать информацию о розничной торговой сети

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

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

Теперь перечисляем модули.

Функционал сайта

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

Нужны ли новости

Нужен ли рекламный блок

Нужна ли регистрация

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

Нужна ли форма обратной связи

Нужен ли скрипт рассылки

И т.д. и т.п.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

После того, как все это описали, мы подбираемся к самому главному и интересному. Конечно, вся проделанная выше работа очень важна, но теперь становиться еще «жарче».

Описание функционала

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

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

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

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

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

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

Далее может идти вкладка «новости». Подпункты могут быть «события», «акции», «новое».

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

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

о компании

история компании

контакты

отзывы

новости

продукция

каталог продукции

релизы

отзывы о продукции

сервис

служба сервиса

гарантийное обслуживание

послегарантийное обслуживание

потребителю

покупка и доставка

пользование

о сервисе

магазинам и интернет магазинам

фотографии продукции

Часто задаваемые вопросы

сервисным центрам

Как стать сервисным центром

Часто задаваемые вопросы

партнерам

приглашение к сотрудничеству

Часто задаваемые вопросы

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

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

Главное теперь описать логику работы.

Логика работы

Я описывать буду исходя из рисунка выше.

Верхняя часть (header) остается неизменной на каждой странице. Новостная лента видна только на главной странице.

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

Здесь же, под подпунктами слева отображаем данные для связи с он-лайн консультантами (Skype, ICQ). Блок акции и релизы остаются на каждой странице. Подвал (футер) отображается один и тот же на каждой странице.

Примерно так описывается общая логика работы.

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

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

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

При нажатии на ссылку «архив за (такой-то месяц или год)» вниз выпадает список новостей за соответствующий месяц/год.

Примерно так описываем работу каждого блока. Не забываем про случай с календарем. И самое главное нужно расписать работу каталога товара. Здесь я даю вам задание: попробуйте продумать и описать, как будет работать каталог. Свои варианты присылайте на e-mail. Лучший мы опубликуем.

Что еще должно быть? Неплохо было бы указать совместимость.

Совместимость

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

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

Заключение

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

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

И не забывайте про задание!

Бернацкий Андрей

E-mail: contact@webformyself.com

“Киберсант-вебмастер” — самый полный курс по сайтостроению в рунете!

P.S. Хотите опубликовать интересный тематический материал и заработать? Если ответ «Да», то жмите сюда.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

Источник: https://webformyself.com/kak-napisat-tz-na-razrabotku-sajta/

Разработка личного кабинета

Техническое задание на создание личного кабинета сайте

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

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

Нас выбирают для b2b и нестандартных b2c проектов. Наши решения подойдут вам если:

  • у вас нет специфичных требований к стеку технологий
  • планируемое количество пользователей кабинета от 100 до 25 000
  • необходима сложная интеграция кабинета с другими системами (1С, CRM, СЭД и др.)
  • условия сотрудничества не предполагают работу над проектом в вашем офисе

Задать вопрос

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

Наиболее популярные задачи, которые мы успешно решали:

  • автоматизировать обслуживание клиентов, снизить нагрузку на отдел продаж/контактный центр (детализации начислений, заказов и услуг, текущий статус, наличие на складах, расчет стоимости доставки, конфигураторы заказа и др.)
  • упростить продажи (удобный каталог, быстрый умный поиск, подбор по параметрам, повторный заказ и др.)
  • повысить продажи (внедрение инструментов up, down и cross продаж, реферальные ссылки, таргетируемые баннеры, рассылки и др.)
  • организовать прием платежей онлайн
  • кэшбэк, детализация начисления и вывода
  • персональные скидки и бонусы, скидки от объема, скидки по акции, сезонные скидки и логика их суммирования
  • интегрировать онлайн и офлайн системы лояльности
  • документооборот с контрагентами
  • чат с сохранением истории переписки с менеджером
  • контроль удовлетворенности клиентов, опросы и обратная связь (жалобы, предложения и др.)
  • Аналитика Проведем интервью с представителями бизнеса, соберем и детализируем требования всех заинтересованных сторон. Декомпозируем задачи целевой аудитории личного кабинета. Достигнем ясности по целям и задачам проекта.
  • Проектирование Проработаем обмен данными между личным кабинетом и другими системами (CRM, 1C, эквайринг, кассы и др.).Создадим объектную модель. Разработаем и согласуем пользовательские сценарии и интерактивный прототип личного кабинета, который позволит увидеть как и из чего будет скомпонована каждая его страница. Напишем подробную спецификацию требований на разработку.
  • Дизайн Основываясь на согласованном прототипе нарисуем дизайн макет каждой страницы личного кабинета. При разработке дизайна личного кабинета будем опираться на стилистику сайта или фирменный стиль вашей компании. Будем править макеты до тех пор, пока вы не останетесь довольны.
  • Адаптивная верстка Использование общепризнанных стандартов и современных технологий позволяет нам создавать верстку макетов, которая корректно отображается и работает на любых устройствах, во всех популярных браузерах и операционных системах. Ваши клиенты будут довольны.
  • Программирование Разработаем функционал личного кабинета и встроим его в ваш сайт или разместим на отдельном домене. При необходимости интегрируем личный кабинет с внешними системами (1С, CRM, эквайринг, кассы и др.).
  • Контроль качества Для того, чтобы разработанный кабинет порадовал вас уровнем исполнения на всех этапах его разработки мы проводим внутренний контроль качества.Для крупных проектов вместе с функциональным тестированием мы проводим также нагрузочное тестирование и тестирование отказоустойчивости.
  • Документация Разработаем и передадим вам пакет подробной пользовательской и технической документации.
  • Сервис После запуска личного кабинета мы предоставляем 2 месяца бесплатной поддержки и консультаций. По истечении этого срока вы сможете продлить поддержку на персональных выгодных условиях.
  • Управление проектом Все работы по проекту координируются профессиональным менеджером проекта, который несет ответственность за его ключевые параметры: бюджет, качество и сроки, а также управляет рисками и изменениями в проекте. Поэтому вы можете быть спокойны за результат.

Интеграция с 1С любой сложности

В зависимости от задач и бюджета проекта реализуем файловый обмен, используем готовое XML API или создаем веб-сервисы. Если в вашей компании нет квалифицированного специалиста 1С, то предложим вам услуги проверенного партнера – группы КИТ. Работа с постоянным партнером позволяет нам решать интеграционные задачи любой сложности “под ключ”, быстрее и дешевле.

На сайт партнера

Сколько стоит создать личный кабинет

Для каждой компании мы создаем уникальное нетиражируемое на другие компании решение.

Стоимость разработки личного кабинета в нашей компании зависит от:

  • количества разделов (страниц) на проектирование, дизайн, верстку и программирование;
  • реализуемой функциональности;
  • количества систем для интеграции и наличия у них API;
  • степени участия специалистов заказчика и исходных данных.

Минимальный бюджет проекта – 300 000 рублей. Рассрочка до 12 месяцев.

Минимальный срок реализации проекта от аналитики до сдачи – 3 месяца.

Нужно быстрее или дешевле? Обратите ваше внимание на это решение.

  • у нас поэтапная оплата работ по проекту
  • вы получите 3 месяца поддержки после запуска без доплат
  • с 20.06.2019 вы также можете заказать личный кабинет с комплексной поддержкой на весь период рассрочки с платежом от 40 000 рублей в месяц

Посмотреть портфолио

Связаться с нами

Источник: https://web365.ru/razrabotka-kabineta/

Тз на создание сайта с человеческим лицом (не по госту)

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

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

Важный момент, мы говорим о сложных сайтах, а не сайтах, сделанных с помощью сборки на WordPress или других CMS (системах управления сайтом). Мы говорим о порталах, биржах, CRM, онлайн-сервисах и так далее.

Зачем нужно ТЗ на создание сайта?

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

Почему же некоторые считают, что крупный сайт можно сделать без технического задания? Просто по обрывкам фраз или “как Youdo.ru”.

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

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

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

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

Что является самым важным для ТЗ?

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

Раздел Термины и определения. Не нужно забивать его общими понятиями типа “сайт”, “хорошо”, “плохо”.

Здесь должны быть термины предметной области (например, “Обналичивание чеков”), с которыми предстоит познакомиться разработчикам, а также специфические термины, которых может не знать заказчик (например, “DNS-зона”).

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

Раздел Общие моменты по взаимодействию. Здесь мы проявляем различные ожидания по взаимодействию.

Например, что все, что не описано в ТЗ – это доп (дополнительные работы; доработка, не включенная в ТЗ), который оплачивается отдельно.

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

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

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

Раздел Требования к страницам. Здесь описываются конкретные требования к каждой странице. Главное слово “конкретные”. Очень опасно писать неконкретику в этом разделе – это порождает споры и недопонимание на этапе сдачи проекта. “Я думал, что это входит”, “а мы поняли это так-то…”.

В нашей практике был случай, когда лет 7 назад в ТЗ была прописана безобидная фраза “Интеграция с 1С”. Такого автора ТЗ можно смело увольнять – при такой постановке задачи заказчик вправе интегрировать все, что угодно из 1С. Нужно конкретно указать какие данные будут передавать из 1С (в одну сторону или в обе). Без этих деталей есть риск возникновения принципиальных разногласий.

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

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

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

В нашей рыбе ТЗ вы найдете эти элементы.

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

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

Раз прописано и согласовано – значит надо делать. Отсутствие вариативности в этом плане – это хорошо.

Раздел про Требования к заказчику. Да, заказчик тоже должен участвовать в проекте. И надо явно обозначить его роль. Чем точнее эта роль и чем лучше заказчик осознает свои обязанности в проекте, тем больше шансов на успех проекта. Наверно кто-то подумает “вообще обнаглели.

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

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

Тз на создание сайта и макеты (прототип)

И последнее, что непременно должно быть в современном ТЗ – это макеты.

Макеты – это схематичное отображение графического интерфейса портала.

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

Вот пожалуй и все, что нужно рассказать про ТЗ на создание сайта с человеческим лицом (не по ГОСТУ).

Так, а где рыба ТЗ? Рыба ТЗ на разработку сайта: https://web-automation.ru/wp-content/uploads/2017/11/ТЗ-Web-Automation.docx. Здесь учтены многие дополнительные нюансы, о которых мы не упомянули. Она составлена в таком плане, чтобы максимально прояснить ожидания по проекту.

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

Источник: https://web-automation.ru/tz-na-sozdanie-sajta/

Техническое задание на разработку портала «Что? Где? Почем?»

Техническое задание на создание личного кабинета сайте

При нажатии кнопки «Войти» блока “Войти в личный кабинет”, пользователю должна открываться данная страница. Если логин и пароль введены правильно, то при нажатии кнопки должна производиться авторизация клиента.

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

Под сообщением должна быть ссылка “Забыли пароль“.

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

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

  • Login
  • Имя
  • Фамилия
  • Телефон
  • E-mail
  • Пароль
  • Повторите пароль

Защита от автоматической регистрации

  • Введите цифры с картинки слева

Все поля для ввода текста обязательны к заполнению.
Под полями расположить кнопку “Зарегистрироваться“. При нажатии кнопки должен выполняться следующий алгоритм:Если все поля заполнены – производится запись введенной информации в базу данных сайта, пользователю на экран выводится сообщение типа: “Спасибо за регистрацию на сайте www.infocentr12.ru. На Ваш электронный адрес отправлено письмо для подтверждения регистрации (или что-то вроде того). Автоматически высылается соответствующее письмо на почту клиента.Если пользователь с таким e-mail или телефоном уже существует, то выводится соответствующее сообщение.Если не все поля заполнены, или неверно введено значение в поле “капча”, то пользователю выводится соответствующее сообщение. В данном сообщении должны быть перечислены незаполненные поля, данные поля становятся выделенными красным цветом, причем ранее введенные в форму данные не должны быть стерты.
После авторизации на сайте пользователь в блоке авторизации видит приветственное сообщение и ссылку на личный кабинет пользователя и личный кабинет организации. В данной версии сайта в личном кабинете пользователя реализованы следующие разделы:

  • Профиль пользователя (управление личными данными)
  • Управление рассылками (события, афиша)
  • Мои заявки в рубрику «Хочу!»
  • Социальные сети

Схема расположения блоков в ЛК пользователя приведена ниже на рис. 5.Центральная часть содержит информацию, в зависимости от выбранного раздела.Рис 5. Схема расположения блоков в личном кабинете пользователя. Страница содержит информацию, которую пользователь может редактировать.

Регистрационная информация:

  • Имя:
  • Фамилия:
  • Отчество:
  • E-Mail:*
  • Логин (мин. 6 символа):*
  • Новый пароль:
  • Подтверждение нового пароля

Личные данные:

  • Профессия:
  • Пол:
  • Дата рождения (DD.MM.YYYY):
  • Телефон

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

  • Акции и спецпредложения организации
  • афиша.

При подписке на афишу мероприятий форма имеет следующие поля:

  • E-mail
  • Развлекательное заведение (выпадающий список)
  • Тематика (для детей, для взрослых и т.д.)

Содержит все заявки из рубрики «Хочу!»Заявки представления в виде таблицы с полями:

  • Дата размещения
  • Текст заявки
  • Статус

По 20 на странице, далее предусмотрена постраничная навигация. Сортировка: по дате размещения и по алфавиту столбца «текст заявки».

  1. Сайт должен корректно отображаться на компьютерах под управлением ОС Microsoft Windows в следующих браузерах:
    1. Microsoft Internet Explorer, версия не ниже 7.0
    2. Mozilla Firefox, версия не ниже 2.0
    3. Opera, версия не ниже 9.2
  2. Допускаются незначительные различия во внешнем виде страниц сайта в различных браузерах, не ухудшающие возможностей пользователя по просмотру информации и навигации.
  3. Для корректной работы сайта необходимо, чтобы на стороне пользователя была разрешена работа скриптов (JavaScript). При запрете скриптов нормальная навигация по сайту не гарантируется.
  4. Для нормальной работы сайта необходим хостинг, поддерживающий PHP+MySQL, версиями не ниже 5.0, установленные Zend Optimizer и Web Accelerator.
  5. При щелчке на ссылки, ведущие на внешние страницы, последние должны открываться в новом окне.
  6. Под форматированным текстом в ТЗ понимается блок информации, содержащий:
  • графику, таблицы,
  • ссылки на внешние и внутренние страницы и файлы на данном сайте.
  • текст с возможностью делать выделенный фрагмент:
    • жирным, наклонным, подчеркнутым,
    • смещенным вправо, влево, по центру,
    • содержащим нумерованные и ненумерованные списки,
    • различного цвета (из предопределенной гаммы).
  1. Концепция дизайна сайта разрабатывается Исполнителем и утверждается Заказчиком.
  2. Стиль дизайна – деловой, строгий, информативный.
  3. Использовать Flash-анимацию не предполагается.
  4. В цветовом решении сайта должны доминировать цвета: белый, голубой, светло-серый.
  5. Дизайн переменной ширины, разрабатывается под базовое разрешение монитора 1024х768 pх. до 1280х768 pх.
  • В рамках настоящего технического задания, дизайнер проекта разрабатывает 2 принципиально разных варианта дизайна последовательно. После разработки первой концепции заказчик в письменном виде высказывает свои пожелания, на их основе разрабатывается 2-я концепция.
  • Заказчик рассматривает предложенные варианты и выбирает из них один, который будет взят за основу общего дизайна сайта.
  • Если Заказчика не устраивает ни один из предложенных вариантов, он формулирует свои замечания и пожелания письменно.
  • По выбранному варианту дизайнер делает еще один вариант дизайна с учетом требований Заказчика. Допускается внесение непринципиальных изменений.
    1. Страница раздела каталога
    2. Страница предприятия
    3. Страница раздела «Афиша»
    4. Страница мероприятия
    5. Страница Раздела «Горячие услуги»
    6. Страница детального описания «Горячей услуги»
    7. Страница «Размещение рекламы»
    8. Личный кабинет пользователя
    9. Личный кабинет организации
    10. Личный кабинет оператора Call-центра

Page 3

НазваниеТехническое задание на разработку портала «Что? Где? Почем?»
страница14/13
Дата конвертации14.12.2012
Размер0.52 Mb.
ТипТехническое задание

1   …   5   6   7   8   9   10   11   12   13 1   …   5   6   7   8   9   10   11   12   13

Техническое задание на разработку портала SaitName
Для удобства навигации, в документ внедрены заголовки, которые работают как ссылки и ведут к запрашиваемым страницам. Переход осуществляется…
Техническое задание на создание музыкального портала
Разобраться с базовой версткой. Создать тулбар на всех страницах (там где поиск и логин)
Техническое задание на разработку интернет-портала mastercost ru О системе «Интернет-портал mastercost ru»
Система «Интернет-портал mastercost ru» предназначена для создания в среде Интернет информационного пространства, позволяющего
Техническое задание на разработку нового веб-сайта “Galeria”
Подключается и настраивается приложение Flowplayer (платная лицензия на 1 сайт)
Техническое задание на разработку сайта. 03. 2009
Конечным результатом работ является создание новой версии веб-сайта компании, соответствующей всем условиям данного технического…
Техническое задание на выполнение работ по разработке портала ООО «Медотрейд». Общие сведения
Программа-клиент (Internet Explorer, FireFox, Opera, Safari, Chrome и т п.), предоставляющая пользователю возможности навигации по…
Техническое задание на разработку сайта студии «Интайтл» !(пример)
Перечень документов, на основе которых создается сайт Брифинг на создание сайта. Пример можно скачать с нашего сайта
Техническое задание на разработку web-сайта для компании Oriflame Цели проекта
Техническое задание на разработку сайта для гостиницы 3 Основные задачи Сайта: 3
Даже самые престижные, но весьма похожие по набору базовых сервисных услуг, «одинаковые» отели в разных городах уже не привлекают…
Техническое задание на разработку сервиса shopoo ru Структура информации Клиенты (список записей)
Аноним/Клиент (Если аноним, ничего не выводим, если клиент то выводим Имя и e-mail, имя — ссылка на страницу клиента в админке)

Разместите кнопку на своём сайте:
kak.znate.rukak.znate.ru
KakZnate

Источник: http://kak.znate.ru/docs/index-723.html?page=10

Секреты права
Добавить комментарий