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

Исследование рынка

Вам пришла в голову бизнес- идея. Замечательно! Прежде чем приступить к подсчету прибыли необходимо понять насколько она перспективна. Даже если вы видите 10-ки схожих успешных проектов это не значит что ваш 11 повторит их успех. Как минимум по двум причинам:

• 11-й клон рынку не нужен, на следовательно вы должны предлагать что-то уникальное, имеющее конкурентные преимущества, или являющееся уникальным торговым предложением. Повтор чужого удачно опыта на другой аудитории, как правило тоже имеет ряд своих особенностей - продажа купальников в летний сезон в Якутии не повторит Сочинского успеха.
• Ошибка выжившего - вы видите лишь успешные компании, и не знаете о том сколько компаний стартовали и “прогорели”.

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

Бизнес-план

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

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

• Капитальные инвестиции, разработка
• Подъем, выход на самоокупаемость
• Развитие - период после того как окупились капитальные вложения. Эта точка может определяться не только тем что затраченные деньги удалось физически “отбить”, но и стоимостью проекта (если бы вы захотели проект продать).

Что важно учесть при его составлении:

• Капитальные затраты (покупка оборудования, разработка проекта, лицензии и т.п.)
• Затраты на рабочие места (мебель, аренда) и зп сотрудников - тут важно учесть что проект не начнет приносить прибыль с момента запуска.
• Инвестиции в развитие на всем протяжении существовании проекта, если на первом и втором этапе это может быть фиксированная сумма, то на третьем этапе это может быть % от прибыли (ДРР).
• Срок выхода на уровень текущей окупаемости
• Окупаемость капитальных затрат

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

Естественно что планов должно быть три:

• Оптимистичный
• Реалистичный
• Пессимистичный

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

Именно на этом этапе закладываются основные KPI проекта на которые в дальнейшем будет необходимо ориентироваться.

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

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

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

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

Roadmap ( дорожная карта проекта)

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

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

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



Описание бизнес-процессов

Кроме внешнего функционала проекта вам необходимо продумать о следующем:

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

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

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

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



Функциональные требования

Это первичный документ, определяющий требования к проекту и его функционалу. Требования группируются в блоки, например - требования к каталогу, к верстке к SEO.

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

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

Давайте разберем на примере нескольких реальных кейсов (далее приводим цитаты с формулировками клиентов):

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

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

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

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

• Протокол обмена
• Формат обмена
• Периодичность обмена
• Поля информации по которым должен производиться обмен

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

Об этом распространенном формате хочется сказать отдельно - формат как структура очень даже неплох. Но у него есть несколько существенных недостатков:

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

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

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

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

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

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

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

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

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

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

Прототип

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

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

Техническое задание

Это важнейший технический документ, который должен быть понятен вам как заказчику, менеджеру проекта и разработчику. В него необходимо включить всю значимую информацию, собранную на предыдущих этапах. Он должен быть достаточно подробен независимо от методологии по которой будет реализовываться ваш проект (Waterfall/Agile). Исходите из того, что если чего-то нет в ТЗ, то этого не будет и в проекте. Стоимость ТЗ может составлять до 15% от стоимости его реализации.

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

Документация по проекту

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