Konferencje
Mobile Trends

Chmura w smartfonie – Jak Google rozwija aplikację Cloud Platform

Czy zastanawiałeś się kiedyś, jak Google rozwija swoje aplikacje? Wraz z otwarciem biura w Warszawie, możemy to sprawdzić. Kamil Brzeziński, Product Manager, który czuwa nad rozwojem Google Cloud Platform zdradził nam nieco szczegółów. Jeśli interesują Cię doświadczenia Kamila, w kontekście tworzenia i projektowania aplikacji Google Cloud, zostań z nami. Dowiesz się, co to jest GCP, kto z niej korzysta, jak zespół rozwija aplikację, a także jak wygląda proces projektowy w Google!

Google od jakiegoś czasu dostrzega potencjał polskich inżynierów, a z Warszawy stworzyło istny hub dla swoich chmurowych rozwiązań. Jedną z osób, która miała okazję skorzystać na tej operacji jest Kamil Brzeziński. Doświadczony specjalista w Google zajmuje się obecnie rozwojem Google Cloud Platform. Jako Product Manager jest osobą odpowiedzialną za ocenę biznesową produktu. Reprezentuje też głos użytkownika wewnątrz zespołu pracującego nad aplikacją. Odpowiada za cały produkt – od koncepcji do wdrożenia. Kamil podkreśla jednak, że to, że odpowiada za produkt od pomysłu, wcale nie oznacza, że on jest pomysłodawcą wszystkiego, co się w jego obrębie dzieje. Odpowiada jedynie za to, żeby konkretne pomysły przekuwać na liczby, realizowane w gotowym produkcie. Jednocześnie z tyłu głowy musi mieć funkcjonalność całego produktu, niezbędną dla realizacji potrzeb i celów użytkowników. 

Kamil Brzeziński

Google

Buduje zespoły skupione wokół sukcesu swojego produktu. W przeszłości CTO w Edipresse i Redexperts. Szef zespołu mobilnego i technologii VOD w Agorze, Kierownik działu mobilnego w Grupie Allegro czy wcześniej w GG Network. Dzisiaj pracuje w Google Cloud. Wykształcenie techniczne zdobył na Politechnice Bydgoskiej na kierunku Elektronika i telekomunikacja. W czasie wolnym spędza czas z rodziną i przy grach komputerowych.

Google Cloud – co to jest

Jak podkreśla rozmówca Roberta Rachwała, Google Cloud można rozróżnić na dwie oddzielne kategorie produktowe. W Google Cloud znajduje się zarówno aplikacja Workspace jak i Platform. Google Workspace jest bardzo dobrze znane w świecie biznesowym wszystkim osobom, które korzystają z Gmaila. Wchodzą w to usługi współdzielenia dysków, kalendarzy, dokumentów. Ogółem są to wszystkie narzędzia zapewniające kolaborację w firmie. Z kolei, aplikacja, nad którą pracuje zespół Kamila to Google Cloud Platform, czyli aplikacja dla platformy chmury, z której mogą korzystać inne firmy. Obejmuje to różnego typu usługi infrastrukturalne, jak maszyny wirtualne, ale też serwerowe dla baz danych. – Aplikacja mobilna, nad którą pracujemy, służy użytkownikom Clouda, czyli tych usług chmurowych do zarządzania nimi, do monitoringu oraz do analizy tego, co się tam dzieje. Generalnie aplikacja służy do zarządzania i monitoringu tego, co klienci mają uruchomione na chmurze Google – tłumaczy Kamil Brzeziński.

Google Cloud Platform – kto z niej korzysta?

Jak czytamy na empressia.pl, Google Cloud Platform oferuje narzędzia oraz usługi, które są przydatne zarówno dużym przedsiębiorcom mającym swoje siedziby w wielu krajach na świecie, jak i tym początkującym bez rozwiniętej struktury. Potwierdzają to słowa Brzezińskiego, który mówi, że aplikacja nie jest limitowana do żadnej grupy. 

Tak naprawdę każdy, kto zarejestruje się na cloud.google.com i stworzy sobie konto bilingowe do rozliczeń, może zacząć korzystać z chmury. W tym samym momecie, kiedy ma już dostęp do usług chmurowych, może korzystać z nich poprzez aplikację mobilną. 

Second screen dla desktopu

Aplikacja nie ma funkcji rejestracji, ale zalogować się tam możemy. Aplikacja nie ma wielu funkcji. Kamil podkreśla, że jest tzw. “second screenem”, co oznacza, że nie jest trakotwana na równi z wersją desktopową. Można tam zarządzać zasobami, o ile te zasoby istnieją. Aplikacja pełni funkcję pomocniczą w kontrolowaniu i monitorowaniu, ale to aplikacja webowa jest głównym produktem. – To nie jest rozwiązanie w pełni kompleksowe, czyli ja nie loguję się na swoje konto cloudowe i stworzam maszyny wirtualne czy jakieś inne usługi bezpośrednio w aplikacji. Nie do tego ta aplikacja służy. Trzeba mieć najpierw jakieś zasoby. Trzeba coś uruchomić na cloudzie, korzystać z tych usług, które w aplikacji wspieramy. Dopiero w tym momencie można z aplikacji zacząć z nich korzystać – mówi PM z Google. 

Aplikacja głównie dla admina

Z rozmowy CEO Wellms z Brzezińskim możemy wysnuć konkluzję, że Google Cloud app jest głównie dla administratorów serwerowych, którzy monitorują stan usług, z jakich korzysta chmura oraz zawiadują ich zużyciem, płatnościami oraz procesem eksploatacji. Może być to także aplikacja dla biznesu.

Niedawno, zespół Kamila uruchomił w aplikacji nowy biling, który pozwala osobom biznesowym na podejrzenie “stanu magazynowego” co do zużycia chmury dla aktualnie prowadzonych projektów. Mogą sprawdzać jakiego typu zasoby pobierają, z jakiej wysokości rachunkami mają do czynienia, a także mogą sprawdzić predykcję. Google ma funkcjonalność, dzięki której sam oblicza przewidywane koszty pod koniec okresu rozliczeniowego, co ułatwia planowanie budżetów organizacjom z niego korzystających.Są tam wykresy oraz informacje, które pomagają szczególnie osobom biznesowym, ale faktycznie to admini są największą grupą użytkowników. To są te osoby, które dbają o infrastrukturę po stronie klientów. 

Co do Google Maps, reCAPTCHA czy Translatora i reszty usług Google, to Cloud Platform nie wspiera usług tego typu. Jeśli znajdują się one w kontekście wykorzystania w danym projekcie i istnieje łączność z API, to owszem w aplikacji można takie rzeczy sprawdzić pod kątem bilingowym. Sama chmura po stronie klienta nie wspiera nie wspiera jednak tego typu funkcjonalności. A przynajmniej na razie.

Kto wchodzi w skład zespołu rozwijającego Google Cloud Platform

Nad aplikacją Google Cloud Platform, w momencie audycji Mobile Trends Podcast pracowało co najmniej kilkanaście osób. Poza Kamilem, drugą najważniejszą osobą w projekcie jest  Technical Project Manager, który odpowiada za kwestie bardziej techniczne, inżynieryjne. Zespół korzystał też z pracy inżynierów back-end, Android i iOS oraz ich Managera. W zespole znalazło się też miejsce dla dwóch UX researcherów ze Stanów Zejdnoczonych oraz UX Designerki również z USA, ze Seattle. 

Skąd zespół Google Cloud bierze dane? 

Google czerpie wiedzę z różnych źródeł. W przypadku GCP badaniami zajmuje się Kamil oraz wspomniani badacze UX, którzy zajmują się badaniami z użytkownikami. W obrębie projektu zespół prowadzi różnego typu badania. Od badań desk-research po bezpośrednie wywiady pogłębione i testy użyteczności. Niektóre badania polegają na zwykłym zebraniu informacji z raportów czy integracji opinii w App Store i Google Play, gdzie podstawą jest odpowiednie ich przefiltrowane. Na podstawie tego można się już sporo dowiedzieć na temat oczekiwań użytkowników, co do następnych wersji aplikacji.

Opinie to bardzo ważne źródło danych, o czym co jakiś czas wspomina każdy badacz UX. Przykładem może być Jadwiga Kijak z mobeedick, podczas rozmowy na kanale Zebzy. Badania bezpośrednio z użytkownikami aplikacji mogą dotyczyć wypełnienia ankiet czy spotkań 1:1 lub w grupie. Często prowadzi się także badania rynku, gdzie największą sympatią w Google ciesza się badania konkurencji, czyli co konkurencja robi w kierunku mobilnego dostępu do usług chmurowych. – Źródeł danych mamy wiele. Ja jako PM muszę podjąć odpowiednią decyzję z którego źródła danych skorzystać. To czasami wcale nie jest takie takie proste, żeby podjąć właściwą decyzję – śmieje się Brzeziński. 

Jak wygląda projektowanie usług w Google

Kamil zauważa, że mimo, że Google wyznacza standardy, to daje wolną rękę w wielu kwestiach swoim specjalistom. Google w końcu jest twórcą systemu komunikacji wizualnej dla aplikacji pisanych pod Android OS, Material Design. Pracownicy Google wiedzą jaka jest komunikacja wizualna tej marki i wiedzą jak powinni projektować, żeby zachować spójność, jednak mogą sobie pozwolić na inwencję twórczą, a ostateczny kształt poszczególnych funkcjonalności należy do Product Managerów, którzy odpowiadają za produkt od strony biznesowej oraz Technical PM odpowiedzialnych za warstwę inżynieryjną. W trakcie review uprzednio informują o tym swój leadership, żeby miał wiedzę co się dzieje w produktach marki.

– To nie jest tak, że robimy sobie miszmasz. Raczej każdy Product Manager z zespołem dąży do tego żeby te aplikacje były spójne. Mamy oczywiście wewnętrzne wytyczne, a nasi designerzy wiedzą dokładnie jak projektować aplikacje mobilne. Ale to nie jest tak, że coś jest narzucone – tłumaczy Product Manager w GCP. –  My nic w projekcie nie musimy. To jest raczej tak: Jeżeli będziecie podążać za naszymi standardami, to aplikacje będą spójne i użytkownikom łatwiej będzie z nich korzystać, bo nie muszą odkrywać koła na nowo. Prawda jest taka, że mamy dosyć dużo swobody i oczywiście aplikacja jest przeglądana przez nasz zespół od jakości oraz accessibility, czyli dostępności dla różnych użytkowników oraz programów wspomagających korzystanie z urządzeń chociażby dla osób z różnymi niepełnosprawnościami, więc takie rzeczy są brane pod uwagę, ale wciąż cieszymy się dużą wolnością w projekcie – dodaje Brzeziński.

Zespół musi też pamiętać, że istnieje świat poza Google i Androidem. Apple ma przecież swoje własne wytyczne, których trzeba się trzymać, jeśli projektowana aplikacja ma działać na iOS.

Największe wyzwanie w rozwoju aplikacji Google Cloud – dług technologiczny

Według Kamila największym wyzwaniem produktowym z jakim przyszło mu się do tej pory zmierzyć w Google jest dług technologiczny. Akurat to wyzwanie jest ogromne w każdym kontekście dla każdego biznesu, gdyż wymaga operacjonalizacji w kontekście wdrożenia nowych standardów czy technologii przy zachowaniu ciągłości usługowej i dotychczasowego działania przedsiębiorstwa. W przypadku Google Cloud Platform nie jest inaczej. Dużym wyzwaniem okazała się zmiana stosu technologicznego, czyli kodu, który jest pod spodem aplikacji. To wyzwanie zarówno od strony produktowej, gdyż wymaga doboru odpowiedniej technologii oraz od strony procesowej, gdyż cała produkcja aplikacji nie może zostać wstrzymana. Mowa o aktualizacjach i rozwoju. Powstaje więc sytuacja, w której z jednej strony musimy przepisać cały kod na nowo, a w drugiej bez ustanku pisać nowy, żeby nie przerwać ciągłości produkcyjnej aplikacji. 

– Według mnie to jest największe wyzwanie […], bo od strony produktowej procesy i cała produkcja aplikacji jest bardzo dobrze ułożona. Nie spodziewam się tutaj jakichś większych problemów. Ale zmiana technologii aplikacji to jest ogromne wyzwanie. Nie tylko technologiczne, ale też produktowe. No bo musimy dbać, o to żeby użytkownicy cały czas dostawali aktualizację. To nie jest tak, że możemy sobie porzucić rozwój aplikacji na rok czy dwa lata i tylko przepisywać się na nową technologię. Faktycznie musimy odpowiednio to przemyśleć zaplanować […] Oczywiście prace już zaczęliśmy. Przygotowywaliśmy się w zeszłym roku do tego. […] Mamy jakieś estymaty: Ile czasu nam nam to zajmie, bo nie powiedziałem, ale […] aplikacja natywna czyli androidowa rozwijana była w javie, a iOSowa głównie w objective-C i trochę Swifta tam jest, więc trochę pomieszane technologicznie. I podjęliśmy decyzję dosyć trudną decyzję, żeby przejść na Fluttera – mówi Product Manager w GCP.

Dlaczego Flutter?

Flutter to technologia googlowa, cross-platformowa, która wspiera krótszą pracę, gdyż kod napisany we Flutterze obsługiwany jest zarówno przez urządzenia z AndroidOs jak i iOS.  Oznacza to, że kod wystarczy napisać raz, a “wypluć” można dwie aplikacje. W przypadku decyzji produktowej to całkiem sprytne rozwiązanie, gdyż aktualizacje do aplikacji również można pisać we Flutterze. Technologia ta wspiera podejście hybrydowe, czyli połączenie własnego kodu z aplikacją natywną.

Zapewnia to ciągłość aktualizacji, a pozostały kod może być nadpisywany w trakcie. Co więcej, decyzja ta wsparła także oszczędność budżety, gdyż nie trzeba było zatrudniać w tym przypadku sztabu specjalistów konkretnego języka programowania.  Kamil mówi, że w przyszłości decyzja ta znacznie przyspieszy rozwój aplikacji. Mimo wszystko nadal, to ogromne wyzwanie organizacyjne zaplanować prace produkcyjne i “restauracyjne” dla starego kodu, z równoczesną jego optymalizacją i testami.

– Dobre jest to, że dysponujemy w Google ogromną ilością danych szczególnie wewnętrznych i skontaktowaliśmy się z innymi zespołami, które przechodziły przez migracje. Porozmawialiśmy z nimi jak u nich to wyglądało, a także jak robione przez nich estymaty rozminęły się z rzeczywistością, czyli ile faktycznie pracowali nad nad tą migracją i w jaki sposób podeszli do migracji. No i to pozwoliło nam podjąć. mam nadzieję dobrą, decyzję – dodaje Kamil Brzeziński.

Według Brzezińskiego, Flutter mimo swojego młodego wieku, o ile możemy tak powiedzieć w kontekście języka programowania, jest dosyć dojrzałą technologią, którą z powodzeniem wykorzystują najwięksi gracze na rynku. Z powodzeniem wykorzystała go chociażby spółka Credit Agricole, o czym opowiadali przedstawiciele LeanCode wraz z Katarzyną Tomczyk-Czykier na Mobile Trends for Experts. Flutter ma też dobrą dokumentację, a zespół Google, który rozwija Fluttera może służyć też wsparciem dla Cloud Platform. – Tych argumentów “za” było dużo, zdecydowanie więcej niz “przeciw”. Cały projekt, cały pomysł był poprzedzony dogłębną analizą. Spędziliśmy kilka miesięcy nad zastanowieniem się, którą ścieżkę wybrać, w jakim kierunku iść i mieć trochę więcej pewności, że podejmujemy właściwą decyzję – kwituje PM z Google Cloud.

Jak zachować balans między wdrożeniem nowych rzeczy, a nadpisywaniem i poprawianiem starych? Jak wygląda proces aktualizacji w Google?

W Google Cloud Platform, sprinty trwają sześć tygodni. To optymalny czas dla wstawiania aktualizacji oraz dosyć dużo czasu na opracowanie i napisanie kodu czy zrobienia badań. – Ten cykl sześciotygodniowy wybraliśmy nieprzypadkowo. On jest na razie dostosowany do całego procesu i do tego jak wygląda wydanie aplikacji. Generalnie sześciotygodniowe sprinty pozwalają nam w miarę sensownie ułożyć ten proces i nie frustrować się też tym, że użytkownicy na coś muszą długo czekać – tłumaczy Kamil Brzeziński.

Kamil mówi, że w Google nie muszą przepisywać tylko danej funkcji dla danego obszaru w produkcie. To konkretne flow pozwala im zmieniać i poprawiać kod podczas przepisywania. Samo przepisywanie powoduje, że zespół pozbywa się znanych błędów. Przy okazji wprowadzając nowe, gdyż jest to nie do uniknięcia. Jednak lista z priorytetami rzeczy do dodania w każdym z obszarów znacznie ułatwia podejmowanie decyzji programistycznych oraz nie wywołuje przerw w zastanawianiu się nad konkretnymi wdrożeniami czy funkcjonalnościami. Wszystko jest już ustalone z wyprzedzeniem w roadmapie. 

– Mamy listę rzeczy i listę nowych funkcji, które chcemy dodać do aplikacji i one obejmują praktycznie wszystkie nasze obszary produktowe. Aplikacja wspiera compute, czyli maszyny wirtualne. Wspieramy storage, bazy danych, wspieramy IAM czyli zarządzanie uprawnieniami, wspieramy także GKE i Compute Engine. W każdym z tych produktów, wiemy co trzeba dodać, bo o to proszą użytkownicy, więc jest nam łatwiej – kwituje PM z Google. 

Posłuchaj Podcastu z Kamilem!

Brzeziński mówi, że praca z ludźmi nie jest tak łatwa, jak praca z kodem. Praca z komputerami wbrew pozorom jest łatwiejsza, bo komputery są przewidywalne i w programach wiadomo jak coś powinno się zachować. Nawet jak czasem zdarzają się odstępstwa od tej reguły, to zazwyczaj wiadomo co w takiej sytuacji trzeba zrobić. W przypadku ludzi, nie ma takich reguł, co jest dużym wyzwaniem. Ważne, aby dostosowywać język do odbiorcy, wykazywać się empatią oraz sporą dozą cierpliwości i powściągliwości. Jeśli chcesz posłuchać całej rozmowy z Kamilem, wejdź w podcast pod tym artykułem! 

foto: Canva.com

Udostępnij
Mobile Trends
Zobacz także