Техническое задание на создание программы

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

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

Почему ТЗ — это важно

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

Техническое задание. Что такое и зачем нужно?

В статье я расскажу:

• почему оформлению ТЗ нужно уделить особое внимание,
• какие разделы включить в ТЗ и что в них должно быть;

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

ТЗ — это ваша гарантия

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

Первый сценарий — это работа с недобросовестным подрядчиком, когда он делает “тяп-ляп”.

Часто недобросовестные вендоры просят за разработку системы гораздо меньше всех остальных по рынку. Когда ищите разработчика, лучше забыть правило “дороже — не значит лучше”. Как раз-таки дороже — значит лучше, но и тут есть свои огрехи.

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

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

ТЗ — это фундамент вашего приложения

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

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

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

Разработка технического задания для мобильного приложения iOS или Android (Technical Requiriments)

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

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

В процессе разработки ТЗ часто дополняется. В какой-то момент разработчики понимают, что согласованный способ хранения данных ненадежен, невозможен или неудобен — в общем, можно сделать лучше. Однако, в ТЗ уже прописаны требования к хранению данных. Составляя ТЗ вы не учли некоторые детали, и теперь, чтобы продолжить разработку, нужно согласовывать дополнительные документы с уточнениями к ТЗ. Всё это растягивает время разработки, а значит и стоимость (если вы работаете по модели Time Material (почасовая ставка), помните пословицу “Время — деньги”, а вместе с ней запомните — “Рассеянный делает одну работу дважды”.

ТЗ позволяет сокращать расходы

Представьте, что на разработку приложения выделено 5 миллионов. Вы присылаете ТЗ некоторому количество разработчиков и получаете оценку в 7-8 миллионов.

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

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

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

Обязательно ли делать ТЗ своими силами

Как сказал Майкл Францезе: “Делайте то, что у вас лучше всего получается, а остальное перепоручите соответствующим специалистам.”

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

Практически любая аутсорсинговая компания разработчик может разработать за вас ТЗ. Конечно, в 9 из 10 случаев за это придется заплатить. Зато вы получите отличное, полное техническое задание! Более того, вы можете не обращаться к тому же подрядчику за разработкой, а начать исследования рынка и найти того вендора, который вам понравится.
В дальнейшем, если возникнут новые задачи на разработку, вы сделаете новое ТЗ по шаблону старого. Это очень удобно, не правда ли?

Как должно выглядеть ТЗ

Обратите внимание, что мы описываем структуру ТЗ по нашему шаблону. Наше ТЗ — гибрид из стандарта по ГОСТу и собственных предпочтений. Можно сказать, что этот шаблон — тот документ, который мы видим у “идеального” заказчика. По нашему мнению, такая структура ТЗ максимально удобна для описания системы, и поверьте, технических заданий за 10 лет работы мы видели не малое количество…

Документ состоит из основных разделов:

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

Раздел Общие сведения

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

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

Не забудьте добавить требования, которые не относятся к реализации проекта. Требования касаются регулирования работы двух сторон, например:

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

Резюмируем. Добавьте:

1. Реквизиты исполнителя и заказчика.
2. Сроки начала и окончания проекта (вплоть до разбивки по этапам).
3. Опишите требования, которые не касаются разработки приложения.

Цели и назначение проекта.

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

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

После прочтения цели мы понимаем, зачем вам нужна кастомная разработка (в данном случае нужно автоматизировать бизнес-процессы), и, если вы укажите “прототип” того, что нравится — это упростит дальнейшую разработку.

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

Что такое назначение? Назначение заключается в том, как будет использоваться продукт.

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

Резюмируем.

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

• Раздел 2. Требования к системе в целом
• Раздел 3. Функциональные требования

Источник: codestetic.com

Как написать ТЗ на разработку IT-продукта. Что должно быть в ТЗ для разработчика

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

Эта статья будет полезна вам, если:

1. Вы хотите отдать проект в разработку, при этом не важно инхаус или внешней команде;
2. У вас в команде нет бизнес-аналитика или тимлида, который уже имеет опыт формирования ТЗ на разработку IT-проекта;
3. Вы хотите убедиться, что техническое задание полное, команда сможет по нему точно оценить проект и реализовать его в срок.

Техническое задание: что важно знать

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

Что предшествует составлению ТЗ на разработку

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

На этом остановимся подробнее:

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

Например, бизнес-требованием можно назвать:

• Настроить фильтрацию каталога по ключевым словам: бренд, цвет, вид товара, производитель, страна производителя

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

Например, к функциональным требованиям можно отнести:

• Организовать сортировку результатов поиска по релевантности. Первыми должны идти те товары, у которых все слова поискового запроса находятся в одной строке. Далее идут товары у которых все слова встречаются в разных свойствах (при этом учитывается «вес свойства» см. ниже). Далее идут товары у которых встречается меньшее количество слов из поискового запроса
• Сделать возможность поиска по свойствам: бренд, суббренд, вид товара, название производителя, страна производитель
• Организовать сортировку результатов поиска в соответствии с «весом» свойства (название, бренд, суббренд, вид товара, состав, название производителя, страна производитель)

Обязательные составляющие тех. задания на разработку

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

• ГОСТ 34
• IEEE 29148-2011 — стандарт разработки сложных систем
• Rational Unified Process — спецификация для разработки требований к IT-продуктам

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

Гайд “Как организовать разработку IT продукта с привлечением внешней команды”

Что должно быть в ТЗ для разработки IT-продукта

Информация о разрабатываемом IT-продукте

1. Назначение и цели создания
2. Структура IT-продукта
3. из чего состоит продукт
4. как он взаимодействует с системой в целом

Глоссарий

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

Требования к IT-продукту

1. Бизнес-требования
2. Функциональные требования
3. Технические требования:
4. характеристики (нагрузка, которую должен выдержать сервис, производительность и т.д.)
5. требования к технологиям
6. требования к серверам
7. требования к скорости работы сервиса
8. обязательная интеграция со сторонними сервисами
9. требования к безопасности
10. и прочее. Таких требований может быть очень много, все зависит от того, какой продукт вы разрабатываете

Гайд “Как организовать разработку IT продукта с привлечением внешней команды”

Спецификация на интерфейс

Этот пункт присутствует в ТЗ на разработку IT-продукта при реализации по прототипам или макетам.

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

Пользовательские сценарии (use case)

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

Пользовательские сценарии помогают всем участникам системы, в том числе тимлиду:

• Определить появление возможных проблем во время разработки
• Четко определить и предсказать поведение системы
• Упрощает приемку задачи, дает совпасть ожиданию и реальности
• Дает однозначность: упрощает жизнь для разработчика, тестировщика, постановщика

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

Однако, каждый сценарий должен обязательно содержать 3 блока:

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

Пользовательская и техническая документация

Набор документации, которая будет передана по итогу работ:

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

Неважно, внешняя или внутренняя у вас команда разработки – любая команда должна вести документацию по вашему проекту и передать ее вам по итогу. В каком виде передается документация:

• Техническое задание — мы используем Confluence, Notion
• Спецификация на интерфейс — Confluence, Notion
• Конструкторскую документацию — Confluence, Notion
• Описание API — мы используем openAPI (swagger), postman
• Документация кода (оно же комментирование кода) мы используем PHPDoc, JsDoc

Порядок контроля и приемки

• Этот пункт описывает сроки и порядок сдачи разработанного web-сервиса. И значительно упрощает жизнь как команде разработке, так и Заказчику, так как регламентирует порядок приемки разработки. Не бывает так, что Заказчик отдал ТЗ и забыл о разработке продукта, вспомнив только на финальном этапе. Обычно весь процесс поделен на этапы и у каждого этапа есть контрольные точки. Чтобы у обеих сторон было понимание о ходе разработки — эти контрольные точки фиксируются и закрепляются.
• Также в этом пункте описывается, с помощью каких инструментов будет тестироваться работоспособность системы. Как правило, грамотное ТЗ содержит набор этих основных требований, но, как и говорили выше, может дополняться в зависимости от исходных данных. Следите, чтобы в вашем техническом задании были все эти пункты. Если же в команде нет экспертизы, которая может описать технические требования — передавайте эту функцию потенциальной команде разработки.

Согласование ТЗ

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

Вместо заключения

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

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

Источник: iqdev.digital

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

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

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

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

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

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

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

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

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

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

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

— Карен Оганесян, руководит командой, которая пишет и сокращает ТЗ

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

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

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

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

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

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

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

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

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

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

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

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

— Иван Леонтьев, «Лайв Тайпинга»

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

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

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

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

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

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

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

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

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

— Павел Разуваев, «Лайв Тайпинга»

Изображения

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

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

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

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

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

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

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

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

— Андрей Дёмин, «Лайв Тайпинга»