Cześć, dzień dobry, witam was w podcaście IT i biznes. Nazywam się Grzegorz Tabor i na co dzień prowadzę trzy firmy, w tym firmę programistyczną, agencję doradczo-rekrutacyjną i SaaS do monitoringu cen konkurencji dla e-commerce. Podcast IT i biznes kieruję do właścicieli firm oraz menedżerów, którzy na co dzień współpracują w swoich firmach często i dużo z szeroko pojętym IT i chcieliby realizować owe projekty IT bardziej świadomie i skuteczniej. Odcinek czterdziesty szósty. Sposoby na szybką realizację kolejnych celów biznesowych, gdy twoi programiści już nie wyrabiają. Przedsiębiorco-menedżerze.

Jesteś osobą, która ma głowę pełną pomysłów. Chcesz rozwijać swój produkt, wdrażać nowe funkcje, automatyzować różne procesy, no w dużym skrócie spełniać swoje cele biznesowe, ale kiedy przychodzisz do swojego obecnego zespołu IT czy działu IT, słyszysz tylko, że nie dadzą rady, że nie ma już na to czasu, że dokończmy najpierw to, co zaczęliśmy. Nie rozpoczynajmy nowych rzeczy, dopóki nie zakończymy tych starych.

Czyli w skrócie, brakuje mocy przerobowych, brakuje czasu, brakuje ludzi. Sam nie wiesz do końca czego brakuje, żeby móc twoje cele biznesowe dalej realizować, twoje szalone pomysły wdrażać szybko, dynamicznie. No i przez to czujesz, że firma stoi w miejscu.

Jeżeli jesteś w tego typu sytuacji, to postaram się tutaj stanowczo odpowiedzieć na te problemy i wytłumaczyć, jak można do tego podejść. Zatem nie przedłużając, serdecznie zapraszam do części głównej dzisiejszego odcinka. Cześć, dzień dobry.

Witam serdecznie, drogi słuchaczu, droga słuchaczko. W czterdziestym szóstym już odcinku podcastu IT i biznes. Dzisiaj skupiamy się na temacie bardzo często widocznym w różnych firmach, w których teraz udzielamy konsultacji, gdzie cele biznesowe i wizje na biznes są naprawdę potężne, ale jeżeli by to zderzyć z rzeczywistością, z możliwościami technicznymi czasowymi osób, które te cele biznesowe zaspokajają z użyciem technologii, okazuje się, że to są kompletnie dwa różne światy.

No i dzisiaj właśnie porozmawiamy sobie o sytuacji, którą wielu przedsiębiorców zna, tak jak powiedziałem we wstępie. Są pomysły, są wizje, chcemy je realizować, ale brakuje, sami do końca nie wiemy czego. Bo być może brakuje ludzi z określonymi kompetencjami, może brakuje po prostu czasu, może zespół jest za mały, a może zespół jest nie wiem, zbyt rozprężony.

Kto wie, w każdym razie na tym cierpi biznes w kontekście takim, że cele biznesowe nie są realizowane albo dynamicznie pojawiające się zmienne sytuacje nie są odpowiednio zaopiekowane. No i czujemy, że firma stoi w miejscu. I to co się dzieje w tego typu sytuacji to raczej nie jest kwestia złej woli.

Ja bym tego nie zakładał. To znaczy myślę, że to jest w dużym uproszczeniu patrząc w zderzenie dwóch różnych typów osobowości, czy dwóch różnych temperamentów, tak to możemy rozumieć. No bo zobacz, z jednej strony jest przedsiębiorca, menadżer, który ma jakąś wizję, którą chce zamienić na określone cele biznesowe, myśli przyszłościowo, lubi eksperymentować, działać szybko, lubi testować, chce mieć to zrobione w odpowiedniej jakości, oczywiście, że tak, ale zdarza się, że ma nowe pomysły nawet co tydzień i czy co dwa tygodnie i chce te pomysły w miarę możliwości sprawnie weryfikować, na przykład z rynkiem.

Z drugiej strony mamy zespół IT, czyli często takie osoby analityczne, zadaniowe, które raczej potrzebują planu, potrzebują określonego procesu, potrzebują wiedzieć co po kolei następuje, niekoniecznie potrzebują chaosu, raczej potrzebują tego, żeby dany etap rozpoczęty też zakończyć, żeby to zrobić w bardzo dobrej jakości, rzekłbym to wręcz perfekcyjnie i lubią nie mieć dużej ilości wątków z reguły naraz, tylko lubią właśnie tych wątków mieć mniej i je po prostu zaczynać i szybko domykać. I tutaj często po prostu wynika to, że w momencie, kiedy przedsiębiorca czy menadżer mówi, wpadłem na jakiś nowy pomysł, spróbujmy zrobić to i to, zobaczmy jak rynek na to zareaguje, to wtedy często słyszy, zaczekaj, skończmy najpierw to, co zaczęliśmy, dopiero potem zaczynajmy kolejne. Albo na przykład słyszy, najbliższy termin to mamy za pół roku, na razie musimy skończyć coś i tutaj cel biznesowy sprzed pół roku wcześniejszego.

Albo słyszy, znowu coś wymyśliłeś, albo słyszy, po co to zmieniać, słuchaj, po co to testować, to nie ma kompletnie sensu, tak jak jest, jest okej, nie zmieniajmy, po co to zmieniać, niekoniecznie nawet weryfikując rzeczy z rynkiem, tylko po prostu weryfikując ze swoją opinią, ze swoim zdaniem. No i tutaj pewne napięcie rośnie, no i z jednej strony przedsiębiorca, menadżer jest niezadowolony, bo cele biznesowe leżą, te nowe, jeszcze te nowe pomysły, takie świeżutkie też muszą poczekać kolejne pół roku, albo dwa lata na wdrożenie, z kolei no zespół IT po prostu ma zakolejkowane prace, realizuje te prace, no i wydaje mu się, że wszystko jest okej, no i teraz w procesie wytwarzania oprogramowania, bo teraz zastanawiając się w ogóle nad tym, dlaczego to tak się dzieje też, to, to, że po prostu nagle zespół IT ma, jest zbyt przeciążony i teraz dlaczego tak się dzieje, no z reguły właśnie przez ilość wątków, to jest dość oczywiste, natomiast jak sobie poradzić z tą sytuacją? I tutaj myślę, że trzeba przejść w ogóle do podstawy problemu i wrócić trochę do etapu procesu wytwarzania oprogramowania. Ten proces wytwarzania oprogramowania omawialiśmy sobie w odcinku dwunastym, właśnie w odcinku, w którym opowiadaliśmy jak nad tym procesem wytwarzania oprogramowania zapanować jako osoba nietechniczna.

W dużym skrócie możemy go podzielić na takie pięć głównych części. Pierwsza część to jest właściwe zdefiniowane celu biznesowego i to, żeby ten cel biznesowy ktoś przeanalizował i dopasował np. do systemów, które już mamy w firmie.

Następnie etap analizy tego wszystkiego, no i rozpisywania zadań. Kolejną z reguły jest jakieś makietowanie, jakiś projekt UX-owo, UI-owy, czyli narysowanie jak to będzie wyglądało. Następnie jest development, testy, no i na koniec uruchomienie produkcyjne.

To takie pięć, sześć tak naprawdę etapów. I teraz na każdym z tych etapów może dochodzić do pewnych przeciążeń, czyli do tego, że po prostu w danym momencie coś się blokuje. Po prostu np.

jest za mało testerów w zespole, mają za dużo zadań do testów, więc te zadania nie będą wchodziły na produkcję, więc np. przez to mogą się korkować i cele biznesowe mogą nie być realizowane. No i teraz trzeba by sobie wziąć pod uwagę właśnie to, żeby sprawdzić na początek, chcąc coś z tym zrobić, czyli chcąc zrealizować cele biznesowe szybciej, zastanowić się, który obszar tego procesu wytwarzania, oprogramowania powinniśmy przyspieszyć, polepszyć, który powinniśmy po prostu bardziej zaopiekować.

Czyli, czy nie ma kto przetworzyć twojego pomysłu w konkretne wymagania, czy te wymagania są zebrane i rozpisane w zadania, ale nie ma kto ich zaprogramować, czy one są zaprogramowane, ale utykają na etapie testów, czy one nawet są przetestowane, ale utykają na etapie uruchomienia produkcyjnego, czy np. odbiorów na środowisku produkcyjnym. W zależności od tego, w którym z tych obszarów mamy blokadę, no to właśnie ten obszar powinniśmy zaopiekować jako pierwszy.

No i teraz w zależności od tego, ile mamy potrzeb na stole, że tak powiem, do pokrycia, czyli czy to jest tak, że widzimy, że zespół jest tak tylko przez najbliższy miesiąc przeciążony, bo po prostu się spiętrzyło trochę potrzeb i raczej będziemy mieli tych potrzeb w następnych miesiącach już zdecydowanie mniej, czy widzimy, że zespół jest już od dłuższego czasu przeciążony i raczej to się nie zmieni, bo firma potrzebuje dynamicznego nadrobienia rzeczy technicznych i po prostu nie uda się i myślimy o tym, co tu zrobić, a niekoniecznie chcemy rekrutować nowych ludzi do zespołu, bo np. nie mamy zaplanowanego procesu onboardingu, bo np. nie mamy na to czasu albo np.

obawiamy się tego, że nie wiemy jeszcze, kogo zatrudnimy i czy ta osoba będzie w cudzysłowie dowozić, czy nie będzie dowozić swoje tematy. No i rozważamy, jak tutaj podejść do tego, nazwijmy to skalowania zespołu, czyli po prostu wsparcia obecnego zespołu kimś nowym, czy po prostu rozpoczęcia współpracy z kimś nowym. I teraz są takie trzy najpopularniejsze modele takiego skalowania zespołu oparte o pewnym sensie outsourcing, tylko w różnym sposób realizowany.

I teraz pierwszy z nich to body leasing tak zwany, czyli po prostu dokładamy programistów, dokładamy analityków, dokładamy testerów do zespołu, czyli to jest taka powiedzmy przyśpieszona rekrutacja, w ramach której ustalamy z firmą taką właśnie body leasingową, często też np. z software housem, bo wiele software house'ów działa też w takim modelu, że potrzebujemy programisty określonej technologii na np. trzy miesiące, no i taki programista dynamicznie dołącza do naszego zespołu, realizuje określone zadania i po trzech miesiącach jest wyłączany albo np.

jego czas jest przedłużany jeszcze o miesiąc czy dwa. I teraz plusem tego podejścia jest to, że możemy w miarę szybko i sprawnie taką osobę włączyć, przy czym tylko w momencie kiedy nasz projekt jest poukładany. Tu jest słowo klucz.

Może się okazać, że jeżeli np. mamy potrzebna jednego, dwóch programistów więcej, jeżeli chodzi o sam development i dołączymy taką osobę do zespołu, do projektu, który jest nie poukładany i panuje w nim też dość duży chaos, może się okazać, że te nowe osoby już obecnym osobom w zespole będą zabierały jeszcze czas i energię na to, żeby im tłumaczyć jak coś działa, jak coś zrobić, jak do czegoś podejść. I z tych takich trzech miesięcy tego body leasingowania, w cudzysłowie swoją drogą ciekawa nazwa, tego procesu, no ale taka jest.

No więc może się okazać, że w ciągu trzech miesięcy tego body leasingowania to my z trzy tygodnie, cztery stracimy na tak naprawdę onboarding takiej nowej osoby. No i może się okazać, że ten proces uda się, ale musimy po prostu znać jego wady. No i wadą jest właśnie to, że musimy mieć naprawdę mocny zespół analityków, testerów, żeby nad tym body leasingiem szczególnie programistów zapanować, żeby się nie okazało, że zatrudnimy sobie szybko jednego, dwóch programistów do zespołu, no ale okaże się, że np.

nie ma kto im przygotować zadań albo nie ma kto po nich przetestować tych zadań. Dlatego tak ważne jest w przypadku szczególnie body leasingu, żeby zastanowić się w którym obszarze tego procesu wytwarzania, oprogramowania mamy największe luki i problemy, czyli największe tak zwane wąskie gardła, żeby ten obszar przede wszystkim wesprzeć i właśnie takim body leasingiem, czyli jak widzimy, że na etapie analizy nie ma kto odebrać od biznesu potrzeb i rozpisać na zadania, no to zatrudnimy analityka czy product ownera w formie body leasingu. Jak widzimy, że na etapie dewelopmentu coś się przyblokowuje, zatrudnimy programistów, tylko upewnijmy się, że ma kto im rozpisać zadania i ma kto odebrać te zadania w kontekście testów i tak dalej i tak dalej.

Tak bym podchodził do body leasingu. Polecałbym go w momencie, kiedy bardzo dobrze znamy firmę, od której będziemy w cudzysłowie wypożyczać te osoby, chociaż to jest złe określenie, ale nie mam chwilowo lepszego, więc firmę, z której będziemy, z którą będziemy podejmować współpracę z daną osobą w ramach tego bodyleasingu. No i po prostu będziemy też mogli tę osobę poznać, szczególnie w boju.

Zdarza się, że na przykład firmy dają takie gwarancje, że na przykład pierwszy tydzień ktoś może tydzień czy dwa współpracować. Jeżeli ta współpraca nie zadziała, no to można po prostu się gdzieś tam szybko rozstać. To też musimy pamiętać, że no musi być dopasowanie takie też i zespołu z tą osobą.

To też fajnie widać często w firmach, jak na przykład firmy pracują hybrydowo albo stacjonarnie i nagle pojawia się osoba, która pracuje zdalnie, która nie jest w biurze, nie uczestniczy w wszelkich takich elementach kultury organizacyjnej, które nawet nie są też jakoś tam mocno spisane, ale są, funkcjonują i która jednak jest takim dodatkowym programistą na określone zadania. To też trzeba brać sobie bardzo mocno tutaj w tym modelu pod uwagę. I to jest tak naprawdę pierwszy model jaki mamy na stole, czyli takie po prostu dołączenie osoby określonych kompetencjach do zespołu.

Drugi model jaki funkcjonuje z tych trzech, o których chciałbym Wam dzisiaj opowiedzieć, to model zlecania odpowiedzialności projektowo, czyli na przykład oddajesz do jakiejś firmy zewnętrznej cały moduł, cały proces, całą odpowiedzialność biznesową na przykład. Generalnie jakiś projekt. To jest coś co powoduje, że kompletnie nie zastanawiasz się nad tym, jak zonboardować człowieka do projektu, jak podejść w ogóle do samej realizacji, czy ten ktoś z zewnątrz się zgra z Twoim zespołem, czy się nie zgra.

Bo Ty w pewnym sensie wyjmujesz ze swojego wielkiego projektu jakiś obszar, który chcesz na przykład rozwinąć albo obszar, który chcesz w ogóle napisać, zaprogramować i ten konkretny kawałek przekazujesz na zewnątrz. No i teraz tutaj, jeżeli chodzi o plusy tego podejścia, no to na pewno jest to taka większa kontrola i taki bardziej zamknięty zakres, czyli mamy tę gwarancję w pewnym sensie, że wiemy dokładnie jaki element wydzielamy na zewnątrz, no i oczekujemy, że ten konkretny element zostanie zaspokojony, zrobiony. Minusem tego podejścia jest to, że stanowczo trzeba w takim modelu bardzo dobrze przygotować sobie analizę tego co chcemy zlecić, czyli jednak mimo wszystko ten proces rozpoznania celów biznesowych i ich zamiany na operacje, na działania, na projekty musimy zrobić wewnętrznie.

No musimy sobie też zaopiekować kwestię dokumentacji i musimy zaopiekować przede wszystkim takie w miarę formalne odbiory. No bo jeżeli chcemy to zlecać projektowo i jeszcze na przykład wpadniemy na to, że chcemy to zrobić tak fix price'owo, żeby mieć pełny budżet. No to, no to koniecznie musimy mieć też zaplanowane odbiory i musimy pamiętać o tym, że to będzie się wiązało z tym, że ktoś u nas w firmie musi się tym zająć, czyli w tym modelu numer dwa, gdzie zlecamy taką pewną odpowiedzialność projektowo na zewnątrz, czyli outsourcujemy po prostu projekt, musimy wiedzieć po prostu to, że musi być osoba też od razu po naszej stronie wewnętrznie przydzielona do odbioru tego projektu, do komunikacji na temat tego projektu, do udostępniania dokumentacji na temat tego projektu, no i to jest właśnie coś, co trzeba sobie na pewno zaplanować też na etapie już samego zlecania projektu odpowiedzialności.

No i to jest model numer dwa. Jego bym polecił w momencie, kiedy na przykład chcemy do istniejącego systemu dodać jakąś określoną integrację, która łączy jeden system z drugim, albo na przykład chcemy wdrożyć coś gotowego na rynku, co jest dostępne i są firmy, które to super wdrażają, a nasz zespół musiałby się tego na przykład super mocno uczyć, czyli na przykład jak chcemy wdrożyć sobie e-commerce, ale nasz wewnętrzny dział IT nigdy nie wdrażał e-commerce'u, to może się okazać, że wydzielenie tego konkretnego projektu na zewnątrz, takiego wdrożenia e-commerce'u będzie stosunkowo, może nawet tańsze niż realizacja z zespołem wewnętrznym, no i na pewno szybsze, sprawniejsze w przypadku doboru dobrej firmy, tak żeby się nam to też po prostu zwyczajnie w świecie zwróciło. Więc to jest obszar numer dwa.

Obszar numer trzy z kolei to taka trochę hybryda, to znaczy połączenie tego, żeby mieć określony zespół, który współpracuje też z naszym głównym zespołem, tak go będę teraz w dalszej części odcinka nazywał, i jednocześnie możliwość zlecania różnych rzeczy, które wpływają na cele biznesowe. No i teraz ja tutaj zakładam model, w którym w pewnym sensie uruchamia się drugi zespół. Działa sobie zespół główny, zespół A, niezależnie czy to jest twój zespół wewnętrzny, czy zespół z software house'a jakiegoś obecnego, bez znaczenia.

Chodzi o to, że jest już zespół główny, który zna projekt, który w nim pracuje, który zna też po części cele biznesowe, no bo powinien w jakimś stopniu je znać, jeżeli realizuje twoje projekty. No i obok tego powstaje zespół numer dwa. I teraz zespół numer dwa jest jak taki drugi silnik w samolocie, czyli nie zmieniasz całego układu działania, ale możesz nagle lecieć szybciej i bezpieczniej, mając dwa silniki zamiast jednego, w dużym uproszczeniu.

No i teraz to, co jest istotne, to to, że no pewnie możemy sobie zbudować drugi zespół, ale teraz jak go połączyć z tym pierwszym zespołem. No i to jest super kluczowe, bo w momencie, kiedy wiemy jak sprawić, żeby te zespoły działały ze sobą synergicznie i jednocześnie, żeby każdy z nich mógł jednak działać też osobno, no to to powoduje, że możesz z jednej strony przekazywać konkretne obszary, konkretne problemy do realizacji, tak jak do zespołu wewnętrznego, ale pracować z firmą zewnętrzną, która tym zespołem może dynamicznie zarządzać i też skalować w kontekście np. ilość osób, jaka w tym zespole zwyczajnie współpracuje.

To jest coś w rodzaju team leasingu, ale z takim mocnym nastawieniem na dowożenie efektów przez ten zespół, to to jest dla mnie tutaj słowo klucz. No i teraz jak połączyć pracę dwóch zespołów w jednej firmie. No i teraz zacznijmy sobie od samego początku.

Z jednej strony mamy cele biznesowe. Cele biznesowe powinny być jasne tak samo dla obu zespołów, czyli uważam, że przedstawiciel każdego z zespołów powinien uczestniczyć w spotkaniach, które dotyczą omawiania celów biznesowych, czyli jeżeli np. w obecnej sytuacji, w obecnej firmie twojej działa to tak, że jest jakiś np.

Tech Lead czy Product Owner, którzy uczestniczą w spotkaniach takich ogólno firmowych na temat różnych bolączek, problemów, to jeżeli chcesz szybko i sprawnie zlecać do nowego zespołu pracę tak samo jak do starego zespołu je zlecasz, gdyby ten zespół miał czas i możliwości, żeby te problemy twoje potrzeby podjąć, no to musisz mieć też po prostu takiego Product Ownera z drugiego zespołu, który też uczestniczy w spotkaniach biznesowych i który jest takim twoim łącznikiem między biznesem a zespołem technicznym. I to jest kwestia numer jeden. Teraz jeżeli masz już taką drugą osobę, do której możesz przekazywać potrzeby biznesowe, to ta osoba te potrzeby biznesowe powinna analizować, oczywiście uprzednio zapoznając się też z twoim biznesem.

No i powinna ta osoba te potrzeby rozpisywać na zadania. I teraz to co jest ważne w kontekście zadań to to, żeby oba zespoły korzystały z tych samych narzędzi i to jest w ogóle w kontekście całej współpracy super istotne, żeby w momencie kiedy realizujesz taki model hybrydowy, kiedy chcesz po prostu uruchomić drugi zespół, który jest bardziej dynamicznie zarządzany, jeżeli chodzi o ilość osób w tym zespole, ilość czasu jakie te osoby w zespole mogą poświęcać na twój projekt, to super ważne jest to, żeby te zespoły były jak najbardziej do siebie zbliżone, jeżeli chodzi o sposób działania, jeżeli chodzi o narzędzia. No i sposób działania zaczęliśmy sobie od celów biznesowych i tego w jaki sposób te cele zdobywać.

Teraz jeżeli chodzi o narzędzia, oba zespoły powinny komunikować się z tobą w ten sam sposób, czyli jeżeli masz Teamsa, no to działaj z Teamsem w obu zespołach, a nie miej z jednym zespołem Slacka, a z drugim Teamsem, bo to nie zadziała. Jeżeli korzystasz z JIRy, z RedMina czy z np. ClickUp albo Trello, jeżeli chodzi o zadania, to drugi zespół też powinien korzystać z tego samego narzędzia.

Oczywiście te zespoły powinny mieć osobne tablice, osobne flow, osobne np. sprinty, jeżeli pracujecie w Scrumie, czyli generalnie tutaj sposób pracy z tymi zadaniami powinien być niezależny, tak jakby to były jednak dwa osobne zespoły. Natomiast sposób pracy, narzędzia, forma komunikacji powinna być identyczna.

Ona nie może być nawet zbliżona. Ona musi być taka sama, no bo dzięki temu już tutaj na drugim kroczku nie utykamy na zasadzie, dobra to teraz muszę się przełączyć z nawędzia do nawędzia, komuś coś napisać, tylko mamy jeden ekosystem, gdzie pracujemy. Teraz to co te zespoły powinny mieć wspólne, w momencie kiedy już mamy rozpisane zadania następuje development.

No i teraz w ramach developmentu ludzie powinni korzystać z tego samego repozytorium, mieć te same zasady dotyczące pisania kodu, więc znowu jeżeli masz to już zrobione wcześniej zespołem to super, jeżeli nie to warto to nadrobić, zanim taki dodatkowy zespół będzie uruchamiany. No i przede wszystkim móc pracować razem. To co ważne na etapie realizacji projektu to to, żeby proces code review, czyli wzajemnej weryfikacji kodu jaki powstanie był realizowany między zespołami też, czyli nie tylko w zespole tylko też między zespołami.

To powoduje, że to jest jeden z obszarów, gdzie te zespoły wymieniają się wiedzą. Kolejny obszar, który jest do zaopiekowania to jest dokumentacja i znowu oba zespoły powinny korzystać z tej samej dokumentacji w tym samym narzędziu, mieć ustalony wspólny schemat jak tą dokumentację się tworzy, jakie rzeczy się tam zapisuje. No i w ten sposób też powinny te osoby tam pracować.

Teraz jeżeli chodzi w ogóle o wymianę wiedzy i tak, jeżeli chodzi o sam proces testów i na przykład środowiska, wyznaję zasadę, że raczej każdy zespół powinien mieć swoje środowisko testowe, takie online, na którym dokonuje się odbiorów prac, czy po prostu testuje te prace. Można oczywiście w zależności od tego z ilu środowisk się korzysta w firmie, to można sobie to gdzieś tam tą ścieżkę wydzielić na środowisko testowe i na przykład preprodukcyjne, natomiast co do zasady chodzi o to, żeby każdy zespół miał swoją ścieżkę osobną do uruchomień, projektów, czy zadań w zasadzie produkcyjnie. Teraz jeżeli chodzi o testy, no to znowu zakładamy, że to jest osobny proces testów, ale jednak, który działa dokładnie w taki sam sposób w obu zespołach.

I jeżeli chodzi o proces uruchomienia zmian produkcyjnie, jestem bardzo dużym fanem tego, żeby każdy zespół zadania uruchamiał niezależnie na produkcji, czyli żeby deploye w miarę możliwości nie były łączone. Wynika to z tego, że w momencie kiedy połączy się zadania jednego i drugiego zespołu i uruchomi produkcyjnie i coś tam nie zadziała, no to w tym momencie zespoły nie wiedzą, który zespół ma zareagować, który nie, więc wtedy warto im pomóc i po prostu rozdzielić te deploye na dwa osobne dni. Oczywiście, jeżeli jest taka możliwość.

Jeżeli takiej możliwości nie ma, to warto, żeby z każdego zespołu albo przynajmniej nawet z jednego z tych dwóch zespołów był wyznaczony taki release manager, który odpowiada za dany proces deploymentu danego dnia i do tej osoby zgłasza się wtedy wszelkie problemy, uwagi, zastrzeżenia, jeżeli coś nie zadziałało. I to ta osoba wtedy jest odpowiedzialna na to, żeby szybko przeanalizować i zobaczyć w którym obszarze mogą być problemy i czy dany błąd przekierować do zespołu głównego, czy do tego zespołu dodatkowego. Więc to jest ta też kwestia, jeżeli chodzi o relisy i w pewnym stopniu odpowiedzialność.

Teraz, jeżeli jesteśmy już przy odpowiedzialności, bardzo ważne jest to, żeby sobie zakontraktować z oboma zespołami, kto za co odpowiada, jeżeli chodzi o proces. No bo to też jest super istotne, żeby potem było wiadomo, że jak np. jest uruchomiony proces deploymentu, to co się robi z innymi środowiskami, w jaki sposób wyrównuje się zmiany na tych środowiskach, kto będzie dbał i o co, kiedy ktoś odpowiada za np.

dany fuck up, no i w jaki sposób potem go też naprawia. I wszystkie tego typu rzeczy, to tą odpowiedzialność też sobie jest dobrze zdefiniować i opisać, no bo jeżeli to nie jest zapisane, to potem ludzie po czasie zwyczajnie zapominają. To co jest jeszcze istotne, to to tak naprawdę dwie ostatnie kwestie, które chciałbym w ramach tego przekazać.

Pierwsza z tych dwóch ostatnich jest taka, że warto, żeby te zespoły też ze sobą rozmawiały i co do zasady jestem zwolennikiem, żeby raz w tygodniu, przynajmniej albo dwa razy w tygodniu, był taki slot czasowy w kalendarzu, kiedy nawet przedstawiciele po prostu tych zespołów, np. ich tech leadowie, są w stanie się połączyć i sobie kilka rzeczy powyjaśniać, czy powymieniać się wiedzą, jeżeli jest taka potrzeba. Po prostu, żeby mieli do tego przestrzeń.

Uważam, że to bardzo dużo daje w przypadku, jeżeli takie dwa zespoły pracują, szczególnie jeżeli to robią nad jednym produktem, czyli jedną jakąś aplikacją, czy jednym zbiorem aplikacji, które mają wspólną odpowiedzialność biznesową. I to jest ta pierwsza rzecz. A ta druga rzecz to kwestia dzielenia projektu na moduły.

No i teraz bardzo często obserwuję już, jeżeli już funkcjonują nawet właśnie zespoły typu jest zespół wewnętrzny, główny i np. kilka osób z zewnętrznego software house'u, to obserwuję coś takiego, że do tego zewnętrznego software house'u są wydzielane pewne moduły, które się zleca na zewnątrz. No i potem się okazuje, że np.

software house to odpowiada za moduł XYZ, a za całą resztę odpowiada zespół wewnętrzny. No i teraz w perspektywie IT jest tak, że ta odpowiedzialność jest podzielona też od strony kodu. Każdy jest tutaj zadowolony.

Każdy oprócz biznesu, bo np. biznes przychodzi i mówi dobra, chcemy zrobić szybciutko jakieś zmiany, jakieś poprawki, wdrożenie cokolwiek w tym korze aplikacji. No i przychodzi do kogoś z zewnętrznego działu IT, bo chce to po prostu popchnąć sprawnie.

Pyta software house'u, czy mają kogoś dostępnego, kto mógłby się tym zająć i szybko dołączyć do zespołu i podziałać. No a software house mówi, że nie może tego zrobić, no bo za to odpowiada zespół wewnętrzny i tak naprawdę to jest bardzo częsty problem, który powoduje, że firmy nie idą do przodu, mimo tego, że wdrożyły sobie ten drugi zespół właśnie, czy po prostu osoby z zewnątrz, no bo te osoby z zewnątrz nagle nie mają możliwości wprowadzania zmian, gdzie ten brak możliwości wynika tylko i wyłącznie z tego, że nie zostało to dobrze ustalone na początku i główny zespół IT zwyczajnie nie chce się podzielić modułami, czy na przykład nie ma tego ustalonego po prostu, więc dla bezpieczeństwa nie daje dostępu np. głębiej, głębiej do systemu albo nawet daje te dostępy, ale nie daje możliwości wprowadzania tam zmian.

Więc ja jestem raczej fanem tego, żeby dzielić te odpowiedzialności per obszary biznesowe, czyli np. że dany zespół zewnętrzny odpowiada np. za potrzeby danego działu, czyli za potrzeby biznesowe i to nam definiuje wtedy, jeżeli skupimy się na potrzebie biznesowej i w ten sposób dzieleniu jakby tego per zespoły, czyli jak wypiszemy sobie, że w najbliższym czasie mamy pięć celów biznesowych, to warto je wtedy podzielić w ten sposób, że np.

dwa, trzy cele biznesowe zostawić w zespole wewnętrznym faktycznie, ale np. kolejne dwa cele takie do zrobienia szybciej, czy do zrobienia nawet równolegle z tamtymi trzema, przenieść zwyczajnie na zespół zewnętrzny, żeby to on mógł się wtedy tym zająć i wtedy w zależności kto czego potrzebuje, trzeba oczywiście przeanalizować na ile te cele biznesowe są ze sobą powiązane, żeby sobie za bardzo też nie wchodzić w drogę na etapie realizacji, no ale to też nie oznacza, że nie można w ogóle sobie wchodzić w drogę, tylko właśnie w ramach wzajemnej komunikacji trzeba na bieżąco wymieniać się informacjami kto gdzie wprowadza zmiany i to się dzieje w ramach procesu code review, no i trzeba na bieżąco te po prostu procesy synchronizować, tylko tyle i aż tyle jak to mówią. Podsumowując te kwestie, bo trochę się tutaj rozgadałem, dodatkowy zespół IT taki z zewnątrz, czyli ten taki team leasing robiłbym w momencie kiedy miałbym dużo potrzeb długoterminowych jeszcze nie do końca zdefiniowanych, kiedy miałbym to na poziomie celów biznesowych jakiejś wizji, a niekoniecznie miałbym to już zebrane w zadania i wiedziałbym, że potrzebuję tak realnie po prostu tego drugiego zespołu, no ale nie chcę go rekrutować z różnych przyczyn, na przykład czasu, na przykład wiedzy, na przykład doświadczeń przeróżnych, po prostu, więc wtedy bym się szczególnie skupiał na tym modelu skalowania numer 3, czyli po prostu uruchomieniu dodatkowego zespołu.

No i podsumowując dzisiejszy odcinek, tak naprawdę chciałbym żebyście z tego zapamiętali trzy główne rzeczy, to że mamy model kiedy możemy po prostu włączyć danego specjalistę, analityka, programistę czy testera do zespołu i że warto z poziomu celów biznesowych i z poziomu procesu wytwarzania oprogramowania zastanowić się kogo tak naprawdę nam potrzeba, czyli innymi słowy gdzie jest wąskie gardło i to jest pierwsza rzecz. Druga rzecz z podsumowania, że projektowo najłatwiej zlecać jakiś cały moduł, całą integrację albo coś z czym zespół wewnętrzny kompletnie nie ma doświadczenia, no bo wtedy możemy łatwo ten projekt sobie opisać, dać mu jakieś kryteria odbioru i po prostu go wyoutsourcować i mieć z głowy. I trzeci model, kiedy wiemy, że te nasze potrzeby są raczej długoterminowe, że ich jest raczej dużo, no i że to tak naprawdę są potrzeby na drugi zespół, no to jest zwyczajnie uruchomienie dodatkowego zespołu.

No i jeśli czujesz, że twoja firma mogłaby realizować więcej tematów szybciej, skuteczniej, mądrzej, ale obecny zespół jest po prostu w cudzysłowie zawalony pracą i nie da rady już wziąć kompletnie nic więcej na swoje barki, to znak, że naprawdę trzeba pomyśleć nad potencjalnie nowym modelem współpracy. Nie zawsze będzie chodziło o zatrudnienie tylko kolejnego programisty i jeszcze kolejnego, bo okazuje się, że w tym całym procesie wytwarzania programowania development to jest tylko jeden z iluś etapów. Czasem lepiej postawić czy to na równoległy zespół, czy to na outsourcing, a czasem po prostu na kilka dodatkowych rąk do pracy na kilka miesięcy, ale rąk człowieka o właściwej specjalizacji.

Jeśli nie wiesz, który model będzie najlepszy w twoim przypadku, to serdecznie zapraszam do omówienia sobie takiej kawki na żywo czy kawki online, w ramach której chętnie przeanalizuję twoją sytuację i doradzę, jak moglibyśmy do tego podejść wspólnie, żeby twoje cele biznesowe zwyczajnie w świecie zrealizować. Dzięki bardzo za wysłuchanie dzisiejszego odcinka. Mam nadzieję, że zainspirowałem cię i trochę rozjaśniłem temat tego, że można mieć ciastko i zjeść ciastko, czyli z jednej strony mieć stały, stabilny zespół wewnętrzny, który realizuje długoterminowe zapotrzebowania firmy i te długoterminowe cele biznesowe i zjeść ciastko, czyli po prostu realizować krótkie pomysły, które chcemy wdrażać sprawnie i szybko z zespołem zewnętrznym.

Dzięki raz jeszcze i do usłyszenia za tydzień we wtorek. Cześć.