Ваша заявка получена!
Наш менеджер вскоре свяжется с Вами!

Напишите письмо
команде Rubedite

Я бы хотел поговорить о...
Размер файла слишком большой
Главная Блог Как правильно заказать сайт или приложение под ключ? Часть 1: написание ТЗ

Как правильно заказать сайт или приложение под ключ? Часть 1: написание ТЗ

Что такое ТЗ?


Как его написать?


Почему это так (не) страшно?


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


Все статьи:

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

Что ж, приятного чтения!


Как написать ТЗ (а это, вообще, что?)

Если ты не упоротый ИТ-шник


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

Почему все (было) так сложно?

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


Следы этих классических подходов поисковые системы выдают до сих пор: структурные схемы, напоминающие спагетти карбонара на противне; UML-диаграммы, не влезающие на лист А1; какие-то "дорожки" на BPMN-картах процессов (мы что, в бассейне?).

Медвежонка Винни-Пуха из советского мультфильма длинные слова расстраивали. Если это про вас, то вы попали на правильную страницу. Из нашей статьи вы узнаете, что такое ТЗ (подсказка - это означает "Техническое Задание") и что в XXI веке ТЗ можно делать проще.


Жажда скорости


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


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


(источник: pinterest.ru)


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

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

Так что же такое ТЗ?

Аббревиатура ТЗ расшифровывается как "Техническое Задание" (не путать с "Тля Зеленая"). Такой суровый термин остался от советской промышленности - английская фраза Statement of Work (список или изложение работ) более точно раскрывает суть ТЗ.


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

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

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

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

В примере мы используем разработку сайта для интернет-магазина.

Больше дела - меньше слов
Или минимальная структура ТЗ.

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


В терминологии гибкой разработки такая версия называется "минимально жизнеспособный продукт" (по-английски, MVP).

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


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


Отметим, что перспективные идеи тоже можно записать в ТЗ, тогда разработчики будут знать, что им предстоит, и смогут лучше спроектировать системы. По agile это называется бэклог (backlog) - список отложенных работ.

Итак, мы рекомендуем несложную структуру ТЗ для интернет-магазина, состоящую из следующих разделов:


  1. Цели
  2. Персонажи пользователей
  3. Пользовательские истории
  4. Карта сайта
  5. Описания страниц
  6. Наброски дизайнов страниц
  7. Нефункциональные требования
  8. Риски
  9. Будущие версии


Цели
Или куда мы идем

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


Составляя раздел, ответьте на простые вопросы:


  • Какова цель этого проекта?
  • Какова основная концепция продукта?
  • Какие проблемы пользователей решит продукт?
  • Какой новый процесс предлагает продукт или каким образом продукт улучшает существующий процесс?


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

Персонажи пользователей
Или кто наши клиенты

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

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

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

Некоторые правила создания персонажей:


  • Всех пользователей поголовно считать не нужно, достаточно собрать группы по каким-то общим признакам. Для интернет-магазина это могут быть "Покупатель", "Продавец" и "Администратор". Больше 3 групп на простых проектах обычно не требуется - 80% пользователей в них впишутся.
  • В формировании исчерпывающего профиля на начальном этапе нет необходимости, у нас же не World of Warcraft. Дополнительные поля можно будет добавить по ходу разработки. Что нужно знать интернет-магазину о клиенте? Минимально: имя, телефон, e-mail, для доставки еще и адрес. ИНН и паспорт, скорее всего, будут лишними.
  • Дайте персонажам имена "Покупатель Вася", "Продавец Ашот", "Администратор Семен" - так они будут живыми, с ними легче будет работать, смотреть на продукт их глазами и управлять действиями. Правда, похоже на ролевую игру?
  • Для каждого персонажа надо сформулировать цель - что ему нужно от вашей программы. Для примера: цель "Покупателя" - приобрести товар, цели "Продавца" - разместить и продать товар, цель "Администратора" - управлять системой и другими профилями.