Współpraca wielu zespołów IT - sprawdzone rozwiązania

Wprowadzenie i cel odcinka

Czy da się zbudować dział IT bez zatrudniania własnych programistów? Jak połączyć siły różnych firm technologicznych, które korzystają z różnych narzędzi, mają odmienne podejścia, a mimo to stworzyć jeden, sprawnie działający, zintegrowany zespół? Jak zadbać o bezpieczeństwo, klarowność i jednocześnie nie stracić elastyczności, kiedy pracuje kilka ekip programistycznych naraz? Dzisiaj mam dla Ciebie odcinek, który szczególnie może zainteresować firmy z branż, gdzie niezawodność to podstawa, medycyna, produkcja, farmacja, logistyka, duży e-commerce czy też dystrybucja i te, które mają sporo różnych potrzeb do pogodzenia naraz. Zostań ze mną do końca i koniecznie subskrybuj ten kanał, bo opowiem Ci na przykładzie jednego z naszych klientów, jak można zorganizować współpracę kilku zespołów technologicznych, która działa. Nie przedłużając, serdecznie zapraszam.

Cześć, dzień dobry, z tej strony Grzegorz Tabor, a to jest podcast IT i biznes, gdzie jako dyrektor technologiczny pomagam przedsiębiorcom i menedżerom realizować projekty IT, które wspierają cele biznesowe skutecznie i w terminie. Jeśli napotykasz na swojej drodze wyzwania i potrzeby wsparcia Twojego biznesu świadomie z użyciem technologii, ten podcast jest dla Ciebie. Cześć, dzień dobry, witam serdecznie w odcinku numer 65. Współpraca wielu zespołów IT. Sprawdzone rozwiązania. I w dzisiejszym odcinku opowiem o tym, w jaki sposób właśnie można podejść do takiej koncepcji mocno odmiennej. To znaczy z reguły na rynku funkcjonuje koncepcja tego, żeby współpracować albo z własnym zespołem IT, która to koncepcja była bardzo mocno polubiona po pewnym wirusie z uwagi na fakt, że z software house’ami gdzieś tam się opinia pojawiała, że współpracuje się trudno. Z drugiej strony wcześniej właśnie próbowano współprac z software house’ami, szczególnie kiedy te zespoły IT gdzieś tam ciężko się rozbudowywały i były trudne warunki rekrutacyjne na rynku. Z kolei teraz jesteśmy w takiej kropce, no bo z jednej strony część rzeczy z powrotem zleca się do software house’ów i na nowo próbuje się z nimi współpracować, ale raczej w modelu fix price’owym niż godzinowym, co jest w sumie ważne. Z drugiej strony natomiast te wewnętrzne zespoły IT nie zawsze firmy wiedzą w jaki sposób z nimi współpracować, no i po prostu to wszystko nie wychodzi.

Studium przypadku – hybrydowy model współpracy IT

No i jeden z naszych klientów wpadł na pomysł, żeby zrobić pewnego rodzaju, ulubione słowo chyba w tym podcaście, hybrydę, no i połączyć pracę zespołów różnych zewnętrznych, tak jakby to był jeden duży zespół IT. No i zacznijmy od tego, że ta firma nie jest technologicznym nowicjuszem, jest to organizacja z mocnym zapleczem IT, architektura systemów jest mocno rozbudowana, część z tych systemów zresztą działa w firmie od lat, a część to stosunkowo nowe wdrożenia, niektóre systemy są w ogóle dopiero planowane w ramach roadmap’y i czekają na realizację. Niektóre z nich wymagają modernizacji, świeżego spojrzenia, czasem nawet powiedzmy napraw po wcześniejszych, różnych, no też często mniej udanych wdrożeniach. To jest też ważny kontekst w kontekście w ogóle tej historii, o której Wam opowiem, dlatego zwróćcie proszę na to uwagę. Po różnych doświadczeniach wcześniejszych firma bardzo ostrożnie podchodziła do wyboru nowych partnerów. Awaryjność, bezpieczeństwo danych, ciągłość działania, te trzy rzeczy to są kwestie, które były dla nich i są absolutnie krytyczne.

Dlaczego nie jeden dostawca IT?

No i pojawia się pytanie, dlaczego nie znaleźć po prostu jednej konkretnej firmy? Czy nie byłoby to prostsze i bardziej przejrzyste jeżeli chodzi o współpracę? Jest to naturalne pytanie, zwłaszcza jeśli zależy nam na klarowności i jednolitej odpowiedzialności. Jednak w przypadku tego klienta i wielu, wielu dużych organizacji, takich naprawdę dużych, o złożonych potrzebach, odpowiedź też jest bardziej złożona.

Trzy główne powody wyboru modelu multi-vendor

Po pierwsze, często potrzeby biznesu w takich przypadkach są tak szerokie i tak różnorodne, że jedna firma nie byłaby w stanie realizować ich efektywnie i z odpowiednią szybkością. Tempo działań, które biznes wymaga jest w tym momencie tak wysokie, że pojedynczy dostawca bardzo często może się zwyczajnie przeciążyć i realizować zadania zbyt wolno. Po drugie, z czego to może w ogóle wynikać? No między innymi z tego, że różne obszary technologiczne wymagają zupełnie innych specjalistycznych kompetencji. Mam na myśli to, że mamy do czynienia zarówno z gotowymi rozwiązaniami, które potrzebują takiego bardziej produktowego know-how, czyli jeżeli mamy wdrożonego jakiegoś gotowego ERP-a, HRM-a, DMS-a czy WMS-a takiego pudełkowego, no to potrzebna jest ta wiedza produktowa. Z kolei też, jeżeli budujemy jakieś rozwiązania dedykowane czy nakładki, wewnętrzne aplikacje, no to one też wymagają zupełnie innego podejścia, innego flow pracy, które wymaga też ciągłego rozwoju, integracji i dostosowywania do potrzeb klienta. Po trzecie, istnieje w tym wypadku ryzyko vendor-locka, czyli sytuacji, w której cały dany system mógłby stać się zależny od jednego dostawcy. Jest to zagrożenie, które trzeba brać pod uwagę, szczególnie w branżach takich superkrytycznych typu medycyna czy typu produkcja, gdzie awarie mogą oznaczać duże problemy pod kątem przestojów czy też problemy z bezpieczeństwem danych. I tutaj akurat klient miał już przykre doświadczenia i zrozumiał, że ta dywersyfikacja odpowiedzialności na różnych dostawców względem ich kompetencji, podejścia, to jest jakiś sposób na zmniejszenie tego ryzyka. I dodatkowo w projektach pojawiają się też obszary takie jak Power BI, AI czy zaawansowana analityka, które wymagają zupełnie jeszcze innego podejścia i innych kompetencji. I dlatego ta decyzja współpracy z kilkoma firmami, które są wyspecjalizowane w swoich obszarach, wydawała się tutaj być bardziej efektywnym i bezpieczniejszym rozwiązaniem.

Jasny podział ról i odpowiedzialności

Teraz to co jest ważne to to, że każda z tych firm wnosi swoje unikalne kompetencje, ma jasno wyznaczone odpowiedzialności i określony zakres czy też obszar działań. I jednocześnie wszyscy pracują w ramach wspólnej architektury, mają wspólny cel i funkcjonują pod konkretnym skoordynowanym nadzorem, co też jest bardzo ważną tutaj kwestią. I tego typu model wymaga bardzo dobrej organizacji i precyzyjnych reguł, no bo kiedy łączy się różne środowiska, różne zespoły, każdy z nich chce pracować inaczej, a jednocześnie biznes musi mieć świadomość i wiedzę w jaki sposób w ogóle i co do kogo zlecać, no i w jaki sposób. Tutaj się powtarzam, ale to jest też częsty problem. Nie ma tu miejsca na bałagan, na niejasne zakresy, czy na sytuację, że każdy będzie robił po swojemu, co też wymaga dużej dojrzałości i doświadczenia ze strony tych firm, tych partnerów technologiczno-biznesowych, którzy muszą współpracować i z klientem i ze sobą. I od samego początku klient postawił tutaj na transparentność i na klarowność. Każda firma ma jasno przypisany obszar odpowiedzialności. Do tego powstała też szczegółowa strategia architektoniczna, a rola i znaczenie każdej firmy jest określona w kontekście całego projektu, czy całej właśnie firmy klienta.

Rola lidera i strażnika danych

I w tym modelu jedna z firm pełni też rolę lidera i to jest ta firma, która realizuje najwięcej prac programistycznych i ma kluczowe znaczenie dla całego projektu. Tego typu firma nadaje rytm całemu przedsięwzięciu i koordynuje działania między zespołami. Obok niej działa inna firma, która pełni rolę takiego strażnika danych i odpowiada za taką całościową spójność, dokumentację i utrzymanie wysokich standardów, jeżeli chodzi o jakość danych. Dlaczego jest taki podział? Czyli jest lider taki organizacyjny nadający rytm prac i jest firma, która odpowiada jako drugi taki powiedzmy współlider, ale za kwestie danych. Wynika to z tego, że z jednej strony dane między tymi systemami bardzo są ze sobą powiązane i muszą być spójne. Z drugiej strony jest system, który te wszystkie dane zbiera w całość, czyli mówimy tutaj o ERP-ie. No i jeszcze z kolejnej strony firma od ERP-a kompletnie nie działa z systemami dedykowanymi, na których z kolei ta firma chce opierać swoją strategię dalszego rozwoju, widząc, że rozwiązania gotowe zwyczajnie nie spełniają jej oczekiwań. I to jest tutaj dlatego istotne, żeby właściwą firmę z tych wszystkich partnerów technologicznych wybrać zarówno na tego takiego strażnika danych, jak i też na tego lidera nadającego tempo prac, po to żeby całość szła dla klienta i firmy do przodu. Pozostałe firmy odpowiadają za konkretne klasy systemów i działają w ramach swoich wyznaczonych specjalizacji. Inne z kolei też firmy zajmują się środowiskami analitycznymi, bezpieczeństwem czy np. wdrażaniem eksperymentalnie AI-a. I co ważne, każda z tych firm może korzystać z własnych technologii, ale muszą być przestrzegane pewne zasady i taka spójność, jeżeli chodzi o ustalone punkty integracyjne i prowadzona wspólna, aktualna dokumentacja.

Systemy krytyczne i zasady bezpieczeństwa

I w projekcie bardzo wyraźnie są oznaczone zarówno systemy krytyczne, jak i też krytyczne procesy. I tutaj firma doskonale rozumie też to, że błędy w tym obszarze, gdyby te krytyczne systemy szczególnie przestały z jakiegoś powodu działać, no to kompletnie nie ma tutaj żadnej taryfy ulgowej, jeżeli chodzi o kwestie, no nie da się tego wytłumaczyć, musi to być zapewnione z określonym SLA. I właśnie SLA to jest jedna z zasad, jakie tutaj wdrożono, jeżeli chodzi o współpracę, czyli z jednej strony każda z firm ma określone SLA na swoje działania, z drugiej strony są też określone podejścia co do samych wdrożeń i w jaki sposób one powinny być przeprowadzone, według jakich procedur. Są ustalone reguły komunikacji i co ważne, jeden wspólny kanał komunikacji. Mam na myśli to, że jeżeli firma, klienta korzysta np. z Teamsa, to dobrym pomysłem jest, żeby wszystkie te podmioty korzystały z Teamsa na jakiejś wspólnej przestrzeni, a nie żeby jedne firmy korzystały z maila, drugie ze Slacka, trzecie z Whatsappa, a czwarte z Teamsa, bo wtedy to się na pewno nie uda. Na pewno środowiska produkcyjne są ze sobą połączone i środowiska testowe też muszą być ze sobą połączone, co jest częstym błędem, że środowiska testowe nie oddają tego, co się dzieje na produkcji. Tutaj musi to być połączone i każde środowisko testowe musi być też spięte z innymi środowiskami testowymi innych rozwiązań innych firm. Wszystkie zmiany, które są wdrażane muszą też przejść testy integracyjne, częściowo zautomatyzowane, częściowo manualne, ale to jest super istotny aspekt właśnie do tego, żeby zapewnić spójność i działania tych systemów i spójność danych w tych systemach. I teraz każda firma w tym układzie doskonale wie co, kiedy i z kim powinna skonsultować, bo to też jest ustalone, więc nie zakłada się tutaj patrzenia tylko na pojedynczą funkcjonalność i zadanie, tylko musi to wszystko być zgodne z całą taką strategią i architekturą, która została wypracowana.

Model współpracy łączący różne role i kompetencje

To jest taki model współpracy, który przypomina połączenie CTO ze serwis, czyli właśnie nasze usługi CTO na godzinę, trochę team leasingu, trochę project managementu, czy właśnie project managementu ze serwis, ale rozdzielone na kilka firm, które muszą działać jak jeden spójny zgrany zespół. I co ciekawe, tutaj też w trakcie tej współpracy jeden z partnerów został wyłączony właśnie z tej współpracy.

Dlaczego jeden z partnerów został wykluczony ze współpracy

Nie dlatego, że brakowało tutaj kompetencji technicznych czy technologicznych, powodem był brak transparentności, problemy z dostosowaniem się do wspólnych zasad, no i zwyczajnie inna kultura pracy, która z perspektywy tego partnera nie była możliwa do zmiany. I to pokazuje, że w takiej organizacji nie wystarczy tylko umieć programować, ale trzeba też umieć współpracować i umieć odnieść to, co się robi jako swój wycinek układanki do całej układanki, do całej strategii. I w naszym przypadku nie jesteśmy tutaj tylko wykonawcą tego właśnie wycinka systemu, tylko nasza rola jest taką rolą, gdzie jesteśmy partnerem technologicznym, który musi rozumieć cały ekosystem i potrafić efektywnie funkcjonować w środowisku z wieloma dostawcami jednocześnie.

Kluczowe zasady współpracy i komunikacji

Kolejny ważny krok to jest dostosowanie się każdej z firm do zasad współpracy wypracowanych przez klienta. Wspomniałem o środowiskach testowych, wspomniałem już wcześniej o wspólnym kanale komunikacji. Trzeba też połączyć wspólnie tablice, repozytoria, ustalić sobie też jasny proces akceptacji zadań. Oczywiście, że per dane flow pracy można wykorzystać różne per dana firma w pewnym stopniu. To znaczy, jeżeli jest taka sytuacja, że dana firma pracuje w określony sposób, to da się to też zorganizować, tylko trzeba po prostu ustalić punkty styku, czyli punkty momenty, kiedy następują odbiory, kto ich dokonuje i w jaki sposób. Trzeba ustalić w jaki sposób klient będzie zlecał zadania, czyli jeżeli klient potrzebuje coś zrobić, no to klient jako osoba nietechniczna, czy przedstawiciele tej firmy jako osoby nietechniczne w jakimś też stopniu, muszą wiedzieć do kogo mają się zgłosić, komu mają zgłosić te potrzeby i wiedzieć w jaki sposób zostanie to zweryfikowane z różnymi podmiotami, czyli z tymi różnymi subzespołami nazwijmy to, znaczy podzespołami, tak żeby każdy podzespół mógł wykazać też swoją opinię na dany temat. Trzeba tutaj też ściśle trzymać się ustalenia architektonicznych, żeby nowe rzeczy powstawały też z zatwierdzeniem osób czy firmy, która jest tą taką główną, tym liderem, który to wszystko koordynuje. No i trzeba oczywiście pamiętać o bezpieczeństwie i stabilności, szczególnie przy integracjach z systemami krytycznymi, gdzie każda zmiana musi być testowana na tych środowiskach testowych w całości.

Wyzwania i realia pracy w modelu multi-vendor

Teraz czy taka współpraca jest prosta? No nie jest. Czy ona zawsze przyspiesza realizację prac? No też nie zawsze. To znaczy nie zawsze jest tak, że jeżeli włączymy 10 firm to zrobimy coś 10 razy szybciej. Rzekłbym wręcz, że to będzie tak 3-4 razy szybciej a nie 10 razy szybciej. Chodzi po prostu o to, że im więcej firm współpracuje i zajmuje się swoimi obszarami, tym więcej rzeczy dobrze zorganizowanych i skoordynowanych można w jednym czasie realizować. Ale czy ta współpraca jest satysfakcjonująca? Zdecydowanie tak. W świecie dużych organizacji, zwłaszcza takich z rozbudowaną architekturą IT, wieloma systemami i dostawcami, samo dowożenie zadań to często jest za mało, bo trzeba widzieć cały obraz i rozumieć kontekst biznesowy i umieć się w niego wpasować.

Znaczenie zaufania i transparentności

I w tym projekcie, w tej współpracy kluczowe jest zbudowanie zaufania po wcześniejszych, trudnych doświadczeniach klienta, tak żeby mógł on mieć we współpracy partnera i partnerów, którzy nie tylko będą pisali kod, ale będą też rozumieli jak ten kod wpisuje się w całość ich systemów. I stworzony tutaj model to odpowiedź na rosnące wymagania biznesu, ponieważ tempo realizacji pracy byłoby niemożliwe do osiągnięcia przy współpracy tylko z jedną firmą, a nawet samym zespołem wewnętrznym. Chyba, że ten zespół byłby turbo duży, ale od tego się trochę jednak już teraz odchodzi. I dlatego powstał model, w którym działamy jako część ich własnego outsourcingowego, takiego zespołu z pełną kontrolą nad wszystkimi zaangażowanymi zespołami wewnątrz tej struktury. I nie każdej firmie taki sposób współpracy będzie odpowiadał, dlatego kluczowa była pełna transparentność już na etapie przed rozpoczęciem współpracy, czyli jasne przedstawienie oczekiwań i wymagań pozwoliło tutaj uniknąć wielu nieporozumień i stworzyć solidne podstawy do działania i w ogóle do zbudowania tej struktury współpracy. Pracujemy tutaj na narzędziach klienta i w procesach, które zostały wspólnie ustalone. Trzymając się ustaleń architektonicznych jednocześnie możemy wnosić nasz know-how, świeże spojrzenie, no i też nadawać tempo realizacji tych wszystkich prac, co pomaga rozwijać wszystkie te systemy działające w obszarze klienta, no i daje nam ogrom satysfakcji.

Najważniejszy wniosek – model współpracy ważniejszy niż sama technologia

No i myślę, że to jest chyba najważniejszy wniosek, że w IT nie liczy się już tylko technologia, na co bardzo dużo i długo i często i wiele razy zwracano uwagę, szczególnie wśród firm technologicznych, ale jednak ważny jest też aspekt tego modelu współpracy, który pozwoli biznesowi działać szybko, bezpiecznie i w zgodzie z długoterminową strategią biznesową firmy.

Zaproszenie do kontaktu i współpracy

Jeżeli w Twojej organizacji pojawiły się wyzwania związane z integracją różnych zespołów technologicznych lub chcesz usprawnić współpracę z zewnętrznymi partnerami albo w ogóle rozpocząć taką współpracę z zewnętrznymi partnerami, żeby trochę podkręcić tempo realizowanych prac, to chętnie porozmawiam. Razem możemy zastanowić się, jak zbudować zgrany i efektywny zespół, który realnie wesprze rozwój Twojego biznesu. Zapraszam do kontaktu. Sprawdźmy, co możemy dla Ciebie zrobić. Tymczasem bardzo dziękuję za wysłuchanie dzisiejszego odcinka. Mam nadzieję, że to będzie pewna forma inspiracji do tego, jak można jeszcze inaczej podejść do realizacji projektów IT, niekoniecznie w modelu tylko software house albo tylko zespół wewnętrzny. Jednocześnie gorąco zachęcam do tego, żeby tę decyzję na spokojnie przemyśleć, bo nie zawsze trzeba w takim modelu działać. To musi być już taka sytuacja, w której faktycznie widzimy ewidentnie, że jedna firma nie jest w stanie obsługiwać wszelkich obszarów, jakie mamy na stole do obsłużenia. Dzięki raz jeszcze za wysłuchanie dzisiejszego odcinka. Jeżeli jest to dla Ciebie merytoryczna, przydatna wiedza, zachęcam do subskrypcji mojego kanału i do usłyszenia za tydzień we wtorek.

Cześć!