33. Plusy i minusy własnego działu IT – Łukasz Grajewski – Szopex Dutkiewicz

Grzegorz Frątczak: Cześć Łukasz!

Łukasz Grajewski: Cześć! Miło Cię znowu słyszeć.

GF: To już drugi raz w podcaście, bo ostatnio rozmawialiśmy na tematy różne, związane z e-commerce’m – odnośnie  branży obuwniczej, o tych wszystkich 8 sklepach. O 8 latach doświadczenia Łukasza. I zeszło nam też, już tak trochę offline’owo, na temat tego, jak oni rozwijają sklepy technicznie. To trochę moja bajka, ale z drugiej strony Łukasz i jego firma mają ciekawe podejście i ciekawe doświadczenia. I dlatego dzisiaj chcieliśmy też chwilę o tym pogadać.

ŁG: Tak jest. W rzeczy samej.

Wyzwania współpracy z zewnętrznym Software House’m

GF: Łukasz, zróbmy więc może w takim razie podsumowanie. Jak to było? I jak to jest teraz?

ŁG: Mamy trochę wyzwań. Ponieważ 8 sklepów nie pisze się samo, więc potrzebujemy do tego całkiem sporo zasobów. Patrząc z perspektywy historycznej, jak to wyglądało, gdy przyszedłem do firmy w 2013 roku – sklepy wówczas raczkowały. Była platforma dostarczana przez zewnętrzny Software House. To nie była żadna z tych platform, które znamy teraz na rynku czy Presta, czy Magento, czy jakiekolwiek pudełkowe rozwiązania. Nic z tych rzeczy. Powiedzmy, że był to, jakiś tam dedykowany system, dostarczony przez zewnętrzny Software House i tyle. I rzeczywiście, gdzieś tam powiedzmy ten Software House miał za zadanie to rozwijać.

Nie bardzo mieliśmy to uporządkowane wówczas. Ja dosyć szybko przejąłem zadania związane ze współpracą z tym Software House’m. Pracowaliśmy wtedy na systemie Redmine, czyli takim powiedzmy ticketowym systemie. Myślę, że w branży dosyć znanym. Bardzo szybko okazało się, że było kilka tysięcy tasków rozpoczętych przed laty, nigdy nie skończonych. Tak naprawdę, nie było żadnego procesu nadzoru nad tymi zadaniami, które gdzieś tam sobie przepływały. Generalnie – wolna amerykanka.

Były wyzwania i to dosyć spore, ponieważ mieliśmy osobno ERP-a, osobno platformę e-commerce’ową. No i zaczęły się wyzwania, z którymi się wiele e-commerce’ów mierzyło. Na przykład: jak tu zsynchronizować stany magazynowe, tak żeby towar nie sprzedawał się równolegle w 2 kanałach dystrybucji. Jest to szczególnie istotne przy towarze, którego zbyt dużo nie mieliśmy, o czym już mówiłem w poprzednim odcinku. I pierwsze sposoby wymiany informacji odbywały się przez zapomniany już chyba – ja nie pamiętam, kiedy używałem – protokół FTP, w plikach. Architektura była taka, że każdy sklep miał swoją bazę lokalną i z tej bazy, co godzinę, na tego FTP-a szedł plik tekstowy. Platforma zbierała pliki z tego FTP-a i się wymieniała informacjami. Gdy coś nie zagrało na którymś z 50 lokali, to nie było stanów z tego lokalu. Powodowało to: anulację zamówień, wzmożony ruch w biurze obsługi klienta i tak dalej. Więc katastrofa.

Druga rzecz – infrastrukturę serwerową mieliśmy gdzieś tam swoją, hostowaną w jednym z takich centrów hostingowych. No bo tak nam doradził zewnętrzny Software House – że to będzie takie super i fajnie. Że będziemy mieć swoje, że bezpieczeństwo danych i tak dalej. Szczerze mówiąc, w tamtym czasie nie mieliśmy zbyt wiele pojęcia o tym, jak samemu tym zarządzić.

Okazało się, że przy jakimś tam tempie wzrostu, z początku, pewnie 1000% rocznie, albo i lepiej, te serwery tak naprawdę w moment trzeba było skalować w pionie. Czyli, tak naprawdę – dokupić pamięć,  dokupić procesy, dokładać kolejne maszyny. Zrobiła się z tego naprawdę gruba sprawa. To też nie do końca było fajne.

No i chyba jedna taka rzecz, która – teraz uważam, że działa całkiem przyzwoicie, a wówczas nie było jej w ogóle, nawet nie mieliśmy świadomości, że coś takiego istnieje. Nie było w ogóle zdefiniowanego procesu wytwarzania oprogramowania – jakkolwiek. Więc nie dało się tym w ogóle zarządzić. Był to, po prostu, jakiś worek chaotycznych zadań, które trzeba było zlecać. Mówię o tym z premedytacją, bo wierzę i wiem, że wiele firm dalej w ten sposób funkcjonuje. Że to jest powiedzmy taki worek zadań. Zleca się coś tam, do jakiegoś tam zewnętrznego Software House’u i “zróbcie”. Tak na prawdę, nie wiadomo jakie są priorytety, co jest ważniejsze i tak dalej. Co o tym myślisz?

Zarządzanie priorytetami rozwijając platformę ecommerce

GF: Bardziej tutaj mówisz o tym, że po prostu, co nam wpadnie do głowy to wrzucamy do zrobienia, nie zastanawiając się głębiej, czy to w ogóle nam jest potrzebne?

ŁG: No na przykład.

Myślę, że częstym problemem jest to, że po pierwsze wiele osób jest uprawnionych do tego, żeby wrzucać takie zadania.

GF: Tak…

ŁG: To jest jakiś kłopot.

Warto więc  przed zespołem IT czy to zewnętrznym, czy wewnętrznym postawić filtr w postaci chociażby product ownera albo analityka biznesowego, albo powiedzmy – chociaż koordynatora tych zadań.

GF: Tak.

ŁG: Żeby tak naprawdę, developerzy skupili się nad tym, na czym się znają, a nie na rozmowie z biznesem, bo to często się kończy źle. Więc to tak sobie wyglądało. No ale mieliśmy mówić trochę o retrospekcji i jak jest teraz, więc na razie wróćmy do tego.

GF: Wasze sklepy, pewnie są teraz gigantami, w porównaniu do tych, które my obsługujemy. I sklepy, które obsługujemy mają tam 200, 300 tys. obrotu na miesiąc, do paru milionów na miesiąc, to tego takiego problemu nie mają. Ponieważ, zazwyczaj my kontaktujemy się z właścicielem, który zazwyczaj wie o co chodzi. Albo E-commerce Managerem, który ogarnia te rzeczy i on jest takim filtrem, i zazwyczaj on to filtruje. To jest jedna rzecz.

Z drugiej strony, tam też są ograniczenia budżetowe i nawet nie chodzi o ograniczenia zasobowe po naszej stronie, ale wiadomo, że właśnie oni czują każdą złotówkę, więc sami tego pilnują. A z trzeciej strony, od nas jest opiekun klienta, który często się kłóci z klientem: “Po co Wam to w ogóle?”. Bo często, tak jak Ty mówisz, wszyscy wrzucają różne pomysły i później jest pytanie: “Ale po co to?”. Tak?

I u nas dość często się okazuje, że jeśli nam odpowiedzą na: po co Wam, jaka jest potrzeba? To mówimy: “Hej, ale zamiast robić to 3 dni, jeśli zmodyfikujecie chociaż te założenia biznesowe, które i tak będą spełniać cele, to zrobimy to w pół dnia”.

ŁG: Tak.

GF: Albo w ogóle się okazuje, że wybijamy z głowy pewne rzeczy – mówiąc brutalnie, ponieważ rzeczy, które robimy powinny sprzedawać albo optymalizować. A często to jest takie widzi mi się. Mówię “często”, ale zdarza się, że są to pomysły typu: “A bo to inni mają”, tak?

Tak jak powiedziałeś w poprzednim podcaście, że robicie wideo-chat. Teraz wszyscy się rzucają na to. Ale to nie działa. Tak jak powiedziałeś – tak jakby rynek jeszcze nie dojrzał. Zrobimy taki test. Jesteście dużym sklepem, więc możecie wysupłać na to zasoby, przetestować i będziecie liderem branży. Z drugiej strony mniejsze sklepy – to warto zainwestować w coś co przyniesie realnie zwroty. Jak byliście mali, to pewnie nie wysyłaliście wszystkiego. Tak?

ŁG: Tak. Wiesz, myślę, że takie podejście: “Nie róbmy rzeczy, które jeszcze na rynku nie działają”, jest generalnie podejściem słusznym. Lepiej kopiować, to co już działa. Naprawdę, nie musimy wymyślać koła od nowa, żeby się odnaleźć w biznesie.

Ale przy pewnej skali i przy pewnym zestawie wartości, takie testowanie hipotez, czyli: czy dana hipoteza trafi w nasze wyobrażenia o potrzebach klienta, też jest jakimś elementem budowania przewagi konkurencyjnej. Więc myślę, że mix tego jest jak najbardziej wskazany.

W jakichś określonych proporcjach. Czyli, my staramy się coś tam testować, ale nie jest to core naszej działalności. O – może tak.

GF: Tak…

ŁG: Ale wiesz, wracając do tego, to chwała Wam, że odwodzicie klientów od nieuzasadnionych biznesowo pomysłów. U nas w firmie też od jakiegoś czasu operuje w ogóle takie pojęcie, jak uzasadnienie biznesowe. Nie zawsze takowe było. Czyli nie, że dany Iksiński wymyśli sobie funkcję, to musi jeszcze uzasadnić po co to jest i gdzie będzie zwrot z tego. I kiedy będzie ten zwrot. Więc to jest ważne.

Znam przykład dużej apteki, oczywiście brandów nie będziemy wymieniać.  Apteka, która ma platformę, w której jest kilkaset funkcji i zostało zmierzone, że niecałe 10% tych funkcji jest wykorzystywanych. Cała reszta leży odłogiem. Po prostu, została kiedyś tam napisana, bo komuś się wydawało, że ona będzie istotna.

GF: 10%?

ŁG: Tak.

GF: Okej.

ŁG: Można by tutaj zapytać, jak wyglądała czasochłonność tworzenia pewnych funkcji. Powiedzmy, że liczymy na sztuki: czyli, powiedzmy, że mamy 700 funkcji. 70 jest wykorzystywanych, 630 leży odłogiem. Tam były jakieś zdefiniowane granice, tak naprawdę, nie pamiętam teraz, ale powiedzmy, że jeżeli funkcja nie została ani razu użyta przez 3 miesiące, uznawano ją za martwą. Więc myślę, że jest to wyzwanie, żeby tym bardzo sprytnie zarządzać, bo w innej sytuacji, to jest nic innego niż marnowanie zasobów.

GF: No i kosztów, które drążą.

ŁG: Tak.

GF: I komplikowania całego sklepu i systemu, co powoduje później droższy rozwój tego systemu i komplikacje.

ŁG: Tak. A w pewnym momencie, właściwie – niemożliwość rozwoju.

GF: Tak.

ŁG: No więc, myśmy od takiego etapu wyszli. Obecnie dalej mamy tę platformę własną, czyli dedykowaną.

Zalety i wady własnego działu IT

GF: Ale już nową – dedykowaną, że tak się zapytam?

ŁG: Nową.

GF: I co? Sami pisaliście?

ŁG: W międzyczasie, od tego momentu, gdy mieliśmy zewnętrzny Software House, udało się zbudować zespół in house, który tak naprawdę, jest odpowiedzialny za utrzymanie całej platformy, całej infrastruktury związanej z IT w firmie.

GF: Jak to jest mieć zespół in house w porównaniu do zewnętrznej firmy?

ŁG: Moim zdaniem, dużo fajniej jest mieć ten komfort, że ma się zespół in house. Oczywiście, jak wszędzie – są plusy i minusy.

Tak naprawdę, zyskujesz bardzo dużo na elastyczności i takich rozwiązaniach, które są dla Ciebie. Jeśli masz jakiś pomysł, ideę, która – uwaga! – ma uzasadnienie biznesowe, to jesteś w stanie to wdrożyć dużo szybciej niż z zewnętrznym partnerem. Szczególnie jeśli mówimy o jakichś rozwiązaniach pudełkowych.

Jeżeli mamy Software House zewnętrzny, no to też inaczej. To tego problemu nie ma. Ale tak naprawdę myślę, że drugim ważnym elementem jest takie merytoryczne partnerstwo z zewnętrznymi podmiotami. Dla Ciebie też na pewno jest ważne to, żeby mieć z kim rozmawiać po drugiej stronie. I wiemy obaj, że jest z tym różnie.

GF: Tak.

ŁG: My jesteśmy partnerem, z którym można porozmawiać, co też generuje bardzo fajne możliwości, chociażby, w takich rzeczach jak negocjowanie kontraktu. Inaczej się rozmawia. Również, czasem mamy szanse rynkowe i wdrażamy rzeczy, których jeszcze na rynku nie ma. Jakieś tam beta wersje, tego typu rzeczy. Dostawcy pewnych usług są w stanie z nami rozmawiać po partnersku, dzięki temu, że też mamy jakieś zasoby wewnętrzne.

Z kolei minusem, myślę, że są wyższe koszty. I te koszty są absolutnie nieelastyczne. Jeżeli na przykład wybucha pandemia, jest lockdown, jakaś część naszego biznesu została wysadzona w powietrze – myślę o offline’ie. Mając zewnętrznych partnerów, to teoretycznie i praktycznie też możesz negocjować. Możesz na przykład wyciąć jakąś część usługi i tak dalej. Wiadomo, że każdemu zależy na przetrwaniu takiej relacji. Gdy masz to wewnątrz, no to, to masz. Dalej masz ten koszt. Więc to jest minus.

Koszty własnego działu IT vs koszty współpracy Software House’em

GF: Powiedziałeś, że jest droższe niż zewnętrzne. Dobrze usłyszałem?

ŁG: Że jest droższe niż zewnętrzne?

GF: Utrzymanie takiego zespołu.

ŁG: Takie mam przekonanie. Poza kosztami etatów masz… Jak masz z zewnątrz, to przede wszystkim płacisz za konkretny efekt. A tutaj dochodzą Ci koszt zarządzania tym wszystkim. Czyli tak naprawdę nie możemy o tym zapominać, że koszt IT, to nie jest: koszty etatów razy liczba tych etatów i koniec. Bo, po pierwsze, ktoś musi tym zarządzić i tak naprawdę jest to kupa pracy, żeby dowozić pewnie efekty w danym czasie. Z zewnętrzną firmą zabezpieczasz się umową i tak naprawdę płacisz, gdy masz efekt.

Druga rzecz, to wszystkie koszty dodatkowe, operacyjne, administracyjne – że tak to nazwę. To też jest jakiś % w całości.

No i kolejna rzecz, że tak naprawdę koszt rozwoju na “bez rozwoju”. To trudno mówić tutaj o dalszym budowaniu zespołu i ewolucji.

GF: A zdradzisz słuchaczom, jaki duży macie u Was zespół IT, na te 8 e-commerce’ów?

ŁG: W tym momencie 6-osobowy. I to jest zdecydowanie za mało, patrząc na liczbę przedsięwzięć, projektów, które chcielibyśmy realizować równolegle.

Czy znalezienie programistów do działu IT jest proste?

GF: I co teraz? Jak mówisz za mało, no to zatrudnijcie.

ŁG: Grzesiek, daj mi namiary – bardzo chętnie przerwę podcast i będę dzwonił, zapraszał na rozmowy.

Zapewne wiesz, jak wygląda obecnie rynek i rzeczywiście zatrudnienie człowieka do IT, jest wybitnie trudne. Szczególnie, przypomnę, że my pochodzimy z Olsztyna i tam mamy centralę. Oczywiście, w obecnych czasach, jasne, że pracujemy zdalnie, ale generalnie dążymy też do tego, żeby to był model jakiś taki mocno hybrydowy. Czyli duża część, przynajmniej dla deweloperów pracy zdalnej – z możliwością i 100%, więc cała Polska niby do dyspozycji. Ale jest to trudne. To jest też taka bariera rozwoju.

GF: Tak, to jest. Mamy paru klientów, którzy mają, może nie 6-osobowy dział e-commerce, ale 1 osobę u siebie, a my jesteśmy tym zewnętrznym partnerem, który pozwala skalować. Wręcz, to my zarządzamy programistą, który jest wewnątrz tej firmy i go pilnujemy.

ŁG: Ciekawe.

GF: Może nie pilnujemy, ale tak jakby – wspieramy go. My ten proces narzucamy. Bo jeśli mamy 1-osobowy dział, to tak jak powiedziałeś, te procesy trudno ułożyć. Jak masz 6-osobowy i pewnie jest tam jakiś szef, to on pilnuje, żeby to wszystko było poukładane.

Przy 1-osobowym dziale, polegamy na tym, że ten programista wszystko ogarnie. Natomiast, programista zazwyczaj jest specjalistą, ekspertem w swojej dziedzinie, a nie managerem, który pilnuje procesu, żeby to oprogramowanie dobrze powstawało. Tak?

ŁG: Tak. Tu też dochodzi kwestia technologii poszczególnych. No, Full-Stack Developer – okej, istnieje takie pojęcie, jednocześnie ja w nie tak umiarkowanie wierzę.

GF: Tak. Poproś Backednowca, żeby zakodował szary. Pokażesz mu 2 szare na grafice, to on zrobi jeszcze inny szary – kompletnie nie ten.

ŁG: Dokładnie tak.

GF: Ja to nazywam u programistów: “ile szarości widzisz?”.

ŁG: No tak. Kierunek, z racji na te bariery, mamy taki, że teraz po  refakturyzacji platformy, platforma jest…

GF: Refakturyzacja, czyli pewnie przepisanie od początku, całej na nową technologię.

ŁG: Tak. Mieliśmy ten kod zastany. Nie było do niego dokumentacji, więc ciężko było tutaj o 1-osobową, czy 1-działową odpowiedzialność, czy za wyniki dalszego procesu deweloperskiego. Więc, na szczęście, teraz mamy to już za sobą. Dwa – zmieniliśmy zupełnie architekturę, jeśli chodzi o hosting. Przeszliśmy na clouda w całości. To też jest temat, dzięki któremu jesteśmy w stanie się mocno skalować,  co jest nie do przeceniania przy jakichś tam pikach e-commerce’owych. A my mamy jeszcze takie wyzwanie dosyć często, że atakują nas boty wszelakie.

GF: A, no tak.

ŁG: Mamy towar szukany przez wszystkich, więc rynek botów poszukujących obuwia działa prężnie. Musimy więc odpowiednie firewalle stosować, plus rzeczywiście skalowanie infrastruktury na wypadek, gdyby firewall jednak wpuszczał za dużo ruchu.

GF: A, no tak.

ŁG: Więc, takie ciekawostki w tej branży.

Teraz, z racji trudności w rozwoju zespołu in house i minusów, które widzę w postaci elastyczności, będziemy kierować się gdzieś w stronę partnerstw strategicznych z partnerami, którzy będą nas wspierać w rozwoju poszczególnych projektów. Ale zespół in house, oczywiście sobie zachowujemy. Głównie będzie odpowiadał: po pierwsze, za koordynację tych współprac, za zarządzanie projektami, no i za odpowiednie planowanie i wdrażanie tej infrastruktury, tak żeby to wszystko ze sobą funkcjonowało.

Jak zorganizować pracę w  dziale IT

GF: Powiedziałeś też, że jak ma się wewnątrz ten zespół, to można działać szybciej – wdrażać różne rzeczy. A z drugiej strony bardziej merytorycznie, bo ludzie wewnątrz znają system. Tak?

ŁG: Tak.

GF: No, ja się nie zgodzę, tak, jak jakby patrząc na nasze doświadczenia i na to jak my pracujemy. Ale też widzę, jak inni pracują. Myślę, że nie jest aż tak bardzo popularne. To wszystko zależy jak ten Software House jest poukładany. Jak wewnątrz ma tę strukturę dopasowaną do konkretnego rodzaju klienta.

My na przykład obsługujemy tych klientów od 200 tys. do kilku milionów miesięcznie. Jak byśmy Was mieli na przykład przejąć, albo kogoś większego, to ja bym powiedział: “Nie”. Ponieważ my nie damy rady powyżej tam powiedzmy 10 mln złotych miesięcznie. Nie wiem – gdzieś ta granica między 5 a 10 mln na miesiąc. Powiedziałbym, że raczej nie damy rady obsługiwać takiej firmy. Z prostego powodu – nasze procesy wewnętrzne nie są przystosowane do tego.

Zazwyczaj klienci wykupują u nas od 8 do 60-80 godzin miesięcznie. Jak na takie sklepy, przy takich obrotach, to i tak jest bardzo dużo. Na przykład, nie jestem w stanie teraz sprzedać 300 godzin do 1 klienta. To by było niebezpieczne dla nas jako firmy, ale z drugiej strony i procesów – jak to ugryźć. I z tego powodu, że ja jestem fanem efektywności procesów. Mamy z 300 ponad stron, jak nie więcej, różnych spisanych, jak to wszystko ma działać i rzeczywiście potrafimy to robić.

Jeden z naszych klientów nazwał to: “Taki złoty środek”. To nie jest tak, że wszystko od ręki zrobimy. Pożary rozwiązujemy w ciągu godziny – czyli sklep stoi, a coś co trzeba pilnie zrobić, inne rzeczy standadowo  w  przyszłym tygodniu. Klienci wiedzą, że im mniej wyjątków, tym lepiej.

ŁG: No tak, ale to wynika zapewne z Waszego procesu.

GF: Tak.

ŁG: Jakiegoś tam sprint planingu i tego typu rzeczy.

GF: Ja myślę, że jak się ma wewnętrzny zespół, to też tak jest.

ŁG: Tak.

GF: Ponieważ, w tym momencie zespół nie jest się w stanie skupić na tym, na przykład na jakimś większym wdrożeniu. Oddzielnie powinien być zespół do szybkiego reagowania, oddzielnie do większych projektów.

ŁG: No właśnie. My przede wszystkim dzielimy sobie pracę na zadania bieżące i na większe projekty. Często alokujemy zasoby na wyłączność do projektu, bo inaczej to się rozwleka. No i wyzwaniem też była transformacja z takiej roli służebnej stricte, czyli: dostajesz taski, taski, taski, i oni tam robią. Właściwie nie bardzo wiedzą po co, ale robią. Tłuką te taski, bo ktoś to im zlecił i co drugi pyta: “Jak tam? Na kiedy?”.

GF: Tak.

ŁG: I teraz…

To jest taka transformacja, żeby biznes zrozumiał, że tutaj musi obowiązywać pewien proces, bo dzięki niemu wszyscy dostaną swoje efekty projektów szybciej.

GF: Tak.

ŁG: I to było kluczowe, żeby to transformować wewnątrz organizacji, która była przyzwyczajona do tego, że: “Ej, no jak to? Dzisiaj zlecam. Ja mam jutro akcję, więc ja potrzebuję mieć osadzony landing page na wczoraj”.

GF: Tak, tak. Znamy to.

ŁG: I powiem Ci, oczywiście, że…

Ja nie słyszałem o firmie, w której nie ma tarć IT – biznes. Nie słyszałem, ale myślę, że w dużej mierze nasze poszczególne zespoły się przyzwyczaiły do procesów i to działa na pewno lepiej niż działało sobie wcześniej, bo jedna i druga strona wiedzą czego się spodziewać.

GF: Tak. Ty to nazywasz procesami, a ja bym nazwał zasadami współpracy. Czyli: żeby było jasne, jak szybko pewne rzeczy mogą być zrobione i ile wcześniej trzeba o tym powiedzieć? Co powinno być opisane i jak opisane? I wtedy obie strony potrafią docenić się na wzajem.

ŁG: Tak.

GF: Z drugiej strony, to co ja na przykład wprowadzam, to to, żeby programista nie widział tylko tego jednego tasku, bo wtedy nie możemy liczyć na jego kreatywność. On po prostu musi wtedy wystukać. Mamy też taki dział e-commerce, więc programiści widzą szerzej te taski, widzą, jak to działa, widzą, jak inne sklepy działają i oni dzięki temu mogą powiedzieć: “Hej, ale to chyba głupie, bo tutaj robiliśmy to inaczej, tutaj ktoś powiedział…” I nie są takimi ślepymi wykonawcami, tylko ludźmi, którzy przy okazji, oprócz tego, że muszą wymyślić, jak to zakodować, to mogą powiedzieć: “Hej, ale może ten proces zmieńmy w tym tasku, bo coś tam”. I to też jest wsparcie. U Was też jest to, że programista przyjdzie: “Hej, ale jak to będziemy chcieli tak zrobić, to po prostu będę musiał połowę sklepu przekopać i to będzie strasznie drogie”. Tak?

ŁG: No.

GF: Gdzie tu sens biznesowy?

ŁG: Tak, tak.

GF: Pewnie też macie taki problem.

ŁG: Wyceniamy sobie poszczególne funkcjonalności przed decyzją – czy będziemy wdrażać poszczególne pomysły, musi nastąpić ten proces wyceny. I wiesz, to chwała Wam, że macie takie podejście, że rzeczywiście dział e-commerce’u współpracuje z deweloperami. My też promujemy tego typu podejście.

Celem jest to, żeby deweloperzy rozumieli biznes, żeby znali cele całego przedsięwzięcia, nie pojedynczych tasków.

GF: Tak

ŁG: Czyli na przykład deweloperzy są obecni na takim kick-offie projektu, gdzie omawiamy co jest celem danego przedsięwzięcia, danego projektu. Po co nam to potrzebne? Jakie jest uzasadnienie biznesowe? Co my z tego będziemy mieli i kiedy?

GF: Tak.

ŁG: I wówczas rzeczywiście, to zupełnie inaczej zaczęło sobie iść. I nie mamy tego od zawsze – stosunkowo od niedawna. Wcześniej widać było więcej zgrzytów, gdy tego nie było. Myślę, że ważne jest też ten proces analityczny.

Tutaj trochę padło to w kontekście tej wyceny czy godzin – warto budować w firmach taką, jakby to ująć – w ogóle – świadomość cyklu życia projektu nie tylko z perspektywy IT.

GF: Tak.

ŁG: Trzeba pamiętać, że…

IT często jest tylko pewnym elementem realizacji. Musimy budować w firmie świadomość, że cykl życia projektu, to jest również etap analizy, później, dopiero po decyzjach realizacja, a potem mamy jeszcze testy, stabilizacje i tak dalej. U nas ta świadomość jest już lepsza niż była. I widać tego efekty – że biznes jest w stanie poczekać na solidną analizę, po to, żeby podjąć później lepsze decyzje. I żeby później – ostatecznie po realizacji – szybciej wdrożyć dany produkt.

Rola analizy w rozwoju platformy ecommerce

GF: A co znaczy dla Ciebie analiza?

ŁG: Po pierwsze:

…kwestia analizy biznesowej, czyli solidne uzasadnienie. Bez tego w ogóle nie zaczynamy.

Dwa, rzeczy związane z technikaliami, czyli: diagramy przepływów, opisy procesów, jak co ma funkcjonować, uszczegóławianie. Czasami do granic możliwości. To wydłuża czas trwania projektu. Często na przykład o 1/3, ale z drugiej strony obniża koszty na tych etapach ostatnich, gdy wdrażasz coś, bez odpowiedniego przetestowania. A żeby odpowiednio przetestować, to musisz mieć uzgodnione wcześniej, co to tak naprawdę ma dowozić i tak dalej.

GF: Tak.

ŁG: Pewnie dla Software House’u to mogą być to oczywistości, ale dla e-commerce’u, który gdzieś tam budował to od zera, te rzeczy były w pewnym momencie takim game changerem. Trochę takim odkryciem Ameryki.

GF: Akurat my, pracując z klientami – to zazwyczaj oni oczekują wyceny. Więc często wysyłają 3 punkty i: “Zróbcie mi taką funkcjonalność”. Ja mogę powiedzieć z doświadczenia: “Hej, to zajmie 1 dzień, pół dnia, 2 tygodnie”. Natomiast cały szkopuł, to ten diabeł tkwiący w szczegółach.

ŁG: Dokładnie.

GF: Który powoduje: “Ej, ale jak to ma działać? Jak Twój sklep wygląda? Jak Twój sklep reaguje?” I tam 1000 rzeczy wyskakuje. Więc u nas zazwyczaj jest tak: “Hej. To może być między 1 a 5 dni”. I potrzebujemy zrobić – my to nazywamy – studium wykonalności, gdzie siadamy z klientem i analizujemy. Pytamy się go i pytamy: “Po co to?”. Później programista siada, patrzy jak jest ten sklep zrobiony. Co tam można zrobić, zmienić? Plus – na co pozwala platforma? I na przykład jest proponowane jakieś 1 lub 2 rozwiązania, jak to zrealizować przy różnych budżetach. Bo na przykład można zrobić prosto, na twardo. I to będzie tanie. Albo zrobić to jak trzeba i wtedy mamy drożej, ale lepiej. I w przyszłości nie odbije nam się to czkawką.

I ja widzę, że to się zmienia – ta świadomość. Że ta analiza jest potrzebna. Tylko, że ona również zajmuje czas i często ta analiza, u nas też zajmuje 20% w ogóle z całego wykonania zadania, żeby to przeanalizować. I to też jest tak, że po tych 20% klienci mówią: “Nie, nie robimy tego”, bo na przykład się okazuje, że to rozwiązanie jest strasznie drogie, albo się w ogóle okazuje, że to nie ma sensu biznesowego. Bo zaczynamy rozmawiać. My zadajemy pytania. O! Bo często – nie wiem, czy u Was jest tak, ale ten kto chce, to widzi cały świat w różowych okularach. Że po prostu, to zmieni nasz biznes, będzie wzrost konwersji o 50%, a później są ciężkie pytania, które pomysłodawca nie zawsze chce sobie zadać. Okazuje się, że tak, to do końca nie będzie.

ŁG: No tak. I tutaj podchodzą 2 rzeczy.

Po pierwsze warto robić MVP (przyp. Minimum Viable Product) i rzeczywiście szybko testować te hipotezy.

Kolejna rzecz jest taka, żeby od samego początku próbować wystrzegać się budowy kombajnów. Jakichś bardzo rozbudowanych funkcjonalności z milionem pomysłów. A lepiej zrobić coś małego i sprawdzić, jak klienci na to reagują i jeżeli reagują umiarkowanie pozytywnie, to ewentualnie poprawiać.

No i chyba kolejna rzecz, w kontekście tego, co powiedziałeś, że ta analiza zajmuje czas. No okej – zajmuje, tylko ja wolałbym mieć wniosek, żeby czegoś w ogóle nie robić, niż stracić pieniądze, jak zrobię to bez analizy.

GF: Tak.

ŁG: Dla mnie tak naprawdę, jest to oszczędność.

GF: Ja myślę, że w tym momencie najbardziej mi żal tych wszystkich ludzi, którzy wchodzą do e-commerce’u i wydają pieniądze na stworzenie sklepu, a nie zrobili porządnej analizy i strategii – czy w ogóle warto, żeby oni wchodzili w e-commerce. Wydają pieniądze, a później się okazuje, że jednak w ich przypadku, to nie ma przyszłości, bo no nie będą w stanie mogli tego ogarnąć.

ŁG: No tak. Tutaj mówimy akurat o takiej analizie powiedzmy – strategicznej. Ale na każdym etapie warto poświęcić w ogóle jakiś czas przed rozpoczęciem działań, no bo to może się okazać zbawienne w skutkach na późniejszych etapach. I tu przykładów można mnożyć.

Przepisanie kodu – headless ecommerce

GF: Łukasz, powiedziałeś, że Wasz plan jest taki, żeby mieć wewnętrzny zespół, jako taki krytyczny, plus zewnętrzne zespoły, które pomogłyby Wam w skalowaniu, w szybkości realizacji budowy całego sklepu. Czy teraz jest to już możliwe u Was? Bo do tego to trzeba mieć specjalną strukturę samego sklepu. Jeśli Wy macie dedykowany sklep, no to każdy nowy programista będzie musiał poznać ten sklep, strukturę, a przecież to jest drogie, żeby się nauczyć. Co stosujecie? Headless? Jakieś mikroserwisy?

ŁG: No dokładnie – masz bingo. Właśnie poszliśmy w tę stronę, przepisaliśmy to w idei headless, czyli oparliśmy całość o mikroserwisy. Tak naprawdę poszczególne moduły sklepu są od siebie niezależne z perspektywy technologii. Komunikują się po API czy po jakiejś tam szynie danych. I po prostu – mówiąc kolokwialnie – gadają ze sobą. Ale dzięki temu jesteśmy w stanie niezależnymi zespołami rozwijać poszczególne elementy. I później dbać tylko o to, żeby jedne z drugimi się komunikowały. Czyli rozwijać na przykład API.

GF: Okej. Mikroserwis, czyli każdy moduł tak jakby oddzielnie, działa niezależnie od siebie. A headless, czyli Front end niezależny od Back endu. Tak?

ŁG: Dokładnie tak.

GF: Okej.

ŁG: To teraz zaczyna być modne w e-commerce’owym światku. Hasło “headless”.

GF: Tak.

ŁG: U nas to pewnie jeszcze tak do końca, w 100%, to nie jest, ale generalnie wydaje mi się, że przy tych wszystkich buzzwordach występujących na rynku, one są o tyle przydatne, że mogą wytyczać pewne kierunki, a dopiero pod tymi kierunkami należy definiować konkretne przedsięwzięcia, żeby do tego kierunku zdążyć.

GF: Tak. Jesteście tak naprawdę liderem w swojej branży, niszy. To jest trochę inaczej niż ja. Jestem gdzieś tam, nie jestem jeszcze w czołówce. 😊 Mam inną niszę i mniejsze obroty niż Wy. Tak jak mówiłeś – lepiej skopiować i używać gotowego rozwiązania, niż iść w to. Natomiast zastanawiam się, bo mówiłeś, że przepisaliście kod do takiej struktury – długo to zajęło? Tak z ciekawości.

ŁG: Długo.

GF: Za długo?

ŁG: Nie, no wiesz… Może tak – uważam, że na poziomie tego długu technologicznego, który był przed i z uwagi na to, że brakowało jakiejkolwiek dokumentacji, więc tutaj była kwestia jeszcze analityczna mocno do zrealizowania. Plus do tego, że trzeba było jeszcze w tym uwzględnić projekt migracji do clouda, no to to zajęło trochę ponad rok. Rok i 2 miesiące.

GF: Cały zespół kodował, czy część zespołu?

ŁG: Nie, nie, nie. 2 osoby plus szef jako architekt zamieszania. No i oczywiście mieliśmy do tego – z perspektywy chociażby w przypadku projektu cloudowego – to mieliśmy partnera zewnętrznego, który tak naprawdę za rączkę nas przez to przeprowadził, ponieważ nie mieliśmy wcześniej doświadczeń w tym zakresie.

GF: Okej. Drodzy słuchacze, możecie policzyć i zobaczyć, ile: średnia stawka programisty razy 2 czy 3 plus jeszcze partner. Pewnie jeszcze nie wszystko zostało przepisane. Tylko te najważniejsze rzeczy. Solidny budżet na to, żeby nie było tak, że 10% funkcji jest używanych. Tak?

ŁG: Tak.

GF: Pewnie sprawdziliście, zanim zaczęliście pisać?

ŁG: Z racji na doświadczenia – tak, pewne funkcje zostały pominięte. Trzeba również wziąć pod uwagę, że było też generalne założenie przy projekcie: nie wymyślamy nic nowego.

GF: Czyli przez rok nie tworzyliście żadnej nowej funkcji na starych sklepach?

ŁG: Nie, tworzyliśmy na starych, ale minimalne ilości. Naprawdę wycinaliśmy co się dało, żeby przypadkiem nie pisać tego od nowa. Operacja była bolesna. Na efekty trzeba będzie jeszcze trochę poczekać, ale wierzę, że to była dobra decyzja. W tej konfiguracji, w tej w której obecnie jesteśmy.

GF: Tak mi się przypomniało: “Operacja była bolesna, ale pacjent przeżył”.

ŁG: Pacjent przeżył. Z ciekawostek, tak dla śmiechu właśnie – że pacjent przeżył, wyobraź sobie, że zrobiliśmy rzecz karkołomną – wydawałoby się. Przepięliśmy się na chmurę tydzień przed Black Friday.

GF: W tamtym roku?

ŁG: Wyobraź sobie jaki był stres, czy to będzie działać?

GF: O! Ja to przeżyłem w swoim życiu raz. Powiedziałem nigdy więcej.

ŁG: Ja pozdrawiam – tym razem Maćka, bo Maciek, był tutaj głową tego zamieszania. Raportował co się dzieje na bieżąco, nawet i o 3:00 w nocy. Tylko, że tak naprawdę, to jest hipoteza, no bo nie byliśmy w stanie do końca tego zweryfikować – prawdopodobnie, na poprzedniej infrastrukturze byśmy Black Friday po prostu nie przeżyli. A były sklepy, które nie przeżyły, które się zcrashowały na wiele godzin.

GF: Czyli mieliście takie straszne promocje i straszny ruch – rozumiem?

ŁG: No, tak, tak. Ruch był potężny, więc musieliśmy to zrobić i przeżyliśmy ten Black Friday i zakończyło się to happy endem. Nie obyło się oczywiście bez perturbacji, nie wszystko działało idealnie.

GF: Czyli były ofiary. Na szczęście, nie w ludziach.

ŁG: No były, były. Ten czas stabilizacji trochę trwał, żeby rzeczywiście można było przejść od innych projektów i skończyć gasić pożary.

GF: Okej. Aha, czyli rozumiem, że po prostu, później, jak przepięliście, to było jeszcze dużo poprawek i błędów, które wychodziły po drodze?

ŁG: Tak, tak. Rzeczy, które nie zostały uwzględnione, zapomniane. Braki w dokumentacjach się kłaniają.

Tak naprawdę jeszcze raz podkreślę, że ten proces analityczny i dokumentowanie są mega istotne dla późniejszego rozwoju. Bo później to generuje tylko bariery.

GF: A nie wiem, czy mierzycie to, jaki procent z całego czasu projektu, to jest dokumentacja? Żeby ją dobrze stworzyć?

ŁG: Tak dokładnie, to nie mierzymy, ale patrząc po harmonogramach projektu oceniałbym na 20-30% całości. Tak jak powiedziałeś 20, myślę, że nawet koło 30 może być.

GF: Dokumentacja? Do Waszego sklepu?

ŁG: Dokumentacja i analiza – to mam na myśli.

GF: Okej. Ale patrzcie, jak już wychodzimy w dokumentację oprogramowania.

ŁG: Techniczną.

GF: Że na przykład programista pisze i później musi dopisać jeszcze.

ŁG: A to nie wiem. Jest ten proces, ale nie wiem. To by trzeba by było Maćka zapytać. Mogę zapytać. Następnym razem będę przygotowany.

Jak skoordynować prace deweloperskie dla kilku sklepów internetowych

GF: Okej. Widzicie – takie pytania niespodziewane. Podsumowując całość, żebyśmy już powoli kończyli, to jesteście na własnym, dedykowanym rozwiązaniu. Tworzy go niezły zespół 6 osób. I to rozwiązanie powoduje, też pewnie komplikacje, bo tu jeszcze macie taki zonk, że macie 8 różnych sklepów. Prawda?

ŁG: Tak.

GF: Też trzeba sobie jakoś z tym radzić.

ŁG: Trzeba. I tu jest też wyzwanie, bo wyobraź sobie, że można podzielić klientów na zewnętrznych. Czyli to jest klient, który przychodzi po buty do Sklepu Biegacza. I na klientów wewnętrznych, czyli to jest na przykład manager, któregoś ze sklepów, który chce na wczoraj taką, a taką funkcjonalność. No i ci klienci wewnętrzni często mają zupełnie przeciwstawne potrzeby między sobą, co rzeczywiście jest problemem.

Tutaj trzeba wykazywać się nie lada asertywnością i jednocześnie dyplomacją, żeby to funkcjonowało. Jeden chciałby mieć wyłączanie z rabatu produktów zrobione w sposób “X”, a drugi w “Y” i one zupełnie ze sobą nie grają. A jeżeli chcielibyśmy być dla każdego dobrym wujkiem i robić funkcjonalności, po prostu, tak jak zostały zlecone, według własnego widzi mi się autorów, no to za rok czy dwa mielibyśmy z nowo, świeżo przepisanej, pięknej platformy, znowu taki bałagan, w którym nikt by się nigdy nie odnalazł. No i koło by się zamknęło. Ten błąd już popełnialiśmy, więc nigdy więcej.

GF: Macie spisane gdzieś żelazne zasady? Co robicie, czego nie robicie?

ŁG: Tak. Mamy procedury popisane – jak to ma wyglądać. I rzeczywiście staramy się pewnych rzeczy trzymać. Oczywiście nie jest to –”żelazne”, to dobre słowo, bo bywają różne wyjątki. No nie robimy już takich rzeczy, że na przykład operacja na otwartym sercu, czyli grzebanie na produkcji bezpośrednio już nie ma miejsca. I się nawet chyba teraz nie da. Ale kiedyś takie rzeczy były. Więc – tak – jest trochę takich zasad, które, może nie pisanych do końca, ale każdy je zna.

GF: Ja przyznaję, że gdy opowiadasz, że masz tych 8 managerów z różnych sklepów, którzy negocjują różne funkcjonalności, to tak jakby nasi koordynatorzy negocjowali między sobą o zasoby programistyczne, bo też przecież mamy ograniczone. Nasi klienci też chcą pewne rzeczy “na już”, albo “inaczej”. Do tego jeszcze trzeba przenegocjować z klientem pewne rzeczy – że może lepiej tego nie robić na tej platformie, bo to w ogóle się posypie. Albo on chce na szybko: “Dobra, zrobimy ten wyjątek. Zróbmy to na żywym organizmie, to przecież jest takie proste”. Tak?

ŁG: Dokładnie. Wiesz, ja się będę bardzo cieszył, gdy ekipy ode mnie tego posłuchają. Dużo takich ciekawych rzeczy zdefiniowaliśmy.

GF: A później jest historia: “No to było proste, ale pacjent był wyłączony na godzinę”. Tak?

ŁG: Tak.

GF: I jednak to nie było takie hop-siup. Jak się tworzy sklep, tak jak u Was – w ten rok, przez kilka osób, to tych funkcjonalności są setki. Nawet programista, który to tworzy zapomina, że to jest powiązane z tym i z tym.

ŁG: Tak.

GF: I to nie jest wprost napisane.

ŁG: Warto więc o to dbać, żeby zapobiegać temu zapominaniu – czyli dokumentacja. U nas jeszcze dochodziły kwestie integracji z różnymi systemami, co też jest inaczej niż chociażby w Prescie, gdzie wiele integracji masz po prostu do wzięcia i do dostosowania. Bo to też nie jest tak.

GF: Jest do wzięcia, ale te moduły, dlatego że są pisane przez różnych programistów, one się kłócą i nie działają, i trzeba je poprawiać.

ŁG: Nie współpracują ze sobą – dlatego powiedziałem, że do wzięcia i do dostosowania – żeby też słuchacze mieli świadomość, bo to jest chyba ważne, że jak weźmie się open source’a, to wcale to nie jest tak, że: wchodzę sobie na sklep z wtyczkami i wybieram wtyczki, i tego samego dnia mi wszystko działa.

GF: No to nie jest telefon czy Apple, czy Google, że zainstalujemy sobie aplikację i to świetnie działa. Powiedziałbym, że to nie ten poziom działania.

Tak podsumowując – jeszcze raz, bo ostatnio mi się nie udało. Życie – zawsze coś wyjdzie ciekawego po drodze.

Zastanawiam się, bo Ty reprezentujesz ogromny sklep – jak dla mnie. Ogromną infrastrukturę. Niewiele firm może sobie pozwolić na taki 6-osobowy zespół IT wewnątrz, jeszcze do tego zewnętrzne. Jest to w ogóle kompletnie inna liga niż 90-95% sklepów w Polsce – jeśli mówimy o 50-tys. sklepów, bo wspomniałeś, że tyle jest w Polsce, na podstawie raportu z Senuto. Tak, tu będziemy robić kryptoreklamę. Przypadkiem.

ŁG: Tak.

GF: Więc tych sklepów – takich liderów, to pewnie jest 500, max – mi się wydaje.

ŁG: No, tak.

Czego wymagać od zewnętrznego Software House?

GF: Więc dla całej reszty osób, które tu słuchają i są w mniejszych e-commerce’ach, myślę, że wartościowym jest to, żeby zwrócić uwagę na to jak i czego wymagać od zewnętrznego Software House’u. Na przykład zapytać o to, bo nikt o to nie pyta jak: wygląda proces komunikacji pomiędzy mną a Wami? Jak wygląda proces dokumentacji? Jak wygląda proces zlecania, szybkość reakcji? Co w razie “X”, co w razie “Y”? Kto o to zadba? Czego mogę oczekiwać? Jaka jest jakość kodu? Czy jak to się dzieje? Czy Ty byś coś jeszcze dodał?

ŁG: Nie. Wymieniasz te rzeczy, o które ja bym zapytał zewnętrzny Software House – ale to po latach doświadczeń.

Rzeczywiście, pierwsze o co bym zapytał, to kwestie komunikacji, definicji, oczekiwań. Jak szczegółowo będziemy rozpisywać sobie poszczególne zadania? Jaki procent z czasu alokujemy na ten etap analityczny i gdzie, i w jakiej formie będzie przechowywana dokumentacja? No i oczywiście rzeczywiście rzeczy związane z SLA, czyli tak naprawdę później dostępnością serwisów.

Ale zakładam, że o to raczej klienci pytają.

GF: Też nie do końca.

ŁG: Aha.

GF: Mamy jasne zasady. Ja, nauczony tym, że tak jak u Was klienci w sklepach mają różne oczekiwania, to my często na początku mówimy, jak to u nas jest.

ŁG: Yhm.

GF: I co możemy zrobić. Tak jakby te oczekiwania, te krytyczne rzeczy, które później zazwyczaj wychodziły i to były takie pożary, bo klient się na nas na przykład złościł czy obrażał, czy miałby do nas pretensje. Wyciągamy tego trupa z szafy na początek. Od razu mówimy: tak szybko reagujemy, te dni robimy, to możemy zrobić, tego nie możemy zrobić. I odnośnie komunikacji – tak się komunikujemy. I najczęściej prosimy klientów, żeby się do nas dopasowali. Pomagamy im w tym.

Z drugiej strony, opisywanie zadań – tutaj koordynator, który prowadzi klienta, to jest wyższa szkoła, żeby wyszkolić klienta w dobrym opisywaniu zadań – że tak się wyrażę. To ułatwia, skraca czas później na produkcji, ale i też obniża koszty. To czasami trwa i 2 lata.

ŁG: No właśnie. Świetnie, że odpowiedziałeś na pytanie, którego nie zdążyłem zadać. Chciałem zapytać, ile trwa edukacja klienta w kontekście rozpisywania zadań, dzięki czemu, na koniec dnia on oszczędzi kasę? Nawet 2 lata. No…

GF: Tak. To wszystko zależy od osoby.

ŁG: Tak.

GF: Tutaj mówiłem o takim bardzo hardcore’owyma przypadku. Natomiast, tu koordynatorzy są bardzo wyczuleni. Mamy wręcz instrukcję albo opis i uczymy tego klienta jak to opisywać. Jakie rzeczy? Jak robić zrzuty ekranu? Bo tutaj to są pomysły, żeby to miało ręce i nogi, żeby nam ułatwić pracę. Bo później, też jest tak, że jak jest zewnętrzna firma: “No, ale to Wy mieliście mnie zapytać o to i o to. To Wy mieliście dopilnować tego procesu”. No więc bierzemy na to odpowiedzialność za siebie i pomagamy.

ŁG: Tak.

GF: Myślę, że temat przegadaliśmy dokładnie.

ŁG: Udało się liznąć.😉

GF: Tak. Ja myślę, że kiedyś zrobię podsumowanie, bo już kilka razy o tym rozmawialiśmy –  i złożę to w jeden tak zwany e-book. Ostatnio Cię pytałam, czego Ci życzyć, a dzisiaj zapytam: co byś polecił e-commerce managerom, właścicielom w sklepów, żeby czytali i uczyli się. Jakieś wartościowe źródła wiedzy?

ŁG: To może, tak w kontekście tego, o czym dzisiaj rozmawialiśmy. Ta książka już ma swoje lata, ale jest tam wiele treści, które są ponadczasowe. Jest taka książka: “Technologia w e-commerce”, bodajże – nie pamiętam – któryś z braci Karawatka był współautorem. Mogę zaraz poszukać jej na półce. Myślę, że to bardzo fajna pozycja w kontekście tego, o czym dzisiaj rozmawialiśmy.

I druga rzecz, która ostatnio fajnie mnie zainspirowała, czyli: “PMO. Project Management Office”. To jest już taka bardzo praktyczna propozycja mówiąca o tym, jak zorganizować wewnątrz organizacji biuro projektów. O ten temat żeśmy dzisiaj nie zahaczyli za bardzo, ale to też jest mega ciekawe. Można sobie spróbować dzięki temu zestandaryzować prace nad projektami w organizacji, a to pryz pewniej skali jest kluczowe.

GF: Tak. To jest już na pewno kluczowe.

ŁG: To takie mi 2 rzeczy do głowy przychodzą, które bym tutaj, w kontekście dzisiejszej rozmowy mógł z czystym sumieniem polecić.

GF: Łukasz wielkie dzięki za rozmowę.

ŁG: Dzięki. Dzięki również.

GF: Dziękuję, że się tym podzieliłeś i trzymam kciuki, żeby Wasz pomysł, na rozwój Waszej technologii wyszedł tak jak chcecie.

ŁG: Wiesz, że tak będzie. Również dzięki. No i cóż, oby tych dużych klientów też się udawało Wam łapać i żeby biznes szedł do przodu.

GF: Dzięki. I do usłyszenia.

ŁG: Do usłyszenia.

GF: I to już koniec. Jakie masz przemyślenia? Już wiesz, czy warto mieć własny zespół IT, czy może zewnętrzny? A może jakiś SaaS? Daj znać w komentarzu czy to na You Tube, Facebooku czy w e-mailu.