3 помилки в інтеграціях і 4 поради РМ-ам

3 помилки в інтеграціях і 4 поради РМ-ам

20 September 2023

  • Автор: Олександр Кононенко

  • Складність: норм

  • Час: 8 хв

Інтеграція із зовнішніми системами (сторонніми додатками) часто стає «паличкою-виручалочкою» під час розробки продукту. Такий підхід прискорює час і економить бюджет, якщо створення власного рішення дорожче. Без інтеграції не обійтися і коли необхідно підключити сторонній застосунок для виконання вимог законодавства, наприклад, у зарегульованих нішах.  

А ще, інтеграція із зовнішніми системами – це своєрідний челендж. Комунікація, документація, технічна частина – ніколи не знаєш, що може піти не так. У статті зібрали три яскраві приклади.

Кейс 1. Відмінне спілкування – невдалий запуск

Створювали застосунок для користувачів пристроїв Huawei. Щоб його повноцінно запустити, потрібна була інтеграція з AppGallery.

Вийшли на зв’язок із менеджерами AppGallery, пояснили їм ситуацію. Їхні технічні фахівці завантажили з Play Market наш застосунок і зробили реверс-інжиніринг. Потім надіслали нам список того, що потрібно змінити, і детальну інструкцію. Також був зідзвон AppGallery і наших розробників, на якому обговорили деталі. 

Приблизно за чотири тижні (за планом було три) було внесено всі необхідні зміни та застосунок відправили на модерацію. З першого разу нас не пропустив бот. Довго шукали причину, а вона виявилася в першому екрані. На ньому був список країн, де Гонконг ми написали окремо від Китаю, а за правилами AppGallery мали вказати як регіон Піднебесної.

У підсумку технічні фахівці AppGallery порадили просто додати фразу «країни і регіони». Після внесення змін застосунок пропустили, але ми втратили ще тиждень і зірвали заплановані терміни запуску.

За результатами можемо сказати, що технічний етап інтеграції ми пройшли «на ура» завдяки хорошій комунікації з фахівцями AppGallery. А ось запуск застосунку «пробуксували» через незнання нюансу з формальним визначенням Гонконгу на платформі. Завжди потрібно уточнювати подібні моменти перед стартом інтеграції.

Кейс 2. Хороша готова бібліотека, якби не один нюанс

Проводили інтеграцію застосунку з Google Faces, щоб була можливість змінювати обличчя, а точніше форму брів, в AR-додатку.

Фахівці в команді затримували технічну частину на 3 тижні, оскільки планували використовувати вже готові бібліотеки. Коли ж почали процес інтеграції, виявилося, що на той момент Google Faces не вміла розпізнавати ту ділянку обличчя, яка потрібна для застосунку (форму брів змінити так і не вдалося). У результаті терміни затягнули приблизно вчетверо, клієнт був страшенно незадоволений, а проєкт загалом збитковий.

Помилки припустилися на етапі проєктування. Ми не до кінця вивчили технічні можливості Google Faces, що і призвело до неприємних наслідків. В інтеграції із зовнішніми системами будь-яка деталь може зіграти фатальну роль, тому потрібно уважно все перевіряти ще на етапі вибору стороннього рішення. Наприклад, можна взяти готову бібліотеку, написати шматочок коду й одразу перевірити, чи все ОК.

Кейс 3. Не врахували ризик, втратили прибуток

Клієнт поставив завдання з інтеграції регіонального банкінг-сервісу.

З технічної точки зору проблем не було, але в якийсь момент банк підняв суму комісії за транзакцію. Що робити? На той момент на тому регіональному ринку було ще два гравці, з якими можна було провести інтеграцію. У підсумку так і зробили, але зайняло це приблизно місяць, протягом якого ми пропрацювали майже в мінус через низьку маржинальність бізнесу. Приціл був на обслуговуванні великої кількості людей, а через підйом комісії банком «з’їдався» майже весь прибуток.

Ми спочатку не врахували ризик, пов’язаний із цінами на послуги банку. У підсумку втратили місяць і відчутну суму грошей. Слід пам’ятати, що під час інтеграції зовнішньої системи багато речей неможливо контролювати. Тому ще на моменті проєктування важливо продумувати всі можливі ризики і план реагування на них.

Словник термінів для IT-менеджерів для вдалого спілкування з клієнтом

Розуміння та правильне використання спеціалізованих термінів не лише спрощує комунікацію, а й сприяє формуванню довіри з боку клієнта. Ось деякі з ключових термінів, пов’язаних з API, які кожен IT-менеджер має знати:

  • API (Application Programming Interface) – Інтерфейс програмування додатків, який дає змогу різним програмам взаємодіяти одна з одною. Це свого роду «міст» між вашим додатком і зовнішнім сервісом, що дає змогу обмінюватися даними.
  • Endpoint – Кінцева точка API, по суті адреса, за якою ваш застосунок може запитувати або надсилати дані. Кожен endpoint виконує певну функцію в межах API.
  • JSON (JavaScript Object Notation) – Легкий формат обміну даними, що використовується для серіалізації структурованих даних. Часто використовується в API для форматування повідомлень, що надсилаються та отримуються від сервера.
  • REST (Representational State Transfer) – Архітектурний стиль розроблення веб-сервісів, який використовує стандартні HTTP-запити (GET, POST, PUT, DELETE) для спілкування. RESTful API – це API, який слідує цим принципам.
  • Authentication and Authorization – Аутентифікація та авторизація. Ці процеси використовуються для верифікації користувачів і надання доступу до певних функцій API. Часто це робиться з використанням токенів безпеки.
  • OAuth – Стандартний протокол авторизації, який дає змогу користувачам надавати стороннім додаткам доступ до своїх захищених ресурсів без необхідності розкривати свої облікові дані.
  • SOAP (Simple Object Access Protocol) – Протокол обміну структурованими повідомленнями у веб-сервісах, що використовує XML. Часто застосовується в корпоративних і фінансових додатках.
  • SDK (Software Development Kit) – Набір інструментів для розробників, який дає змогу створювати додатки для конкретної платформи або операційної системи.
  • Webhook – Метод зворотного виклику HTTP для надання додаткам можливості отримувати повідомлення про події в реальному часі.
  • XML (eXtensible Markup Language) – Мова розмітки, яка використовується для кодування документів у форматі, який і читається людиною, і легко обробляється машиною.
  • Rate Limiting – Обмеження на кількість запитів, які користувач або застосунок може надіслати до API за певний період часу.
  • Latency – Затримка між надсиланням запиту та отриманням відповіді, важливий показник продуктивності API.
  • API Gateway – Керуючий шар, який забезпечує централізований вхід у систему, керуючи трафіком, авторизацією, моніторингом та іншими аспектами API.
  • Microservices – Підхід до розроблення програмного забезпечення, за якого додаток будується як набір дрібних, незалежних сервісів.
  • CRUD (Create, Read, Update, Delete) – Чотири основні операції, які можна виконувати з даними в базах даних і через API.

Розуміння цих термінів та їхнє правильне використання може значно поліпшити взаєморозуміння між ІТ-менеджерами та їхніми клієнтами, а також допомогти в ефективнішій комунікації з командою розробників.

Цей список термінів є лише початковою точкою у величезному світі IT-комунікацій. Щоб справді говорити однією мовою з розробниками, впевнено спілкуватися з клієнтами та доносити їм усі переваги й технічні аспекти проєкту, необхідно глибше занурюватися в тему. Курс TechMind від IAMPM надає всебічне навчання, що дає змогу IT-менеджерам опанувати необхідні знання та навички для ефективної взаємодії у сфері розробки та інтеграції. Це ваш шанс стати мостом між технічними фахівцями та клієнтами, приносячи максимальну цінність у кожен проєкт.

3 помилки в інтеграціях і 4 поради РМ-ам

9 помилок інтеграції API та їх вирішення

Розгляньмо 9 найпоширеніших помилок, що виникають під час інтеграції API, і запропонуємо ефективні рішення для їх усунення. Розуміння цих помилок та їхніх наслідків допоможе вам мінімізувати ризики та підвищити успішність інтеграційних проєктів. 

Неправильне використання API

Неправильне використання API може відбуватися, коли розробники не повністю обізнані про функції та обмеження API. Це може призвести до неправильного надсилання запитів, неправильного опрацювання даних або неправильного використання ресурсів API, що зі свого боку може призвести до збоїв у роботі застосунку, витоку даних і погіршення користувацького досвіду.

Рішення:

  • Перед початком інтеграції ретельно вивчіть документацію API. Розуміння всіх функцій і обмежень API допоможе уникнути багатьох помилок.
  • Забезпечте навчання і технічну підтримку для вашої команди розробників. Регулярно проводьте тренінги та семінари для оновлення знань про останні зміни в API.
  • Проводьте комплексне тестування. Перед тим, як інтегрувати API в продуктивне середовище, переконайтеся, що він був ретельно протестований в умовах, максимально наближених до реальних.

Недостатнє тестування

Недостатнє тестування інтеграції може призвести до непередбачених проблем після запуску, таких як збої в роботі, проблеми з продуктивністю або безпекою даних. Це особливо критично, коли інтеграція впливає на ключові бізнес-процеси.

Рішення:

  • Розробіть і впровадьте ретельний план тестування. Включіть до нього різні сценарії використання, перевірку на відповідність вимогам безпеки, і тестування навантаження.
  • Використовуйте автоматизовані інструменти тестування для забезпечення постійної та ефективної перевірки.
  • Залучіть кінцевих користувачів до процесу тестування. Їхній зворотний зв’язок може бути цінним для виявлення проблем, які не були помічені під час внутрішніх тестів.

Невраховані зміни в API

API постійно розвиваються, і зміни в них можуть вплинути на інтегровані системи. Невраховані оновлення API можуть призвести до збоїв або втрати функціональності.

Рішення:

  • Підпишіться на оновлення від провайдера API. Це дасть вам змогу бути в курсі будь-яких змін.
  • Розробіть стратегію управління версіями та плани на випадок екстрених оновлень.
  • Регулярно проводьте ревізію використовуваних API та їхню відповідність поточним бізнес-потребам і технологічним стандартам.

Невідповідність специфікаціям API

Часто виникає, коли розробники не повністю дотримуються технічних вимог або принципів роботи API. Це може призвести до неправильного обміну даними, збоїв у роботі застосунку або навіть до порушень безпеки.

Рішення:

  • Уважно дотримуйтесь усіх специфікацій і рекомендацій, наданих провайдером API.
  • Переконайтеся, що ваша команда розробників має достатній рівень знань і досвіду для роботи з конкретним API.
  • Регулярно проводьте рев’ю коду і технічні аудити, щоб гарантувати відповідність специфікаціям.

Проблеми з продуктивністю

Інтеграція із зовнішніми API може призвести до проблем із продуктивністю, особливо якщо API повільно відповідає на запити або генерує великий обсяг даних. Це може негативно позначитися на швидкості роботи програми та користувацькому досвіді.

Рішення:

  • Оптимізуйте запити до API, щоб мінімізувати їхню кількість і обсяг переданих даних.
  • Використовуйте кешування даних, де це можливо, для зменшення навантаження на API.
  • Розгляньте можливість використання асинхронних запитів для поліпшення продуктивності.

Неадекватне управління залежностями

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

Рішення:

  • Впровадьте сувору систему управління залежностями, яка відстежує і контролює всі використовувані бібліотеки та фреймворки.
  • Регулярно оновлюйте залежності та ретельно тестуйте систему після кожного оновлення, щоб забезпечити сумісність і стабільність.
  • Використовуйте інструменти для автоматизації управління залежностями та відстеження вразливостей.

Недостатня масштабованість

Ігнорування потенційного зростання і масштабування системи під час інтеграції API може призвести до проблем із продуктивністю і стійкістю при збільшенні навантаження.

Рішення:

  • Під час проектування системи передбачте можливість масштабування, особливо в частині інтеграції з API.
  • Регулярно проводьте навантажувальне тестування й аналізуйте показники продуктивності для визначення необхідності масштабування.
  • Розгляньте використання хмарних рішень і автоматизованих інструментів для гнучкого масштабування.

Недооцінка важливості користувацького досвіду

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

Рішення:

  • Приділяйте увагу дизайну користувацького інтерфейсу і зручності взаємодії з інтегрованими функціями.
  • Проводьте тестування за участю реальних користувачів для оцінки зручності та інтуїтивності інтерфейсу.
  • Збирайте й аналізуйте відгуки користувачів для постійного поліпшення користувацького досвіду.

Неправильне опрацювання винятків і помилок

Неадекватне опрацювання помилок під час інтеграції з API може призвести до збоїв у застосунку та плутанини серед користувачів.

Рішення:

  • Розробіть чітку систему обробки винятків і помилок API.
  • Переконайтеся, що застосунок може коректно реагувати на різні види помилок, наприклад, тимчасову недоступність сервісу.
  • Передбачте інформативні повідомлення про помилки для користувачів, щоб полегшити розуміння проблем, що виникли.

Курс ArchiTech від IAMPM допомагає учасникам розібратися з ключовими аспектами API інтеграцій. Він охоплює теми, пов’язані з вибором правильних архітектурних рішень для інтеграції, управлінням технічними командами, і поглибленим розумінням технічних особливостей проєктів. Участь у курсі дасть вам знання, необхідні для ефективного управління інтеграціями, розуміння технічних деталей і прийняття обґрунтованих рішень у проєктах, пов’язаних з API.

3 помилки в інтеграціях і 4 поради РМ-ам

4 поради, щоб інтеграція пройшла добре

  1. Ретельно вивчіть документацію. Перед підключенням стороннього рішення уважно вивчіть усю інформацію про нього, навіть між рядків (особливо технічну частину). Поставтеся до неї так, ніби це юридичний договір, де невірно прописана або зрозуміла фраза може серйозно «відгукнутися» в результаті. Аналогічно робіть і з документацією з вашого боку. Вона має бути зрозумілою і максимально повною – це серйозно спрощує роботу над інтеграцією будь-якого продукту.
  2. Заздалегідь продумайте менеджмент доступів. Безлад у цьому питанні може призвести не тільки до незручності роботи команди, а й до проблем у безпеці проєкту. У будь-який момент ваш проєкт може покинути хтось із команди або зміниться відповідальний з боку клієнта/партнера. Отже можливий витік інформації. Тому не роздавайте всім підряд доступи, не зберігайте їх у листуванні й обов’язково продумуйте варіант швидкого вимкнення тих, хто вийшов із процесу. Для цього у вас має бути не тільки доступ до всіх акаунтів, а й контроль за ними. Для зручності можете використовувати сторонні сервіси на кшталт Vault і подібні.
  3. Правильно розрахуйте вартість. Перш ніж зважитися на інтеграцію зовнішньої системи, розпишіть усі плюси і мінуси. Є ймовірність, що після розрахунку ви почнете розробляти своє рішення. У довгостроковій перспективі власне рішення може бути вигідним не тільки за грошима, а й в інших аспектах: підтримці, можливостях апгрейда, безпеці.
  4. Перевірте стабільність сервісу. Переконайтеся в працездатності стороннього рішення (наприклад, через Statuspage). Якщо щось не так, але альтернативи немає, під час інтеграції продумайте резервні варіанти і failover-механізми.

Зовнішня система допомагає заощадити гроші або швидко запустити продукт. А швидкість в IT відіграє вирішальну роль. Що швидше користувачі отримають можливість взаємодіяти з продуктом, то вища ймовірність успіху. Повністю позбутися підключення сторонніх рішень навряд чи вийде. Дата-провайдери, mls, якісь специфічні бази даних – без інтеграції з ними складно уявити розробку будь-якого продукту. Головне, робити все грамотно і систематично поглиблювати свою технічну експертизу.

Олександр Кононенко

Копірайтер-маркетолог з технічною освітою, досвідом у продажах та маркетингу. Завжди в пошуках найкращих рішень для досягнення поставленої мети. Вважає, що створення текстів — це симбіоз мистецтва та науки.