W ciągu moich 5 lat pracy w branży spotkałem zarówno czystych humanistów w IT, jak i tych, którzy awansowali na PMów ze stanowiska technicznego.
A jako programiście łatwiej było mi negocjować z menedżerami, którzy mają przynajmniej podstawową wiedzę techniczną. Zwłaszcza dzisiaj, gdy w środowisku zdalnym cała komunikacja poważnie się rozmyła. Jeśli PM wie, jak przebiega proces rozwoju, oszczędza to mnóstwo czasu i wysiłku całego zespołu.
W artykule opowiem, co w moim rozumieniu oznacza podstawowa wiedza techniczna. Na praktycznych przykładach zobaczmy, jak znajomość procesów rozwojowych pomaga managerowi efektywniej zarządzać projektem.
Jeszcze minutka motywacji: dlaczego wiedza techniczna jest ważna dla PM-a
Oddzielmy od razu background techniczny i wiedzę. Background techniczny ma miejsce wtedy, gdy osoba przyszła na PM-a ze stanowiska technicznego. Na przykład była testerem lub pisała kod. Takie doświadczenie może pomóc lub przeszkodzić w pracy, jeśli kierownik myli role i nie wykonuje swojej pracy. Dla PM-a cenna jest umiejętność zrozumienia, co robią programiści, ale nie wykonywania pracy za nich.
Zdecydowanie ważna dla PM-a jest wiedza techniczna — zrozumienie, jak działają technologie, z których korzysta zespół.
Menedżer bez wiedzy technicznej:
- Nie rozumie estymacji: przydziela zbyt długi czas na wykonanie zadania lub odwrotnie, oszacowanie jest zbyt optymistyczne — a zespół nie dotrzymuje terminu.
- Słabo rozróżnia obszary odpowiedzialności w zespole, kto za co jest winny, do kogo ma być skierowane zadanie. Na przykład, z kim rozmawiać, jeśli logo na stronie się zepsuło? Z designerem czy webmasterem?
- Nie potrafi wyjaśnić klientowi złożoności lub korzyści pewnych decyzji. Często 80% pracy backendu nie jest wcale oczywiste dla użytkowników (na przykład optymalizacja komponentów systemu), ale bez tej części technicznej produkt nie będzie działał normalnie.
Podam przykład, jak wiedza techniczna pomaga kierownikowi projektu w szacowaniu (estymacji) zadań i podejmowaniu decyzji. Załóżmy, że zespół udostępnił w wersji produkcyjnej aplikację z funkcją przesyłania obrazów. W pewnym momencie obrazy przestały się ładować. PM konsultuje się z programistą i dowiaduje się, że są dwa rozwiązania: naprawić wszystko w trzy dni lub rozwiązać problem szybciej, ale w przyszłości mogą pojawić się problemy z aplikacją.
Którą opcję lepiej wybrać? Biorąc pod uwagę, że aplikacja już działa i ludzie z niej korzystają, trzy dni na naprawę to za dużo. Bardziej opłaca się wdrożyć szybkie rozwiązanie, a następnie stopniowo «usuwać» dług techniczny.
Menedżerowi posiadającemu wiedzę techniczną łatwiej jest zrozumieć wewnętrzne mechanizmy i odpowiadać na pytania klientów bez dodatkowej synchronizacji z programistami.
Jak rozdzielane są role w zespole
Ustalenie, kto jest odpowiedzialny za co — to podstawa dla PM. Następnie spójrzmy na praktyczny przykład tego, do kogo należy kierować poszczególne zadania, jeśli coś poszło nie tak.
W tworzenie dowolnej aplikacji lub usługi zaangażowanych jest 5 komponentów: Design, Backend, Frontend/Mobile, QA, SysAdmin/DevOps. Każdy element jest obsługiwany przez różnych specjalistów w zespole.. Kiedy menedżer rozróżnia obszary odpowiedzialności, nie będzie rozpraszał frontendu, jeśli żądania są przetwarzane przez długi czas.
- Designer (UX i UI Design) — tworzy projekt i podkreśla wymagania biznesowe, zastanawia się nad scenariuszem użycia. Odpowiada za wygląd produktu i wygodę interakcji z witryną lub aplikacją. Wszystko powinno być przemyślane, układ przycisków jest intuicyjny. Zadania frontendu i backendu w dużej mierze zależą od projektu.
- Backend — pisze logikę i API (interfejs aplikacji), aby mogli z nim pracować programiści frontendowi lub mobilni.
- Frontend lub Mobile — dba o to, jak działa widoczna, po stronie klienta część witryny (Frontend) lub aplikacji (Mobile).
- QA (tester) — testuje produkt pod kątem zgodności z określonymi wymaganiami i normami jakości. Najważniejszym celem testera nie jest liczba błędów znalezionych podczas fazy testowania, ale to, aby użytkownicy nie znaleźli defektów po wydaniu produktu.
- SysAdmin/DevOps — dba o to, aby wszystkie ważne części aplikacji były dostępne 24 godziny na dobę, 7 dni w tygodniu, a usprawniony proces dostarczania kodu odbywał się w sposób ciągły. Jest to cichy obserwator, który działa równolegle ze wszystkimi procesami «w tle». Najczęściej praca sysadminów lub DevOps nie jest zauważana, dopóki coś się nie zepsuje. Jeśli wszystko pójdzie dobrze, praca DevOps pozostaje niewidoczna.
Przyjrzeliśmy się poszczególnym komponentom programistycznym, teraz przyjrzyjmy się, jak rozłożone są obszary odpowiedzialności w zespole na przykładzie zadania praktycznego.
Gra: do kogo skierować zadanie
Wyobraźmy sobie, że klient zgłasza się do nas z następującym zadaniem: stworzyć MVP witryny skracania linków, gdzie użytkownik będzie mógł:
- zarejestrować się/zalogować się;
- tworzyć skrócone linki;
- zobaczyć statystyki dotyczące linków.
Logika w takiej aplikacji jest bardzo prosta: istnieje główny link i to, do czego jest sprowadzony. Gdy wymagana jest wersja skrócona, aplikacja podaje wersję rzeczywistą.
Załóżmy, że uruchomiliśmy naszą usługę skracania linków i zaczęły się pojawiać pierwsze błędy zgłaszane przez użytkowników. Istnieją różnego rodzaju problemy i dobrze, gdy PM rozumie, komu przydzielić zadanie naprawy konkretnego błędu.
Spójrzmy na przykłady:
- Harmonogram kliknięć w link nie jest wyświetlany w przeglądarce Safari. A w Chrome wszystko działa zgodnie z oczekiwaniami. Z takim błędem trzeba podejść do frontendu, bo jego zadaniem jest zajmować się wyświetlaniem danych w przeglądarce.
- Statystyki kliknięć nie są gromadzone. Użytkownicy podążają za wygenerowanymi linkami, ale aktualizacje statystyk nie są widoczne w konsoli. Backend może w tym pomóc, ponieważ zliczanie kliknięć to zadanie niezwiązane z wyświetlaniem danych, jest to czysto wewnętrzna logika, która żyje w backendzie..
- Otwieranie linków dla użytkowników z Ameryki Łacińskiej zajmuje dużo czasu. W Europie łącze otwiera się w 300 milisekund, a w Ameryce Łacińskiej — 1,5 sekundy. Najprawdopodobniej jest to zadanie dla DevOps: musisz albo skonfigurować DNS, albo zduplikować serwer aplikacji gdzieś w regionie Ameryki Łacińskiej.
- Podczas próby otwarcia witryny pojawia się błąd 500. Jest to jeden z przypadków, w których nie można od razu zidentyfikować, czyj to problem. Najprawdopodobniej rozwiązywać go będzie backend wraz z DevOps.
- Tworzenie nowych linków nie działa. Na stronie jest jakiś formularz, musisz go wypełnić, wpisać długi link, kliknąć «zapisz» — i uzyskać skrócony analog. W pewnym momencie ten formularz przestał działać.
Ten błąd może mieć kilka przyczyn:
- backend zgłasza błąd 500, a link nie jest generowany;
- coś zostało zepsute w interfejsie użytkownika, więc parametr wskazujący, że użytkownik jest autoryzowany nie jest przekazywany. Wtedy linki nie zostaną skrócone, ponieważ backend nie uważa użytkownika za autoryzowanego;
- być może problemy leżą po stronie DevOps: jeden z serwerów uległ awarii i strona jest wyświetlana, ale cała logika jest zablokowana.
Niektórym powyższe przykłady będą wydawać się elementarne, ale bez zrozumienia tych elementarnych rzeczy kierownik ryzykuje niewłaściwym kierowaniem zadaniami. Kiedy zdarza się to wiele razy, ludzie się rozpraszają, denerwują i pojawiają się niepotrzebne konflikty.
Nawet przy wiedzy technicznej znalezienie rozwiązania może być trudne, ponieważ istnieje wiele problemów, które leżą na styku obszarów odpowiedzialności specjalistów. Nie zawsze jest możliwe natychmiastowe zidentyfikowanie źródła problemu, zwłaszcza jeśli jest on związany z interakcją elementów systemu. W takim przypadku PM ma do dyspozycji najważniejsze narzędzie — komunikację. Zawsze możesz porozmawiać i zapytać.
Aby jednak komunikować się poprawnie, menedżer musi mieć przynajmniej w dużym stopniu rozumieć obszary odpowiedzialności każdego specjalisty.
Zrozumienie podstaw rozwoju jest podstawowym poziomem wiedzy technicznej PM. Następnym krokiem jest doskonalenie umiejętności oceny wraz z zespołem.
Zrozumienie estymacji
Bez wiedzy technicznej kierownikowi trudno jest odpowiednio oszacować łączny czas pracy nad choćby jednym zadaniem. Zawsze zdarzają się sytuacje, kiedy programiści albo przesadzają z terminami, albo wręcz przeciwnie, podają zbyt optymistyczną estymację, a potem zespół nie wyrabia się, bo praca zajęła 15, a nie 5 godzin, jak planowano.
Przy szacowaniu liczby godzin pracy, PM musi umieć rozłożyć problem, rozbić rozwiązanie na małe punkty. Gdy tylko zadanie zostanie rozłożone, staje się jasne, jakie są szacunki i co mają zrobić programiści.
Dam ci przykład. Backend może być napisany w PHP, a może w Javie. PHP szybko przetwarza żądania, podczas gdy Java to osobna aplikacja, która nieustannie kręci się w oczekiwaniu na żądania. W zależności od języka programowania czas naprawy błędu będzie różny. W przypadku PHP istnieje możliwość szybkiego wypchnięcia zmian z serwera, praktycznie niewidocznych dla użytkownika. W przypadku Javy, żeby wszystko działało, trzeba przebudować cały backend od początku. Jeśli PM rozumie różnicę między językami, nie będzie oczekiwał, że błąd zostanie szybko naprawiony, nie będzie narzekał, że minęła godzina, a programista nie naprawił jeszcze problemu.
Inny przykład dotyczy różnicy między estymacjami w pracy frontendowej i mobilnej. Za każdym razem przeglądarka żąda kodu frontendowego dla nowego użytkownika z serwera. Dlatego nawet jeśli gdzieś popełni się błąd, jego pilne naprawienie to kwestia godziny. Użytkownicy pobierają aplikację mobilną za pośrednictwem App Store: niekoniecznie muszą mieć włączoną funkcję automatycznej aktualizacji. Dlatego koszt błędu jest zupełnie inny.
Jak ocenianie działa w praktyce
Załóżmy, że musimy dodać płatność przez PayPal do naszej aplikacji dla tworzenia skróconych linków.
Najpierw decydujemy, kto z zespołu będzie potrzebny:
- designer: stworzenie designu strony, okna modalnego lub okna w aplikacji mobilnej, na której będzie dokonywana płatność;
- frontend i backend do pisania logiki;
- QA do przetestowania całego procesu na podstawie wyników pracy zespołu.
Teraz PM musi obliczyć, ile czasu zajmie osiągnięcie celu. Zadanie zostało oszacowane przez front-end i back-end.
- Frontend ocenił pracę na 4 godziny, łącznie z layoutem, logiką żądania/odpowiedzi backendu i to wszystko.
- Backend ocenił zadanie na jeden miesiąc: zapisanie nowych tabel w bazie danych, logika żądań/odpowiedzi do serwerów PayPal, API, z którymi frontend będzie współpracował.
Ocena front-endowa wygląda realistycznie. Kiedy jest zadanie, na przykład napisanie «modalu», aby można było zapłacić przez PayPal, to 4 godziny wydają się być dobrym czasem.
Następnie PM zaczyna rozkładać zadanie na czynniki pierwsze i okazuje się, że front-end nie wziął pod uwagę wszystkich punktów. Tego, że układ strony powinien być adaptacyjny, dobrze wyglądać na urządzeniach mobilnych i w różnych przeglądarkach.
Kiedy PM wraz z zespołem krok po kroku omawiają elementy zadania, przychodzi zrozumienie pominiętych kroków: układ może zawierać dodatkowe opcje, także logikę. Frontend będzie musiał obsłużyć błędne odpowiedzi z backendu.
To samo z backendem. Gdy wszystkie części zadania są omawiane, na przykład tworzenie nowych tabel bazy danych, logika żądań/odpowiedzi, API, mogą pojawić się warunki brzegowe, które mogą nie iść zgodnie z planem.
Załóżmy, że nie ma problemów z nowymi tabelami w bazie danych, a także z logiką zapytań dla frontendu. Mamy działającą aplikację i najprawdopodobniej chłopaki ustalili, w jakim formacie otrzymują i przesyłają dane.
Przed oceną należy zebrać statystyki dotyczące sprintów i na ich podstawie zbudować kilka hipotez.
Z mojego doświadczenia mogę powiedzieć, że prowadzimy statystyki dotyczące tego, jak programiści radzą sobie w sprintach i identyfikujemy współczynniki dla każdego z nich. Następnie mnożymy estymacje przez te współczynniki. Najczęściej średni współczynnik dla programistów wynosi 1,6. Osoby ze współczynnikiem 1,5 i niższym mają dobry wskaźnik, dość przewidywalny.
Nie jest możliwe oszacowanie złożoności zadania i czasu na jego wykonanie z absolutną dokładnością: gdy tylko pojawi się interakcja między ludźmi, wszelkie gwarancje przestają być czymś realnym. Jednak umiejętność dekomponowania pomaga PM lepiej radzić sobie z terminami, odpowiednio oceniać zarówno duże funkcje, jak i cały projekt.
Podsumowanie
PM z wiedzą techniczną:
- rozróżnia obszary odpowiedzialności specjalistów w zespole;
- rozumie, do kogo zwrócić się z danym problemem;
- umie rozdzielać zadania i oceniać szacunki wspólnie z zespołem;
- potrafi uzasadnić klientowi korzyści płynące z określonych rozwiązań lub złożoność zadania.
Oczywiście na stanowisko PM-a można przyjść z absolutnie humanistycznej sfery, i znam całkiem udane przykłady. Jeśli firma zgodzi się na przeszkolenie nowego specjalisty, to wiedza będzie musiała być rozwijana w procesie zarządzania projektami. Nie będzie łatwo uczyć się i jednocześnie rozwiązywać zadania projektowe, dlatego lepiej z góry zrozumieć, kto czym zajmuje się w zespole, co robią programiści, z czego składa się system.
PM z wiedzą techniczną więcej rozumie, wie więcej, co oznacza, że ma większe szanse na znalezienie dobrej pracy nawet w czasach kryzysu.