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

Кому будет полезна эта статья:

1. Тем, кто начинает свой путь в IT-предпринимательстве, но не знаком с технической стороной вопроса. 

2. Начинающим менеджерам IT-проектов, которые пока не имеют опыта в постановке задач подрядчикам.

3. Владельцам уже существующих проектов, которые нуждаются в дополнениях/доработках.

Пара слов обо мне и причине написания статьи

Привет! Я - Ксения, технический писатель, вот уже 5 лет корпящая над бесчисленными страницами техзаданий в компании мобильной разработки (Признайтесь, воображение нарисовало вам какого-то техножреца из вселенной Вархаммер? Приятно, конечно, но тут не до игр, дело-то серьезное).

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

Выглядит сложно, звучит просто - что это? Ответ: ТЗ

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

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

Чем же грозит неадекватно поставленное ТЗ на начальном этапе разработки? Ни много, ни мало - превышением бюджета и дедлайнов, иногда срывом проекта. Если заложить неправильный фундамент изначально, масштабировать систему постфактум будет непросто, не говоря уже о том, сколько денег уйдет на исправления. Главное лекарство - опытная команда разработки, которая не просто распознает дьявола в деталях, но и допилит/добавит эти детали, чтобы из них получилось собрать изначально задуманное.

Список всего что вам нужно или правильные вопросы ради правильных ответов 

Люди делятся на два типа:

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

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

Рассмотрим пока первый тип

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

1. Считаем сроки/стоимость будущего проекта

Сроки/стоимость чего именно мы хотим посчитать? Варианты такие:

• Мобильное приложение и/или сайт (веб-версия вашего сервиса). Команда считает их вместе либо отдельно. Может быть, вам нужен только сайт или только приложение.

• Первая версия продукта (MVP) для проверки состоятельности идеи либо первая версия + конечная версия (продукт в идеальном своем состоянии).

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

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

2. Общая идея/концепция сервиса

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

3. Что будет в первой версии продукта (сайт и/или мобильная версия)?

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

Примерный набор функций MVP-версии: регистрация, авторизация, главная страница с каталогом товаров, корзина заказов, форма оплаты, функции администратора (добавление товара, управление списком товаров и пользователей, смена статусов заказа, отправка пуш-уведомлений, прочее).    

4. Что будет в идеальной версии продукта через 2-3 года?

Конечная (идеальная) версия продукта не должна принципиально отличаться от начальной. Тут наша задача - развить сильные стороны продукта, обзавестись обоснованными улучшениями и надстройками. 

Планируя свой продукт в его завершенном виде, вам стоит продумать подобные вещи:

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

5. На какие рынки планируем выйти? Ближайшая цель + перспектива

Тут имеем такие варианты:

• Выходим только на отечественный рынок. Определяемся с масштабом охвата (города, области).

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

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

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

6. Какое количество пользовательского трафика (нагрузку системы запросами пользователей) ожидаем?

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

• Вероятную максимальную нагрузку на этапе старта и раскрутки приложения.

• Вероятную максимальную нагрузку после роста и раскрутки.  

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

7. Определяем типы пользователей нашего приложения 

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

• В первой версии приложения предусмотрены: администратор, арендодатель, арендатор.

• В конечной версии приложения предусмотрены: администратор, модератор, арендодатель, арендатор, сотрудники арендодателя и прочие.

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

8. Для каких устройств будем разрабатывать? Язык и тип разработки

Если вы знаете что такое технологический стек и имеете в этом вопросе свои предпочтения - укажите это команде. Но вы можете попросить команду выбрать наиболее подходящий вариант за вас, особенно если программисты владеют всеми типами разработки (нативная разработка или кросс-платформа). К примеру, мы пишем наши приложения на JAVA, Kotlin, Swift и Flutter. Если это абсолютно ничего вам не сказало - это нормально.

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

Теперь рассмотрим второй тип

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

В этом случае, список информации, которую Клиент должен предоставить команде, таков:

1. Передайте команде доступ к API-документации.

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

2. Нужны следующие данные для доступов:

• Данные для доступов к сторонним сервисам, интегрированным с вашим приложением (если таковые есть, например, сервис доставки для вашего онлайн-магазина). 

• Данные для доступа к базам данных.

• Данные для доступа к хостингу.

• Данные для доступа к DNS.

• Данные для доступа к Git.

3. Расскажите детали и хронологию работы прошлых программистов.

А именно:

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

• Сколько времени заняло написание кода? (также с разделением на платформы, если были).

• Языки написания клиентской и серверной части приложения.

Эта информация даст команде представление о legacy (наследии) кода. Можно будет понять, насколько глубоко нужно погрузиться в проект, и какого уровня специалисты должны это сделать.

4. Передайте прототипы или макеты дизайна.

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

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

Наставление и парочка советов

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

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

С уважением, Ксения.