Wycenę dokończenia cudzego projektu podajemy po przeglądzie kodu i dostępów, bo dopiero wtedy wiadomo, ile pracy zostało. Termin samego przeglądu jest od razu w jego wycenie, a zanim zmienimy pierwszą linijkę kodu, przechodzimy listę, w której kolejność ma znaczenie.
Co sprawdzamy przed wyceną dokończenia
| Co | Dlaczego |
|---|---|
| Hasła, klucze i tokeny | zmieniamy wszystkie, które mógł znać poprzedni wykonawca; GitHub pisze, że pierwszym krokiem po wycieku sekretu jest jego unieważnienie, bo z cudzych kopii repozytorium sekretu nie da się usunąć |
| Domena, serwer i usługi zewnętrzne | przepisujemy je na Twoją firmę, a nie na nas; o domenie .pl decyduje jej abonent, więc domena zapisana na wykonawcę wymaga jego udziału |
| Czysta instalacja | budujemy i uruchamiamy projekt na nowej maszynie wyłącznie według repozytorium, bez wiedzy poprzedniego zespołu |
| Kod i zależności | struktura, testy, przestarzałe i podatne biblioteki oraz to, czy da się je bezpiecznie zaktualizować |
| Kopia i monitoring | kopię danych sprawdzamy odtworzeniem, a monitoring włączamy przed pierwszą zmianą, żeby widzieć stan wyjściowy |
Raport i decyzja
Raport z przeglądu mówi, co zostawić, co poprawić, a co przepisać, z uzasadnieniem. Przepisujemy tylko moduły, które psują się przy każdej zmianie albo stoją na bibliotece, której nikt już nie rozwija, a resztę kończymy etapami na wersji testowej. Wycena ma zakres podzielony na etapy, termin każdego z nich i ryzyka nazwane wprost, a decyzja, co przepisać, zawsze należy do Ciebie. Kod, który dopiszemy, przechodzi na Ciebie po odbiorze i opłaceniu. Gdy na razie potrzebujesz tylko diagnozy, zacznij od audytu kodu.
Przegląd, plan dokończenia i dokumentację na koniec opisuje strona przejęcia projektu.
Czy ten wpis był przydatny?
