Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Rzeczywistość wsparcia technicznego na przykładzie SDK

Arkadiusz Pachucy Senior Software Developer
Sprawdź, jak rozwiązać problemy związane ze złym podejściem do wsparcia technicznego, na podstawie doświadczeń z projektów.
Rzeczywistość wsparcia technicznego na przykładzie SDK

W poprzedniej części cyklu artykułów opisałem swoje doświadczenia związane z rozwijaniem oraz utrzymaniem istniejącego rozwiązania. W drugiej części cyklu chciałbym się skupić na wsparciu klientów oraz współpracy między działami.

Dlaczego piszę właśnie o wsparciu? Rozwój produktu jest bardzo ważny. Pozwala przykuć uwagę potencjalnych klientów. „Support” odpowiada również za utrzymanie tych już zdobytych. Każdy z nich powinien być szczęśliwy z wykorzystania naszego SDK. Jak można to osiągnąć? Integrując się z nim bardzo szybko oraz rozwiązując wszystkie zaistniałe wyzwania.

Historię rozpoczęliśmy od jednego, wewnętrznego klienta. Nikt 3 lata temu nie przewidział, że biblioteka może odnieść aż tak spektakularny sukces. Dzięki temu pomagaliśmy już niejednej znanej marce na rynku środkowoeuropejskim.


Integracja

Zerknijmy teraz oczami klienta na produkt. Jak należy zintegrować się z takim rozwiązaniem?

Integracja z biblioteką jest bardzo prostolinijna. Biblioteka jest częścią większej całości, która początkowo była traktowana tylko jako mniejsza odnoga procesu płatności. Klient, który chce z niej skorzystać, powinien mieć postawiony własny backend, na którym przechowuje się informacje odnośnie statusu transakcji. Bardzo często w takich przypadkach klient zintegrował się już z webowym rozwiązaniem umożliwiającym płatności, a aplikacja mobilna ma być tylko rozszerzeniem już istniejącej działalności, dając użytkownikom końcowym lepsze doświadczenia. Jest to prosty proces:

  • Dodaj bibliotekę do swojej aplikacji, poprzez dodanie do konfiguracji nowego repozytorium
  • Dodaj nowy widok, który odpowiada za wybór metody płatności
  • Stwórz plik konfiguracyjny dla biblioteki, który pozwala na wybór wspieranych języków oraz środowiska, z którym będzie się komunikowało
  • Stwórz przycisk „płacę” oraz przekaż do obiektu związanego z płatnością zawartość koszyka
  • Stwórz token oAuthowy, który zostanie przekazany do biblioteki za pomocą ‘serwisu’


Wiemy już, co należy zrobić, jednak czasem system klienta jest nieco bardziej skomplikowany, przez co integracja z biblioteką oraz całym ekosystemem płatności stają się dużym wyzwaniem. Warto wtedy podpytać, skontaktować się z supportowym SDK. Jak wiadomo - każdy klient tworzy i wdraża unikalny biznes, a co za tym idzie, podstawowe funkcje oferowane przez bibliotekę mogą nie wystarczyć.


Jaki jest idealny klient?

Idealny klient z punktu widzenia zespołu to taki, który nie zgłasza problemów :) Pisząc nieco bardziej poważnie, idealna osoba, to taka, która jest w stanie w przypadku problemu:

  • Zapoznać się z dokumentacją
  • Skonfigurować wszystkie niezbędne elementy do przeprowadzenia transakcji na środowisku testowym
  • Opisać problem
  • Podać kroki reprodukcji
  • Podać wersję systemu operacyjnego oraz wersję biblioteki, na której reprodukowany jest problem
  • Zapoznać się z dostępnym FAQ
  • Posiada wiedzę domenową - jak działa system płatności
  • Zapoznać się z aplikacją demo, która może uzupełnić/potwierdzić wiedzę nabytą z dokumentacją
  • Być osobą kontaktową - w celu szybkiego wyjaśnienia sprawy


Mamy również przyjemność z klientami, którzy proponują nam wdrożenie nowej funkcjonalności, która akurat mogłaby się im przydać. W tym przypadku klient powinien mieć świadomość, że kontaktuje się on z zespołem programistów oraz testerów, który powie mu, czy da się stworzyć daną funkcjonalność oraz ile to może potrwać. Decyzja o tym, czy zostanie zaimplementowana dana funkcjonalność, nie należy do nas, tylko do biznesu, dlatego w takich przypadkach odsyłamy go do bardziej odpowiednich ludzi.


Rzeczywisty klient

Cechy klienta, z którymi spotykamy się najczęściej:

Brak zapoznania się z dokumentacją lub tylko częściowe

Ze względów bezpieczeństwa, od pewnego czasu token oAuthowy dla biblioteki mobilnej powstaje inaczej, niż dla części webowej. Okazało się to brzemienne w skutkach, gdyż w pewnym czasie na 20 zgłoszonych problemów, 14 dotyczyło właśnie tego problemu i uwypukliło nam to prostą rzeczywistość: nikt nie lubi czytać dokumentacji, nieważne jak byłaby ona napisana. Zwłaszcza jeżeli powinieneś się zapoznać z dokumentacją zarówno dla aplikacji mobilnej, jak i później backendowej.

W dokumentacji backendowej jest jeden rozdział opisujący tworzenie tokena dla części webowej oraz osobny podrozdział informującym o tym, jak zintegrować się poprawnie z biblioteką mobilną. Obie metody tworzenia oAutha różnią się tylko jednym parametrem. Jednak zachowanie biblioteki jest zupełnie inne dla każdego z tych tokenów. Zdarzały się również przypadki „pomieszania” obu - powstawała „hybryda” poprawnego tokena.

W przypadku, kiedy przekazano tokena webowego, najczęściej biblioteka przechodzi w stan connection error - co skutecznie nie pozwalało na poprawne działanie biblioteki. W końcu, jeżeli widzisz na ekranie błąd, a nie wybór metod płatności, nie jesteś w stanie opłacić zakupionego produktu. Czasem osoby integrujące się z rozwiązaniem czerpały informację raz z jednej części dokumentacji, raz z drugiej. Doprowadzało to do powstania “hybrydowych” rozwiązań dziwnych zachowań w aplikacji. Tak wygenerowany token miał część uprawnień pozwalających na poruszanie się po bibliotece. Np. można było płacić tylko przelewem, a pozostałe metody płatności zwracały błędy.

Niepełny opis problemu

Często otrzymujemy niepełny opis zdarzenia, bez informacji o tym, jak go zreprodukować. W momencie, kiedy prosimy o więcej szczegółów, często słyszymy informację: jutro wrócę do Was.

Brak wiedzy domenowej oraz świadomości jak działa biblioteka

Biblioteka poza stworzeniem zamówienia, informuje aplikację o zmianie stanów związanych z zachowaniem płatności (przyjęta, realizowana, zakończona), wspieranej przez dany Payment Processor (uproszczona definicja: firma wyśrubowane normy bezpieczeństwa).

W końcu nasz użytkownik nie musi przejść całego procesu płatności, może otrzymać błąd albo po prostu się rozmyślić. Czasem jest również poproszony o dodatkową autentykację lub chce się zalogować do swojego konta u danego operatora płatności.

W takich przypadkach bardzo często otrzymujemy informację: Państwa Biblioteka nie działa poprawnie, proszę to naprawić (a gdzie kroki reprodukcji? A gdzie platforma, urządzenie, aplikacja do reprodukcji problemu?).

FAQ

Warto tu zajrzeć nawet przed implementacją. Jeżeli ktoś już miał podobny problem, postaraliśmy się opisać go w sposób przejrzysty, który pozwala na próbę rozwiązania częstych problemów bez kontaktu z supportem.

Pośpiech

Bardzo często podczas rozmów z klientami starają się oni nas pośpieszyć i oczekują rozwiązania podczas rozmowy, często wręcz wraz ze swoim zespołem developerskim starają się udowodnić, że problem leży po naszej stronie i powinniśmy go jak najszybciej naprawić.

Poza wsparciem naszych klientów oraz rozwojem biblioteki nasz zespół miał również pewne szczególne zadanie. Często użytkownik biblioteki integrował się z nią, po czym zapomniał zrobić testów przepływu albo mówiąc bardziej kolokwialnie - zintegrował się z produktem, jednak „nie przeklikał” całego procesu zakupowego. W związku z tym, żeby zadbać o markę produktu i przetestowanie przepływu zakupowego, użyliśmy terminu “audyt”.


Audyty

Początkowo audyt polegał tylko i wyłącznie na upewnieniu się, że wszystko zostało zintegrowane, jak należy. Polegało to na wcieleniu się w zwykłego użytkownika aplikacji na środowiskach produkcyjnych u klienta oraz w systemie płatności. Z czasem zobaczyliśmy, że jest to za mało.

Okazało się, że jako firma wspierająca płatności, możemy ucierpieć na wizerunku związanym z negatywnymi recenzjami aplikacji naszego klienta, nawet jeżeli nie będzie to naszą winą. Chodzi tu zarówno o przepływ informacji tych jawnych, stabilności aplikacji, jak i ukrytych w logach informacji, które mają posłużyć do przeprocesowania płatności.

Zacznijmy jednak od początku, po doświadczeniach związanych z klientami, gdzie czasem traktowano nas jako zło konieczne. Audyt nie zawsze musi być tylko formalnością - czasem, gdy przekazywano wersję debugowe aplikacji, mieliśmy do nich uwagi. Jeżeli mnie pamięć nie myli, to rekordzista z różnych względów podchodził 14 razy do audytu. Z roli sygnalizacji świetlnej „tak”, „nie”, która informowała dział ryzyka, czy należy dopuścić danego klienta do produkcji, staliśmy się “miękkim” oddziałem doradczym, który poza przeklikaniem ścieżki płatności w aplikacji, przeklikiwał dla bezpieczeństwa pozostałe ścieżki.

Przed rozpoczęciem audytu klient powinien zapoznać się z listą rzeczy. Dzięki temu może on po swojej stronie wyłapać drobne nieścisłości. Następnie za pomocą maila lub prywatnego marketu przekazywał nam swoją aplikację (część z nich przekazuje również dodatkowy opis aplikacji, aby mieć kontekst, do czego aplikacja powinna służyć), która komunikowała się z testowym środowiskiem.

Kilka rzeczy, które sprawdzaliśmy podczas testowania:

  • Czy aplikacja loguje informację do konsoli (jeżeli tak to jakie?)
  • Czy wykorzystują aktualną wersję biblioteki?
  • Czy komunikacja odbywa się ze środowiskiem testowym?
  • Testujemy ścieżki płatnicze
  • Czy możemy się wylogować z aplikacji?
  • Czy aplikacja jest zobfuskowana?
  • Jak wygląda proces komunikacji sieciowej?


Niestety, ale bardzo często otrzymywaliśmy aplikację, która nie wycinała logów, jak i komunikowała się ze środowiskiem produkcyjny (bo tak było szybciej). Zdarzało się również, że oczekiwany rezultat po rozpoczęciu transakcji przez merchanta to 400, lub uznał, że connection error również jest ok podczas płatności.

Podczas wspierania klienta najczęstszą metodą komunikacji była droga e-mailowa, jednak o wiele szybszą drogą było wdzownienie się na telco i przekazanie niezbędnych informacji. Audyty przez klientów były traktowane nie tylko jako potwierdzenie poprawnej integracji z biblioteką, ale również jako zewnętrzny zespół jakości, który nie tylko zgłasza ogólne uwagi odnośnie stabilności, ale jest również proszony o dokładną ścieżkę, jak należy zreprodukować problem, a następnie o retesty.


Porady

W celu wyjaśnienia wielu problemów najczęściej wystarczy zwykła komunikacja e-mailowa. W przypadku kiedy komunikacja jest bardzo „długa”, czyli jest to po prostu głuchy telefon, gdzie przekazujemy informację do osób technicznych przez bardzo długi łańcuch lub gdy sprawa jest bardzo paląca, lepiej jest po prostu zadzwonić lub wdzwonić się za pomocą hangouta/skypa. Warto tutaj wcześniej przygotować agendę (powtórzenie problemu, dopytanie o kroki reprodukcji, czy brali pod uwagę następujące rozwiązania).

Ludzie naprawdę inaczej zachowują się, pisząc wiadomości i mówiąc o swoich problemach. Z większością osób można rozwiązać problem przez telefon, gdzie najpierw stara się określić, co jest palącym wyzwaniem. Niestety, ale znajdują się również nieco trudniejsi odbiorcy. W takich przypadkach najlepiej wziąć ze sobą większy kubek melisy. Wydaje mi się, że idealne spotkanie zawiera kilka osób technicznych, które debatują nad problemem - rozbijają go na czynniki pierwsze, żeby później znaleźć idealne rozwiązanie, jak również i po jednym przedstawicielu biznesowym z obu stron, którzy będą pilnowali zarówno czasu spotkania, jak i odpowiednio je podsumują.

W przypadku spotkań związanych z biblioteką, jak i spotkań związanych z tematem płatności mobilnych, bardzo ważną funkcję pełnią analogowe notatki. Służą one jako podsumowanie ustalonych do tej pory rzeczy oraz podkreślają punkt widzenia danej osoby. W zależności od tego, jaka osoba tworzy notatki, niektóre sformułowania mogą okazać się niejednoznaczne lub dążyć do omyłki (ktoś coś błędnie zrozumiał). Notatki również przydają się, gdy dany temat jest odświeżany w dłuższej perspektywie czasowej oraz jako podsumowanie spotkania.


Co dalej?

W następnej części opowiem o tym, jak współpracuje się wewnętrznie pomiędzy różnymi działami. Zapewne wszyscy posiadają jakieś pojęcie związane ze współpracą między frontendowcami, a backendowcami. Do nich należy dołożyć inne działy jak np. zespół sprzedażowy oraz prawny...

Masz coś do powiedzenia?

Podziel się tym z 120 tysiącami naszych czytelników

Dowiedz się więcej
Rocket dog