VulCode

Przejęcie projektu IT po innym wykonawcy

Przejmujemy projekty porzucone w połowie albo prowadzone przez zespół, z którym współpraca się skończyła. Zaczynamy od przeglądu kodu i wyceny tego, co zostało, a kończymy na działającym wdrożeniu z dokumentacją, której wcześniej brakowało.

Katalog usług
Raport z przeglądu przed przejęciem aplikacji zamówień w panelu klienta: wyniki przeglądu i decyzja dla każdego modułu

Kiedy przejmować projekt

Przejęcie projektu to dokończenie aplikacji albo strony, którą zaczął inny wykonawca, bez pisania wszystkiego od nowa, gdy nie ma takiej potrzeby. Dla firm, którym projekt utknął w połowie, a rezygnacja z niego kosztowałaby więcej niż dokończenie.

Dziś: projekt po poprzednim wykonawcy
Co zwykle widać
  • Wykonawca zniknął
    Kod jest, ale nie ma kto go dokończyć ani wdrożyć.
  • Termin przepadł
    Projekt miał być gotowy dawno temu i nadal nie działa.
  • Brak dokumentacji
    Nikt nie wie, jak uruchomić projekt na nowym serwerze.
  • Aplikacja bez opieki
    Działa, ale nikt jej nie aktualizuje i każda zmiana jest ryzykiem.
  • Zespół wewnętrzny bez czasu
    Własny zespół zajęty, a projekt poboczny czeka od miesięcy.
Harmonogram poprzedniego wykonawcy
dziś
  • Wersja testowa
    działa częściowo
  • Moduł płatności
    brak testów
  • Wdrożenie
    nie ma kto wdrożyć
  • Dokumentacja
    nikt nie wie, jak uruchomić projekt
Po przejęciu
Od czego zaczynamy
  • Wykonawca zniknął
    Odzyskanie dostępów i uruchomienie od zera.
  • Termin przepadł
    Lista tego, co działa, a co nie.
  • Brak dokumentacji
    Czysta instalacja i opis kroków.
  • Aplikacja bez opieki
    Przegląd zależności i kopie zapasowe.
  • Zespół wewnętrzny bez czasu
    Ustalenie, kto decyduje i kto odbiera etapy.
Plan przejęcia
dziś
  • Dostęp do kodu
    komplet dostępów po zmianie haseł
  • Przegląd
    raport: co zostawić, co przepisać
  • Wycena dokończenia
    plan z wyceną
  • Dokończenie
    etapy odebrane na wersji testowej
  • Wdrożenie i dokumentacja
    działający projekt z dokumentacją

  • Najpierw diagnoza

    Wycena dokończenia powstaje po przeglądzie kodu, nie w ciemno.

  • Najpierw sekrety

    Zmieniamy hasła, klucze i tokeny, które mógł znać poprzedni wykonawca, zanim zaczniemy cokolwiek zmieniać.

  • Wersja testowa

    Każdy etap możesz sprawdzić, zanim trafi na produkcję.

  • Dokumentacja na końcu

    Uruchomienie, architektura i wdrożenie opisane dla następnej osoby.

Gdy chcesz najpierw tylko diagnozy, zacznij od audytu kodu.

Co przejmujemy

Projekt to nie tylko kod: każda warstwa ma swoje dostępy i przechodzi te same trzy kroki, zanim uznamy ją za przejętą. Na rysunku przykład w połowie przejęcia.

Repozytorium
Repozytorium z historią, gałęzie i otwarte zmiany, ustalenia na piśmie.
Przejęte
Serwer i baza danych
Serwery i bazy danych, kopie zapasowe, sposób wdrażania.
W dokumentacji
Domena i poczta
Konto u rejestratora, DNS, skrzynki i nadawcy poczty.
Na Twojej firmie
Usługi zewnętrzne
Płatności, klucze API, analityka i konta w sklepach.
brak dostępu: odtwarzamy go razem z Tobą
brak dostępu: odtwarzamy go razem z Tobą
Gdy dostępu nie ma

Konto zapisane na Twoją firmę odzyskujesz u rejestratora albo dostawcy jako jego właściciel, a my podpowiadamy, o co poprosić. Klucz, który był tylko na prywatnym koncie poprzedniego wykonawcy, zakładamy od nowa na koncie Twojej firmy.

Co znaczy każdy krok

Repozytorium

  1. Nowe hasła i klucze: konto poprzedniego wykonawcy odłączone, klucze wdrożeniowe wymienione.
  2. Na Twojej firmie: repozytorium z całą historią na koncie Twojej firmy.
  3. W dokumentacji: uruchomienie i wdrożenie opisane w samym repozytorium.

Serwer i baza danych

  1. Nowe hasła i klucze: nowe hasła do serwera i bazy, stare klucze SSH usunięte.
  2. Na Twojej firmie: serwer na koncie Twojej firmy u dostawcy.
  3. W dokumentacji: kopie zapasowe i sposób wdrażania spisane.

Domena i poczta

  1. Nowe hasła i klucze: nowe hasło do konta u rejestratora.
  2. Na Twojej firmie: domena zarejestrowana na Twoją firmę.
  3. W dokumentacji: spis rekordów DNS, skrzynek i nadawców poczty.

Usługi zewnętrzne

  1. Nowe hasła i klucze: klucze bramki i tokeny API wygenerowane od nowa, stare unieważnione.
  2. Na Twojej firmie: konta bramki płatności, analityki i sklepów na Twojej firmie.
  3. W dokumentacji: spis usług i miejsc, w których są ich klucze.

Jak wygląda raport z przeglądu

Zanim cokolwiek obiecamy, sprawdzamy, co faktycznie jest w repozytorium. Przykładowy, skrócony raport z przeglądu aplikacji zamówień.

Zbliżenie raportu z przeglądu w panelu klienta: zakres, pięć wyników przeglądu i tabela decyzji dla modułów

  1. Stan repozytorium

    Czy projekt buduje się i działa na czystej maszynie, bez wiedzy poprzedniego zespołu. Bez tego nie ma sensu wyceniać dalszych prac.

  2. Ryzyka od najpilniejszego

    Klucz w historii repozytorium unieważniamy od razu. Biblioteki z poprawkami do wgrania i moduły bez testów trafiają do planu prac.

  3. Rekomendacja dla każdego modułu

    Zostawić, poprawić, dokończyć albo przepisać, z uzasadnieniem. Raport omawiamy na spotkaniu, a decyzja zawsze należy do Ciebie.

Dokończyć czy przepisać

Częściej opłaca się dokończyć. Nie zawsze. Wybór dotyczy pojedynczych modułów, a nie całego projektu.

Dokończyć

  • To, co działa, zostaje bez zmian.
  • Poprawiamy to, co zepsute albo niedokończone.
  • Kończymy etapami na wersji testowej.

Przepisać część

  • Przepisujemy tylko moduły, które tego wymagają.
  • Reszta aplikacji, jeśli jest zdrowa, zostaje bez zmian.
  • Nowy moduł od razu dostaje testy.

Kod się buduje, a problemy siedzą w pojedynczych modułach

DokończyćPrzepisać część

Przeważa: Dokończyć. Poprawiamy te moduły i kończymy resztę etapami, bez pisania od nowa.

Moduł łatany wielokrotnie psuje się przy każdej zmianie

DokończyćPrzepisać część

Przeważa: Przepisać część. Łatanie wyszłoby drożej niż napisanie go od nowa, od razu z testami.

Dane i adresy działają i mają ruch

DokończyćPrzepisać część

Przeważa: Dokończyć. Tego ruchu nie warto tracić przy przeprowadzce, więc budujemy dalej na tym, co jest.

Biblioteka, na której stoi moduł, nie jest już rozwijana

DokończyćPrzepisać część

Przeważa: Przepisać część. Nie dostaje już poprawek bezpieczeństwa, więc przepisujemy ten moduł, a resztę zostawiamy.

Gdy przepisać trzeba cały system, a nie jeden moduł, to już migracja na nowy system.

Jak przejmujemy projekt

Najpierw sprawdzamy, co jest w kodzie, a dopiero potem wyceniamy dokończenie. Aplikacja zamówień po freelancerze, który przestał odpowiadać.

  1. Dostęp do kodu

    Zbieramy repozytorium, dostępy do serwerów i usług oraz wszystko, co zostało po poprzednim wykonawcy, łącznie z ustaleniami na piśmie.

    dostajesz: komplet dostępów po zmianie haseł
  2. Przegląd

    Uruchamiamy projekt na czystej maszynie i oceniamy kod, zależności i bezpieczeństwo.

    Repozytorium i serwer
    klucze płatności zmienione tego samego dnia
    dostajesz: raport: co zostawić, co przepisać
  3. Wycena dokończenia

    Na podstawie przeglądu dostajesz zakres podzielony na etapy, termin każdego etapu i ryzyka nazwane wprost.

    Brakujące ekrany
    drugi etap prac
    dostajesz: plan z wyceną
  4. Dokończenie

    Pracujemy etapami na wersji testowej, a każda zmiana przechodzi przegląd. Postęp widzisz na bieżąco.

    Moduł płatności
    przepisany najpierw, z testami
    zmiana zakresu wraca do wyceny: Wycena dokończenia
    dostajesz: etapy odebrane na wersji testowej
  5. Wdrożenie i dokumentacja

    Wdrażamy projekt i opisujemy uruchomienie, architekturę i proces wdrożenia.

    dostajesz: działający projekt z dokumentacją

Kto co robi przy przejęciu

Najwięcej czasu oszczędza szybkie zebranie dostępów.

Lista dostępów do przejęcia w panelu klienta: warstwy projektu, hasła i klucze oraz stan każdego dostępu

  1. Ty

    Kopie zapasowe: czekają na Twój wybór

    Dajesz dostęp do kont, które są na Twoją firmę, i przekazujesz ustalenia z poprzednim wykonawcą. Decydujesz o zakresie i odbierasz etapy.

  2. My

    Bramka płatności: nowe klucze, stary unieważniony

    Wymieniamy hasła i klucze, robimy przegląd i plan, dokańczamy projekt na wersji testowej i piszemy dokumentację. Hasła i kod obejmuje obowiązek poufności z regulaminu, pkt 9.1.

  3. Poprzedni wykonawca

    Klucz do map: na prywatnym koncie wykonawcy

    Trzyma repozytorium i dostępy, których jeszcze nie oddał, oraz wiedzę, której nikt nie spisał. Gdy czegoś brakuje, odtwarzamy to razem z Tobą.

Zmiana zakresu w trakcie prac wymaga zgody obu stron na piśmie i może zmienić kwotę oraz termin (regulamin, pkt 3.3).

Najczęstsze pytania o przejęcie projektu

Odpowiedzi o koszcie, stanie kodu, dostępach i tym, co po oddaniu projektu.

Czytaj dalej

Strony, które przydają się przed przejęciem i po nim.

Projekt utknął u poprzedniego wykonawcy?

Napisz, co już jest, czego brakuje i do czego masz dostęp. Odpowiemy w godzinę z pytaniami i wyceną przeglądu.