Dwa oblicza architekta

Dwa oblicza architekta

Wielokrotnie podczas konferencji programistycznych prelegenci przedstawiają się jako programujący architekt. Zawsze intrygowało mnie to stwierdzenie i zadawałem sobie pytanie: czy nieprogramujący architekt to jakaś hańba? Przecież ja osobiście mam wiele dni lub nawet tygodni, gdzie nie dotykam swojego ulubionego IDE i nie pushuję żadnych zmian do GITa. Czy ja jestem nieprogramującym architektem? Czy ja w ogóle jestem architektem, skoro nie programuję? W pewnym momencie udało mi się to poskładać do kupy i zorientować się, o co w tym wszystkim chodzi. We własnej karierze dostrzegam dwa oblicza architekta: Architekt – sprzedawca oraz Architekt – wykonawca.

Architekt – sprzedawca

Sprzedaż, account manager, sales manager – sama myśl o tych stanowiskach mrozi krew w żyłach. Odwieczny konflikt między programistą a sprzedawcą:

  • Programista: sprzedać umiał, ale weź to teraz zaprogramuj – przecież tego nie da się zrobić! Ehhh ci ludzie z biznesu! Banda [pi, pi, pi].
  • Sprzedawca: zaprogramowali, a ja muszę się wstydzić za błędy, niestabilność! Ehh ci programiści! Siedzą w tych ciemnych norach i produkują jakieś [pi, pi, pi].

Brzmi znajomo, prawda? Jakże to prawdziwe. Jednak, gdy wejdziemy w temat głębiej to zdamy sobie sprawę z tego, że bez sprzedaży nie byłoby projektów. Klient ma określoną kwotę na zbudowanie serwisu i przychodzi do naszego account managera, by zamówić system. To właśnie sprzedaż dwoi się i troi, by załatwić nam kontrakt, być podczas realizacji projektu często maskując błędy i niedopatrzenia developerów. To właśnie sprzedaż odbywa dziesiątki spotkań z Klientem przekonując go o wartości firmy. To wlaśnie sprzedaż! Ale zaraz, przecież sprzedaż z reguły nie ma pojęcia o technologiach, kontenarach, programowaniu. Zna jedynie hasła, ale Klient często oczekuje więcej. Tutaj dochodzimy do miejsca, gdzie wjeżdża architekt cały w bieli, na białym rumaku. Architekt zaczyna być sprzedawcą. Dwoi się i troi pokazując swoją wiedzę i próbuje pomóc w procesie sprzedażowym.

Mówiąc bardziej poważnie, wsparcie architekta na etapie pozyskiwania projektu jest bardzo istotne. Już w dokumentach ofertowych przedstawia się bloki, z których będzie zbudowany system, mówi się o technologiach. Jest to niesamowite miejsce, gdyż w tym właśnie punkcie architekt próbuje dopasować technologie, framework czy nawet architekturę systemu. Nie mówimy tu jeszcze o programowaniu, nie powstała nawet linijka kodu – a architekt musi się napracować. Jak wielką wiedzę powinna mieć taka osoba, jakie doświadczenie. Już na tym etapie jest wielka rozgrywka: sukces czy porażka całego projektu. Niejednokrotnie stawałem ramię w ramię ze sprzedażą i pomagałem tworzyć dokumenty ofertowe, planować budżet, itd. Praca trudna, praca niewdzięcza, olbrzymia odpowiedzialność, ale jakże wielka satysfakcja. Dlaczego trudna i niewdzięczna? Architekt w tym wypadku musi być alfą i omegą. Musi asymilować się z danym biznesem, dla którego sprzedajemy produkt (raz to jest sektor ubezpieczeniowy, raz branża bankowa, energetyczna, kurierska, itd.). Każdy nowy projekt to kolejna lekcja, poznanie kolejnej branży. Z drugiej strony architekt musi być biegły w trendach technologicznych, za którymi podąża rynek. Musi gonić świat, nowe frameworki, nowe podejścia do projektowania itd. Jest zawieszony pomiędzy Klientem, Analitykiem i Project Managerem. To on musi zrozumieć dokumenty analizy, umieć znaleźć wspólny język z Klientem oraz oszacować zadania dla swego kierownika projektu. Kiedy jest więc czas na programowanie, na zamknięcie się w czterech ścianach, nałożenie słuchawek na uszy i oddanie się milionom warunków logicznych, które w postaci cząstek neuronowych pałętają się po mózu programisty? (ahhh te stare dobre czasy) 🙂

Architekt – wykonawca

Drugim obliczem architekta jest wsparcie developmentu. Tutaj wchodzimy na bezpieczne pole, gdzie nie ma polityki, gdzie nie ma aktorstwa. Czysty kod, czyste reguły. Tylko ja, mój komputer i specyfikacja. Architekt wykonawca ma tą przyjemność, że spina cały projekt. To on tworzy szkielet aplikacji, adoptuje odpowiednie narzędzia, frameworki i tworzy z tego poezję 🙂 Piszę tutaj z lekkim sentymentem, gdyż mam coraz mniej okazji na programowanie. Jednak robię wszystko co w mojej mocy, by być blisko kodu.

Wracając do głównej myśli – architekt w tym procesie jest takim trochę mistrzem Jedi. To on podejmuje wszystkie kluczowe decyzje, odpowiada za wygląd projektu, za jego jakość, za zmieszczenie się w budżecie! Nie jest to łatwa sztuka, w szczególności gdy zespół wykonawczy nie jest zgrany lub dynamicznie się zmienia. Osobiście jestem zwolennikiem stałych zespołów, gdzie wszyscy się znają i wzajemnie ufają. Chciałbym tu raz jeszcze podkreślić słowo jakość projektu. To właśnie na tym etapie widać mądrość architekta. Jest on w stanie przemycić do projektu stabilne rozwiązania, wymusić dobre testy, zadbać o samotestowalność aplikacji. Deweloperzy bardzo często pracują w reżimie czasowym tworząc tony kodu, który w żaden sposób nie jest pokryty testami. Wielokrotnie audytowałem aplikacje tworzone przez różne zespoły. Taką operację zawsze zaczynam od sprawdzenia ilości testów jednostkowych. Już sama liczba mówi dużo o projekcie i sposobie jego realizacji. Nie zapomnę projektu, który przejmowałem. Był tam jeden test jednostkowy, który się wywalał. Koniec końców okazało się, że projekt był prowadzony bez architekta i niestety nie zmieścił się w budżecie. Tak z reguły kończą się realizacje, gdzie nie ma main-man’a, osoby która spina całość i bierze na barki dostarczenie całego projektu, tj. etap developmentu, testów, instalacji oraz dokumentacji projektu.

Polityka firmy

W firmie w której pracuję, obie role architekta się przenikają. Mam tą przyjemność pracować jako architekt sprzedawca i być świadkiem powstawania czegoś wielkiego – nowego projektu. Następnie mogę być osobą, która ciągnie ten pług i tworzy oprogramowanie. Nie jestem w tym idealny, popełniam wiele błędów, podejmuję wiele błędnych decyzji. Jestem tylko człowiekiem i cały czas zbieram nowe cenne lekcje programowania. Taki tryb pracy pozwala mi doskonalić rzemiosło programistyczne, ale też poszerza moje umiejętności miękkie, negocjacyjne, itd. W którym kierunku dalej pójdę? Nie wiem. Życie pokaże, gdzie będę się czuł lepiej.

 

About the author

piotr.filipowicz

View all posts

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *