5 pytań o zarządzaniu projektami w IT

Co to jest inżynieria wymagań?

Bartosz Chrabski: Inżynierię wymagań można scharakteryzować jako proces identyfikowania, dokumentowania i zarządzania wymaganiami, jakie powinno spełniać dostarczane oprogramowanie. Aby nie ograniczać się jedynie do oprogramowania, można powiedzieć, że wymagania dotyczą nie tylko produktu informatycznego, ale i dowolnego innego produktu. Dlatego też pełna definicja inżynierii wymagań powinna brzmieć – proces określania, dokumentowania i zarządzania wymaganiami na rozwiązanie. Preferuję upraszczać tę definicję i określać inżynierię wymagań jako dziedzinę, która pozwala jednoznacznie określać potrzeby klienta i je konkretyzować w kontekście danego rozwiązania. Myślę, że ten opis oddaje jednoznacznie charakterystykę tego, czym się zajmujemy.

Karolina Zmitrowicz: W prostych słowach jest to proces, dzięki któremu jesteśmy w stanie określić potrzeby i oczekiwania interesariuszy przedsięwzięcia i zarządzać nimi podczas etapów wytwarzania produktu.  Istotne jest również to, że inżynieria wymagań to nie tylko identyfikacja potrzeb, ale i określenie ograniczeń i założeń, które należy uwzględnić projektując rozwiązanie optymalnie spełniające postawiony przez interesariuszy cel w danym kontekście i uwarunkowaniach.

Dlaczego inżynieria wymagań jest ważna w zarządzaniu projektami IT?

Karolina Zmitrowicz: Ponieważ ustanawia podstawy dla planowania i wykonywania podstawowych czynności wytwarzania produktu – inżynieria wymagań określa „co” ma być dostarczone w ramach projektu i jakie parametry jakościowe ma to spełniać. Przykładowo, wynikiem realizacji czynności inżynierii wymagań jest koncepcja produktu informatycznego posiadającego określone funkcje i cechy jakościowe, jak użyteczność czy wydajność. Innymi słowy, ta dziedzina pozwala nam określić podstawowy cel i zakres przedsięwzięcia. Bez niej poruszalibyśmy się po omacku – nie wiedząc, co robimy, dla kogo i w jakim celu, każdy podejmowany krok i każdy dostarczony produkt będzie równie zły.

Bartosz Chrabski: Odpowiedź na to pytanie jest bardzo szeroka i można nią wypełnić rozdział w książce. Aby odpowiedzieć na to pytanie możemy użyć uproszczenia, gdzie przychodzi konsument do sklepu i chce kupić produkt  tani, wysokiej jakości i aby mu został dostarczony od zaraz. Odpowiedź sprzedawcy w tym wypadku jest prosta: po co Panu dwa różne produkty.

Podobnie jest z inżynierią wymagań, ma ona określić to, co faktycznie jest wymagane przez klienta i wykryć ewentualne konflikty, które mogą być problemem w realizacji projektu. Zarządzanie projektem bez inżynierii wymagań jest jak wyprawa w podróż Titanicem, zapowiada się wspaniale, kapitan obiera odpowiedni kurs, projekt zostaje rozpoczęty i płyniemy pełną para. Istnieje jednak mały szczegół w wymaganiach, który został pominięty w rezultacie idziemy na dno. Kierownik projektu zwykle nie ma wiedzy analitycznej, technicznej, często dziedzinowej, dlatego właśnie potrzebujemy wsparcia analityków i samej inżynierii wymagań. Doświadczenia z przeszłości wiele razy pokazały, jak kończą się projekty ze źle lub słabo określonymi wymaganiami i myślę, że nie musimy ich już w dzisiejszych czasach powtarzać.

Jakie są największe wyzwania w realizacji projektów informatycznych?

Bartosz Chrabski: Problemy w realizacji projektów informatycznych są nieustannie wdzięcznym tematem do dyskusji. Omawia się je na konferencjach, szkoleniach, w prasie i innych publikacjach. Szczególnie „medialne” i interesujące są spektakularne porażki, odbijające się szerokim echem w środowisku IT. Analizując statystyki i dostępną dokumentację, można wyciągnąć wniosek, że większość problemów występujących podczas realizacji projektów IT jest związana z samym zarządzaniem projektem. Po wnikliwej lekturze można wskazać kilkanaście notorycznie powtarzających się czynników w każdym projekcie. Jednym z kluczowych elementów jest brak planowania strategicznego, które pozwoliłoby organizacji określić cele i zaplanować realizację często współzależnych projektów. Rezultatem jest to, że klient nie wie, co chce osiągnąć za pomocą danego rozwiązania, i jakim celom biznesowym ma ono służyć.

Karolina Zmitrowicz: Rzeczywiście, jednym z podstawowych problemów jest brak określenia celów biznesowych, do których teoretycznie organizacja powinna dążyć podejmując kolejne przedsięwzięcia i inicjatywy. Jeśli nie ma celów, pojawia się pytanie, po co właściwie zainicjowano dany projekt? Co on ma osiągnąć? Biznes, w tym IT, to nie zabawa w „zobaczymy, co się stanie”. Tu każdy koszt powinien być zbilansowany korzyściami a decyzja o realizacji projektu powinna być wynikiem analizy mającej na celu ocenę opłacalności projektowanego rozwiązania w kontekście spełnienia określonych, mierzalnych celów. Tymczasem zbyt często widzimy projekty podejmowane w kompletnie nieprzemyślany sposób.

Brak celów to jednocześnie najczęściej brak odpowiedzialności za podejmowane decyzje, których koszt jest czasem ogromny a konsekwencje miażdżące. Przykładem niech będą spektakularne awarie oprogramowania, którymi żyła cała Polska pod koniec 2014.

Innym poważnym problemem w realizacji projektów IT są kwestie komunikacji i wiedzy. Biznes nie wie, jakie są potrzeby docelowych użytkowników. Biznes nie zna strategii i celów długofalowych własnej organizacji. Zespół wytwórczy nie wie, czemu i komu ma służyć produkt, który opracowują.

Bartosz Chrabski: Na podstawie środowisk, w których obecnie prowadzone są projekty, możemy stwierdzić, że zespoły analityków, programistów i testerów zwykle nie komunikują się ze sobą w sposób efektywny, co negatywnie wpływa na wydajność pracy, koszty i jakość finalnego produktu. Powszechnie używane narzędzia wspierające prowadzenie projektu nie potrafią wymieniać informacji między sobą, co prowadzi do powielania funkcjonalności i konieczności żmudnego i narażonego na błędy przenoszenia danych między nimi. Wybór narzędzi dokonywany jest zwykle pod kątem zaspokojenia potrzeb każdego zespołu z osobna, co z czasem całkowicie blokuje postęp strategii departamentu odpowiedzialnego za rozwój IT.

Na czym polega różnica w zarządzaniu projektami "tradycyjnymi" a zwinnymi?

Bartosz Chrabski: Odpowiadając na to pytanie warto wyjaśnić, co rozumiemy przez projekt tradycyjny. Wiele osób rozumie go jako sformalizowany proces, w którym praca z klientem polega tylko i wyłącznie na wymianie  dokumentów. Przez tradycyjny projekt możemy rozumieć przedsięwzięcie, w którym od początku znamy wszystkie kluczowe potrzeby klienta a gotowy projekt jest odbierany na końcu. Daje to czasami zgubne wrażenie bezpieczeństwa, ponieważ klient aktywnie nie uczestniczy w pracach nad produktem.

W projektach opartych o metodyki zwinne bardziej istotną rolę odgrywa komunikacja bezpośrednia, gdzie na początku projektu posiadamy jedynie zarys produktu, a następnie jest od doprecyzowywany przez ciągłą pracę z klientem.

Różnic w podejściach jest wiele i możemy je omawiać w kontekście wymagań czy samego sposobu realizacji projektu, podstawową różnicą jest to, że w metodach zwinnych klient otrzymuje produkt, który w założeniu ma bardziej odpowiadać jego potrzebom. Należy zwrócić uwagę, że metodyki zwinne nie są rozwiązaniem wszystkich problemów w realizacji projektów IT i nie w każdym projekcie są możliwe do stosowania.

Karolina Zmitrowicz: Istotnie, różnic jest dość sporo. Podstawową różnicą pomiędzy tymi dwoma podejściami jest sposób organizacji i formalizacji pracy. W projektach „tradycyjnych” dominuje pewien stopień „biurokracji”, czyli udokumentowane procesy, procedury oraz wyniki ich wykonania. Dlaczego? Ponieważ nie mając bezpośredniego i stałego kontaktu z klientem należy dokumentować postęp i wyniki prac, by w określonych momentach projektu przedstawiać je klientowi celem akceptacji. W projektach zwinnych klient jest „na miejscu” a celem jest jak najszybsze dostarczenie rozwiązania. Przy takiej organizacji pracy generowanie większości dokumentacji jest zupełnie zbędne – zastępuje je komunikacja bezpośrednia.

Warto jednak zwrócić uwagę na to, co zasygnalizował Bartek – metody zwinne, mimo swej pozornej atrakcyjności, wiążą się z pewnymi ryzykami i ograniczeniami. Podobnie zresztą jest w przypadku projektów „tradycyjnych” – nie w każdym kontekście będą one właściwym wyborem. Dlatego zamiast zaczynać przedsięwzięcie od pytania: „jakie podejście wybrać?”, warto zadać sobie pytanie: „co chcę osiągnąć, jakie mam warunki i możliwości, jakie widzę ryzyka” i dopiero na tej podstawie wybrać odpowiedni model pracy.

Na czym polega praca analityka biznesowego?

Bartosz Chrabski : Na wstępie do tego pytania należy zwrócić uwagę na to, że rola analityka biznesowego jest jedną z kluczowych dla inżynierii wymagań, ale na pewno nie jedyną. Zazwyczaj rola ta jest odpowiedzialna za pozyskiwanie, ewentualnie negocjacje,  analizę, dokumentowanie i przeglądy kontrolne wymagań oraz za prezentowanie wymagań pozostałym interesariuszom w celu uzyskania ich opinii i akceptacji. Istotny jest tutaj poziom abstrakcji, na jakim osoba działa. Sama nazwa roli wskazuje, że jest to poziom biznesowy i osoba może posiadać znikomą wiedzę na temat systemów IT, ale specjalistyczną i unikalną wiedzę na temat prowadzonego przez organizację biznesu. W wielu organizacjach granica ta jest z powodów braku kadr zacierana i generuje dodatkowe problemy związane z zakresem odpowiedzialności. Na chwilę obecną mamy raczej tendencje do tworzenia nowych specjalizowanych ról analitycznych w obszarze architektury korporacyjnej czy analizy danych, co pokazuje, że jest zapotrzebowanie na tę specjalizację.

Karolina Zmitrowicz: Analityk biznesowy to inżynier wymagań pracujący na poziomie biznesu. W mojej ocenie najlepszą definicję tej roli podaje IIBA (International Institute of Business Analysis) opisując analityka biznesowego jako osobę odpowiedzialną za pozyskiwanie potrzeb biznesowych interesariuszy i opracowanie koncepcji rozwiązania spełniającego te potrzeby.

Istnieją i inne role powiązane z inżynierią wymagań. Przykładem jest analityk systemowy, czyli inżynier wymagań pracujący na poziomie systemów – infrastruktury IT, oprogramowania, często sprzętu.

Jak zostać analitykiem?

Karolina Zmitrowicz: W pracy analityka biznesowego najistotniejsza jest znajomość danego obszaru biznesowego. Umiejętności zarządzania wymaganiami i projektowania rozwiązań są według mnie wtórne i stosunkowo łatwe do wykształcenia. Kluczowa jest dogłębna wiedza o biznesie, jego potrzebach i ograniczeniach, czego niezwykle trudno nauczyć się z książek. Dlatego też często analitykami biznesowymi zostają osoby pracujące w danym obszarze na stanowiskach operatorów czy właścicieli procesów. W branży ubezpieczeń typowym analitykiem biznesowym jest agent czy likwidator – osoby doświadczone w realizacji danych procesów biznesowych.

Nie jest to jedyna ścieżka – analitykiem biznesowym zostaje się systematycznie gromadząc wiedzę o danym biznesie. Konsultanci IT poruszający się stale w tym samym obszarze biznesowym z biegiem czasu uzyskują wiedzę wymaganą do tego, by mienić się analitykiem biznesowym w danej gałęzi biznesu.

Bartosz Chrabski: Istotnie, zrozumienie biznesowego kontekstu odgrywa kluczową rolę w rozwoju i pracy analityka, a bez niej nie da się realizować  pracy. Ciężko jest tutaj mówić o zdobyciu takiej wiedzy w inny sposób niż przez budowanie doświadczenia w różnych projektach i organizacjach. Pozwala to zdobyć przekrojową wiedzę dziedzinową z różnych punktów widzenia.

Nie można jednak zapominać o podstawach: przydatna jest wiedza z zakresu modelowania biznesowego oraz systemowego oraz umiejętności użycia narzędzi wspierających pracę. W dzisiejszych czasach wiele dobrych praktyk oraz technik pracy analitycznej zostało ujednolicone w standardy co ułatwia wyznaczenie ścieżki rozwoju dla zainteresowanej tą rolą osoby. Wiele firm dostarczających komercyjne narzędzia dla wsparcia prac analitycznych oraz organizacje certyfikujące oferują ścieżki szkoleń dla analityków, co może być źródłem dalszych inspiracji.

Bardzo dziękuję za rozmowę.

Informacje o rozmówcach  - do uzupełenienia