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