W nasze biznesowe DNA mamy wpisane budowanie relacji i dbanie o nie. Nie tylko dlatego, że po prostu chcemy poznać ludzi, z którymi pracujemy, ale również dlatego, że takie podejście przynosi konkretne efekty. I temu poświęciliśmy nasz wpis. Znajdziecie w nim przykłady konkretnych działań, które podjęliśmy, żeby od zera stworzyć owocną relację z Fully-Verified.
Biznesowe 100 metrów czy 42 kilometry?
W inProjects duża część realizowanych projektów wynika z relacji biznesowych, które nawiązaliśmy i rozwijaliśmy przez lata. Biznes relacyjny to coś, w czym jesteśmy dobrzy i co jest nieodłącznym elementem tego, jak działamy. Gdybyśmy mieli to opisać sportową metaforą, to zdecydowanie wolimy maratony od biegów krótkodystansowych. Efektem takiego podejścia jest udział w projekcie Fully-Verified, który jako zespół developerski, rozwijamy od jesieni 2017 roku.
Fully-Verified to platforma do zdalnej weryfikacji tożsamości działająca w oparciu o sztuczną inteligencję oraz zintegrowane, dedykowane narzędzia wspierające wyspecjalizowanych operatorów. Platforma swoje usługi kieruje głównie do firm z sektora finansowego, m.in banków, giedły kryptowalut, platform tradingowych, pożyczkodawców, w których obowiązują dość restrykcyjne regulacje dotyczące procesów potwierdzania tożsamości związane z przeciwdziałaniem praniu brudnych pieniędzy (AML) i finansowaniu terroryzmu.
…Cause I gotta have faith*
Nasza współpraca z Łukaszem Kwiatkowskim – właścicielem i pomysłodawcą Fully-Verified rozpoczęła się od rekomendacji naszego wieloletniego partnera biznesowego. Wspólnie z Maksem realizowaliśmy projekt WellServed i mWars i to on zasugerował, Łukaszowi, że jesteśmy odpowiednim zespołem do pracy przy tworzeniu Fully-Verified.
Łukasz przychodząc na pierwsze spotkanie z nami miał pomysł, plan oraz środki, na ich realizację. Nie miał jednak wystarczającej wiedzy i umiejętności technicznych. Zdecydowany klient z budżetem – to brzmi jak sytuacja idealna, ale wbrew pozorom, wcale nie jest ona najprostsza dla obu stron. Dla osoby, która ma pomysł i środki na produkt, ale nie ma wystarczającej wiedzy technologicznej największym problemem jest znalezienie zewnętrznego zespołu do realizacji projektu, stworzenie relacji opartej o zaufanie oraz akceptacja ryzyka, które wynika z takiego modelu developmentu.
Jeżeli samemu nie ma się wystarczającej wiedzy trzeba zaufać drugiej stronie, że ją ma i jest w stanie dostarczyć wymagane elementy, zgodnie z wysokimi standardami – z założeniem, że ja mogę nigdy nie mieć wystarczająco wiedzy żeby to faktycznie zweryfikować. Zweryfikuje to dopiero rynek i użytkownicy. – Łukasz Kwiatkowski, Fully-Verified CEO
Od deklaracji do konkretów
No tak, tylko jak zbudować zaufanie i dać klientowi poczucie, że jest w dobrych rękach? Coś, co jest niemierzalne i trudne do zweryfikowania? Z naszego doświadczenia wynika, że są elementy, które wspomagają proces budowania takiej relacji biznesowej.
Ponieważ relacja jest obustronna i takie też powinno być zaufanie, dlatego kluczowe dla nas było przygotowanie umowy, która zabezpiecza Fully-Verified i reguluje przejrzystość naszej pracy.
Ważne dla nas było aby w opisach poszczególnych etapów developmentu skupić się na tym, co z biznesowego punktu widzenia ma zostać dostarczone, z celowym pominięciem np. wyglądu interfejsów lub wykorzystanych technologii. Taka konstrukcja konkretnie określała, co Łukasz otrzyma od nas na koniec danego etapu.
Wynikiem konstrukcji umowy oraz wspólnych ustaleń było rozliczanie projektu w sprintach, zgodnie z założeniami time&material oraz korzystanie z innych elementów Scruma. Dzięki takiej formie współpracy Łukasz miał wgląd w szczegółowe, godzinowe rozliczenia poszczególnych sprintów:
Praca w modelu time&material i Scrumie dała mi większą przejrzystość dla postępów w rozwoju produktu i wydanych pieniędzy. – Łukasz Kwiatkowski, Fully-Verified CEO
O ile dla klienta taka forma realizowania projektu była komfortowa, ponieważ pokazywała jednoznacznie ciężar finansowy poszczególnych działań, to na nas nakładała ryzyko, że każdy z kolejnych sprintów może być ostatnim. Mimo to, dzięki otwartej komunikacji i zaufaniu zawsze z perspektywą wielotygodniową wspólnie tworzyliśmy dalsze plany rozwojowe Fully-Verified. Pozwoliło nam to przewidywać obciążenia zespołu z wyprzedzeniem i odpowiednio planować pracę w innych projektach.
Żeby zyskać trzeba stracić
Pozytywnie na budowanie wzajemnego zaufania wpłynęło również zaangażowanie zespołu w biznesowy rozwój i zwiększanie wartości produktu – w szczególności Wojtka, który w dużym stopniu pełnił w projekcie rolę product ownera. Na pozór praca w takiej roli może sprawiać wrażenie konfliktu interesów, ponieważ nie zawsze to, co jest korzystne z biznesowego punktu widzenia, jest w interesie firmy, która prowadzi development. Czasami rolą product ownera jest wstrzymanie developmentu danej funkcjonalności, co przekłada się na mniej pracy dla zespołu – a przecież w modelu time&material mniej pracy, to mniej przychodów.
We współpracy z Fully Verified naszym nadrzędnym celem było unikanie błędów przy tworzeniu produktów, które my sami popełniliśmy lata temu w inProjects np. przy projekcie WellServed. Tak naprawdę była to dość prosta kalkulacja biznesowa – jeżeli produkt nie zacznie odpowiednio szybko funkcjonować na rynku i przynosić zysków klientowi – nie będzie też dla nas pracy przy developmencie. – Wojciech Kozicki, prezes inProjects
W developmencie śpiesz się powoli
Jednym z obszarów, w których doświadczenie Wojtka z innych projektów procentowało były integracje naszego API z systemami klientów. Bardzo często klienci, jeszcze przed rozpoczęciem testów usługi, przesyłali listę specyficznych wymagań lub funkcjonalności, które były im natychmiast “potrzebne”. Wojtek twardo forsował podejście iteracyjne, w którym najpierw dążyliśmy do integracji bez custom developmentu (w stylu proof of concept), a dopiero po tym etapie rozmawialiśmy o specyficznych potrzebach. Często okazywało się, że wcześniejsze wymagania klienta nie były już aktualne lub ulegały znaczącej zmianie, co pozwalało wytwarzać je już jako biznesowo uzasadnione funkcjonalności.
W kontekście próbnych integracji, które stanowiły obciążenie dla devleoperów warto wspomnieć o pomyśle Michała i Krzyśka, którzy widząc jak często sama testowa integracja nas obciąża, stworzyli sandboxowe środowisko integracyjne umożliwiające klientom praktycznie bezobsługowe testowanie usługi i integracji, jeszcze przed domknięciem ustaleń biznesowych i kontraktów, które mogły być negocjowane równolegle.
Czasem mniej znaczy więcej
Nie tylko Wojtek zaangażowany był w optymalizowanie kierunków developmentu. Cały zespół pracował nad roadmapą projektu i wpływał na kształt tworzonego produktu. Na spotkaniach demo z właścicielami platformy każdy członek naszego zespołu miał głos i możliwość sugerowania zmian lub funkcjonalności.
Korzyści z takiego modelu współpracy są obustronne. Zespół developerski jest bardziej zaangażowany w wykonywane zadania i zmotywowany, od strony klienta pozwala to na optymalizację wydatków.
Dobrym przykładem takiego podejścia jest sugestia Krzyśka, który pracując nad developmentem aplikacji mobilnej dla systemu Android zwrócił odpowiednio szybko uwagę, że niepotrzebnie staramy się utrzymać kompatybilność dla Androidów w wersji 4.4. i niżej. Koszt utrzymania zgodności z leciwymi już urządzeniami nie miał żadnego uzasadnienia biznesowego – raz, że odsetek takich użytkowników był bardzo niski, a dwa – telefony pracujące na tej wersji systemu i tak miałyby trudności z odpowiednią wydajnością na potrzeby połączenia wideo.
Korzystanie ze wsparcia biznesowo-technologicznego inProjects dało nam możliwość optymalizacji czasu i precyzyjnego nawigowania roadmapy. Bez wiedzy zaczerpniętej od zespołu na pewno dużo więcej czasu tracilibyśmy na znajdowanie odpowiednich rozwiązań lub na zbędne zagłębianie się w mniej istotne zagwozdki technologiczne. – Łukasz Kwiatkowski, Fully-Verified CEO
Ramię w ramię
Oczywiście, taki model współpracy wymagał chęci i woli z obu stron i nie sprawdzi się w każdym przypadku. Jednak dla projektów, które mają długoterminowy czas realizacji i wymagają zaangażowania na poziomie koncepcyjnym, warto zainwestować czas w rozwinięcie relacji biznesowej, opartej na wzajemnym zaufaniu i zaangażowaniu.
Efektem współpracy w takim modelu jest produkt, który funkcjonuje i jest w stanie się obronić na rynku. InProjects widzę jako część zespołu Fully-Verified, a nie zewnętrznego kontrahenta i myślę że działa to w dwie strony. Dzięki temu produkt jest rozwijany z większą odpowiedzialnością. – Łukasz Kwiatkowski, Fully-Verified CEO
W tej chwili Fully-Verified jest działającym produktem z klientami z Azji i Europy, który bez kompleksów konkuruje z innymi firmami oferującymi usługi o zbliżonej specyfice. Platforma oferuje dwa typy procesów weryfikacyjnych: oparty na wideo rozmowie z wykwalifikowanym operatorem oraz drugi automatycznym, w którym użytkownik przechodzi weryfikację samodzielnie na wideo, a jej wyniki są dodatkowo weryfikowane przez operatora. Wbrew pozorom proces oparty na obecności operatora (w obu przypadkach) powoduje, że usługa Fully-Verified wyróżnia się na rynku ponieważ spełnia najostrzejsze normy prawne i zapewnia pełne bezpieczeństwo.
Takie elementy, jak odpowiednia umowa, przejrzysty sposób raportowania i rozliczenia godzin, współdzielone narzędzia (w naszym przypadku YouTrack) i dokumenty do pracy nad rozwojem produktu są bardzo ważne. Jednak w budowaniu relacji biznesowej nieprzeceniona pozostaje rola rozmowy, która pozwala zrozumieć wizję klienta i efekt, który chce osiągnąć.
Chętnie porozmawiamy o Twoim projekcie i jego założeniach, dowiemy się, jaki cel chcesz osiągnąć. Skontaktuj się z nami na info@inprojects.pl a my zaproponujemy ścieżkę, jaką możesz tam dotrzeć.
Psst… to jeszcze nie koniec 😉
Post Scriptum
*Jeżeli próbujecie sobie przypomnieć, z jakiej piosenki pochodzi nasz nagłówek to już śpieszymy z podpowiedzią i życzymy miłego odsłuchu 🙂 Piosenka
**Wszystkie kwoty w przykładowym rozliczeniu podane są kwachach zambijskich i nie mają odzwierciedlenia w rzeczywistości, ale dla dociekliwych: 1 kwacha zambijska to około 30 groszy.
