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

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

С чего начать

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

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

Что в итоге

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

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

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

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

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

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

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

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

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

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

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

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

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

👉 Почитать про MoSCow

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

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

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

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

Функциональная спецификация. 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.

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

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

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

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

• Шпаргалка по разбивке пользовательских историй
• 10 советов по написанию хороших пользовательских историй, Роман Пихлер
• Руководство по созданию прототипов для перфекционистов, Эдрик Лапнирамай, Smashing Magazine
• Разработка функций с использованием Job Stories, Алан Клемент, Intercom

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

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