Хайди хо, Кайл!
Давайте обсудим достаточно спорный для бизнес-аналитика вопрос: насколько нужно шарить в разработке? Например, чтобы проанализировать и выбрать варианты взаимодействия со сторонними системами при проектировании фичи. Ведь разработчики априори лучше разбираются в средствах разработки — зачем привлекать любителя бизнес-аналитика?
В аутсорс-разработке часто появляются новые задачи, команды работают над разными проектами — иногда одновременно. Поэтому и вопрос выбора способа интеграции перед командой встаёт достаточно часто: по моему опыту — минимум раз в пару месяцев.
Под интеграцией со сторонними сервисами я подразумеваю использование API или SDK для увеличения функциональности сервиса, автоматизации процессов и решения задач бизнеса.
При разработке по методологии SCRUM ТЗ для фичи пишется с опережением разработки на один-два спринта. К моменту, когда разработчики берутся за декомпозицию фичи, уже должен быть готов дизайн, отражающий особенности SDK, описание интеграции и особенностей для продукта и бизнес-задачи. Безусловно, со спорными моментами помогут лиды. Но это не отменяет того, что верхнеуровневый анализ сторонних систем и выбор вариантов интеграции — ответственность и задача аналитика.
Меня зовут Диана Стацура, я специализируюсь на мобильной аналитике в Surf. На реальных кейсах расскажу, какие узкие моменты бывают при работе с сторонними сервисами, и поделюсь практиками, которые помогают мне и коллегам.
Зоны ответственности аналитика
Давайте всё-таки проговорим задачи аналитика на проекте и его роль в команде. Может, в зоны ответственности аналитика по умолчанию входит анализ SDK, проектирование интеграций и программирование программ, и я зря демагогию развела.
Я слежу за рынком вакансий, а ещё я — тот человек, который объяснял родителям, кем он работает. И могу сказать, что моя специальность не так четко определена, как, например, у разработчиков (хотя и у них много ответвлений), и включает в себя очень широкие понятия. Кто такой аналитик и какую роль в разработке продукта он выполняет, понимают не все. Даже иногда пытаются доказать, что аналитик на проекте не нужен (:poshel_ya_nafig:).
В разных проектах, командах и компаниях роли распределяются по-разному. Несмотря на то, что границы специальности «аналитик» не очень чёткие, аналитика на проекте присутствует всегда. Это понятие в нашем контексте включает:
бизнес-аналитику,
системную аналитику,
продуктовую аналитику. Если вам интересно больше узнать про продуктовый подход и продуктовую аналитику в нашей компании, мы пишем о них в Telegram-канале.
В больших и сложных проектах аналитика необходима: она помогает понять цели проекта и выстроить правильные процессы. Поэтому именно аналитик — тот специалист, который задает направление развития проекта.
Кроме базовых задач, которые прописаны в каждой вакансии на hh.ru, в зону ответственности аналитика на проекте входит:
работа с бэклогом,
анализ рынка на этапе старта проекта,
выбор средств разработки, решающих поставленную в контексте фичи задачу, и так далее.
В чём разница, когда интеграцию проектирует сам разработчик или за него это делает аналитик
При выборе вариантов интеграции возможны два пути развития: сразу отдать фичу на откуп разработчику или чтобы сначала её проработал аналитик.
Первый вариант: фичу отдают на откуп разработчику
Разработчик сам выбирает самый удобный и простой для себя способ реализации. Но:
Он не всегда ориентируется на удобство пользователя и цели заказчика.
Фича-то будет реализована, но задачи бизнеса не решит. Например, заказчик хочет заложить в проект дополнительную логику. Её предоставляют далеко не все SDK. Разработчик при выборе будет ориентироваться в первую очередь на удобство и стабильность — и это может привести к тому, что он учтёт не всю логику, которую ожидает бизнес. В итоге заказчик будет недоволен: его требования не реализовали.
Разработчики разных платформ могут изначально выбрать разные способы интеграции: например, команда Android выберет SDK, а команда iOS решит использовать API. Или все они выберут SDK — но разные. В этом случае всё равно может потребоваться мнение третьей стороны, чтобы прийти к компромиссу.
Второй вариант: фичу сначала прорабатывает аналитик
Аналитик проанализирует требования заказчика и пользователя. Это даст:
Ориентированность на нужный результат: даже если разработчику будет что-то неудобно, проскочить со словами «Можно сделать быстрее и проще, убрав эту логику» или «Ну неее, это невозможно» у него уже не выйдет. В этом месте в меня летят помидоры от разработчиков:(
Ещё один уровень качества: минимум три человека будут работать над фичей. Это повысит вероятность, что все кейсы будут учтены.
Выбор единого решения, одновременно удобного обеим платформам. А вместе с тем — и единый вариант реализации.
Как выбирать способ интеграции со сторонней системой в зависимости от фичи
Давайте ещё раз вспомним, какие варианты интеграции есть:
Взаимодействие с системой через API.
Использование SDK.
Мобильное приложение обращается к бэку, который уже взаимодействует с системой (что в целом можно приравнять к первому варианту).
Для примера я выбрала три фичи:
электронные чеки,
пуш-уведомления,
чат.
У них разный уровень сложности, и при разработке я столкнулась с разными бизнес-процессами (читай, проблемами:)).
Чтобы выбрать вариант реализации, нужно точно определить, какую конкретно бизнес-задачу хочет решить заказчик с помощью фичи. Для этого аналитик обсуждает с заказчиком бизнес-требования и на основе этого приходит к разработчикам с описанием требуемой функциональности.
Анализ интеграции со сторонними системами во многом зависит от их специфики. Нет четкого гайдлайна, как описывать интеграцию, но есть несколько общих советов:
Чётко определять бизнес-цель и отталкиваться от этого в выборе варианта реализации.
Учитывать требования к системе — то есть достаточность предоставляемой функциональности. Например, если речь идёт о разделении пушей на каналы.
Советоваться с командой на всех этапах анализа: от выбора SDK до путей реализации. Например, как реализовывать функциональность: кастомно или используя методы SDK.
Уточнять у заказчика и команды, требуется ли взаимодействие с сервером и какая часть функциональности будет вынесена на фронт, а какая — на бэк.
Учитывать опыт других проектов и команд. Звучит как «делайте хорошо, а плохо не делайте», но это действительно полезный совет. Например, мы делимся проектным опытом внутри компании и опираемся на знания коллег, которые уже реализовывали аналогичные фичи.
Пример 1. Электронные чеки
Этот кейс будет сниться мне в кошмарах — мой любимый. Фича оказалась сложной и с точки зрения аналитики, и с точки зрения разработки. Требовалось совместно с разработчиками проработать много условий и найти лучший вариант реализации.
Одна из самых сложных задач — верно определить условия взаимодействия со сторонней системой, не взаимодействуя с ней напрямую. Вся передача данных реализовывалась через бэк.
Давайте разбираться на примерах.
Бизнес-задача. Реализовать в мобильном приложении функциональность подключения электронных чеков, чтобы пользователь мог выбрать электронный чек вместо бумажного.
Взаимодействие с платформой управления программами лояльности, реализующей подписку на электронные чеки, делали через сервер. На первый взгляд хорошо: часть логики берет на себя бэк, а нам — меньше работы. В реальности это была работа «с закрытыми глазами», потому что все требования к интеграции приходили порционно со слов команды бэка.
Достаточно очевидно, что для подключения электронных чеков требуется передать электронную почту в эндпоинте на подключение, а в ответе на запрос получить HTTP 200 OK.
Несколько подводных камней:
В системе у пользователя может быть только одна привязанная электронная почта. Именно на неё будут приходить электронные чеки.
Если у пользователя уже есть привязанная электронная почта, другую указать он не может.
Если у приложения общий бэк с сайтом, нужно прослушивать статус подключения: пользователь имеет несколько точек, откуда он может включить или выключить подключение к электронным чекам.
Электронные чеки может подключить только пользователь с подключённой картой лояльности.
Должна быть предусмотрена проверка на наличие карты лояльности.
Если карты лояльности нет, нужно вести пользователя по флоу подключения новой карты лояльности.
Чтобы определить эти бизнес-требования, сначала нужно проанализировать принцип работы платформы и взаимодействие «мобильное приложение — сервер — сторонняя платформа». Этот анализ поможет понять, какую информацию мобильное приложение должно передать и откуда её можно взять.
Для подключения электронных чеков нужно построить логику:
Проверки наличия карты лояльности для определения пользователя в системе, предоставляющей возможность подписки на электронные чеки.
Определения способа получения электронной почты, которая будет использоваться для привязки чеков.
Последующей передачи номера карты лояльности и электронной почты напрямую платформе или на сервер, который передаст его платформе.
Мини-кейс внутри кейса
Теперь — самый сок. Как я уже говорила, со стороны мобильного приложения мы не взаимодействовали напрямую с системой лояльности Лоймакс: все данные проксировал сервер.
В итоге на демо мы узнали, что электронную почту, передаваемую сторонней системе, нужно подтверждать. Чтобы учесть это дополнительное требование, пришлось перерабатывать и без того сложную логику и двигать релиз на две недели, чтобы добить фичу.
Что мы могли сделать, чтобы избежать этого? Смотреть шире, провести дополнительный анализ логики взаимодействия с системой, и не доверяться полностью бэку.
Пример 2. Пуш-уведомления
На этом примере детально разберём, что влияет на выбор SDK.
Пуш-уведомления — короткий текст, всплывающий на экране девайса пользователя. Сообщает важную информацию: старт акции, изменение статуса заказа, уведомление об операции по счёту и так далее.
Чтобы составить требования к реализации, важно понять, нужны ли:
Разделение на пуш-каналы — они определяют, какой части пользователей будет приходить уведомление. Это инструмент сегментирования аудитории для рассылок и настройки транзакционных пуш-уведомлений.
Настройка специальных предложений для пользователей.
Возможность выключить пуши в настройках приложения. Спойлер: она очень нужна! Иначе приложение навязчивое и совсем не юзерфрендли — такое надо взашей гнать с рынка :ъуъ:
При проектировании фичи изначально мы планировали использовать SDK, предложенное заказчиком. При анализе документации всё выглядело так, как будто вся необходимая функциональность в это SDK заложена (слова не мужа, но мальчика).
Признаюсь честно, это был мой первый опыт анализа SDK и проектирования фичи с его использованием: я допустила много ошибок.
Читала в основном документацию, но не смотрела детально на предоставляемые функции.
Проектировала фичу и писала ТЗ, не советуясь с разработчиками.
Сначала погрузилась в интеграцию с SDK, а уже потом начала разбираться в функциональности: смотрела на реализацию недостаточно широко.
Команда при этом также недостаточно глубоко погрузилась в фичу и не обратила внимание на детали в реализации. Оказалось:
Реализация части функциональности предвещала много говнокода и сложности в тестировании. Например, SDK не давал возможности полной отвязки пушей.
Менеджеры со стороны SDK не отвечали на наши вопросы несколько недель (чтоб я так жила…).
В итоге мы отказались от этого SDK, хотя большая часть работы уже была сделана. Конечно, при выборе альтернативного SDK мы уже не допустили предыдущих ошибок, а наделали новых (шутка).
На основе субъективного опыта я выработала первичные критерии, которые помогут отсеять неудобные SDK. У хорошей SDK:
Есть подробная документация.
Понятная интеграция.
Понятные методы: например, описание параметров, определяющих разделение пушей на каналы.
Менеджеры со стороны платформы, отвечают быстро (не по 2–3 дня) и понятно, а также дают доступ к личному кабинету и помогают его настроить.
На этом этапе отсеивается большая часть SDK. Дальше нужен более глубокий анализ и, конечно, согласование с командой.
Например, при выборе альтернативной SDK для реализации пушей мы учитывали дополнительно:
Детальность описания используемых методов.
Удобство личного кабинета.
Возможности тестирования пушей.
Возможности настроек пушей в приложении:
Отключение пушей из мобильного приложения.
Включение и выключение части уведомлений (то есть привязку и отвязку отдельных каналов).
Адекватность и скорость ответа менеджеров: без их участия, как минимум, не получится настроить личный кабинет.
Пример 3. Чат в приложении
Этот пример показывает, как важно собрать бизнес-требования. Это поможет определить средства реализации и объём работ с учётом требований к логике.
Бизнес-задача заказчика: чтобы пользователь в любой момент мог связаться с поддержкой, нужен чат для e-commerce приложения.
Если для банковского приложения чат с поддержкой — must have и в него стоит вложиться, то для e-commerce кастомный чат с поддержкой может быть неоправданно дорогим украшательством.
Едва ли пользователь захочет моментально связаться с поддержкой приложения, если не смог оформить заказ на новый свитшот или мячик для собаки. Вероятнее всего, чат нужен, чтобы показать пользователю клиентоориентированность: «Тебе помогут, если будут проблемы с заказом». Функциональность чата и срочность ответа в таком случае — не первый приоритет: заказчик вряд ли захочет переплачивать за кастом.
Если клиент хочет недорогой чат, есть три пути реализации:
SDK,
стороннее API,
редирект на чаты в мессенджерах.
Заказчик изначально хотел делать чат через SDK. Мы проанализировали варианты и обнаружили проблемы:
Поддержка игнорировала вопросы и не отвечала неделями.
Непонятная интеграция и запутанная документация.
Неудобное API. Например, в SDK, которое мы рассматривали для реализации чата, не было отдельного эндпоинта для получения списка чатов. Вместо этого нужно было вызывать список тикетов и фильтровать их по user_id (знаю, непонятно — нам тоже).
Плохой код и большая вероятность крашей (и я не про симпатичных чечиков, с которыми вы случайно встречаетесь взглядом на улице и понимаете, что это ваша судьба).
Изначально команда хотела просто найти другой SDK, но… оказалось, что найти удобное SDK с хорошим кодом без крашей и с быстрой или хотя бы просто работающей поддержкой, достаточно сложно.
Поэтому, исходя из бизнес-целей, сроков, стоимости и возможностей реализации мы решили реализовать редирект в мессенджеры. Это сократило трудозатраты команды и сроки реализации фичи.
Аналитик может обнаружить часть проблем, если проанализирует документацию или обсудит возможности реализации с менеджерами системы. Однако часть проблем может оказаться вне его поля зрения — как минимум из-за того, что он не смотрит в код. Например, в этом кейсе на плохой код и большую возможность крашей обратил внимание лид.
Поэтому очень важно подключать разработчиков и спрашивать их мнение на всех этапах анализа SDK. Ведь может оказаться, что вы пытаетесь изобрести велосипед, причем за деньги заказчика (много денег). Иногда самый простой вариант реализации подходит лучше всего.
Написание ТЗ
С выбором средств разработки разобрались. Теперь нужно определиться с тем, что должно быть отражено в ТЗ.
Если документация SDK или описание стороннего API — это общая инструкция, то ТЗ — это что конкретно надо сделать конкретно для решения задачи. Аналитик должен максимально конкретно описать задачу разработчикам, чтобы реализация совпадала с ожиданиями.
Основные пункты, которые влияют на реализацию фичи:
Какие методы SDK или стороннего API использовать для интеграции.
Какие параметры передавать.
Нужно ли генерировать ключи для подключения (к SDK).
Как получить предоставляемую платформой информацию для отображения в приложении.
Добавить ссылки на более подробное описание (например, используемых методов или генерации ключей), если там есть более исчерпывающая информация, которую не стоит переносить в ТЗ.
Готово, вы великолепны.
В случае с пушами, например, необходимо описать:
генерацию ключей.
подключение к самой системе,
определение варианта отправки событий: через сервер или с помощью SDK,
разделение на каналы,
data.payload.
На примере реальных кейсов я хотела показать зону ответственности аналитика и насколько он должен быть погружен в проект и в разработку.
Аналитику не обязательно нужно лезть под капот SDK и анализировать код. Важно внимательно подходить к выбору средств разработки и учитывать разные факторы. Для этого достаточно использовать стандартные навыки:
умение коммуницировать с командой и заказчиком,
понимание технической документации,
критический анализ разных вариантов реализации,
понимание ценностей продукта и бизнес-логики.
Спасибо за то, что дочитали до этого момента и до новых статей. Всем кискам пис! :peepocat:
Кейсы и лучшие практики в области системной и бизнес-аналитики, новости, вакансии и стажировки Surf — в телеграм-канале Surf BA Team. Присоединяйтесь!
