Что такое тз Вконтакте

Польза: получите знания о том, что такое ТЗ и как его составить. Обогатите словарный запас словами: концептуальная модель, data flow, mind card, user flow. use cases, wireframes, ER-model, client-server, API.

Для кого: начинающим разработчикам и желающим чтобы их поняли (заказчикам, стартапам и менеджерам).

Время чтения: 7 минут.

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

Хочу пирожное, потом морожное!
Вовка в тридевятом царстве

Существует распространенное заблуждение, что достаточно сказать: “Нужно приложение для музея/кошки/завода” и сразу станет понятно, что вам необходимо.

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

Спойлер
Через полгода вас ожидает нечто в поле и вообще с забором серобуромалинового цвета.

Короче говоря, я удалился из ВКонтакте

Жутко правда? Бюджет уже потрачен и срок истек.

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

Удобный вид требований — ТЗ

Замесить и нарубить!
Вовка в тридевятом царстве

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

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

Подводный камень №2: память человека не безгранична, всегда лучше иметь одно место, где все ваши пожелания и требования зафиксированы (не переписка в telegram или звонок по телефону). Поэтому ТЗ это печатный текстовый документ с приложением схем и инфографики, не написанный от руки или сфотографированный. Лучше всего в формате .PDF или Google Docs.

Рецепт грамотного ТЗ

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

• Концептуальная модель
• Функциональная карта
• Путь пользователя
• Пользовательский интерфейс
• Программные интерфейсы
• Нефункциональные требования

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

Такого НАГЛОГО КОТА как Басик еще нужно поискать, он сделал из Люськи ЛИЧНОГО МАССАЖИСТА!

Концептуальная модель

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

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

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

Стоит рассказать о типах пользователей и их ключевых отличиях.

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

И в завершении расскажите о компонентах вашего продукта.

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

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

Функциональная карта

Функциональная карта отображает общую концепцию проекта с уровнем детализации необходимым для того, чтобы оценить объем работ, расставить приоритеты.В традиционном формате такая карта напоминает карту сайта. Но удобнее всего ее отобразить в виде mind card (майнд карт, интеллект карт). Часто менеджеры рисуют на совещании на доске или листе бумаги слова и между ними связи, так вот, это и есть майнд карта. Это можно сделать удобно в бесплатных сервисах (coggle, draw.io и mindmeister) или просто в Office Word.

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

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

Путь пользователя

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

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

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

Например: на экране регистрации пользователь может:
перейти на экран авторизациизарегистрироваться через соцсети (Facebook, Twitter)может ввести почту, пароль, затем его повторить и подтвердить регистрацию в письме, пришедшем на почту.

Пользовательский интерфейс

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

• ukraine.craigslist.org
• www.theworldsworstwebsiteever.com (предупреждение, если вы страдаете приступами эпилепсии то не переходите по ссылке
• www.art.yale.edu

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

Дизайнеры скажут вам большое спасибо, если вы укажите стиль дизайна интерфейса, например flat design или material design.

Высшим пилотажем будет добавить wireframes (вайрфреймы) — прототипы интерфейса продукта в виде приближенных схем.

Программные интерфейсы

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

Сервер декомпозируется на модули: базы данных, аутентификации, чата и т.д.Клиент связывается с сервером через API (интерфейсы передачи данных), стоит указать его тип (REST, WEB, RPC и т.д.) и описать методы, ответы и обработку ошибок.

Данные обычно хранятся в базе данных в виде специальных структур, чаще всего таблиц (для реляционных БД) и json структур (для нереляционных). Разработчики скажут вам огромное спасибо, если в техническом задании вы укажите сущности базы данных (ER-модели) и опишите хранимые поля, с указанием их типов данных (string, int и т.д), ключей (primary, foreign), обязательности (required) и пустого значения (nullable).

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

Это общие требования к продукту. Их можно разделить на требования к техническому обеспечению, требования безопасности и требования к производительности.В требованиях к техническому обеспечению указывают пожелания к устройствам и операционной среде, например для приложения знакомств это Android 7.0+ и JDK 8+, iOS 11.0+ и Swift 4.2.

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

Советы

1. Создавайте текстовый документ в онлайн офисе или PDF, который легко будет прочесть. Это гораздо лучше переписки в чате или голосового сообщения, его всегда можно будет посмотреть с любого устройства.
2. Соблюдайте последовательность, переходите от общих требований к частным, приведенная выше структура не идеальна, но может служить хорошей основой.
3. Все требования должны быть в одном документе или вики-структуре, не храните их отдельно, они должны быть всегда доступны из одного источника.
4. Давайте четкие и разумные указания, избегайте неточностей, пишите максимально простым языком.
5. Описывайте ваши требования максимально подробно. Лучше один раз все продумать, чем постоянно уточнять различные детали и нюансы.
6. Приготовьтесь потратить больше нескольких дней или обратитесь к профессионалу для составления документа. Грамотное техническое задание спасет вас от долгих обсуждений деталей с разработчиками и обозначит четкие критерии сдачи проекта. Например, полноценное ТЗ по стандарту IEEE-830, приложенное к договору на разработку, является аргументов в суде в случае невыполнения требований.

• техническое задание
• тз
• srs
• prd
• техническое задание для разработки
• проектный менеджемент
• аналитика требований
• требования к разработке
• ТЗ для приложения

Источник: habr.com

Как правильно составить ТЗ для разработчиков чат-бота?

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

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

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

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

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

Что учесть при составлении ТЗ?

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

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

Наиболее распространенный функционал чат-бота:

1. Быстрый поиск по базе вопросов.
2. Проведение тестирований.
3. Отправка файлов.
4. Интеграция с CRM-системой.
5. Интеграция с онлайн-чатом.
6. Интеграция чат бота с e-staff для HR.
7. Решение офисных и бумажных вопросов.
8. Самообучение.

Можно также предусмотреть функцию Auto-Exit, т.е. появление бота при уходе пользователя со страницы. Отметим, что зачастую такая функция строится на событии «закрытия страницы», что блокируется современными браузерами. Поэтому важно выбирать исполнителя, который понимает особенности современных версий ПО и способен их использовать.

Обучение с ботами

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

Польза ТЗ для заказчика

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

Зачем ТЗ заказчику:

1. Понять, как будет выглядеть и работать чат-бот.
2. Понять структуру расходов на чат-бота.
3. Понять реальные сроки исполнения заказа.
4. Увидеть всю цепочку диалогов.
5. Определиться с нужными функциями и интеграциями.
6. Застраховаться от недобросовестности исполнителя.
7. Получить чек-лист для проверки готового задания.

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

Польза ТЗ для разработчика чат-бота

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

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

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

1. Главная
2. Общее
3. Как правильно составить ТЗ для разработчиков чат-бота?

Источник: 4study.pro

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

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

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

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

Они и заносятся в ТЗ.

Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей

Зачем нужно ТЗ

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

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

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

Каким должно быть ТЗ

На самом деле, соблюдение четких правил при составлении ТЗ не требуется. Разные компании и предприниматели оформляют задания по-разному. Вопрос в преследуемых целях.

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

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

А кто-то описывает все в деталях и структурирует каждый аспект:

Нужно написать текст на тему «Душевые кабины» объемом 3500 знаков. Уровень спама – до 55%, уровень воды не более 18%, уникальность – от 90%. Слово «душевые» использовать не более 15 раз. Избегать стоп-слов (и, или, но, а).

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

Технические характеристики

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

В случае с текстами сюда можно отнести:

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

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

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

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

Маркетинговые характеристики

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

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

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

Этапы работы

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

1. Этап разработки идей и дополнение существующего плана действий.
2. Демонстрация первого прототипа.
3. Приемка первой тестовой версии продукта.
4. Тестирование функциональности.
5. Разработки дизайна.
6. А/Б-тестирование визуальных компонентов и CTA-элементов.

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

Другие аспекты

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

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

Срок выполнения работы тоже приписывается заранее, как и общий бюджет проекта.

Примеры ТЗ

Рассмотрим два абстрактных примера технического задания в том виде, в котором они часто встречаются.

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

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

Сайт должен быть выполнен в соответствии с указанным макетом. Цветовая палитра, расположение объектов, шрифты, текст и прочие элементы из Figma должны быть перенесены на итоговый проект.

Текст ТЗ может содержать более конкретную информацию об имеющихся функциях:

• На сайте должна быть форма для загрузки файлов (только в форматах JPG, PNG).
• При скролле должно появляться сообщение с предложением зарегистрироваться.
• Если пользователь долго бездействует (более 20 секунд), должен появляться робот-помощник (его функциональность описана ниже).
• Под каждым материалом на сайте должна быть секциями с комментариями.

Также в ТЗ можно внести требования к дизайну и оформлению кода:

• Цвет подзаголовков берем из макета (#CD6326).
• Списки должны быть оформлены в формате ul > li > a.
• Блочные структуры должны быть реализованы с помощью свойства селекторов flex.

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

• Работа должна быть доступна в репозитории my-new-project.
• Каждое изменение должно сопровождаться отдельным коммитом.
• В качестве базы данных используется технология MongoDB.

Для копирайтеров

Текст на тему «Стоит ли использовать WordPress в 2020 году?».

Общие требования к тексту:

1. Статья должна быть поделена на части. Каждый подзаголовок отделяет один логический блок.
2. В тексте необходимо использовать одну таблицу и минимум один список.
3. Между списками, таблицами, цитатами и подзаголовками должно быть расстояние минимум в 400 знаков.
4. В тексте должны быть подзаголовки второго уровня, минимальный промежуток между подзаголовками – 750 символов, максимальный – 900 символов.
5. Ключевые фразы должны быть использованы столько раз, сколько указано в скобках рядом со словом.
6. Ключевые фразы должны быть равномерно распределены по тексту. Расстояние между ключевыми фразами не менее 1000 знаков. Первое ключевое слово должно использоваться в первом абзаце.

Объем текста: от 10 000 знаков.

Примерная структура текста:

1. Что такое WordPress.
2. Основные преимущества WordPress.
3. Сравнение WordPress с другими CMS.

Ключевые фразы:

• WordPress (8)
• Темы для ВордПресс (1)
• CMS WordPress (2)
• Для разработчиков (1)
• Для новичков (2)
• Как установить на сайт WordPress (1)
• Joomla (2)
• Drupal (1)

Вместо заключения

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

Источник: timeweb.com