Jakiś czas temu napisałem, krótki artykuł o metodologiach zarządzania projektami, oraz podstawowych zasadach bez których projekt it nie może się udać. Ten artykuł jest obecnie dostępny na moim profilu w serwisie medium.com pod adresem (projekt informatyczny – wersja ang.).

Czytając ten artykuł można zadać sobie pytanie czy wymienione w nim obszary takie jak: 

• wielozadaniowość, 
• bycie project managerem i specjalistą w jednej osobie, 
• rozpoczynanie kolejnych projektów bez finalizacji poprzednich, 
• brak dzielenia zadań na mniejsze,
• dobieranie złych metodologii do projektów lub nieodpowiednich projektów do wybranych metodologii,

są wszystkimi obszarami na które jeżeli będziemy uważali odniesiemy w projekcie sukces?!

Z biegiem wzrostu doświadczenia okazuje się, że docelowo można utworzyć kategorie bloga nazwaną “błędy, których należy unikać w zarządzaniu projektami”, ponieważ im więcej projektów wykonujemy i ludzi poznajemy tym więcej sytuacji nowych. 

A więc co jeszcze powinniśmy uwzględnić aby zwiększyć szanse na sukces? 

---

Projekt IT – kolejne 5 kluczowych obszarów do rozwoju

1. Określanie celu
2. Nieprawidłowo wykorzystywane Sprint Refinement
3. PM-owie wykonujący nie swoje obowiązki
4. Brak osoby Product Owner
5. Brak kluczowych interesariuszy na wybranych spotkaniach

I znowu jak poprzednio, moglibyśmy tutaj listę nieco wydłużyć, ale uważam, że mniejsza partia materiału jest łatwiej przyswajalna więc skupmy się na nich, a w przyszłości z pewnością pojawią się kolejne artykuły.

---

1. Określanie celu

Każdy z nas mierzy się z wykonywaniem dużej ilości pracy na co dzień, można wręcz powiedzieć, że niekiedy wpadamy w błędną spiralę bo im więcej robimy tym więcej napotykamy problemów powodujących kolejny przyrost pracy. Ale czy każda wykonywana przez nas praca niesie wartość przez nas oczekiwaną? Tutaj już nie do końca…

Wiem też, że często jest tak, że obowiązków jest znacznie więcej aniżeli posiadanego czasu na wykonanie tych zadań. Ale czy nie wyglądałoby to zdecydowanie prościej gdybyśmy na wstępie określili cel?

Na przykładzie pracy w środowisku zwinnym możemy określić na początku cel produktu, kolejno cel sprintu, a finalnie nawet cel poszczególnych zadań. Dzięki czemu, podczas podejmowania poszczególnych działań możemy zadać sobie pytania:

• co będzie wyznacznikiem odniesienia sukcesu?
• czy jeżeli np. zwiększymy przychód o 30% to będzie to sukces, jeżeli koszt prowadzący do zwiększenia przychodu będzie wyższy niż jego wzrost? 
• jak w takiej sytuacji powinien wyglądać wzrost?
• lub po prostu, które z wykonanych zadań doprowadzą nasz szybciej do tego wzrostu? 

Te lub wiele innych pytań mogą znacząco skrócić listę zadań wykonywanych na co dzień, a docelowo dać nam czas na obszary kluczowe. 

2. Nieprawidłowe wykorzystanie Sprint Review

Zgodnie z definicją Scruma Sprint Review powinien spełniać, poniższe założenia:

• ​​Uczestnikami są Zespół Scrumowy i kluczowi interesariusze zaproszeni przez Właściciela Produktu,
• Członkowie Zespołu Scrumowego wyjaśniają, które elementy Backlogu Produktu zostały „Ukończone”, a które nie,
• Deweloperzy omawiają, co poszło dobrze podczas Sprintu, jakie problemy napotkał i jak te problemy zostały rozwiązane,
• Deweloperzy demonstrują wykonaną pracę i odpowiadają na pytania dotyczące Przyrostu,
• Właściciel Produktu omawia Backlog Produktu w jego aktualnej postaci. Projektuje prawdopodobne cele i terminy realizacji w oparciu o dotychczasowe postępy (w razie potrzeby),
• Cała grupa współpracuje nad tym, co robić dalej, tak aby Przegląd Sprintu dostarczył cennego wkładu w kolejne Planowanie Sprintu,
• Przegląd tego, jak rynek lub potencjalne zastosowanie produktu mogło zmienić, co jest najcenniejszą rzeczą do zrobienia w następnej kolejności,
• Przegląd harmonogramu, budżetu, potencjalnych możliwości i rynku dla kolejnych przewidywanych wydań funkcjonalności i możliwości produktu.

Jak widać powyżej zostali wymienieni “kluczowi interesariusze”. No właśnie, ale co jeśli spotykasz się z sytuacją, w której kluczowi interesariusze nie są w ogóle zaproszeni na takie spotkania? Wygląda to tak jakbyś posiadał klienta, dla którego wykonujesz jakieś prace, ale de facto w ogóle nie rozmawiasz z klientem o najważniejszych obszarach w danych momencie, nie robić aktualizacji posiadanych informacji. Po przepracowaniu kilku tygodni lub miesięcy kiedy już dochodzi do spotkania nagle się dowiadujesz, że nie o to tutaj chodziło. Ale są też inne konsekwencje. Jakie? Duża grupa interesariuszy wymagająca od zespołu deweloperskiego nie posiadająca świadomości jak dużo pracy i ile celów jest stawianych zespołowi przez innych interesariuszy. A zespół przecież nie może pogodzić wszystkiego i projekt się nie udaje.

3. PM-owie wykonujący nie swoje obowiązki – a projekt it

W tym obszarze chyba nie trzeba się bardzo mocno rozpisywać. Motyw przewodni tego punktu to permanentny brak czasu PM-ów na wykonywanie ich pracy, ponieważ ich czas jest poświęcany na modyfikację plików graficznych, lub ustawianie banerów. Ale jak to?

A no właśnie, tak to wygląda, że nikt nie zweryfikował przyszłych konsekwencji chociażby finansowych. A rozwiązaniem tego problemu może być zrekrutowanie osób na początku kariery IT, lub pozyskanie stażystów. Czy nie uważacie, że w takiej sytuacji lepiej byłyby wykorzystywane kluczowe zasoby i kompetencje PM-ów?

4. Brak osoby Product Ownera

Ten fakt może być niekiedy tłumaczony na różne sposoby. Jednym z argumentów na brak obecności PO jest brak zasobów finansowych, ale też zdarzają się sytuacje gdzie uważamy, że przecież to mogą robić ludzie np. z biznesu, przecież oni doskonale wiedzą czego oczekują? No i znowu zderzamy się ze ścianą ponieważ w biznesie napotykamy duże grono interesariuszy, a każdy mimo grania do jednej bramki i posiadania jednego celu widzi inną drogę tam prowadząco. To właśnie osoba Product Ownera ma być osobą w pełni obdarzoną zaufaniem, która będzie wybierała najbardziej kluczowe działania w danym momencie bazując na swoim doświadczeniu oraz w danej chwili posiadanych argumentów.

5. Brak kluczowych interesariuszy na wybranych spotkaniach

Zdecydowanie o tym niedociągnięciu dużo napisałem w punkcie 2, ale ten obszar ma wiele innych kluczowych aspektów. Możemy tak jak wcześniej wspomniane wykonywać prace na której efekty nikt nie liczy, lub doprowadzić do braku świadomości interesariuszy dlaczego zespół deweloperski nie wykonuje pracy przez innych oczekiwanej. Ale też, może być to powód całkowitego zamknięcia projektu, dużych strat finansowych, jak również znaczących konfliktów po stronie miękkiej. Ludzie nie posiadający wystarczającej wiedzy i świadomości o kluczowych aspektach z powodu których projekt się nie udał lub ktoś nie wykonał jakiejś pracy mogą bezmyślnie obwiniać drugą osobę, druga osoba w tym przypadku deweloper po pewnym czasie może czuć się sfrustrowana i nawet odejść z pracy.

Ok, możemy powiedzieć, że na miejsce tej osoby jest kilka kolejnych, ale zadajmy sobie pytanie, jaki to ma wpływ na terminy w projekcie? Na odczucia pozostałych członków zespołu? 

Podsumowując, wyzwań przed nami stawianych w prowadzeniu projektów, lub chociażby pracy w zespołach jest bardzo wiele, jak widzimy nie można ich sprowadzić do jednej listy 5 obszarów, w związku z czym artykułów w tych tematach będzie przybywać. Ale pamiętajmy, najważniejszym jest aby nie popełniać powtórnie tych samych błędów, a nawet jeżeli musimy to z pełną świadomością podejmować decyzję w oparciu o kluczowe argumenty. Dzięki temu, możemy zrobić krok na przód, możemy rozwinąć swoje kompetencje i budować wielkie rzeczy. 

Jeżeli interesuje Cię więcej informacji dla hasła projekt it zapraszam również do innego artykułu pod adresem.