Nowy projekt i co dalej? Warstwy projektowe
Dawno nie było tak technicznego wpisu jak dziś. Praca kierownika projektów często przesiąka elementami technicznymi.
Jakiś czas temu odpowiedziałem na pytanie Czy kierownik projektu musi być osobą techniczną?
Dzisiaj będę kontynuował ten temat. Podzielę się z Tobą pewną koncepcją, która ułatwia rozumienie kwestii technicznym w projekcie – nawet jeśli nie masz za wiele wspólnego z programowaniem.
Warto zaznaczyć, że na codzień zajmuję się projektami webowymi, ale myślę, że z łatwością przeniesiesz moją koncepcję na inne technologie.
Chyba wszystkich nas dotyka ten sam problem – często trzeba wykonać analizę lub wycenić pracę do zakresu, który jeszcze nie został określony.
Możemy wtedy bardzo szybko „odpłynąć” skupiając się na mniej istotnych detalach projektu, zamiast skupić się „na mięsie” żeby móc określić pracochłonność/koszt danego projektu.
Trzy Warstwy Projektu
Dzielę każdy projekt na trzy warstwy:
- modelu – jest to odpowiednie zrozumienie struktury i zależności w projekcie. Wydzielamy role systemowe, powiązania i hierarchię. Doskonale obrazuje to diagram klas. Można „luźno” powiedzieć, że to baza danych naszego projektu.
- aplikacji – jest to logika naszej aplikacji. Wszelkie algorytmy i procesy jakie mamy w naszym projekcie.
- widoku – cała część wizualna, UXowa, czyli interfejs użytkownika.
Tworząc analizy czy wyceny zawsze staram się jak najdokładniej określić warstwę modelu. Bez dokładnego zrozumienia modelu nie jesteśmy w stanie poprawnie zaprojektować logiki biznesowej, ani interfejsu (może się zmieniać gdy zmienimy model).
Projektuj w dół: model -> aplikacja -> widok
Często zmiany w warstwie modelu oddziaływują na inne warstwy. Jeśli np źle zrozumieliśmy hierarchię obiektów to przy poprawieniu warstwy modelu musimy nanieść zmiany w logice biznesowej i często w warstwie widoku. Bo inne informacje trzeba prezentować w inny sposób.
Powyższą koncepcję stosuję też klasyfikując błędy w projekcie. Koszt naprawy błędów w warstwie modelu jest zawsze największy, w warstwie aplikacji mniejszy i najmniejszy w warstwie widoku. Oczywiście nie jest to regułą tylko uogólnieniem.
Wraz ze schodzeniem warstw w dół (model -> aplikacja -> widok) mamy coraz więcej możliwości różnego zaprojektowania ich.
Jeśli dobrze zrozumiemy model i nasza struktura/schemat będzie znormalizowana istnieje niewiele alternatywnych ścieżek zaprojektowania np diagramu klas czy konkretnej struktury bazy.
Natomiast mamy większe pole manewru zaprojektowania warstwy aplikacji, naszej logiki biznesowej. Dane obliczenia możemy zrealizować różnymi wyliczeniami, algorytmami, które dadzą ten sam wynik.
Najwięcej możliwości różnej interpretacji mamy w warstwie widoku. Tutaj do naszej warstwy modelu i aplikacji możemy zaprojektować „nieskończoną” ilość możliwości interfejsu.
Podsumowanie
Myślenie o projekcie w kontekście trzech warstw może pomóc Ci skupić się na tym co jest w danej chwili najistotniejsze. Powinieneś próbować analizować projekt w kolejności warstw: modelu, aplikacji, widoku.
Warstwa modelu wpływa znacznie na to jak wyglądać będzie warstwa aplikacji, a ta z kolei wpływa na warstwę widoku dlatego najlepiej zacząć od korzenia.
Koncepcję tą możesz wykorzystać również do istniejących projektów, żeby klasyfikować błędy w projekcie – dość szybko dojdziesz do wniosku, czy powinieneś przebudować np bazę danych by zredukować ilość błędów (jeśli błędy tyczą się warstwy modelu).
Mała uwaga – zdaję sobie sprawę, że z punktu widzenia architekta, analityka lub programisty podział projektu wygląda zupełnie inaczej.
Koncepcja, którą Ci przedstawiłem pomoże Ci „ogarnąć” chaos na początkowym etapie projektu, żeby wiedzieć, na których elementach wykonując pre-analizę powinieneś się skupić by móc określić m.in. pracochłonność.
Mam nadzieję, że ta koncepcja przyda się głównie nietechnicznym kierownikom projektu, którzy będą modli nieco skuteczniej przenosić wymagania między biznesem i programistami.
Dziękuję, że przeczytałeś ❤️
Pssst... przygotowałem dla Ciebie kilka prezentów - wybierz co Ci się przyda! 👍