Zespół Delivery vs produktowy

Paweł Tomkiel
Cześć wszystkim. Dzisiaj w formie wideo nagrywamy również odcinek podcastu zwinne organizacje. Do tej rozmowy zaprosiłem Maćka Oczko. Cześć Maćku.

Maciek Oczko
Cześć Pawle.

Paweł Tomkiel
Będziemy rozmawiać właśnie o tych dwóch podejściach. Będziemy rozmawiać o tym, czym się różnią, jak je definiujemy, o tym, jakie są plusy, jakie są minusy. Gdyśmy mogli zacząć Maciek od tego, kim jesteś. Ty jesteś Senior Engineering Managerem w Snowflalke, ale gdybyś mógł powiedzieć naszym słuchaczom trochę więcej o sobie, trochę więcej o swoim doświadczeniu.

Maciek Oczko
Jasne, jasne. Dziękuję za zaproszenie powtórne. Parę słów o mnie. Myślę, że najważniejsze o mnie to jest to, że jestem dumnym tatą trójki maluchów i mężem też oczywiście. Jeżeli chodzi o tę zawodową stronę, tak jak wspomniałeś, Senior Engineering Manager w Snowflake. Poprzednio przez wiele, wiele lat, niemalże 10, pracowałem w firmie podwykonawczej – software house, tak jak się to potocznie mówi, czy w firmie konsultingowej. A potem przeszedłem właśnie do produktu, jakim jest Snowflake.

Paweł Tomkiel
O tym rozmawialiśmy już w odcinku podcastu, który nagraliśmy jakiś czas temu. Do tego odcinka również odsyłamy, bo tam de facto rozmawialiśmy o tym, jak to było zorganizowane, jak przeszliście z software house do firmy produktowej Snowflake. Maciek, gdybyś mógł na sam początek powiedzieć o Snowflake, więcej o firmie i może o tym, jak jesteście zorganizowani, macie swój produkt, ale domyślam się, że przy tak dużej ilości osób, ile jest obecnie osób w Snowflake?

Maciek Oczko
Z kilka tysięcy.

Paweł Tomkiel
To nadal wiesz, potrzeba nad tym jakąś formę governance nałożyć jednak. Więc gdybyś mógł powiedzieć więcej może o samej strukturze organizacji.

Maciek Oczko
Jasne to może 2 słowa o Snowflake jako takim. Czym to w ogóle jest, co to za produkt. Snowflake powstało już 10 lat temu, tak mi się wydaje. Niektórzy to określają jako po prostu baza danych w chmurze, myślę, że to jest duże uproszczenie, niemniej coś w tym jest. To jest baza analityczna, silnik bazodanowy, służący do celów analitycznych, który jest w chmurze. Wręcz w wielu różnych chmurach. Takie były początki, potem byliśmy taką powiedzmy z siedem, pięć lat temu, hurtownią danych w chmurze. Znowu jakby kolejny stopień ewolucji. Teraz jesteśmy na takim etapie, który nazywamy data cloud, czyli w ogóle dane, to jest to, czym żyjemy i oddychamy. Chcemy udostępniać naszym klientom możliwości analityczne, maszyny learningowe związane z danymi, po to, żeby oni po prostu mogli je tam wrzucać i jak najwygodniej, jak najłatwiej konsumować do jakichś takich swoich celów business intelligence analitycznych, być może nieco też bardziej skomplikowanych, związanych z data science. Także to wszystko to jest Snowflake. Jeden produkt, tak jak wspomniałem wielochmurowy. To jest też znacząca rzecz z punktu widzenia naszych klientów, ponieważ wiemy wszyscy, czy to jest dość powszechne, że chmura to jest ta przyszłość, tam się powinniśmy przenosić, to jest tam, gdzie bezpieczeństwo i elastyczność. Natomiast duzi gracze, duże firmy sektora enterprise też patrzą na to jeszcze szerzej. Ten multicloud, dostępność, co, jeżeli coś się stanie, będzie awaria itd. To wszystko ma znaczenie. Także przekrój danych i chmury, to jest to, gdzie jest Snowflake.

Paweł Tomkiel
Okej, a kwestia organizacji.

Maciek Oczko
Kwestia organizacji, więc ja będę mówił tylko za engineering, no bo to jest jakaś taka moja struktura. Jest nas tam obecnie, myślę, że już około tysiąca osób w engineeringu, także to jest już niemała organizacja. Oczywiście jeszcze nie jesteśmy, jeszcze, tak mówię jeszcze, nie jesteśmy Googlem, nie jesteśmy AWS, gdzie to są już dziesiątki tysięcy inżynierów różnych kategorii. Natomiast tu już jest sporo, prawda? Także organizacyjnie myślę, że zacznę od może takiego podziału niestandardowego, ale geograficznego. Mamy pięć biur inżynierskich, dwa w Stanach, jedno w Toronto, w Berlinie i w Warszawie. To już nas troszkę tutaj układa, bo każde z naszych biur z jednej strony jest bardzo niezależne i autonomiczne. Bardzo się staramy, żeby zespoły inżynierów, które są w danych lokalizacjach, potrafiły działać z maksymalną taką dozą właśnie autonomii, jeżeli chodzi o to, co budują. Z drugiej strony oczywiście jesteśmy zobowiązani siatką zależności, tak jakby nie da się zupełnie w izolacji pracować. Szczególnie że my pracujemy rzeczywiście nad jednym produktem, nie mamy jakiejś palety różnych produktów. Tylko Snowflake, to jest po prostu, jak idziesz do Snowflake, to używasz Snowflake i koniec. To jest jakby coś, co jest dla nas bardzo ważne. Taka jakaś prostota myślenia o tym, o platformie. Wracając do organizacji, w ramach podziałów geograficznych każde biuro stara się mieć jakąś taką swoją domenę powiedzmy. To tak z angielskiego mówimy, że to jest jakiś charter i im jesteśmy więksi, tym jest też to troszkę trudniejsze, no bo te domeny coraz bardziej się mieszają. Tutaj są jakieś tam rzeczy związane ze SQL, to z serwisu, to z jakimiś pipelinami. Przepraszam za anglicyzmy, ale myślę, że trudno mi będzie od tego uciec w tej rozmowie. Więc to się coraz bardziej miesza, niemniej staramy się, żeby każde biuro miało taką swoją nazwijmy to etykietkę, jakąś taką główną domenę, którą się zajmuje. Natomiast oczywiście różnie to wychodzi w praktyce. Druga rzecz, jeżeli chodzi o organizację, no to oczywiście jesteśmy podzieleni na zespoły projektowe. Tylko jeszcze przed tym, może bym powiedział, zanim zespoły projektowe, to jeszcze są takie obszary. My to nazywamy obszarami. Czyli na przykład mamy obszar, który się zajmuje tylko organizacyjnie front endem, czyli tą warstwą, nazwijmy to, doświadczenia użytkownika. Mamy obszary, które właśnie się zajmują tymi niższymi warstwami jak infrastruktura, cloud engineering, ale też nawet w samym produkcie, że tak powiem inżyniersko, on też jest warstwowy. To znaczy, są rzeczy, które są dość niskopoziomowe, takie średniopoziomowe, no i te, które są najbardziej skierowane do klienta.