Как составить техническое задание на разработку приложения

При знакомстве со студией клиент рассказывает, какое приложение он хочет получить. Все его характеристики от внешнего вида до функций фиксируются в техническом задании (ТЗ). Этот документ — руководство к действию,
на него студия опирается во время разработки приложения, чтобы создать для клиента продукт, который соответствует его ожиданиям. Но как его написать?

ТЗ по ГОСТу: поможет ли оно сделать классное приложение

У ТЗ на разработку мобильного приложения или веб-сервиса есть стандарты качества: отечественные ГОСТы и зарубежные SRS (software requirements specification). У SRS более разветвлённая структура: его содержание похоже на реферат с введением, главами, подглавами и заключением. Но и в том и в том стандарте есть общие смысловые
части:

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

SRS популярен на западе — на российском рынке он пока не прижился. ТЗ по ГОСТу необходимо только госсектору и тем компаниям, которые с ним тесно связаны. У крупных корпораций, которые заказывают
приложение, могут быть свои стандарты качества — тогда студия оформляет документы по их образцу.

Поскольку в законодательстве нет жёстких требований к проектной документации, студии мобильной разработки «настраивают» ТЗ под себя. Некоторые продолжают писать по ГОСТу — такой документ удобнее проверять: вы открываете
стандарт, открываете техзадание и сверяете разделы. Ну, а больше плюсов мы не нашли. Из минусов:

1. Гостовский документ кажется нам слишком громоздким. В нём сложно ориентироваться. Если вы приходите за конкретной информацией и не знаете, где её искать, вам придётся изучить весь документ. На листание
   страниц уходит время, которое можно было потратить на завершение других задач.
2. ТЗ по ГОСТу не подходит для сотрудничества по Agile. Стандарт, написанный в конце
   80-х, не знает, что проектная разработка может идти спринтами. Приложение разрабатывается поэтапно.
   У каждого спринта — своя документация, поэтому монументальное ТЗ будет не к месту.

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

Кто пишет техническое задание на мобильную разработку

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

Люди, которые привыкли к формату официальных документов, могут спокойно работать с ТЗ по ГОСТу. Но чаще техзадание сокращают до ёмких инструкций и схем.

Проблема любых больших документов, особенно аналитических, в том, что их сложно читать как клиентам, так и самим разработчикам, поэтому мы не пропагандируем ТЗ по определённым форматам, будь то ГОСТ или зарубежные
стандарты. Я за то, чтобы делать ТЗ под конкретный проект. Более того, я сторонник подхода «меньше текста без ущерба смыслу — лучше». Если можно обойтись без документа и заменить его на изображения или схемы,
тем самым сократив объём, то лучше сделать именно так.

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

Как понять, что вы попали к плохому аналитику

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

• Вы не понимаете, что написано в ТЗ. Несмотря на техническую направленность, текст должен быть читаемым. Аналитики жертвуют терминами и красивостью в пользу ясности. Иногда мы пишем одно и то же слово несколько
  раз подряд: «Пользователь может нажать на кнопку. После нажатия на кнопку, кнопка…» — смотрится не очень, но эта тавтология делает текст однозначным.

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

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

Сколько стоит техническое задание

В масштабах общей стоимости приложения цена, которую клиент платит за ТЗ, небольшая. Час работы техписателя оценивается в 1500–2000 рублей. На простое
приложение без бэкенда уходит 60 часов, а на сложный eCommerce можно потратить больше двухсот. Но экономить на ТЗ нельзя. В мобильной разработке оно выполняет ту же роль, что и чертёж в строительстве дома: одна неправильная линия и всё может рухнуть. Поэтому вкладываться нужно с самого начала. Компании IBM выяснила:
если вы найдёте ошибку на ранних этапах разработки, исправить её будет дешевле.

Зависимость стоимости ошибок от этапов, на которых они выявлены

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

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

— Иван Леонтьев,
Android-разработчик «Лайв Тайпинга»

Можно ли скачать готовый шаблон ТЗ 

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

Техническое задание без ошибок, воды, повторов — наш подход к проектной документации

Главная задача ТЗ — описать, что должно быть сделано: понятно, наглядно и ёмко, а формат не имеет значения. В «Лайв Тайпинге» документы создаются не ради документов, а для того, чтобы привести проект клиента к успеху.
Мы отказались от многостраничного ТЗ в пользу артефактов — лаконичных документов, которые решают точечные задачи. Набор артефактов, из которых сложится техническое задание, зависит от размера и целей вашего
проекта. Мы определим его вместе на этапе знакомства и оценки.

Из чего может состоять проектная документация в «Лайв Тайпинге»:

1. Функциональное задание

Функциональное задание (ФЗ) — самый мощный артефакт в нашей проектной документации. К нему обращаются на каждом этапе разработки
от прототипирования до релиза. На его основе дизайнеры создают экраны, разработчики пишут код, а отдел QA проводит тестирование. И при этом у него нет ни одного магического свойства. Сила ФЗ в том,
что оно подробно описывает функции, которые доступны пользователю при работе с приложением. На интервью с клиентом мы узнаём, какие ролевые модели (администратор, модератор, простой пользователь) предусмотрены в приложении,
и описываем набор функций для каждой роли: куда пользователь может пойти, что сделать и какой результат его ждёт. Пока мы с клиентом готовим этот артефакт, дизайнеры делают прототипы экранов, которые соответствуют возможностям
приложения, прописанным в ФЗ. Готовый документ проверяют разработчики.

На этапе проектирования я читаю готовое ФЗ минимум два раза. Первый — целиком, ни на чём не останавливаясь, чтобы у меня сложилось общее впечатление о работе приложения. Затем я начинаю читать ФЗ на второй раз, более вдумчиво и критически. Это позволяет мне: 1) задать вопросы, которые
меня интересуют, чтобы проверить документ на ошибки; 2) дополнить конкретные моменты в приложении исходя из своего опыта; 3) дать более точную оценку проекту.

— Павел Разуваев, iOS-разработчик «Лайв Тайпинга»

Содержание функционального задания

Изображения

2. Функциональные схемы

Функциональные схемы (ФС) иллюстрируют, как простые функции приложения группируются в более сложные и взаимодействуют друг с другом. Те, у кого много очков опыта в айти, легко воспользуются этим артефактом. Но если вы ещё
не подняли скилл до нужно уровня, прочитать функциональные схемы вам поможет описание компонентов системы.

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

3. Описание компонентов системы

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

4. Технические заметки

Артефакт описывает, как разработчики реализуют функции из ФЗ. Мы не хотим тратить деньги клиента на очевидные вещи, поэтому делаем технические заметки только на те места, которые кажутся нам рискованными и требующими
внимания: любые алгоритмы, расчёты, интеграции.

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

— Андрей Дёмин,
Android-разработчик «Лайв Тайпинга»

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

5. Спецификация API (application programming interface)

API — язык, на котором приложение «общается» с серверной частью. Когда пользователь совершает действие, внутри приложения формируется запрос, который улетает в сервер, обрабатывается и возвращается в виде ответа. Спецификация
устанавливает нормы этой коммуникации. Артефакт не используется в приложения без бэкенда.

6. Карта рисков

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

7. Документация на фичу

Этот артефакт — референс к гостовскому ТЗ: он собирает технические и функциональные характеристики на одну фичу в одном месте. Нужен, когда к нам на поддержку приходит готовый проект и мы добавляем
в него новые функции или исправляем баги.

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

Как «Лайв Тайпинг» сокращает затраты клиента на документацию

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

• Gym Record — лёгкий и удобный дневник для записи тренировок. Клиенту не нужна была сложная
  авторизация, поэтому мы сделали приложение без серверной части. Таким проектам не требуются документы, которые описывают работу с сервером — API, схемы и пояснения к ним. Основной упор в приложении сделан
  на дизайне, который отталкивается от функциональности. Поэтому для нашего клиента мы сделали только функциональное задание, в котором прописали особенности UX и UI.
  На создание документа мы потратили 20 часов — суммарно 2–2,5 рабочих дня.

• Justfood — сервис по доставке готовых блюд для тех, кто следит за фигурой. Проект пришёл к нам на поддержку со своей документацией. Она помогла нашим разработчикам понять принцип работы приложения.
  Но чтобы вносить изменения, нам потребовалось сделать документацию на фичи, которые мы добавляли. В артефакте мы прописали шесть новых фичей и к каждой указали функциональные, технические требования
  и ограничения. Например, «Автопродление подписки» выглядит так: 1) пользователь применят продление и получает скиду — это функциональное требование; 2) при применении промокода скидки не суммируются — это ограничение;
  3) карта клиента сохраняется в приложении с помощью дополнительных параметров метода оплаты — это техническое требование. Разобраться в документах клиента и создать новый артефакт — 24 часа, или 3 дня.

• D-Style — приложение для одноимённого московского магазина одежды. Набор документации для eCommerce однотипен: функциональное задание, технические заметки, спецификация API, функциональные схемы и их описания.
  Исключение — крупные ретейлеры, которые сами готовят документацию. Для
  D-Style мы не делаем описание компонентов системы: на стороне клиента нет людей, которым пригодится эта информация. Поэтому мы не видим смысла тратить деньги и время клиента на артефакт, который не приносит
  пользы. Сейчас для
  D-Style мы пишем технические заметки — как только закончим, здесь появится время, которое мы потратили на документацию для этого проекта.

Вы уже придумали концепцию для мобильного приложения? Можете составить для него полезную проектную документацию по нашему методу. А если вам потребуется помощь — свяжитесь с нами или позвоните
+7 495 204-35-03. Мы вместе разберёмся в деталях, определим какие артефакты нужны вашему проекту и превратим его в героя Меча и Магии.

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

Польза: получите знания о том, что такое ТЗ и как его составить. Обогатите словарный запас словами: концептуальная модель, 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) служат:

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

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

Ниже я разберу подробно каждый из пунктов. Для тех, кому не хочется подробно разобраться, оставляю ссылку на международный стандарт 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, приложенное к договору на разработку, является аргументов в суде в случае невыполнения требований.

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

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

Или вы хотите создать какой-то уникальный сервис для пользователей.

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

Составление вакансии и ТЗ для программиста

Чтобы оставить объявление о поиске программиста-фрилансера, нужно сузить круг поиска. Для этого пишется объявление такого вида:

Требуется программист, чтобы добавить функцию X на готовый сайт на WordPress.

1. Сроки, обговоренные с исполнителем, и ситуации, когда дедлайн можно подвинуть.
2. Способ и вариант оплаты. Например, на банковскую карту после принятия заказа.
3. Штрафы и правки.
4. Подробное описание того, как вы видите результат работы.
5. Техническая информация.
6. Тестирование

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

Желаемый результат

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

Допустим, вам нужен сервис проверки орфографии. Опишите все ваши представления:

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

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

Техническая информация

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

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

Идентификация сетевых ресурсов является важным подготовительным этапом перед осуществлением взлома. Если хакер знает, что ваш корпоративный портал работает под управлением IIS 7 под управлением Windows Server 2008, то ему необходимо найти уязвимости, которым подвержены данные программные продукты. Для этого проще всего поискать в базах уязвимостей. В случае если найти ничего не удалось, то особо продвинутый взломщик может попытаться самостоятельно найти «лазейку», собрав у себя точную копию взламываемой системы и попытавшись самостоятельно проанализировать код. «Информационная безопасность: защита и нападение», Бирюков А. А.

Стандарты оформления кода

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

Я спросил Ольгу Безматерных, HR-директора TexTerra, что она думает по поводу работы с чужим кодом. Она ответила, что он замедляет выполнение задач, а один раз в ее практике был случай, когда работать с кодом было невозможно – пришлось вернуть деньги.

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

Допустим, нужен код, который будет проверять, равна ли переменная $a единице, и выводить об этом сообщение. Кроме того, что этот код можно по-разному оформить, его можно по-разному реализовать.

Переменные можно называть по-разному: $aB, $ab, $a_b, $A и так далее. Если это незначительно, добавлять комментарии критически важно. Без них в коде тяжело ориентироваться, даже если его писали вы, но отложили на неделю.

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

Подключение и тестирование

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

Заключение

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

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

Дмитрий Соколов, сооснователь IT-студии Alef Development, рассказывает, зачем тратить время на составление техзадания и как распознать качественное ТЗ. Примеры в статье будут связаны с разработкой мобильного приложения, но советы применимы к техническому заданию на любой программный продукт, будь то сайт или уникальная CRM, сделанная под ваши нужды.

Зачем тратить время на ТЗ

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

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

1. вы даете исполнителю краткий перечень функций, экранов и других особенностей приложения;
2. он делает предварительный расчет и называет примерные сроки и стоимость работ, опираясь на эту информацию;
3. когда есть понимание вилки цены и сроков, происходит переход к этапу написания ТЗ;
4. если вы будете добавлять в приложение функции, которых не было на этапе предварительной оценки, то срок и стоимость вырастут. Добросовестный исполнитель сообщит вам об этом на этапе составления ТЗ, и окончательный расчет не станет сюрпризом;
5. как только техническое задание будет написано и утверждено, вы, наконец, получите точную стоимость и сроки разработки приложения.

Почему разработка ТЗ стоит денег

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

Фото: Unsplash

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

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

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

Если же подрядчик сообщает вам, что разработка ТЗ бесплатна, не воспринимайте это буквально — стоимость ТЗ «размазана» по общей стоимости проекта. В таком случае будет достаточно сложно сменить исполнителя.

Кто должен составлять ТЗ — заказчик или исполнитель

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

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

Как согласовать ТЗ быстро и качественно

Один из самых распространенных подходов к утверждению и обсуждению ТЗ — пересылка друг другу документа с правками или совместная работа над документом в Google Docs.

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

Мы под эту задачу написали программу Voodoo.

Скриншот программы

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

Скриншот программы

Когда обсуждение завершено, заказчик нажимает кнопку «Утвердить» и переходит к следующему экрану приложения. Voodoo показывает, сколько экранов осталось согласовать, это психологически помогает справиться с задачей большого объема.

Как распознать качественное ТЗ

• С первых страниц понятно, какую функцию выполняет приложение

Попросите постороннего человека прочитать ТЗ и описать приложение в общих чертах. У него это должно легко получиться.

• Перечислены поддерживаемые устройства и операционные системы

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

• Детально описаны все экраны и кнопки

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

• К каждому экрану нарисована схема

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

• Не используются отсылки к сторонним продуктам при описании функций

Слова «как в инстаграме» или «как в фэйсбуке» абсолютно не подходят для ТЗ. Любой продукт может измениться во время разработки вашего приложения, и отсылка будет вести в никуда. К тому же она может быть по-разному трактована вами и исполнителем.

• Прописано поведение приложения для нестандартных ситуаций

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

На что стоит обратить внимание в ТЗ

• Контрольная панель. Она нужна, чтобы управлять пользователями и контентом в приложении. Если не предусмотреть в ней все необходимые действия, то вам придется постоянно обращаться к разработчику за помощью.
• Система оплаты. Если вы используете систему оплаты, зафиксируйте в ТЗ, какой провайдер платежей используется, как происходит процесс оплаты, что произойдет в случае неуспешного платежа. Убедитесь, что провайдер работает в вашей стране и предоставляет необходимые тарифы.
• Загрузка фото. Стандартные системные функции подразумевают выбор фотографии или ее получение с камеры. Если вам нужно ручное кадрирование аватарки пользователя, фильтры или другие способы обработки — скажите об этом отдельно.
• Шеринг материалов. Если в приложении можно делиться товаром или статьей, убедитесь, что в ТЗ описана веб-страница, на которую будет вести ссылка шеринга.
• Геолокация. Если для работы приложения нужна геолокация, укажите в ТЗ, что произойдет, когда пользователь не даст разрешение на использование геоданных.
• Различные формы доступа. Убедитесь, что по ТЗ неавторизованный пользователь не может ошибочно попасть на экран для авторизованного.
• Жизненный цикл. Если в приложении предусмотрены разные статусы объектов, проверьте описание переходов между ними. Например, заказы в интернет-магазине отмечаются как «получен», «обрабатывается», «на доставке», «отменен», «доставлен». При ошибке в переходе между этими статусами возникнет проблема со своевременной доставкой, а следом — недовольные клиенты и потеря денег.
• Аналитика. Если вы хотите знать, сколько времени пользователи проводят в приложении, на какие экраны они попадают чаще и какие кнопки нажимают, это стоит отдельно прописать в техническом задании. По умолчанию такие данные нигде не учитываются.

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

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

Что такое ТЗ на разработку мобильного приложения

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

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

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

Вопросы, с которых начинается ТЗ на разработку приложения (пример)

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

Готовые ответы на следующие вопросы упростят и ускорят составление технического задания.

Каким заказчик видит свое приложение? 

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

Какова специфика программы? 

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

Будет ли выгода от запуска сервиса? 

Прежде чем обращаться к специалистам за ТЗ на разработку приложения, следует четко понимать, как вы собираетесь монетизировать инструмент. Бизнесу важно определить преимущества перед конкурентами и объем охвата пользователей, чтобы проанализировать рентабельность.

Каким бюджетом располагает заказчик? 

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

Какую платформу выбрать?

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

Кто будет отвечать за внедрение, релиз и отладку?

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

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

Как написать ТЗ для мобильного приложения

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

• Конкретика во всём: у шрифтов есть названия, у цвета — коды, у форм и элементов — размеры.
• Четкое разделение полномочий: участие и ответственность исполнителя и заказчика строго регламентированы.
• Нет субъективных оценок, только факты: «красиво» и «полезно» — субъективно. Оперируя в техзадании подобными терминами, стороны рискуют качеством процессов.

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

Кто пишет ТЗ?

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

Заказчик

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

Когда заказчик может составить этот документ самостоятельно:

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

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

Эксперты

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

• Маркетологи находят целевую аудиторию (ЦА), определяют ее мотивы и вносят в ТЗ рекомендации, подсказывающие остальным специалистам, каким должен быть продукт, чтобы отвечать ожиданиям потребителей и быть востребованным.
• Разработчики отвечают за технические компоненты: код, оптимизацию внутренней и серверной частей программы. Они лучше других понимают особенности, которые помогут приложению работать стабильно и быстро.
• Дизайнеры вносят предложения по визуальному представлению ПО. Здесь важно учитывать не только модные тренды в оформлении, но и удобство пользовательского интерфейса.
• Технический писатель обрабатывает информацию, собранную другими специалистами, грамотно компилирует ее и переводит на общедоступный язык, понятный всем участникам проекта.

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

Структура ТЗ для приложения

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

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

Требования к разработке ТЗ мобильного приложения

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

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

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

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

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

Вывод

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

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

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

От ТЗ на разработку зависит управление проектом: либо он контролируется, либо процесс протекает стихийно.