Процесс запуска проекта шеринга
☝ Запуск проекта — это процесс, который начинается от подписания нового проекта и передачи его проджекту от отдела продаж, до полноценного запуска одного объекта в мобильном приложении на бою
⚙ Запускаем четко, в срок и чтобы клиент был доволен.
📌 На данный момент наша система готова к запуску типов транспорта:
— 🛴 кикшеринги
— 🚗 каршеринги
— 🚲 велошеринги
2. Регистрация в партнерских сервисах
3. Настройка и подключение оборудования
4. Настройка панели администрирования
6. Тестирование сервиса
Опорные точки для определения дедлайна запуска. Какие критерии должны учитывать: — Загруженность команд продуктовой и разработки, график отпусков; — Наличие оборудования на руках (или оно только готовится к отгрузке); — Исходный статус готовности клиента (готовы ли регистрации по первому этапу, есть ли тестовый самокат для подключения); — Наличие или отсутствие дизайнера у клиента; — Для App Developer Account регистрация на Юридическое (дольше) или физ.лицо. Для постановки дедлайна, который получается после расчёта, добавляем + 25% рабочих дней от прогнозного срока. Согласовываем эту дату с клиентом.
📌 Все общение по запуску проекта происходит в телеграме от имени корпоративного аккаунта.
Данные для входа в корп. аккаунт:
+7 991 698 8498

📌 Цели первого созвона: — Познакомиться с клиентом, установить человеческий контакт — Рассказать клиенту про особенности запуска и что ему предстоит делать — Договориться о дедлайне по запуску — Собрать все вводные по проекту
Cформировано видение о проекте, определены участники проекта, определены основные риски (например, нет оборудования на руках, нет иностранной карточки для платежей за сервисы, нет партнёра или админа, клиент технически не подкован). Определен дедлайн запуска и согласован с клиентом. Есть понимание о наличии фирменного стиля для брендирования.
Этапы:
— Изучаем бриф по проекту в Odoo, который заполнили Sales.
— Создается группа в телеграме по запуску.
— Пишем в группу приветственные сообщения, договариваемся о первом звонке
Шаблоны сообщения приветственного
Давайте запланируем с вами первичный звонок, чтобы мы познакомились, и я рассказал вам подробнее о этапах запуска. В какое время вам удобно?
— Созваниваемся с клиентом, текстом прописываем первые этапы по запуску. — Согласовываем и обозначаем дату дедлайна запуска;
— Если sales-менеджер не заполнил карточку клиента в odoo, то узнаем у клиента информацию для создания карточки компании в CloudPayments: название компании, рабочее название проекта, имя представителя, номер телефона, e-mail;
— Рассказываем про биллинг и про наши выгодные условия — 3% на старте, так как для наших клиентов скидка. Обычный тариф — 3.9%;
— Устанавливаем график коммуникации по задачам проекта — 3 раза в неделю (понедельник утро, среда, пятница после обеда).
— Создаем карточку компании через партнерский кабинет CloudPayments используя инструкцию.
Шаблон сообщения после первого созвона
Шаблон сообщения в СloudPayments, чтобы они связались с клиентом
ВАЖНО: клиент не знает о том, что у нас партнёрская программа с СloudPayments, и то, что мы зарабатываем 0.5% с общей выручки клиента.
Шаблоны сообщений (пока не используем, так как переезжаем в Jira) Всю коммуникацию по запуску ведем в Телеграм
Задачи в очереди (здесь начинаются все задачи)
Уточнение задачи (сюда попадают задачи, которые клиент не понял)
В разработке (задачи, которые делает Rightech)
В работе (задачи Rightech команды ПМов и клиента)
Тест Rightech
Тест клиентом
Готово
Первый этап состоит из данных этапов:
Регистрация аккаунта в Apple Store;
Регистрация аккаунта в Google Play;
Регистрация Google сервисов (Firebase, Google Maps, Captcha);
Регистрация аккаунта в смс-центре;
Подключение эквайринга
Страхование клиентов
Сайт для сервиса
📌 Данные шаги выполняются как со стороны клиента, так и со стороны проджекта.
⏰ Данные шаги выполняются параллельно и у каждого шага есть свой срок выполнения. Как со стороны клиента, так и со стороны проджекта.
🍏 Регистрация аккаунта Apple Developer
Что нужно делать клиенту?
Выполнить все настройки, которые описаны здесь
<aside> 📌 Срок выполнения: 3-4 недели
</aside>
Что нужно делать проджекту?
— Получить логин и пароль от Apple ID
🌎 Регистрация аккаунта разработчика в Google Play Console
Что нужно делать клиенту?
Выполнить все настройки, которые описаны здесь
<aside> 📌 Срок выполнения: 2-3 недели
</aside>
Что нужно делать проджекту?
— Получить приглашение ииспользовать аккаунт Google Play Console на почту: rightech.project@gmail.com
🤖 Регистрация в сервисах Google
Что нужно делать клиенту?
Выполнить все настройки, которые описаны здесь
<aside> 📌 Срок выполнения: 2-3 дня
</aside>
Что нужно делать проджекту?
📩 Регистрация аккаунта в SMS-центре
Что нужно делать клиенту?
Выполнить все настройки, которые описаны здесь
<aside> 📌 Срок выполнения: 2,3 дня
</aside>
Что нужно делать проджекту?
— Получить логин и пароль от смс-центра, занести данный в BitWarden — Настроить смс центр. Инструкция **здесь** — Занести данные для созданного SMPP и Api в Bitwarden
🏧 Подключение интернет-эквайринга и онлайн-кассы
Что нужно делать клиенту?
Выполнить все настройки, которые описаны здесь
<aside> 📌 Срок выполнения: 4, 5 дней
</aside>
Что нужно делать проджекту?
— Получить логин и пароль от ЛК экваера, занести данный в BitWarden — Проконтролировать, чтобы ключи мерчанта занесли в наш корпоративный аккаунт CloudPayments — Настроить мерчанты и внести их в панель администрирования. Инструкция здесь
🤕 Страхование жизни и здоровья клиентов сервиса кикшеринга
🗺 Создание сайта для сервиса
Получаем схему подключения и создаём цифровую модель в платформе
Чек-лист по добавлению нового ТС с Teltonika:
Добавляем объект в платформу Идеально — через копирование от такого же, ранее заведенного в систему. Обращаем внимание на заполнение данных о цифровой модели, типе, названии для приложений клиентов, данных о запасе хода и конфигурации объектов.
Добавляем обработчик Добавляем используемый для модели устройства обработчик данных, чтобы рассчитывался запас хода, или система выполняла дополнительный разбор пакетов данных.
Выводим объект в онлайн и тестируем команды Проверяем, чтобы приходили все данные: заряд батареи, статус, координаты. Отправляем команды настройки передачи данных и скоростных режимов, если используются. Обычно они внесены на вкладку «Настрой» в разделе команд
Добавляем геозоны Можно добавить конкретные зоны к объекту или добавить сразу несколько объектов к геозоне для дальнейшего учета в автоматах и контроля выезда. Выбираем тип геозоны у объектов.
Запускаем автоматы Добавляем набор автоматов логики к новым объектам и запускаем их.
Синхронизируем объекты между платформой и админкой Таким образом, мы добавим их в клиентское приложение сервиса Это шаг, перед которым оборудование настроено для аренд. На данном этапе мы должны «состыковать» модель в админке с конкретными объектами в платформе. После синхронизации им автоматически назначится модель с тарифами, картинкой транспорта, страховкой, допустимыми командами в интерфейсе клиентского приложения.
Тестируем аренду из приложения Проводим аренду в режиме клиента, что проверить настройки и работу оборудования перед выпуском в город.
Настраиваем группу для проекта на sandbox.rightech.io и выдаём доступ клиенту
[ ] Создаём группу копированием от группы другого шеринга Родителем группы выбираем её же саму, так это группа для «Главной компании» Роль обязательно
Rightcar Base roleЛицензию группе НЕ УСТАНАВЛИВАЕМ Имя — произвольное Метка — произвольное SMPP — выберем, когда подключим смс-центр.
[ ] Копируем набор ролей для проекта (4 шт). на sandbox.rightech.io созданы образцовые роли

💡 Что такое панель администрирования? Это система, которая связана с работой мобильного приложения. Если коротко, то через эту панель осуществляется полноценное администрирование сервисом (настройка тарифов, выгрузка отчетов, история аренд, список и данные пользователей, начисление бонусов и штрафов, а также многое другое).
💡 Термины и структура Бекенд мобильных приложений = Панель администрирования = Админка Админка, также как и платформа, делится на тестовую среду (песок) и боевую
⚙ Настройка админки очень важна. Если неправильно настроить админку или что-нибудь забыть, то сервис будет работать не корректно. Панель администрирования позволяет настроить содержание и логику работы клиентских мобильных приложений. В результате настроек получается пазл из конфигураций. Сервис начнёт полноценно работать согласно вашему видению и особенностям бизнес-процессов.

То, как выглядит панель администрирования
[ ] Добавить локаль en
[ ] Настроить "Виды транспорта"
[ ] Авторизация (внести тестовых пользователей и установить лимиты)
[ ] Биллинг (эквайринг)
[ ] Пуш-уведомления пользователя (статусы аренды, оповещения о лимитах в пакетной аренде)
[ ] Пуш-уведомления (ключ Firebase, настройка массовой рассылки)
[ ] Логика (автомат контроля времени и пробега)
[ ] Переводы (предупреждение об отсутствии переводов для нескольких языков)
[ ] Регистрация (поля для регистрации, данные для доступа к аренде)
[ ] Тарифы (время брони, оценки и количество бесплатных бронирований) (admin/configs-app/tariffs)
[ ] Команды перехода в режим ожидания (rent-pause, rent-continue)
[ ] Локализация
[ ] Настроить модель и прилинковать к ним тарифы и команды
[ ] Валюта
📎 Полезные материалы:
1. Как развернуть бэкенд для проекта. Кикшеринг
2. Капча. Создание и настройка
3. Команды. Создание команд в админке проекта
4. Лого и Favicon на бэкэнде. Конфигурация
6. SMTP Подключение. Конфигурация почты.
📌 Брендирование — это замена логотипов, картинок, иконок и цветов на экранах приложения под ваш бренд. При брендировании мы не меняем расположение, форму, наличие или отсутствие каких-либо модулей интерфейса и дизайна приложения.
✅ 😉Инструкции для брендирования для клиентов - 👈 там можно почитать какой дизайн хороший, а какой нет. Его подготовил наш дизайнер. Данную инструкцию мы отправляем нашим клиентам, чтобы не пришлось переделывать корявые материалы для брендирования.
👇 Вот таблица, которая показывает из каких шагов состоит брендирование 👇До получение файлов для брендирования | После получения файлов для брендирования |
|---|---|
1. Собираем данные о проекте ПЕРЕД ТЕМ КАК ЗАПУСКАТЬ БРЕНДИРОВАНИЕ: — количество объектов у клиента на запуске — какие замки (механические/электрические или без замка) — тип аренды (станции, парковки, свободные) — если есть замок, то пусть пришлет как он выглядит и работает (механизм открытия и закрытия). Как крепится замок к самокату/велосипеду — IoT протокол на котором работает клиент — c кем работает клиент: наши дизайнеры или его | 1. Работа с файлами брендирования и передача их дизайнеру и продуктологу а) Если у клиента свой дизайнер: — Контролируем и напоминаем, чтобы файлы соответствовали Инструкции для брендирования для клиентов — передаем файлы дизайнеру на утверждение б) Если клиент использует наши услуги: — тогда данные этапы контролирует дизайнер |
2. Отправляем Инструкцию для брендирования для клиентов | 2. Cоздаем задачу на брендирование в GitLab для Android и Ios * После того, как дизайнер забрендировал проект в figma. Примеры заполненных задач: 1. Кикшеринг. Android и Ios 2. Каршеринг |
3. Просим клиента заполнить таблицу “Требования к публикации приложений”. Зачем: — Это таблица после заполнения которой мы можем выполнять настройку страниц и отправлять на публикацию приложение Где ее взять: — Она находится в папке Perfect Project Template . Называется [Шаблон] Требования к публикации приложений. От этой паки нужно сделать копию и присвоить ее твоему проекту и отправить ссылку клиенту, чтобы он ее заполнял | 3. Инициализация проекта в сторе. Android Цель: опубликовать приложение в PlayMarket и AppStore на проверку Этапы: 1. Создание задачи по инициализации проекта в Gitlab для Android Примеры: Android 2. Заполнить страницу в Playmarket |
4.1 Создаем задачу на развертывание бекенда приложения. Пример задачи по развертыванию админки вот 4.2 Создаем задачу на брендирование iOS и Android Пример задачи по брендированию | 4. Ios. Отправка приложения на проверку: Этапы: 1. Во время того как разработчик создал приложение и начал его брендировать можно приступать к отпрвке приложения на проверку. 🎈Здесь инструкция, как это делать 2. После того как разработчик создал версию приложения и тестировщик ее проверил можно публиковать приложение на проверку |
5. Обсуждаем c руководителем и продуктологом, нужно ли запросить дополнительную информацию в зависимости от тонкостей проекта | 5. Публикация приложений в сторы После того как приложения прошли проверку их можно публиковать в PlayMarket и AppStorе |
К моменту начала тестирования сервиса и мобильных приложений клиентом мы должны провести основные и дополнительные пользовательские сценарии самостоятельно, чтобы убедиться, что клиент не встретит очевидные ошибки.
Только после полной настройки сценариев с нашей стороны мы можем передавать сервисы клиентам!
Для того, чтобы выполнить наши обязательства по запуску, достаточно выполнения описанных сценариев:
Приемка результата запуска шеринга электросамокатов
Приемка результата запуска шеринга автомобилей
После успешного теста и проверки приложений в Google Play и App Store, мы договариваемся о дате и периоде технического запуска на ограниченной партии. Средний срок: 5-8 дней. В этот период нормально наличие ошибок и совместная работа над улучшением настроек сервиса, автоматов логики.
По результату правок в процессе технического запуска мы согласовываем переход в полноценный запуск и переход проекта в режим поддержки.

