#40 Platformy i platform team

Własne wewnętrzne platformy to coraz śmielej pojawiający się trend. Sprawdź 9 istotnych kroków, dzięki którym z sukcesem utrzymasz platformę i platform team-y!

Ciekawe linki i inne znaleziska z tego odcinka:

• Software Visualization — Challenge, Accepted
• Improving Distributed Caching Performance and Efficiency at Pinterest

Transkrypcja

Szymon Warda [SW]: Cześć! Słuchacie Patoarchitektów. Prowadzą Szymon Warda

Łukasz Kałużny [ŁK]: i Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na: patoarchitekci.io/40. Dzisiaj jest pełnoprawny odcinek, a nie short. Szymon, jaki przygotowałeś link?

SW: Link, który mnie trochę rozbawił, ale jest całkiem niezły. Improving distributed caching performance and efficiency at pinterest. Co jest tam ciekawego? W dużym skrócie, jakbym miał podsumować: mówimy o wydajności, a pinterest powiedział, że ma to wszystko gdzieś. I powiedział, że Uwaga!: pięć tysięcy EC dwójek do Mencache’a. Czyli mają 460 TB in memory danych. Czyli serwer domen cache ma łącznie 460 TB RAM-u. Tak. W kontekście wydajności każdy projekt można zasypać odpowiednią ilością cache’owania.

ŁK: Raczej dwie rzeczy. Z tego co pamiętam, jest jeszcze podział. Bo to pięć tysięcy na szczęście to nie jeden klaster tylko siedemdziesiąt. Więc jest trochę pocięte. Ja zauważyłem dwa dowcipy w tym wpisie. Pierwszy to jest, że Memcache DI, nawet nie żaden Redist.

SW: Tak.

ŁK: Po prostu stary, klasyczny Memcache DI bez żadnych podejść. To była dla mnie pierwsza kwestia. Druga: skala przy serwisie, który – tak jak, Szymon, wspomniałeś w dyskusji przed nagrywaniem – za bardzo nie istnieje już w Internecie, jeśli można tak powiedzieć.

SW: Tak. I ten serwis oferuje głównie zdjęcia. To nie jest treść, nie są to wpisy czy komentarze. To są zdjęcia. Więc zastanawia mnie, co oni w tym trzymają. Ale koniec hejtu na ten wpis, bo wcale nie jest zły. Jest całkiem ciekawy, ponieważ przechodzi przez optymalizację caching’u, przez to jakie maszyny wybierają, które serwery są czym obciążone: czy one są obciążone bardziej IO, CPU czy RAM-em. Więc wpis jest naprawdę godny uwagi. Jest dość długi, można się też ponabijać, że zasypali problemy wydajnościowe, głównie korzystając z Memcache’a. I czemu Memcache? Mamy też PC IT, więc dużo bardziej wydajny będzie. No, Łukasz, a co u Ciebie?

ŁK: U mnie tak naprawdę jest wpisik (tak go nazwijmy jeśli chodzi o skalę) na blogu Engineeringu w Spotify. Software visualization challenge accepted. Czyli podejście Spotify do wizualizacji, architektury. Co mnie zaskoczyło? To, że używają C4. Jako rozszerzenie wzięli model C4, który trochę rozszerzyli i ciągle używają. Dlaczego mnie to trochę zaskoczyło? Zazwyczaj firmy tej wielkości i tego typu tech wymyśla coś samodzielnego. Przykładem jest ich control place do zarządzania usługami – Backstage. A tu wzięli gotowca, którego jedynie trochę rozszerzyli. Wychodząc tak naprawdę i dodając dwa pojęcia: system landscape diagram, czyli pokazanie połączeń między systemami bez wchodzenia w detale, i umiejscowienie systemów w kontekście jako systemów context diagram.

SW: I Ty mówisz, że Spotify Cię zaskoczyło, że użyło C4. Mnie w ogóle. Do nich to pasuje. Mimo wszystko to jest zwinna firma. Tak naprawdę. Jest używana na całym świecie, ale oni nie są aż tak wielcy. A Backstage, jak wspomniałeś (mówiliśmy o tym parę odcinków temu), też jest czymś, co jest mimo wszystko dość lekkie i zwinne. Mnie użycie C4 bardzo cieszy, bo to jest mega fajny model, jeśli chodzi o wizualizację architektury.

ŁK: Upraszcza nam filozofię.

SW: Bardziej go cenię za to, że daje jasne kryteria, co na którym modelu powinno być, czego nie wrzucać…

ŁK: Właśnie. Dlatego mówię… Dlatego filozofia. I Backstage, który wymieniłem (kiedyś też wspominałem w odcinkach o nim) jest bardzo ciekawym open source. Tak naprawdę napisali plugin do Backstage’a, żeby wizualizować system landscape. Więc to jest wpis informujący o ich podejściu. Chwila czytania i zrozumienia, jak to wygląda.

SW: Dobrze, to przechodzimy do głównego tematu, czyli platformy i platform team-ów. Na ten temat trochę się kłóciliśmy, trochę gadaliśmy, więc stwierdziliśmy, że włączymy mikrofon i nagramy naszą dyskusję. Może zbierzemy inne opinie. Więc, Łukasz, zaczynaj.

ŁK: Dobra. Zanim zacznę moje przemyślenia (bo mam 9 punktów, o których powinniśmy myśleć przy platformach), przypomnę, że przy przeglądzie ostatniego Technology Radar wskazaliśmy (ja to wrzuciłem), że platform team pojawiły się na holdzie. Było wskazane, że platform team-y to troszeczkę nowy DevOps (w sensie labelowania) i tworzymy platform team-y i platformy, żeby zrobić „łajno-kompostownik” i zrzucić rzeczy, którymi nikt nie chce się zajmować. Później możemy powiedzieć, że mamy platformę, whatever, czyli nowy sukces pataologiczno-biznesowo-operacyjny.

SW: Tutaj pato może nie cechujmy negatywnie, prawda?

ŁK: Tak, tak.

SW: Ale nie. Właśnie mnie się wydaje, że ten wpis w Technology Radarze był właśnie o tym, żeby nie robić platform team-ów, żeby nie robić rebrandingu z SysOps-ów, DevOps-ów, bo potem ich przepisujemy. Tylko że trzeba te zespoły odpowiednio zbudować. To jest ten klucz. Żeby to zrobić dobrze, a nie byle jak.

ŁK: Dobra. Przy moich przemyśleniach pierwszym punktem jest dobre zdefiniowanie, co chcemy dostarczać, jaką usługę. Bo platforma oznacza, że stajemy się usługodawcą czegoś. Dajemy ludziom dostęp do naszej platformy. Pomijam jaka to jest technologia, bo to jest…

SW: Inaczej bym to ujął. Ważne jest dla kogo jesteśmy platformą: czy dla zespołów, czy dla całej firmy. Więc to nam daje powód do cięcia: gdzie się nasze usługi kończą, a gdzie się zaczynają pozostałe rzeczy.

ŁK: Tak. I kolejną istotną rzeczą oprócz tego, co i komu chcemy dostarczać, jest to czym ma być ten zespół. Bo może się okazać, że przy mindsecie ludzi, których posiadamy, nazywanie czegoś platformą zupełnie nie będzie miało sensu. Jeżeli chcemy budować coś jako usługę, team będzie bardzo mocno R&D.

SW: Dodajmy – co jest bardzo ważne – usługę wewnętrzną. Bo to jest duża różnica.

ŁK: Tak.

SW: Spotkałem się z podejściem, że to jest zespół R&D i on wyznacza główny horyzont, w którym kierunku ma iść. Według mnie, to się w ogóle do tego nie nadaje.

ŁK: Raczej trzeba podzielić to. Zespół nie może być typowym R&D. (To jest moje podejście). To jest po prostu zespół inżynierski, który utrzymuje i zna swoje ramy. I to jest chyba bardzo istotna rzecz. Bardzo często mamy jeden cel: że będziemy robić niesamowicie dużo i zakopiemy się w drobnej pracy operacyjnej. Albo drugi: cały zespół będzie R&D i nic nie będzie działało.

SW: Dokładnie. To w pewnym momencie staje się zespół supportowy. To jest zespół wsparcia zespołów engineering, które wytwarzają faktyczne systemy dla biznesu tak naprawdę. To nie jest zespół, który ma być na czele całej firmy i prowadzić co, jak, gdzie. Ich rolą jest to, żeby szybciej zapewniać wartość. Dlatego do zespołów biznesowych wpadają.

ŁK: Wiesz co, tak… Tylko trzeba… Nie powiem, że to jest zespół supportowy w kontekście firmy. Jednak nie powinien być też zespołem supportowym, że rozwiązuje super czyjeś problemy i robi „babysitting”, bo to jest… Dla mnie słowo „supportowy”, „wsparcia”, niesie konotacje…

SW: Te negatywne…

ŁK: Tak. Taką negatywną wizję „babysittingu”, więc…

SW: Nie. Może… Zespół wsparcia, który wspiera i pomaga. I ma po prostu polepszać życie innych.

ŁK: Tak. I słuchajcie, drugim punktem, który za tym idzie, to zdefiniowanie modelu operacyjnego. To jest problem, który zazwyczaj się olewa, a jest to coś według mnie krytycznego. Większość osób kiedy już do tego podchodzi – nawet managerów, techleadów – podchodzi do tego na szybko i zaraz przeskakuje do architektury i tego, czego nie zrobimy i w jaki sposób.

SW: Do zabawek.

ŁK: Tak. Do zabawek. Zamiast zdefiniować model operacyjny. Co rozumiem poprzez model operacyjny? To są 4 elementy. Podział odpowiedzialności i zbudowanie RACI (RASCI), czyli odpowiednie opisanie, co chcemy dostarczać w sposób formalny i kto za co odpowiada.

SW: Dobrze. To teraz się wtrącę i jak zwykle będziemy rozwijali wszystkie skróty, których używasz. RACI (RASCI), czyli to jest macierz odpowiedzialności. R – Responsible, A – Accountable, C – Consulted i I – Informed. Na czym RACI polega? Mówimy jawnie, kto w jakiej roli występuje. Czyli jeżeli ktoś ma jakiś pomysł lub inicjatywę, to mówimy z kim konsultujemy, czyli kogo informujemy, kto jest osobą odpowiedzialną i kto jakie role pełni.

ŁK: Tak.

SW: To nie jest tylko po to – co mi się podobało – żeby wyznaczyć tych od R i A, ale to jest też po to, żeby na poziomie firmy zakomunikować (to jest bardzo ważne, szczególnie w IT), kogo informujemy, czyli kto nie bierze udziału w decyzji. Chodzi o to, żeby każdy wiedział, że tylko informują. Aby zdawał sobie sprawę, że jak dostaje informację, to już nie jest moment na to, żeby teraz ten pomysł wywracał do góry nogami, bo jest tylko informowany. Jeżeli chce, żeby było inaczej, to w tym momencie się konsultuje z zespołem i tak dalej. Czyli pokazuje kto w jakim momencie procesu występuje. To jest super ważne.

ŁK: Tak, dokładnie. I to trzeba ustawić, niestety, wysokopoziomowo, bo to jest bardzo ważne. To nie jest detaliczne. Niektórzy siądą od razu i pomyślą, że muszą rozpisywać RACI-e detalicznie, co do tasków i innych rzeczy. Nie. Tu chodzi o pierwszy wysokopoziomowy podział, żeby było wiadome, co będziecie robić, co ta platforma będzie robić.

SW: Tak. Tu chodzi o samą platformę tak naprawdę. Co robimy i jak robimy. Dokładnie.

ŁK: Tak. I podział odpowiedzialności idzie za tym. Bo to jest trochę inna rzecz niż samo RACI. To jest już unormowanie tego. A podział odpowiedzialności, to jest powiedzenie, jak będą wyglądały punkty odcięcia na tej platformie. Można to przyrównać do modelów IaaS/PaaS, gdzie mam tzw. shared responsibility pomiędzy dostawcą cloudowym, a nami jako klientem. I to jest właśnie zdefiniowanie sobie tych punktów odcięcia, gdzie my jako platforma jesteśmy za coś odpowiedzialni, a gdzie nasz wewnętrzny użytkownik będzie za coś odpowiedzialny.

SW: Tak. I tu jest jedna bardzo ważna rzecz: musimy nie tylko brać pod uwagę nasz wishful thinking, ale też to, jaki skillset mają ludzie w zespołach engineerowych, biznesowych. Wiadomo, że byśmy chcieli, aby jak najwięcej odpowiedzialności przejęli, ale jeżeli nie mają pewnych umiejętności, to nie możemy im tego wrzucić, bo to się po prostu nie uda. Mamy generować wartość biznesową, pomagać w generowaniu tej wartości. To jest bardzo ważny element – żeby była jasna komunikacja, kto za co jest odpowiedzialny.

ŁK: Tak. Budowa takiej platformy i usługi zawsze będzie się skupiać na tym, dla kogo będziemy to robić i jak z nimi będziemy grać. Kolejną rzeczą, która często jest niewidoczna przez osoby techniczne (chociaż teraz przy wykorzystaniu clouda się to zmienia), jest model finansowy wewnątrz. Jak to będzie finansowane.

SW: Bo to nie będzie tanie.

ŁK: Tak. Zwykle prace na budowie jakiejś platformy… Załóżmy, że budujemy wewnętrzne podejście do K8s-a. Jeżeli nie bierzemy gotowego produktu z rynku na zasadzie OpenShift i wdrażamy by the bug na K8s-ie, to zajmie nam z rok czasu, aby to miało ręce i nogi.

SW: Ale nawet, załóżmy, że bierzemy tego OpenShifta. To nie jest tak, że go sobie bierzemy. Bo jeżeli ustalimy, że naszą platformę mamy bardziej jako passa, to mamy do zrobienia masę read me, edukacji, ustaleń odpowiedzialności, zarządzania zespołami, monitoringu, wsparcia i tego wszystkiego, co jest dookoła platformy i całego managementu. Nawet jak weźmiemy gotowego OpenShift-a czy gotowego AKS-a – cokolwiek weźmiemy – tam jest masa rzeczy do konfiguracji, żeby to zaczęło działać i żeby to wdrożyć w firmie. Bo to nie jest tylko kwestia tego, że wysyłamy e-maila: „Jest! Używajcie!”. Musimy zrobić cały onboarding platformy, tak jak każdego normalnego produktu. Bo to jest wewnętrzny produkt. Czyli musimy mieć dokumentację, testy itd.

ŁK: Dobra. Pójdźmy dalej, bo o tym zaraz pogadamy. Ostatnią rzeczą są oczekiwania, co do SLA/SLO.

SW: Jak najwyższe – wiadomo.

ŁK: Tak, jak najwyższe. I chodzi, aby jawnie powiedzieć, jakie są główne produkty platformy, którą chcemy dostarczyć. Jak już mamy wizję, to co chcemy dostarczyć. To tak naprawdę negocjacje, jakie chcemy mieć SLA/SLO. Więc zawsze to będą dwa światy: team platformowy – dostawca usługi –zawsze będzie chciał mieć na koniec dnia jak najniższą, żeby było jak najtaniej. Z drugiej stron im bardziej wysokopoziomowy jest odbiorca, tym chce mieć zawsze jak najlepiej, jak najszybciej.

SW: Nie, Łukasz. Ja bym to ujął inaczej. To jest pokazanie, ile kosztuje SLA/SLO. Ile te dziewiątki kosztują. Bo teraz mówimy, że: ustalenie. Ustalenie to jest takie, że np. każdy chciałby mieć jak najwięcej, ale jak pokażemy że dodanie jednej dziewiątki z tyłu kosztuje nas dużo więcej, nagle jest: „Ok, jednak tyle nie potrzebujemy”.

ŁK: Tak, to jest to. Tylko z drugiej strony też powiedzenie sobie – bo to jest istotne – dziewiątka przy platformie nie oznacza, że aplikacja takie będzie miała. I to też powiedzenie sobie, przy tym podziale odpowiedzialności, jakie to SLA tak naprawdę będzie. Zobaczmy, jak dostawca cloudowy na nas zrzuca pewne rzeczy.

SW: Tak, oczywiście. To bez dwóch zdań.

ŁK: Dobra. I to była część modelu operacyjnego, czyli: RACI, podział odpowiedzialności, finansowanie i oczekiwania, jeżeli chodzi o SLA/SLO. Teraz można zacząć przechodzić do technikalii, bo to jest ten moment, kiedy wiemy, co chcemy robić, i wiemy, jaki mamy model odpowiedzialności. To pora na zdefiniowanie sobie architektury naszej platformowy. Pierwszy element to zbudowanie pryncypii, czyli głównego już czwartego założenia naszej platformy. Nie niskopoziomowe, ale wysokopoziomowe założenia, których będziemy się architektonicznie trzymać. To będzie straszne, bo mamy tendencje – sam na to często choruję – że chcemy od razu schodzić do niskopoziomowych detali. Ale tutaj powinniśmy ustawić takie główne punkty (już spisane z tego, co wcześniej zdefiniowaliśmy), jak kierujemy tą platformą i jakie będą usługi (w takich wysokich założeniach), które będziemy dostarczać.

SW: Czyli które obszary nasza platforma pokrywa, a którymi obszarami muszą się zająć deweloperzy biznesowi.

ŁK: Tak, to jest ten element. Czyli np. założenia techniczne, że będziemy wymuszać coś na użytkowniku. Na razie wysokopoziomowo, ale tak. To wynika z tego, w co idziemy. Kiedy mamy pryncypia, to tak naprawdę jest już pora na określenie zakresu produktów. Bo to jest rzecz, która mam wrażenie, że przy platformie zawsze jest niejawna: „Zacznijmy sobie coś robić i nie nastawiajmy się już na techniczny wynik końcowy, co my dostarczymy”. To określenie zakresu produktów pozwoli nam wyznaczyć nasz production rediness, czyli kiedy i na jakich warunkach ta platforma będzie gotowa do użycia.

SW: A ja bym powiedział, że sfazowania tych produktów. Bo to nie jest tak, że wylatujemy w pierwszej wersji ze wszystkimi usługami, bo też musimy się nauczyć je obsługiwać. Lepiej jest etapami robić rollout i pomyśleć o tym, jak przygotować systemy biznesowe do tego, żeby potem, jak za pół roku wyjdzie kolejna funkcjonalność, one umiały to konsumować, żeby można było się przepiąć.

ŁK: Tak. To co powiedziałeś jest istotne. Jeżeli definiujemy zakres produktu, to na początek powinno być MVP, ale nie najmniejszy widoczny produkt, tylko najmniejszy wartościowy produkt. Dajmy przykład, jak robią to dostawcy cloudowi. Ich usługi, kiedy wychodzą w pierwszych wersjach nie są full blown, super kobyłami. Jak przypomnę sobie, jak wyglądały GKE, AKS, EKS-y czy inne zabawki bazodanowe, to one nie były super przyjemne. Tylko z biegiem czasu one są ciągle rozwijane. I w ten sposób trzeba na to popatrzeć. Dobra. Kolejną za to idącą rzeczą, którą dobrze jest wyciągnąć z podejścia cloudowego i tych dużych dostawców, jest standaryzacja. Jeżeli robimy platformę, to – w mojej opinii – nie ma miejsca na specjalne traktowanie i super klientów. W większości przypadków powinniśmy sobie powiedzieć, że mamy podział odpowiedzialności, mamy pryncypia i z tego wynika standaryzacja.

SW: A ja się tu nie zgodzę. O tym będziemy mówić trochę za chwilę, ale standaryzacja jest na starcie i to działa super. Na starcie faktycznie olewamy 20 czy 25% najbardziej kłopotliwych przypadków. Jest miejsce na to, że jak stawiamy K8s-a i potem wdrażamy workload ML-owe czy dodatkowe, dziwniejsze user case’y. Ale to robimy dużo później, jak już wszystko działa. Po prostu pokrywamy, idziemy od tego, która część pokryje największą część biznesową. Potem ten sam krok, do czasu spędzonego tak naprawdę. Do sytuacji dziwnych, kiedy mówimy: „A co będzie, jeżeli ktoś…”, dojdziemy, jak będzie na to moment, kiedy będzie taka potrzeba i te case’y wyjdą. Chodzi o to, żeby nie gdybać na samym starcie i nie standaryzować zbyt dużo, tylko robić to, co możemy w danym momencie zrobić.

ŁK: Zasada Pareta tutaj sprawdza się idealnie, czyli: 20% potencjalnych klientów zje 80% czasu.

SW: Tak, dokładnie. I 20% funkcjonalności będzie pokrywało 80% potrzeb, które de facto mamy.

ŁK: Tak, dokładnie. Standaryzacja jest bardzo ważna. Jeżeli robimy rzeczy platformowe, zazwyczaj chcemy to od początku automatyzować, utrzymywać pewne rzeczy, żeby potem… Do cyklu życia platformy jeszcze dojdziemy. Często po prostu chcemy mieć… Standaryzacja pozwala nam w przyszłości iść do przodu. I to jest istotne. Sprawia, że nie mamy niepotrzebnych rzeczy – tak jak niektóre organizacje, które przez 5 lat trzymają jakieś guano, bo inne guano na nich siedzi, a oni zobowiązali się do tego.

SW: Tak. Ale znów wchodzimy w problem, że zaczynamy projektować: a co będzie gdyby, usuniemy pewne standardy i może nigdy do nich nie dojdziemy. To jest – mówiliśmy wiele razy – architektura ewolucyjna. I tak też można do tego podejść. Ustalamy pewne zasady, umawiamy się na coś, ale nie lokujemy tego za bardzo, tylko pilnujemy, żeby ludzie za bardzo nie odchodzili od pewnego standardu. Bo jak robimy platformę, to z reguły proces trochę trwa i od momentu startu do momentu wdrożenia service mesh-a trochę czasu minie. W tym czasie może się dużo na rynku zmienić; systemy będą mogły robić co innego, my się więcej nauczymy i zobaczymy, czy jest sens dodatkowych opcji. Więc nie przygotowujmy tych serwisów, nie nakładajmy wymagań na zespoły biznesowe od samego startu.

ŁK: Tak. Tylko chodzi o to, że musi być ta wysokopoziomowa standaryzacja i jeżeli coś nie jest wartościowe dla szerszego grona, to nie powinniśmy – w szczególności na początku wytwarzania – skupiać się na takich scenariuszach. Przy określaniu sobie całej i definiowaniu standaryzacji, określamy sobie tak naprawdę co będzie używane szeroko. Szukamy elementów do impaktu i szerokiego użycia, a nie żeby spełnić zachcianki jednego teamu.

SW: Podoba mi się to, co powiedziałeś. Że szukamy. Bo czasami po prostu onboarduję kolejne teamy, kolejne produkty i potem szukam następnego obszaru, który możemy standaryzować. I patrzę, np. „Ok, to mogłoby iść jako jedno z pierwszych (format logowania, czyli identity)”. Patrzę jak są używane, jaki jest standard wśród zespołów – bo może być inny niż rynkowy – i po prostu to standaryzujemy, żeby potem wszyscy korzystali już z tego samego, bo z tego korzysta cała firma. Albo poddajemy dyskusji, że korzystamy z tego rozwiązania, ale chcemy przemigrować się na inny system i w tym momencie jawnie z organizacją i zespołami biznesowymi migrujemy się na nowy system, żeby oni w to wchodzili.

ŁK: Dobra. Kolejnym punktem jest samo delivery platformy. Tutaj nie chciałbym poświęcać dużo czasu, bo to jest po prostu czysta praca inżynierska. Jedyną rzeczą, którą mocno bym sugerował, to mieć od początku użytkowników, którzy sprawdzą, będą kontrybuować i będą dawali feedback. Czyli na tym etapie developmentu powinniśmy troszeczkę podchodzić – tak jak gdzieś wspominaliśmy parę odcinków wcześniej, to było chyba w R&D – że trzeba często wydawać i pokazywać. I tutaj w przypadku delivery platformy również powinniśmy komunikować, pokazywać to i dawać do testowania, żeby dostawać jak najszybciej feedback z zewnątrz. Bo nasze założenia przy użyciu nie zawsze będą tak oczywiste, jak to będzie wyglądało z drugiej strony.

SW: To się wiąże z tym MVP. Dla mnie MVP jest takie, że ktoś będzie mógł tego używać realnie na produkcji. To jest MVP. Bo póki nie będą mogli używać na produkcji, to nie będziemy mieli wkładu, który faktycznie taki będzie, że będzie na zasadzie: fajnie, byłoby gdyby, a nie: potrzebujemy tego i tego. To są dwa zupełnie inne słowa i co innego oznaczają.

ŁK: Tak. Development powinien jakiś pierwszy trafić na produkcję bądź może zostać użyty jakoś shadowing czy jako inne miejsce lub mało krytyczna rzecz – ważne żeby została odpalona. Musimy podejść z podejściem hypercare do takiego klienta, który chce na naszym developmencie robić coś produkcyjnie. Ale w ramach założonej troszeczkę standaryzacji na tym się uczyć i stabilizować.

SW: Ja się cofnę do tego, co powiedziałem. Nie musi być produkcyjnie. Możemy naszą platformę dać np. do hostowania wewnętrznych środowisk Dev, Test i po kolei środowiska onboardować na naszą platformę. Nie musi być produkcyjne.

ŁK: Tak i to wszystko zależy, co jeszcze dostarczamy jako platforma. Inną rzeczą będzie kawałek platformy data’owej, inne będzie budowanie usługi do tożsamości (bardziej zaawansowane), a co innego obrobienie clouda czy K8S-a jako platformy. I zawsze będą takie niuanse. Potem idzie produkcyjny Go Live, czyli już faktyczne wykorzystanie. Najważniejszą rzeczą z mojego Go Live’u jest upewnienie się, że wszystkie elementy, co do których się umówiliśmy w modelu operacyjnym i production redinessie, są faktycznie gotowe. Użytkownicy wiedzą, co z tym mają zrobić, a my jesteśmy w stanie ich poinformować przy onboardingu na platformę, czyli przy udostepnieniu tej platformy, jesteśmy w stanie dać im tę wiedzę. Nie chodzi o dokumentację, przykłady i szkolenia, bo na to jest oddzielny punkt, który jest bardzo nieoczywisty przy usługach wewnętrznych. To, Szymon, …

SW: Wiem, o czym mówisz.

ŁK: …coś do Go Live’a jeszcze dodasz?

SW: Nie. Wydaje mi się, że wyczerpałeś temat.

ŁK: Dobra. Marketing. To jest – moim zdaniem – najbardziej zaniedbana kwestia przy tym jak tworzymy platformę.

SW: Zgodzę się. Z jednym wielkim ale: to się bardzo mocno zmienia. Kiedyś to było w ogóle ignorowane i nie istniało, ale teraz jest coraz widoczniejsza i świadoma potrzeba, żeby marketing wewnętrzny był. I to mnie bardzo cieszy.

ŁK: Tak. I słuchajcie. Co rozumiem przez marketing wewnętrzny? To są trzy duże elementy. Pierwszy to jest dokumentacja naszej platformy. Nie powinniśmy pisać tej dokumentacji jako kolejne epopeje czy cokolwiek innego. Róbmy to tak naprawdę na pytaniach użytkowników. Zamiast odpowiadać mu mailowo, spisz je w FAQ-u. Każde pytanie klienta, to jest kolejna odpowiedź na to, jak coś zrobić na platformie. I tym powinna być dokumentacja (oprócz zasad, odpowiedzialności etc.). Coś, Szymonie, chcesz dodać?

SW: Ja się uśmiecham trochę, dlatego mnie wywołał. Bo to nie jest, Łukasz, marketing. To, o czym mówisz.

ŁK: Tak, ale wiesz co…

SW: To jest uproduktowienie de facto, ponieważ budujemy z platformy produkt. I potem do tego robimy marketing. Bo dokumentacja, to już mówiliśmy na przykładach, to jest to, że traktujemy platformę jako produkt realny…

ŁK: Tak, to jest jako produkt. Ale ja go wrzucam specjalnie do marketingu, żeby odnieść świadomość, bo… Fajne, co mówisz, ale z mojej perspektywy powinniśmy patrzeć na to też jakościowo, jako na element marketingowy.

SW: Ja się zgodzę w zupełności. Tylko jak pomyślimy o platformie jak o produkcie, to nam odchodzą takie rzeczy jak definition of done, SLO/SLA. Czyli rzeczy, które wymagamy od naszych systemów, które są user facing, dla użytkownika zewnętrznego też się przenoszą jak najbardziej do tego, co istnieje już. Nie wewnętrznego.

ŁK: Tak.

SW: Więc dla mnie to jest… Pierw robimy z tego produkt, potem wokół tego produktu (jak wokół każdego innego produktu) robimy marketing wewnętrzny – wychodzimy do innych stakeholderów, do innych zespołów, i mówimy: „Ej, korzystajcie!”.

ŁK: Dobra. Więc to jest jedna rzecz, czyli dokumentacja stworzona na bazie FAQ-u. Idąc dalej, z dokumentacji powinny iść przykłady użycia, czyli jakieś „referencyjne kawałki architektury” i proste how to guide, które kierują użytkownika technicznego, jak z tego ma skorzystać. To są dwie rzeczy. I teraz możemy mieć wyższość świąt Bożego Narodzenia nad wielkanocnymi, w którym miejscu to wrzucić. Ja to świadomie przesuwam w kierunku marketingu.

SW: Ja mam jedną wrzutkę. Bo budujemy platformę – mam nadzieję wielką – na bazie istniejących systemów. I odnośnie dokumentacji, tak się zastanawiam… Widzę taki ruch, żeby opisywać, jak to wygląda. Dokumentacja powinna być podzielona na dwie części. Jaki jest API, możliwości systemu pod spodem. Często tą platformą będzie coś na bazie K8s-a, więc dajemy szkolenia, linki do K8s-a. Nie będziemy tłumaczyć, jak działa, nie będziemy pisali read me, bo to nie ma po prostu sensu, bo potem standaryzujemy i opisujemy jak my, jakie limitacje i jak my go wykorzystujemy, jakie są standardy i tak dalej. Kluczem do tego, co mówię, jest to, że możemy spokojnie wspierać się zewnętrznymi dokumentacjami. Na starcie to, jak dla mnie, może być po prostu lista linków i kilka zdań odnośnie do tego, jak i co jest wykorzystywane i to jest tyle. To jest start. To nie jest oczywiście koniec naszej dokumentacji.

ŁK: Tak. Więc to jest właśnie tak, jak powiedziałem: trochę odpowiedzi w FAQ-u co i jak oraz wrzuta z wykorzystaniem zewnętrznych materiałów. W sumie tak robię, ale nie pomyślałem, żeby tu dodać. I przy marketingu jest bardzo ważna rzecz: promowanie wśród użytkowników, ale też wśród managementu. Dlaczego tak jawnie będę podkreślał ten management i użytkowników? Mieliśmy akcję, gdzie techniczny leadership w jednej organizacji się zebrał, bo była odpalana nowa platforma: podzielenie się doświadczeniami, cokolwiek i bloki dyskusyjne dla odbiorców. W pewnym momencie wylało się wiadro pomyj, że czegoś nie ma na platformie, a było obiecywane. I co się okazuje? Bardzo dobrze, że ktoś z managerów był świadomy, że osoba, która wylewa to wiadro pomyj konfabuluje.

SW: Ja dodam inny powód, czemu marketing jest taki ważny. Najgorsza sytuacja do jakiej możemy dopuścić, to że powstanie wiele platform. Widziałem sytuacje, że nagle mamy wiele systemów, które robią mniej więcej to samo. Powstały one tylko dlatego, że ktoś stwierdził: „Ok, ta platforma nie nadaje się…”

ŁK: Więc zrobimy to po swojemu.

SW: „…zrobimy po swojemu” – dokładnie. Albo ktoś nie wiedział, że coś w ogóle istnieje i zrobili po swojemu. I, Łukasz, na pewno widziałeś, że nagle w małych korporacjach z reguły jest kilka systemów, które robią dokładnie to samo.

ŁK: No wiesz co… widziałem. To było piękne. I de facto jak słuchałem, bo miałem taki jeden obszar w karierze, jak oglądałem w dużej globalnej korporacji, gdzie dowiedziałem się, że jest siedem czy osiem systemów na to samo, rozrzuconych po dużych rynkach geograficznych. I na koniec dnia mają dokładnie te same wymagania, tylko trzeba było scheme kolorków inną narzucić. I inny układ frontendu. (śmiech) Bo robią to samo, a opowiadają, że my mamy zupełnie inne wymagania. No, tylko wiesz co, tego w pewnej skali organizacji…

SW: Wiadomo, że nie unikniesz.

ŁK: …nie technologicznych nie unikniesz. W szczególności w nie technologicznych nie unikniesz.

SW: Tak, ale możesz limitować, czy tych systemów będzie osiem czy będzie ich trzy.

ŁK: Tak, dokładnie. Więc tutaj: promowanie. I jeszcze co do promowania, istotną rzeczą jest robienie jakiś cyklicznych… Przy marketingu to jest troszeczkę też przy cyklu życia. Pisanie release notes do managementu użytkowników, żeby wiedzieli, jakie są funkcjonalności, co planujecie, co się zmieniło. Czyli informowanie. I drugi element szkoleniowy tak naprawdę: zróbcie cyklicznie proste szkolenia z podstaw. Krótkie, żeby użytkownik mógł wejść, zobaczyć. Jedna rzecz jeszcze przy części szkoleniowej, przykładowej marketingu: powinny być na platformie jakieś sand boxy, które są łatwo dostępne dla użytkownika.

SW: Dodam jeszcze jedną rzecz, którą widziałem wiele lat temu w jednej firmie. Wypuszczając nowy produkt wewnętrzny, była tworzona przy każdym releasie nowa ulotka z informacjami co było robione. I to wszystko, o czym powiedziałeś, było zebrane w ładną, ułożoną graficznie prezentację, zajmującą 5 do 10 stron tak naprawdę. I to był fenomenalny selling point, bo z punktu widzenia dostawcy, to jest też o tyle fajne, że jako dostawca reklamujemy się w skali firmy: co zostało dostarczone, co się działo i jaka wartość została wytworzona za te faktury, które są wystawiane. Więc to nie jest tylko ważne w kontekście produktu, ale też w pewnym momencie właśnie z roli w jakiej występujemy. Że to musi żyć, musi być pokazana ta wartość i to musi być ładne. Mówisz o e-mailu. E-mail jest fajny, ale zrobiona łatwa prezentacja na 5 stron, taka do managementu, jest dużo lepsza.

ŁK: Znaczy… Tak, jest dużo lepsza. Wszystko zależy od tego, jakie mamy podejście i możliwości. Mówię bardziej o czymś minimalnym wartościowym. Więc nawet taki release note napisany językiem managementu jest bardzo dobrą rzeczą.

SW: Tak, ale okazało się, że wartość daje dużo większy zysk tak naprawdę. Kolejny punkt, jeżeli chodzi o support, bo to jest też ciekawy obszar.

ŁK: Tak. I wiesz co… to jest rzecz… Powiem tak: trzeba się zastanowić na temat ścieżki supportowej i jak to będziemy robili. Jedna rzecz: to wyjdzie nam dopiero po Go Livie.

SW: A ja miałem nadzieję, że o czymś innym powiesz, jak mówisz o supporcie. Bo dla mnie: ok – musimy ustalić itd. Ale coś, co wchodzi bardzo w zakresie odpowiedzialności: komunikując, że mamy platformę, musimy jasno określić, kto za który obszar supportu odpowiada. To nie jest tak, że ktoś wrzuci system i teraz idzie na urlop, zespołu biznesowego nie ma, a wy utrzymujcie 24/7 platformę. To tak nie działa. Mówimy, że utrzymujemy platformę, ale wy macie to monitorować. My dajemy narzędzia, gdzie…

ŁK: Ale to Wasza…

SW: …i tak dalej. Ale wy za to odpowiadacie. To jest bardzo, bardzo ważne. W sensie tworzymy, bo my w tym momencie wchodzimy w tą drabinkę supportu, wszystkie warstwy, które występują. I bardzo ważne jest, żeby mieć narzędzia wewnętrzne, które pokażą, kto, gdzie, na którym punkcie tej drabinki wystąpił błąd. Jeżeli błąd był np. typowo biznesowy, to idzie to do zespołu biznesowego. Jeżeli błąd był połączenia z bazą relacyjną jakąkolwiek, no to leci to do nas – bo to jest pewnie coś sieciowego. Więc o tym trzeba bardzo mocno pomyśleć, bo im więcej będzie przeniesionych ludzi i zespołów wewnętrznych na naszą platformę, tym bardziej będzie rósł over head utrzymania i może się skończyć na tym, że nie będziemy mogli robić żadnego R&D, bo będziemy w supporcie.

ŁK: Bo będziemy utrzymywać. Tak. I istotna rzecz: każdy z teamu platformowego, nawet jeżeli główną jego rolą jest co innego, powinien jeden dzień w miesiącu albo dwa dni w miesiącu supportować swoje rozwiązania.

SW: To jest o tyle ważne, żeby robić taki dogfooding. Zgodzę się. Ale to jest też ta opcja, o której chyba nie mówiliśmy, że nie budujemy zespołu platformowego od zera. Z reguły robimy migracje istniejących ludzi.

ŁK: Tak.

SW: I to jest ogromny zestaw umiejętności, które Ci ludzie muszą nabyć tak naprawdę. To jest droga wewnętrzna zespołu: jak oni idą, w co ich edukujemy, jaki zestaw umiejętności wymagamy. I to też trudne w budowaniu tych zespołów.

ŁK: To w ogóle… z tego można byłoby zrobić cały odcinek, jak nie dwa, bo jest do tego sporo podejść. Ale przejdźmy dalej. Mamy platformę, żyjemy i są nowe ficzery oraz kierunki rozwoju. I tak jak wcześniej mówiliśmy, raczej nie mówiliśmy o żadnym product managemencie i takich rzeczach.

SW: O produkcie ja mówiłem.

ŁK: Tak, o produkcie. Ale o product managemencie. Chodzi o podejście już biznesowe, podejście do product managementu zaczyna przynosić wartość w momencie, kiedy już jesteśmy na produkcji i planujemy, co będzie dalej. Bardzo ważną rzeczą jest słuchanie wtedy feedbacku użytkowników i ciągłe szukanie elementów, które są szeroko wymieniane.

SW: Ale to znowu wracamy do tego, że traktujemy platformę jako normalny produkt. Czyli szukamy ficzerów, mamy product discovery, komunikujemy road mapę… To jest produkt jak każdy inny, tylko klientem jest klient wewnętrzy. Więc nawet bardziej ryzykowny klient niż zewnętrzny.

ŁK: Z pewnej perspektywy klient wewnętrzny może być (jeszcze w szczególności dla utrzymujących) może być – nie bójmy się tego określenia – upierdliwy.

SW: Tak. On często będzie limitujący. Szczególnie, że budując jakąkolwiek platformę w dużych korporacjach, z reguły produkt wewnętrzny, nasza platforma, nie będzie zawierała najnowszych supertechnologii, bo technologia idzie szybko do przodu. Więc trzeba ludzi uświadomić, co, jak i czemu. Więc wracamy do standaryzacji, o której mówiłeś. Jeżeli będziemy mieli dobrze ustalone interfejsy i dobry zbiór odpowiedzialności (za co my bierzemy odpowiedzialność, ale za co odpowiadają już systemy), to będziemy mogli upgrade’ować kolejne rzeczy i rozwiązania, a platforma nie zrobi się przestarzała. To jest bardzo ważne, aby to ustalić.

ŁK: Tak. I troszeczkę mi płynnie wszedłeś w cykl życia.

SW: Taki był mój cel.

ŁK: Tak. czyli… Słuchajcie. Cykl życia jest rzeczą, o której nie myślimy, ale właśnie trzeba pomyśleć. To jest element w całym procesie, o którym trzeba cały czas myśleć, nawet na początku. Zakładamy cykl życia na zasadzie aktualizacji, upgrade’ów, ale również wygaszania. I powiedzenie sobie, powinniśmy mieć w SLA/SLO i w oczekiwaniach… powinniśmy zostawić sobie furtkę na możliwość również wygaszania platformy.

SW: To jest ciekawe, bo z reguły będzie Wam ciężko wygaszać rzeczy platformowe. Bo to będzie wymagało współpracy od zespołów biznesowych, często do systemów, które już nie są utrzymywane. A oni nie mają aktualnego rozwoju albo przypisanego zespołu biznesowego. Więc odnośnie wygaszania bardziej bym przechodził w opcję migracji, bo wygaszenie nie zawsze się udaje. Przy migracji kolejna platforma będzie wyglądała tak i tak, ale musimy starszą zostawić w jakiejś wersji, żeby była utrzymywana – będzie miała gorszy SLA/SLO albo będzie miała gorsze wsparcie, bo mniej ludzi będzie przy niej pracowało, ale chodzi o przechodzenie z kolejnej wersji na kolejną wersję. Wygaszenie – fajnie byłoby, ale nie zawsze się udaje.

ŁK: Tak, ale wiesz… teraz pomyślmy. Dlatego ja mówię, że próba robienia najczarniejszego scenariusza z perspektywy użytkownika może być dla nas w pewnych miejscach ratunkiem. I też w zależności od tego, co my będziemy tam świadczyć. Jest bardzo dużo rzeczy i często się okazuje, że z pewnych funkcjonalności na początku dużo osób korzystało, a po trzech latach okazuje się, że zostaje tylko jeden klient, który nam ciąży i dla niego to trzymamy. Mam TIP, którego używam, jak robimy rzeczy infrastrukturalne, nazywa się: security. CVE i inne ciekawe rzeczy naprawdę w dzisiejszych czasach upraszczają jako element negocjacyjny.

SW: Ja powiem tak: widziałem zbyt dużo antycznych systemów, które nie mają nawet wsparcia i dalej są wykorzystywane. Ja mam inne podejście. Ponieważ znowu platforma jest produktem, więc pokazujemy, ile utrzymanie tego klienta nas kosztuje w danej walucie. Jeżeli podamy odpowiednią wartość, powiemy, że: „Ok, nas to kosztuje dziesięć tysięcy miesięcznie”, nagle się okazuje, że: „Ok, ale bez jakichś funkcjonalności”. Albo: „Migracja tego systemu kosztuje nas trzydzieści tysięcy” , i nagle się okazuje, że: „Ok” i po trzech miesiącach wychodzimy na plus. Jeżeli mówimy o pieniądzach, to jest to element, po którym każdy na każdym poziomie zrozumie.

ŁK: Tak. Tylko to są sytuacje, do których chcielibyśmy nie dążyć, żeby tam nie dochodzić jako właściciel platformy.

SW: Tak, ale na nas czekają mimo wszystko. Wszystko nas kosztuje ileś pieniędzy. Jeżeli pokażemy, jakie decyzje ile nas kosztują, to jest normalna rozmowa. Rzeczy idą do przodu.

ŁK: To jest dogrywka podsumowania. Dajesz, Szymon.

SW: No to, to jest Szymon z przyszłości. Wyłapaliśmy, że brakuje nam podsumowania. No to podsumowanie właśnie nagrywamy. Zwinnie, agile. Dobra, Łukasz, trochę tej rozmowy było, więc przydałoby się kilka podstawowych punktów zebrać od Ciebie. Jakie TOP 3 chciałbyś przekazać?

ŁK: Dobra. TOP3. Ustal model operacyjny, RACI i podział odpowiedzialności. I to jest w ogóle dla mnie…

SW: Czyli ownership.

ŁK: Tak. Ownership. To jest dla mnie krytyczne i bez tego nie ma sensu ruszać dalej. Druga rzecz: zadbaj o production rediness, żeby wiedzieć, co to jest. I zadbaj o to, co nazywaliśmy marketingiem platformy.

SW: Dobrze. To ode mnie. Platforma jest produktem. To jest super, super ważne. Musi mieć product ownera i business ownera. Musimy pokazać jej wartość, co robimy, jak robimy, co wygaszamy, jaka jest nasza road mapa, co będziemy robili. Zgodzę się z Tobą – marketing wewnętrzny jak najbardziej też. To jest punkt pierwszy. Jeżeli chodzi o drugi punkt ode mnie: powiedzenie MVP, czyli tego, co wspieramy teraz, co wspieramy później. Nie napalajmy się, nie budujmy opus magnum na samym starcie. To jest dużo fajnej zabawy, wiec moglibyśmy, tylko po prostu lepiej minimalnie – ktoś używa, lecimy dalej i ładnymi etapami możemy to wdrażać. Przemyślmy działanie, nie róbmy opus magnum, nie róbmy przekombinowania na samym starcie. Ktoś musi tego używać. I trzecie: pamiętajmy o Pareto. Naprawdę większość klientów wewnętrznych ma dużo mniejsze potrzeby i z czegoś dużo mniejszego a użytecznego będą bardziej zadowoleni niż nam się wydaje. Więc ponownie podkreślę: niech ktoś tego zacznie używać. Bez tego się nie uda. I tyle tak naprawdę.

ŁK: Na razie!

SW: Hej!