Architekt oprogramowania jest jak reżyser filmowy

p.p1 {margin: 0.0px 0.0px 10.0px 0.0px; font: 11.0px 'Trebuchet MS'; color: #000000; -webkit-text-stroke: #000000} span.s1 {font-kerning: none} span.s2 {font-kerning: none; background-color: #ffff00}

Mój punkt widzenia dotyczący roli architekta oprogramowania (software architekt) jest nieco kontrowersyjny, więc będę się starał was do niego przekonać. 

Kim jest więc architekt oprogramowania? Zwykle widzicie architekta, jako osobę mająca wyższe zarobki niż programista, siedzącą na lepszym fotelu, w lepszym biurze. Jest to ktoś, kto jest obecny na wszystkich spotkaniach i ma tytuł ładnie wypisany na wizytówce. I tyle. Nawet, kiedy chcą was zatrudnić na takim stanowisku, nie tłumaczą, o jaką role tak naprawdę chodzi.

Z mojego doświadczenia wynika (a poznałem wielu architektów oprogramowania nie tylko z nazwy na wizytówce), że rola architekta polega na byciu tym członkiem zespołu, który podejmuje decyzje techniczne. To ta osoba, która także podpisuje się pod wszystkimi technicznymi decyzjami w trakcie realizacji projektu. Bez względu na to, jak zespół dochodzi do decyzji, skąd pochodzą dane, z iloma osobami trzeba się skomunikować, zawsze na końcu ktoś musi się podpisać pod tą decyzją. Jest to właśnie ta jedna osoba – architekt oprogramowania. Tak powinno to wyglądać. A ci wszyscy ludzie otaczający architekta? Mogą się komunikować między sobą, mogą wymieniać się informacjami, odbyć tyle spotkań, ile trzeba, a i tak to ta jedna osoba podejmuje ostateczne decyzje. 

To, co powiedziałem powyżej wydaje się być oczywiste, a jednak w wielu miejscach wcale się tak nie dzieje. W wielu przypadkach zespół podejmuje decyzje w drodze demokratycznej dyskusji i głosowania, a architekt, mimo, że jego głos jest traktowany jako ważniejszy, musi skupiać się głównie na przekonywaniu członków zespołu, kiedy przeważają głosy sprzeczne z jego własnym zdaniem. Nie powie im: „Zrobimy tak jak ja chcę i nie obchodzi mnie, że się z tym nie zgadzacie, bo to moja decyzja”. Raczej będzie się starał perswadować. Takiego sposobu nie pochwalam. 

Porównałbym rolę architekta oprogramowania do roli reżysera filmowego. Przy produkcji filmu angażuje się mnóstwo osób: kamerzyści, aktorzy, inwestorzy, producenci itp. Ale osobą, która podejmuje decyzje jest tylko reżyser, jak, podziwiany przeze mnie, Martin Scorsese. Jeśli film będzie dobrym filmem, wszyscy będą świętować sukces reżysera. Jednak będzie on także jedynym obwinianym, jeśli film okaże się kiepski. W takim wypadku nikt nie mówi, że to wina kamerzysty, albo aktorów. Zawsze obwiniany jest reżyser. Waśnie dlatego rola architekta powinna się opierać na dwóch fundamentach: na odpowiedzialności i na władzy

Pierwszy z nich to odpowiedzialność. Architekt, jak reżyser, jest w pełni odpowiedzialny za problemy i kłopoty projektu: czy będzie to kilka złych decyzji, czy błędy w kodzie, czy błędy w rozwiązaniach technicznych, czy zrobimy nieodpowiedni design, czy wreszcie źle zaplanuje się strukturę - za to wszystko obwinia się jedną osobą. Nigdy się nie mówi, że to wina zespołu, czy grupy osób. To wina jednej osoby. Ta właśnie osoba zostanie pociągnięta do odpowiedzialności i może zostać jakoś ukarana, na przykład zwolniona. Zupełnie oddzielna kwestia jest, z jakiej przyczyny doszło do powstania błędu. Może architekt nie zdołał uzyskać właściwych informacji, może nie był w stanie się komunikować z zespołem, może zatrudnił niewłaściwych programistów. Nie ważne. Ważne jest, że wszyscy wiemy, że odpowiedzialność za ten błąd ponosi „reżyser” projektu. 

Drugim fundamentem jest władza. Skoro odpowiedzialność za błędy i porażki projektu spada na tę jedną osobę, to do tej osoby naturalnie powinna należeć władza nad projektem. Architekt musi mieć władzę podejmowania wszelkich decyzji technicznych. Jeśli chcecie mnie obwiniać o zły wybór bazy danych, musicie mi najpierw pozwolić ją wybrać. Nie wyobrażam sobie, że zarzucamy architektowi, że projekt jest źle wyskalowany, bo baza danych nie jest wystarczająco szybka, a on mówi, że nie mógł podjąć innej decyzji, bo odbyło się głosowanie i zespół podjął decyzję wbrew jego woli. Kto wtedy ponosi odpowiedzialność? Taka sytuacja jest nie do zaakceptowania. Ostateczna decyzja musi należeć do architekta, więc musi on mieć pełnię władzy w kwestiach technicznych. To już nie jest gra zespołowa, tylko jednoosobowy ruch. Współpraca w zespole jest tu na niższym szczeblu niż rola lidera. Zadaniem architekta jest dobrać zespół tak, aby pracował dla niego. Architekt nie przychodzi do pracy, aby się zaprzyjaźnić z programistami, czy spędzić miło czas w biurze. Jego zadaniem jest osobiście stworzyć produkt. Jeśli ktoś zabiera się do tego z myślą, że jest tu tylko chwilowo i chodzi mu tylko o zarobienie większych pieniędzy zanim przeniesie się do innej firmy, to także nie pomaga projektowi.

 

Jaka jest struktura procesu?

W projekcie są cztery kluczowe role: architekt (osoba podejmująca decyzje techniczne), zespół (grupa programistów tworząca elementy projektu), kod źródłowy i system ticketowy (produkt, wraz z zapisem całego procesu tworzenia), oraz menadżer projektu (PM, nadzorujący przebieg tworzenia produktu). Ten ostatni elementem struktury, menadżer projektu, kontroluje czy wszyscy członkowie zespołu idą określoną drogą według ustalonych zasad zarządzania, czy są wynagradzani i czy nie rodzą się jakieś destruktywne konflikty. Jego rola nie jest przedmiotem tej prezentacji. 

Uważam, że bezpośrednie połączenie między architektem, a zespołem powinno stanowić bardzo cienką linię, albo nie powinno istnieć w ogóle. Według mnie, właściwa komunikacja architekta z zespołem powinna zawsze odbywać się przez produkt. Architekt nie powinien zajmować się uczeniem zespołu, ani treningiem, ani coachingiem, ani mentoringiem, ani nawet wyjaśnianiem. Te wszystkie działania chwilowo mogłyby wspomóc programistów, ale w dłuższej perspektywie, zabijają one projekt. Załóżmy, że jako architekt podjąłem decyzję o dużej zmianie, na przykład zmianie baz danych. Nie idę do zespołu, żeby jego członkom tłumaczyć, jaka to decyzja i dlaczego ją podjąłem. Tworzę ticket, w którym wyjaśniam decyzję i w ten sposób tworzę dokumentację zmiany. Wkładam ticket do repozytorium, więc zespół otrzymuje go i wie, czego chcę. Jeśli zależy mi na uzyskaniu opinii członków zespołu, także proszę ich przez tickets i przez repozytorium. Wstawiam swój kod i wyjaśnienie do repozytorium i zostaje to w dokumentacji historii projektu. Wszystko odbywa się przez repozytorium, zamiast normalnej komunikacji werbalnej. Chodzi o to, aby architekt był oddzielony od zespołu, a idąc w tym rozumowaniu dalej, uważam, że dobrym rozwiązaniem byłoby także oddzielanie programistów od siebie nawzajem.  Nie powinni oni pracować razem w tym samym pokoju. 

Produkt jest królem tego procesu. Nie architekt, nie programiści. Dlatego właśnie repozytorium jest takie ważne, ponieważ w nim znajduje się cała dokumentacja przebiegu tworzenia projektu. Tam znajduje się kod źródłowy, zmiany, nasze dyskusje i zadania. Jest to nasz główny produkt. Wszystko, co się dzieje po drodze przechodzi przez kod źródłowy i to jest najważniejsze dzieło, jakiego dokonujemy. Nie jesteśmy od trenowania się, od szkolenia i prowadzenia za rączkę. Architektowi płacą za wytworzenie lepszego i większego produktu. Nauka i rozwój, oraz wzrost motywacji to jedynie efekt uboczny procesu tworzenia produktu. 

 

Jak architekt ma się komunikować z zespołem?

Jak więc architekt ma się komunikować z zespołem i jak może wpływać na produkcję? W tej chwili realizujemy około 20 projektów, pracuje nas około 50 osób i wszyscy pracują zdalnie. Ja jestem architektem w kilku z nich. 

Stosuję dwa narzędzia komunikacji z zespołem. Pierwsze z nich to raport błędów (bug report). Podczas tworzenia produktu widzę, jaki wkład mają programiści, jak przebiega proces tworzenia produktu, a kiedy chcę coś zmienić, idę do bugtrackera i tworzę błąd (bug). Wprowadzam ten błąd, rejestruję go i wyjaśniam na czym polega, oraz jak go uniknąć w przyszłości. Przydzielam to jednemu z programistów, aby naprawił i w ten sposób produkt się rozwija, zaczyna iść inną drogą. Nie spotykam się z zespołem w większości wypadków, nie mówię im co mają zrobić, nie wygłaszam pogadanek i nikogo nie szkolę. Nie wyjaśniam niczego werbalnie. Tworzę na to dokument i uważam, że to dobry sposób. To tak jak w projektach open source.

Drugim narzędziem jest inspekcja kodu (code review). Kiedy wprowadzam błąd i ktoś zaczyna nad nim pracować, a potem ta osoba przysyła żądanie zmiany kodu (pull request), mam szansę na kształtowanie produktu. Patrzę na te proponowane zmiany i decyduję, czy zmieniać, czy nie. Czasem muszę to skomentować i poprawić tę osobę. Muszę sprawdzić, czy propozycje są dobre. Wpuszczam błąd, albo wiele błędów i tak właśnie tłumaczę, co jest źle i w którym kierunku musimy rozwijać produkt. Pokazuję, gdzie jesteśmy i gdzie chcemy dojść. Nie siedzę na spotkaniach i nie wygłaszam kazań. Patrzę na rozwiązania i informuję daną osobę, że to czy tamto jest źle i trzeba to poprawić. W ten sposób architekt staje się pewnego rodzaju technicznym dyktatorem projektu. 

Gdy jestem menedżerem projektu musiałbym kontrolować pracę architekta I trzymać rękę na pulsie. W tym celu zadaję mu trzy pytania. Pierwsze z nich dotyczy statusu wykonania (scope status) projektu. Architekt, jako główny wykonawca projektu, wie, w której fazie wykonania jesteśmy. Ile już zrobiono, a ile jeszcze musi być zrobione. Patrzy na projekt z wyższej platformy, niż pozostali.. 

Drugie pytanie, jakie bym mu zadał, to jakie mamy teraz problemy (issues), co nie idzie i co nie działa. Architekt posiada taką wiedzę, na przykład, że baza danych nie jest wyskalowana wystarczająco, że strona internetowa jest zbyt wolna, że kod jest wadliwy, że nie działa w XML itp. Albo, że używamy Javy 7, a powinniśmy używać Javy 6  w tym konkretnym procesie. 

Trzecie pytanie dotyczyłoby zagrożeń (risks). Architekt musi mieć szersze spojrzenie na produkcję i musi przewidzieć problemy, jakie zaistnieją w przyszłości. Co może nie pójść za miesiąc, za dwa, za rok? Baza danych jest teraz odpowiednio szybka, ale przewiduje się, że za pół roku, kiedy ruch będzie znacznie większy, będziemy mieli problem z wyskalowaniem jej i najpewniej spowolni. Taką informacje architekt musi przedstawić menadżerowi projektu. 

 

Kontrowersje

Niektórzy uważają, że ciężko jest pracować w takim zespole zarządzanym przez dyktatora architekta, ale z mojego doświadczenia wynika, że programiści są zadowoleni z takiego systemu. Mamy zerowy odpływ pracowników z powodu systemu pracy. Dla pracowników taka struktura jest przejrzysta i podział kompetencji jasny. Widzą system i jego dyscyplinę, więc także ich praca ma ściśle określony zakres. Jeśli mi, jako programiście nie podoba się jakieś rozwiązanie, wiem, komu mam to zakomunikować. Architekt może wziąć pod uwagę moją opinię, albo nie, ale podział kompetencji jest jasny. Nie ma tu rozproszonej odpowiedzialności grupowej, czyli sytuacji, w której nikt nie poczuwa się do bycia ojcem porażki. Zdarza się, że ludzie nam odpływają, bo chcą więcej zarabiać, podczas gdy nas na to nie stać, ale nie zdarza się, żeby uciekali, bo nie podoba im się system zarządzania projektem. Próbowałem innych formatów pracy, ale ten uważam za najlepszy. 

Popularnie mówi się, że co dwie głowy to nie jedna, więc uważa się także, że praca zespołowa na zasadzie burzy mózgów daje możliwość znajdowania kreatywnych i innowacyjnych rozwiązań znacznie lepiej, niż w przypadku sterowania jednoosobowego. Jednak uważam, że motywacja dla znajdowania innowacji jest znacznie wyższa, kiedy wiadomo, kto za co odpowiada. Uważa, się także, że mimo zebrania właściwych informacji i danych, nadal można podejmować złe decyzje. To prawda, że jeśli architekt jest słaby, to projekt upadnie. Nikt nie jest doskonały, więc można zepsuć projekt nierozważnym działaniem. Jednak druga strona medalu jest taka, że taki schemat daje także szansę architektowi, by osiągnął mistrzostwo. Oddzielenie obowiązków i odpowiedzialności wywołuje wyższą motywację i kreatywność u lidera. Nawet, jeśli chcecie pracować nad projektem w zespole równych sobie statusem programistów, już na samym początku ktoś obejmie prowadzenie, wyłoni się naturalny lider. Ktoś z was zacznie dominować, a inni będą go słuchać. Czemu więc nie mianować go otwarcie i w ten sposób z nieformalnej hierarchii zrobić formalną? Wtedy będzie przynajmniej odpowiadał za sterowanie projektem. Pozostali mogą wrzucać swoje pomysły, ale jeden za to odpowie. Ponadto obserwuje się, że w nieformalny lider to dość często nie ta osoba, która jest najzdolniejsza i najwyżej wykwalifikowana, tylko ten, kto najgłośniej mówi i jest pewny siebie. Jeśli mianuje się lidera oficjalnie na podstawie jego zdolności i umiejętności, a nie sympatii kolegów i siły osobowości, projekt zyska. Możecie głośno dyskutować i krzyczeć na siebie, a i tak ostatecznie decyzję podejmie ten cichy gość, którego mianowano na stanowisko architekta, bo ma do tego kwalifikacje i doświadczenie i zasługuje na to. Według mnie takie rozwiązanie sprawdzi się nawet w zespole dwuosobowym. 

Niektórzy krytykują moje rozwiązania z powodu konieczności przygotowania dokumentacji, co jest dodatkową pracą, za którą trzeba zapłacić, co podwyższa koszt projektu. My nie robimy niczego na papierze, tylko cała dokumentacja i historia projektu powstaje elektronicznie w repozytorium. W krótkim okresie wydaje się, że to niepotrzebny koszt, ale ja uważam, że to konieczny koszt, szczególnie, jeśli chodzi o długie projekty, na przykład roczne. Korzystamy z systemu ticketowego w każdym momencie, kiedy chcemy się skomunikować, więc wszystko, dokładnie wszystko utrwala się w repozytorium. Nawet, jeśli zaczynam prace jako pojedynczy architekt, który jeszcze nie ma teamu, wszystko przeprowadzam w ten sposób, ponieważ za jakiś czas, kiedy zespół się dobuduje, przyjdą ludzie, albo zmienią się ludzie, nie będzie trzeba nikomu nic tłumaczyć i wprowadzać. Taka osoba otworzy ticket i sama sprawdzi, jakich zmian dokonałem rok temu i dlaczego. Sama się dowie, jaka jest wizja i jakie już wystąpiły problemy i z jakiego powodu. W dłuższym okresie, taki system bardzo zmniejsza koszty. Programiści i architekt porozumiewają się tylko i wyłącznie elektronicznie, językiem kodu. Pewnie, że najłatwiej by było, gdyby jeden zadzwonił do drugiego i ustaliliby sobie jakieś rozwiązanie. Szybciej dla nich, ale wtedy w tym procesie pomijają wszystkich innych członków zespołu, a przede wszystkim mnie, jako architekta. Dlatego nie wolno im ustalać niczego werbalnie. Słyszę często, że werbalne ustalenia powinno się stosować, bo tak jest szybciej i łatwiej. Ale uważam, że jeśli programiście łatwiej jest pogadać, niż napisać kawałek kodu, to znaczy, że być może nie jest on dobrym programistą. Może nie ma wystarczających umiejętności i kwalifikacji do tej pracy.  Jestem orędownikiem tworzenia sztucznych ścian w zespole, tak, aby zmuszać programistów do rozmawiania kodem przez system, a nie werbalnie przy kawie. To, co jest „obgadane” normalnie nie jest zapisywane i znika, a potem pojawia się jako zaburzenie w systemie, bo nie ma jak dojść, dlaczego i jak podjęto decyzje o zmianie.

Wiele osób uważa, że nie chciałoby pracować pod rządami dyktatora. Architekt oprogramowania powinien być takim dyktatorem, ale także powinien mieć największy wkład w pracę zespołu. Nie tylko rządzi i ustala reguły, ale także powinien tworzyć kod z innymi. To drugi powód, dla którego nie powinien on chodzić po spotkaniach i gadać, po prostu nie ma na to czasu. Powinien relatywnie więcej kodu stworzyć niż pozostali. 

Niektórzy twierdzą, że w takim układzie zespół nie jest odpowiednio szkolony. To prawda, ale musimy pamiętać, że naszym celem w projekcie jest produkt, a nie nasz rozwój profesjonalny. Nikt nie będzie się zajmować uczeniem zespołu, bo sponsor płaci za produkt, a nie za waszą naukę. Jeśli dbacie o swój rozwój, w każdym takim zadaniu będziecie sami poszerzać swoje umiejętności, czytać, kreować i szukać. Nie jestem od tego, żeby was uczyć. Nawet często nie chcę tego robić, bo ja poświęciłbym czas i pieniądze na uczenie człowieka, który jutro odejdzie do innej firmy, więc po mojej stronie będzie strata. Naszym zadaniem jest produkt. Ten produkt ma przetrwać, nawet, jeśli cały zespół odejdzie, łącznie z architektem. Produkt jest ważniejszy niż sprawy i decyzje ludzi, którzy go tworzą. Dlatego tworzymy dokumentację i rejestrujemy wszystkie decyzje, bo ktokolwiek obejmie tę pracę po nas, będzie mógł doprowadzić ją do końca. A wy jesteście tu po to, aby stosować w praktyce swoją wiedzę, a nie po to, aby ktoś zajmował się waszym kształceniem. To nie szkoła i zleceniodawca nie płaci za to. Uczycie się sami dla siebie. Ja nie nauczam i nie wygłaszam pogadanek, nie jestem nauczycielem - tak rozumiem szacunek do kolegi i koleżanki z pracy. Jeśli chcesz się ode mnie uczyć, zajrzyj w mój kod, w moje poprawki i przyjrzyj się moim decyzjom. 

W dzisiejszych czasach jest wręcz oczekiwanie społeczne, że wszędzie będziemy stosować zasady demokracji. Ja jestem przeciwnikiem decentralizacji decyzji i planowania w sferze pracy projektowej. W rodzinie, społeczności lokalnej, czy w całym społeczeństwie, niech panuje demokracja, ale nie w moim projekcie. Mój system organizacji ma strukturę piramidy: na górze lider, a pod nim zespół, który pełni rolę doradczą i wykonawczą. Taka struktura jest w stanie wyprodukować duże rzeczy. Jeśli chcecie dobrze się bawić w pracy, to usuńcie lidera, bo on z definicji będzie on wam mówił, co macie robić. Tylko, że wtedy prawdopodobnie nie pociągniecie dużego projektu.  

 

Jak można zostać architektem oprogramowania?

To tylko rola. Niesie ona ze sobą problemy do rozwiązania i ryzyko odpowiedzialności. Jak się tego nauczyć? Trzeba obserwować architektów przy pracy, śledzić ich decyzje. W zespole, w którym jestem programistą architekt tworzy skomplikowane testy unitowe. Czytam to, co on robi, podglądam jego pomysły, kopiuję je i testuję. Nie jestem wystarczająco w tym dobry, więc przyglądam się temu, kto to potrafi. Piszę własne testy i je wypróbowuję. Staram się czytać i rozwijać na własną rękę, bo wiem, że on zarabia znacznie lepiej niż ja. Uczę się w ramach mojej pracy i chociaż nie mogę podejmować decyzji strategicznych, tak jak on, ale przygotowuję się do tego. Nawet jeślibym je za niego podejmował w ramach uczenia się, to i tak on dostanie za to pieniądze. Pewnego dnia role się zmienią i to ja będę się tym zajmował. 

(Poglądy Yegora Bugayenki w kwestii roli architekta oprogramowania i organizacji pracy projektowej zespołu, webinarium dla BuildStuff Ukraina 2016 – synopsis: Joanna Jedlińska) Youtube , Blog Autora.