Данная инструкция описывает общий процесс интеграции мобильного приложения в порядке от начала до конца. Последовательность действий не является строгой, но если стремиться к её поддержанию, то можно снизить риск провалов в скорости работы по нашей вине.
Отмечаем, хотя-бы кратко, все крупные процессы по интеграции приложения в данном файле https://docs.google.com/spreadsheets/d/1RkxW6-zNVmxplAd3BCyt_lfUTt7HLfPEGug0h2cQ0Ys/edit?usp=sharing. При большом количестве активных проектов он позволяет быстро вспомнить нужное и продолжить работу с клиентом

В общем чате проходит автоматическое оповещение о закрытой сделке по ПМП от product owner

В этот момент должна автоматически создастся задача на разработку приложения

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

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

• Описываем общую схему работы с ним. Нам нужно вкратце описать суть данной документации, чтобы клиент понимал, из чего будет состоять процесс разработки и интеграции приложения
• Интересуемся как они в целом, сейчас работают и для чего они хотят использовать приложение. Эти знания помогут нам понять, какие самые важные для клиента задачи будет решать приложение(например, если клиент хочет приложение, только чтобы подтверждать заказы и получать пуши, то перенапрягать его заказами из корзины и выездами сильно не стоит, а если он хочет, чтобы клиенты могли просматривать цены на свои услуги, то стоит заострить вопрос на том, что клиенту нужно будет залить картинки на свои услуги и почистить прайс-листы от мусорных позиций , также оптимизировать их количество)
• Подчёркиваем тот факт, что приложение является типовым и серьёзных изменений в него мы внести не сможем. В основном это будет дизайн и заполняемые данные. Элементы интерфейса изменить нельзя
• Согласовываем создание чата по разработке мобильного приложения. Чат создаётся в телеграмм, при необходимости его можно добавить в битрикс. В чат добавляются все ответственные лица со стороны заказчика, а также эксперт мобильной команды
  

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

• В файле мобильников https://docs.google.com/spreadsheets/d/1Rznf2f7AIXRQ41Ea-j2Tea4FRM-eKMpW1HdWiacNWdU/edit?gid=985607214#gid=985607214
  
• В соответствующей теме внутри документации версии приложения
  

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


Если клиент находится еще на запуске, то уточняем у отдела запуска сроки, когда у него будут готовы сообщения, хим-инфо и он будет, в целом, подготовлен для интеграции
Обязательно проверяем у клиента, как он отправляет сообщения. Для интеграции мобильного приложения необходимы СМС сообщения(в будущем, возможно, еще будет доступен Wazzap канал). Если у клиента они не подключены, то нужно обговорить этот вопрос с клиентом и начать подключение СМС. Глобально, варианта 2:

• Подключение сообщений от интегрированных с нами операторов. Этот вопрос относится к СОБРу если клиент уже активный либо к отделу внедрения, если клиент еще на внедрении. В случае с СОБРом мы создаём на них задачу и ждём подключения. В случае с отделом внедрения - просто ожидаем когда им подключат сообщения
• Подключение сообщений через SMSsender - вопрос курирует мобильная команда

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

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

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

Проверяем брендбук клиента в анкете и создаём подзачу из основной задачи на дизайнера. ОБЯЗАТЕЛЬНО выставляем задачу с корректным названием ПМП. Не путаем ПМП Базовый и ПМП Pro

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

Проверяем, что у клиент указал в оплатах в анкете и сверяемся с тем, что у него настроено в управлении хим-инфо
Если у клиента не настроены никакие оплаты, а в анкете он указал необходимость подключения, то нам необходимо либо отправить клиента заключать договор с банком, с которыми они хотят осуществить интеграцию либо начать проработку новой интеграции(данный вопрос находится в ведении отдела 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 и поздравляем себя