#jakzaczacwit

Jeśli chcesz pracować w IT ale nie wiesz od czego zacząć, ta seria artykułów pomoże Ci znaleźć coś dla siebie. Sukcesywnie będę dzielić się z Wami swoim doświadczeniem i dopisywać kolejne rozdziały tego poradnika.

Zacznijmy od zdefiniowania kilku możliwych ścieżek rozwoju w IT.

UX Designer vs UI Designer

UX Designer

Koncentruje się na całości wrażeń użytkownika z użytkowania produktu. Nie tylko projektuje wygląd produktu ale także dba o to aby był intuicyjny w użyciu. UX designer dba o to aby produkt był piękny oraz użyteczny. Dba o odbiór produktu na poziomie wrażenia – emocji.

W przypadku branży IT UX Designer często:

  • Rozumie potrzeby branży oraz jest na bieżąco z trendami oraz rozwiązaniami stosowanymi przez konkurencję.
  • Pracuje z klientem bądź użytkownikami i stara się zrozumieć co jest dla nich najważniejsze.
  • Projektuje flow (przepływ) – Sposób w jaki użytkownik porusza się po aplikacji. Np. decyduje, które funkcje powinny być wyróżnione i łatwiej dostępne, jak powinien wyglądać proces zakupu, jak powinna wyglądać nawigacja w aplikacji.
  • Przygotowuje prototypy i wireframes.
  • Testuje użyteczność produktu, dopasowuje go do typu persony użytkownika, dbając o  łatwość użycia.
  • Współpracuje z biznesem nad rozwojem produktu.

UX designer może być, ale nie musi, UI designerem.

UI Designer

Zajmuje się zaprojektowaniem, na poziomie szczegółowym, tego jak wygląda produkt. Kieruje się wskazówkami UX designera odnośnie flow i rozmieszczeniem funkcjonalności na prototypach. Wypełnia je szczegółami wraz ze wszystkimi danymi potrzebnymi do implementacji. Potrafi tworzyć projekty “pixel-perfect”. Rozumie ograniczenia technologii oraz bibliotek używanych przez developerów. Negocjuje z nimi kompromisy pomiędzy “pięknym”, a “możliwym do zrealizowania”. Dba przy tym aby projekt nie utracił użyteczności, ani by nie pogorszył się odbiór produktu na poziomie wrażeń i emocji.

W przypadku IT UI designer często:

  • Wykonuje prototypowanie z uwzględnieniem podpowiedzi UX Designera
  • Wykonuje szczegółowy projekt zgodny z dostarczonym prototypem
  • Współpracuje z developerami i pomaga im odzwierciedlić wygląd projektu w gotowym produkcie; dobiera konkretne grafiki, motywy elementy
  • Potrafi dostosować wygląd produktu do odpowiedniej platformy z zachowaniem typowych dla platformy bądź technologii elementów (np. rożny wygląd dla urządzeń mobilnych, czy aplikacji natywnych, uwzględnienie różnic w menu używanym na iOS oraz Android)

W uproszczeniu możemy powiedzieć, że UX designer tworzy wizję użytecznego produktu, UI designer czuwa aby produkt był piękny, Developer sprawia, że ten produkt powstaje.

Scrum Master vs Agile Coach

Scrum Master

Dba o to aby zespół Developerski mógł swobodnie pracować oraz współtworzyć “zwinne środowisko” pracy. Pomaga zrozumieć czym jest Scrum poprzez naukę, szerzenie oraz wspierania dobrych praktyk oraz wartości Scrum. Pomaga grupie ludzi zawiązać się w prawdziwy zespół oraz uczy zespół Developerski samoorganizacji. Wspiera rozwój Scrum w organizacji. Wspiera oraz edukuje Product Ownera w sposobach optymalnego prowadzenia Backlogu produktu oraz maksymalizacji wartości dostarczanej przez zespół Developerski.

Agile Coach

Wspiera rozwój metodyk zwinnych (takich jak Lean, Scrum, Kanban, XP) w organizacji. Promuje wartości Agile, często prowadzi szkolenia oraz warsztaty. Pracuje z managementem nad identyfikacją oraz eliminacją wąskich gardeł w procesie wytwarzania oprogramowania. Często pracuje z klientem oraz pomaga mu zrozumieć procesy zwinne. Wspiera oraz szkoli zespoły w zrozumieniu oraz wybraniu zwinnej metodyki pracy.

Project Manager vs Delivery Manager

Project Manager

Zarządza projektem. Często dysponuje budżetem, ustala timeline delivery, negocjuje z klientem zakres produktu. Dba o terminową realizację projektu. Zarządza ryzykiem.

Delivery Manager/Program Manager

W zależności od wielkości organizacji oraz skomplikowania struktury organizacyjnej jego obowiązki mogą pokrywać się z obowiązkami Project Managera. Przy dużych projektach składających się z kilku programów role Delivery Managera czy Program Managera mogą zostać rozdzielone i różnie zdefiniowane.

Najczęściej Delivery Manager dba o delivery, czyli terminowe dostarczenie powiązanych ze sobą projektów, z których każdy ma własnego Project Managera. W zależności jak dysponowany jest budżet może odpowiadać za rozdzielenie budżetu pomiędzy projekty w programie oraz wstępne ustalenie zakresu odpowiedzialności danego projektu.

Project Manager vs Scrum Master

W niektórych organizacjach, które dopiero zaczynają wdrażać Scrum następuje “przemianowanie” roli Project Managera na rolę Scrum Mastera i rozszerzenie roli Project Managera o obowiązek prowadzenia spotkań Scrumowych. Taki zabieg zwykle się nie udaje. Rolą Scrum Mastera jest szerzenie wartości Scrum w organizacji i praca z zespołem. Scrum Masterzy częściej skupieni są na potrzebach ludzi, operują na emocjach, pracują na zaufaniu zespołów developerskich proponując zmiany. Pozostają liderami służebnymi względem zespołu developerskiego wskazując mu drogę rozwoju oraz podrzucając pomysły na rozwiązywanie problemów, ale nie podejmują decyzji ZA zespół. Zachowują się jak coachowie pomagający zespołowi odkryć sedno problemu, wymyślić rozwiązanie oraz ustalić plan wcielenia go w życie. Podświadomie czują odpowiedzialność za delivery jednak zawsze postawią zespół na pierwszym miejscu.

Rola Project Managera często jest inna. Wymaga się od nich pilnowania timelinenów, budżetu oraz “resourców”. Często Project Manager pracuje “mając pod sobą” kilka zespołów developerskich. Siłą rzeczy jest miedzy nimi większy dystans. Project Manager często ma nawyk zarządzania zespołami – mówienia im co mają robić. Są to cechy, których nie powinien rozwijać w sobie Scrum Master, gdyż przeczą idei wspierania samoorganizacji zespołów.

Wbrew powszechnemu zamiennemu stosowaniu nazwy Scrum Master/Project Manager te role są rozbieżne. Wymagają innego podejścia oraz rozwijania innych cech charakteru. Jeśli więc wasza organizacja faktycznie planuje wdrożyć metodyki zwinne, powinniście koniecznie zapewnić nie tylko szkolenia ale i coaching  każdemu Project Managerowi oraz upewnić się, że będzie się czuł dobrze w nowej roli. Czasem lepszym pomysłem jest uczynienie z Project Managera Product Ownera zamiast Scrum Mastera. Dużo zależy od charakteru danej osoby.

Biznes Analityk vs Product Owner

Product Owner

Rola Product Ownera jest bardzo odpowiedzialna. Jest Właścicielem Produktu, co znaczy, że jest umocowany aby podejmować wszelkie decyzje dotyczące kierunku rozwoju produktu. Product Owner pracuje bezpośrednio z “biznesem”, a więc z klientem i użytkownikami produktu. Do Product Ownera mogą docierać naciski z wielu źródeł (np. jeśli klientów jest wielu i każdego  z nich interesuje tylko jego “kawałek produktu”), jest odpowiedzialny za to aby pertraktować z klientami i ustalać priorytety. Robi to przez porządkowanie Backlogu Produktu i upewnianie się, że zespoły developerskie dostarczają wartość o odpowiedniej jakości i w  kolejności zgodnej z priorytetami.

Na co dzień w IT:

  • Product Owner nie musi być osobą “techniczną”. Często zdarzają się przejścia z roli UX Designera bądź Biznes Analityka na rolę Product Ownera. Jednak w praktyce osobie “nie technicznej” będzie bardzo ciężko znaleźć pierwszą pracę w tej roli. Od Product Ownera oczekuje się dużej dojrzałości. Przyjmuje on pełną ODPOWIEDZIALNOŚĆ za rozwój produktu oczekiwane jest więc, nie tylko, że potrafi rozmawiać z klientem i zbierać wymagania na nowe funkcjonalności ale również, że będzie ten produkt rozumiał lepiej niż ktokolwiek inny.
  • Product Owner musi posiadać na tyle wiedzy technicznej aby mógł zrozumieć problemy i ograniczenia technologii wybranej przez zespół developerski oraz być w stanie świadomie podjąć decyzję o zarządzaniu długiem technologicznym.
  • Product Owner musi potrafić przełożyć wymagania zebrane od klienta, najczęściej w formie “historyjki użytkownika”, na język zrozumiały dla developerów. Tutaj bardzo przydaje się doświadczenie w roli Biznes Analityka.

Analityk Biznesowy

Pomaga tworzyć Backlog Produktu. Często pracuje z Klientem, tak jak Product Owner, i wykonuje podobne obowiązki jak tworzenie historyjek użytkownika, wyjaśnianie wątpliwości, praca z zespołem nad zrozumieniem wymagań. W małych projektach często istnieje tylko jedna z tych ról, najczęściej rola Product Ownera. W większych projektach może wystąpić podział obowiązków w taki sposób, że Product Owner dyskutuje z klientami o priorytetach i priorytetyzuje Backlog, zaś Biznes Analityk pracuje bliżej zespołu. Pomaga zespołowi wyjaśnić szczegóły wymagań. Ogólne zagadnienia rozpisuje sam bądź wraz z zespołem developerskim na konkretne zadania techniczne. Ustala dokładne kryteria akceptacji dla każdego zadania technicznego. Pomaga przygotowywać dokumentację techniczną. Główna różnica polega na tym, że w większych projektach nie zawsze musi rozumieć całość produktu wystarczy, że posiada dokładne zrozumienie obszaru, za który jest odpowiedzialny. Nie ponosi odpowiedzialności za nie dostarczenie, bądź wadliwość wytworzonego produktu.

 

W praktyce w IT.

  • Biznes Analityk nie musi być osobą “techniczną” jednak niewątpliwie musi być bardzo “lotny” i uporządkowany.
  • Nie zawsze będzie miał możliwość rozmawiania z klientem, czasem będzie odgrodzony od klienta przez PO jednak potencjalnie powinien posiadać umiejętność samodzielnego nawiązania oraz utrzymania relacji z klientem oraz zbierania wymagań.
  • Biznes Analityk pracuje często blisko zespołu developerskiego, powinien więc mieć na tyle rozwinięte pojęcie o produkcie aby potrafić pomóc zespołowi w wyjaśnieniu wątpliwości.
  • W praktyce często zostaje “sekretarzem Backlogu” zwłaszcza na początku ścieżki, jego zadaniem staje się więc fizyczne “wklepywanie” zadań w wybrane narzędzie do zarządzania Backlogiem. Oraz uzupełnianie dokumentacji. Z czasem uczy się przesuwać tę odpowiedzialność w stronę zespołów.

 

*Backlog Produktu – Uporządkowana lista wszystkich (znanych na daną chwilę) funkcjonalności, które mają znaleźć się w rozwijanym produkcie.

Ciąg dalszy nastąpi...