Szukasz szkolenia sprzedażowego lub biznesowego w Warszawie? Szkolenia edukacyjne!

Koncepcyjna jednorodność i architekt – dalszy opis

Architekt. Dowodzę w rozdziałach od 4 do 7, że najważniejszym działaniem jest wyznaczenie jednego architekta produktu, odpowiedzialnego za koncepcyjną jednorodność wszystkich właściwości produktu, dostrzegalnych przez użytkownika. Architekt tworzy i odpowiada za koncepcyjny model produktu, który będzie wykorzystywany do wyjaśnienia użytkownikowi, jak się nim posługiwać. To on ustala szczegółową specyfikację wszystkich funkcji oraz środki ich wywoływania i sterowania nimi. Architekt jest też przedstawicielem użytkownika, świadomie reprezentującym jego interesy w nieuniknionych kompromisach między funkcją produktu, jego efektywnością, rozmiarami, ceną i harmonogramem. Funkcja ta wymaga pracy w pełnym wymiarze godzin: jedynie w najmniejszych zespołach można ją łączyć z funkcją szefa zespołu. Architekt przypomina reżysera, a szef – producenta filmu.

Oddzielenie architektury od implementacji i realizacji. Aby w ogóle zrozumieć, na czym polega kluczowe zadanie architekta, trzeba oddzielić prace nad architekturą, czyli definicją produktu w kategoriach postrzeganych przez użytkownika, od prac nad implementacją. Takie podejście wyznacza wyraźną granicę między poszczególnymi częściami zadania projektowego, a jest co robić zarówno w jednym, jak i w drugim wypadku.

Podział architektury. W wypadku dużych produktów jeden umysł nie jest w stanie zaprojektować całej architektury, nawet po oddzieleniu wszelkich zajęć związanych z implementacją. Główny architekt systemu musi zatem podzielić system na podsystemy. Granice między podsystemami powinny przypadać tam, gdzie interfejsy między podsystemami są najmniejsze i gdzie najłatwiej je ostro zdefiniować. Wtedy każda część musi mieć własnego architekta, podlegającego głównemu architektowi systemu. Oczywiście proces ten można powtarzać, w zależności do potrzeb.

Jestem o tym dzisiaj przekonany bardziej niż kiedykolwiek. Koncepcyjna jednorodność to wymóg najważniejszy, jeśli chodzi o jakość produktu. Ustanowienie architekta systemu to najważniejszy krok na drodze do spełnienia go. Zasada ta w żadnym wypadku nie ogranicza się do prac nad systemami oprogramowania. Odnosi się także do projektowania dowolnej złożonej konstrukcji, na przykład komputera, samolotu, Inicjatywy Obrony Strategicznej albo Globalnego Systemu Lokalizacji. Po 20-krotnym prowadzeniu warsztatów z inżynierii oprogramowania doszedłem do tego, że wymagałem od studentów, żeby nawet w zaledwie czteroosobowych zespołach wybrali szefa i architekta. Wyznaczenie odrębnych stanowisk w tak niewielkich grupach może być przesadą, ale z moich obserwacji wynika, że jest to skuteczne i prowadzi do sukcesów w projektowaniu.

Nadmiar funkcji i odgadywanie częstości występowania cech użytkowników

Projektowanie dla dużych zbiorów użytkowników. Jedną z konsekwencji rewolucji komputerów osobistych jest to, że w coraz większym stopniu zastępuje się programy użytkowe, opracowywane na indywidualne zamówienia, gotowymi pakietami programów, sprzedawanymi z półki. Ponadto standardowe pakiety oprogramowania są sprzedawane w setkach tysięcy egzemplarzy, a nawet w milionach. Architekci systemów oprogramowania sprzedawanego z automatów zawsze musieli projektować na rzecz wielkiego, amorficznego zbioru użytkowników – inaczej niż w wypadku konkretnego, możliwego do zdefiniowania programu użytkowego, przeznaczonego dla jednej firmy. Dziś wobec takiego zadania staje bardzo wielu architektów systemu.

Paradoksalnie, znacznie trudniej zaprojektować narzędzie ogólnego użytku (uniwersalne) niż specjalizowane – a to właśnie dlatego, że trzeba uwzględniać odmienne potrzeby rozmaitych użytkowników.

Nadmiar funkcji. Architekt narzędzia ogólnego użytku, takiego jak arkusz kalkulacyjny albo edytor tekstu odczuwa dokuczliwą pokusę przeładowania programu funkcjami o marginalnej przydatności – i to kosztem efektywności, a nawet wygody w użytkowaniu. Atrakcyjność proponowanych funkcji jest widoczna od początku: cena, jaką się za to płaci, w postaci obniżonej efektywności staje się widoczna dopiero w trakcie testowania systemu. Zmora utraty łatwości użytkowania danego narzędzia skrada się zdradliwie, w miarę przyrostowego dodawania nowych funkcji, a podręczniki stają się coraz grubsze1.

Podobne Artykuły

Zostaw odpowiedź

Twoj adres e-mail nie bedzie opublikowany.