Humanista w świecie IT

Humaniści vs umysły ścisłe

Kim jest humanista? Jak głosi oficjalna definicja, humanista to specjalista w zakresie nauk humanistycznych (źródło: pwn.pl). Ich przedmiotem jest człowiek i jego twórczość, np. filozofia, historia sztuki, dziennikarstwo, kulturoznawstwo, politologia, socjologia, prawo czy też filologie. Można powiedzieć, że nauki humanistyczne różnią się od nauk ścisłych tym, że nie można ująć przedmiotu ich badań w sposób matematyczny. Czy są przez to mniej logiczne? Z pewnością tak nie jest. W naukach humanistycznych, mimo iż ich metodyka nie jest ścisła, to występują zasady, które pozwalają na odróżnienie rzetelnej wiedzy od innych wypowiedzi. Humanista często upatrywany jest jako taki trochę marzyciel, bujający w obłokach, podczas gdy umysł ścisły to ten twardo stąpający po ziemi. Tym, co łączy te dwa światy, jest potrzeba czerpania ze swojego doświadczenia i kompetencji, które mogą się nawzajem uzupełniać. Klient zwracający się do firmy IT z zadaniem modernizacji systemu, na którym pracuje, nie musi być ekspertem w kwestiach technicznych. Wystarczy, że wskaże, na czym polega problem, który się pojawił lub jakich usprawnień oczekuje. Zaproponowanie najlepszych rozwiązań, to już zadanie IT.

Zalety, które dają przewagę w IT

Komunikacja i prezentowanie sprawiają większą łatwość humanistom. Programiści mają bogatą wiedzę, są fachowcami w swojej dziedzinie, jednak kłopot może sprawić im opowiedzenie w jasny sposób o kwestiach technicznych, zwłaszcza osobom spoza branży. Na pomoc śpieszy humanista, który wdzięcznie o wszystkim opowie, zaciekawi i wręcz sprzeda. A to jest bardzo cenna umiejętność. Humanista, dzięki swoim kompetencjom komunikacyjnym i krasomówczym, pomoże pozyskać sponsora i budżet, pomoże uratować projekt, jeśli trochę zboczył z torów, przekona interesariuszy, że wszystkie wymagania zostaną spełnione, tylko w odpowiednim czasie i w odpowiedni sposób. 

Abstrakcyjne myślenie pomoże zrobić „fajniejsze” oprogramowanie. Programiści często nie rozumieją, co to znaczy, że coś ma być “ładne”. Ładny jest dla nich kod, który nie zawiera żadnych zbędnych elementów, nie ma błędów, jest napisany zgodnie ze sztuką. Wszelkie ozdobniki wizualne nie są dla nich aż tak istotne. Architekt dba o spójność systemu, nie o ich końcowy wygląd dla użytkownika, admin po prostu wdroży to, co dostanie. Najczęściej informacji o oczekiwaniach względem wyglądu i funkcjonalności aplikacji dostarcza ktoś po stronie biznesu. I ten ktoś może nie mieć pojęcia o wytwarzaniu oprogramowania. Dzięki wsparciu humanisty w zespole zyskuje on kreatywność, dostaje szansę na to, że budowana aplikacja będzie unikalna, oryginalna. Na spotkaniach dzięki intuicji i abstrakcyjnemu myśleniu humaniści lepiej odczytają intencje biznesu, który tak naprawdę może nie wiedzieć do końca, czego oczekuje od IT. Humanista natomiast wie, rozumie, potrafi znaleźć wspólny język z programistami i razem z UXowcem stworzą idealny, przyjazny interface. 

Umiejętności przywódcze. Trzymać w ryzach spotkanie, umiejętnie przydzielić zadania, zdecydować co z natłoku zleceń jest najważniejsze, dbać o ducha zespołu i pozytywne relacje wśród pracowników. Tutaj umiejętności tzw. miękkie biorą górę, a tych więcej mają humaniści. Developer nie chcę się “kłócić” (pewnie by potrafił, ale po co?), on chce dostać jasną listę priorytetów, konkretne zadania, analizę - chce pracować. Kto inny powinien doprowadzić do tego, żeby analiza dotarła, wyznaczono priorytety, a to wymaga nieraz zdecydowanego postawienia na swoim, użycia tych “miękkich” umiejętności, twardego podejścia, asertywności, czy wręcz odwrotnie – humoru i sensownych negocjacji. 

Praca z ludźmi, rozumienie ich pozwala na stworzenie lepszego zespołu. Nie samym kodowaniem żyje IT, trzeba umieć komunikować się nie tylko z komputerem. Obecność humanisty wnosi nową jakość do zespołu, pojawiają się nowe tematy, rozmowy stają się bardziej urozmaicone. Jedni od drugich mogą się wiele nauczyć. Dodatkowo, co bardzo ważne, łatwiej rozwiązywać konflikty w zespole i dogadać się z innymi. 

Cierpliwość, czyli umiejętność wytrwania na kilkugodzinnym spotkaniu i jeszcze przygotowania na jego podstawie przydatnej notatki, umiejętność wytłumaczenia autorowi dziesięciostronicowego opisu procesu, że taka opisowa forma nie jest przyjazna dla programisty, powtarzanie w kółko, że to niemożliwe, żeby wszystkie zadania miały najwyższy priorytet, że czasami kilku rzeczy nie można zrobić równolegle. Zespół developerski to wie, dla nich jest to oczywiste, a biznes czasami traktuje to, jak wymówki. 

Umiejętność pisania to jak błogosławieństwo dla programisty. Oczywiście sam nie musi być w tym perfekcyjny, ale, tak czy inaczej, musi przygotować protokół odbioru, product show swojej aplikacji, raport, studium wykonalności i tutaj pojawiają się schody. Programiści, umysły ścisłe, są konkretni, ważą słowa i z radością odstąpią przygotowanie szerokich opisów humaniście. Oczywiście, jeśli taki znajdzie się w zespole. 

To wszystko na pewno daje przewagę humaniście, pozwala mu stać się naprawdę wartościowym graczem w projekcie IT. Jednak czy to wystarczy? Czy może tak po prostu wejść do ekipy programistów i z miejsca zacząć pracę? To już nie jest takie proste. Humanista musi nabyć pewne cechy od IT, w myśl powiedzenia: kiedy wejdziesz między wrony, musisz krakać, jak i one.

Jakich cech musi się wyzbyć, a jakie nabyć, żeby być wartościowym członkiem Zespołu? 

Podstawy programowania to konieczność. Nie chodzi o to, żeby umieć programować, nie, chodzi o to, żeby wiedzieć co i jak jest zbudowane, jakie są zasady powiązań pomiędzy systemami, czym jest architektura systemów, czym jest API, jakie mamy technologie i które z nich są odpowiedzialne za backend, a które za frontend. Teoria. Wystarczy trochę poczytać, dla bardziej interesujących tematów poszukać jakiejś książki lub podręcznika. Przydatne jest również nauczenie się podstaw SQL. Kiedy potrafimy napisać proste zapytanie, daje to nam ogromne możliwości i punktujemy w zespole IT. 

Umiejętność rozmowy z IT. Najsłynniejszy żart wśród humanistów, kiedy są na spotkaniu i developerzy czy architekci rozmawiają o szczegółach jakiejś aplikacji, czy próbują zrobić wstęp do analizy technicznej, posługując się przy tym fachową terminologią to: „nie wiem, czy Ty mnie teraz obrażasz, czy co…”. Z pozoru śmieszne, ale na dłuższą metę męczące. Nie mając wykształcenia informatycznego ciężko zrozumieć wszystkie rozmowy programistów, to prawda, ale nic nie stoi na przeszkodzie, żeby rozumieć, chociaż ich część. Warto poczytać o tym, jak rozmawiać w języku IT, co z czym się je, co znaczą poszczególne sformułowania i samemu zacząć ich używać.

Konkretność wypowiedzi i działań to kolejny obszar do nauki dla humanisty. Zespół IT składa się z osób konkretnych, zmierzających do jasnego, określonego, często wyliczonego celu. Aby to osiągnąć, Zespół potrzebuje precyzyjnych opisów wymagań, zwięzłych i trafnych wypowiedzi, krótkich, owocnych spotkań. Do tego, humaniście potrzebna jest konkretna, ustrukturyzowana wiedza. Humanista musi zacząć myśleć, że do każdego spotkania trzeba się dokładnie przygotować, a nie wymyślać ustalenia podczas jego trwania. 

Inne podejście do czasu, czyli po prostu szanowanie pracy IT. Nie tylko dlatego, że man-day jest kosztowny, ale też dlatego, że trwonienie czasu IT wpływa negatywnie na morale zespołu. Na spotkanie należy przyjść przygotowanym, z konkretnymi pytaniami, czy też wymaganiami a po jego zakończeniu powinna powstać krótka, konkretna notatka. IT musi wiedzieć, że współpracuje ze świadomym przedstawicielem biznesu, który rozumie podejście programistów i wie, że nieefektywne zarządzanie czasem generuje straty.

Zwięzłe analizy, to te idealne dla programisty. Najlepiej, gdyby były zawarte w tabelce, a nie w formie wypracowania. Przebrnięcie przez pięć czy dziesięć stron barwnego opisu, to dla programisty może być po prostu strata czasu. Humanista musi się tego nauczyć, ponieważ nadrzędną cechą analizy wymagań powinno być to, aby rozumiało ją IT. 

Na koniec coś, co nazwę umiejętnością „wiem, albo nie wiem”. Styl humanisty jest w skrócie taki “jak czegoś nie wiem, to coś wymyślę, a nawet jak to za chwilę okaże się do zmiany, to zmienię”. W wielu przypadkach to się sprawdza i nie powoduje większych problemów, ale nie w IT. Zmiana wymagań nie jest obca zespołom developerskim, wręcz robi się coraz bardziej powszechna i pojawia się w niemal każdym projekcie, ale nie powinno się do niej doprowadzać celowo. Nie powinno być zasady „zróbmy tak, najwyżej potem zmienimy”. To bardzo ważna cecha, którą humanista musi nabyć: przemyślane stawiane twierdzeń, poparte konkretną wiedzą, czy wyliczeniami. A kiedy pada pytanie, na które nie znamy odpowiedzi — należy powiedzieć wprost, że jest to niejasne i ustalić plan jak się tego dowiedzieć. 

Podsumowanie

To fakt, humaniście może brakować, nazwijmy to — matematycznych zdolności i cech, ale ma za to szereg innych, które mogą mu pomóc odnaleźć się w branży IT, a wręcz dać pewną przewagę. Uważa się, że ktoś, kto ma problem ze zrozumieniem działań matematycznych czy statystyki, nie będzie w stanie zrozumieć tego, jak działają systemy, na czym polega programowanie, co kryje się w tysiącach linijek kodu. Nic bardziej mylnego. Badania rezonansem magnetycznym dowiodły, że podczas czytania kodu w mózgu uruchamiają się ośrodki odpowiedzialne za przetwarzanie języka, pamięć i uwagę, nie zaś za liczenie. Co więcej, nawet podczas czytania kodu obejmującego matematykę — obszary mózgu odpowiedzialne za matematykę nie były aktywne. (źródło: nofluffjobs.com). 

Przygotowując się do opracowania tego artykułu i kompletując informacje z różnych źródeł, doszedłem do wniosku, że tak naprawdę nie istnieje do końca sztywny podział na humanistów i ścisłowców. Są tylko ludzie, którzy chcą! Chcą poświęcić czas na naukę i zrozumienie innych oraz ich punktu widzenia. Świat samych humanistów czy samych ścisłowców byłby niesamowicie nudny. Jak to powiedział Rafael Reif, przewodniczący MIT:

Świat potrzebuje ludzi dwujęzycznych. To znaczy inżynierów zakochanych w sztuce oraz humanistów, którzy rozumieją technologię.