Ликбез по техническому заданию

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

В закладки

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

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

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

Хочу пирожное! А потом морожное! .... А что это, вы и есть за меня будете?!

Вовка в тредевятом царстве
Product Owner

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

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

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

Сбор требований

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

Замесить и нарубить! ... Будет сделано!

Двое из ларца
Команда разраб

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

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

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

Рабочий процесс без ТЗ

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

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

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

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

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

Компоненты технического задания​

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

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

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

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

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

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

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

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

Например:

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

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

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

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

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

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

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

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

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

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

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

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

Например: на экране регистрации пользователь может:

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

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

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

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

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

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

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

​Wireframes

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

Этот раздел для специалистов. Если вы уверены в своих силах, то продолжайте чтение.

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

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

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

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

​ER mode

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

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

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

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

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

Советы

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

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

Написать
{ "author_name": "Артем Летюшев", "author_type": "self", "tags": [], "comments": 7, "likes": 5, "favorites": 26, "is_advertisement": false, "subsite_label": "hr", "id": 109136, "is_wide": false, "is_ugc": true, "date": "Wed, 26 Feb 2020 12:51:14 +0300", "is_special": false }
0
7 комментариев
Популярные
По порядку
Написать комментарий...
0

Круто, но это все тезисы. А тут нужен механические правила как в случае со скрамом например. Что на входе что на выходе.

Ответить
2

Чтобы тратить на ТЗ адекватное время - нужны готовые шаблоны. А ими никто (в здравом уме) не будет делиться. 

Ответить
0

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

Ответить
0

Сколько по вашему адекватное время?

Ответить
0

Экономия два-три раза. Это вообще конкретно дофига, если на ТЗ дали неделю. А в реальности его пилить две-три недели с нуля.

Ответить
0

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

Ответить
1

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

Ответить

Прямой эфир