Tworzę i rozwijam oprogramowanie.

Narzędzie do wyceny pracuje na tym, co sam o projekcie wpiszesz, i pokazuje rząd wielkości wraz z podziałem na moduły. Rozpoznanie zaczyna się od rozmów i od obejrzenia pracy na miejscu, a kończy dokumentem wymagań i propozycją architektury. Wycena zajmuje kilka minut przy komputerze, licząc od chwili, w której masz już konto w narzędziu. Rozpoznanie jest osobnym zleceniem.

To rola dyrektora technicznego w niepełnym wymiarze. Biorę na siebie decyzje o architekturze, bezpieczeństwo aplikacji i proces wydań produkcyjnych, a zespół zyskuje kogoś, kogo można zapytać, nim decyzja zapadnie sama. Zakres i częstotliwość zależą od wielkości zespołu i od tego, co akurat dzieje się w produkcie, dlatego domykamy je na początku.

Tak. Przez pięć lat pracowałem w aplikacji, której kodu nie pisałem, wchodząc ze zmianami do systemu używanego w tej samej chwili. Osobna sprawa to systemy z długą historią: najstarszy, który prowadzę, ma jedenaście lat i wciąż wchodzą do niego zmiany. Zaczynam od uruchomienia systemu poza produkcją i od testów opisujących jego dzisiejsze zachowanie, dopiero potem wchodzę w zmiany. Jeśli po obejrzeniu kodu okaże się, że nie ma czego ratować, powiem to, zanim wystawię pierwszą fakturę.

Zależy od zakresu, liczby modułów, integracji i wymagań bezpieczeństwa. Pierwsze przybliżenie najszybciej da narzędzie do wyceny. Konkretną liczbę podaję po ustaleniu zakresu.

Tak i najczęściej to proponuję. Pierwsza wersja ma rozwiązać jeden problem i pokazać, czy pomysł się broni.

Nie. Proponuję je tam, gdzie skraca pracę albo robi coś, czego zwykła automatyzacja nie zrobi wystarczająco dobrze. W pozostałych miejscach wystarcza zwykły kod.