Ellada-flowers.ru

Заработок и деньги
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Как составить тз на сайт

Как составить ТЗ: подробная инструкция по созданию технического задания

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

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

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

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

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

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

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

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

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

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

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

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

Во многих вакансиях на позицию системного аналитика или технического писателя можно встретить требование: знание ГОСТ 19 и ГОСТ 34. Что это такое?

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

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

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

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

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

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

Более новый стандарт — ГОСТ 34, но и здесь присутствует нюанс. Новее он только на 10 лет. То есть, введён с 1 января 1990 года.

Формулировка назначения выглядит так: «Распространяется на автоматизированные системы (АС) для автоматизации различных видов деятельности (управление, проектирование, исследование и т. п.), включая их сочетания…».

Текст технического задания строится по структуре:

  • Общие сведения;
  • Назначение и цели создания (развития) системы;
  • Характеристика объектов автоматизации;
  • Требования к системе;
  • Состав и содержание работ по созданию системы;
  • Порядок контроля и приемки системы;
  • Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
  • Требования к документированию;
  • Источники разработки.

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

ISO/IEC/IEEE 29148

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

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

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

Читать еще:  Как видит яндекс сайт

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

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

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

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

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

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

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

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

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

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

Виджет обратного звонка для сайта

  • Повысьте конверсию сайта на 30%.
  • Экономьте на тарифах: от 5 рублей в минуту.
  • Настраивайте под ваш сайт. Адаптируйте под все устройства. Тестируйте разные виджеты.
  • Используйте гибкие настройки показа.
  • Стройте отчеты по звонкам: от показа виджета до ключевого слова.

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

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

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

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

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

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

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

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

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

Технический проект

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

В соответствии с практическими наработками, составляются новые задания и требования — частные технические задания по отдельным подсистемам (ЧТЗ).

Эксплуатация

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

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

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

Рекомендации по составлению ТЗ

Ведите историю правок

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

Составляйте список терминов и сокращений

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

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

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

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

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

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

Читать еще:  Как узнать количество просмотров сайта

Как составить грамотное техзадание на разработку сайта

Время чтения: 10 минут Нет времени читать? Нет времени?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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