Sytuacja kobiet w IT w 2024 roku
26.10.201811 min
Yegor Bugayenko

Yegor BugayenkoCEOZerocracy

Czy architekt oprogramowania jest jak reżyser filmowy?

Zobacz na czym polega zawód architekta IT. Poznaj kontorwersyjną perpektywę programisty z 20-letnim stażem.

Czy architekt oprogramowania jest jak reżyser filmowy?

Kim jest architekt oprogramowania? Zwykle widzisz go jako osobę o wyższych zarobkach niż programista, siedzącą na lepszym fotelu, w lepszym biurze. Kogoś obecnego na wszystkich spotkaniach, ze stanowiskiem ładnie wypisanym na wizytówce. I tyle. Nawet, kiedy chcą Cię zatrudnić na takim stanowisku, nie tłumaczą, o jaką rolę tak naprawdę chodzi.

Poznałem wielu architektów oprogramowania - nie tylko z nazwy na wizytówce. Z mojego doświadczenia wynika, że rola ta polega na byciu członkiem zespołu, który 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ę pod decyzją podpisać - właśnie architekt oprogramowania. Tak to powinno wyglądać. A ci wszyscy ludzie, którzy go otaczają? Mogą komunikować się między sobą, wymieniać informacjami, odbyć tyle spotkań, ile trzeba - a i tak to on jeden podejmie ostateczne decyzje. 

To wydaje się oczywiste, a jednak w wielu miejscach wcale tak nie jest, a zespół podejmuje decyzje w drodze demokratycznej dyskusji i głosowania. 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: Zrobimy tak, jak ja chcę i nie obchodzi mnie, że się z tym nie zgadzacie - bo to moja decyzja. Będzie raczej starał się perswadować. A 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: kamerzystów, aktorów, inwestorów, producentów. Ale osobą, która podejmuje decyzje jest tylko reżyser - np. podziwiany przeze mnie Martin Scorsese. Jeśli film będzie należał do dobrych, wszyscy będą świętować sukces reżysera. 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 winny jest reżyser. I właśnie dlatego rola architekta powinna się opierać na dwóch fundamentach: na odpowiedzialności i władzy

Pierwszy z nich - 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 zrobienie nieodpowiedniego designu, czy wreszcie złe zaplanowanie struktury - za to wszystko obwinia się jedną osobę. Nigdy nie mówi się, że to wina zespołu czy grupy osób. Właśnie ta osoba zostanie pociągnięta do odpowiedzialności i w jakiś sposób ukarana - na przykład zwolniona. Przyczyna powstania błędu to zupełnie oddzielna kwestia. Może architekt nie zdołał uzyskać właściwych informacji, może nie był w stanie się dobrze skomunikować z zespołem, może zatrudnił niewłaściwych programistów. Nieważne. Ważne jest to, że wszyscy wiemy, że odpowiedzialność za ten błąd ponosi „reżyser” projektu. 

Drugim fundamentem roli architekta jest władza. Skoro odpowiedzialność za błędy i porażki projektu spada na tę jedną osobę, to do niej naturalnie powinna należeć władza nad projektem. Jeśli chcecie mnie obwiniać o zły wybór bazy danych, musicie mi najpierw pozwolić ją wybrać. Nie wyobrażam sobie zarzucanie architektowi, że projekt jest źle wyskalowany, bo baza danych nie jest wystarczająco szybka, i jego odpowiedź, że nie mógł podjąć innej decyzji - bo odbyło się głosowanie, a zespół podjął decyzję wbrew jego woli. Kto wtedy ponosi odpowiedzialność? To sytuacja 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 gra zespołowa, a jednoosobowy ruch. Współpraca w zespole jest tu na niższym szczeblu hierarchii 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 manager projektu (PM nadzorujący przebieg tworzenia produktu). Ostatni element struktury - manager projektu - kontroluje, czy wszyscy członkowie zespołu idą określoną drogą wedle ustalonych zasad zarządzania, czy są wynagradzani i czy nie rodzą się jakieś destruktywne konflikty. Ale jego rola nie jest tematem artykułu.

Uważam, że architekta i zespół powinna łączyć bardzo cienka linia, albo to połączenie nie powinno istnieć w ogóle. Właściwa komunikacja architekta z zespołem powinna zawsze odbywać się poprzez 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ą projekt. Załóżmy, że jako architekt podjąłem decyzję o dużej zmianie, na przykład baz danych. Nie idę wtedy do zespołu, żeby mu tłumaczyć, jaka to decyzja i dlaczego ją podjąłem. Tworzę ticket, w którym wyjaśniam decyzję - w ten sposób tworzę samą dokumentację zmiany. Dodaję ticket do repozytorium, więc zespół otrzymuje go i wie, czego chcę. Zależy mi na uzyskaniu opinii członków zespołu? Również proszę ich przez tickets i przez repozytorium. Wstawiam swój kod i wyjaśnienie do repozytorium, które zostają w dokumentacji projektu. A więc wszystko odbywa się poprzez repozytorium, zamiast normalnej komunikacji werbalnej - chodzi o to, aby architekt był oddzielony od zespołu. Idąc za tym rozumowaniem - uważam, że dobrym rozwiązaniem byłoby także oddzielanie programistów od siebie nawzajem. Nie powinni oni pracować razem, w tym samym pomieszczeniu.

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

Komunikacja architekta z zespołem

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

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 i jak przebiega proces tworzenia produktu. A kiedy chcę coś zmienić, idę do bugtrackera i tworzę bug. Wprowadzam go, rejestruję i wyjaśniam, na czym polega oraz jak go uniknąć w przyszłości. Naprawę przydzielam jednemu z programistów - w ten sposób produkt się rozwija, zaczyna iść inną drogą. W większości przypadków nie spotykam się z zespołem, nie mówię, co ma zrobić, nie wygłaszam pogadanek i nikogo nie szkolę. Nie wyjaśniam niczego werbalnie. Do tego celu tworzę dokument. 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 przysyła pull request, mam szansę na kształtowanie produktu. Patrzę na proponowane zmiany i decyduję, czy zmieniać, czy nie. Czasem muszę to skomentować i tę osobę poprawić. 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.

Gdybym był managerem projektu, musiałbym kontrolować pracę architekta I trzymać rękę na pulsie. W tym celu zadałbym mu trzy pytania. Pierwsze z nich dotyczyłoby statusu wykonania (scope status) projektu. Architekt - jako główny wykonawca projektu - wie, w której fazie 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ł: Jakie mamy teraz problemy? Co nie idzie, co nie działa?
Architekt posiada taką wiedzę. Na przykład, że baza danych nie jest wystarczająco wyskalowana, strona internetowa zbyt wolna, kod wadliwy, nie działa w XML itp. Albo, że używamy Javy 7, a w tym konkretnym procesie powinniśmy używać Javy 6.

Trzecie pytanie dotyczyłoby zagrożeń. Architekt musi mieć szersze spojrzenie na produkcję i 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, a wtedy najpewniej spowolni. Taką informacje architekt musi przedstawić managerowi projektu.

Kontrowersje

Niektórzy uważają, że ciężko jest pracować w zespole zarządzanym przez takiego architekta. Jednak z mojego doświadczenia wynika, że programiści są zadowoleni z takiego systemu. Mamy zerowy odpływ pracowników z powodu systemu pracy. Taka struktura jest przejrzysta, a podział kompetencji jasny. Pracownicy widzą system i jego dyscyplinę, więc także ich praca ma ściśle określony zakres. Jeśli jako programiście nie podoba mi 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 kreatorem porażki. Zdarza się, że ludzie odchodzą, bo chcą np. 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.

Uważa się, ż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. Moim zdaniem 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, projekt upadnie. Nikt nie jest doskonały, więc projekt można zepsuć nierozważnym działaniem. Jednak taki schemat daje także szansę architektowi, by osiągnął mistrzostwo. Oddzielenie obowiązków i odpowiedzialności wywołuje u lidera wyższą motywację i kreatywność. Nawet, jeśli chcecie pracować nad projektem w zespole równych sobie statusem programistów, już na samym początku ktoś obejmie prowadzenie - w naturalny sposób wyłoni się lider. Ktoś zacznie dominować, a inni 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 nie odpowie.

Nieformalny lider to dość często nie ta najzdolniejsza i najwyżej wykwalifikowana osoba, 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, odpowiednie doświadczenie i na to zasługuje. 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ą, która podwyższa koszt projektu. My nie robimy niczego na papierze - cała dokumentacja i historia projektu powstaje elektronicznie w repozytorium. Uważam, że to koszt konieczny - szczególnie, jeśli chodzi o długoterminowe - np. roczne - projekty. Korzystamy z systemu ticketowego w każdym momencie, kiedy chcemy się skomunikować, więc wszystko utrwala się w repozytorium. Nawet, jeśli zaczynam prace jako architekt, który jeszcze nie ma teamu, wszystko przeprowadzam w ten sposób. Za jakiś czas, kiedy zespół się dobuduje - przyjdą, albo zmienią się ludzie - nie będzie trzeba nikomu nic tłumaczyć i wprowadzać nowej osoby. Otworzy ona ticket i sama sprawdzi, jakich zmian dokonałem rok temu i dlaczego. Sama się dowie, jaka jest wizja, jakie już wystąpiły problemy i z jakiego powodu.

W dłuższej perspektywie 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 są OK, 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 zachęcania programistów do rozmawiania kodem przez system, a nie werbalnie przy kawie. Nie zapisuje się tego, co jest „obgadane” normalnie, a więc ustalenia znikają. System się zaburza - trudno 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ć właśnie takim dyktatorem - z największym wkładem w pracę zespołu. Nie tylko rządzić i ustalać reguły, ale także tworzyć kod z innymi. To drugi powód, dla którego nie powinien chodzić po spotkaniach - po prostu nie ma na to czasu. Do niego należy stworzenie relatywnie większej ilości kody, niż do pozostałych.

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 Twoją naukę. Jeśli dbasz o swój rozwój, w każdym takim zadaniu będziesz sam poszerzać swoje umiejętności, czytać, kreować i szukać. Nie jestem od tego, żeby uczyć. 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. Ktokolwiek obejmie tę pracę po nas, będzie mógł doprowadzić ją do końca. A Ty jesteś tu po to, aby w praktyce zastosować swoją wiedzę. Jeśli chcesz się ode mnie uczyć, zajrzyj w mój kod, w moje poprawki i przyjrzyj się moim decyzjom.

W dzisiejszych czasach funkcjonuje społeczne oczekiwanie, że wszędzie będziemy stosowac zasady demokracji.
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 chcesz w pracy dobrze się bawić, usuń lidera, bo on z definicji będzie mówił, co masz robić. Ale wtedy prawdopodobieństwo, że nie pociągniecie dużego projektu jest duże.

Jak zostać architektem oprogramowania?

To tylko rola. Niesie ze sobą problemy do rozwiązania i ryzyko odpowiedzialności. Jak się tego nauczyć? Poprzez obserwację architektów przy pracy i śledzenie ich decyzji. W zespole, w którym jestem programistą, architekt tworzy skomplikowane testy unitowe. Czytam to, co robi, podglądam jego pomysły, kopiuję je i testuję. Nie jestem w tym wystarczająco 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, przygotowuję się do tego. Nawet jeśli bym je za niego podejmował w ramach uczenia się, to i tak on dostanie za to pieniądze. Pewnego dnia role się zmienią - to ja będę się tym zajmował.

<p>Loading...</p>