мета-данные страницы
Различия
Здесь показаны различия между двумя версиями данной страницы.
| Предыдущая версия справа и слева Предыдущая версия | |||
|
agbis_pmp:pmp_integration_process [08.10.2025 14:43] Евгения удалено |
— (текущий) | ||
|---|---|---|---|
| Строка 1: | Строка 1: | ||
| - | ===== Общий процесс интеграции мобильного приложения от продажи до повторного перевыпуска ===== | ||
| - | Данная инструкция описывает общий процесс интеграции мобильного приложения в порядке от начала до конца. Последовательность действий не является строгой, но если стремиться к её | ||
| - | поддержанию, то можно снизить риск провалов в скорости работы по нашей вине. | ||
| - | \\ | ||
| - | Отмечаем, хотя-бы кратко, все крупные процессы по интеграции приложения в данном файле https://docs.google.com/spreadsheets/d/1RkxW6-zNVmxplAd3BCyt_lfUTt7HLfPEGug0h2cQ0Ys/edit?usp=sharing. При большом количестве активных проектов он позволяет быстро вспомнить нужное и продолжить работу с клиентом | ||
| - | \\ | ||
| - | \\ | ||
| - | ==== Получение задачи ==== | ||
| - | В общем чате проходит автоматическое оповещение о закрытой сделке по ПМП от product owner\\ | ||
| - | {{:agbis_pmp:pasted:20250206-120847.png?1000x300}}\\ | ||
| - | В этот момент должна автоматически создастся задача на разработку приложения\\ | ||
| - | {{:agbis_pmp:pasted:20250206-121039.png?1000x1000}}\\ | ||
| - | Если скрипт отработал некорректно и задача не создалась автоматически, то необходимо обратиться к эксперту мобильной команды и попросить сделать задачу в канбане сделок | ||
| - | В дальнейшем нам необходимо перемещать сделку в канбане сделок из одной колонки в другую, когда приложение будет проходить разные стадии своего развития | ||
| - | \\ | ||
| - | \\ | ||
| - | ==== Подготовка к работе с клиентом ==== | ||
| - | |||
| - | Прежде чем начинать работы по интеграции, необходимо установить первичную связь с клиентом. Для этого берём его номер телефона из задачи или узнав её у product owner или из иных источников\\ | ||
| - | На звонке клиенту: | ||
| - | * Описываем общую схему работы с ним. Нам нужно вкратце описать суть данной документации, чтобы клиент понимал, из чего будет состоять процесс разработки и интеграции приложения | ||
| - | * Интересуемся как они в целом, сейчас работают и для чего они хотят использовать приложение. Эти знания помогут нам понять, какие самые важные для клиента задачи будет решать приложение(например, если клиент хочет приложение, только чтобы подтверждать заказы и получать пуши, то перенапрягать его заказами из корзины и выездами сильно не стоит, а если он хочет, чтобы клиенты могли просматривать цены на свои услуги, то стоит заострить вопрос на том, что клиенту нужно будет залить картинки на свои услуги и почистить прайс-листы от мусорных позиций , также оптимизировать их количество) | ||
| - | * Подчёркиваем тот факт, что приложение является типовым и серьёзных изменений в него мы внести не сможем. В основном это будет дизайн и заполняемые данные. Элементы интерфейса изменить нельзя | ||
| - | * Согласовываем создание чата по разработке мобильного приложения. Чат создаётся в телеграмм, при необходимости его можно добавить в битрикс. В чат добавляются все ответственные лица со стороны заказчика, а также эксперт мобильной команды\\ | ||
| - | {{:agbis_pmp:pasted:20250206-130940.png}}\\ | ||
| - | \\ | ||
| - | \\ | ||
| - | |||
| - | ==== Анкета и первичные проверки ==== | ||
| - | Высылаем клиенту одну из анкет по разработке приложения(анкета для лайт/миддл/про) и просим её заполнить, хотя-бы частично. Делаем главный акцент на пункте с дизайном - его клиент должен обязательно заполнить и скинуть побольше своих материалов. | ||
| - | Ссылки на анкеты можно взять: | ||
| - | * В файле мобильников https://docs.google.com/spreadsheets/d/1Rznf2f7AIXRQ41Ea-j2Tea4FRM-eKMpW1HdWiacNWdU/edit?gid=985607214#gid=985607214 \\ | ||
| - | * В соответствующей теме внутри документации версии приложения\\ | ||
| - | Когда клиент присылает неполную анкету - не забываем докидывать изменения по ней в задачу и напоминаем про пункты, которые он нам должен\\ | ||
| - | \\ | ||
| - | \\ | ||
| - | Если клиент находится еще на запуске, то уточняем у отдела запуска сроки, когда у него будут готовы сообщения, хим-инфо и он будет, в целом, подготовлен для интеграции | ||
| - | \\ | ||
| - | Обязательно проверяем у клиента, как он отправляет сообщения. Для интеграции мобильного приложения необходимы СМС сообщения(в будущем, возможно, еще будет доступен Wazzap канал). Если у клиента они не подключены, то нужно обговорить этот вопрос с клиентом и начать подключение СМС. Глобально, варианта 2: | ||
| - | * Подключение сообщений от интегрированных с нами операторов. Этот вопрос относится к СОБРу если клиент уже активный либо к отделу внедрения, если клиент еще на внедрении. В случае с СОБРом мы создаём на них задачу и ждём подключения. В случае с отделом внедрения - просто ожидаем когда им подключат сообщения | ||
| - | * Подключение сообщений через SMSsender - вопрос курирует мобильная команда | ||
| - | \\ | ||
| - | \\ | ||
| - | Если клиент иностранный, то проверяем, есть ли у нас перевод для ПМП в его стране. Информацию о наличии перевода можно узнать у ответственного программиста. Если нет, то необходимо будет запросить файл для перевода у него и передать клиенту для заполнения | ||
| - | \\ | ||
| - | \\ | ||
| - | Проверяем сервер клиента если он не на нашем облаке - у него должен быть хороший интернет и достаточная производительность(чтобы приложение не сбоило) и круглосуточная доступность(чтобы приложение было доступно круглые сутки). Если сервер не удовлетворяет данным требованиям, то можно порекомендовать клиенту перейти на наше облако либо улучшить требуемые показатели сервера. Сервер с не круглосуточным режимом работы нельзя запускать с мобильным приложением т.к. это может повлечь к блокировкам со стороны маркетов и последствиям для нашего личного кабинета | ||
| - | \\ | ||
| - | \\ | ||
| - | |||
| - | ==== Проверка анкеты и создание дизайна==== | ||
| - | После того, как клиент выслал нам анкету её необходимо проверить и зафиксировать все моменты, которые он нам не предоставил, а также запрашивать и напоминать клиенту о них, периодически. Важно не перегружать клиента данными и не запрашивать у него всё сразу.(т.к. шанс, что вам сразу на всё ответят и сделают - небольшой) | ||
| - | \\ | ||
| - | \\ | ||
| - | Проверяем брендбук клиента в анкете и создаём подзачу из основной задачи на дизайнера. __**ОБЯЗАТЕЛЬНО**__ выставляем задачу с корректным названием ПМП. __Не путаем__ ПМП Базовый и ПМП Pro\\ | ||
| - | {{:agbis_pmp:pasted:20250206-155254.png?1000x1000}}\\ | ||
| - | Дизайнер, в среднем, готовит дизайн за 3-5 дней и высылает нам несколько вариантов по дизайну, которые нам необходимо согласовать с клиентом. Одобренный вариант скидываем дизайнеру и он подготовит проект для интеграции в приложение | ||
| - | \\ | ||
| - | \\ | ||
| - | Проверяем, что у клиент указал в оплатах в анкете и сверяемся с тем, что у него настроено в управлении хим-инфо | ||
| - | {{:agbis_pmp:pasted:20250206-160123.png?1000x1000}}\\ | ||
| - | Если у клиента не настроены никакие оплаты, а в анкете он указал необходимость подключения, то нам необходимо либо отправить клиента заключать договор с банком, с которыми они хотят осуществить интеграцию либо начать проработку новой интеграции(данный вопрос находится в ведении отдела Web), если в стране клиента еще нет подключенных интеграций с оплатами | ||
| - | \\ | ||
| - | \\ | ||
| - | ==== Настройка серверной части и заполнение данных по приёмным пунктам==== | ||
| - | Когда у нас готов и подтверждён клиентом дизайн и он выслал достаточное количество данных для сборки тестовой версии приложения, мы можем приступать к настройке сервера по данной инструкции https://doc.agb.is/internal/pmp_work | ||
| - | \\ | ||
| - | \\ | ||
| - | Первым делом необходимо обновить версию Агбис Химчистки до последней актуальной версии. Обновление нужно согласовать с клиентом | ||
| - | \\ | ||
| - | \\ | ||
| - | Параллельно необходимо передать клиенту информацию, о необходимости заполнения им данных по своим приёмным пунктам по этим инструкциям: | ||
| - | * https://youtu.be/yGARebJMSzQ - видеоматериал по настройке приёмных пунктов и центру управления хим-инфо | ||
| - | * https://doc.agb.is/work_himinfo - текстовая документация по настройке приёмных пунктов и центру управления хим-инфо | ||
| - | \\ | ||
| - | \\ | ||
| - | После заполнения данных сервера пишем это в задачу и сообщаем ответственному программисту о том, что можно собирать приложение | ||
| - | Чем больше данных заполнил клиент в анкете, тем лучше. Нужно стремиться к тому, чтобы он заполнил по максимуму перед выпуском тестовой версии, но | ||
| - | если он не заполнил даже эти данные, то смысла передавать приложение на сборку нет и нужно дождаться хотя-бы их: | ||
| - | * API ключ для карт | ||
| - | * Файл с переводами приложения на другие языки | ||
| - | * Название приложения, Юр. лицо, телефон химчистки | ||
| - | * Данные по доставке(исключая текст о доставке) - интервалы выездов, минимальный срок выезда | ||
| - | * Подтвержденный клиентом и выгруженный дизайнером проект дизайна приложения | ||
| - | * У клиента нет рабочих СМС сообщений | ||
| - | |||
| - | ==== Тестовая версия ==== | ||
| - | Ответственный программист собирает приложение и передаёт нам ссылку на скачивание после чего мы проводим его тестирование на android и ios. Для тестирования используется данный набор тест-кейсов https://docs.google.com/spreadsheets/d/1fGD4RMIVEegUgYGplC2FIUIcwKKLKA_SOCQdsh3LwIM/edit?gid=1378845214#gid=1378845214. В нём описаны не все возможные тестовые случаи, но этот набор является минимальным. При тестировании обращаемся самое большое внимание на следующие моменты: | ||
| - | * Любые точки где данные заполняются программистом - пользовательское соглашение, политики, тексты о доставке | ||
| - | * Любые точки, на которые клиент может влиять самостоятельно(доступность сайта, ссылок, соцсетей) | ||
| - | * Любые подозрительные моменты. Сразу сообщайте о них ответственному программисту. **__Не придерживайтесь__** принципа "если так сделали, значит так надо". Замеченная ошибка это вина программиста, незамеченная ошибка это вина тестировщика | ||
| - | \\ | ||
| - | \\ | ||
| - | ==== Клиентский тест==== | ||
| - | После проведения тестирования нашими силами, мы передаём приложение на тест клиенту. Он может тестировать его долго и дотошно, а не может вообще проигнорировать тестирование и дать добро на отправку в продакт. Мы должны исправлять ошибки, которые нашел клиент, в приложении, но при первых признаках того, что клиент будет просить глобально переделать дизайн или функционал сообщить ему, что приложение является **__типовым__** и крупные изменения в нём невозможны. | ||
| - | (Опционально) Если у клиента мусорные прайс-листы, то сообщаем, что ему необходимо будет почистить их, сняв галочки с ненужных позиций, а в идеале еще и залить картинки качественные | ||
| - | \\ | ||
| - | \\ | ||
| - | Фактические ошибки, обнаруженные клиентом передаются в виде задач ответственному программисту для решения. Что подходит под критерии задачи на исправление программисту по итогам клиентского теста: | ||
| - | * Клиент нашел фактическую ошибку, некорректное отображение и любой другой __**реальный баг**__ приложения | ||
| - | * Если клиенту не нравится текущее исполнение дизайна, то мы можем его переделать, но тут нужно знать меру. 1 раз переделать можно, но если клиент не может определиться, то ему нужно сообщить, что многократно переделывать дизайн мы не можем | ||
| - | * Если клиент хочет фактического изменения функционала и интерфейса, то любые данные изменения должны быть доведены до эксперта мобильной команды и разрешены им с проставлением задачи на программиста. Клиенту __можем обещать только то, что передадим информацию эксперту__ | ||
| - | \\ | ||
| - | \\ | ||
| - | ==== Обучение ==== | ||
| - | Когда клиент провёл первичное тестирование и перестал активно высылать нам ошибки и требования на доработку можно назначить с ним обучение. На обучение стоит выделять не менее 2-3 часов. Рекомендуется не объединять несколько тем в одном обучении т.к. клиент не успеет усвоить вопросы и время будет потрачено зря. После каждого обучение просим клиента сделать небольшое домашнее задание, например, после обучения по функционалу, пусть сделает 2-3 разных выезда/заказа из приложения и пообщается сам с собой в чате. После второго обучения пусть создаст и выгрузит тестовую акцию. После третьего обучения - сделает тестовую рассылку пушей(если он использует рассылки) | ||
| - | \\ | ||
| - | На обучение нужно передать клиенту 3(+1 дополнительная) глобальные темы | ||
| - | * Функционал приложения, создание заявок, общие возможности | ||
| - | * (опционально, если клиент не использовал ранее выезды) Работа с журналом выездов и бизнес процессы доставки с АП или без | ||
| - | * Выгрузка данных с сервера в приложение; корректировка прайс-листов, акций, складов | ||
| - | * Продвижение мобильного приложения, пуш-уведомления, польза пуш-рассылок | ||
| - | \\ | ||
| - | Обучение желательно проводить в Zoom с записью. По итогам запись сохраняется, а ссылка передаётся клиенту\ | ||
| - | \\ | ||
| - | Ниже приведён минимальный список необходимой документации, которую нужно порционно скидывать клиенту по итогам обучения: | ||
| - | \\ | ||
| - | \\ | ||
| - | Общая информация о приложении:\\ | ||
| - | https://www.youtube.com/watch?v=UTRj1ozTatY - оформление заявок из приложения\\ | ||
| - | https://www.youtube.com/watch?v=sfra1Mf4DSQ - передаваемые данные из приложения в химчистку\\ | ||
| - | https://doc.agb.is/pmp_discount - дисконтная карта в приложении\\ | ||
| - | https://doc.agb.is/pmp_notifications - настройка уведомлений о выездах\\ | ||
| - | |||
| - | Управление данными в приложении:\\ | ||
| - | https://youtu.be/yGARebJMSzQ - видеоматериал по настройке приёмных пунктов и центру управления хим-инфо\\ | ||
| - | https://doc.agb.is/work_himinfo - текстовая документация по настройке приёмных пунктов и центру управления хим-инфо\\ | ||
| - | https://doc.agb.is/promo_himinfo - выгрузка новостей и акций в приложение\\ | ||
| - | https://doc.agb.is/pmp_translation - перевод контента на другие языки\\ | ||
| - | https://doc.agb.is/picture - картинки для номенклатуры\\ | ||
| - | |||
| - | Продвижение приложения:\\ | ||
| - | https://doc.agb.is/pmp_lite_marketing - общие возможности по продвижению\\ | ||
| - | https://doc.agb.is/pmp_push - пуш уведомления\\ | ||
| - | |||
| - | Журнал выездов \\ | ||
| - | https://doc.agb.is/pmp_notifications | ||
| - | \\ | ||
| - | \\ | ||
| - | <надо сюда еще документации по выездам добавить когда будет> | ||
| - | \\ | ||
| - | \\ | ||
| - | ==== Подготовка к публикации ==== | ||
| - | После обучения мы добиваем все недостающие моменты и готовим приложение для публикации в маркетах. Перед публикацией мы должны удостовериться, что: | ||
| - | * Всё необходимое по анкете от клиента мы получили и внесли в приложение | ||
| - | * Все необходимые настройки(включая оплаты) выполнили либо определили, что они не нужны(например клиент отказался от отправки сообщений на Email) | ||
| - | * Закрыли все вопросы и все возражения от клиента | ||
| - | * Пофиксили все баги приложения, обнаруженные на этапе тестирования | ||
| - | \\ | ||
| - | \\ | ||
| - | Запрашиваем у бухгалтера, нет ли у клиента долгов по приложению и всё ли оплачено. Если есть долги, то оповещаем клиента о необходимости их закрыть | ||
| - | \\ | ||
| - | \\ | ||
| - | Передаём клиенту данный акт https://docs.google.com/document/d/1piGfGmyqweQw6ByC3_c7YyZcS79H0jOaqUZliAzJINQ/edit?tab=t.0 который ему необходимо подписать после чего пишем в теме и оповещаем ответственного программиста о том, что приложение можно публиковать | ||
| - | \\ | ||
| - | \\ | ||
| - | ==== Основная и повторная публикации ==== | ||
| - | Когда приложение опубликовано обязательно оповещаем клиента о данном факте. Передаём ему ссылки на маркеты, а также сообщаем, что в течении 30 дней от текущего дня у него есть право на бесплатный перевыпуск по требованию. Перевыпуск будет проведён если им, в процессе работы, будут обнаружены ошибки либо нужно будет внести небольшие корректировки в данные. Об этом он должен сообщить нам заранее. Если по истечения 1 месяца(либо увеличенного срока, по договорённости) клиент не предоставил список для доработки и повторной публикации, то повторная публикация не осуществляется. Об этом **__необходимо предупредить клиента заранее__** | ||
| - | \\ | ||
| - | \\ | ||
| - | Для повторной публикации не требуется актов и подтверждений - достаточно лишь согласия клиента в чате либо в голосе(если есть запись). После повторной публикации также оповещаем клиента и сообщаем ему, что приложение переопубликовано, а его техническая поддержка осуществляется в рамках договора сопровождения | ||
| - | \\ | ||
| - | \\ | ||
| - | На этом работы завершены. Вносим последние галочки в файлик https://docs.google.com/spreadsheets/d/1RkxW6-zNVmxplAd3BCyt_lfUTt7HLfPEGug0h2cQ0Ys/edit?usp=sharing и поздравляем себя | ||
| - | \\ | ||
| - | {{:agbis_pmp:pasted:20250207-132821.png?1000x1000}} | ||