Zmiana wykonawcy projektu IT może wydawać się ryzykowna. Nowy zespół nie zna kodu, architektury, historii decyzji ani wszystkich wyjątków biznesowych, które przez lata zostały zaszyte w systemie. Jednocześnie działająca aplikacja, platforma B2B, sklep internetowy czy inny system nie może po prostu przestać funkcjonować na czas zmiany dostawcy.
Dlatego przejęcie projektu IT po innym wykonawcy nie powinno polegać wyłącznie na przekazaniu repozytorium z kodem źródłowym.
Trzeba przejąć również wiedzę, dostępy, środowiska, integracje, dane, sposób wdrażania zmian oraz odpowiedzialność za dalsze funkcjonowanie systemu. W praktyce przekazanie projektu obejmuje więc nie tylko sam system, ale również informacje i procesy potrzebne nowemu zespołowi do jego utrzymania i rozwoju.
Dobrze przeprowadzona zmiana software house pozwala ograniczyć ryzyko, zachować ciągłość działania i stopniowo odzyskać pełną kontrolę nad projektem.
Źle przeprowadzona może sprawić, że nowy wykonawca przez pierwsze tygodnie będzie próbował ustalić rzeczy, które poprzedni zespół wiedział od lat.
W tym artykule wyjaśniamy:
Przejęcie projektu IT to proces przekazania odpowiedzialności za rozwój, utrzymanie lub dalszą realizację istniejącego rozwiązania technologicznego z jednego zespołu do drugiego.
Może dotyczyć:
Nie zawsze przejmowany jest projekt niedokończony.
Nowy software house może przejąć również system działający od wielu lat, który wymaga dalszego utrzymania, rozwoju nowych funkcjonalności, modernizacji albo dostosowania do zmieniających się procesów biznesowych. Dlatego przejęcie projektu nie musi oznaczać ratowania nieudanego wdrożenia.
Czasami jest po prostu kolejnym etapem życia systemu informatycznego.
Decyzja o zmianie firmy programistycznej może wynikać z bardzo różnych powodów. Dotychczasowy wykonawca może zakończyć działalność, zmienić profil firmy albo nie posiadać już zasobów potrzebnych do dalszego rozwoju projektu.
System może również wejść na etap wymagający innych kompetencji. Firma, która dobrze przygotowała MVP, niekoniecznie musi być najlepszym partnerem do skalowania aplikacji, integracji z ERP, przebudowy architektury lub zapewnienia regularnego utrzymania i wsparcia technicznego tj. maintenance.
Podobnie niewielki zespół może dobrze obsługiwać projekt przez kilka lat, ale wraz ze wzrostem jego znaczenia biznesowego organizacja może potrzebować:
Zmiana wykonawcy może być więc konsekwencją rozwoju projektu, a nie konfliktu. Oczywiście zdarzają się także sytuacje, w których powodem są opóźnienia, problemy jakościowe, brak komunikacji, rosnące koszty albo brak możliwości dalszego rozwoju systemu.
Bez względu na przyczynę techniczny proces przejęcia powinien wyglądać podobnie: najpierw zabezpieczyć system i wiedzę, później zmieniać.
Nie każda trudność we współpracy uzasadnia zmianę dostawcy.
Jeżeli problem można rozwiązać poprzez poprawę komunikacji, zmianę procesu albo uporządkowanie listy zadań i priorytetów projektu, często jest to prostsze niż przenoszenie całego projektu.
Są jednak sygnały, których nie warto ignorować.
Estymacje przestają mieć związek z rzeczywistym czasem realizacji, a niemal każda zmiana ujawnia nowe problemy.
Może być to sygnał problemu organizacyjnego, ale również konsekwencja rosnącego długu technologicznego.
Projekt potrzebuje integracji, skalowania, przebudowy architektury albo infrastruktury, których dotychczasowy wykonawca nie realizuje.
Jeżeli praktycznie cała wiedza o systemie znajduje się w głowie jednego developera, projekt posiada poważne ryzyko operacyjne.
Problemem może być sytuacja, w której klient nie ma dostępu do:
Niezależnie od tego, kto aktualnie rozwija projekt, jego właściciel powinien wiedzieć, gdzie znajdują się kluczowe elementy systemu i kto posiada do nich dostęp.
Brak dokumentacji nie zawsze uniemożliwia dalszy rozwój, ale zwiększa koszt wejścia kolejnego zespołu.
Projekt staje się krytyczny biznesowo i wymaga stałej opieki, szybszych czasów reakcji, monitoringu albo SLA.
Nowe funkcjonalności są coraz trudniejsze do wdrożenia, aktualizacje odkładane, a rozwój wymaga tworzenia kolejnych obejść.
Niekiedy sytuacja jest prostsza: umowa wygasa, wykonawca kończy działalność albo strony podejmują decyzję o zakończeniu współpracy.
Wtedy trzeba przede wszystkim zadbać o prawidłowe przekazanie projektu nowemu wykonawcy.
Repozytorium jest niezwykle ważne. Nie jest jednak całym systemem.
Wyobraźmy sobie sytuację, w której nowy software house otrzymuje kod aplikacji.
Nie wie jednak:
Kod może być kompletny, a mimo to uruchomienie i bezpieczne rozwijanie projektu może być bardzo trudne. Dlatego przy przejęciu warto myśleć nie o przekazaniu kodu, ale o przekazaniu zdolności do utrzymywania i rozwijania systemu.
Na potrzeby praktycznej organizacji przejęcia projektu można podzielić go na sześć obszarów.
Nie jest to formalny standard. To sposób, który pozwala sprawdzić, czy wraz ze zmianą wykonawcy nie tracimy któregoś z elementów potrzebnych do dalszej pracy.
Podstawą jest ustalenie:
W większych projektach jedno repozytorium może być tylko częścią systemu.
Osobno mogą istnieć:
Nowy zespół powinien otrzymać możliwość odtworzenia wersji systemu działającej obecnie na produkcji.
Drugą warstwą jest infrastruktura. Trzeba ustalić:
W idealnym scenariuszu nowy zespół powinien być w stanie odtworzyć środowisko bez zgadywania, które parametry konfiguracyjne są potrzebne.
Projekt może korzystać z wielu kont:
Przy przekazywaniu projektu warto przygotować rejestr dostępów, zamiast przesyłać pojedyncze hasła w wiadomościach. Po zakończeniu przejęcia należy również zweryfikować, czy poprzedni zespół nadal powinien posiadać dostęp do poszczególnych usług.
W przypadku kont, kluczy, tokenów i innych danych uwierzytelniających warto stosować zasadę minimalnych niezbędnych uprawnień. Dostęp powinny posiadać wyłącznie osoby i usługi, które rzeczywiście go potrzebują, a po zakończeniu współpracy niepotrzebne konta, uprawnienia i dane dostępowe powinny zostać odpowiednio wycofane lub zmienione.
W zależności od sytuacji po zakończeniu przejęcia projektu zasadne może być również:
Nie chodzi o automatyczną zmianę każdego hasła w systemie.
Chodzi o to, żeby po zmianie wykonawcy dokładnie wiedzieć, kto nadal ma do czego dostęp.
Następna warstwa to dane. Trzeba wiedzieć:
Szczególną uwagę warto poświęcić integracjom z systemami ERP, CRM, WMS, płatnościami, przewoźnikami i zewnętrznymi API. Integracja może działać przez lata niemal bezobsługowo, dlatego wiedza o jej szczegółach często nie znajduje się w bieżącej dokumentacji ani na liście aktualnych zadań. Nowy software house musi tę wiedzę odzyskać.
System nie składa się wyłącznie z kodu. Zawiera także reguły biznesowe.
Dlaczego klient typu A może korzystać z innej ceny niż klient B?
Dlaczego konkretnego zamówienia nie można anulować po określonym etapie?
Dlaczego synchronizacja stanów jednego produktu działa inaczej niż pozostałych?
Dlaczego użytkownik posiada pięć ról, skoro w dokumentacji widnieją tylko trzy?
Takie wyjątki często powstają stopniowo i mogą być logiczne z biznesowego punktu widzenia, nawet jeśli dla nowego developera początkowo wyglądają jak błąd.
Dlatego przy przejęciu projektu warto zebrać:
Jeżeli dokumentacja nie istnieje, nie oznacza to, że projekt jest niemożliwy do przejęcia.
Nowy zespół będzie jednak musiał część wiedzy odtworzyć.
Ostatnim obszarem jest sposób pracy.
Warto ustalić:
Dwa identyczne repozytoria mogą być utrzymywane zupełnie inaczej w zależności od jakości procesów wokół nich. Dlatego przejęcie procesu jest równie ważne jak przejęcie technologii.
Zakres będzie zależał od projektu i zawartej umowy, ale przed zakończeniem współpracy warto sprawdzić przede wszystkim:
Nie każda pozycja będzie dotyczyć każdego projektu. Najważniejsze jest sprawdzenie, czy nowy zespół otrzymuje wystarczająco dużo informacji, żeby nie odkrywać systemu wyłącznie metodą prób i błędów.
Przejęcie warto rozpocząć przed wyłączeniem poprzedniego zespołu z projektu. Możemy przeanalizować kod, dostępne materiały i środowisko oraz wskazać, czego brakuje do bezpiecznego rozpoczęcia dalszych prac.
Najbezpieczniejszy scenariusz zakłada okres, w którym dotychczasowy i nowy wykonawca są jednocześnie dostępni. Nie muszą wspólnie rozwijać projektu. Wystarczy możliwość przekazania informacji. Warto zaplanować kilka obszarów rozmowy.
Obecny zespół przedstawia najważniejsze moduły, zależności i przepływ danych.
Wyjaśnia, gdzie działa system i jak wykonywane są wdrożenia.
Przekazuje informacje o zewnętrznych API, ograniczeniach i znanych problemach.
Opisuje mniej oczywiste wyjątki, których nie można wywnioskować wyłącznie z nazwy funkcji.
Nowy wykonawca powinien wiedzieć, które obszary są problematyczne już dzisiaj.
Trzeba ustalić, co jest zakończone, co rozpoczęte, a co dopiero planowane.
Dobrze przeprowadzone przekazanie wiedzy może zaoszczędzić wiele godzin samodzielnego odtwarzania tych samych informacji przez nowy zespół.
Najlepiej, jeśli tak. Nie zawsze jest to jednak możliwe.
Można wyróżnić trzy podstawowe scenariusze przejęcia.
To najlepsza sytuacja.
Poprzedni wykonawca:
Nowy zespół może rozpocząć analizę jeszcze przed całkowitym zakończeniem współpracy z poprzednim wykonawcą. Ryzyko jest wtedy najmniejsze.
Klient posiada kod i dostępy, ale:
Projekt nadal można przejąć. Pierwszy etap będzie wtedy bardziej przypominał techniczną analizę i odtwarzanie wiedzy o systemie niż standardowe rozpoczęcie pracy nad projektem.
Nowy zespół musi samodzielnie:
Najtrudniejszy przypadek występuje wtedy, gdy poprzedni wykonawca:
Wtedy pierwszym celem nie jest rozwój.
Pierwszym celem jest odzyskanie kontroli nad systemem.
Trzeba ustalić:
Dopiero później należy rozpoczynać dalsze prace programistyczne i rozwój systemu.
To jeden z najczęstszych lęków przy zmianie wykonawcy. Brak dokumentacji komplikuje przejęcie projektu, ale go nie uniemożliwia.
Kod źródłowy, konfiguracja, infrastruktura, baza danych, logi i działająca aplikacja same w sobie są źródłami informacji o systemie.
Nowy zespół może stopniowo odtworzyć:
Problem polega na tym, że odtwarzanie wiedzy kosztuje czas. Dlatego niepełna dokumentacja powinna wpływać na sposób planowania pierwszego etapu przejęcia.
Zamiast oczekiwać natychmiastowego rozpoczęcia prac nad nowymi funkcjami, rozsądniej najpierw zmniejszyć poziom niewiedzy.
Najpierw warto przygotować listę braków. Nie wszystkie dostępy mają ten sam priorytet.
Krytyczne są przede wszystkim te elementy, których brak może uniemożliwić:
Dostęp do starego narzędzia projektowego może poczekać. Dostęp do serwera produkcyjnego albo DNS – zwykle nie.
Priorytet powinien wynikać z wpływu danego zasobu na ciągłość działania systemu.
Tak, pod warunkiem że firma posiada odpowiednie zasoby i dostępy pozwalające na dalszą pracę. Trzeba jednak liczyć się z większym zakresem analizy.
Nowy software house będzie musiał samodzielnie zidentyfikować rzeczy, które przy standardowym przekazaniu projektu można byłoby wyjaśnić podczas jednej rozmowy.
Dlatego przed całkowitym zakończeniem współpracy warto – jeśli to możliwe – wykorzystać dostępność poprzedniego zespołu do przekazania wiedzy.
To kwestia, którą warto zweryfikować przed zmianą wykonawcy, a najlepiej już podczas rozpoczynania każdego projektu IT.
Należy sprawdzić umowę zawartą z dotychczasowym dostawcą, zasady dotyczące praw do oprogramowania, wykorzystanych komponentów, licencji oraz możliwości przekazania projektu kolejnemu wykonawcy.
Sama techniczna możliwość pobrania repozytorium nie odpowiada jeszcze na pytanie o zakres praw do jego wykorzystania.
Jeżeli zapisy umowy są niejasne, właściwym krokiem jest ich weryfikacja prawna przed rozpoczęciem dalszych prac.
Nie zawsze. W niektórych projektach można kontynuować bieżące prace programistyczne do końca współpracy z poprzednim wykonawcą i płynnie przekazać odpowiedzialność.
W innych warto wprowadzić krótki okres stabilizacji, podczas którego nie powstają duże nowe funkcjonalności.
Ma to szczególne znaczenie wtedy, gdy:
Najważniejsze jest ustalenie jednego punktu przejęcia odpowiedzialności. Nowy i stary wykonawca powinni wiedzieć, od którego momentu to nowy zespół odpowiada za produkcję i wdrażane zmiany.
Błędem byłoby rozpoczęcie prac od realizacji kolejnych zaplanowanych funkcjonalności.
Najpierw trzeba zrozumieć środowisko.
Zbieramy:
Powstaje lista tego, co mamy i czego brakuje.
Nowy zespół powinien być w stanie samodzielnie uruchomić rozwiązanie.
Jeżeli nie może tego zrobić, warto najpierw ustalić dlaczego.
Sprawdzane są między innymi:
To etap zbliżony do audytu technicznego, ale jego celem nie musi być stworzenie pełnego raportu o każdym możliwym problemie.
W procesie przejęcia najważniejsza jest odpowiedź na pytanie: czy możemy bezpiecznie przejąć odpowiedzialność za system i rozpocząć jego dalszy rozwój?
Problemy warto rozdzielić według wpływu.
Przykładowo:
Nowy software house nie powinien zaczynać od poprawiania wszystkiego. Powinien zacząć od tego, co naprawdę stanowi ryzyko.
Jeżeli system posiada problemy krytyczne, przed rozwojem nowych funkcji warto je ograniczyć.
Może to oznaczać:
Dopiero po poznaniu projektu można rozsądnie określić:
Po ustabilizowaniu sytuacji projekt może wejść w normalny model pracy.
W zależności od potrzeb może to być:
W przypadku rozbudowanego lub słabo udokumentowanego projektu audyt techniczny może znacząco ograniczyć ryzyko przejęcia. Pozwala ocenić między innymi architekturę, kod, technologie, integracje, testy, infrastrukturę i najważniejsze zależności systemu.
Nie każde przejęcie wymaga jednak pełnego audytu. Czasami wystarczający jest ograniczony etap analityczny, którego celem jest sprawdzenie, czy nowy zespół może bezpiecznie przejąć odpowiedzialność za produkcję i rozpocząć dalszą pracę.
Szerzej zakres takiej analizy opisujemy w artykule Audyt techniczny systemu informatycznego – co sprawdzić przed dalszym rozwojem lub przejęciem aplikacji?
Nie. Sam fakt, że nowy developer napisałby określony fragment inaczej, nie jest wystarczającym powodem do jego przebudowy.
Refaktoryzacja ma sens, gdy istniejący kod:
W przeciwnym razie zmiana może nie dostarczać żadnej wartości biznesowej. Przejęcie projektu nie powinno być pretekstem do „przepisania go po swojemu”. Więcej o tym, kiedy takie zmiany mają rzeczywiste uzasadnienie, opisujemy w artykule Refaktoryzacja kodu – czym jest i kiedy ją stosować?
To jedna z decyzji, których nie powinno się podejmować przed poznaniem projektu. Napisanie systemu od nowa może być właściwym rozwiązaniem.
Ale może też być najdroższą możliwą odpowiedzią na problem, który dałoby się rozwiązać poprzez:
Starsza aplikacja może zawierać wiele lat wiedzy biznesowej zapisanej w kodzie. Przepisując system od nowa, trzeba tę wiedzę odtworzyć. Dlatego przed rekomendacją nowego rozwiązania warto najpierw określić rzeczywisty poziom długu technologicznego w systemie oraz wpływ obecnej architektury na dalszy rozwój.
Nie istnieje uniwersalny czas. Prosty WordPress z kilkoma dedykowanymi funkcjami może wymagać zupełnie innego podejścia niż kilkuletnia platforma B2B z dziesiątkami integracji i własną infrastrukturą.
Na zakres wpływają przede wszystkim:
Dlatego ostrożnie podchodziłbym do wykonawcy, który jeszcze przed zobaczeniem projektu potrafi dokładnie określić czas jego przejęcia. Najpierw trzeba zobaczyć, co rzeczywiście jest do przejęcia.
Podobnie jak czas, koszt zależy przede wszystkim od poziomu niewiedzy i złożoności rozwiązania.
Największy koszt początkowy mogą generować:
Dlatego pierwszego etapu nie zawsze da się odpowiedzialnie wycenić jak standardową funkcjonalność: „przejęcie projektu – 20 godzin”.
Im mniej wiadomo o systemie, tym większa niepewność estymacji. W takich sytuacjach rozsądny może być ograniczony etap analityczny rozliczany za rzeczywistą pracę, po którym dopiero powstaje dokładniejsza roadmapa.
Przejęcie istniejącego systemu wymaga innego podejścia niż budowa nowej aplikacji od początku. Dlatego przy wyborze wykonawcy warto sprawdzić przede wszystkim, czy zespół:
Szczególnie istotna jest transparentność pierwszego etapu. Klient powinien wiedzieć, co zostało sprawdzone, jakie ryzyka wykryto, czego jeszcze brakuje i jaki powinien być kolejny krok.
Szersze kryteria wyboru zespołu opisujemy w poradniku Jak wybrać firmę programistyczną do rozwoju strony, sklepu lub systemu?
W przypadku systemów dedykowanych szczególne znaczenie ma poznanie logiki biznesowej. Taki system powstał zwykle właśnie dlatego, że standardowe narzędzia nie realizowały wszystkich procesów firmy.
Kod może więc odzwierciedlać:
Nowy software house nie może analizować takiego rozwiązania wyłącznie od strony technologicznej. Musi również zrozumieć, dlaczego system działa właśnie w taki sposób.
Systemy B2B bardzo często posiadają rozbudowane zależności z wewnętrzną infrastrukturą przedsiębiorstwa.
Mogą obsługiwać:
Przy przejęciu takiego systemu szczególnie ważne jest odwzorowanie przepływu danych pomiędzy platformą a pozostałymi rozwiązaniami firmy.
Problem w systemie B2B może bowiem nie wynikać z samej aplikacji, ale z procesu rozpoczynającego się albo kończącego w ERP, CRM czy magazynie.
WordPress bywa prostszy do przejęcia niż dedykowana aplikacja, ale nie zawsze.
Rozbudowana instalacja może posiadać:
Przy przejęciu WordPressa warto sprawdzić:
WooCommerce wymaga jeszcze ostrożniejszego podejścia, ponieważ sklep funkcjonuje cały czas i generuje zamówienia.
Nowy zespół musi zrozumieć nie tylko WordPressa, ale cały proces sprzedażowy:
Zmiana wykonawcy nie może spowodować zatrzymania sprzedaży. Dlatego przed większymi zmianami warto najpierw zapewnić bezpieczne środowisko testowe oraz możliwość odtworzenia najważniejszych procesów sklepu. Przy dalszym rozwoju warto również sprawdzić, czy obecna architektura odpowiada planowanym funkcjom, integracjom i skali sprzedaży – szczególnie w przypadku bardziej rozbudowanych sklepów WooCommerce.
Integracja z ERP jest często jednym z najbardziej krytycznych elementów przejmowanego systemu.
Trzeba ustalić:
Bez tej wiedzy nawet drobna zmiana może wpłynąć na procesy magazynowe, księgowe albo sprzedażowe.
Najważniejsza zasada jest prosta: nie zmieniaj wszystkiego jednocześnie.
Jeżeli tylko sytuacja na to pozwala:
Pozwala to oddzielić dwa problemy: „czy potrafimy bezpiecznie utrzymać obecny system?”
od: „jak chcemy go dalej rozwijać?”
To dwie różne decyzje.
Jeżeli potrzebujesz przejąć aplikację, platformę B2B, WordPress, WooCommerce lub dedykowany system po innym wykonawcy, możemy rozpocząć od analizy dostępnych materiałów i aktualnego stanu projektu. Sprawdźmy, co jest potrzebne do bezpiecznego przejęcia i dalszego rozwoju systemu.
Jako zespół developerski możemy rozwijać zarówno projekty tworzone przez nas od początku, jak i rozwiązania przygotowane przez innych wykonawców.
Przy przejmowanym projekcie nie zakładamy z góry, że system wymaga napisania od nowa. Najpierw trzeba poznać jego stan.
W zależności od projektu analizujemy między innymi:
Następnie można ustalić, czy właściwym kierunkiem jest:
Przejęcie projektu powinno prowadzić do sytuacji, w której dalszy rozwój staje się bardziej przewidywalny, a nie do wymiany jednego zestawu niewiadomych na drugi. Jeżeli projekt wymaga przejęcia, modernizacji i dalszego developmentu istniejącego rozwiązania, zobacz również Firma programistyczna.
Zmiana software house nie musi oznaczać zatrzymania projektu ani budowania systemu od początku. Największym ryzykiem nie jest samo pojawienie się nowego zespołu. Ryzykiem jest sytuacja, w której firma nie posiada wiedzy o własnym systemie, nie kontroluje dostępów i nie potrafi określić jego rzeczywistego stanu technicznego.
Dlatego dobre przejęcie projektu powinno kolejno:
zabezpieczyć → zinwentaryzować → zrozumieć → ocenić → ustabilizować → rozwijać.
Jeżeli poprzedni wykonawca współpracuje, warto wykorzystać ten czas do przekazania wiedzy. Jeżeli nie współpracuje, nadal można przejąć projekt, ale trzeba uwzględnić dodatkowy czas potrzebny na odtworzenie informacji.
Nie należy również automatycznie przepisywać starego systemu. Najpierw trzeba wiedzieć, co rzeczywiście warto zmienić. Dobrze przeprowadzone przekazanie projektu kończy się nie wtedy, gdy nowy software house otrzyma dostęp do repozytorium. Kończy się wtedy, gdy nowy zespół rozumie system na tyle dobrze, aby bezpiecznie wziąć odpowiedzialność za jego dalsze funkcjonowanie i rozwój.
Przejęcie projektu IT polega na przekazaniu odpowiedzialności za istniejący system lub aplikację nowemu zespołowi. Proces obejmuje zazwyczaj kod źródłowy, dostęp do infrastruktury, dokumentację, integracje, dane, wiedzę biznesową oraz sposób wdrażania i utrzymywania systemu.
Tak. Zmiana software house może odbyć się zarówno po zakończeniu konkretnego etapu, jak i podczas dalszego rozwoju projektu. Ważne jest wyznaczenie momentu przekazania odpowiedzialności i zabezpieczenie kodu, danych, dostępów oraz aktualnego stanu prac.
Nie zawsze jest to konieczne, ale współpraca znacznie ułatwia proces. Możliwość rozmowy z poprzednim zespołem pozwala szybciej przekazać wiedzę o architekturze, integracjach, procesach biznesowych i znanych problemach.
Tak. Dokumentację można częściowo odtworzyć na podstawie kodu, infrastruktury, bazy danych, konfiguracji i działania aplikacji. Brak dokumentacji zwiększa jednak czas potrzebny nowemu zespołowi na zrozumienie systemu.
Nie. Potrzebne mogą być również dostępy do serwerów, bazy danych, DNS, usług chmurowych, integracji, API, CI/CD, monitoringu, backupów oraz informacje o sposobie działania procesów biznesowych.
Nie. Rewrite powinien wynikać z analizy, a nie samego faktu zmiany wykonawcy. W wielu przypadkach istniejący system można dalej rozwijać po uporządkowaniu kodu, infrastruktury lub najbardziej problematycznych modułów.
Przy większym, złożonym lub słabo udokumentowanym projekcie audyt może znacząco ograniczyć ryzyko przejęcia. Nie każde przejęcie wymaga jednak pełnego audytu – zakres analizy powinien odpowiadać złożoności systemu i poziomowi niewiedzy przed rozpoczęciem pracy.
Zależy to od wielkości i złożoności systemu, jakości dokumentacji, liczby integracji, dostępności poprzedniego zespołu oraz stanu kodu i infrastruktury. Dlatego dokładny czas najlepiej określać po pierwszej analizie projektu.
Koszt zależy przede wszystkim od zakresu analizy potrzebnej do poznania systemu i ewentualnych prac stabilizacyjnych. Im mniej dokumentacji i więcej nieznanych zależności, tym większy może być początkowy zakres pracy.
Najważniejsze jest zachowanie kontroli nad systemem i ciągłości jego działania. Kod, infrastruktura, dane, dostępy, integracje i wiedza powinny zostać zabezpieczone przed rozpoczęciem większych zmian.
Ten wpis stworzył
Ekspert od wycen dedykowanych rozwiązań i zarządzania projektami. Posiada ogromne doświadczenie w tworzeniu ofert idealnie dopasowanych do potrzeb i oczekiwań klientów, specjalista łączący pasję do nowych wyzwań z analitycznym podejściem do każdego szczegółu projektu.
Czym jest dług technologiczny i jak wpływa na rozwój systemów informatycznych? Sprawdź, kiedy wystarczy refaktoryzacja, a kiedy potrzebna jest modernizacja systemu.
Jak wybrać firmę programistyczną do rozwoju strony, sklepu lub systemu? Sprawdź doświadczenie, proces, estymację, rozliczenie i przejęcie projektu.
Time & Material czy Fixed Price? Porównaj sposób rozliczenia, ryzyko, kontrolę budżetu i zmiany zakresu. Sprawdź, który model pasuje do projektu IT.
Czym jest dług technologiczny i jak wpływa na rozwój systemów informatycznych? Sprawdź, kiedy wystarczy refaktoryzacja, a kiedy potrzebna jest modernizacja systemu.
Share:
