Zanim napiszesz, możesz sprawdzić odpowiedzi na pytania, które słyszymy najczęściej.

Nie. Wystarczy, że potrafisz opisać problem, obecny sposób pracy albo efekt, który chcesz osiągnąć. Zakres i specyfikację układamy razem po rozpoznaniu procesu.

Tak — i często właśnie tak rekomendujemy. Najpierw budujemy albo sprawdzamy fragment, który daje największą wartość lub usuwa największą niewiadomą.

Bez poznania procesu nie chcemy podawać przypadkowej liczby. Koszt zależy m.in. od liczby ról, danych, integracji, poziomu automatyzacji i odpowiedzialności systemu. Po rozpoznaniu przygotowujemy zakres i estymację dla konkretnego etapu.

Prosta witryna i rozbudowany system biznesowy to zupełnie inne projekty. Zamiast obiecywać jedną liczbę dla wszystkiego, dzielimy pracę na etapy i pokazujemy, kiedy możesz dostać pierwszy działający efekt.

Nie. Możemy rozbudować istniejący produkt, uporządkować fragment procesu, zbudować portal klienta obok obecnego systemu albo połączyć narzędzia integracją. Najpierw sprawdzamy, co warto zachować.

Tak, jeśli tego potrzebujesz. Utrzymanie, poprawki, rozwój i kolejne etapy traktujemy jako naturalną część życia produktu, a nie awaryjny dodatek.

Jeżeli dany system udostępnia API, pliki wymiany albo inny bezpieczny sposób integracji, zwykle tak. Sprawdzamy możliwości i ograniczenia przed obiecaniem konkretnego zakresu.

Robimy oba typy projektów. W przypadku witryn nadal zaczynamy od celu biznesowego: kto ma wejść, co ma zrozumieć i jaki kolejny krok powinien wykonać.

Tak, jeśli problem i zakres mają sens dla obu stron. Nie zakładamy, że każdy projekt musi być duży. Czasem najlepszym rozwiązaniem jest niewielkie narzędzie albo dobrze zaprojektowany pierwszy etap.

Opowiadasz nam, jak wygląda sytuacja dzisiaj i co chcesz zmienić. My dopytujemy o proces, użytkowników, dane i ograniczenia. Na końcu powinniśmy wiedzieć, jaki następny krok ma sens — albo uczciwie powiedzieć, że nie jesteśmy właściwym zespołem.