Solutions Architect. Wizja osobista.

10 listopada, 2020 Krzysztof Kąkol

Kim właściwie jest Solutions Architect? Intuicyjnie każdy ma jakąś swoją definicję. Definicje te są w większości niekompletne i zależą od tego, czego nam w projekcie potrzeba. Kiedy rozmawiam z project managerami, tech leadami, developerami, klientami czy analitykami biznesowymi, to wyłania się z tego obraz architekta jako człowieka-orkiestry. Kogoś, kto swoją ekspertyzą, doświadczeniem, elastycznością i odpowiedzialnością załata wszystkie dziury w projekcie. Zarówno te związane z procesami, jak i te wynikające z braku kompetencji zespołu czy problemów komunikacyjnych.

Każdy projekt jest inny i w każdym odpowiedzialności Solutions Architecta mogą być rozłożone inaczej. Czasami architekt pracuje razem z zespołem, nierzadko dostarczając nawet kod. Czasem jest to praca wysokopoziomowa, związana z koncepcjami architektonicznymi i definiowaniem drogi, którą projekt ma podążać w obszarze technologii. To, w co tak naprawdę angażuje się architekt, jest wypadkową potrzeb zespołu, charakteru samego architekta oraz definicji projektowych.

Różne wizje Solutions Architecta są jak najbardziej uzasadnione, a na dodatek ciężko sprowadzić je do wspólnego mianownika. Jednak architekt może pomóc sobie i projektowi, będąc świadomym pewnych aspektów swojej pracy.

Technologiczny jasnowidz


Architekt z reguły koncentruje się na bieżących wyzwaniach w projekcie. Rozwiązuje sprawy nierozwiązywalne i planuje wykonanie tego, co akurat jest do wykonania. Ale – tak jak nie powinien zapominać o wyzwaniach technologicznych biznesu – nie może tracić z widoku tego, co wydarzy się za chwilę. To oczywiście bardzo trudne, bo jak przewidzieć, jak rozwinie się dana technologia czy w jakim kierunku pójdą zmiany w samym projekcie? Albo jak odpowiedzieć na podstawowe pytanie – jaką technologię wykorzystać?

Zwykle to zespół implikuje wybór technologii. Przy pomocy specjalistów od aplikacji MVC nie zrobimy trudnego projektu w technologiach serverless (to znaczy jest to, rzecz jasna, możliwe, ale gwarancja dowiezienia działającego rozwiązania jest minimalna). Oczywiście może się okazać, że to klient narzuca technologię – wtedy rolą architekta jest uświadomienie mu konsekwencji tego wyboru.

Trudniejsze nie znaczy lepsze. Architekt musi zdawać sobie sprawę ze środowiska, w którym pracuje, z wymagań klienta, a przede wszystkim z tego, co jest priorytetem – dowiezienie MVP, zapewnienie fantastycznej jakości, a może genialnej architektury? Zadaniem architekta jest podjęcie decyzji: czy idziemy prosto do celu czy może nieco wolniej, ale z założeniem, że wybrana droga opłaci się później.

Jak to osiągnąć?
  • Zrozum kontekst biznesowy. Współpracuj z klientem, analitykiem biznesowym, project managerem, product ownerem, UXem… Generalnie współpracuj z każdym, kto jest w stanie przedstawić perspektywę potrzeb klienta. Często te potrzeby będą wpływać na wybór technologii, a nawet architekturę rozwiązania.
  • Pomóż w zestawieniu zespołu (jeśli masz taką możliwość).
  • Poznaj członków zespołu, porozmawiaj z nimi o ich doświadczeniu. Jeśli projekt trwa już od jakiegoś czasu, zapytaj o ich opinię na temat wybranej wcześniej technologii. Czasem może się okazać, że umiejętności zespołu nie pozwalają na efektywną pracę – wtedy należy podjąć jakieś kroki: można zasugerować zmianę technologii lub próbować aktywnie działać w celu podniesienia kompetencji zespołu w danym obszarze. Obie rzeczy są trudne, ale najgorsze to nie zrobić nic.
  • Fail fast. Jeśli architekt potrafi przetestować jakiś pomysł sam, by potwierdzić koncepcję w praktyce, to fantastycznie. Świetnym pomysłem jest zaangażowanie do takiej weryfikacji członka zespołu. W ten sposób można potwierdzić kompetencję zespołu w zakresie danej technologii.
  • Generalnie – prototypuj to, co może się nie udać lub to, w czym brakuje tobie lub zespołowi wiedzy albo przekonania, czy idziecie dobrą drogą.

Miękki przywódca


Prawdopodobnie większość architektów złapie się w tym momencie za głowę… Architekt ma być przywódcą? Liderem? Ale dlaczego? Solutions Architect jest od projektowania, a nie zarządzania ludźmi. Ale… to tylko częściowo prawda.

Oczywiście można sobie łatwo wyobrazić architekta wyłącznie w roli technologicznej wyroczni. Jednak taki architekt nie będzie miał łatwo. Być może będzie musiał współpracować z innymi architektami, devopsami z dużym doświadczeniem albo tech leadami z własną wizją. Być może w zespole będzie „zbyt dużo seniorów na metr kwadratowy”.

Wizja architekta zadziała tylko wtedy, gdy będzie mieć naturalny autorytet. Oczywiście konsultuje on swoje pomysły z zespołem, ale jednak chce też przekonać innych do swojej wizji, gdy istnieje wokół tego jakiś spór. Czasem powinien być autorytarny, żeby osiągnąć zamierzony cel. Często musi powiedzieć członkom zespołu, że idą w złą stronę i nie może mieć żadnych oporów, żeby tak zrobić. Do tych wszystkich rzeczy potrzebne są rozwinięte umiejętności miękkie, zwłaszcza te związane ze słuchaniem, podejściem koncyliacyjnym, dostrzeganiem potrzeb innych członków zespołu, realizacją ich ambicji. Tylko wtedy możliwe jest „przełożenie wajchy” bez konsekwencji – a więc np. autorytatywne podjęcie decyzji.

Nic z tego, co zamierza architekt, nie zadziała, jeśli nie będzie zwracać uwagi na komunikację, rzetelną, opartą na faktach argumentację, tłumaczenie swojej perspektywy, rozmowę. Widziałem mnóstwo konfliktów w zespołach spowodowanych silną ręką architekta, niezwracającego uwagi na to, że członkowie zespołu mają swoje wizje i ambicje. To prawie zawsze prowadzi do komunikacyjnej katastrofy, a w najgorszym razie do odejść ludzi z projektu lub nawet z firmy. I to tych najlepszych ludzi.

Architekci czasem tego nie lubią, ale to jest projektowy “must-have”. Architekt powinien być nie tylko technologicznym wizjonerem, ale także miękkim przywódcą – mistrzem komunikacji, ekspertem w słuchaniu potrzeb członków zespołu, geniuszem taktyki lawirowania pomiędzy różnymi, ścierającymi się wizjami.

Tak, to trudne. Nikt nie mówił, że będzie łatwo.

Jak to osiągnąć?
  • Rozmawiaj, rozmawiaj, rozmawiaj. To może się wydawać stratą czasu, ale nią nie jest. Autorytetu nie zbudujesz w oparciu o podejmowanie samych słusznych decyzji. Żeby wykazać słuszność decyzji potrzebujesz czasu, a autorytet musisz zbudować szybciej.
  • Jeśli coś idzie w złą stronę, powiedz o tym. Nigdy nie udawaj, że nic się nie dzieje. Pamiętaj, że technologicznie to ty jesteś najwyższą instancją.
  • Dostrzegaj potrzeby i ambicje członków zespołu. Może ktoś może ci pomóc w tym, co uważasz za swój obowiązek. Dla ciebie to obowiązek, a dla kogoś może być nobilitacja.
  • Jeśli uważasz, że trzeba coś zmienić, zrób to. Oczywiście zwykle trzeba to z kimś uzgodnić, porozmawiać z klientem, zespołem, project managerem. Ale nie wahaj się; brak zmiany (zakładając, że dobrze zdiagnozowałeś problem) może mieć ogromne konsekwencje.
  • Pokaż wyraźnie cel. Jeśli zespół widzi tylko problemy, to źle wróży. Zrób więc krok do tyłu, pomóż zespołowi sformułować MVP (jeśli to możliwe), zmień problemy w wyzwania i wesprzyj team w znalezieniu właściwej drogi.

 

Dołącz naszych Solutions Architektów

Gruboskórny wizjoner


Projekt to obszar ścierania się różnych interesów. Rzeczywistość bywa trudna, bo zdarza się, że klient ma nieco inny punkt widzenia niż project manager, tech lead czy w końcu developer. Architekt powinien się w tym odnaleźć i być swego rodzaju rozjemcą na froncie biznesu i technologii. Musi wziąć pod uwagę różne perspektywy, ułatwiać dzielenie się nimi i pomóc w znalezieniu rozwiązania.

Każdy z nas brał udział w niejednej dyskusji o jakości oprogramowania. Wszyscy chcielibyśmy robić porządnie – uwzględniać wszystkie dobre praktyki, mieć kod w pełni pokryty testami, pilnować wzorców projektowych itp. Nie zawsze jest to jednak możliwe, a blokerem bywa stricte biznesowa perspektywa klienta. A to oznacza zwykle “jak najszybciej” albo “jak najtaniej”. Powody mogą być różne, np. chęć szybkiego wyjścia na rynek albo ograniczony budżet. Powinniśmy to rozumieć. To w końcu pieniądze klienta, jego biznes i to on najlepiej wie, jakie ma ograniczenia.

Te rozbieżne perspektywy przekładają się zwykle na mikrokonflikty, którymi (znowu, jako architekci) powinniśmy umieć zarządzać. Tech lead i deweloperzy czasem narzekają, że nie mają czasu pisać testów. PM może być zainteresowany jakością kodu, ale czuje presję czasu ze strony klienta. Klient pyta architekta o najlepsze rozwiązania i nie chce słyszeć, że “szybciej się nie da”. Nasz bohater jest zwykle między młotem a kowadłem i lepiej, jeśli jest gruboskórny i dąży do celu, mimo oporów „materii”.

To wymaga nutki wizjonerstwa. Pamiętacie jak w „Potopie” Sienkiewicza Radziwiłł tłumaczył swoją zdradę i podpisanie traktatu z królem Szwecji? Otóż jego rzekomy plan wyglądał tak: poddamy Polskę Szwecji, Karol Gustaw na tronie podległej Polski usadowi Radziwiłła, a ten odbuduje siłę Rzeczpospolitej i wypędzi Szwedów. Abstrahując od tego czy historycznie takie były intencje Radziwiłła (nie, nie były) to może to być wzór dla architekta: musi on czasem poświęcić jedno, by zyskać drugie. Jeśli MVP pozwoli klientowi zarabiać pieniądze, to trzeba je dostarczyć, by potem walczyć o jakość.

To wszystko wiąże się z umiejętnością lawirowania pomiędzy naturalną tendencją zespołu do tworzenia rozwiązań wysokiej jakości, na które być może w danym momencie nie ma czasu (znacie to marzenie developera o tym, że “ten nowy projekt to będzie w końcu taki, że mucha nie siada i zrobimy wszystko tak jak trzeba”?), a koniecznością dostarczania działającego rozwiązania. Architekt będzie zmagał się czasem z krytyką ze wszystkich stron, ale powinien mieć dalekosiężną “perspektywę Radziwiłła” i nie może jej poświęcać dla krótkoterminowych korzyści.

Jak to osiągnąć?
  • Jeśli dla klienta najważniejsze jest dostarczenie rozwiązania w możliwie krótkim czasie, otwarcie mów o konsekwencjach, czyli np. o powstającym długu technologicznym, który trzeba będzie spłacić.
  • Zmodyfikuj wizję architektury w oparciu o kontekst biznesowy. Pokaż klientowi, co i w jaki sposób może osiągnąć, stosując różne podejścia.
  • Przygotuj długoterminowy plan. Jeśli na przykład planujesz, że najlepszym wyjściem będzie migracja do chmury, ale na razie jest to niewykonalne, ze względu na krótkoterminowe korzyści dla klienta, to pomyśl o tym już teraz. Przygotuj chociaż zarys koncepcji, jak to zrobić i koniecznie przedstaw go klientowi. To nie musi być plan doskonały. To nie musi być w ogóle plan sensu stricte. Może to być np. wysokopoziomowa koncepcja docelowego rozwiązania. Dziurawa, niepełna, ale taka, która pomoże przyjąć jakiś kierunek.
  • Jeśli już zespół musiał pójść na skróty, pilnuj, żeby to nie stało się normą. I pamiętaj o tym, że likwidacja długu technologicznego to zazwyczaj nie jest jednorazowa operacja, tylko powolna, żmudna praca. Uświadom zespół, że boy scout rule dotyczy wszystkich. To jest oczywiście w pierwszym rzędzie odpowiedzialność tech leada, ale nie znaczy to, że architekt nie powinien go w tym wspierać.

Odpowiedzialne wsparcie


Mówimy czasem, że w projekcie należy ustalić ścisły podział odpowiedzialności. Np. kto jest odpowiedzialny za release. Uzgadniamy nie tylko to, kto jest za to odpowiedzialny (w sensie firmowania tego swoim nazwiskiem), ale też, kto to fizycznie wykona i sprawdzi efekty (pomijając oczywisty aspekt, że musimy zdefiniować czym to “to” w zasadzie jest). Na końcu za powodzenie projektu odpowiedzialny jest oczywiście cały zespół.

Ale wiecie co? Dla klienta i PMa z punktu widzenia technologicznego widoczny jest przede wszystkim architekt. Jeśli sobie to uświadomimy, to szybko dostrzeżemy, że mimo precyzyjnie sformułowanej macierzy RACI to właśnie na architekcie będzie ciążyć duża część odpowiedzialności za procesy w projekcie i za projekt jako taki. Architekt może próbować zrzucić pewne ciężary ze swoich barków, ale z przykrością informuję, że będzie to działać wyłącznie do pierwszej porażki. Potem odpowiedzialny – i za tę porażkę, i za kontynuację – będzie tylko architekt. Zawsze łatwiej znaleźć jednego kozła ofiarnego.

Dlatego dobrze, jeśli w projekcie architekt przyjmuje postawę odpowiedzialnego wsparcia. Nie odcina się od problemów członków zespołu, wspiera ich nie tylko w obszarze realizacji zadań, ale także w rozwoju technologicznym. Umie dostrzegać słabe punkty zespołu, nazywać potencjalne zagrożenia i starać się je proaktywnie eliminować. Innymi słowy, architekt na bieżąco dokonuje analizy ryzyka w kontekście technologii i współpracy członków zespołu. Interweniuje również tam, gdzie być może nie leży jego odpowiedzialność. Nie ignoruje zatem potencjalnych lub istniejących problemów.

Jako się rzekło – cokolwiek pojawi się w macierzy RACI, to i tak architekt jest odpowiedzialny za powodzenie technologiczne projektu.

Jak to osiągnąć?
  • Znowu – rozmawiaj, rozmawiaj, rozmawiaj. Świetna komunikacja w zespole bardzo ci pomoże.
  • Wspieraj członków zespołu w rozwoju. To wsparcie może być oczywiście bardzo różne, ale im lepszych masz ludzi w zespole, tym łatwiej będzie ci realizować swoją wizję architektury (nieoderwaną od potrzeb klienta, rzecz jasna).
  • Nie bój się wyzwań. Nie tylko wyzwań dla ciebie, ale też dla zespołu. Często to właśnie trudne zadania powodują, że ludzie chętnie się uczą i rozwijają dla dobra projektu.

Członek zespołu


To brzmi banalnie, ale wcale takie nie jest. Architekci, przez charakter swojej pracy, mają tendencję do odcinania się od codziennej pracy zespołu. Zazwyczaj wynika to z tego, że większość czasu poświęcają na wysokopoziomowe projektowanie i rozmowy z klientem, a niekiedy z tego, że mają zbyt mało czasu na udział w projekcie. Bywa, że niewielki udział architekta w pracy z zespołem wynika z czynników obiektywnych i wtedy trzeba iść na kompromis.

Jeśli się da – pracuj z zespołem. Integruj się, bierz odpowiedzialność za niskopoziomowe zadania, wspieraj swoich kolegów, dziel się wiedzą, bądź dla nich wsparciem. Tak właśnie buduje się autorytet. A musisz go zbudować, żeby móc któregoś dnia przyjść i walnąć pięścią w stół. Żeby bez konsekwencji dla siebie móc powiedzieć komuś wprost, że robi złą robotę. Żeby wszyscy słuchali uważnie, kiedy będziesz mówić, że wizja zespołu prowadzi projekt na manowce i trzeba natychmiast skręcić w innym kierunku.

Jeśli projekt realizowany jest w technologii, której nie znacie, to nic straconego. Praca “hands-on” nie jest niezbędna (choć polecam przyjęcie roli “kaczuszki”, wasze doświadczenie na pewno pomoże rozwiązać problem). Za to niezbędne jest wsparcie, bycie przy releasach, rozumienie procesów i tłumaczenie ich. Czasem architekt jest w projekcie tylko na małą cząstkę etatu i wtedy praca z zespołem jest trudna, jeśli nie niemożliwa. Bywa. Ale nie znaczy to, że w takiej sytuacji architekt jest skazany na porażkę. Po prostu w takim układzie odpowiedzialności będą inaczej rozłożone.

Człowiek-orkiestra


Te wszystkie aspekty pracy architekta powodują, że klient może spać spokojnie. Architekt daje mu poczucie bezpieczeństwa i zajmuje się wszystkimi problemami. Klient nie będzie musiał robić po nocach researchu, żeby sprawdzić, czy zespół zaproponował technologię, która się sprawdzi. Nie będzie musiał bać się o to, czy za siedem sprintów nie trafi na dywanik CFO, bo koszty AWS urosły do astronomicznych rozmiarów. Będzie miał poczucie kontroli – nawet, jeżeli nie udało się dostarczyć precyzyjnie wszystkich wymagań.

Życie architekta nie jest proste i nikt nigdy nie twierdził, że takie jest. Architekt to człowiek-orkiestra. Zarówno pod kątem technologicznym jak i (co niezwykle ważne) pod kątem umiejętności miękkich. Powinien mieć ogromne doświadczenie, które umie właściwie wykorzystywać, by doprowadzić projekt do szczęśliwego końca. Last but not least, architekt powinien zdawać sobie sprawę z własnych słabości, bo ta pokora pomoże mu zbudować autorytet, zdobyć zaufanie zespołu i zrealizować to, co sobie zamierzył.

 

Masz pytania albo uwagi?

Napisz do Krzyśka TUTAJ.

 

Najnowsze wpisy