Бизнес требования к приложению пример

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

Что такое документ требований?

Документ требований к продукту (на английском PRD — product requirements document) определяет ценность и назначение приложения для вас самих и для команды разработчиков. С помощью этого документа вы сможете объяснить разработчикам для кого предназначен продукт и какую пользу он приносит конечному пользователю. PRD направляет разработку продукта, обеспечивая понимание цели, стоящей за приложением. Документ описывает бизнес-логику продукта, содержит все технические характеристики и помогает команде разработчиков преобразовать раннюю концепцию в полнофункциональное приложение.

В статье мы расскажем, как составить идеальный PRD, который поможет продукту пройти путь от идеи до выхода на рынок.

Виды и примеры требований. Видеокурс Основы разработки требований в ИТ-проектах. Денис Бесков, 2013

Потребности бизнеса

Любое мобильное приложение создаётся для решения определённых задач. Потребности бизнеса в PDR описывают как приложение будет отвечать нуждам компании и пользователей.

При составлении бизнес-требований необходимо учитывать следующие моменты:

• Для каких целей вам нужно приложение? Чего хотите добиться с его помощью?
• Какую текущую проблему(-ы) оно решит? Как улучшит текущие бизнес-процессы?
• Что должно делать приложение? Какова его основная функциональность, какие функции могут понадобиться?
• Существуют ли рекомендации по брендингу и дизайну, которым должны следовать разработчики?

Цели мобильного приложения

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

Уровень доступа пользователей

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

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

Каким вы видите ваше мобильное приложение?

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

Как писать требования так, чтобы команда хотела их читать / Александр Войтехович / ISsoft

Составьте список функций

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

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

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

Стратегия монетизации

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

Реклама — вы получаете доход за счёт продажи рекламного пространства и показа рекламы в приложении.

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

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

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

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

Технические характеристики

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

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

На каких платформах будет доступно приложение (iOS, Android или Windows)?

Какие версии операционной системы должны его поддерживать?

Каковы ваши потребности в обслуживании? Необходима ли дальнейшая поддержка специалистов?

Есть ли у вас текущая документация по API/сервисам?

Есть ли у вас текущие учётные записи Apple, Google или других разработчиков?

Каковы ваши текущие сервисы, серверы, базы данных?

Выбор платформы

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

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

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

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

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

Техническое обслуживание и модернизация

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

Допущения и ограничения

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

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

Подготовка к загрузке в магазины

В документе требований обязательно должна содержаться информация, необходимая для загрузки приложения в Apple App Store и Google Play. Разработчики знают требования магазинов и смогут подсказать, что именно нужно, какие нюансы следует учитывать в процессе разработки, чтобы облегчить подачу заявки.

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

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

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

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

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

ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА РАЗРАБОТКУ МОБИЛЬНОГО ПРИЛОЖЕНИЯ

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

Подпись Заказчика и Исполнителя на настоящем документе подтверждает их согласие с нижеследующими фактами и условиями:

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

1. Требования к графическому дизайну сайта

3.1 Требования к дизайну сайта

При разработке сайта должны быть использованы преимущественно светлые и контрастные цветовые решения (пример дизайнерских решений: https://habrahabr.ru/post/334722/ ).

Оформление должно быть разработано в достаточно консервативном ключе.

На страницах недолжно быть большого объема текста.

В дизайне сайта не должны присутствовать:

— много сливающегося текста;

— тёмные и агрессивные цветовые сочетания и графические решения.

Рис. Пример формы авторизации

3.2 Порядок утверждения дизайн-концепции

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

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

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

4.1 Классы пользователей

3) Администратор – пользователь, авторизованный в интерфейсе сайта

• Полный доступ ко всем функциональным возможностям администрирования мобильного приложения:
• Статические разделы — просмотр, добавление, редактирование, удаление
• Разделы новостей — просмотр, добавление, редактирование, удаление
• Новости – просмотр, добавление, редактирование, удаление
• Статьи – просмотр, добавление, редактирование, удаление
• Разделы– просмотр, добавление, редактирование, удаление
• Видеоролики, фотографии – просмотр, добавление, редактирование, удаление
• Личные данные пользователей – просмотр, редактирование
• Список рассылок и уведомлений – просмотр, добавление, редактирование, удаление
• Комментарии к фотографиям, видеороликам, текстам– просмотр, редактирование, удаление
• Группы пользователей – просмотр, добавление, редактирование, удаление
• Пользователь — просмотр, добавление, редактирование, удаление, раздача прав
• Статистика – просмотр

4.2 Требования к представлению мобильного приложения

Требования к представлению главной страницы мобильного приложения.

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

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

Контентная часть главной странице мобильного приложения должна включать:

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

Требования к отображению раздела «проживание».

При переходе пользователя на раздел «проживание» пользователю в верхней части экрана

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

Требования к внутренним страницам раздела проживание.

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

Требования к отображению раздела «развлечения».

При переходе пользователя на раздел «развлечения» пользователю

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

Требования к внутренним страницам раздела «развлечения».

• стрелка, чтобы вернуться на страницу разделов. Должна присутствовать опция поделиться с друзьями и добавить в избранное.
• во всю ширину должен располагаться слайдер с фотографиями данной экскурсии;
• название места, количество звездочек, количество отзывов, выбор дата заезда и отъезда (с выбором дат на карте);
• Ниже должна быть написана цена и спецпредложение. Чуть ниже должна присутствовать информация о отеле (хостеле, дома отдыхе и тд).

Требования к разрабатываемому разделу «транспорт»

• Должны присутствовать разделы-выборы авиа-билеты, жд билеты, вызов такси, аренда автобуса;
• В разделе авиабилеты должен быть календарь с выбором дата отчета и прилета, пунктом отправления и пунктом назначения, класс
• В разделе авто должны присутствовать выбор тип авто: эконом, «люкс», «комфорт»

Требования к разрабатываемому разделу «питание»

• Вызов питания на дом
• Заказ столика в ресторане

Требования к внутренним страницам раздела «питание».

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

Требования к внутренним страницам раздела «личный кабинет».

Требования к странице «оплата».

Оплата путевки, тура, экскурсии, снаряжения и тд.

• После добавления элемента (путевки и тд) в корзину, пользователю выводится сообщения о том, хочет ли он продолжить покупку чего-нибудь еще и перейти на оплату.
• После перехода пользователю на вкладку оплаты, если у него не введены данные карты, то ему предлагается вести данные карты (Номер, код, владелец). После введения этих данных пользователь переходит на страницу подтверждения оплаты
• На странице подтверждения оплаты ему выводится список того, что он выбрал, стоимость заказы, налог на данную услугу, комиссия, если она есть, и итоговая стоимость и кнопка оплатить.
• После нажатия на кнопку оплатить. Клиенту выводится сообщение, что его заказ принят и обрабатывается. Если у клиента недостаточно денег, то ему выводится сообщение, о том, что у него недостаточно денег и предлагается ему вести другой номер карты или повторить попытку снова.
• После успешной транзакции на почту клиента приходит чек о совершенной операции.
• Оплата услуг должна производиться с помощью стороннего сервиса — Payonline.
• После оплаты пользователю должно вернуться 6% кеш бека со следующей покупки.
• Передача данных производится внутри приложения с помощь REST или JSON технологии.

Оплата авиа, жд билетов.

• Оплата билетов происходит с помощью iframe, который выводится после нажатия на кнопку оплатить.
• В iframe передаются параметры: фамилия, имя, отчество, данные кредитной карты.
• После оплаты возвращается callback в мобильное приложение.

Требования к структуре сайта

• Сайт создается с целью внесения в ручном режиме информации на сайт.
• Для выгрузки отчетности

Пользователи группы «Администратор-владелец» могут редактировать все поля. Пользователи группы «Администратор-аналитик» могут выгружать информацию, но не могут редактировать и просматривать информацию о клиентах.

Пользователи могут авторизоваться в мобильном приложении, в форме авторизации должны присутствовать:

• Текстовое поле для ввода логина пользователя
• Кнопка отправки формы.

Данные для доступа (авторизации):

• Логин – адрес электронной почты пользователя
• Пароль – строка содержащая от 8 символов, состоящая из A-z, 0-9.

Ниже формы располагаются ссылка:

Форма «Забыли пароль» содержит поля:

• Email адрес пользователя, указанный при регистрации

При неудачной попытке авторизации – появляется приглашение для повторной попытки

авторизоваться с формой авторизации.

Списки рассылок и уведомления

Авторизованные пользователи могут управлять своими списками рассылок, а также

просматривать полученные уведомления.

• Добавить рассылку
• Удаление рассылку
• Редактирование рассылку

• Просмотреть список рассылок
• Подписаться на список рассылок
• Отписать от списка рассылок
• Просмотреть уведомления

4.4 Требования к разделению доступа

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

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

5.1 Требования к информационному обеспечению

Требования к хранению данных

Все данные сайта должны храниться в структурированном виде под управлением реляционной

СУБД. Исключения составляют файлы данных, предназначенные для просмотра и скачивания

(изображения, видео, документы и т.п.). Такие файлы сохраняются в файловой системе, а в БД

размещаются ссылки на них.

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

инсталляцией системы, должно храниться под управлением единой СУБД.

Требования к языкам программирования

Для реализации статических страниц и шаблонов должны использоваться языки HTML 4.0 и CSS.

Исходный код должен разрабатываться в соответствии со стандартами W3C (HTML 4.0).

Для реализации интерактивных элементов клиентской части должны использоваться языки

JavaScript и DHTML.

Для реализации динамических страниц должен использоваться язык PHP.

Для разработки мобильного приложения должен быть использован ReactJS

Требования к организации гиперссылок

Все ссылки в мобильном приложении должны быть относительными (за исключением внешних).

Требования к иллюстрациям

Все рисунки и фото объемом более 1 kb (кроме элементов дизайна страницы) должны быть

выполнены с замещающим текстом. Все рисунки должны быть в формате gif или jpg.

Требования к объему одной страницы

Объем одной стандартной загружаемой страницы сайта в среднем не должен превышать 170 kb.

5.2 Требования к программному обеспечению

• Операционная система семейства Unix (Linux, FreeBSD и пр.)
• Веб-сервер Apache 1.3.18 и выше
• Nginx, модуль mod_accel для Apache
• Набор библиотек и утилит ffmpeg
• PHP 4.2.0 и выше (должен быть собран как модуль Apache)
• СУБД MySQL 4.1.14 и выше (предпочтительно: поддержка формата InnoDB).
• Модули PHP: Mcrypt, FTP, ffmpeg-php
• Библиотеки PHP: Smarty, GeoIP
• Возможность доступа к localhost по FTP протоколу
• 2 пользователя БД

Желательно, чтобы PHP не был запущен в SafeMode.

• Любой из перечисленный ниже браузеров (указана минимальная версия) с включенным
• Internet Explorer 6
• Mozilla 1.6 (Firefox 1.0)
• Opera 9
• Adobe Flash Player версии 9 и выше. Сайт должен быть работоспособен (информация,
• расположенная на нем, должна быть доступна) при отключении в браузере поддержки flash и

5.3 Требования к техническому обеспечению

• Компьютер с процессором Xeon 4 ядерный
• 2 ГГц (рекомендуется от 3 ГГц)
• Оперативная память 4 Гб
• Место на жестком диске от 1 Гб

Точные технически характеристики сервера будут уточнены после завершения системы и

обширного тестирования всех модулей

• Компьютер с процессором i3 ГГц (рекомендуется от 1.5ГГц)
• Оперативная память 256 Мб (рекомендуется от 512 Мб)

5.4 Требования к лингвистическому обеспечению

Сайт должен выполняться на русском языке.

5.5 Требования к эргономике и технической эстетике

Дизайн приложения должен быть адаптивный и работать корректно во всех устройствах (Android и IOS) с разрешением экрана 720х1280 пикселей, 1080х1920, 2560×1440, 640х1136 и 750х1334 пикселей соответственно. Интерфейс подключаемых модулей должен быть выполнен в едином стиле с интерфейсом ядра системы и должен обеспечивать возможность прозрачного перемещения администратора между модулями системы и использование одинаковых процедур управления и навигационных элементов для выполнения однотипных операций.

1. Требования к приемке-сдаче проекта

6.1 Требования к наполнению информацией

Общие требования к информационному наполнению

Наполнение страниц мобильного приложения должно происходить в автоматическом режиме.

6.3 Требования к персоналу

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

Администратор, оператор: уверенный пользователь сети Интернет, знание Microsoft Word.

Прочие пользователи: уверенный пользователь сети Интернет.

6.4 Порядок предоставления дистрибутива

По окончании разработки Исполнитель должен предоставить Заказчику дистрибутив системы в

— архив с исходными кодами всех программных модулей и разделов сайта;

— дамп проектной базы данных с актуальной информацией.

Дистрибутив предоставляется на CD-диске в виде файлового архива.

6.5 Порядок переноса сайта на технические средства заказчика

После завершения сдачи-приемки сайта, в рамках гарантийной поддержки Исполнителем

производится однократный перенос разработанного программного обеспечения в apple store, google market .

Перед осуществлением переноса Заказчик обеспечивает удаленный shell-доступ к веб-серверу и

доступ к базе данных сайта.

6.6 Дополнительные требования

Требования к производительности

Работа любого скрипта не должна превышать 60 секунд.

При условии нагрузки на сервер не более

500.000 обращений к страницам портала в сутки.

Требования к безопасности

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

код скриптов. Требуется разграничение доступа.

Пароли пользователей хранятся в зашифрованном виде. Перехват данных на уровне протокола tcp возможен.

На уровне СУБД должно быть реализовано разграничение доступа к данным в БД.

Требования к надежности

Система может быть недоступна не более чем 24 часа в год. Резервирование данных осуществляет

хостинг-провайдер. У администратора сайта должна быть возможность выгрузить и загрузить

Источник: businessarchitecture.ru

Пишем бизнес-план: дополнения и приложения к бизнес-плану

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

Интересно, как вы представляете себе хороший, грамотный бизнес-план? На самом деле, это 200-300 (а иногда и больше!) напечатанных страниц “скучного” текста, «разбавленного» иногда рисунками, схемами, диаграммами. Это то, что видно снаружи. Внутри скрыта кропотливая напряженная работа, иногда бессонными ночами, сжатые сроки, неуместные требования некомпетентного заказчика, и другие не очень приятные моменты.

Причем, совсем не факт, что ваше «творение» понравится потенциальному инвестору, и вам выделят средства на ваш проект. Как правило, это случается в соотношении примерно 1/40. А в условиях кризиса в стране, начавшегося в 2015 году, это соотношение значительно увеличилось. Отказы бывают часто, и к этому нужно быть готовым. Когда в надежде получить финансирование своего проекта, вы трудитесь, не покладая рук, в течение месяца, а после отказа у вас остаются лишь расходы на печать и несколько сотен тысяч символов на бумаге, руки опустятся у кого угодно. p, blockquote 1,0,0,0,0 —>

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

Вряд ли вы будете читать дальше первых трех разделов бизнес-плана: титульного листа и краткого резюме проекта, описания компании, и описания услуг и продукции. Даже, если описание будет сверхгениальным. p, blockquote 2,0,1,0,0 —>

1. Презентационный, описывающий в ярких красках все преимущества и выгоды предлагаемого проекта – специально для инвестора.
2. И развернутый, предназначенный для инвестиционной защиты проекта, скучный и полный цифр и расчетов – для специалистов, которые будут проверять этот бизнес-план.

Обоим проектам нужно уделить самое пристальное внимание при подготовке. Если для первого типа будет достаточно нескольких листов описания (до 25-30) и, возможно, видеопрезентации, то второй должен содержать все предыдущие изученные нами разделы бизнес-плана: p, blockquote 4,0,0,0,0 —>

1. Титульный лист. Резюме
2. Описание компании
3. Описание услуг и продукции
4. Анализ рынка
5. Маркетинговый план
6. Производственный план
7. Организационный план
8. Финансовый план
9. Оценка и страхование рисков

p, blockquote 5,1,0,0,0 —>

p, blockquote 6,0,0,0,0 —>

Что содержит раздел дополнений и приложений?

• Регистрационные документы компании: копии регистрации ИП, или юридического лица, копии устава, лицензий, сертификатов, свидетельств, и т.д.
• Документация на технические характеристики предполагаемого к использованию оборудования: патенты на оборудование; фотографии, чертежи, схемы; отчеты о проведенных испытаниях; примеры использования; отзывы и комментарии компаний, использовавших данное оборудование, клиентов, конкурентов, и т.д.
• Таблицы, отражающие итоги маркетинговых исследований, мониторинга рынка, итоги социологических опросов, и другие подобные документы.
• Документы, имеющие отношение к Производственному разделу бизнес-плана: расчетные этапы строительства производственных площадей (при необходимости); описание используемых в производстве или при оказании услуг технологий и технических решений; необходимые лицензии и другая разрешительная документация на производство или оказание услуг; обоснование требований по наличию на объекте производства того или иного оборудования, техники, инвентаря; схемы расположения производственных площадей, расстановки оборудования; фотографии (и/или видеоматериалы) предлагаемого производства.
• Нормативные и правовые документы бизнес-плана: общая схема руководящей структуры компании и иерархия всех ступеней на предприятии; графики-схемы, отражающие этапы, сроки, и условиях для их выполнения для полной реализации предлагаемого бизнес-плана; законодательные акты, нормативно-правовые формулировки, выписки из юридических документов, которые имеют отношение к выполнению проекта; требования, предъявляемые на областном, районном, и муниципальном уровне; составленное штатное расписание, определение должностных обязанностей всех сотрудников, график времени работы предприятия (желательно составленный на год вперед).
• Документация, имеющая отношение к финансовому разделу бизнес-плана: это различные таблицы, графики, диаграммы, расчеты, сметы, и другие документы, которые по каким-то причинам (например, объем) не вошли в основную часть финансовой части, но имеют непосредственное отношение к реализации проекта.
• Документация, имеющая отношение к минимизации возможных рисков: гарантийные письма клиентов, поставщиков, подрядчиков, и т.д.; договора аренды (субаренды), поставок, и т.д.; оформленные страховые договора, и т.д.
• Документы об экологическом воздействии предлагаемого бизнеса на окружающую среду: стратегия экологической политики предприятия, экологические нормативы, предъявляемые к подобным производствам; меры, предполагающиеся к использованию для снижения влияния на природу; штрафы и санкции, налагаемые в результате нарушения экологического равновесия; заявление о несении ответственности за воздействие на экологическую обстановку.
• Биографические сведения руководства предприятия, автора проекта, свидетельствующие об их компетенции в предлагаемой сфере бизнеса.

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

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

Это важно! Раздел приложений и дополнений не ограничивается по объему написания. Главное здесь полезность и полнота отражения всех нюансов.

Источник: business-poisk.com