Historia programisty SI
#9. Po dołączeniu do projektu SI - początek prawdziwego rozwoju

Po okresie adaptacji w projekcie rozpoczyna się prawdziwy rozwój. Rozwój odbywa się zgodnie z harmonogramem WBS, opierając się na funkcjach określonych w RFP (dokumentacji wymagań). W SI zakłada się, że funkcje mogą ulec zmianie w dowolnym momencie, dlatego tworzy się je w taki sposób, aby jak najmniej wpływały na integrację z innymi modułami.

Przyczyną tego jest to, że zleceniodawca projektu zna wprawdzie swoje obowiązki, ale nie jest w stanie podać wytycznych dotyczących realizacji, takich jak niezbędne funkcje, sposób konfiguracji ekranu itp. Dlatego też pokazanie mu gotowych ekranów często skutkuje pojawieniem się dodatkowych wymagań lub zmian.

Z tego powodu w przypadku silnej integracji z innymi modułami modyfikacja jednego modułu wymaga modyfikacji innych, co może prowadzić do nieoczekiwanych efektów ubocznych i niepotrzebnego powielania kodu.

Głównym celem SI jest stworzenie czegoś, co działa, więc kwestie takie jak czysty kod czy wydajność schodzą na drugi plan.

Na początku zawsze chcesz zrobić wszystko dobrze, ale napięty harmonogram i ciągłe żądania od klienta, który wciąż dodaje nowe wymagania, sprawiają, że szybko zaczynasz pracować "po łebkach".

Poza tym klienci czasami myślą, że skoro płacą, to wszystko zrobi się samo. To sygnał ostrzegawczy przed nadchodzącym chaosem na końcu projektu. Jeśli coś jest niejasne, zawsze pytaj i spisz to na piśmie.

Pamiętaj o tych kwestiach podczas pracy w SI:

• Treść może ulec zmianie w dowolnym momencie.
• Klient nic nie wie. Pokazuj mu ekrany po kawałku i regularnie zbieraj jego opinie.
• Nie odpowiadaj "tak" na każde dodatkowe żądanie, chyba że jest to konieczne.
• Nie jestem Billem Gatesem. Klienci bardziej cenią szybkość tworzenia ekranów niż dobrze napisany kod.