Nasza strona używa cookies. Dowiedz się więcej o celu ich używania i zmianie ustawień w przeglądarce. Korzystając ze strony, wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki. Rozumiem

Architekt w projektach IT - o co w tym wszystkim chodzi?

  • 13.04.2017

Architekt w projektach it %2814%29
Architekt w projektach IT

„Jesteś informatykiem?” – pada pytanie a zaraz po nim prośba „Mam właśnie taki stary program SuperFaktura2000 i tam zrobiłam zestawienie kosztów za ostatni kwartał i chciałabym zrobić wykres porównawczy z analizą trendu długoterminowego. To co mam teraz kliknąć? Nie wiesz???!!! Jak to? To chyba jesteś słabym informatykiem.”.

Większość z nas, "informatyków", zetknęła się z taką lub podobną sytuacją. Reszta populacji widzi nas jako jednorodną, spójną masę o identycznych umiejętnościach i wiedzy. Informatyk to informatyk, po co drążyć. A jednak tak jak w przypadku lekarzy czy prawników dzielimy się na grupy, które często łączy tylko kilka lat wspólnych studiów, a dzieli wszystko inne.

Niskopoziomowy programista lubujący się w C i Assemblerze to przecież zupełnie inny zakres wiedzy niż projektant systemów bazodanowych w sieciach rozległych lub specjalista wsparcia IT pracujący w helpdesku dużej korporacji. Co prawda, jako ludzie ciekawi świata, interesujemy się i mamy często spore pojęcie również w tematach IT bardziej odległych od naszej specjalizacji, ale to nie znaczy, że każdy z nas potrafi obsługiwać program SuperFaktura2000. Piekło zaczyna się w momencie, jak już uda mi się wytłumaczyć, że nie znam się na programie SuperFaktura2000, bo jestem architektem oprogramowania. „Jak to architektem? Mówiłeś, że informatykiem? Coś kręcisz!”. A więc co to za stwór ten architekt, dlaczego nic namacalnego nie buduje i do tego często nie wie co to belka stropowa?

Architekt oprogramowania to specjalizacja często nieznana do momentu rozpoczęcia pracy w poważnej firmie zajmującej się wytwarzaniem oprogramowania. Gdy świeżo upieczony absolwent politechniki przekroczy pierwszy raz drzwi wymarzonej firmy szybko zdaje sobie sprawę, że tworzenie prawdziwego „softu” to bliska współpraca wielu osób a spontaniczny jednoosobowy zryw na noc przed terminem raczej nie ma prawa się udać. Oczywista wydaje się wtedy potrzeba istnienia kogoś, kto od strony czysto technicznej ogarnie chaos i poprowadzi wszystkich w stronę światła.

 

Tym kimś jest architekt.

Tak jak jego budowlany odpowiednik, ma za zadanie rozłożyć planowany produkt na części, określić wszystkie kluczowe zależności, uwzględnić wymagania, zdefiniować niezbędne do zaimplementowania elementy, relacje między nimi i w formie graficznej opisać efekt swojej pracy. Tak opisany system, może zostać zaimplementowany przez programistów i przetestowany przez testerów. Współczesne oprogramowanie potrafi być złożone jak nowoczesny drapacz chmur, więc zbieżność nazw jest nieprzypadkowa.

 

Jak zostać architektem?

To pytanie jest też częstym tematem dyskusji samych architektów. Raczej rzeczą bezsporną wydaje się, że przyszły architekt powinien mieć doświadczenie w pracy na stanowisku programisty. W końcu efekty jego pracy stanowić mają główne źródło wiedzy programistów, a nikt inny nie zrozumie potrzeb programisty jak ten kto sam nim kiedyś był. Poza tym praca architekta opisywana jest przy pomocy języka UML. Wieloletnie doświadczenie w czytaniu diagramów zapewne przekłada się na umiejętność tworzenia ich w czytelnej i poprawnej postaci w przyszłości. Nie zapominajmy również, że architekt powinien być w jakimś stopniu mentorem dla swoich programistów. Jest to możliwe tylko wtedy, gdy mówi tym samym językiem i posiada wystarczającą wiedzę niezbędną do rozwiązywania złożonych problemów.

Praca architekta jest szczególnie zauważalna w początkowej fazie projektu.

To wtedy powstaje koncepcja całego systemu i wymagana jest dość bliska współpraca z klientem. Istotne są umiejętności interpersonalne, bo klient często przekazuje niewystarczającą ilość informacji i trzeba je z niego skutecznie wydobyć. To co zostanie stworzone w tej fazie, będzie miało kluczowe znaczenie dla ostatecznego kształtu produktu. Architekt musi zaprojektować system z odpowiednią szczegółowością wystarczającą do jego implementacji. Ważna jest znajomość wzorców projektowych i standardów w branży (np. sieci CAN w przypadku projektów Automotive). Błędy popełnione na tym etapie mogą być bardzo kosztowne w przyszłości, dlatego architekci często konsultują się ze sobą i z programistami szukając najlepszych i najpewniejszych rozwiązań. 

Ponieważ zakres obowiązków jest bardzo szeroki, istotne jest, żeby architekt potrafił je odpowiednio planować i priorytetyzować. Rola ta wymaga elastycznego podejścia do wykonywanych zadań. Nie jest czymś nadzwyczajnym sytuacja, w której praca architekta przerywana jest przez ważniejsze zadanie, wymagające szybkiej realizacji. Późniejszy powrót do poprzedniej aktywności powinien przebiegać płynnie i bez zbędnych opóźnień. Wynika to między innymi z tego, że architekt współpracuje z innymi członkami projektu, którzy pełnią różne role, przez co obszar ich zainteresowań może znacząco się różnić. Inaczej wygląda rozmowa architekta z programistą, a inaczej z kierownikiem projektu czy klientem. Również wynik pracy i odpowiedzialność zmienia się w zależności od skali projektu, firmy, klienta. W dużych, liczących np. kilkadziesiąt osób mogą to być zadania związane wyłącznie z tworzeniem i utrzymywaniem architektury systemu. W projektach małych, architekt może pełnić również rolę programisty, mając szansę zaimplementować to, co sam koncepcyjnie stworzył.

W GlobalLogic stawiamy na to, aby każdy Architekt był ekspertem w dziedzinie, w której pracuje. Tematy i obszary, w których miałby się specjalizować nie są narzucane z góry, a raczej odzwierciedlają faktyczne zainteresowania danej osoby. Nie wyobrażamy sobie Architekta, który nie śledzi bieżących nowinek w branży leżącej w kręgu jego zainteresowań - ciągłe dokształcanie się pozwala sprostać rosnącym oczekiwaniom klienta. 

Co więcej - w GlobalLogic chcemy przenieść pracę Architektów na inny poziom tak, żeby jeszcze lepiej wykorzystać ich potencjał, a jednocześnie dać im możliwość dalszego rozwoju. W tym celu wprowadzamy rolę, która oprócz typowych dla architekta zadań, wykorzystuje specyficzny dla tej roli charakter pracy i pozwala mu pełnić zadania nie tylko ściśle projektowe, ale również mające na celu zdobycie i przyciągnięcie nowych klientów. Do takich zadań należą m.in. analiza pod kątem technicznym zapytań projektowych, szacowanie czasu potrzebnego do ukończenia projektu czy definiowanie zespołu, który najlepiej nowy projekt wykona. Są to zadania złożone, obarczone sporym ryzykiem i niepewnością, dlatego Architekt w GlobalLogic bierze dużą odpowiedzialność za swoją pracę. Jednocześnie poziom satysfakcji z osiągnięcia celu jakim jest zdobycie nowego projektu jest ogromny. Jednak nie jest tak, że architekt ze swoimi zadaniami pozostaje sam na sam. Pracuje w zespole, którego członkami są również przedstawiciele działu sprzedażowego oraz kierownicy projektów.

Wracając do podobieństw - nie ma dobrej konstrukcji bez dobrego architekta tak samo jak nie będzie dobrego oprogramowania bez tej wyjątkowej roli w zespole. W różnych firmach może ona przyjmować różne formy, realizować mniej lub więcej zadań, być bardziej lub mniej obarczona odpowiedzialnością za realizację projektu - nie podlega jednak wątpliwości że chcąc uzyskać wysokiej jakości produkt - jest ona niezbędna.

 

Marcin Medyński Consultant w GlobalLogic

Seweryn Pływaczyk Consultant w GlobalLogic

 

Architekt w projektach IT
Architekt w projektach IT
Hqdefault

Rekrutują