Cześć, dzień dobry. Witam was w podcascie 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 kieruje do właścicieli firm oraz menadż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 35. 7 porad jak skutecznie zmienić lub rozbudować zespół IT, aby realizować cele biznesowe sprawniej.

Przejmowanie projektów IT przez nowy zespół to proces wymagający przemyślanego planu i precyzyjnego działania. O tym jak poznać, że projekt nie idzie w dobrym kierunku mówiliśmy w odcinku nr 6. Także jeżeli jeszcze nie jesteście pewni, czy wasze podejrzenia tutaj są słuszne, to zachęcam do odsłuchania właśnie tego odcinka nr 6 i zweryfikowania owych podejrzeń. Natomiast kwestia jest taka, że nie zawsze jest tak, że to brak dobrej jakości jest motorem napędowym zmiany.

Często okazuje się, że po prostu wystarczający zespół niekoniecznie idzie z duchem czasu, czy też niekoniecznie jest dobrym partnerem biznesowym cały czas. Z tego po prostu względu, że nie nadąża za pędzącym biznesem, który ciągle chciałby realizować coraz więcej projektów i coraz więcej zmian. Także dzisiaj skupimy się na konkretach.

Jeżeli zakładasz, że twój zespół być może realizuje pracę zbyt wolno, albo wdrożenie jest niekończącą się historią, albo twój projekt jest według ciebie niekoniecznie najlepiej zaopiekowany i zastanawiasz się nad zmianą zespołu bądź jego rozbudową, to przedstawię ci 7 porad jak skutecznie zmienić, by rozbudować zespół IT, aby twoje cele biznesowe były zaopiekowane. Nie przedłużam, serdecznie zapraszam do części głównej dzisiejszego odcinka. Cześć, dzień dobry.

Witam Was serdecznie w 35 odcinku podcastu IT i biznes. Przygoda trwa, odcinki są nagrywane, także cieszę się, że systematyka tutaj, czy systematyczność jest zachowana. No i co, zaczniemy sobie od tego, że opowiem wam dzisiaj o tym, w jaki sposób ten projekt, który wynika z naszych celów biznesowych zrealizować projekt, projekty zrealizować odpowiednio, czy to z zespołem obecnym, czy to rozbudowując go, czy to po prostu z nowym zespołem.

Skupię się tutaj głównie na tej części już samego procesu zmiany, to znaczy to jest ten moment, kiedy już być może podjąłeś, bądź podjęłaś decyzję o tym, że chcesz nowy zespół, albo chcesz swój obecny zespół powiększyć, no i zastanawiasz się jak to teraz poukładać, jeżeli chodzi o kroki i teraz jak to zrobić. I teraz przede wszystkim myślę, że zacznijmy od tego, co już najprawdopodobniej na tym etapie wiesz, bo być może jeszcze nie zebrałeś, nie zebrałaś tego w takie powiedzmy podpunkty planu i działania, no ale na pewno podejmując decyzję o zmianie jesteś świadomy, bądź świadoma tego, dlaczego chcesz to zrobić, no bo coś cię tutaj do tego napędza. No i pierwszy punkt tak naprawdę, pierwsza porada to zdiagnozuj problem, jasno określ oczekiwania.

No i teraz generalnie chodzi tutaj o to, bo być może tak, są różne powody, dla których być może czas realizowanych zadań zbyt mocno odbiega od pierwotnych deklaracji, a może masz wrażenie, że zespół nie komunikuje się w sposób transparentny, a jak dopytujesz o szczegóły, no bo masz takie prawo, to dostajesz jakiś zdawkowy techniczny bełkot, albo może na przykład sytuacja wygląda tak, że projekt jest podzielony na różne części, z których na przykład taka kluczowa, jakiś rdzeń został ukończony, całość już działa na wersji produkcyjnej, produkt jest już funkcjonalny, czyli klienci na przykład mogą realizować zakupy w twoim e-commerce, albo na przykład twój wewnętrzny zespół korzysta już z systemu dla niego zbudowanego, ale jednocześnie trwają prace nad kolejnymi funkcjonalnościami. No i co się dzieje? Każde wdrożenie nowej funkcji generuje błędy w tym, co już powinno działać, tak zwane regresje, wracasz do poprawiania rzeczy, które już dawno powinny być zamknięte, a w efekcie na przykład 70% czasu poświęcasz na gaszenie pożarów, a tylko 30% na realny rozwój projektu. Jest tak, że generalnie pożary się pojawiają w projektach i tego nie da się uniknąć w 100%, natomiast odpowiednie zarządzanie pożarami i zarządzanie czasem na te pożary jest szalenie istotne.

No i tutaj warto podsumowując, żebyś wiedział, wiedziała dokładnie, co cię denerwowało w tej współpracy, czy irytowało, albo co jest twoim głównym motorem napędowym, żeby myśleć o zmianie bądź rozbudowie zespołu, tak, żeby to sobie nazwać, żeby w pewnym sensie nie popełnić drugi raz w cudzysłowie tego samego błędu, albo wejść do niewłaściwej rzeki, jak to się chyba mówi, albo nie mówi. No i teraz jeżeli chodzi o... dwa razy się nie wchodzi do tej samej rzeki, to prawda, ale to nic, tutaj chodzi po prostu o to, żeby wybrać właściwą drogę. No i dobrze, idźmy dalej.

Punkt drugi, to jest przygotuj kompletną dokumentację projektu. No i oczywiście, jeżeli mamy diagnozę problemu, to już wiemy, co trzeba poprawić, czyli na przykład chcę realizować więcej zadań, albo chcę realizować zadania z mniejszą ilością błędów po czasie, albo w ogóle bez błędów w idealnym świecie. Chciałbym robić wdrożenia sprawniej, albo chciałbym, żeby ktoś zarządził, nie wiem, wyszkolił użytkowników na przykład z nowych funkcjonalności, które są wdrażane, bo nikt o tym nie pomyślał.

Albo chciałbym właśnie mieć więcej informacji o rzeczach technicznych, żeby ktoś mi je tłumaczył po ludzku, a nie technicznym bełkotem, czyli to już wiem, czego tutaj potencjalnie bym oczekiwał od nowego zespołu, albo od nowych członków tego zespołu. No i teraz przychodzi moment, kiedy już te osoby się pojawią, czy to z zewnętrznej firmy, czy wewnętrznie, to niezależnie, bo proces jest dość podobny. No i będzie ten moment przekazania projektu.

No i teraz do tego momentu w idealnym świecie powstałaby wielka dokumentacja, w ramach której opisalibyśmy, jaki był cel biznesowy projektu i wymagania funkcjonalne, jaki jest obecny cel biznesowy projektu, czy on się jakoś zmienił, jakoś ewoluował. Opisywalibyśmy architekturę systemu, użyte technologie, stan prac, gdzie te prace są zlecane, w jaki sposób, w jakiej metodyce. Opisywane różne integracje, czy mamy jakieś API, czy jest podział na front-end i back-end.

Mielibyśmy dane kontaktowe do kluczowych osób z zespołu. No i cóż, dużo tego. No i jeżeli chodzi o kwestie tak naprawdę dokumentacji, to często jest tak, że jak zadajemy pytanie, czy jest w projekcie dokumentacja, to ludzie tak jakby zniżają wzrok, patrzą w dół i mówią, że piszemy dokumentację, zdarzało nam się trochę pisać na przykład komentarzy w kodzie, ale generalnie komentarze w kodzie to niekoniecznie jest dokumentacja.

No i teraz w ramach tego punktu, żeby podejść do tego mocno realnie i tak rzeczowo, wydaje mi się, że dobrze jest, aby tą dokumentację mieć, ale oczywiście spisaną na tyle, na ile się da. Czyli potrzebny jest taki ogół dokumentacji, w ramach którego jesteśmy w stanie po zapoznaniu się z nią i co ważne ona nie może być super długa, bo jak będzie za długa, to nikt się z nią nie będzie zapoznawał dokładnie. Natomiast ona musi być na tyle szczegółowa, a jednocześnie na tyle ogólna, żebym zapoznając się z nią potencjalnie jako na przykład nowy partner biznesowy, był w stanie z grubsza wiedzieć o co w tym projekcie chodzi, jaka jest użyta architektura jak najbardziej, ale też bardzo podstawowo, bo pewne rzeczy po prostu wyjdą w toku prac i tego się nie uniknie.

Oczywiście trzeba to robić z głową, trzeba to robić na odpowiednim środowisku testowym, te różne zmiany, bo przy nich będą wychodziły pytania, będzie wychodziła wiedza do zdobycia. No i to jest kwestia najbardziej, na którą bym się nastawił, czyli nowy zespół trzeba w pewnym sensie wdrażać też mając kogoś w swoim biznesie, kto będzie otwarty na to, żeby raz na jakiś czas na jakieś pytania odpowiedzieć, bo oczywiście dokumentacja jest potrzebna w kontekście wdrażania nowych ludzi, natomiast ludzie z twojego biznesu, znający twój biznes i wiedzący czemu ktoś kiedyś podjął jakąś decyzję i dlaczego przynajmniej z grubsza, to będzie dużo, dużo większa wartość niż ta dokumentacja. I na tym bym się przede wszystkim skupił.

Punkt trzeci, zabezpiecz dostęp do kluczowych zasobów. To jest taka podstawa podstaw i o tym trzeba, o to trzeba zadbać w momencie kiedy pojawiają się nowe osoby. O to trzeba zadbać także kiedy się pojawia obecny zespół, ale to kwestia taka do nadrobienia bardzo szybko, więc ja to też tutaj bardzo polecam w ramach punktu trzeciego.

I trzeba zadbać o kluczowe zasoby i techniczne i organizacyjne, tak żeby nowy zespół mógł jak najbardziej gładko przejść przez te rzeczy. I teraz rzeczy o jakie trzeba zadbać, taka absolutna podstawa, to jest tak, dostęp do kodu i do repozytoriów. My z reguły korzystamy z systemu kontroli wersji git.

On pozwala zapisywać progres w projekcie, czyli robić ctrl s powiedzmy od strony kodu i w ramach takich pojedynczych porcji zapisywać te informacje. No i teraz właśnie ten dostęp do kodu jest bardzo istotny, żeby go mieć na swoich serwerach czy tam na swoim środowisku, żebyśmy jako firma mieli do niego dostęp i mogli zarządzać dostępem dla wszelkich osób, które będą z tego kodu korzystać i na tym repozytorium pracować, bo oczywiście programiści na takim repozytorium pracować powinni. Druga rzecz to jest oczywiście dostęp do środowiska testowego i dostęp do środowiska produkcyjnego.

Tutaj istotne jest to, żeby nowy zespół miał też dostęp do środowisk właśnie testowych, do środowiska produkcyjnego, jeżeli będzie odpowiadał za proces deployment'u, czyli za uruchamianie zmian na środowisku docelowym to też. No i tu też oczywiście, że jeżeli jakieś funkcjonalności będą wymagały drobnych poprawek, to będzie po prostu potrzebny ten dostęp do środowiska produkcyjnego. Natomiast jeżeli damy dostęp też do środowiska testowego, to będzie można przejść sobie fajnie cały proces od A do Z, czyli od momentu potrzeby biznesowej, przez rozpisanie zadania, przez code review, przez testy tego zadania, no aż po uruchomienie zadania produkcyjne.

No i to, co jest istotne to to, żeby nowy zespół, czy to będzie drugim zespołem rozszerzającym zespół wewnętrzny, czy to będą nowi ludzie, czy po prostu zupełnie nowy zespół, który zastępuje zespół poprzedni. Ważne jest, żeby miał też narzędzie do zarządzania projektami. No i tutaj umówmy się.

Każdy projekt potrzebuje dobrze zorganizowanego systemu zarządzania zadaniami i też po prostu do komunikacji. Więc jeśli twój projekt był prowadzony na przykład na Trello, na Jeerze, czy w Asanie, to zadbaj, aby nowy zespół miał pełny wgląd w to, co się tam działo. No bo jeżeli nie będziesz miał, miała informacji o takiej przestrzeni, to warto dowiedzieć się od obecnego zespołu IT, czy taka przestrzeń była.

Generalnie nie wyobrażam sobie, żeby biznes nie miał dostępu do zadań, ale jednocześnie wiem, że tak się czasem zdarza, że z jakiegoś powodu biznes nie ma dostępu do tasków, na których pracują programiści. Więc tym bardziej warto sobie zadać pytanie, czy na pewno mam do tego dostęp i czy jestem w stanie w każdej chwili podejrzeć stan prac plus to, co dokładnie jest realizowane w ramach danego zadania. No bo te zadania powinny być dokładnie opisane i powinniśmy być w stanie to zrobić.

No i też jeżeli chodzi o kwestie dostępów do projektów, no to też jeżeli na przykład korzystamy z usług chmurowych, no to tutaj też trzeba dać dostęp. Jeżeli na przykład mamy bazy danych na innych serwerach albo na przykład DNS-y tak zwane, czyli rzecz powiązana z domeną, która kieruje domenę na właściwy serwer, tak w dużym uproszczeniu, no to to są rzeczy, do których dostęp nowi wykonawcy czy ktoś po stronie nowego partnera powinien mieć, jeżeli jest mu to faktycznie do prac potrzebne. No i tutaj myślę, że te dostępy, no to jest taka istotna sprawa.

Trochę się tutaj rozgadałem, ale podsumowując ten punkt, ważne, żeby po prostu do wszystkiego, co nowi ludzie będą potrzebowali mieć łatwy dostęp. Punkt czwarty, zleć audyt wykonywanych prac. Tutaj jeżeli chcesz już podjąć działania na przykład z nowym zespołem, to warto zlecić takie przeprowadzenie audytu technicznego przez nowy zespół.

To będzie moment, w którym ten nowy zespół będzie mógł zapoznać się z dokumentacją, będzie mógł zapoznać się z kodem, z serwerami, z tym, co tam jest skonfigurowane. Będzie mógł zadać już też pierwsze pytania, będzie mógł pokazać, czy rozumie ten projekt, czy absolutnie go nie rozumie. To też dać jakąś wiedzę o tym, czy ten nowy zespół jest faktycznie tutaj odpowiedni.

No i też czy będzie mógł sobie po prostu nadrobić te takie powiedzmy luki informacyjne. To jest taki proces, bo to też brzmi, że audyt to będzie coś bardzo długiego, szalenie trudnego. I oczywiście w zależności od firmy różnie się do tego podchodzi.

Natomiast to też warto sobie ustalić na przykład, co będzie w zakresie tego audytu. Potraktować to trochę projektowo, tak jak większość rzeczy, gdzie mamy więcej niż kilka zadań. Jeżeli jest projekt wykonania audytu, no to ten projekt powinien mieć właśnie ustalony termin, powinien mieć ustalony zakres tego audytu, powinien mieć ustalony efekt końcowy, czyli takie kryteria odbioru, że ten projekt faktycznie się zakończył, czyli ten audyt niejako zakończył się pozytywnie.

No i pozytywnie to znaczy, że są z niego wnioski, w tym sensie pozytywnie. No i, że faktycznie ten projekt ma swojego product ownera, do kogo można napisać i podpytać, jak sytuacja z audytem, jak to wszystko wygląda. No i tutaj jeżeli nawet jest dokumentacja projektu, no to warto mocno zadbać o to, żeby ten audyt ktoś wykonał, no bo to pozwala ocenić, czy wszystkie funkcjonalności się zgodzą z dokumentacją, czy być może są jakieś niezgodności, jakieś błędy, które trzeba poprawić, czy po prostu jakieś elementy wymagają dostosowania.

No i w tym wypadku audyt pozwoli również na oszacowanie kosztów i tak naprawdę czasu potrzebnego na przejęcie projektu, co też powinno pomóc po prostu w dalszej realizacji tego procesu przejmowania projektu, czy też rozszerzania zespołu. No i o czym należy tu jeszcze w sumie pamiętać, aby przyspieszyć proces pełnego przejęcia projektu przez nowego dostawcę. Tak naprawdę to nikt nie zna lepiej projektu niż osoba, która go wykonywała, czy osoby, które wykonywały dany projekt.

No a przynajmniej w teorii tak powinno być, że jeżeli ktoś wiedział co robi, no to będzie znał bardzo dużo gdzieś tam case'ów powiedzmy z życia tego projektu i też z różnych decyzji biznesowych, które wpływały na to jak ten projekt wygląda na przykład dzisiaj po kilku czy kilkunastu latach. No ale teraz dlatego właśnie warto zadbać o, i tutaj punkt piąty, warto zadbać o okres przejściowy, w którym twój obecny zespół będzie też dostępny w razie pytań. No i tu oczywiście jest tak, że jest z tym różnie.

Zdarza się, że tego zespołu nie ma. Mieliśmy takie sytuacje gdzieś tam w przeszłości i przejmowaliśmy takie projekty. To też trochę zależy od myślę świadomości organizacji, która projekt przejmuje i też metodyki przejmowania projektów, czy ktoś takowo ma, czy nie ma.

No bo często firmy wolą jednak pisać oprogramowanie zupełnie od podstaw niż przejmować to, co już istniejące. My mamy na odwrót, no ale to jest różnie, to znaczy na odwrót. Nie boimy się rozwiązań, które już funkcjonują, natomiast zdarza nam się też oczywiście pisać rozwiązania od podstaw, kiedy faktycznie jest już taka potrzeba, żeby takie rozwiązanie zbudować.

No i są takie sytuacje oczywiście, że tak, że zadajemy sobie pytanie, co autor miał na myśli, kiedy staramy się wgryźć w kot albo np. wdrażamy jakieś zmiany. Przy czym, i mam takie poczucie, że najłatwiej wdraża się w tym okresie przejściowym w projekt po prostu robiąc zadania, po prostu je realizując.

To jest istotna sprawa taka wtedy, że jeżeli tego zespołu nie ma w razie pytań, no to pytania lądują u biznesu i tutaj kluczowe jest to, żeby właśnie firma przejmująca projekt, mająca metodykę do przejmowania projektu wiedziała, że w jaki sposób zadać pytanie do osoby z biznesu, czemu to tak tutaj mogło zostać zrobione. No bo też widziałem takie sytuacje, gdzie np. ludzie gdzieś tam techniczni po prostu wklejali kawałek kodu, który ktoś z biznesu miał przeanalizować, jakie tam są warunki.

No i pewnie, że to nie jest tak, że się nie da, no ale pytanie, czy o to chodzi w prowadzeniu biznesu, żeby analizować kawałki kodu. No moim zdaniem nie i trzeba właśnie mieć na to sposób i wiedzieć jak do tego podejść. No i tutaj oczywiście, że bezpośredni kontakt z realizatorem obecnym prac przyspieszy proces zrozumienia kodu, no i pozwoli pewne wnioski sobie wyklarować, ale koniec końców ja bym się na tym aż tak mocno nie skupiał, bo prawda jest taka, że jeżeli ktoś przejmuje projekt, no to już w pewnym sensie bierze za niego odpowiedzialność.

Warto sobie natomiast i tak bym podsumował ten punkt, przygotować opis momentu od kiedy pełną odpowiedzialność za projekt przejmuje nowy zespół, nowa firma. Czyli tutaj myślę, że fajnie to podzielić na etapy, że np. pierwszym etapem to jest jakiś etap audytu, drugi etap to jest moment, kiedy zespół zaczyna już realizować zadania, ale jeszcze ich nie uruchamia produkcyjnie i wtedy proces kod review i uruchomienia produkcyjnego w idealnym świecie organizuje jeszcze obecny zespół, który projekt zna wie jak tam idą deploye itd.

I w trzecim etapie to nowy zespół zaczyna realizować deploye i od tego momentu przejmujesz pełną odpowiedzialność za projekt. Ja bym tak do tego podchodził, no bo koniec końców tak się tutaj i tak musi wydarzyć. Punkt szósty, zdefiniuj cele na przyszłość i ustal priorytety.

Czy najpierw należy naprawić błędy, czy najpierw należy się skupić na wdrażaniu nowych funkcji, a może trzeba najpierw poprawić wydajność, a może skupić się na bezpieczeństwie? No tutaj odpowiedzi na te pytania będą zależały niejako od priorytetów twojej firmy. Z reguły to jest tak, że u klientów, których się spotykamy jest tak, że są jakieś pożary do rozwiązywania i trzeba się nimi zaopiekować w pierwszej kolejności. Przy czym bardzo szybko przechodzimy do tej fazy rozwojowej, aby jak najwięcej czasu i pracy jaką wykonujemy to były jednak te tematy rozwojowe, a nie tylko pożary.

Więc no to jest tak, że oczywiście, że zdarza się, że przy przejmowaniu projektów trzeba pewne rzeczy urealnić i z pewnymi decyzjami się pogodzić, no bo jeżeli dług technologiczny tak zwany był zaciągany bardzo, bardzo długo, to pewne ograniczenia będą. Natomiast tutaj też jest takie zjawisko, że zespoły techniczne zdarza się, że przechodzą zbyt w taki tryb, że to jest o, stary system, o, tu się nic nie da, o, jak tu ruszymy w jednym miejscu to się zepsuje w drugim i tak naprawdę na przykładzie tego ostatniego to nie jest problem, że się zepsuje w tym drugim miejscu coś, tylko problemem jest to, że nikt tego nie wykryje i tak to wyląduje na produkcji. Czyli nikt tego nie sprawdzi w odpowiednim sposób.

Dlatego tutaj warto zadbać o takie podstawy podstaw, o których wspomnieliśmy wcześniej. Warto też zadbać o testy regresji, o których wspominamy w innych odcinkach i tutaj też można w razie czego o nich posłuchać. I warto generalnie zapewnić sobie jak najbezpieczniejszy proces.

Natomiast trzeba po prostu brać pod uwagę też w dużej, dużej perspektywie biznes i jego potrzeby, no bo jeżeli skupimy się tylko na tym, że to jest stary system, tu się już nic nie da dodać, nic nie da się z tym zrobić i trzeba go w ogóle napisać od nowa i absolutnie nie da się inaczej, no to jeżeli tylko tak do tego podejdziemy no to nie ma mocy, żeby to po prostu funkcjonowało dobrze i żeby to funkcjonowało też dobrze od strony biznesowej. Więc tu dług technologiczny, długiem technologicznym, ale jeżeli będziemy mieć na uwadze, że no oczywiście, że są ograniczenia, oczywiście, że jest ryzyko, no ale znowu ograniczenia starajmy się jakoś przepracować, ryzyko starajmy się oszacować i zminimalizować no i skupiajmy się na celach biznesowych, żeby one były faktycznie tutaj zorganizowane. No i od strony jako potencjalnych tutaj przedstawicieli biznesu, menedżerów, no to zalecam po prostu dobrze zdefiniować te cele na przyszłość i też ustalić priorytety, czyli na ile można się skupić na przykład na jakichś poprawkach, na tak zwanej refaktoryzacji, czyli ulepszeniu kodu w tym wypadku, a na ile trzeba coś super pilnie dowieźć, bo od tego zależy jakaś część życia biznesu, no oczywiście pół żartem, pół serio, ale po prostu jakaś ważna rzecz dla biznesu.

No i tak naprawdę od tego potem wychodzi dalsze ustalanie takiej powiedzmy road mapy tego, co należy realizować, przy czym pamiętajmy, że w projektach IT jest tak, że często nie trzeba realizować tylko jednego wątku naraz, można sobie pozwolić na to, żeby jakieś rzeczy utrzymaniowe, w tym też właśnie jakaś refaktoryzacja kodu się znalazła, czy jakieś ulepszenia, czy jakieś wyciągnięcie czegoś do nowego mikroserwisu, no z reguły da się to poukładać, tylko trzeba po prostu do tego mądrze podejść i z takim nastawieniem probiznesowym, no a drugie wątki czy kolejne wątki to są wątki typowo biznesowe już, które wymagają nowych rzeczy. Dobrze i zbliżamy się do punktu siódmego, ostatniego już w tym odcinku i tutaj punkt jest taki, jeśli po prostu potrzebujesz szybszego tempa prac, to niekoniecznie musisz od razu zmieniać cały obecny zespół. Ja dodałem taki punkt na koniec, żeby właśnie zwrócić na to szczególną uwagę, że jeżeli generalnie jesteś zadowolony, bądź zadowolona z działania obecnego zespołu, jesteś zadowolony, zadowolona z jakości, z jaką ten zespół dowodzi, tylko po prostu trwa to za długo albo widać, że brakuje czasem jakiejś wiedzy, czy może jakiejś kompetencji w zespole, czy jakiś jeden konkretny obszar ewidentnie powoduje tego tak zwanego bottlenecka, czyli gdzieś tam coś utyka, nie wiem, ktoś nie ma czasu rozpisywać zadań, ktoś nie ma czasu zarządzić zespołem, ktoś nie ma czasu zrobić deployu, ktoś nie ma czasu przetestować zmian, ktoś nie ma czasu po stronie biznesu odebrać na przykład prac, to to wszystko nie oznacza, że musimy od razu zmieniać cały zespół.

I te przyczyny niewyrabiania się oczywiście mogą być różne, natomiast finalnym efektem no właśnie nie musi to być koniecznie zmiana całego zespołu, to mocno podkreślam. I można tutaj nowe prace, i to też taka mała inspiracja będzie wynikała z tego punktu, że można te nowe prace wydzielić jako na przykład osobny tak zwany mikroservice, czyli taką obok aplikację powiedzmy czy jakąś mini aplikację, która wspiera jakiś określony proces. Co ważne, to wszystko może być w ramach jednego interfejsu użytkownika, czyli dla ciebie jako użytkownika z poziomu biznesu czy menadżera nie będziesz generalnie widzieć zmiany na minus, czyli, że to jest kolejna aplikacja, ale od strony kodu dla osób technicznych i ogólnie dla działania systemu to będzie miało duże znaczenia.

Więc właśnie taki mikroservice można tutaj sobie wydzielić. Można też po prostu zrobić osobny tak zwany subprojekt, w ramach którego będą pewne prace realizowane na obecnym systemie, ale przez nowy zespół, albo można po prostu zorganizować połączenie pracy obu zespołów. Jeżeli chciałbyś lub chciałabyś się dowiedzieć jak zrobić to połączenie pracy obu zespołów albo w ogóle jak do tego podejść wszystkiego, to koniecznie subskrybuj mój podcast, to po pierwsze, bo chętnie dzielę się i będę jeszcze się chętnie dzielił wiedzą w tym temacie.

Natomiast też jeżeli chcesz zasięgnąć indywidualnej opinii z mojej strony, to po prostu serdecznie zapraszam do kontaktu. No i podsumowując dzisiejszy odcinek, omówiliśmy sobie takie najlepsze praktyki związane z przejmowaniem projektu, czyli o co zadbać, żeby ten projekt, nowa firma, nowy zespół lub rozszerzony zespół mógł szybko i w miarę bezboleśnie przejąć. Myślę, że zwróciliśmy tutaj uwagę na takie kluczowe aspekty typu dobrze zaplanowany okres przejściowy, dokumentacja rozsądna, porządki w kodzie, czy też jasne cele na teraz, ale i na przyszłość.

Wydaje się, że przejmowanie projektu to jest trudny proces no i on nie należy do najłatwiejszych, no nie ma się co czarować. Natomiast budowa projektu zupełnie od podstaw też nigdy nie jest łatwym procesem, bo wszystko rozchodzi się o to, żeby dobrze skomunikować IT i dobrze skomunikować ze sobą biznes. Także te dwie sfery muszą iść ze sobą w parze i o tą komunikację często w dużej mierze się tutaj właśnie rozchodzi.

Natomiast przejęcie projektu wcale nie musi oznaczać rewolucji, a raczej ewolucję, która umożliwi dostosowanie istniejącego rozwiązania do aktualnych potrzeb i celów firmy. I często ta decyzja o zmianie dostawcy lub o zmianie zespołu, czy powiększeniu zespołu wiąże się po prostu z trudnością, ponieważ naturalnie pojawia się obawa o na przykład utopione koszty zainwestowane w projekt, ale jednak jak pokazuje doświadczenie to czasem świeże spojrzenie na projekt może otworzyć, no tak serio, serio, nowe perspektywy, nowe spojrzenie nadać faktycznie i nadać też temu wszystkiemu kierunek, który pozwoli na optymalizację i dalszy rozwój. No i czy warto przejąć projekt? Czy warto przekazać projekt przede wszystkim? Może tak powinienem zadać pytanie.

Uważam, że jeżeli są trudności to warto. Jeżeli masz poczucie, że coś nie działa tak jak powinno, to warto zacząć od audytu pracy obecnego czy to partnera, czy od audytu pracy obecnego zespołu. Audyt to takie może nie do końca trafne słowo, natomiast ono naprawdę jakby sam ten proces audytu pomaga zapoznać się z sytuacją firmy i często już na tym etapie pomóc w ramach po prostu przeprowadzania takiego audytu, jeżeli problem po prostu wymagał świeżego spojrzenia i tego, żeby ktoś doradził jak do niego podejść.

Dobrze. Dzięki Wam bardzo za dzisiaj. W przyszłym odcinku w ogóle będziemy mówić o kwestiach interesujących szczególnie branży e-commerce i tutaj uwaga w szczególności osoby, które swoją przygodę z e-commerce dopiero będą rozpoczynać albo są świeżo po rozpoczęciu tej przygody.

I tutaj porozmawiamy sobie o tym jak wybrać system dla e-commerce. Także nie przegap tego odcinka i zasubskrybuj kanał. Dzięki raz jeszcze za dziś i do usłyszenia za tydzień.

Cześć.