Jak pracuję nad aplikacją lub automatyzacją dla firmy

1. Zaczynam od pracy firmy, nie od listy funkcji

Najpierw chcę zobaczyć jedną prawdziwą sprawę od początku do końca. Kto ją rozpoczyna, jakie dane są potrzebne, gdzie ktoś coś przepisuje, gdzie zapada decyzja i co oznacza „gotowe”. Dopiero wtedy wiadomo, czy problem wymaga aplikacji, integracji czy tylko prostszej automatyzacji.

2. Wybieramy najmniejszy sensowny pierwszy etap

Nie próbuję zamknąć całej firmy w pierwszej wersji. Pierwszy etap powinien samodzielnie dawać wartość: np. lista zleceń i statusy, integracja formularza z CRM-em albo kalkulator, który usuwa ręczne liczenie ofert.

3. Zakres jest opisany rezultatem

Zamiast „40 godzin programowania” ustalamy, co ma działać po zakończeniu etapu. Dzięki temu łatwiej odebrać pracę i ocenić, czy rozwiązanie rzeczywiście usuwa problem.

4. Testuję na realnych scenariuszach

Najważniejsze są przypadki z codziennej pracy: poprawne dane, brak danych, zmiana decyzji, duplikat, anulowanie i sytuacja wyjątkowa. W integracjach sprawdzam także, co dzieje się przy niedostępności zewnętrznego systemu.

5. Wdrożenie bez zatrzymywania firmy

Jeżeli to możliwe, nowy moduł uruchamia się równolegle z dotychczasowym procesem. Pozwala to sprawdzić dane i przyzwyczaić zespół bez „wielkiego przełączenia” jednego dnia.

6. Po wdrożeniu system może rosnąć modułami

Gdy pierwszy etap działa, dokładamy to, co faktycznie ma największą wartość: kolejne role, raport, dokument, panel klienta albo integrację. Nie budujemy funkcji „na zapas”, jeśli nikt jeszcze nie wie, czy będą potrzebne.

7. Utrzymanie jest osobnym zakresem

Jeżeli aplikacja opiera się na zewnętrznych API, warto monitorować błędy i zmiany po stronie dostawców. Mogę zostać przy systemie po wdrożeniu albo przekazać go dalej w uporządkowanej formie.

8. Kod, repozytorium i dostęp do infrastruktury

Przed startem ustalamy, gdzie będzie repozytorium, kto ma do niego dostęp, gdzie działa środowisko produkcyjne i kto jest właścicielem kont administracyjnych. Jeżeli projekt ma być łatwy do przejęcia przez innego wykonawcę, najlepiej założyć to od początku zamiast odtwarzać dostępy dopiero przy zmianie dostawcy.

Model praw do kodu, licencji i komponentów zewnętrznych powinien być wpisany w zamówieniu lub umowie dla konkretnego projektu. Nie mieszam tego z samą ceną programowania — ważne, żeby obie strony wiedziały, co dokładnie jest przekazywane i na jakich zasadach.

9. Poufność i dostępy techniczne

Do pierwszej rozmowy nie potrzebuję haseł, tokenów ani danych klientów. Jeżeli później potrzebny jest dostęp do systemu, zakres powinien być możliwie najmniejszy: osobny użytkownik techniczny, ograniczone uprawnienia i możliwość odebrania dostępu po zakończeniu etapu. Jeżeli projekt wymaga NDA albo dodatkowych zasad poufności, ustalamy je zanim zaczniemy przekazywać wrażliwe materiały.

10. Hosting, backup i przekazanie projektu

Hosting może być po stronie klienta albo w uzgodnionej infrastrukturze. Ważniejsze od nazwy dostawcy jest to, żeby firma wiedziała, gdzie działa aplikacja, gdzie są kopie zapasowe, kto ma dostęp administracyjny i jak wygląda odtworzenie po awarii.

Przy przekazaniu większego systemu porządkuję przynajmniej podstawowe informacje o uruchomieniu, zależnościach, konfiguracji i miejscach integracji. Celem jest to, żeby kolejna osoba techniczna nie musiała zaczynać od zgadywania, jak system został zbudowany.

Co dostajesz na końcu etapu?

• działający uzgodniony zakres,
• testy na ustalonych scenariuszach,
• informację o zależnościach i integracjach,
• instrukcję użytkową tam, gdzie jest potrzebna,
• listę sensownych kolejnych kroków zamiast obowiązku dalszej rozbudowy.

Od czego zacząć rozmowę?

Najprościej przez stronę Opisz projekt. Jeżeli wolisz najpierw uporządkować materiał samodzielnie, zobacz jak przygotować brief aplikacji i co wpływa na koszt projektu.

Opisz pierwszy problem do rozwiązania →