Problem natury nie do końca filozoficznej. Bowiem jest wiele praktyk i technik, które są opisane, powszechnie znane i nauczane jako właściwe podejście do tworzenia (w tym przypadku: internetowych projektów programistycznych). Czy ścisłe stosowanie się do nich zawsze będzie najlepszym (czytaj – najbardziej efektywnym) rozwiązaniem?
Dla akademickiego przykładu (podkreślam, akademickiego i nieobejmującego wszystkich aspektów wszystkich możliwych projektów;)) – informacyjna (czyli funkcjonalnie w dłuższym okresie czasu niezmienna) strona internetowa z systemem CMS, będąca w zasadzie zbiorem artykułów.
W końcowej fazie projektu Klient stwierdza, że chciałby mieć możliwość dołączenia do dowolnego artykułu formularza o polach konfigurowanych za pomocą CMS.
Aby utrzymać model MVC, należałoby w warstwie kontrolera aplikacji pobrać opis pól formularza oraz przekazać go do widoku, który zajmie się pokazaniem pól. Wiemy jednak (w końcu prowadzimy projekt od jakiegoś czasu), że klient będzie żonglował wyglądem formularza na tyle, że konieczne będzie jego prototypowanie.
Termin się zbliża, budżet jest ustalony, możemy zatem powiedzieć klientowi że jest to osobny moduł aplikacji, który wymaga spisania dokumentacji funkcjonalnej, zaakceptowania jej i wyceny. A następnie wdrożenia zgodnie z zasadami sztuki. To droga jaką najchętniej obrałaby większość programistów
Możemy powiedzieć Klientowi że w tym cyklu życia aplikacji nie ma szans – skończmy, będziemy rozbudowywać. To droga jaką najchętniej obrałaby pozostała część programistów
Ale życie jest życiem i nie zawsze można wybrać najlepszą drogę, zatem możemy wykonać moduł wg wstępnych założeń i zdecydować się na wdrożenie podstawowej funkcjonalności i dalszą rozbudowę pod dyktando Klienta. Dopóki nie wyczerpie się budżet lub nasza cierpliwość
Wówczas:
- możemy wykonywać moduł i poprawki zgodnie z zasadami sztuki, co wymaga dopisania fragmentu interfejsu do CMS, zmodyfikowania kontrolera oraz zmodyfikowania widoku strony. Przy ewentualnych zmianach, sprawa się powtarza – modyfikujemy interfejs CMS (np. o pole definiujące szerokość inputa w formularzu), modyfikujemy kontroler tak by dodał do parametrów widoku odpowiednie opcje i modyfikujemy widok.
- Modyfikujemy CMS o podstawową funkcjonalność w rzeczonym zakresie, a bezpośrednio w warstwie widoku pobieramy definicje pól formularza z bazy i ustawiamy je “na sztywno” pod dyktando klienta tak, aby każde nowe pole (dodane przez Klienta już po zakończeniu projektu) było dodawane w jednym, określonym z góry wyglądzie.
Plusem drogi nr 1. jest to, że wszystko jest zrobione “jak należy”. W kontekście opisanej sytuacji minusem jest to, że pożera ona cenne na końcu projektu czas i koszty, wymaga więcej testowania, a także powoduje wpisanie do systemu CMS funkcjonalności, która nie zawsze będzie przydatna w kolejnym wdrożeniu (np. “ten input niech ma ramkę taką czarną, a ten zieloną…”).
Plusem drogi nr 2. z kolei jest to, że zmiany można wykonać szybko (czyli tanio) i zrobić dokładnie co zechce Klient. Kosztem jakości produktu.
Ostateczny wybór należy oczywiście do samego Klienta, ale jestem przekonany, że większość wybrałaby opcję nr 2. – ponieważ pozwoli ona uzyskać to, co Klient sobie wymarzył. Bez kosztów i z pomijalnie małymi konsekwencjami – ponieważ strona nie będzie rozwijana funkcjonalnie.
Czy zatem droga 2 jest w tym konkretnym przypadku lepsza? I czy warto poświęcić jakość wykonywanej pracy na rzecz zadowolenia klienta?

