Architekt rozwiązań. Wizja osobista.

Kto dokładnie jest architektem rozwiązań? Intuicyjnie, każdy ma swoją własną definicję. W większości przypadków definicje te są niepełne i zależą od tego, czego wymaga dany projekt. Kiedy rozmawiam z kierownikami projektów, liderami technicznymi, programistami, klientami czy analitykami biznesowymi, to wygląda to na architekta jako zespół jednoosobowy. Ktoś, kogo wiedza, doświadczenie, elastyczność i odpowiedzialność mogą być wykorzystane do łatania wszystkich dziur w projekcie, zarówno tych związanych z procesami, jak i tych wynikających z braku kompetencji czy problemów komunikacyjnych.

Każdy projekt jest inny i w każdym z nich odpowiedzialność architekta może być różnie rozłożona. Czasami architekt pracuje razem z zespołem, często dostarczając kod. Czasami jest to praca na wysokim poziomie związana z koncepcjami architektonicznymi i określeniem ścieżki, którą projekt ma podążać w dziedzinie technologii. W rzeczywistości zaangażowanie architektów jest produktem ich charakteru, potrzeb ich zespołu i definicji projektu.

Różne wizje architekta rozwiązań są doskonale uzasadnione i trudno jest sprowadzić je do wspólnego mianownika. Architekt może jednak pomóc sobie i projektowi, jeśli jest świadomy pewnych aspektów swojej pracy.

Jasnowidz technologiczny

Architekci zazwyczaj koncentrują się na bieżących wyzwaniach projektu; rozwiązują nierozwiązywalne problemy i planują przyszłe działania. Nie powinni jednak zapominać o biznesowych wyzwaniach technologicznych i nie mogą tracić z oczu tego, co ma się wydarzyć. Jest to oczywiście bardzo trudne, bo trudno przewidzieć, jak będzie się rozwijać dana technologia, jak będą się kształtować zmiany w samym projekcie, a co najważniejsze, z jakiej technologii skorzystać.

Zazwyczaj jest to zespół, który wybiera technologię. Z pomocą specjalistów od aplikacji MVC nie zrealizujemy trudnego projektu w technologiach bezserwerowych. I nawet jeśli jest to technicznie możliwe, nie możemy zagwarantować, że dostarczymy działające rozwiązanie. Oczywiście może się okazać, że klient narzuci technologię, a jeśli tak, to rolą architekta jest uświadomienie klientowi konsekwencji takiego wyboru.

"Trudniejsze" nie oznacza "lepsze". Architekt musi być świadomy środowiska, w którym pracuje, wymagań klienta, a przede wszystkim tego, jakie są jego najważniejsze priorytety: czy dostarcza on MVP, zapewniając fantastyczną jakość, czy może genialną architekturę? Zadaniem architekta jest podjęcie decyzji, czy projekt powinien być wykonany od razu, czy może jego realizacja powinna zająć trochę więcej czasu, przy założeniu, że ten ostatni w końcu się opłaci.

Jak to zrobić?

  • Zrozumieć kontekst biznesowy. Współpracować z klientem, analitykiem biznesowym, kierownikiem projektu, właścicielem produktu, UX-em itp. Innymi słowy, pracować z każdym, kto może przedstawić perspektywę potrzeb klienta. Potrzeby te często będą miały wpływ na wybór technologii, a nawet architektury.
  • Pomóż stworzyć zespół (jeśli jest to możliwe). Spotkaj się z członkami zespołu, porozmawiaj z nimi o ich doświadczeniach. W przypadku projektów w trakcie realizacji, poproś ich o opinię na temat wybranej technologii. Czasami może się okazać, że umiejętności zespołu nie pozwalają mu na efektywną pracę. Jeśli tak, to podejmij pewne działania. Zaproponuj np. zmianę technologii lub postaraj się poprawić kompetencje zespołu w danej dziedzinie. Oba rozwiązania są trudne, ale najgorsze jest nie podejmować żadnych działań. Szybko zawodzą. Jeśli architekci mogą sami przetestować niektóre pomysły, aby potwierdzić je w praktyce, to fantastycznie. Ale jest to również świetny ruch, aby zaangażować członków zespołu w takie testy. W ten sposób rozwijają się kompetencje zespołu związane z konkretną technologią.
  • Przewiduj, co może pójść źle lub gdzie Tobie lub Twojemu zespołowi brakuje wiedzy lub przekonania, że idziesz właściwą drogą.

Miękki lider

Większość architektów pewnie będzie teraz zaskoczona... Architekt jako lider? Liderem? Dlaczego? Zadaniem architekta rozwiązań jest projektowanie, a nie zarządzanie ludźmi. Ale ty jesteś w połowie w porządku.

Oczywiście, łatwo sobie wyobrazić, że architekci są tylko autorytetem w dziedzinie technologii. Jednak tacy architekci nie będą mieli łatwo. Być może będą musieli współpracować z innymi architektami, twórcami oprogramowania z dużym doświadczeniem lub technicznymi przewodnikami z własną wizją. Być może w zespole będzie zbyt wielu seniorów na metr kwadratowy.

Wizja architekta będzie działać tylko wtedy, gdy będzie miał naturalny autorytet. Oczywiście, omawiają swoje pomysły ze swoim zespołem, ale chcą też przekonać innych, jeśli ich wizje są kontrowersyjne. Czasami powinni być bezkompromisowi i władczy, aby osiągnąć swoje cele. Często muszą powiedzieć swoim członkom zespołu, że się mylą i nie mogą być niechętni. Aby to zrobić, potrzebują wysoko rozwiniętych umiejętności miękkich i podejścia pojednawczego. Muszą umieć uważnie słuchać innych członków zespołu, dostrzegać ich potrzeby i realizować swoje ambicje. Tylko wtedy możliwe jest dokonanie znaczącej zmiany (np. podjęcie autorytatywnej decyzji) bez negatywnych konsekwencji.

Nic, co zamierzają zrobić architekci, nie zadziała, jeśli nie będą zwracać uwagi na rzetelną komunikację, argumenty oparte na faktach, wyjaśnianie własnej perspektywy czy rozmowę. Widziałem wiele konfliktów w zespołach spowodowanych przez architekta, który był zbyt dominujący i nie zwracał uwagi na to, że członkowie zespołu mają swoje własne wizje i ambicje. Prawie zawsze prowadzi to do katastrofy komunikacyjnej, a kiedy najgorsze przychodzi do najgorszego, do opuszczenia projektu lub nawet firmy przez pracowników, również tych najlepszych.

Architektom się to nie podoba, ale jest to projekt "must-have". Powinni być nie tylko technologicznymi wizjonerami, ale także miękkimi liderami, mistrzami komunikacji, ekspertami w słuchaniu członków zespołu, geniuszami w manewrowaniu pomiędzy różnymi, często zderzającymi się wizjami.

Tak, to jest trudne. Ale nikt nie powiedział, że to będzie łatwe.

Jak to zrobić?

  • Rozmawiać, rozmawiać, rozmawiać. To może wydawać się stratą czasu, ale tak nie jest. Władza nie może być ustanowiona w oparciu o podejmowanie właściwych decyzji. Aby udowodnić słuszność swoich decyzji, potrzebny jest czas, a władza musi być ustanowiona z dużym wyprzedzeniem. Jeśli coś pójdzie nie tak, powiedz to.
  • Nigdy nie udawaj, że nic się nie dzieje. Pamiętaj, że jeśli chodzi o technologię, to ty jesteś najwyższym autorytetem. Rozpoznawaj potrzeby i ambicje członków zespołu. Może ktoś pomoże ci w tym, co czujesz, że jest twoim obowiązkiem. Dla ciebie jest to odpowiedzialność, ale dla kogoś innego może to być nobilitacja.
  • Jeśli uważasz, że coś trzeba zmienić, zrób to. Oczywiście, należy to uzgodnić z innymi, porozmawiać z klientem, zespołem, kierownikiem projektu. Ale nie wahajcie się podejmować działań, ponieważ brak zmiany - zakładając, że problem został poprawnie zdiagnozowany - może mieć daleko idące konsekwencje.
  • Wyraźnie pokaż cel. To zły znak, że zespół nie widzi nic poza problemami. Więc zrób krok do tyłu, zamień problemy w wyzwania, pomóż swojemu zespołowi sformułować MVP (jeśli to możliwe) i znaleźć właściwą drogę.

Wizjoner o grubej skórze

Projekt jest obszarem, w którym spotykają się różne interesy. Rzeczywistość może być trudna, gdy klient ma nieco inny punkt widzenia niż kierownik projektu, lider techniczny czy deweloper. Architekci powinni do niej podchodzić mądrze i działać jak rozjemca pomiędzy biznesem a technologią. Muszą rozważać różne perspektywy, ułatwiać dzielenie się nimi i pomagać w znalezieniu rozwiązania.

Każdy z nas uczestniczył w wielu dyskusjach na temat jakości oprogramowania. Wszyscy chcielibyśmy zrobić to we właściwy sposób: stosować wszystkie dobre praktyki, przeprowadzać testy, przestrzegać wzorców projektowania, itp. Nie zawsze jest to jednak możliwe, ponieważ powstrzymuje nas ścisła perspektywa biznesowa klienta. "Perspektywa biznesowa" oznacza zazwyczaj "jak najszybciej" lub "tak tanio, jak to możliwe". Przyczyny takiego podejścia mogą być różne, ponieważ czasami jest to chęć szybkiego wejścia na rynek, czasami jest to ograniczony budżet. Powinniśmy to zrozumieć. W końcu to pieniądze klientów, ich biznes, a oni najlepiej wiedzą, jakie są ich ograniczenia.

Te rozbieżne perspektywy zwykle prowadzą do mikrokonfliktów, z którymi architekci powinni być w stanie sobie poradzić. Liderzy techniczni i deweloperzy czasami skarżą się, że nie mają czasu na przeprowadzanie testów. Kierownicy projektów mogą martwić się o jakość kodu, ale czują się popychani przez swoich klientów. Klienci pytają architektów o najlepsze rozwiązania i nie chcą słyszeć o przeszkodach. Architekci są często łapani między diabłem a głębokim błękitem morza, więc lepiej jest, jeśli są gruboskórni i dążą do swoich celów bez względu na opór materii.

To wymaga odrobiny wizjonerstwa. Czy pamiętasz, jak książę Radziwiłł, postać z "Potopu", powieści historycznej Henryka Sienkiewicza, tłumaczył swoją zdradę i podpisanie traktatu z królem Szwecji? Cóż, jego plan był prosty: Polska podda się Szwecji, Karl Gustav umieści Radziwiłła na tronie Polski, potem książę odbuduje Rzeczpospolitą i wyrzuci Szwedów. Niezależnie od tego, czy były to prawdziwe intencje Radziwiłła (prawdę mówiąc, nie były), może to być lekcja dla architektów: czasami muszą poświęcić jedną rzecz, by zyskać drugą. Jeśli MVP pozwala klientowi zarobić pieniądze, to muszą być one dostarczone na czas, a ich jakość może być później poprawiona.

Wszystko to wymaga umiejętności manewrowania pomiędzy naturalną tendencją zespołu do dostarczania wysokiej jakości rozwiązania, na które w danym momencie może nie być wystarczającej ilości czasu, a koniecznością dostarczenia działającego rozwiązania. Wszyscy twórcy oprogramowania marzą o tym, aby zrealizować swój kolejny projekt dokładnie tak, jak planowano, ale takie marzenia rzadko się spełniają. Architekci czasami będą musieli zmierzyć się z krytyką ze wszystkich stron, ale powinni mieć na uwadze dalekosiężną perspektywę i nie wolno im poświęcać jej dla krótkoterminowych korzyści.

Jak to zrobić?

  • Jeśli dostarczenie jakiegoś rozwiązania w jak najkrótszym czasie jest dla Państwa klientów najważniejsze, należy otwarcie mówić o konsekwencjach, czyli o wynikającym z tego długu technicznym, z którym trzeba będzie się uporać. Zmodyfikuj wizję architektury w oparciu o kontekst biznesowy. Pokaż klientom, co i jak mogą osiągnąć, stosując różne podejścia. Sporządź długoterminowy plan. Na przykład, jeśli uważasz, że najlepszą opcją jest migracja do chmury, ale obecnie nie jest to możliwe ze względu na krótkoterminowe korzyści dla klientów, pomyśl o tym wcześniej. Przygotuj przynajmniej zarys koncepcji, jak to zrobić i przedstaw go swoim klientom. Nie musi to być doskonały plan. To wcale nie musi być plan ścisły. Może to być na przykład wysokopoziomowa koncepcja ostatecznego rozwiązania. Może być niedoskonały lub niekompletny, ale przynajmniej pokaże jakiś kierunek. Jeśli twoja drużyna musi pójść na skróty, upewnij się, że nie stanie się to normą. I pamiętaj, że radzenie sobie z długiem technicznym zwykle nie jest jednorazową operacją, ale powolnym, żmudnym procesem. Dajcie znać drużynie, że reguła harcerstwa dotyczy wszystkich. Jest to oczywiście główna odpowiedzialność liderów technicznych, ale nie oznacza to, że architekci nie powinni ich wspierać.

Odpowiedzialne wsparcie

Czasami mówimy, że obowiązki muszą być precyzyjnie podzielone w projekcie. Na przykład, należy wyznaczyć osobę odpowiedzialną za uwolnienie. Zgadzamy się nie tylko, kto użyczy swojego nazwiska do zwolnienia, ale także kto fizycznie wykona tę pracę i sprawdzi jej efekty. W końcu to cały zespół jest odpowiedzialny za powodzenie projektu.

Ale wiecie co? Z technologicznego punktu widzenia, klienci i kierownicy projektów zajmują się przede wszystkim architektami rozwiązań. Jeśli zdamy sobie z tego sprawę, szybko zauważymy, że pomimo precyzyjnie sformułowanej matrycy RACI, główna odpowiedzialność za procesy w projekcie i za sam projekt spoczywa na architektach. Mogą oni próbować zdjąć z siebie ten ciężar, ale będzie on działał tylko do czasu pierwszej porażki. Wtedy tylko architekt będzie odpowiedzialny zarówno za tę porażkę, jak i za dalszą pracę. Zawsze łatwiej jest znaleźć jednego kozła ofiarnego.

Dlatego też architekci powinni przyjąć postawę odpowiedzialnego wsparcia. Nie odcinają się od problemów członków zespołu, lecz wspierają ich nie tylko w wykonywaniu zadań, ale również w rozwoju technologicznym. Dostrzegają słabości zespołu, identyfikują potencjalne zagrożenia i starają się je eliminować. Inaczej mówiąc, architekci na bieżąco przeprowadzają analizę ryzyka w kontekście technologii i współpracy między członkami zespołu. W razie potrzeby wykraczają poza zakres swoich obowiązków. Dlatego nie ignorują potencjalnych lub istniejących problemów.

Jak już powiedziano, niezależnie od tego, co pokazuje matryca RACI, architekci są odpowiedzialni za technologiczny sukces projektu.

Jak to zrobić?

  • Powiem to jeszcze raz - mów, mów, mów. Skuteczna komunikacja zespołowa bardzo ci pomoże. Wspierać członków zespołu w ich własnym rozwoju. Oczywiście wsparcie to może przybierać różne formy, ale im lepiej Twoi koledzy z zespołu wykonują swoją pracę, tym łatwiej będzie Ci realizować swoją wizję architektury (oczywiście zgodnie z potrzebami klienta). Nie obawiaj się wyzwań, nie tylko dla Ciebie, ale i dla zespołu. Paradoksalnie, trudne zadania, które sprawiają, że ludzie chętnie się uczą i rozwijają dla dobra projektu.

Członek zespołu

Brzmi banalnie, ale nie jest taki. Architekci, ze względu na charakter swojej pracy, mają tendencję do dystansowania się od codziennej pracy swojego zespołu. Dzieje się tak zazwyczaj dlatego, że większość czasu spędzają na dostarczaniu projektów na wysokim poziomie i prowadzeniu rozmów z klientami. A czasami po prostu mają zbyt mało czasu, by uczestniczyć w danym projekcie. Co jakiś czas ich niski udział w wykonywaniu zadań z zespołem wynika z czynników obiektywnych, jeśli tak, to trzeba iść na kompromis.

Jeśli jest to możliwe, należy pracować z zespołem. Integrujcie się, bierzcie odpowiedzialność za zadania na niskim poziomie, wspierajcie swoich kolegów, dzielcie się wiedzą. W ten sposób tworzy się autorytet. Możesz go potrzebować, jeśli pewnego dnia będziesz musiał działać z przekonaniem lub powiedzieć komuś z bliska, że wykonuje złą robotę, albo sprawić, że wszyscy będą cię uważnie słuchać, gdy powiesz, że wizja zespołu prowadzi projekt na manowce i trzeba ją natychmiast zmienić.

Jeśli projekt jest realizowany przy użyciu technologii, której nie znasz, nic nie tracimy. Podejście "hands-on" nie jest konieczne, choć Twoje doświadczenie na pewno pomoże rozwiązać problem. Konieczne jest jednak zapewnienie wsparcia, pomoc w wydaniu, zrozumienie procesów i wyjaśnienie ich. Czasami zaangażowanie architekta w projekt jest pracą na pół etatu i wtedy praca z zespołem jest trudna, jeśli nie niemożliwa. Szkoda, że tak właśnie jest. Ale to nie oznacza, że w takiej sytuacji architekt jest skazany na porażkę. W takim przypadku obowiązki zostaną rozłożone inaczej.

Jednoosobowy zespół

Wszystkie wyżej wymienione aspekty pracy architektów sprawiają, że ich klienci dobrze śpią. Architekci dają im poczucie bezpieczeństwa i radzą sobie ze wszystkimi problemami, dzięki czemu nie muszą robić badań w nocy, aby upewnić się, że rozwiązania proponowane przez zespół będą działać. Nie muszą się też martwić, że będą musieli zgłaszać się do swoich CFO, ponieważ koszty AWS wzrosły astronomicznie. Mają poczucie kontroli, nawet jeśli nie wszystkie rozwiązania zostały dostarczone.

Życie architekta nie jest proste i nikt nigdy nie mówił, że jest. Architekt jest bardzo podobny do zespołu jednoosobowego, zarówno jeśli chodzi o umiejętności twarde, jak i miękkie, co jest niezwykle ważne. Powinien mieć duże doświadczenie i wiedzieć, jak mądrze z niego korzystać, aby z powodzeniem zrealizować projekt. I wreszcie, co nie mniej ważne, architekci powinni być świadomi swoich własnych słabości, ponieważ pokora pomoże im zdobyć autorytet, zdobyć zaufanie zespołu i zrobić to, co zamierzają zrobić.