Framework Współpracy w Organizacji
Diagram Procesu
Start - Zgłoszenie inicjatywy w ramach NPI i przejście do etapu Tollgate 1
Weryfikacja lub uzupełnienie dokumentacji wymogów kapitalizacji
Proces Management Framework, a Framework Współpracy w Organizacji
Historia zmian
Rozwiń historię
Wersja | Data | Autor | Opis zmiany |
|---|---|---|---|
1.4 | 30 Oct 2023 |
| |
1.3.3 | 19 Sep 2023 | Dodanie informacji o potrzebie tworzenia Epicu do zadań typu CR. | |
1.3.2 | 14 Sep 2023 | Nowa automatyka dot. powiadomień o zmianach statusów inicjatyw. | |
1.3.1 | 21 Jul 2023 | Nowa automatyka dot. kapitalizacji. | |
1.3 | 28 Jun 2023 | Zmiany rozmiarów koszulek w fazie analizy T-Shirt | |
1.2.1 | 31 May 2023 |
| |
1.2.0 | 26 May 2023 |
| |
1.1.3 | 02 May 2023 |
| |
1.1.2 | 26 Apr 2023 |
| |
1.1.1 | 12 Apr 2023 |
| |
1.1.0 | 03 Apr 2023 | Szymon Pająk Slawomir Gawinowski Paweł Stanka Katarzyna Dmitrus | Odświeżenie opisów, dodanie ścieżek dla Change Request oraz Quality |
1.0.0 | 25 Jan 2023 - 17 Mar 2023 | Katarzyna Dmitrus Slawomir Gawinowski Przemysław Ciesielski (Unlicensed) Jakub Demczuk Marek Kalwajtys | Pierwsza wersja opisu Frameworku Współpracy |
Cel
Usystematyzowanie współpracy w Organizacji w zakresie tworzenia nowych i modyfikowania istniejących produktów
Optymalizacja efektywności wykorzystania zasobów Organizacji poprzez lepsze planowanie zapotrzebowania i alokację sił
Poprawienie komunikacji między zespołami Organizacji
Wdrożenie metryk jakościowych (KPI): pomiar i podejmowanie decyzji w oparciu o dane
Monitoring zwrotu poniesionych inwestycji (ROI) dla prowadzonych projektów, w tym kontrola osiągania przyjętych założeń biznesowych
Definicje
BUL - Business Unit Leader - szef jednostki organizacyjnej odpowiedzialnej za relacje biznesowe (Business Unit), https://bluemedia.atlassian.net/wiki/spaces/ITD/pages/1658094028
Chief - szef jednostki organizacyjnej wspierającej (wytwarzanie, operacje, legal itp), https://bluemedia.atlassian.net/wiki/spaces/ITD/pages/1658094028
Sponsor - właściciel budżetu, z którego finansowane jest przedsięwzięcie. Sponsorem może być BUL, Chief ale i inni: Sponsor - jak wybrać dla zadania
PO - Product Owner: PM/PO - odpowiedzialność
PM - Product Manager: PM/PO - odpowiedzialność
SRE Officer - szef (lub wskazany zastępca) zespołu SRE https://bluemedia.atlassian.net/wiki/spaces/SRE
Komisja (ds. Inicjatyw) - zbiór osób złożonych ze sponsorów, Chiefów, PMów, który podejmuje wiążące decyzja na spotkania typu Tollgate
Experience - zespół marketingu
Feedback - zespół operacyjny
Clarity - zespół compliance-legal
Finance - zespół finansów
Delivery - zespół wytwórczy
Diagram Procesu
źródło diagramu:
Opis procesu
Zgłoszenie Inicjatywy
Na początku było słowo. Powstaje idea. Po uzyskaniu akceptacji Sponsora pomysł zgłaszany jest jako inicjatywa. Zakładamy ją za pomocą Service Desk, używając formularza: https://bluemedia.atlassian.net/servicedesk/customer/portal/36/group/114/create/370
Zakres pól do wypełnia
Kliknij aby zobaczyć listę opisów pól
Pole | Opis |
|---|---|
Raise this request on behalf of | Osoba w imieniu której zamawiamy inicjatywę. Możemy zamawiać w imieniu swoim lub np BUL. |
Summary | Wpiszę nazwę inicjatywy w taki sposób, aby oddawała co chcemy wdrożyć/zmienić |
Business Account Manager | Opiekun biznesowy. Kto jest odpowiedzialny od strony biznesowej za daną inicjatywę |
Sponsor | Sponsor, czyli jednostka, która odpowiada za budżet przeznaczony na realizację przedsięwzięcia |
Category | Rodzaj inicjatywy:
|
Submit for tax verification | Czy wymagana jest weryfikacja inicjatywy pod kątem podatkowym? Patrz: Weryfikacja podatkowa |
Type of change | Geneza powstania inicjatywy:
|
Target segments | Branża, do której kierowana jest zmiana. |
Sales channel | Kanał sprzedaży |
Product | |
Business Attachments | Market Analysis: Wskaż jak wygląda rynek dla danej inicjatywy (produktu), jaki jest potencjał rynku (np. liczba Partnerów, Klientów, itp), główni konkurenci (liczba, opis), analiza trendów (np. na rynkach zagranicznych), skalowalność, szanse, zagrożenia P&L: Oszacuj przychody w perspektywie 1/2/3 uwzględniając koszty bezpośrednie:
Customer Journey: opis interakcji, które klienci mają z produktem lub marką od momentu pierwszej świadomości istnienia produktu lub usługi, aż po dokonanie zakupu i ewentualne działania po zakupowe. Poczytaj: https://socjomania.pl/co-to-jest-customer-journey. Process Flow: opis sekwencji działań, które muszą zostać wykonane w produkcie/procesie, aby osiągnąć określony cel lub wynik. Może być reprezentowany w formie diagramu przepływu, który pokazuje kolejność i zależności między różnymi etapami projektu. Use Cases: Opisz przykład użycia dla danej inicjatywy (produktu) - przykład (finansowanie merchantów) - merchant posiadający bramkę płatniczą BM z obrotami dostanie informacje w panelu o możliwości dodatkowego finansowania w postaci pożyczki, akceptacja warunków za pomocą kodu sms, spłata automatyczna z obrotów na bramce zgodnie z ustalonym % spłaty. Poczytaj: https://home.agh.edu.pl/~regulski/psk/cw/01_UseCase.pdf |
Stakeholders | Wskaż wszystkich interesariuszy, którzy będą zaangażowani w proces wytworzenia, sprzedaży i utrzymania produktu |
Business Model | Plan który określa, jak inicjatywa wygeneruje przychody, oraz jaką wartość dostarczy klientom, interesariuszom, właścicielom, pracownikom, dostawcom. Opiera się na analizie rynku i konkurencji, identyfikacji grup docelowych, wyborze sposobu dystrybucji oraz określeniu źródeł przychodów. Może mieć różne formy, w zależności od rodzaju branży, produktów lub usług, jakie ma opisać. Krótko mówiąc: opisz w jaki sposób chcemy zarabiać/oszczędzać na danej inicjatywie. |
Business Acceptance Criteria | Kryteria które muszą zostać spełnione przez projekt lub produkt, aby był on zaakceptowany przez interesariuszy biznesowych, tzn. osoby lub organizacje, które będą korzystać z projektu lub produktu w celu osiągnięcia celów biznesowych. Kryteria te określają, jakie cechy, funkcjonalności, wydajność lub inne wymagania muszą zostać spełnione, aby produkt lub projekt był uznany za zakończony i gotowy do użycia. Ich określenie pozwala uniknąć nieporozumień między klientem a wykonawcą projektu oraz zwiększa szanse na sukces projektu. |
Rollout Mode | Skala projektu, model wdrożenia: od PoC po masowe wdrożenie dla wszystkich klientów. |
Priority | Priorytet po stronie zleceniodawcy BLOCKER- kluczowy dla działania BU/Organizacja pod kątem przychodów i/lub działania organizacyjnego HIGH- konieczny do realizacji, ale może zostać odłożony w czasie (zarówno pod kątem pracy operacyjnej oraz wzrostu przychodów) NORMAL- nie będący kluczowy dla BU/Organizacji pod kątem pracy operacyjnej oraz wzrostu przychodów |
Expected gross margin description | Opis oczekiwanej marży brutto |
Expected gross margin in 1st year | Planowana marża brutto w 1. roku działania |
Expected gross margin in 2nd year | Planowana marża brutto w 2. roku działania |
Due date | Do jakiej daty inicjatywa musi być zrealizowana |
Description | Opis dodatkowy |
Kwalifikacja typu zgłoszenia
Na podstawie wartości w polu Category wybierana jest dalsza ścieżka procedowania inicjatywy:
Change Request
Zmiana w istniejącym produkcie/procesie
Wynikająca z potrzeb produktu/procesu - wartość w słowniku: CR
Wynikająca z incydentu - wartość w słowniku: CR - corrective action (quality)
Zmiana realizowana w ramach jednego zespołu. Jakakolwiek współpraca z innymi zespołami IT oznacza wyjście do ścieżki NPI
Zmiana nie tworzy potencjału marżowego (aby uniknąć używania CR do przesączania przez nie projektów)
Jeśli planowana zmiana ma interesariuszy np w obszarach Feedback, negatywnie bądź pozytywnie (generuje koszt/oszczędność), wymagana jest zgoda tych obszarów na przeprowadzenie zmiany.
Limit roboczogodzin na realizację do 50 wh (60% czasu jednego deva w 2-tygodniowym sprincie) - wymiar umowny, w jego zakresie musi zmieścić się wszystko, od analizy, po uruchomienie i odbiór
Kwalifikacja CR przebiega następująco:
Product Owner dowiaduje się o nowym zadaniu:
Poprzez powiadomienie mejlowe wylane przez automat w Jira
Dla projektów niebramkowych powiadomienie kierowane jest bezpośrednio do PO
Dla projektów bramkowych:
Automat dokonuje próby przypisania PO, ale z racji złożoności bramki może mu się to nie powieść
Powstaje rola strażaka CR - jest to rotacyjnie zmieniający się PO z obszaru bramki, który będzie rozstrzygał właściwego adresata CRki
Poprzez przegląd kolejek w projekcie PRODUKT:
Bramka: https://bluemedia.atlassian.net/jira/servicedesk/projects/PRODUKT/queues/custom/487
Rozliczenia: https://bluemedia.atlassian.net/jira/servicedesk/projects/PRODUKT/queues/custom/486
Topup: https://bluemedia.atlassian.net/jira/servicedesk/projects/PRODUKT/queues/custom/485
Weryfikacje: https://bluemedia.atlassian.net/jira/servicedesk/projects/PRODUKT/queues/custom/482
Komunikacja (SMS): https://bluemedia.atlassian.net/jira/servicedesk/projects/PRODUKT/queues/custom/484
Instant Money Transfer: https://bluemedia.atlassian.net/jira/servicedesk/projects/PRODUKT/queues/custom/483
Wygląd przykładowej kolejki:
Product Owner zaopatrzony w swoje doświadczenie, możliwość kontaktu z zespołem technicznym i powyższą definicję CR akceptuje zadanie jako CR lub odrzuca (ustawia w NEED FEEDBACK ze stosownym komentarzem uzasadniającym decyzję)
CR, który jest zaakceptowany przez PO, powinien:
Być wprowadzony w status SCHEDULED
Mieć ustawione pola:
Team
Product Manager
Recommended Product Owner/Program Manager
Stworzony epic na kolejce, na której powstaną zadania do realizacji zadania. Uwaga. Epic musi mieć uzupełnione pole “Parent link”, które prowadzi do zadania typu Program na kolejce PRODUKT z powstałą CRką - dzięki temu raporty będą mogłby poprawnie policzyć koszt realizacji CR od poziomu programu, po szeregowe zadania.
Zarządzanie i realizacja Change Requestem opisana jest w rozdziale Realizacja Change Request
Quality
Kwalifikacja Quality przebiega następująco:
Po złożeniu inicjatywy z kategorią Quality - subcategory Jira ustala priorytet zgodnie z Roadmap (Quality part) i wysyła powiadomienie do szefa zespołu https://bluemedia.atlassian.net/wiki/spaces/SRE
Szef SRE akceptuje zadanie do wybranej kategorii albo odrzuca (ustawia w NEED FEEDBACK ze stosownym komentarzem uzasadniającym decyzję)
Zakładając zadania z kategorią typu działania naprawcze lub projekt naprawczy, nie musisz już dodawać etykiety DZIALANIA_NAPRAWCZE. Sama kategoria zadania jest wystarczającym oznaczeniem, które pozwoli wyszukać inicjatywy wygenerowane przez incydenty.
Zarządzanie i realizacja inicjatywą Quality opisana jest w rozdziale Realizacja Quality
NPI
NPI to domyślny i podstawowy sposób zlecania realizacji prac po stronie Delivery. Pomysły, których realizacja nie może być zakwalifikowana jako CR albo Quality, trafia w ścieżkę NPI.
Po złożeniu inicjatywy zadanie czeka na przegląd przez przedstawiciela zespołów Delivery i Experience, którzy oceniają kompletność zadania z punktu widzenia założeń formalnych (patrz zakres pól do wypełnienia karty)
Przedstawiciele ww zespołów akceptują inicjatywę i trafia ona w stan oczekiwania na TOLLAGATE 1 albo odrzucają do uzupełnienia (status NEED FEEDBACK ze stosownym komentarzem uzasadniającym decyzję)
Zarządzanie i realizacja inicjatywą w ścieżce NPI opisana jest w rozdziale Realizacja NPI
Realizacja Change Request
Change requesty dla produktów można przeglądać używając:
Widoku roadmapy https://bluemedia.atlassian.net/jira/plans/1/scenarios/1?vid=1#plan/backlog po zastosowaniu odpowiednich filtrów: na kategorię inicjatywy i produkt
Kolejek wewnątrz projektu PRODUKT (powyżej)
Zasady realizacji CR:
Priorytetami na kolejce Change Requestów zarządza Product Manager produktu.
Product Manger ma prawo scedować odpowiedzialność za zarządzanie priorytetami na wybranych Product Ownerów lub Team Leaderów/Managerów IT pracujących nad danymi produktami.
Change Request, który ma zostać zrealizowany powinien być w stosownym momencie przestawiony w status IMPLEMENTATION oraz powinno powstać zadanie powiązane, w projekcie/na kolejce zespołu, który danym CR się zajmie.
Realizacja inicjatyw typu CR powinna być prowadzona przy pomocy zasobów gwarantowanych przez Roadmap - zasady przydziału czasu
Zachować zespołom spójność ich bardów sprintowych/kanbanowych
Zarządzalność tempem realizacji CR i weryfikację ich kosztów
Realizacja Quality
Realizacja projektów z kategorii Quality przebiega analogicznie jak projektów z kategorii NPI.
Różnice dla kategorii Quality względem NPI sprowadzają się do nastepujących punktów:
Priorytetyzacja inicjatyw obliczana jest nie według kalkulatorów zgodności ze strategią i rentowności lecz matryc dostępnych w panelu rozwijanym pod niniejszą listą
Rolę Komisji ds Inicjatyw pełni **szef zespołu ** https://bluemedia.atlassian.net/wiki/spaces/SRE. Po akceptacji ustawia status T-SHIRT ANALYSIS .
Zarządzanie relacją zgłoszonej inicjatywy jakościowej względem innych inicjatyw NPI przejmuje Product Manager lub osoba, na którą taką odpowiedzialność sceduje.
Realizacja inicjatyw typu Quality powinna być prowadzona przy pomocy zasobów gwarantowanych przez Roadmap - zasady przydziału czasu
Mechanizm priorytetyzacji inicjatyw Quality
Rozwiń aby zobaczyć kryteria do priorytetyzacji inicjatyw
Artykuł zawiera algorytm na priorytetyzację projektów wchodzących w skład części jakościowej roadmap-y ( **Quality **) .
Informację dotyczące całej Roadmap-y można znaleźć pod linkiem: Roadmap - zasady przydziału czasu
Link do Roadmap-y na Jira: Roadmap
Project category | Project priority | Conditions | ||||||
|---|---|---|---|---|---|---|---|---|
Quality - architects Projekty:
| Conditions | Examples | ||||||
:blocker: :important: :high: |
|
| ||||||
:medium: |
|
| ||||||
Quality - corrective projects (compliance) Działania naprawcze po incydentach Konieczność dostosowania systemów do regulacji wynikająca z błędów lun nowych regulacji, potencjalna kara z organu nadzoru
| Risk level | Impact
| ||||||
:blocker: :important: | CRITICAL | Potential financial loss | Potential financial loss | Potential financial loss | Potential financial loss | |||
:high: | HIGH | LOW | MEDIUM | HIGH | CRITICAL | |||
:medium: | MEDIUM | Probability Aspekty do rozważenia:
| Almost certain | HIGH | CRITICAL | CRITICAL | CRITICAL (:blocker: | |
:low: | LOW | Likely | HIGH | HIGH | CRITICAL | CRITICAL | ||
Possible | MEDIUM | HIGH | HIGH | CRITICAL | ||||
Unlikely | LOW | MEDIUM | HIGH | HIGH | ||||
Rare | LOW | LOW | MEDIUM | HIGH | ||||
Quality - corrective projects (IT) i Quality - corrective projects (operational) Projekty powstałe jako działania naprawcze, głównie po incydentach IT lub operacyjnych. | Risk level | Impact | ||||||
:blocker: :important: | CRITICAL | Incident SEV-4 (no one is affected) | Incident SEV-3 (anyone affected) | Incident SEV-2 (some group affected, impact on SLA) | Incident SEV-1 (everyone affected, impact on SLA) | |||
:high: | HIGH | LOW | MEDIUM | HIGH | CRITICAL | |||
:medium: | MEDIUM | Almost certain | HIGH | CRITICAL | CRITICAL | CRITICAL :blocker: | ||
:low: | LOW | Likely | HIGH | HIGH | CRITICAL | CRITICAL | ||
Possible | MEDIUM | HIGH | HIGH | CRITICAL | ||||
Unlikely | LOW | MEDIUM | HIGH | HIGH | ||||
Rare | LOW | LOW | MEDIUM | HIGH | ||||
Quality - debt Projekty likwidujące dług technologiczny:
| Upgrade debt [months] (systemy otagowane NEWLEGACY) | Sonar debt - effort [days] (systemy otagowane NEWLEGACY) | W przypadku systemów otagowanych jako DEBT, czyli nierozwijanych gdzie dług upgrade-u lub sonar-a jest bardzo duży priorytety nadawane są indywidualnie i mogą wynikać np. z kwestii Security (np. krytyczne podatności, konieczność podbicia wersji Javy w związku z wersjami TLS) | |||||
:blocker: :important: | > 24 | > 90 | ||||||
:high: | 12 - 24 | 30 - 90 | ||||||
:medium: | 6 - 12 | 5 - 30 | ||||||
:low: | < 6 | < 5 | ||||||
Quality - corrective projects (risk)
| Risk level | Impact | ||||||
:blocker: :important: | CRITICAL | Direct financial loss | Direct financial loss | Direct financial loss | Direct financial loss | |||
:high: | HIGH | LOW | MEDIUM | HIGH | CRITICAL | |||
:medium: | MEDIUM | Almost certain | HIGH | CRITICAL | CRITICAL | CRITICAL :blocker: | ||
:low: | LOW | Likely | HIGH | HIGH | CRITICAL | CRITICAL | ||
Possible | MEDIUM | HIGH | HIGH | CRITICAL | ||||
Unlikely | LOW | MEDIUM | HIGH | HIGH | ||||
Rare | LOW | LOW | MEDIUM | HIGH | ||||
Realizacja NPI
Tollgate 1
Inicjatywa spełniająca wymogi formalne oczekuje na prezentację i omówienie na spotkaniu Komisji TOLLAGATE 1. Lista uczestników i termin spotkań TOLLAGATE 1 znajdują się w tabeli na dole rozdziału.
Na spotkaniu TOLLAGATE 1:
Autor inicjatywy przedstawia jej zakres i wynikające z realizacji korzyści.
Prowadzący spotkanie lub wskazana osoba wprowadza parametry inicjatywy do kalkulatora
Projekty jakościowe. Ostatnia zakładka w: https://en.wikipedia.org/wiki/HTTP_404
Projektów marżowe. Ostatnia zakładka w: Business_case_NPI_marżowe_v3.xlsx
Priorytetyzacja uwzględnia takie parametry jak:
mandat (brak wdrożenia może wstrzymać pracę operacyjną/sprzedaż produktu/zostanie naliczona kara itp.)
zgodność ze strategią Organizacji
skalowalność (liczba zainteresowanych Business Unitów)
dochodowość/rentowność w okresie 1Y/2Y
Dostępne zasoby oraz potencjalną możliwość pozyskania zasobów wspierających
PR i innowacyjność
W przypadku braku ustalenia listy priorytetów decyzja należy do Komisji ds. inicjatyw, a w przypadku niepowodzenia może zostać eskalowana do Zarządu
Zgromadzeni podejmują decyzję o statusie GO / NO GO
Inicjatywy które nie dostają zgody na realizację przenosimy w status WON'T DO z komentarzem
Inicjatywy które dostają zgodę na realizację:
Dostają przypisanie do Product Managera
Umieszczamy inicjatywę w statusieT-SHIRT ANALYSIS, w którym będzie czekać na spotkanie z analizą koszulkowej. Wprowadzenie w status oczekiwania na analizę T-Shirt jest odpowiedzialnością PMa albo klienta procesu (osoby definiującej wymagania). Należy zadbać o to, aby inicjatywa nie pozostawiała wiele pola do interpretacji dla osób technicznych, możliwe więc, że wymagane jest wstępne porozmawianie z wybranymi technikami i analitykami jeszcze przed spotkaniem T-Shirt.
(opcjonalnie) Zapisywana jest informacja o konieczności przeprowadzenia fazy Discovery. Za zlecenie Discovery odpowiedzialny jest
Analiza T-Shirt
Cel i przebieg spotkania analizy T-Shirt opisany jest poniżej:
Opis analizy T-Shirt
What
Analiza T-Shirtowa to technika szacowania złożoności przedsięwzięcia. Stosowana jest w metodykach zwinnych. W największym skrócie polega na kolektywnej ocenie trudności zadania poprzez nadanie mu etykiety rozmiaru pochodzącej ze świata odzieży: XS, S, M, L, XL, 2XL.
Relacja między etykietą rozmiaru, a kryjącą się za nią wartością jest umowna i nie musi być stała. Zależnie od kontekstu i zasad danego szacowania mogą to być: godziny, dni, tygodnie, pieniądze, itp.
Lektura dodatkowa:
When
Analiza T-Shirtowa jest elementem procesu Framework Współpracy w Organizacji pojawiającym się po bramce T1. Przejście inicjatywy przez te bramkę oznacza wstępną kwalifikację do realizacji. W tym momencie pojawia się potrzeba wstępnej oceny złożoności technologicznej i zlokalizowania ryzyk i punktów wymagających pogłębionej analizy w kolejnej fazie.
Spotkania analizy T-Shirt odbywają się zgodnie z kalendarzem opisanym w dokumencie Framework Współpracy w Organizacji
Who
W spotkaniu wziąć udział mają członkowie zespołu Delivery Struktura:
Przynajmniej jeden analityk z zespołu System and Business Analysis
Przynajmniej jeden delivery manager - wskazane przejęcie roli moderatora spotkania
Przedstawiciele zespołów
Wszyscy team leader'owie zespołów developerskich
Product Managerowie, Product Ownerzy z Delivery
How
Board do przeglądania inicjatyw, które pojawiły się po T1
Zadania oczekujące na wycenę znajdziemy na boardzie harmonogramu:
https://bluemedia.atlassian.net/jira/plans/1/scenarios/1?vid=1#plan/backlog
po zastosowaniu filtrowania:
Członkowie spotkania powinni zapoznać się ze znajdującymi się na boardzie inicjatywami, aby być wstępnie przygotowanymi na spotkanie i dzięki temu przeprowadzić je maksymalnie sprawnie.
Tablica rozmiarów
Rozmiar | Czasochłonność prac | Czasochłonność prac |
|---|---|---|
XXS | 1 | n/d |
XS | 3 | 1-8 (dzień) |
S | 10 | 9-24 (do 3 dni) |
M | 30 | 25-80 (do 10 dni) |
L | 90 | 81-240 (do 30 dni) |
XL | 150 | 241-720 (do 90 dni) |
XXL | 150+ | 721-… |
Metodyka przeprowadzania analizy T-Shirt
Moderator dyskusji:
Zbiera deklaracje zespołów odnośnie zaangażowania w projekt
Wypełnia pole Engages Delivery Teams, które będzie niosło informację, w jakich zespołach wymagana jest dalsza analiza szczegółowa.
Zbiera od przedstawicieli zespołów deklaracje wycen i sumuje je do pola T-Shirt Estimate
Wprowadza dodatkowe informacje o
kosztach operacyjnych (stworzenia nowej operacji, przeprowadzania ich)
proponowanym Product Ownerze, Program Managerze
inne informacje, które w trakcie dyskusji zostaną uznane za kluczowe dla projektu
W sytuacji karty o opisie uniemożliwiającym ocenę trudności realizacji inicjatywy, wyklucza ją z procedowania, ustawia w status NEED_FEEDBACK i wprowadza komentarz do karty, wywołując założyciela karty z prośbą o przygotowanie karty do następnej (lub dodatkowej) fazy analizy T-Shirt
Zadania są gotowe do dalszego procedowania NPI.
Rezultat T-SHIRT ANALYSIS przekłada się na proces NPI w następujący sposób:
Zadania, które pozytywnie przeszły analizę:
Otrzymują oznaczenie, które zespoły biorą udział w realizacji inicjatywy
Otrzymują składowe złożoności per zespół + sumę całościową
(opcjonalnie) Otrzymują wstępne przypisanie o kosztach CAPEX/OPEX po stronie zespołów Experience - UX, Clarity i Feedback
Zostają przypisane do rekomendowanego Product Ownera
Zadania, które nie przeszły analizy są cofane do NEED FEEDBACK celem dostarczenia informacji, których braki zostały obnażone a spotkaniu.
Po zamknięciu fazy T-SHIRT ANALYSIS Product Manager jest odpowiedzialny za przygotowanie inicjatywy do spotkania TOLLAGATE 2
Discovery
Faza DISCOVERY jest fazą opcjonalną. Sponsor, inicjator przedsięwzięcia lub Product Manager jest odpowiedzialny za to, żeby tę fazę zainicjować.
Zespołem realizującym prace w fazie DISCOVERY jest zespół Experience. Faza składa się z dwóch etapów:
Praca nad **Model Canvas **(https://bossblog.pl/model-canvas-na-czym-polega/ )
model przygotowywany jest przez Sponsora lub autora inicjatywy
analiza sposobu komercjalizacji, umów, wybór partnerów do współpracy, itd.
Badanie z klientami
Po zamknięciu fazy DISCOVERY Product Manager jest odpowiedzialny za przekierowanie inicjatywy do spotkania T-SHIRT ANALYSIS
Weryfikacja Business Case
W tej fazie dział Finansów dokonuje weryfikacji przygotowanego Business Case’u. Product Manager jest odpowiedzialny za przekierowanie inicjatywy do weryfikacji, której ślad to wpis w polach:
Business Case Acceptance (wartości tak/nie)
Business Case Acceptance Comment
Inicjatywa bez akceptacji Business Case nie może trafić na TOLLAGATE 2
Link do kolejki inicjatyw do weryfikacji: https://bluemedia.atlassian.net/jira/servicedesk/projects/PRODUKT/queues/custom/488
Kwalifikacja do kapitalizacji
W tej fazie dział Finansów dokonuje weryfikacji czy wartość generowana w ramach inicjatywy ma potencjał kapitalizacyjny (Czym jest kapitalizacja.
Weryfikacja możliwości skapitalizowania projektu nie jest elementem blokującym proces NPI.
Informacja o rezultacie kwalifikacji znajduje się w polach:
Capitalization Qualification
Capitalization Qualification Comment
Link do kolejki inicjatyw do weryfikacji: https://bluemedia.atlassian.net/jira/servicedesk/projects/PRODUKT/queues/custom/489
Opis procesu kwalifikacji i kapitalizacji
Diagram procesu 2
Opis
Start - Zgłoszenie inicjatywy w ramach NPI i przejście do etapu Tollgate 1
Każda inicjatywa zgłoszona w procesie NPI z kategorii: "NPI" lub "Quality", po przejściu do etapu Tollgate 1 trafia na kolejkę weryfikacji pod kątem możliwości kapitalizacji.
Zgłoszenie typu "CR" nie trafia na kolejkę weryfikacji po kątem kapitalizacji. CR nie spełnia wymogu kapitalizacji w zakresie limitu roboczogodzin 100 WH.
Jeśli realizujesz projekt poza procesem NPI albo procedujesz "CR" będący elementem większej całości (skądinąd wiesz, że kapitalizowanej) albo masz po prostu wątpliwości - zgłoś się indywidualnie do Działu Sprawozdawczości (Dorota Podgórska) - mailowo lub poprzez Teams.
Weryfikacja możliwości kapitalizacji
Dział Sprawozdawczości weryfikuje projekty które znajdą się w kolejce weryfikacji kapitalizacji:
Na tym etapie Dział Sprawozdawczości kontaktuje się z PM/PO celem omówienie projektu i uzyskania odpowiednich informacji do podjęcia decyzji czy projekt jest pracą rozwojową i klasyfikuje się do kapitalizacji.
Informacje które uzyskuje Dział Sprawozdawczości to m.in.:
rodzaj projektu (opis merytoryczny)
cel biznesowy
przewidywane korzyści ekonomiczne (sposób wykorzystania rezultatów)
planowane etapy
planowane ramy czasowe
planowana czasochłonność
planowane koszty zewnętrzne
w jaki sposób będzie finansowana realizacja (środki własne czy finansowanie obce)
czy projekt jest dotowany
Na podstawie otrzymanych informacji Dział Sprawozdawczości wspólnie z Product Managerem (PM) lub Product Ownerem (PO) podejmuje decyzję o przyjęciu projektu do kapitalizacji lub odrzuceniu projektu.
Warunki które muszą zostać spełnione żeby projekt został uznany za pracę rozwojową i zaklasyfikowany do kapitalizacji:
produkt lub technologia wytwarzania są ściśle ustalone, a dotyczące ich koszty prac rozwojowych wiarygodnie określone,
techniczna przydatność produktu lub technologii została stwierdzona i odpowiednio udokumentowana i na tej podstawie jednostka podjęła decyzję o wytwarzaniu tych produktów lub stosowaniu technologii,
koszty prac rozwojowych zostaną pokryte, według przewidywań, przychodami ze sprzedaży tych produktów lub zastosowania technologii
Dodatkowe warunki przyjęcia projektu do kapitalizacji:
planowana czasochłonność projektu powyżej 100 WH
Więcej informacji znajdziecie tu: Czym jest kapitalizacja i tu: https://bluemedia.atlassian.net/wiki/spaces/KP/pages/1480818700/Kapitalizacja+proces+i+wytyczne
Pozytywne zakwalifikowanie projektu do kapitalizacji
Po podjęciu decyzji, osoba odpowiedzialna z Działu Sprawozdawczości:
Uzupełnia pole "Capitalization Qualification" jako "yes" (projekt kapitalizowany) lub "no" (projekt odrzucony)
W polu "Capitalization Qualification Comment" umieszcza krótką informację dotyczącą kryterium zaklasyfikowania do kapitalizacji lub odrzucenia
Oznacza zadanie labelem "kapitalizacja"
Ocenia inicjatywy Tollgate 2 Decyzja
Do momentu fazy "Toll Gate 2 approval" - projekt jest w fazie badawczej, nie jest kapitalizowany. Oznacza to, że czas pracy poświęcony do tej fazy jest traktowany jako koszt.
Po uzyskaniu akceptacji w fazie "Toll Gate 2 approval" i wejściu w fazę "Analysis" nastepuje rozpoczęcie kapitalizacji projektu. Od tego momentu godziny logowane na projekcie na JIRA podlegają wycenie i kapitalizacji.
Podjęcie decyzji o nierealizowaniu projektu - status "won't do" - projekt nie jest brany pod uwagę w dalszym procesie kapitalizacji (oznaczenie "no" w polu "Capitalisation Qualification").
Powiadomienie o zmianie statusu
Po wejściu projektu w fazę "Analysis" Dział Sprawozdawczości otrzymuje automatyczne mailowe powiadomienie. Osoba z Działu Sprawozdawczości uzyskuje potwierdzenie od PO/PM, że projekt wszedł w fazę "Analysis" i się rozpoczął. Dział Sprawozdawczości rozpoczyna kapitalizację projektu.
Weryfikacja lub uzupełnienie dokumentacji wymogów kapitalizacji
Po przyjęciu projektu do kapitalizacji PO lub PM dokonuje uzupełnienia dokumentacji projektowej maksymalnie w ciągu miesiąca od wejścia projektu w fazę "Analysis", czyli rozpoczęcia fazy rozwojowej projektu i kapitalizacji. Dokumentacja projektowa powinna zawierać elementy/informacje zgodnie z kartą projektu (załącznik nr 2). Dokumentacja projektowa umieszczana jest na stronie projektu na JIRA w zakładce "Capitalization".
W wyjątkowych przypadkach po uzyskaniu akceptacji Działu Sprawozdawczości dokumentacja może zostać przygotowana w formie word/PDF.
Dokumentacja obowiązkowo musi zawierać określenie przyszłych korzyści ekonomicznych. W przypadku gdy korzyści ekonomiczne to przychody- dokumentacja powinna zawierać projekcje finansowe przychodów przynajmniej na kolejne 5 lat. W przypadku gdy przyszłe korzyści ekonomiczne to ograniczenie kosztów- kalkulacji oszczędności lub opis ograniczeń kosztowych.
Weryfikacja opisu danych o kapitalizacji
Dział Sprawozdawczości dokonuje weryfikacji formalno-merytorycznej dokumentacji i przekazuje informację o ewentualnych brakach w dokumentacji/wymaganych poprawkach do PO/PM. Osoba odpowiedzialna niezwłocznie uzupełnia dokumentację lub udziela odpowiednich wyjaśnień.
Rozpoczęcie kapitalizacji projektu
PO/PM powiadamia pracowników realizujacych prace projektowe (również pracowników wspomagających prace projektowe z innych działów) o tym, że projekt podlega kapitalizacji (praca rozwojowa) oraz o konieczności logowania czasu pracy w JIRA pod podanym programem/epiciem/zadaniem. Czas pracy powinien być logowany na bieżąco (czas pracy za dany miesiąc powinien zostać zalogowany maksymalnie do 2 dnich roboczych po zakończeniu miesiąca). W przypadku osób które nie logują czasu pracy w JIRA, zobowiązane są każdorazowo do przesyłania raportu z przepracowanymi godzinami do Działu Sprawozdawczości. Osoby zobowiązane są do załączenia godzin do 2 dnia roboczego po zakończeniu miesiąca.
Raportowanie przepracowanych godzin w Excelu wg musi być raportowane wg wzoru:
Dział Sprawozdawczości dokonuje przeliczenia godzin projektowych wskazanych w JIRA pracowników na podstawie wwygenerowanego raportu z zarejestrowanym czasem pracy z JIRA lub plików Excel, list płac oraz faktur (pracownicy B2B). Następnie przekazuje informację o dokonanym przeliczeniu do Działu Księgowości w formie PK. Pełna kalkulacja powinna zostać zapisana w dedykowanym miejscu na sharepoincie. Informacja dotycząca kapitalizacji kosztów zewnętrznych do przeksięgowania zostaje przekazana do Księgowości.
W przypadku nowego projektu pracownik Działu Księgowości tworzy konto księgowego 084-XXX (Nazwa projektu).
Osoby wykonujące prace na danym projekcie, zobowiązane są do rejestracji czasu pracy w JIRA pod parent/epiciem/zadaniem projektu lub przekazaniem godzin w formie Excela do Działu Sprawozdawczości.
Proces autoryzacji dokumentów PK kapitalizacji, obywa się zgodnie z procesem autoryzacji dokumentów PK.
Weryfikacja kalkulacji kompletności kapitalizacji
Dział sprawozdawczości dokonuje weryfikacji raportu kalkulacji kapitalizacji. Dział sprawodawczości dokonuje analizy zaraportowanych godzin w JIRA oznaczonych labelem "kapitalizacja" a nie skapitalizowanych w danym miesiącu.
Weryfikacja liczby epiców oraz liczby zadań podpiętych do projektu
PO/PM dokonuje comiesięcznej weryfikacji czy wszystkie epici/zadania dotyczące projektu są podpięte pod odpowiedni program (parent link) projektu. Rekomendowaną metodą weryfikacji jest weryfikacja opisana w Komunikat ws wytycznej KPMG
Weryfikacja zaraportowanych godzin w JIRA na projekcie
PO/PM dokonuje comiesięcznej weryfikacji zaraportowanych godzin w JIRA na danym projekcie.
Przekazywanie informacji o fv zewnętrznych oraz osobach nieraportujących w JIRA
Project Manager/Product Owner lub osoba odpowiedzialna z innego działu przekazuje do Działu Sprawozdawczości oraz do Działu Księgowości informacje o kosztach zewnętrznych (fakturach zewnętrznych) poniesionych w związku z prowadzeniem prac rozwojowych na danym projekcie. Informacje które powinien przekazać Project Manager to nazwa kontrahenta, nr faktury, kwota faktury, jeżeli tylko cześć faktury dotyczy prac rozwojowych, należy również przekazać specyfikację ze wskazaniem prac rozwojowych dotyczących projektu. Informacje powinny zostać przekazane poprzez Webcon (komentarz w Webconie) lub mailowo. Faktura zewnętrzna która dotyczy kapitalizowanego projektu powinna zostać oznaczona w Webconie jako “kapitalizacja - TAK”.
Project Manager/Product Owner lub osoba odpowiedzialna z innego działu przekazuje do Działu Sprawozdawczości informacje o osobach pracujących przy projekcie i nie logujących czasu pracy w JIRA.
Weryfikacja etapu projektu oraz przesłanek utraty wartości
Dział Sprawozdawczości dokonuje comiesięcznej weryfikacji etapu projektu (na podstawie statusów w JIRA). W przypadku projektów które są w zawieszeniu (status on hold lub brak rejestrowawnych godzin przez dłuższy czas niż 3 miesiące) wysyła zapytanie do PO/PM w zakresie statusu projektu. Na tej podstawie Dział Sprawozdawczości wraz z PO/PM projektu podejmuje decyzję o dokonaniu ewentualnego odpisu aktualizującego projektu.
Weryfikacja zaksięgowanej kapitalizacji
Dział Sprawozdawczości dokonuje weryfikacji zaksięgowanej kapitalizacji poprzez wyciągnięcie odpowiednich sald/obrotów i zapisów z systemu ksiegowego CDN i porównaniu do raportu kapitalizacji oraz informacji uzyskanej na temat faktur zewnętrznych dotyczących kapitalizowanych projektów.
Wdrożenie produkcyjne
PO/PM przesyła informacje o dacie zakończenia i wdrożeniu produkcyjnym projektu (pracy rozwojowej) do Działu Sprawozdawczości.
Przeliczenie finalne
Finalne przeliczenie wartości projektu oraz przekazanie informacji do Działu Księgowości o zakończeniu projektu i przyjęciu do użytkowania (OT) - aktywowanie zakończonej pracy rozwojowej
W przypadku braków przeciwskazań Dział sprawozdawczości przekazuje informację do Działu księgowości o zakończeniu kapitalizacji.
Dział księgowości dokonuje przeksięgowania kosztów z konta 084_XXX (Nazwa projektu) na konto 020-XXX (Nazwa projektu) Koszty zakończonych prac rozwojowych oraz przyjęcia WNIP.
Dział księgowości w konsultacji z Kierownikiem działu sprawozdawczości oraz PM/PO dokonuje ustalenia okresu ekonomicznej użyteczności rezultatów prac rozwojowych, zgodnie z polityką rachunkowości.
Przyjęcie WNIP zostaje udokumentowane w formie dokumentu OT.
Przygotowanie dokumentacji dla zakończonej pracy rozwojowej
Po zakończeniu pracy rozwojowej i przyjęciu do użytkowania, Dział Sprawozdawczości przygotowuje komplet dokumentacji który zawiera: dokumentację opisową, raport godzin z JIRA/POZA-JIRA, rapot z kalkulacją (wyceną godzin), zestawieniem faktur zewnętrznych, OT. Komplet dokumentacji zapisywany jest w dedykowanym miejscu na Sharepoincie.
Coroczna weryfikacja przesłanek utraty wartości
Nie rzadziej niż na dzień bilansowy, Dział Sprawozdawczości wraz z Kierownikiem działu Produkt lub innego działu dokonuje analizy przesłanek utraty wartości aktywowanych prac rowojowych, poprzez analizę prognozowanych przyszłych korzyści ekonomicznych pracy rozwojowej . W przypadku stwierdzenia przesłanek utraty wartości, lub całkowitego zaprzestania projektu Kierownik Działu Sprawozdawczości dokonuje kalkulacji odpisu i przekazuje ją do działu księgowości do zaksięgowania.
Weryfikacja podatkowa
W tej fazie dział Finansów dokonuje weryfikacji czy inicjatywa wywołuje następstwa podatkowe.
Weryfikacja ta nie jest elementem blokującym proces NPI.
Informacja o rezultacie kwalifikacji znajduje się w polach:
Tax Verification
Tax Verification Comment
Link do kolejki inicjatyw do weryfikacji: https://bluemedia.atlassian.net/jira/servicedesk/projects/PRODUKT/queues/custom/490
Jak stwierdzić czy inicjatywa wymaga weryfikacji podatkowej
Nowy produkt wpływa na rozliczenia finansowe Spółki; wprowadza niestandardowe sposoby rozliczeń
Założeniem nowego produktu jest sprzedaż ze stawką VAT zwolnioną lub poza VAT
Nowy produkt wpływa na relacje z podmiotami powiązanymi, w tym może przenosić pomiędzy podmiotami powiązanymi funkcje, ryzyka lub aktywa
Nowy produkt wpływa na rozliczenia podatkowe Spółki, w tym może generować korzyści podatkowe (schematy podatkowe)
Nowy produkt zakłada nabycie/sprzedaż czegoś trudnego do wycenienia
Nowy produkt może zmienić formę współpracy i rozliczeń z pracownikami/kontrahentem
Tollgate 2
Po fazie T-SHIRT ANALYSIS i DISCOVERY Product Manager musi skonsolidować zgromadzone dane:
Zaktualizować Business Case
Przygotować wstępny harmonogram (wymaga współpracy z Product Ownerami wyznaczonych zespołów)
Z przygotowaną inicjatywą Product Manager przychodzi na TOLLAGATE 2:
Przedstawia zebrane informacje
Zgromadzeni podejmują decyzję o statusie GO / NO GO
Inicjatywy które nie dostają zgody na realizację przenosimy w status WON'T DO z komentarzem
Inicjatywy które dostają zgodę na realizację wchodzą w fazę analizy szczegółowej
Analysis
Szczegółowa analiza skutkuje rozpoczęciem prac po stronie zespołów wyznaczonych na etapie T-SHIRT ANALYSIS.
W tej fazie:
Angażujemy:
Analityków biznesowych i systemowych
Przedstawicieli QA
Tech Leadów zespołów
Architektów IT
Pracujemy na zadaniach zakładanych na zespołowych projektach Jira
Rezultatem fazy ANALYSIS powinny być:
Dokumentacja techniczna
Zidentyfikowane zależności między systemami
Rozpisane story do implementacji
Wstępne oszacowanie czasochłonności przygotowanych story
Weryfikacja kosztu po analizie z kosztem oszacowanym po T-SHIRT ANALYSIS
Implementation
Implementacja, czyli realizacja inicjatywy to faza głęboko zanurzona w Delivery. Zgodnie z ustalonym zakresem, harmonogramem i budżetem, zespoły pracują nad realizacją zamówionej zmiany zgodnie z metodyką tworzenia i kontroli, opisaną poniżej:
Kliknij aby rozwinąć opis Project Management Frameworku
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: Tollgate 2 i kończy przed 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 2
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:
Rozwiń
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:
Kliknij mnie
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
Stare todosy
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
Acceptance of works
Faza w której dokonywana jest weryfikacja, czy zrealizowana inicjatywa spełnia postawione wymogi biznesowe, funkcjonalnej i jakościowe.
Commercialization
Tollgate 3
Po realizacji projektu Product Manager przedstawia gotowe rozwiązanie na spotkaniu TOLLAGATE 3:
Prezentacja metryk podsumowujących projekt
Weryfikacja, czy nadal istnieje zapotrzebowanie na uruchomienie zmiany
Zgromadzeni podejmują decyzję o statusie GO / NO GO
Inicjatywy które nie dostają zgody na realizację przenosimy w status WON'T DO z komentarzem
Inicjatywy które dostają zgodę na wdrożenie, rozpoczynają procedurę roll-outu zgodnie założonym modelem i skalą
W ramach spotkania Tollgate 3 dodatkowo podsumowujemy listę przyjętych lub zrealizowanych zadań CR oraz Quality.
Lista uczestników i terminy spotkań procesu NPI
Spotkanie | Uczestnicy | Termin/częstotliwość |
|---|---|---|
TOLLAGATE 1 |
| Pierwszy wtorek każdego miesiąca. |
T-SHIRT ANALYSIS |
| Drugi wtorek każdego miesiąca.
|
TOLLAGATE 2 i TOLLAGATE 3 |
| Trzeci wtorek każdego miesiąca.
|
Automatyczne powiadomienia
Zdarzenie | Adresat | Link do konfiguracji automatu |
|---|---|---|
Utworzenie inicjatywy |
| |
Utworzenie inicjatywy - Quality |
| |
Utworzenie inicjatywy - CR |
| |
Utworzenie inicjatywy - NPI |
| |
Zmiana statusu w NEED FEEDBACK |
| https://bluemedia.atlassian.net/jira/servicedesk/projects/PRODUKT/settings/automate#/rule/10543262 |
Zmiana statusu na AWAITING TOLLGATE [X] APPROVAL |
| Przejście przez T2: https://bluemedia.atlassian.net/jira/servicedesk/projects/PRODUKT/settings/automate#/rule/14802103 |
Zmiana statusu na ANALYSIS |
| https://bluemedia.atlassian.net/jira/servicedesk/projects/PRODUKT/settings/automate#/rule/13530854 |
Uruchomienie |
| |
Zaakceptowanie business case'u (przy zaznaczonym zgłoszeniu do weryfikacji podatkowej) | https://bluemedia.atlassian.net/jira/servicedesk/projects/PRODUKT/settings/automate#/rule/11837762 |
Automatyka pozostała
Zdarzenie | Akcja | Link do konfiguracji automatu |
|---|---|---|
Utworzenie epicku na kolejce zespołowej | Przypisanie adekwatnej wartości do pola Team, zgodnie z opisami w dokumencie Struktura | https://bluemedia.atlassian.net/jira/settings/automation#/rule/12816528 |
Zalogowanie czasu pracy gdy brak w zadaniu sponsora | Wysłanie wiadomości do autora zadania i przypisanej do niego osoby z prośba o nadanie sponsora. | https://bluemedia.atlassian.net/jira/settings/automation#/rule/12860660 |
Graf przejść stanów na Jira (Workflow)
Link do bieżącego workflow obsługującego zadania typu Program znajduje się pod adresem: https://bluemedia.atlassian.net/secure/admin/workflows/WorkflowDesigner.jspa?wfName=NPI Workflow 2023_04_18&workflowMode=live
Stany grafu i przejścia między nimi starają się wiernie oddać opis procesu biznesowego zaprezentowanego na diagramie na początku tego dokumentu.
Open
Scheduled
Implementation… i dalej
Wizualizacja grafu:
Struktura zadań na Jira
Typ zadania | Liczność per inicjatywa | Opis | |
|---|---|---|---|
1 | Program | 1 | Program to najwyższy byt reprezentujący inicjatywę projekt. Skupia w sobie cały zakres prac do wykonania w organizacji, niezależnie czy suma prac do wykonania po stronie Delivery to 5, czy 1000 wh. Przykładem dużego programu jest na przykład inicjatywa rebrandingu wszystkich produktów. Przykładem małego programu jest change request polegający na dodaniu nowej kolumny w CSV w raporcie dla partnera. |
2 | Epic | N | Epic reprezentuje projekt realizowany w ramach jednego zespołu (Struktura). Epici przypisujemy do programu. Program może mieć wiele epiców |
3 | Story | N | Story reprezentuje krótki i uproszczony opis funkcji w tworzonym systemie. Grupuje pojedyncze zadania, nadaje przejrzystość inicjatywie, ułatwia zarządzanie progresem realizacji inicjatywy i komunikację między zespołami (np z QA). Story przypisujemy do epiców. Epici mogą mieć wiele story. |
4 | New feature/Improvement/Technical Task/… | N | Zadania definiujące najmniejsze elementy odpowiadające za progres w realizacji projektu. Zadania przypisujemy do story i do epiców. |
FAQ
Pytanie | Odpowiedź |
|---|---|
Komu dedykowany jest proces? | Proces służy każdemu. Każdy z pracowników ma prawo złożyć propozycję zmiany, poprawy, stworzenia czegoś nowego. W szczególności proces powstał dla tzw. Sponsorów, czyli Business Unit Leaderów i Chiefów działów, czyli osób-ról, które dysponują budżetem inwestycyjnym. |
Kiedy stosujemy proces NPI/CR? | Proces NPI/CR stosowany jest w następujących przypadkach:
|
Kiedy nie stosujemy procesu NPI/CR? | Procesu NPI/CR nie stosujemy:
|
Kto odpowiada za Business Case Inicjatywy? | Sponsor |
Kto odpowiada za realizacje budżetu projektu? | Rolą odpowiedzialną za zmieszczenie projektu w założonym budżecie jest Product Owner (patrz: PM/PO - odpowiedzialność) |
Kto odpowiada za wybór dostawców? | Dostawca rozwiązań biznesowych: Sponsor Dostawca rozwiązań technologicznych: Delivery |
Kto odpowiada za Umowy biznesowe z Partnerami? | Za Umowy odpowiada Sponsor (osoba wyznaczona), który zgłasza daną inicjatywę |