Как написать ТЗ для приложения: гайд для тех, кто не сильно разбирается в разработке

Всем привет, я Эд Хорьков из «КОД9». Представьте ситуацию: вы хотите сделать приложение, находите разработчиков и устно описываете им идею. Они показывают первый результат, и вы понимаете: это не совсем то, что вы хотели. Чтобы избежать такого, важно готовить техзадание.

Как написать ТЗ для приложения: гайд для тех, кто не сильно разбирается в разработке

Это перевод статьи из Smashing Magazine

Это англоязычное медиа для дизайнеров и разработчиков — судя по Similarweb, туда до сих пор заглядывает больше миллиона людей в месяц. Оригинальный текст я написал в 2017 году, и прошёл тогда 7 кругов с редактором. Материал всё ещё актуален: мы обновили дизайн схем, но почти не трогали смысл.

Читать на английском →

Почему важно готовить ТЗ и с чего лучше начать

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

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

Вот что я советую сделать перед тем, как начать готовить ТЗ:

Этапы для подготовки
Этапы для подготовки

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

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

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

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

Посмотрите на другие приложения и ссылайтесь на них при описании своего. Например, если вам нравится, как работает функция восстановления пароля в приложениях A и B, так и пишите в ТЗ.

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

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

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

Расставьте приоритеты. Укажите, какие функции важнее, чтобы разработчик знал, на чём надо сосредоточиться в первую очередь.

Советую метод MoSCoW — суть в том, чтобы назначить каждой функции уровень приоритетности. Нужно выбрать из таких: Must (Необходимо), Should (Важно), Could (Желательно) и Won’t (Не важно).

<p>Этот фреймворк поможет расставить приоритеты</p>

Этот фреймворк поможет расставить приоритеты

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

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

Какие бывают форматы ТЗ

Когда вы подготовили все вводные, нужно выбрать подходящий формат для ТЗ — вот основные:

Кратко о плюсах и минусах распространённых подходов к ТЗ
Кратко о плюсах и минусах распространённых подходов к ТЗ

Теперь пройдусь по всем подробнее и покажу примеры:

Функциональная спецификация. Functional Specification (FSD) в индустрии разработки ПО можно считать форматом по умолчанию. Она состоит из стандартного списка элементов, которые описывают, что и как должен делать продукт.

Возьмём, например, простое приложение-калькулятор и опишем его функции в формате FSD:

  • На экране приложения отображается цифровая клавиатура с добавлением кнопок основных арифметических действий (сложение, вычитание, умножение, деление) и кнопки результата (отмечена символом «=»).
  • При касании кнопки с цифрой выбранная цифра попадает в поле на экране. Каждая новая цифра добавляется к числу справа.
  • При касании кнопки арифметического действия текущее число в поле добавляется в память. При этом поле очищается, чтобы можно было ввести следующее число.
  • При касании кнопки результата число из памяти взаимодействует с числом на экране в соответствии с запрошенной ранее операцией. Полученное число появляется в поле на экране.

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

❗ Важно

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

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

Вернёмся к нашему примеру с калькулятором и добавим пару других функций в формате пользовательских историй:

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

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

  • Как пользователь, я хочу иметь возможность нажать на кнопку «Настройки доступа» в правом верхнем углу экрана, чтобы посмотреть, кто и в каком виде получит доступ к расчётам.
  • В «Настройках доступа» я хочу уточнить период расчётов, которым собираюсь поделиться, используя инструмент выбора даты в iOS.

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

Эскизы и вайрфреймы. Ещё один способ изложить требования к приложению — визуализировать их в виде эскизов или вайрфреймов. В мобильной разработке около 70% времени тратится на реализацию интерфейса, поэтому, когда у команды все экраны перед глазами, ей легче представить, что необходимо сделать и каков объём работы.

Пример вайрфрейма для калькулятора
Пример вайрфрейма для калькулятора

Создание вайрфреймов для мобильного приложения требует знания основ UX: как экраны связываются друг с другом, какие состояния бывают у каждого экрана, как будет вести себя приложение при открытии из push-уведомления.

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

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

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

Как составить ТЗ — разбираю на примере

В качестве примера возьмём реальное приложение для подсчёта калорий, которое мы разработали — оно называется What I Eat. Я опишу процесс создания ТЗ так, будто мы разрабатываем приложение с нуля.

Сначала давайте придадим идее форму по шаблону XYZ Стива Бланка: «Мы помогаем X делать Y, делая Z».

Цель приложения — дать пользователям возможность контролировать, что они едят в течение дня и сколько потребляют калорий. По методу XYZ цель будет звучать так: «What I Eat помогает тем, кто заботится о своём весе, отслеживать потребление калорий, давая им возможность вести простой дневник питания».

Следующий шаг — пользовательские истории. Теперь опишем What I Eat в виде историй, экран за экраном. Начнём со стартового и домашнего:

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

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

Вайрфрейм главного экрана
Вайрфрейм главного экрана

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

Повторим цикл для других функций. Давайте опишем пользовательские истории для добавления приёма пищи:

  • Я хочу ввести название блюда, которое только что съел.
  • Вместе с названием блюда я хочу ввести количество калорий.

Теперь попробуем собрать вайрфрейм:

Вайрфрейм экрана добавления приёма пищи
Вайрфрейм экрана добавления приёма пищи

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

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

Теперь соберём вайрфрейм для календаря — туда можно поместить интерфейс календаря iPhone, чтобы не придумывать велосипед:

Вайрфрейм календаря
Вайрфрейм календаря

Наконец, нужно добавить в приложение настройки.

  • Я хочу иметь возможность включать и отключать резервное копирование записей о приёме пищи в iCloud.
  • Я хочу иметь возможность включать и отключать ежедневные push-уведомления, которые напоминают мне о необходимости отслеживать, что я ем.
Вайрфрейм экрана настроек
Вайрфрейм экрана настроек

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

Вайрфрейм с пользовательской историей на одной странице
Вайрфрейм с пользовательской историей на одной странице

Кроме того, можно нарисовать карту с визуализацией того, как экраны соединяются друг с другом. Для этого мы используем Miro.

Карта экрана приложения для отслеживания калорий на iPhone
Карта экрана приложения для отслеживания калорий на iPhone

При создании карты экранов я заметил, что на главном экране нет кнопки перехода к настройкам, и добавил её.

Что в итоге

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

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

Что ещё почитать на тему

Для более глубокого погружения в тему советую следующие источники:

Расскажите о своём подходе к составлению ТЗ — нам было бы интересно почитать.

Если интересно узнать больше о мобильной разработке, буду рад видеть вас у себя в телеграме ↓

5858
11 комментариев

Картинка о ТЗ, которая будет актуальна всегда.

4
Ответить

Очень правдивая картинка

Ответить

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

2
Ответить

Хорошо, что нельзя закэнсэлить фреймворк из-за его названия

1
Ответить

Можно заапрувить и пошерить со стейкхолдерами

1
Ответить

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

1
Ответить

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

Ответить