Przejdź do treści

Project Rescue · Przejęcie produktu po innym zespole

Przejmujemy produkt bez przestoju dla Waszych użytkowników

Przejmujemy produkt, który zostawił inny zespół. Zaczynamy od audytu kodu z listą ryzyk i planem naprawy, a pierwsze poprawki trafiają na produkcję zaraz po przejęciu.

Dla kogo

Gdy poprzedni zespół odszedł, a produkt musi działać dalej.

  • Poprzedni software house kończy współpracę albo przestał odpowiadać.
  • Nikt w firmie nie wie dokładnie, jak działa kod.
  • Aplikacja działa wolno, a każde wdrożenie coś psuje.
  • Platforma albo frameworki ograniczają rozwój produktu.

Co dostajecie

Zakres prac

  • 01

    Audyt kodu

    Lista ryzyk i plan naprawy, zanim cokolwiek zmienimy.

  • 02

    Pierwsze poprawki

    Najpilniejsze problemy naprawione na produkcji zaraz po przejęciu.

  • 03

    Przebudowa, gdy ma sens

    Przejście na nowe frameworki albo własny system wtedy, gdy plan naprawy to uzasadnia.

Jak to wygląda

Od rozmowy do produkcji

Każdy etap przechodzi przez te same trzy bramki: AI robi pierwsze podejście, senior dba o jakość, osobny zespół QA testuje wszystko od podstaw.

  1. Przejęcie

    Repozytoria, serwery i dokumentacja przechodzą do nas tak, żeby użytkownicy tego nie odczuli.

  2. Audyt

    Analiza kodu, lista ryzyk i plan naprawy.

  3. Pierwsze poprawki

    Najpilniejsze problemy na produkcji, w krótkich sprintach - przy Mięsnej Paczce tygodniowych.

  4. Utrzymanie i rozwój

    Dalej utrzymujemy i rozwijamy produkt albo przebudowujemy go według planu.

Model współpracy

Jak się umawiamy

Zakres, termin i budżet ustalamy przed startem prac - zanim ktokolwiek napisze pierwszą linijkę.

  • Najpierw audyt

    Audyt to osobny etap: po nim wiecie, co jest w kodzie, co zagraża produktowi i co naprawiamy najpierw.

  • Zakres i budżet przed startem

    Zakres, termin i budżet każdego etapu ustalamy przed startem prac. Po rozmowie dostajecie plan działania i widełki cenowe.

Pytania

Częste pytania

Jeśli nie ma tu Waszego pytania, zadajcie je na pierwszej rozmowie.

Czy przejmiecie projekt po innym software housie?

Tak. Zaczynamy od audytu kodu z listą ryzyk i planem naprawy. Przykład: FOAP - projekt przejęty w trakcie, dziś prowadzimy jego stały rozwój. Mięsna Paczka - przebudowa na najnowszych frameworkach, nowy sklep w miejsce dotychczasowego rozwiązania.

Czy będzie przestój?

Przejęcie planujemy tak, żeby użytkownicy go nie odczuli. Przy dużych zmianach nowa wersja może działać obok starej i przejmować ruch stopniowo - tak wdrażaliśmy nowy system Depilacja.pl.

Ile trwa audyt?

Zwykle 1-2 tygodnie od przejęcia dostępów. Pierwsze poprawki nie czekają na koniec audytu - najpilniejsze trafiają na produkcję zaraz po przejęciu.

Co, jeśli nie mamy dokumentacji?

Wtedy audyt zaczyna się od samego kodu. Jego wynikiem jest lista ryzyk i plan naprawy, czyli opis tego, co jest w systemie i co poprawiamy najpierw.

Czy przepisujecie wszystko od nowa?

Nie z założenia. Przebudowa na nowe frameworki wchodzi wtedy, gdy plan naprawy to uzasadnia - najpierw naprawiamy to, co przeszkadza użytkownikom.

Kontakt

Opowiedzcie nam o projekcie

Wystarczy kilka zdań. Odpiszemy z planem i widełkami, zwykle w dwa dni robocze. NDA podpisujemy na życzenie, jeszcze przed opisem projektu.

  • Wszystkie wiadomości trafią do naszego COO
  • Zakres, termin i budżet ustalamy przed startem prac
  • NDA podpisujemy na życzenie, jeszcze przed opisem projektu
  • Współpracujemy po polsku i po angielsku

Krzysztof Andruszkiewicz, COOTo on przeczyta Wasze zgłoszenie i odezwie się z planem.+48 501 208 292

Napisz do nas

Administratorem Twoich danych jest Mad Mountain sp. z o.o. Dane podane w formularzu wykorzystamy w celu obsługi Twojego zapytania i prowadzenia korespondencji. Szczegółowe informacje o przetwarzaniu danych i przysługujących Ci prawach znajdziesz w Polityce prywatności.

pola wymagane

Wolicie mailem? [email protected]

Porozmawiajmy