Zarządzanie projektem informatycznym jest nie lada wyzwaniem - rola kierownika projektu (ang. Project Manager) i właściciela produktu (ang. Product Owner) łączy w jednej osobie: kwestie biznesowe, związane ze stałym zwiększaniem wartości rozwijanych aplikacji i rozwiązań odpowiadających na potrzeby klienta, sferę technologiczną oraz szereg umiejętności miękkich, pozwalających zbudować silny, interdyscyplinarny zespół. Pracownicy sektora IoT, w którym na co dzień pracuję, mogą pochwalić się bardzo szerokim spektrum umiejętności i technologii, w których sprawnie się poruszają. PO lub PM zwykle współpracuje z grupą od kilku do kilkunastu osób, reprezentujących kompetencje: programistyczne, analityczne, UX/UI, QA, a nawet mechaniczne, elektroniczne i graficzne. Nierzadko dany zespół, funkcjonuje jak samodzielna firma – stąd zespół musi poradzić sobie samodzielnie z wieloma niewiadomymi w obrębie rozwijanego produktu.
Zarządznie projektem, a metodyka
Pierwszym wyzwaniem, przed którym stoi menadżer projektu jest wybór metodyki zarządzania. Postawienie na najbardziej rozpowszechnione metody zwinne niesie za sobą szereg konsekwencji, z których najważniejszą jest specyficzna organizacja pracy. Od doświadczenia, elastyczności i poziomu zaangażowania zespołu zależy, czy tzw. „scrum” ma prawo się udać, ale jeśli spodziewamy się częstych zmian wymagań i chcemy zadbać o komfort współpracowników w szybkozmiennym środowisku, warto wprowadzić metody zwinne w życie. W Comarch można skorzystać z pomocy Scrum Masterów, którzy pomogą bezboleśnie przejść przez proces wdrożenia.
Moje osobiste doświadczenia pokazują, że nawet bardzo młody team skupiony wokół wspólnego celu z sukcesem wykona pracę w dowolnej metodyce, z mniejszymi lub większymi problemami. Kluczem jest tu komunikacja i korzystanie z dostępnych narzędzi, by notować, chociażby drobne pomysły na usprawnienia i dokumentować bieżące problemy. Dzięki temu po kilku latach rozwoju produktu mamy do dyspozycji spory, spisany know-how, a proces wprowadzania nowych osób, zwłaszcza stażystów na początku kariery zawodowej, staje się szybki i nieskomplikowany.
Ograniczenia technologiczne
„Nietechniczny” Product Owner/Project Manager, zwłaszcza na początku swojej kariery, zderzyć się często może ze ścianą w postaci ograniczeń technologicznych. Nawet najlepiej opisana przez zespół biznesowy funkcjonalność, z estetycznie przygotowanym interfejsem użytkownika i dokumentacją zrozumiałą nawet dla największego laika, może okazać się zwyczajnie niemożliwa w realizacji przy zadanych założeniach. W przypadku urządzeń IoT naturalnym ograniczeniem jest czas działania na jednym ładowaniu baterii lub użyte technologie komunikacji bezprzewodowej, które blokują innowacje w zakresie użyteczności i responsywności. Wchodząc w obszary nieznane wcześniej w projekcie (nowa technologia, narzędzie, platforma), istotne jest zasięgnięcie opinii ekspertów, doświadczonych kolegów z innych zespołów lub sektorów – w tak dużej firmie niemal na pewno trafimy na kogoś, kto mierzył się z podobnymi problemami i może nam zaoferować merytoryczne wsparcie. Z pozoru banalna konsultacja pomoże oszacować czasochłonność wdrożenia nowej funkcjonalności i usprawni planowanie.
Komunikacja
Szeroko omawianą niewiadomą w projekcie jest zakres kolejnych funkcjonalności (ang. feature’ów) zgłaszanych przez interesariuszy wewnętrznych (partnerów wewnątrz firmy, kierowników produktu) oraz klientów zewnętrznych (firmy lub klientów indywidualnych). Od poziomu szczegółowości zebranych wymagań zależy, jak szybko programiści przy wsparciu UX designerów i testerów opracują, zaimplementują i przetestują funkcjonalność do stanu pełnej gotowości produkcyjnej. W przypadku bardzo ogólnego zdefiniowania potrzeby klienta zespół często „błądzi”, polegając na własnej intuicji. Dużo czasu i kilka iteracji poprawek może zaoszczędzić dokładne poznanie problemu, który rozwiązuje implementowana funkcjonalność – spory ciężar spoczywa tu właśnie na barkach kierownika projektu, który jest łącznikiem między światem biznesu i technologii. Podejście iteracyjne, znane z metodyk zwinnych zarządzania projektami, jest dobrym sposobem wybrnięcia z niepewnej sytuacji: jeśli pozwala na to specyfika projektu, należy dążyć do stworzenia i przedyskutowania w szerokim gronie wersji MVP (ang. Minimum Viable Product), a następnie nadbudowywać funkcjonalności, aż do osiągnięcia pełnej, satysfakcjonującej klienta wersji.
Nagłe wypadki
Kolejnym aspektem, przyprawiającym o ból głowy niemalże każdego lidera, są defekty występujące w produkcie. Często termin na ukończenie funkcjonalności jest z góry ustalony, stąd rolą zespołu jest określenie priorytetu i wagi (ang. priority and severity) znanych błędów, a następnie rozwiązanie w pierwszej kolejności tych problemów, które mają sumarycznie największy wpływ na odbiór produktu przez klienta. Nawet w doświadczonych zespołach zdarzają się okresy, kiedy trzeba rzucić wszystko i gasić nieoczekiwany pożar w projekcie. Ważne jest, by nie tracić w tym czasie motywacji – jest to naturalna część rozwoju, a przeżywanie horroru intensywnego bugfixingu czasem łączy lepiej niż niejeden duży sukces. Idealnym przykładem na zweryfikowanie swojego wyobrażenia o pracy nad realnymi projektami jest wakacyjny program stażowy w Comarch. Pozwala on zapoznać się z każdym etapem powstawania oprogramowania, od definicji wymagań właśnie do fazy bugfixingu i utrzymania, przez co w bezstresowy sposób wprowadza w realia świata IT, do tej pory znane z memów i opowieści rekruterów.
Potrzeby klientów
Kluczowe dla rozwoju produktu jest określenie realnych potrzeb klienta na wczesnym etapie procesu definiowania wymagań. Co dzieje się, gdy nie uda się wykonać poprawnie tego zadania? Po wydaniu funkcjonalności należy przeprowadzić solidne testy użyteczności – zbadać, jak aplikacja czy nawet pojedyncza funkcjonalność jest odebrana przez grupę docelową, a następnie zaproponować usprawnienia. Dużą rolę odgrywa tu Quality Assurance oraz UX Designerzy. Warto zaangażować kolegów z innych zespołów – przeprowadzić szybkie „testy korytarzowe”. Świeże spojrzenie osoby z zewnątrz pomaga wyrwać się z ram, które narzuciliśmy sobie w trakcie implementacji i może przyspieszyć etap wprowadzania poprawek. Jeśli nasza aplikacja jest już dostępna publicznie dla wielu klientów, warto zainwestować czas w przeprowadzenie testów A/B, by w praktyce zweryfikować pomysły na dużej grupie odbiorców.
Niewiadome w projekcie IT w dużym uproszczeniu dobrze opisuje żelazny trójkąt, wskazujący na wzajemną zależność zakresu, czasu realizacji i kosztów. Niedocenienie któregokolwiek z parametrów przez zespół, na czele z kierownikiem, skutkuje odpowiednią zmianą w dwóch pozostałych aspektach, co pociąga za sobą nieuniknione pogorszenie jakości finalnego produktu. Ponownie zwracam uwagę na ciężką do przecenienia wagę jasnych, zdefiniowanych wymagań i komunikacji zarówno z klientem, jak i pomiędzy członkami zespołu projektowego. Częsta informacja zwrotna, skrupulatnie przeprowadzone testy i dobra dokumentacja procesu to fundamenty bezstresowego środowiska pracy, w którym łatwo się rozwijać i osiągnąć sukces.
A jak powinien wyglądać optymalny proces projektowy? Tego dowiesz się z innego artykułu.