28 listopada 2016
Maciej Wilmiński
Zwinny architekt? Empatyczny i programujący!
Elita
Prestiż, autorytet, duża wiedza i doświadczenie, wysokie zarobki – z tym przede wszystkim kojarzy się stanowisko Architekta Oprogramowania – przez wielu odbierane jako niezwykły splendor, ukoronowanie kariery programistycznej, dowód przynależności do elity IT.
Ciekawe jest, że przez lata nie stworzyliśmy jednolitej definicji tego, czym jest istota tego stanowiska, czym osoba je piastująca powinna się zajmować. Oczywiście, ponad ogólnikowe przekazanie jednej osobie wyraźnej decyzyjności i odpowiedzialności w zakresie – nomen omen – architektury całego systemu informatycznego, nad którym codziennie pracujemy, bądź jego wycinku.
Jak powinna wyglądać rola architekta oprogramowania w środowisku agile? Gdzie powinny być umiejscowione osoby pełniące takie role – w zespołach czy poza nimi? A może w ogóle w agile’owym, egalitarnym środowisku zespołów deweloperskich nie powinniśmy takiej roli wyróżniać?
Ile firm, tyle pomysłów
Na początek przyjrzyjmy się jak w praktyce wyglądają w Polsce obowiązki architekta oprogramowania. Prawda jest taka – ile firm – tyle pomysłów, a w zasadzie potrzeb i prób ich zaadresowania. Architekci to dobro każdej firmy, które zawsze jest w deficycie. To też i różni ludzie. Jedni trafili na to stanowisko ze względu na ogromną wiedzę techniczną i doświadczenie, inni z kolei wyróżniali się tym, że ponadstandardowo wykonywali swoje obowiązki programistyczne, chcieli się rozwijać, mieli solidne zaplecze techniczne i dbali nie tylko o swój wycinek pracy, ale i wszystko wokoło. Innymi słowy – było widać, że im zależy, że „rokują”.
Co trzeba podkreślić, to rola wymagająca nieustannego samorozwoju, gonienia przysłowiowego króliczka, ale i zarazem dużej odporności psychicznej – wielka moc, to bowiem zawsze wielka odpowiedzialność. Stresy związane z wdrażaniem czy konieczność nie tylko odbierania nieprzyjemnych telefonów o różnych dziwnych godzinach, ale i wykonania działań doprowadzających do rozwiązania problemów – to częsta codzienność architektów.
Gdzie mamy wspólny mianownik, zadania, założenia które praktycznie zawsze są częścią tej roli? Przede wszystkim w koncepcji, że to stanowisko całkowicie samodzielne. Co poza tym, jeśli chodzi o zakres zadań/obowiązków, powtarza się najczęściej:
- nadzór nad utrzymaniem, a przede wszystkim rozwojem bazy kodu,
- nieustanne poszukiwanie innowacyjności, wyznaczanie kierunku ulepszeń, rozwoju systemu,
- spoglądanie na cały system z “lotu ptaka”, dbanie o spójność, bezpieczeństwo, wydajność, wytwarzanego oprogramowania – standardy, idee, zasady,
- wykonywanie review kodu.
To chyba sprawy najważniejsze. Spektrum pozostałych obowiązków bywa doprawdy zdumiewające. Zdarzało mi się widzieć architektów – będących zarazem przełożonymi programistów, architektów – Scrum Masterów czy architektów – menedżerów projektu, odpowiadających nie tylko za wizję ich architektury ale i podział pracy, terminy, przydział osób…. Spotkałem i takich, których praca polegała na opracowaniu UML-owych diagramów i dopilnowaniu, aby programista (czy w tej sytuacji faktycznie programista?) zaimplementował je według tego zamysłu. Ba, niejednokrotnie widziałem, że taki architekt funkcjonował w innym mieście niż deweloper. Zero komunikacji bezpośredniej. Mail, komunikatory i nieznoszące sprzeciwu decyzje – ma być tak jak na diagramie.
W klasycznym modelu kaskadowym architekt często był pierwszym emisariuszem IT wyznaczonym do rozmów z biznesem. Analizował, opiniował projekty – tłumaczył co się da, a przede wszystkim czego się nie da zrealizować. Był więcej niż posłem IT, był wojownikiem, który otwierał bitwy między biznesem, a IT, które z czasem przyjęły nazwy projektów.
Często był też głównym odpowiedzialnym za tak zwaną ekspercką wycenę projektów, co z reguły przysparzało mu dozgonne “uwielbienie” wśród rzeczywistych wykonawców, którzy stawali przed zadaniem implementacji z góry ustalonych pomysłów w odgórnie założonym czasie.
Tak, nie było łatwo.
Jak wyobrażam sobie to w wersji Architekci 2.0. – wersja zwinna? Zacznijmy od dwóch, moim zdaniem, najistotniejszych cech. Przede wszystkim jeśli architekt, to…
Tylko programujący!
Był taki moment, że moje programistyczne wysiłki zostały docenione. Zaproponowano mi stanowisko architekta. Hurraaa! Jednym z ważniejszych zdań, jakie wówczas usłyszałem było: nie będziesz już musiał programować. Wtedy, wydawało mi się to fantastycznym pomysłem i byłem tą wizją zachwycony. Dość powtarzalności, nużącego pisania oczywistego kodu, który, no cholera, sam nie chce się napisać… Co napisałem to napisałem, pozostaje w repozytorium jako wzorzec do podziwiania. Teraz w końcu można spokojnie zająć się wyższymi celami, resztę zostawiając programistom. Dziś wiem, że nieprogramujący architekt to najgorsza z możliwych opcji!!
Po pierwsze – sam byłem zaskoczony jak szybko zaciera mi się wiedza o pewnych systemowych kruczkach, tipsach, rozwiązaniach. W jakiej klasie znajduje się dana funkcjonalność, gdzie szukać danej metody, gdzie znajduje się dispatcher, jak działa ten cholerny connector…. Na kolejnych review kodu coraz więcej czasu spędzałem na zaglądaniu do kodu, który kiedyś znałem na pamięć. Niepokojących sygnałów było coraz więcej. Hmm, a co robi w ogóle ta metoda? A co to za dziwny parametr? Zaraz, zaraz, jak to w ogóle zostało zrobione? O co tu w ogóle chodzi… Po roku miałem problemy z implementacją naprawdę banalnych funkcjonalności korzystając z firmowego frameworka. Nawet jeśli wydaje Ci się, że masz pamięć słonia, erozja wiedzy o kodzie jest w tym przypadku nieunikniona. Nie oszukujmy się.
Po drugie – co jest konsekwencją powyższego, ciężko doradzać dobrze, będąc daleko od obszaru, którego rady dotyczą. Łatwo można oderwać się od rzeczywistości, tworząc idealistyczne plany, wymuszając nierealne rozwiązania. To tu jest źródło słynnego powiedzonka o architektach w “wieżach z kości słoniowych”. Deweloperzy przychodzą do nich, bo muszą. Wysłuchają, pokiwają głową z uznaniem, po czym pójdą i zrobią swoje… Tak, też wpadłem w tę pułapkę…
Nawet jeśli na danym systemie zjadłeś zęby, pamiętaj że zjadłeś je pracując w nim w latach 1945-89, tymczasem jest już 2016, minęło 27 lat, kod nie stał w miejscu. Twoje rady są oderwane od rzeczywistości!
Przeczytałeś fajny artykuł o nowym, fantastycznym frameworku? Sprawdź go sam! Poczuj na własnej skórze z czym się wiąże jego użycie, jak to się je. Czy to faktycznie ma sens…
Co więcej – nie ma lepszego sposobu na znalezienie wąskich gardeł, problemów w systemie, miejsc do ulepszenia, niż samodzielne, częste mierzenie się z jego meandrami. Nie należy bazować tylko na wysłuchiwaniu litanii narzekań (albo i propozycji) od innych na licznych spotkaniach…
Jest z tym wszystkim jeszcze jeden zasadniczy problem. Często architekci są tak mocno zawaleni, przygnieceni innymi obowiązkami, że nie mają czasu na pisanie kodu. Zadbajmy o to, żeby było inaczej!
Kompetencje miękkie!
Kolejna ważna sprawa to odpowiednie kompetencje miękkie. Tak, tak, rewolucja w IT dotarła i tutaj. Koniec z naburmuszonymi guru, gardzącymi wszystkimi, do których muszą wypowiadać więcej niż jedno słowo dziennie. Koniec z osobnymi pomieszczeniami do których można się dostać tylko w ściśle wyznaczonych godzinach celem możliwości obcowania z Najwyższym i uzyskaniem możliwości oświecenia, o ile nie zdenerwowało się wcześniej Najwyższego nieodpowiednim pytaniem. Może i niektórzy programiści przesadzają w swoich opowieściach, ale chyba każdy kto pracuje w IT dłużej niż 5 lat, wie o czym mowa. Trochę świadomie tu koloryzuję i podkręcam temat, ale jednak przyznajmy to – większość architektów przywykła do autorytatywnych, samodzielnych decyzji wysłuchiwanych z należytą nabożnością.
Jak już wspominałem, o awansie na stanowisko architekta decydowała przede wszystkim wiedza techniczna, niespecjalnie analizowano czy dana osoba będzie dobrze współpracowała z biznesem czy z innymi programistami. Ba, w przypadku biznesu często traktowano to jako zaletę. Sam pamiętam jak z dumą patrzyłem na kolegę pacyfikującego pomysły biznesu z siłą tsunami. Nikt nie śmiał się mu sprzeciwić. Na wszystko miał gotowe argumenty, był niezwykle pewny siebie, nie pozwalał zbić się z tropu, ani zapędzić w kozi róg. W razie czego, po prostu zakrzykiwał interlokutorów. Triumfalnie wracaliśmy ze spotkania. Będzie po naszemu!
Podobnie było zresztą z obsadzeniem stanowisk menedżerskich w IT. Powstały więc tu i podobne problemy. A nierzadko i patologie, które może nie były codziennością, ale jednak się zdarzały.
Buta, arogancja, pycha, samouwielbienie, dyktatura i zasady rodem z “Dyscypliny” śpiewanej przez Emiliana Kamińskiego w “Panu Kleksie w Kosmosie” z naczelnym Białe dlatego bywa czarne, bo ja je tak nazwałem – to epitety nieraz słyszane na różnych programistycznych spotkaniach z architektami.
Oczywiście o postawie takiej nie może być mowy w agile’owym środowisku pracy. Musi nastąpić przejście z dyktowania, narzucania ku wspieraniu. Konieczna jest empatia i zrozumienie, albo przypomnienie sobie programistycznego znoju. Architekci muszą nauczyć albo przypomnieć sobie, jak słuchać. Mieć anielską cierpliwość. Uczyć. Wspierać. Współpracować.
Istotne jest także zrozumienie biznesowych celów. Brak zacietrzewiania się na najdziwniejsze pomysły Product Ownerów. Cierpliwość w tłumaczeniu, umiejętność dobrej komunikacji, argumentacji niezanieczyszczonej informatycznym żargonem. Chęć współpracy, kooperacji, a nie walki.
Jeżeli nasi architekci mają wieloletnie doświadczenia i przyzwyczajenia waterfallowe – pokażmy im zasady pracy i architektury w środowisku zwinnym. Poświęćmy na to odpowiednią ilość czasu – to naprawdę niełatwe. Koncepcje “walking skeleton”, MVP, MMP, Lean Startup, Lean Programming, eXtreme Programming – to podstawy, które trzeba poznać.
Większość z architektów nie musi zatem nic zmieniać, bo wszystkie te cechy posiada. Ale niektórym przyda się wsparcie w zakresie rozwoju miękkich kompetencji. Zadbajmy o to. Scrum Masterzy – do roboty!
W zespole czy poza nim
Czy architekci powinni wchodzić w skład zespołów deweloperskich? Cóż, zazdroszczę firmom, które mają możliwość pozwolenia sobie na taki komfort. Idealnie byłoby mieć w każdym zespole architekta. Który pracuje, programuje wspólnie z zespołem. Ale wnosi swoją wiedzę ekspercką, kompetencje analityczne, doświadczenie. Taka osoba musi jednakże pilnować się, aby nie ulec pokusie zdominowania zespołu. Idealnie, aby przyjęła rolę coacha. Technicznego trenera dla zespołu, działającego trochę na zasadzie technicznego Scrum Mastera. Dyskretne wsparcie, nakierowanie, a nie dawanie gotowych rozwiązań. A to już nie oszukujmy się – wyższa szkoła jazdy. Wsparcie Scrum Mastera mile widziane.
Oczywiście w wyżej wspomnianym przypadku, konieczne jest wspólna praca wszystkich architektów poza zespołami, dbanie o jednolitą, spójną wizję. Regularne spotkania, wymiana wiedzy, rozwój w ramach specjalizacji.
Częstszym przypadkiem jest jednak wspomniany już niedobór architektów w organizacji. Co wówczas jest najistotniejsze – nie pozwólmy im oddalić się od kodu. Niech tworzą komponenty, wysokopoziomowe rozwiązania, z których mogą korzystać inne zespoły. Niech nie tylko teoretycznie wyznaczają kierunki, dbają o spójność w ramach całej organizacji ale i tworzą, chociażby zręby kodu, które je wyznaczają. Niech stanowią też źródło wsparcia dla zespołu w kluczowych decyzjach. Oczywiście trzeba tu uważać na pułapkę zabierania przez takich architektów dla siebie wszystkich najważniejszych, najtrudniejszych tematów, przez co może zabraknąć wyzwań dla deweloperów. Którzy wszakże je uwielbiają, prawda? Jest tu też pułapka niepoprawiania bugów przez architektów, zgonie ze starą maksymą O wielkie rzeczy bogowie się troszczą, o małe nie dbają.
A może bez sensu?
Gdzieniegdzie można napotkać sugestie pozbycia się roli architekta w zespołach Scrumowych. W zamian proponowane jest przyjęcie zasady “rotacyjnego architekta” – co jakiś czas rolę tę w zespole pełni inna osoba, dbając o zgodność z firmowymi standardami czy podejmując kluczowe decyzje. Powiem krótko – nie wierzę w takie rozwiązanie. I nie mam zamiaru poświęcać mu więcej tekstu.
Podsumowanie
Empatyczny, programujący architekt – trener, do tego dążymy. Dobrze rozumiejący problemy współczesnego biznesu, presję szybkiego dostarczania na rynek, zasady zwinnej architektury, nie zapominający jak to jest być programistą.
Patrzący na całokształt wytwarzanego systemu, bądź systemów z lotu ptaka. Dbający o jego spójność i rozwój. Nieustannie się doskonalący. Pełen energii i zapału. Zarażający entuzjazmem. Autorytet. Architekt Oprogramowania.