Przejmowanie projektów IT przez nowy zespół to proces wymagający przemyślanego planu i precyzyjnego działania. Nie zawsze jest tak, że to brak dobrej jakości jest motorem napędowym zmiany. Często okazuje się, że porostu zespół niekoniecznie idzie z duchem czasu czy też niekoniecznie jest dobrym partnerem biznesowym, z tego względu, że nie nadąża za pędzącym biznesem, który chciałby ciągle realizować coraz więcej projektów i coraz więcej zmian.
Dziś skupiamy się na konkretach. Jeśli uważasz, że Twój zespół realizuje prace zbyt wolno, wdrożenie przypomina niekończącą się historię albo Twój projekt nie jest odpowiednio zaopiekowany i rozważasz zmianę zespołu lub jego rozbudowę, przeczytaj 7 porad, jak skutecznie zmienić lub rozbudować zespół IT, aby sprawniej realizować cele biznesowe. Ostatni punkt Cię zaskoczy!
Zacznijmy od tego co już najprawdopodobniej na tym etapie wiesz, być może nie zebrałeś tego jeszcze w piękne podpunkty ale na pewno podejmując decyzję o zmianie dostawcy jesteś świadomy dlaczego to robisz?
Być może czas realizowanych zadań mocno odbiega od pierwotnych deklaracji? Może masz wrażenie, że zespół nie komunikuje się w sposób transparentny a jak dopytujesz o szczegóły dostajesz zdawkowy techniczny bełkot?
A może sytuacja wygląda tak: projekt jest podzielony na części, z których kluczowa – nazwijmy to „rdzeń” – została ukończona. Całość działa na wersji produkcyjnej, produkt jest funkcjonalny, np. klienci mogą realizować zakupy w Twoim sklepie e-commerce albo Twój wewnętrzny zespół korzysta już z systemu. Ale jednocześnie trwają prace nad kolejnymi funkcjonalnościami. I co się dzieje? Każde wdrożenie nowej funkcji generuje błędy w tym, co już powinno działać tzw. regresje. Wracasz do poprawiania rzeczy, które dawno powinny być zamknięte. W efekcie 70% czasu poświęcasz na gaszenie pożarów, a tylko 30% na realny rozwój projektu.
I umówmy się - pożary w projektach są nieuniknione w 100%, Jednak odpowiednie zarządzanie nimi oraz właściwe gospodarowanie czasem na ich gaszenie jest niezwykle istotne.
Czyli na tym etapie na pewno wiesz co Cię w obecnym projekcie czy współpracy wkurza albo co jest głównym motorem napędowym rozbudowy zespołu. Nazwanie rzeczy po imieniu, deklarowanie od początku i otwarta komunikacja pozwoli Twojemu nowemu partnerowi na zwrócenie szczególnej uwagi na te aspekty aby w obecnej współpracy się nie powtórzyły.
Przychodzi moment, gdy nowe osoby pojawiają się w projekcie – czy to z zewnętrznej firmy, czy wewnętrznie. To, skąd pochodzą, nie ma większego znaczenia, ponieważ proces przejęcia projektu wygląda podobnie. Kluczowym punktem jest moment przekazania projektu.
W idealnym świecie na ten moment powinna istnieć obszerna dokumentacja, w której opisane są między innymi: cel biznesowy projektu i wymagania funkcjonalne, obecny cel biznesowy (czy ewoluował lub zmienił się), architektura systemu, użyte technologie, stan prac, sposób zlecania zadań, metodyka pracy, szczegóły integracji (np. API), podział na frontend i backend, a także dane kontaktowe do kluczowych osób w zespole. To bardzo obszerna lista.
Często jednak okazuje się, że dokumentacja w projekcie jest niepełna lub w ogóle jej brakuje. Zdarza się, że zamiast tego istnieją komentarze w kodzie – ale komentarze w kodzie to nie jest dokumentacja! Dlatego, aby podejść realnie i rzeczowo do tego etapu, dobrze jest zadbać o dokumentację w takim zakresie, w jakim jest to możliwe.
Taka dokumentacja nie musi być bardzo długa, bo jeśli będzie zbyt obszerna, nikt nie przeczyta jej dokładnie. Powinna być wystarczająco szczegółowa, aby dać ogólny obraz projektu. Dzięki temu nowy zespół, zapoznając się z nią, będzie w stanie zrozumieć kluczowe elementy, takie jak użyta architektura, bez wchodzenia w nadmiarowy detal. Oczywiście pewne kwestie i tak ujawnią się w trakcie dalszych prac – tego nie da się uniknąć.
Ważne jest, aby przygotowywać tę dokumentację z głową, na odpowiednim poziomie szczegółowości. Podczas tego procesu na pewno pojawią się pytania i potrzeba uzupełnienia wiedzy. Dlatego istotne jest, aby w firmie była osoba otwarta na udzielanie odpowiedzi i wsparcie nowego zespołu.
Dokumentacja nie zastąpi wiedzy ludzi, którzy znają Twój biznes i potrafią wyjaśnić, dlaczego w przeszłości podjęto określone decyzje. To ta wiedza będzie miała największą wartość i to na niej warto się przede wszystkim skupić.
To absolutna podstawa. Bez dostępu do wszystkich kluczowych zasobów, zarówno technicznych, jak i organizacyjnych, nowy zespół będzie musiał borykać się z wieloma trudnościami, które opóźnią cały proces. A przecież zależy Ci na tym, żeby jak najszybciej ruszyć z nową ekipą i zrealizować projekt bez zbędnych przestojów, prawda?
W tym punkcie warto zadbać o kilka rzeczy:
Podsumowując, jak już na wstępie wspomnieliśmy – dostęp do powyższych narzędzi należy zabezpieczyć w każdym projekcie na samym jego początku. To kluczowy element, który nie tylko ułatwi późniejsze zarządzanie projektem.
Jeśli rozpoczynasz współpracę z nowym zespołem, warto zlecić przeprowadzenie audytu technicznego. To moment, w którym nowy zespół może zapoznać się z dokumentacją, kodem, serwerami i ich konfiguracją na żywo. Dzięki temu będzie mógł zadać pierwsze pytania, sprawdzić, czy dobrze rozumie projekt, oraz uzupełnić luki informacyjne.
Audyt może brzmieć jak coś długiego i skomplikowanego, a podejście do niego różni się w zależności od firmy. Ważne jest jednak, aby na początku ustalić jego zakres, podejść do niego projektowo (jak do każdego zadania z większą liczbą elementów) oraz określić kluczowe aspekty: termin, zakres i oczekiwany efekt końcowy.
Nawet jeśli istnieje dokumentacja projektu, audyt jest wskazany. Pozwala on sprawdzić, czy wszystkie funkcjonalności są zgodne z dokumentacją, wykryć ewentualne niezgodności lub błędy wymagające poprawy oraz zidentyfikować elementy, które trzeba dostosować. Audyt umożliwia również oszacowanie kosztów i czasu potrzebnego na przejęcie projektu lub rozszerzenie zespołu, co jest kluczowe dla skutecznego planowania dalszych działań.
Nikt nie zna lepiej projektu niż osoba, która go wykonywała – a przynajmniej w teorii tak powinno być. Dlatego warto zadbać o okres przejściowy. To czas, kiedy nowy zespół może korzystać z wiedzy obecnego zespołu. Niestety, w praktyce bywa różnie – czasami tego zespołu już nie ma, a w innych przypadkach pojawiają się pytania typu „co autor miał na myśli?”, gdy nowy zespół próbuje odnaleźć się w kodzie lub wdraża zmiany.
Najłatwiej zrozumieć projekt i wdrożyć się w niego w okresie przejściowym, realizując konkretne zadania. Jeśli jednak obecny zespół nie jest dostępny, pytania trafiają do biznesu. Dlatego kluczowe jest, aby firma przejmująca projekt znała metodykę przejmowania i potrafiła zadawać właściwe pytania, na przykład dlaczego coś zostało zrobione w określony sposób. Ważne jest, by unikać interpretacji fragmentów kodu w oderwaniu od kontekstu.
Kontakt z dotychczasowym zespołem z pewnością przyspieszy wdrożenie i pozwoli wyjaśnić pewne kwestie, ale ostatecznie odpowiedzialność za projekt przechodzi na nowy zespół. Warto jasno określić moment, od którego nowy zespół przejmuje pełną odpowiedzialność za projekt. Najlepiej podzielić proces na etapy:
Czy w pierwszej kolejności należy naprawić błędy? Skupić się na wdrażaniu nowych funkcji? A może poprawić wydajność i bezpieczeństwo? Odpowiedź zależy od priorytetów Twojej firmy.
Zazwyczaj w początkowej fazie przejęcia projektu trzeba zająć się „pożarami”. Następnie przechodzi się do fazy rozwojowej, aby maksymalnie skupić się na działaniach, które przynoszą wartość biznesową. Warto jednak pamiętać, że w projektach z dużym długiem technologicznym trzeba zaakceptować pewne ograniczenia.
Największym problemem nie jest to, że podczas wdrażania nowych rzeczy coś się zepsuje – problemem jest, gdy nikt tego nie wykryje i błędy trafią na produkcję. Dlatego należy zadbać o testy regresji i stworzyć proces, który zapewnia maksymalne bezpieczeństwo przy jednoczesnym uwzględnieniu potrzeb biznesowych.
Zdefiniowanie celów na przyszłość i ustalenie priorytetów pozwala ocenić, ile można przeznaczyć na poprawki (refaktoryzację, ulepszanie kodu), a ile na pilne zadania kluczowe dla funkcjonowania biznesu. Na tej podstawie można opracować roadmapę projektu. Pamiętaj, że w projektach IT nie trzeba realizować tylko jednego wątku na raz. Można równolegle prowadzić działania utrzymaniowe (refaktoryzację, ulepszenia, migrację do mikroserwisów) i rozwój systemu poprzez dodawanie nowych funkcji. Kluczem jest mądre zaplanowanie i odpowiednie zarządzanie procesem.
Jeżeli jesteś ogólnie zadowolony z działania obecnego zespołu i jakości ich pracy, ale zauważasz, że projekty trwają zbyt długo, brakuje określonych kompetencji, albo jeden konkretny obszar staje się tzw. wąskim gardłem (np. w rozpisywaniu zadań, zarządzaniu zespołem, deployach, testach czy odbieraniu zadań od biznesu), to wcale nie oznacza, że konieczna jest wymiana całego zespołu.
Możliwe rozwiązania:
Jeśli interesują Cię sposoby na efektywne połączenie pracy kilku zespołów lub wydzielanie mikroserwisów, koniecznie subskrybuj podcast It i Biznes. Regularnie poruszamy tam tematy związane z zarządzaniem projektami i nowoczesnymi rozwiązaniami technologicznymi.
Jeżeli potrzebujesz indywidualnej konsultacji, zapraszamy do kontaktu – chętnie pomożemy znaleźć rozwiązanie dostosowane do Twoich potrzeb. 😊
Omówiliśmy najlepsze praktyki związane z przejmowaniem projektu, które mogą znacznie przyspieszyć proces adaptacji nowego zespołu i ułatwić sprawne przejęcie odpowiedzialności. Kluczowe elementy, takie jak: dobrze zaplanowany okres przejściowy, analiza dokumentacji, porządki w kodzie, oraz jasne cele na teraz i przyszłość, mogą znacząco wpłynąć na sukces takiego procesu.
Choć przejmowanie projektu wydaje się trudnym zadaniem, budowa projektu od podstaw również nie należy do najłatwiejszych. Kluczową rolę w obu przypadkach odgrywa dobra komunikacja – zarówno wewnątrz zespołu IT, jak i między IT a biznesem.
Przejęcie projektu nie musi być rewolucją, ale raczej ewolucją, która umożliwi dostosowanie istniejącego rozwiązania do aktualnych potrzeb i celów firmy. Zmiana dostawcy, zespołu lub decyzja o jego rozszerzeniu często wiąże się z obawą o koszty już poniesione. Jednak, jak pokazuje praktyka, świeże spojrzenie na projekt może otworzyć nowe perspektywy, pozwalając na jego optymalizację i dalszy rozwój.
Czy warto? Zdecydowanie tak! Jeśli czujesz, że coś w projekcie nie działa tak, jak powinno, warto rozważyć audyt pracy obecnego partnera lub zespołu. Dzięki temu zyskasz pełniejszy obraz sytuacji i solidne podstawy do podejmowania kolejnych kroków.
Masz nowe pomysły, stare systemy do ogarnięcia, albo problem do rozwiązania? Napisz do nas, zaproponujemy, jak to zrobić uwzględniając czas, budżet i zasoby.
Jeśli jest przed 15:00 - zadzwonimy do Ciebie jeszcze dzisiaj.
Jeśli jest po 15:00 - skontaktujemy się jutro, no chyba że jutro jest weekend to słyszymy się w poniedziałek.
Adres
ul. Żmigrodzka 81-83 lok. 302, 51-130 Wrocław
