Project Managment Framework
Cel Project Management Framework
Wypracowanie standardu dla całej organizacji, który będzie definiować ramy i zasady prowadzenia projektów w zakresie projektów IT oraz non-IT.
W ramach tego procesu zostaną określone relacje między kartą projektu na Confluence, a Jirą.
Project Management Framework ma w sposób transparentny informować o celu, zakresie, terminach projektu, postępach realizacji projektu, a także strukturyzować ramy pracy panujące w organizacji.
Ramy zarządzania projektami są ważne, ponieważ:
Pomagają poprawić wydajność
Zachęcają do współpracy za pomocą narzędzi, które oferuje organizacja
Wspierają budowanie odpowiedzialności
Pomagają w przeglądzie procesów pracy.
Korzyści z używania struktury zarządzania projektami
Korzyści PMF
Ramy zarządzania projektami mogą przynieść pięć głównych korzyści, całkowicie na nowo definiując sposób obsługi, realizacji i dostarczania projektów. Pięć głównych zalet Ram Zarządzania Projektami to:
Spójność – Jedną z najbardziej znaczących korzyści płynących z zarządzania projektami jest zapewnienie spójności w planowaniu i realizacji projektu. Ponieważ ramy zarządzania projektami kładą ścisły nacisk na szczegółowe planowanie projektu, ogólne podejście jest spójne i dobrze zdefiniowane. Spójność dodatkowo pomaga zapewnić precyzję i przejrzystość projektu.
Przejrzystość — już na początkowych etapach ramy zarządzania projektami definiują i wyjaśniają zakres projektu wszystkim zaangażowanym w projekt. Nie pozostawia to miejsca na zamieszanie i niejasności, w wyniku których projekt postępuje zgodnie z planem. Dzięki temu, że członkowie zespołu dokładnie wiedzą, co mają robić na każdym etapie, efekty końcowe są dużo bardziej spójne i lepsze.
Współpraca — ramy PM z łatwością angażują wszystkich interesariuszy w projekt od samego początku, aż do osiągnięcia ostatecznego etapu zakończenia. Naturalnie zachęca do współpracy między członkami zespołu PM i interesariuszami. W rezultacie wszyscy zaangażowani w projekt wybierają podejście spójne i oparte na współpracy. To nie tylko pomaga ukończyć projekt w pożądanym tempie, ale także znacznie poprawia jakość produktu końcowego.
Ciągłość – ponieważ wszystko jest dobrze zdefiniowane i zaplanowane z góry, ramy zarządzania projektami dotyczą ciągłości i wydajności. Dzięki integracji planowania projekty mogą płynnie przechodzić od fazy początkowej do punktu końcowego. Ponadto ramy PM ułatwiają płynne przejście zarówno pomiędzy nowymi, jak i doświadczonymi uczestnikami. Chociaż poprawia krzywą uczenia się nowych członków zespołu PM, wzmacnia wiedzę doświadczonych członków . Tak więc, gdy projekt jest zakończony, a nowy projekt ma się rozpocząć, członkowie zespołu mogą bezproblemowo wskoczyć na pokład nowego projektu, ponieważ podstawowe ramy pozostają takie same.
Komunikacja — kierownik projektu, zespół kierownika projektu i interesariusze są ściśle zaangażowani w projekt, a linia komunikacji między nimi zawsze pozostaje otwarta. Każdy etap struktury PM obejmuje ścisłą współpracę wszystkich z nich w celu określenia zakresu i celu projektu, a także wszystkich zawartych w nim procesów. Im wyższy współczynnik komunikacji między wszystkimi interesariuszami, tym płynniejszy przebieg projektu.
( Źródło: https://www.proprofsproject.com/blog/project-management-framework/)
Proces Management Framework, a Framework Współpracy w Organizacji
Proces Management Framework rozpoczyna się po zakończeniu: https://bluemedia.atlassian.net/wiki/spaces/ITD/pages/1663631424/Framework+Wsp+pracy+w+Organizacji#Tollgate-2 i kończy przed https://bluemedia.atlassian.net/wiki/spaces/ITD/pages/1663631424/Framework+Wsp+pracy+w+Organizacji#Tollgate-3
Aktorzy
INTERESARIUSZE - Interesariusze projektu to osoby lub grupy, które są zainteresowane lub mogą być dotknięte realizacją projektu. Mogą to być np. klienci, użytkownicy, pracownicy, zarząd, inwestorzy, społeczność lokalna, regulatorzy lub inni zainteresowani.
SPONSOR - Sponsor projektu to osoba lub jednostka organizacyjna, która finansuje lub udostępnia zasoby potrzebne do realizacji projektu. Może to być np. Business Unit. Patrz: Sponsor - jak wybrać dla zadania
PRODUCT MANAGER - Product manager to osoba odpowiedzialna za strategię i zarządzanie produktem w firmie, w tym określanie celów biznesowych, wybór funkcjonalności, definiowanie budżetu i planowanie wdrożeń. Patrz: PM/PO - odpowiedzialność
PRODUCT OWNER - Product owner to osoba realizująca strategię Product Managera. Odpowiada za definiowanie wymagań i priorytetów wewnątrz produktu, prowadzi projekty, jest łącznikiem do Zespołu IT. Patrz: PM/PO - odpowiedzialność
LIDER IT - Lider IT to osoba z zespołu IT, wyznaczona do prowadzenia projektu. Odpowiada za weryfikację wymagań produktowych, rozpisanie zadań na podstawie zdefiniowanych story. Kontroluje projekt, aby był realizowany zgodnie z wymaganiami i terminami. Zna status projektu, identyfikuje i zarządza ryzykami. Odpowiada za zapewnienie odpowiednich zasobów, narzędzi i infrastruktury. Lider IT nie musi być Team Leaderem Zespołu IT.
ANALITYK- Analityk IT to osoba, która zbiera i analizuje wymagania biznesowe oraz definiuje specyfikacje funkcjonalne dla projektów informatycznych. Pomaga w projektowaniu rozwiązań i wdrażaniu ich w organizacji.
QA - QA (Quality Assurance) w projekcie IT to zespół bądź osoba odpowiedzialna za zapewnienie jakości wytwarzanego oprogramowania. Odpowiada za planowanie i realizację testów oraz raportowanie ich wyników. Patrz: Delivery Quality - QA
ZESPÓŁ IT - Zespół IT to grupa osób pracujących nad realizacją projektu informatycznego. W skład zespołu mogą wchodzą programiści kierowani przez Team Leadera. W organizacji poza zespołami developerów mamy też zespoły administratorów, analityków, testerów, monitoringowców. Lista zespołów z ich składami znajduje się tutaj: Struktura
ZESPOŁY WSPIERAJĄCE - Zespoły wspierające to zespoły niezaangażowane bezpośrednio w development, ale pełniące role utrzymaniowe, operacyjne i monitoringowe, np. ISS, AM, DAS. Są to zespoły, które zapewniają jakość procesów w ramach produktu, kontaktują się z kontrahentami, wykonują cykliczne czynności obsługowe zapewniające drożność przepływu danych i informacji.
Opis procesu
Krok | Opis | Aktorzy | Narzędzia | Efekt po zakończeniu danego etapu | |
|---|---|---|---|---|---|
0. | Pojawienie się pomysłu/ zapotrzebowania |
| INTERESARIUSZE | JIRA |
|
Utworzenie dokumentacji projektu - Karta projektu |
| PRODUCT OWNER | KARTA PROJEKTU |
| |
2. | Analiza wstępnych wymagań |
| PRODUCT OWNER | KARTA PROJEKTU |
|
3. | Doprecyzowanie wymagań |
| PRODUCT OWNER | KARTA PROJEKTU |
|
4. | OPTIONALPogłębione konsultacje z innymi działami |
| PRODUCT OWNER | MEETING NOTES |
|
5. | Rozpisanie zakresu projektu - produktowo i technicznie |
| PRODUCT OWNER | JIRA (w tym tworzenie zależności) |
|
NPI T2 | Decyzja GO / NO GO | Decyzja Komisji ds. inicjatyw T2 o rozpoczęciu prac | PRODUCT OWNER | ||
6. | OPTIONALKickoff |
| PRODUCT OWNER |
| |
7. | Realizacja prac w projekcie IT | działania cykliczne:
| PRODUCT OWNER | JIRA |
|
7. | Realizacja prac w projekcie NON-IT | Realizacja prac zgodnie z potrzebami | PRODUCT OWNER ZESPOŁY WSPIERAJĄCE | JIRA |
|
8. |
| QA | JIRA |
| |
9. | Wdrożenie |
| ZESPÓŁ IT | JIRA |
|
10. | Aktualizacja dokumentacji |
| ZESPÓŁ IT | JIRA |
|
11. | Review |
| PRODUCT OWNER | KARTA PROJEKTU |
|
12. | Zamknięcie projektu/ Inicjatywy |
| PRODUCT OWNER | KARTA PROJEKTU |
|
13. | OPTIONALRetro |
| WSZYSCY | CONFLUENCE |
Flowchart Procesu
https://www.figma.com/file/rNgDALWyEScUXIhCzIxSnY/PMF-ToBe?node-id=0%3A1&t=aP3xlSUhAtQxPuUY-1
Stan dotychczasowy https://www.figma.com/file/3UpusQiWRPVYtmRJz40B1y/PMF-AS-IS?node-id=0%3A1&t=OO28OES2nk4m7tTx-1:
Role w procesie
Krok | Faza | INTERESARIUSZE | SPONSOR | PRODUCT MANAGER | PRODUCT OWNER | LIDER IT | ANALITYK | QA | ZESPÓŁ IT | ZESPOŁY WSPIERAJĄCE |
|---|---|---|---|---|---|---|---|---|---|---|
| Stworzenie Karty Projektu, Epiki, podpięcie pod inicjatywę | NA | NA |
|
| NA | NA | NA | NA | NA |
| Uzupełnienie informacji dodatkowych |
|
| |||||||
| Analiza produktowa i systemowa, wybór Lidera IT | Wspiera uzyskanie niezbędnych definicji biznesowych:
| Prowadzi i dokumentuje analizę produktowa czyli analizuje różnice w stanie AS IS produktu versus TO BE. Na tym etapie analiza biznesowa powinna juz byc gotowa i informacje takie jak:
| Prowadzi/wykonuje i dokumentuje analizę systemową, jeżeli do projektu nie zostaje dołączony analityk systemowy. | Współpracuje z zainteresowanymi stronami projektu i użytkownikami końcowymi w celu uzyskania, zrozumienia, przeanalizowania i udokumentowania wymagań systemu w celu rozwiązania danego problemu biznesoweg. | |||||
| Potwierdzenie interesariuszy określonych w ramach przygotowań projektu do NPI. Zgłoszenie zapotrzebowania w organizacji, warsztaty, QA, Brainstorming | Potwierdzają PO/Liderowi IT poziom zaangażowania jaki chcą mieć w projekt, zgodnie z matrycą RACI. Informują niezwłocznie Product Ownera/IT Leada | Wspiera proces, rozwiązuje konflikty. | Na podstawie zebranych informacji o problemie biznesowym i sposobie jego zaadresowania lokalizuje osoby mogące być zainteresowane projektem i wykonuje dla nich macierz RACI. Zbiera informacji z dwóch źródeł poza-IT i IT i dokumentuje na karcie projektu. Organizuje warsztaty, wyjaśnia wizję projektu przewodzi/zbiera potencjalne pytania i jest odpowiedzialny za znalezienie odpowiedzi | Na podstawie zebranych informacji o problemie biznesowym i sposobie jego zaadresowania lokalizuje osoby mogące być zainteresowane projektem i wykonuje dla nich macierz RACI. Komunikuje zlokalizowanych interesariuszy do PO. Uczestniczy w warsztatach, zgłasza pytania IT. | Wspiera lokalizację interesariuszy. | Udziela wsparcia | Udziela wsparcia | ||
| Rozpisanie wstępnych opcji realizacji zmiany i wybór optymalnych | Dyskutuje rekomendacje i wspiera team w osiągnieciu potwierdzenia dla najbardziej optymalnej scieżki. | Rozpisuje wstępne opcje i rekomenduje optymalne opcji wdrożenia potrzeby biznesowej | Uczestniczy z PO w wypracowaniu rekomendacji | Uczestniczy z PO w wypracowaniu rekomendacji | Uczestniczy z PO w wypracowaniu rekomendacji | ||||
| Potwierdzenie możliwości i wybranych opcji ze zleceniodawcą | Potwierdza ukierunkowanie formy implementacji | Wspiera PO/Lidera IT w dyskusji ze sponsorem. | Prowadzi prezentację do sponsora | Wspiera aspekt techniczny prezentacji do sponsora | |||||
| Identyfikacja kamieni milowych | Akceptuje kamienie milowe. | Wspiera PO/lidera IT w prezentacji kamieni milowych do Sponsora i akceptuje | Wypracowuje kamienie milowe i rekomenduje do PM/Sponsora | Uczestniczy w wypracowaniu kamieni milowych | Uczestniczy w wypracowaniu kamieni milowych | ||||
| Utworzenie wstępnej dokumentacji technicznej i produktowej, uzupełnia Kartę Projektu | Akceptuje dokumentacje produktową. Dokumentacja techniczna powinna podlegać pod technicznego managera produktu/architekta. | Wypracowuje wstępną dokumentację produktową lub zleca jej wytworzenie kontrolując jakość | Wypracowuje wstępną dokumentację techniczną lub zleca jej wytworzenie kontrolując jakość | Wypracowuje wstępną dokumentację techniczna lub produktową | |||||
| Stworzenie requirements (stories), diagramów, makiet, opisów | Sa konsultowani czy diagramy, makiety, stories spełniaja swoja role i czy mogą być wdrożone. | Jest odpowiedzialny za wytworzenie stories, diagramów, makiet, opisów. Może być wytworzone przez PO lub podzlecone. | Wykonuje diagramy i opisy techniczne. Zapoznaje się z diagramami, makietami. | Wspiera wytworzenie diagramów, makiet, opisów etc. | |||||
| Konsultacje z dostawcami zewn. | Jest odpowiedzialny za konsultacje z dostawcami zewnętrznymi | Wspiera techniczne konsultacje. | Wspiera lub prowadzi konsultacje. | ||||||
| Zdefiniowanie i mitygacja ryzyk | Wskazuje ryzyka i wspiera wypracowanie mityganty. | Prowadzi rejestr ryzyk dla projektu, wskazuje ryzyka wraz z zesolem i wypracowuje mityganty. Dla ryzyk, ktorych team nie moze sam zaadresowac, informuje o nich na komitecie ds ryzyk projektowych. (do utworzenia) | Wskazuje ryzyka i prowadzi wspólny rejestr ryzyk oraz wypracowuje mityganty. | Wskazuje ryzyka i wspiera wypracowanie mityganty. Na zlecenie PO moze prowadzic rejestr ryzyk | Wskazuje ryzyka i wspiera wypracowanie mityganty. | Wskazuje ryzyka i wspiera wypracowanie mityganty. | |||
| Definicja DoD | Kontrybuuje do DoD i wypelnia DoD. | Ustala DoD wraz z calym Delivery dla release’ow produkcyjnych i wdraza DoD do zespolu. Moze w porozumieniu z zespolem dopisac dodatkowe punkty do zespolu i ustalic dodatkowe zasady dotyczace DoD wewnatrz zespolu | Kontrybuuje do DoD i wypelnia DoD. | Kontrybuuje do DoD i wypelnia DoD. | Kontrybuuje do DoD i wypelnia DoD. | Kontrybuuje do DoD i wypelnia DoD. | |||
| Zebranie doprecyzowanego szacowania | Wspiera potencjalne przekroczenia budzetu. | Zbiera informacje o finalnym szacowanym koszcie i jezeli nastepuje przekroczenie budzetu zgodnie z Framework Współpracy w Organizacji nalezy zaraportowac niezwlocznie, poinformowac Product Managera, ktory ma obowiazek postawic projekt ponownie na T2. | Kontrybuuje do zebrania prawidlowych oszacowan kosztów projektow. | Kontrybuuje do zebrania prawidlowych oszacowan kosztów projektow. | Kontrybuuje do zebrania prawidlowych oszacowan kosztów projektow. | Kontrybuuje do zebrania prawidlowych oszacowan kosztów projektow. | |||
| Uzupełnienie karty projektu i dokumentacji | Aktualizuje informacje w karcie projektu, aby uwzglednic informacje zebrane z analizy systemowej. | ||||||||
| Dodatkowa analiza (opcjonalnie) | Wspiera Product Ownera w dodatkowej analizie. | Jezeli projekt wymaga re-modelacji po analizie systemowej koordynuje dodatkowa analize | Wspiera dodatkowa analizę projektu. | Wspiera dodatkowa analizę projektu. | Wspiera dodatkowa analizę projektu. | Wspiera dodatkowa analizę projektu. | Wspiera dodatkowa analizę projektu. | ||
| Dodatkowe konsultacje (opcjonalnie) | Wspiera Product Ownera w dodatkowych konsultacjach. | Jezeli projekt wymaga re-modelacji po analizie systemowej koordynuje dodatkowa konsultacje. | Wspiera dodatkowe konsultacje w projekcie. | Wspiera dodatkowe konsultacje w projekcie. | Wspiera dodatkowe konsultacje w projekcie. | Wspiera dodatkowe konsultacje w projekcie. | Wspiera dodatkowe konsultacje w projekcie. | ||
| Uzupełnienie karty projektu i dokumentacji (opcjonalnie) | Aktualizuje informacje w karcie projektu, aby uwzględnić informacje zebrane z analizy uzupełniającej. | ||||||||
| Rozpisanie zadań | Product Owner koordynuje rozpisanie zadan, tak aby odpowiadaly zapotrzebowaniu projektu, rozpisuje zadania produktowe. | Lider IT wraz z zespolem rozpisuja zadania niezbedne do realizacji projektu | Rozpisuje zadania niezbedne do realizacji projektu | Rozpisuje zadania niezbedne do realizacji projektu | Rozpisuje zadania niezbedne do realizacji projektu | Wspieraja rozpisanie zadan niezbednych do realizacji projektu | |||
| Ustalenie planu projektu | Product Owner wraz z zespolem ustala kolejnosc działań w projekcie. | Ustala z Product Ownerem kolejnosc dzialan w projekcie | Ustala z Product Ownerem kolejnosc dzialan w projekcie | Ustala z Product Ownerem kolejnosc dzialan w projekcie | Ustala z Product Ownerem kolejnosc dzialan w projekcie | ||||
| Decyzja o rozpoczęciu prac | Wspolnie z zespolem podejmuja decyzje o rozpoczeciu prac przy projekcie zgodnie z zasadami przyjetymi w danym teamie. Jest glosem wiodacym o decyzji rozpoczecia projektu. | Wspolnie z zespolem podejmuja decyzje o rozpoczeciu prac przy projekcie zgodnie z zasadami przyjetymi w danym teamie. | Wspolnie z zespolem podejmuja decyzje o rozpoczeciu prac przy projekcie zgodnie z zasadami przyjetymi w danym teamie. | Wspolnie z zespolem podejmuja decyzje o rozpoczeciu prac przy projekcie zgodnie z zasadami przyjetymi w danym teamie. | Wspolnie z zespolem podejmuja decyzje o rozpoczeciu prac przy projekcie zgodnie z zasadami przyjetymi w danym teamie. | ||||
| Kickoff | Wspieraja kick off | Product Owner inicjuje start projektu i potwierdza mozliwosc wprowadzania zadan na backlog sprintu teamu | Wspiera kick off | Wspiera kick off | Wspiera kick off | Wspiera kick off | |||
| Prace zgodnie z określonymi wymaganiami | Prowadzi pracy zgodnie z okreslonymi wymaganiami, upewnia sie, ze realizacja projektu jest zgodna z definicja przekazana od sponsora projektu. | Wspiera Product Owner’a w w realizacji prac zgodnie z okreslonymi wymaganiami | Wspiera Product Owner’a w w realizacji prac zgodnie z okreslonymi wymaganiami | Wspiera Product Owner’a w w realizacji prac zgodnie z okreslonymi wymaganiami | Wspiera Product Owner’a w w realizacji prac zgodnie z okreslonymi wymaganiami | ||||
| Planowanie | Ustala wraz z zespolem cel sprintu i zakres backlogu sprintu | Wspiera ustalenie celu i aktywnie bierze udzial przy ustaleniu backlogu sprintu | Wspiera ustalenie celu i aktywnie bierze udzial przy ustaleniu backlogu sprintu | Wspiera ustalenie celu i aktywnie bierze udzial przy ustaleniu backlogu sprintu | Wspiera ustalenie celu i aktywnie bierze udzial przy ustaleniu backlogu sprintu | ||||
| Realizacja zadań | Jest dostepny dla teamu w przypadku pytan. Realizuje zadania z zakresu przygotowania produktu | Realizuje zadania. | Realizuje zadania. | Realizuje zadania. | |||||
| Review | Bierze udział w review | Bierze udział w review | Bierze udział w Review | Wraz z zespolem prowadzi review i prezentuje postępy pracy | Prezentuje postępy pracy | Prezentuje postępy pracy | Prezentuje postępy pracy | Prezentuje postępy pracy | |
| Przekazanie do testów (docelowo testy powinny byc w zakresu sprintu) | Wspiera/Koordynuje przekazanie informacji do QA celem realizacji testów | Wspiera/Koordynuje przekazanie informacji do QA celem realizacji testów | Odbiera informacje o zakresie testów do przeprowadzenia | ||||||
| Aktualizacja KP, dokumentacji, wymagań | Zapewnia aktualizacje karty projektu, dokumentacji, wymagan | Wspiera aktualizacje karty projektu, dokumentacji, wymagan | Wspiera aktualizacje karty projektu, dokumentacji, wymagan | Wspiera aktualizacje karty projektu, dokumentacji, wymagan | Wspiera aktualizacje karty projektu, dokumentacji, wymagan | ||||
| Przegląd postępu, kontrola budżetu | Prowadzi wysokopoziomowy nadzor nad budzetem i realizacja projektów, czerpie i przetwarza informacje uzyskana od product ownera | Aktualizuje zakres godzin zuzytych, godzin pozostalych, dostarcza informacji o koniecznosci rozszerzenia zakresu godzinowego | Wspiera informowanie o zakresie godzin zuzytych w czasie projektu poprzez prawidlowe raportowanie czasu zuzytego na zadania. | Wspiera informowanie o zakresie godzin zuzytych w czasie projektu poprzez prawidlowe raportowanie czasu zuzytego na zadania. | Wspiera informowanie o zakresie godzin zuzytych w czasie projektu poprzez prawidlowe raportowanie czasu zuzytego na zadania. | ||||
| Sytuacja wyjątkowa | Podczas interakcji z Sponsorem/Interesariuszami zbiera feedback i reaguje na sytuacje wyjatkowe, jak np zgloszenie zmiany zakresu projektu, ktorych nie mozna zaadresowac w zakresie obecnym projektu. Zglasza do osob zainteresowanych | O wszystkich sytuacjach wyjątkowych ze swojego obszaru pracy raportuje do Product Ownera. | O wszystkich sytuacjach wyjątkowych ze swojego obszaru pracy raportuje do Product Ownera. | O wszystkich sytuacjach wyjątkowych ze swojego obszaru pracy raportuje do Product Ownera. | O wszystkich sytuacjach wyjątkowych ze swojego obszaru pracy raportuje do Product Ownera. | ||||
| Prace zgodnie z określonymi wymaganiami | Product Manager wspiera Product Ownera w zaadresowaniu pracy niezgodnie z wymaganiami. | Jezeli nastepuje zmiana zakresu wymagam, postep projektu nie jest zgodny z pierwotnymi zalozeniami informuje product managera | Jezeli nastepuje zmiana zakresu wymagam, postep projektu nie jest zgodny z pierwotnymi zalozeniami informuje product ownera | Jezeli nastepuje zmiana zakresu wymagam, postep projektu nie jest zgodny z pierwotnymi zalozeniami informuje product ownera | Jezeli nastepuje zmiana zakresu wymagam, postep projektu nie jest zgodny z pierwotnymi zalozeniami informuje product ownera | Jezeli nastepuje zmiana zakresu wymagam, postep projektu nie jest zgodny z pierwotnymi zalozeniami informuje product ownera | |||
| Testy QA | Product Owner definiuje wraz z QA i zespolem zakresu testow i planuje ich wykonanie | Uczestniczy w zaplanowaniu testow QA i wspiera ich wykonanie | Uczestniczy w zaplanowaniu testow QA i realizuje ich wykonanie | Uczestniczy w zaplanowaniu testow QA i wspiera ich wykonanie | |||||
| Testy akceptacyjne | Interesuje sie | Product Owner definiuje wraz z QA i zespolem zakres testow i planuje ich wykonanie | Uczestniczy w zaplanowaniu testow akceptacyjnych i wspiera ich wykonanie | Uczestniczy w zaplanowaniu testow akceptacyjnych i realizuje ich wykonanie. Raportuje niezbedne poprawki do wykonania | Uczestniczy w zaplanowaniu testow akceptacyjnych i wspiera ich wykonanie | ||||
| Poprawki | Realizuje niezbedne poprawki do wykonania | Realizuje niezbedne poprawki do wykonania | Realizuje niezbedne poprawki do wykonania | Wspiera przygotowanie poprawek | Realizuje niezbedne poprawki do wykonania | ||||
| Przygotowanie do wdrożenia | Jest informowany o planie wdrozenia | Jest informowany o planie wdrozenia | Jest informowany o planie wdrozenia | Koordynuje przygotowanie do wdrozenia. Komunikuje sie z zespolami wspierajacymi, interesariuszami i sponsorem celem upewnienia sie ze sa gotowi na wdrozenie | Koordynuje przygotowanie do wdrożenia. Komunikuje się z zespołami technicznymi, które musza wesprzeć techniczne wdrożenie, upewnia się, ze osoby pracujace przy utrzymaniu maja niezbedna wiedze do wsparcia zmiany. | Wspiera przygotowanie do wdrozenia | Wspiera przygotowanie do wdrozenia | ||
| Wdrożenie | Jest informowany o wdrozeniu | Jest informowany o wdrozeniu | Jest informowany o wdrozeniu | Koordynuje wdrożenie holistycznie | Koordynuje wdrożenie techniczne | Wspiera wdrożenie | Wspiera wdrożenie | Wspiera wdrożenie | |
| Aktualizacja dokumentacji | Wspiera przygotowanie aktualizacji dokumentacji. | Koordynuje badz wykonuje aktualizację dokumentacji produktowej. | Koordynuje badz wykonuje aktualizację dokumentacji technicznej do produktu | Wspiera przygotowanie aktualizacji dokumentacji. | Wspiera przygotowanie aktualizacji dokumentacji. | Wspiera przygotowanie aktualizacji dokumentacji. | Wspiera przygotowanie aktualizacji dokumentacji. | ||
| Poinformowanie o zmianach (to jest do zmiany na potwierdzenie zakończenia wprowadzania zmiany) | Informuje o zakończeniu wdrażania do produkcji i potwierdza stan produktu po wprowadzeniu zmian | Wspiera sprawdzenie stanu produktu po wprowadzeniu zmian | Wspiera sprawdzenie stanu produktu po wprowadzeniu zmian (koncept regresywnych testów, do zaadresowania) | Wspiera sprawdzenie stanu produktu po wprowadzeniu zmian | Wspiera sprawdzenie stanu produktu po wprowadzeniu zmian. | ||||
| Organizacja warsztatów (do przedyskutowania) | Product Manager upewnia się, że informacja o zrealizowanym wdrożeniu dociera do organizacji. | Product Owner upewnia się, że informacja o zrealizowanym wdrożeniu dociera do organizacji. | Wspiera Product Owner w informowaniu organizacji | Wspiera Product Owner w informowaniu organizacji | Wspiera Product Owner w informowaniu organizacji | ||||
| Post na blog (do zmiany na post informujacy o zmianie) | Product Manager upewnia się, że informacja o zrealizowanym wdrożeniu dociera do organizacji. | Product Owner upewnia się, że informacja o zrealizowanym wdrożeniu dociera do organizacji. | Wspiera Product Owner w informowaniu organizacji | Wspiera Product Owner w informowaniu organizacji | Wspiera Product Owner w informowaniu organizacji | ||||
| Retro (do uzgodnienia czy retro do projektu) | Prowadzi Retro do projektu, aby zebrać know-how dotyczące prowadzenia projektu, jest to inne retro niz retro scrum’owe. Dla projektów, w których widzi potrzebę, doprasza interesariuszy do udziału w retro. | Wspiera prowadzenie retro z projektu, aby w pelni zebrac know-how. | Wspiera prowadzenie retro z projektu, aby w pelni zebrac know-how. | Wspiera prowadzenie retro z projektu, aby w pelni zebrac know-how. | Wspiera prowadzenie retro z projektu, aby w pelni zebrac know-how. | ||||
| Aktualizacja dat, WH, statusu | Product Owner aktualizuje wszystkie informacje: daty, stan wykorzystanie godzin i status projektu | ||||||||
| Zamknięcie karty projektu i epiki | Product Owner uzupełnia i zamyka kartę projektu i epiki | ||||||||
| Przekazanie do komercjalizacji (potwierdzenie kwalifikacji do komercjalizacji jest przed T2, tutaj możemy miec podsumowanie godzin do komercjalizacji) | Product Manager współpracuje ze Sponsorem projektu/Businessem celem komercjalizacji aspektów wytworzonych w projekcie. | Product Owner wspiera przekazanie projektu do komercjalizacji, poprzez przekazanie wszystkich informacji niezbędnych do wsparcia tego procesu do Product Managera |
Narzędzia
Karta projektu w PMF
Karta projektu została opisana w odrębnym dokumencie: Project Card Management - Karta Projektu
DoD dla pojedynczych zadań w Jirze
Aby dodać DoD do zadań, wykorzystujemy funkcjonalność “checklist”. Dostęp do nich uzyskamy tak jak na poniższym obrazku:
Wybieramy “checklisty”
Przeglądamy rodzaje checklist
Klikając “Set default” wybieramy interesujący nas rodzaj listy i przypisujemy je do wybranych typów zadań (podążaj za oknami dialogowymi)
Szacowanie zadań na sprint
Istnieją dwie szkoły szacowania zadań, gdzie Story Point to:
Określenie trudności zadania
Określenie czasochłonności zadania
Wielu Scrum Masterów broni pierwszego podejścia. Niestety w rutynie pracy produktowca trudno jest przełożyć taką metodykę na odpowiednie zaplanowanie prac na sprint. Przykład: co zrobić z zadaniem prostym (1) ale czasochłonnym ( wymaga ręcznej edycji wielu plików, a zrobienie automatu nie jest opcją)? Takie problemy wymagały by każdorazowo planowania innej liczby story pointów na sprint. W rezultacie story pointy przestały by instrumentem niosącym wartość dla Teamu, a stały by się obciążeniem.
Dlatego rekomendujemy używanie story pointów zgodnie z drugą strategią. Takie podejście pozwoli nam ujednolicić planowanie między zespołami, otworzy możliwość rzetelnego planowania pojemności sprintu i sukcesywnego poprawiania jakości oszacowań.
Story pointy mają oznaczać nie dokładną liczbę roboczogodzin, ale luźne ich zakresy:
1 SP - do 1h
2 SP - do 3h
3 SP - do 5h
5 SP - do 10h
8 SP - do 16h
13 SP - do 24h
21 SP - NO GO! 
(zadania oszacowane na 21 muszą zostać rozłożone na zadania składowe)
Standard dokumentacji technicznej
Temat nie został jeszcze opracowany. Po określeniu, standard zostanie tu opublikowany.
Zarządzanie zmianą
Do decyzji Product Ownera pozostają mniejsze zmiany wymagań/decyzje projektowe, nieingerujące w istniejące procesy. Większe zostają zgłaszane do Product Managera i Sponsora. W ich gestii jest podjęcie decyzji o kontynuowaniu projektu ze zmienionymi Wymaganiami i zmianie harmonogramu.
Każdy znaczące zmiany wymagań/decyzji powinny być naniesione na istniejące Wymagania i do Dziennika Zdarzeń.
Komunikacja z Interesariuszami
Założeniem głównym jest komunikacja poprzez Kartę Projektu (KP), która jest przejrzysta, transparentna i dostępna dla wszystkich zainteresowanych. KP na bieżąco zostaje aktualizowana, a kluczowe zdarzenia zostają odnotowane w Dzienniku Zdarzeń (DZ). Interesariusze wewnętrzni mają dostęp do karty i są powiadamiani automatycznie (po wcześniejszym zaobserwowaniu) o zmianach w KP. W przypadku braku istotnych zmian Interesariusze nie są powiadamiani drogą bezpośrednią, ale mogą sprawdzić status projektu poprzez przejrzenie Wymagań i ich statusów czy Dziennika Zdarzeń. Do decyzji PO / PM pozostaje bezpośrednie informowanie Interesariuszy w sytuacjach, w których uzna to za stosowne. Komunikacja z Interesariuszami zewnętrznymi zostaje w gestii PO.
Mierniki & KPI dla projektów
Każdy z Product Ownerów, podczas rozpoczętego projektu ma w swoim zakresie również mierzenie elementarnych aspektów projektów:
Stopień zaawansowania projektu (Project Completion):
Modyfikowana 50/50 reguła - gdy nie można określić WH
15%, gdy projekt ma rozpoczętą analizę systemowa - wyznaczyc termin, w ktorym powinnismy osiagnac ten stan.
35%, gdy rozpoczął się development - wyznaczyc termin, w ktorym powinnismy osiagnac ten stan.
50% gdy jesteśmy w połowie developmentu - wyznaczyc termin, w ktorym powinnismy osiagnac ten stan.
80% gdy development się zakończył i projekt zbliża się ku wdrożeniu.
Project Completion (Stopień zaawansowania projektu)
Wzór
gdzie:
PC - project completion
BurntWH - spalone roboczogodziny
LeftWH - roboczogodziny planowane do zakończenia prac
d - zespoły/projekty wewnątrz Delivery
nd - zespoły/projekty poza Delivery
Definicje:
Nazwa pola w Jira | Opis pola | Link do administracji polem |
|---|---|---|
WH planned in Delivery | WH zaplanowane w Delivery. Zostanie przerobione na PLN. Podaj tylko WH swojej epiki, nie podawaj WH innych zespołów Delivery. Pole jest dostępne zarówno w Epicach, jak również w Programie (gdzie agregujemy wartości z Epiców) | https://bluemedia.atlassian.net/secure/admin/EditCustomField!default.jspa?id=10784 |
WH planned outside Delivery | WH zaplanowane poza Delivery. Zostanie przerobione na PLN. Podaj Obszar i ilość WH. Pole znajduje się tylko w Programie.
Do pola liczbowego dołączone jest również pole tekstowe w celu rozpisania szczegółów składających się na wartość końcową, np. | https://bluemedia.atlassian.net/secure/admin/EditCustomField!default.jspa?id=10790 |
WH burnt in Delivery | WH dotychczas spalone na realizacje wewnątrz Delivery. Logika jak przy WH planned in Delivery. | https://bluemedia.atlassian.net/secure/admin/EditCustomField!default.jspa?id=10791 |
WH burnt outside Delivery | WH dotychczas spalone na realizacje wewnątrz Delivery. Logika jak przy WH planned outside Delivery. | https://bluemedia.atlassian.net/secure/admin/EditCustomField!default.jspa?id=10909 |
WF left in Delivery | WH pozostałe do utylizacji wewnątrz Delivery. Logika jak przy WH planned in Delivery. | https://bluemedia.atlassian.net/secure/admin/EditCustomField!default.jspa?id=10910 |
WH left outside Delivery | WH pozostałe do utylizacji poza Delivery. Logika jak przy WH planned outside Delivery. | https://bluemedia.atlassian.net/secure/admin/EditCustomField!default.jspa?id=10911 |
Uzupełnij tylko gdy jesteś właścicielem programu.Project On Time - stosunek zaplanowanych terminów realizacji projektu do faktycznych terminów jego realizacji. Obliczamy liczbę dni między planowaną datą startu, a terminem ukończenia. Następnie obliczamy liczbę dni między faktyczną datą startu, a osiągniętym terminem realizacji. Dzielimy liczbę dni skonsumowanych przez liczbę dni zaplanowanych i porównujemy z poniższą drabinką
Wynik w zakresie (0; 1,2>: zielono
Wynik w zakresie (1,2; 1,4>: pomarańczowo
Wynik w zakresie (1,4; ∞): czerwono
Przykład:
Project in Budget
Ilość zużytych godzin/Ilość pozostałych godzin w projekcie [w ujęciu PLN czyli przemnożona przez stawki godzinowe];
ilość godzin oszacowanych w fazie analizy szczegółowej - przemnożone przez stawkę godzinowa dla danego zespołu
ilość godzin zużytych (jeżeli jesteś Product Ownerem prowadzącym inicjatywę, to prezentujesz tą informację ze wszystkich zaangażowanych obszarów, jeżeli jesteś Product Ownerem wykonującym część prac przy inicjatywie to raportujesz do prowadzącego Product Ownera) - zgodnie z danymi zaraportowanymi przez team
ilość godzin pozostałych do zużycia - metoda ekspercka - IT lead/Non-IT lead
KPI = (Zużyte + planowane do zużycia) / Oszacowane w analizie szczegółowej
Na zielono
- wszystko do 1,2Na pomarańczowo
- pomiędzy 1,2 a 1,4Na czerwono
- wszystko powyżej 1,4
Project in Scope - mierzone liczbą CR projektowych:
Na zielono
- wszystko do 1,2 change requestow zgłoszonych w trakcie trwania projektuNa pomarańczowo
- od 3 - 4 change requestow zgłoszonych w trakcie trwania projektuNa czerwono
- powyżej 4 change requestow zgłoszonych w trakcie trwania projektu
Project in Risk:
Na zielono
- brakNa pomarańczowo
- zagrożenia, które posiadają mityganty i wiemy jak nimi zarządzicNa czerwono
- zagrożenia, dla których nie posiadamy mitygantów i należy zaangażować inne departamenty osób, żeby uzgodnić mityganty.
Governance
Wydarzenia scrum/kanban - wewnątrz Zespołu - Governance projektu sprawujemy zgodnie z framework’iem scrum, metoda kanban, mianowicie korzystając z wydarzeń typowych dla scrum nadzorujemy wykonanie projektu i aktualizujemy karte projektu po każdym review i planning.
Wydarzenie Risk Meeting - wewnątrz Delivery - sprawdzamy wspólnie dla Bramki Płatniczej i pozostałych produktów, wszystkie trwające projekty i ich metryki, z uwzględnieniem ryzyk wewnętrznych miedzy-teamowych i zewnętrznych, poza Delivery.
Raport “Reporting Delivery” - z Delivery do Organizacji - docelowo chcemy przedstawiać status projektów na raporcie “Reporting Delivery”, dlatego będziemy pracowali w kierunku takim, aby uwzględnić wszystkie niezbedne metryki i KPI na raporcie “Reporting Delivery”.
Podsumowanie działań i dalsze akcje
Katarzyna Dmitrus Szymon Pająk 07 Jul 2023
Karta projekty:
Stworzenie karty projektu (makra, aktualizacja terminów projektu zgodnie z jira) https://bluemedia.atlassian.net/wiki/spaces/SMS/pages/1625981273 - Joanna Wojnicz Kacper Saweryn
Stworzenie opisu do karty projekty (Przygotowanie kompendium, FAQ, zasad korzystania z Jiry w aspekcie prowadzenia projektów) - Powinna być to przykładowa karta projektu z wytłumaczeniem co jest czym Joanna Wojnicz Kacper Saweryn
Zdefiniowanie wymaganych pól do projektu NON-IT. - Kształt karty projektu NON-IT taki sam jak IT. Joanna Wojnicz Kacper Saweryn
Stworzenie Checklisty interesariuszy Mirek Schitniewski Monika Bieszke
Stworzenie standardu uniwersalnego DoD (DoD powinno być dostosowane później per projekt) Mirek Schitniewski Monika Bieszke
Standard user stories (tam gdzie możliwe do zastosowania) i podział na wymagania funkcjonalne i niefunkcjonalne Joanna Wojnicz Kacper Saweryn - propozycja
Aktorzy w PMF i ich role
Stworzenie definicji Tech Lead/Lidera IT/PM PO i funkcji wewnątrz zespołów Katarzyna Dmitrus Szymon Pająk
Opis ról w PMF Katarzyna Dmitrus Szymon Pająk
Współpraca z QA
Stworzenie / odszukanie instrukcji współpracy z QA → do podrasowania / wpięcia w nowy framework Zadania dla zespołu QA | W jaki sposób zgłaszamy zapotrzebowanie na testy, ?. Dotychczas zapotrzebowanie można było zgłaszać poprzez kolejkę na SD. W procesie NPI zespół QA jest angażowany w wycenę. Prawdopodobnie przyda się konsultacja z Urszula Surmacewicz jak i czy usprawnić obecny proces. Katarzyna Dmitrus Kamila Świercz
Komunikacja z Interesariuszami
Odpytanie Interesariuszy / Zespołów czy powyższe jest dla nich zrozumiałe i akceptowalne Katarzyna Dmitrus Kamila Świercz
Inne
Brak kryteriów akceptacji pojedynczych zadań → do podpatrzenia w Payments Online Templates Szymon Pająk do doprecyzowania o co chodzi
Stworzenie dwóch szablonów pracy: dla kanban i dla scrum, z nałożeniem schematu na wielkość zespołu. Katarzyna Dmitrus pogada z Szymon Pająk
Standaryzacja sposobów szacowania zadań - ważne z punktu widzenia KPI i benchmarku pracownika ← KD 7.07: do przegadania później poza frameworkiem w Product Ownership Framework
Udostępnienie narzędzia do tworzenia zależności?
Template Kickoffu → KD 7.07: zaadresujemy w Product Ownership Framework
Stworzenie dobrych praktyk / templatu Retro ← nie chodzi o samo retro ale o wdrożenie pkt z retro → KD 7.07: zaadresujemy w Product Ownership Framework
Template Review → zaadresujemy w Product Ownership Framework
Przyjęcie/stworzenie standardu dokumentacji technicznych Szymon Pająk Jakub Demczuk i produktowych Patrycja Lasocka → KD 7.07: docelowo Szymon i Kuba jako glowni architekci wypracuja w przyszlosci. Na ten moment nie bedzie podejmowana praca w tym zakresie
Ustalenie prowadzenia projektów nadrzędnych zbierających w sobie podprojekty realizowane w poszczególnych zespołach. https://www.wrike.com/project-management-guide/faq/what-is-a-project-charter-in-project-management/ ← szkolenie z Jira i manual Jakub Demczuk KD 7.07: na razie to zostawmy.
Szkolenie ogólne z Jira ← wyciąganie poszczególnych informacji Jakub Demczuk
“raportowanie postępów - konsultacje z interesariuszami” - zdefiniować propozycje metodyk KD 7.07: na razie to zostawmy.
Mierniki & KPI dla projektów
sprawdzic gotowosc Jira na wprowadzanie danych niezbednych do zbierania mierników projektowych Szymon Pająk do 31.07
wprowadzenie planned date start & planned date end + executed date start & executed date end
Project in budget - czy mozna wprowadzic jakas logike, ktora bedzie obliczala nam szacunek czy projekt w budzecie?
Project in Scope - mierzone iloscia CR projektowych - do rekomendacji przez PO w jaki sposob administruja change requestami Katarzyna Dmitrus do 31.07
Project in Risk - do rekomendacji przez PO w jakis sposob i czy w ogole amidnistruja ryzykiem w projektach Katarzyna Dmitrus do 31.07
Karta projekty TO DO:
Stworzenie opisu do karty projekty (Przygotowanie kompendium, FAQ, zasad korzystania z Jiry w aspekcie prowadzenia projektów) - poprawki Szymon Pająk do 31.07
Opiniowanie frameworku Project Managememt Katarzyna Dmitrus Szymon Pająk do 31.07
QA Szymon Pająk
Teamy bramkowe Jakub Demczuk
szczegolne uwzglednienie czy kanbanowcy maja jakies potrzeby zmian
Teamy nie-bramkowe Szymon Pająk
szczegolne uwzglednienie czy kanbanowcy maja jakies potrzeby zmian
Finance Katarzyna Dmitrus
Devops Szymon Pająk
szczegolne uwzglednienie czy kanbanowcy maja jakies potrzeby zmian
SRE (AM, Monitoring, DBA) Szymon Pająk
SecOps Szymon Pająk
szczegolne uwzglednienie czy kanbanowcy maja jakies potrzeby zmian
Chief of Delivery Szymon Pająk
Experience Katarzyna Dmitrus
Product Managers Katarzyna Dmitrus
Procurement Katarzyna Dmitrus