Pojawienie się pomysłu/ zapotrzebowania | 
|
| | brak szczegółowej wizji brak uzasadnionego (policzonego zapotrzebowania) mnogość wpadających tematów jest nie do przerobienia problem definiowania różnicy między IT/NON-IT brak formalizacji procesu NON-IT (fazy, role, itp) czy NON-IT podlegają kapitalizacji? czy projekty realizujemy procesem NPI, a jeśli tak, to jak?
| 
| N/D W formie docelowej, wkład do PMF będzie dostarczony z frameworka NPI |
Utworzenie wstępnej dokumentacji projektu |
|
| utworzenie karty projektu, określenie celu biznesowego, tła, oraz pożądanej daty - jeśli jest znana ustalenie roli PM (+Tech leada)
| nieprzyjemna  karta projektu, niedziałające makra w wiki. Być może nieaktualne? pytanie, czy karta projektu na tym etapie jest potrzebna? moze do odświeżenia, kiedy powinna być zakładana? projekt to 20wh - nie za mało? (dyskryminator CR/NPI bedzie realizowany w ramach Frameworku Wspolpracy) jak to połączyć z ręcznym wpisywaniem dat/wh itp na roadmapie? kształt karty projektu dla projektow NON-IT - czy taka sama jak dla IT?
| Propozycja BlueMonday: Problem karty projektu
| Użycie szablonu karty zespołu SMS i dostosowanie jej do wymagań/potrzeb reszty zespołów. Zaciągnięcie / dostosowanie wymaganych makr i innych informacji z Jiry. Możliwa konsultacja z AM. Ustalenie prowadzenia projektów nadrzędnych zbierających w sobie podprojekty realizowane w poszczególnych zepołach. Kształt karty projektu NON-IT taki sam. Zdefiniowanie wymaganych pól do projektu NON-IT.
|
Zebranie wstępnych wymagań |
|
| doprecyzowanie celu, business case'u, interesariuszy, klientów wstępne harmonogramowanie projektu
| Brak angażowania zespołów: Analitycy, AM, QA, DevOps ISS, CC Compliance/AML/DAS/Księgowość (powinno być zabezpieczone procesem przygotowania do NPI)
brak zebrania wymagań ze strony zarówno technicznej, jak i produktowej. brak lub niejasny cel brak wymogu i rozliczania business case (patrz NPI)
| Brak zdefiniowania interesariuszy na etapie definiowania wstępnych wymagań. Brak lub niejasny cel.
| Wstępne wymagania high-level dostarczone na T1 w procesie NPI. Cel powinien być jasno zdefiniowany i opisany na etapie zgłaszania inicjatywy.
|
Analiza wstępnych wymagań warsztaty doprecyzowanie zapotrzebowania analiza możliwości/outsourcing opcjonalnie - wstępna analiza prawna/w innych działach wybór lidera IT
|
|
| jeśli temat jest nowy i wzbudza wątpliwości natury prawnej, najpierw powinien być wstępnie przeanalizowany przez DPR/ Compliance (patrz NPI) rozbicie na części pierwsze zakresu na poszczególne elementy leżące po stronie różnych zespołów - rozpisanie procesów jak jest/ma być warsztaty: wyjaśnienie celu projektu, zakresu z podziałem na poszczególne wątki po stronie IT (które potem zamienią się w stories), brainstorm, Questions and Answers rozpisanie możliwych opcji i wybór optymalnych definicja DOD
| problemy z analizą biznesową i systemową - rezultatem niepełny zakres projektu brak zaangażowania zespołów QA i DevOPS brak chętnych do bycia liderem IT definicja roli TechLeada i zasad przyznania tej roli brak budowania dokumentacji (i wzięcia jej w zakres projektu) niezdefiniowane DOD DOD dla projektów NON-IT - jak powinno wyglądać? brak wiedzy w zespołach i znajomości procesów (w weryfikacjach to wynika m.in. z braku kompletnej dokumentacji biznesowo- produktowej z odniesieniami do dokumentacji technicznych) w zespole cards wstępna analiza to zespół: PM, PO i TL, dopiero wtedy wychodzi nam, ze trzeba coś zrobić jeszcze w innych zespołach i wtedy rozmowa z innymi zespołami; nie ma czegoś takiego w naszym procesie jak lider IT - w sensie, zawsze jest to ta sama osoba
rozpoczynanie prac wg dostępności kalendarza, bez uprzedniej pracy analitycznej i przygotowawczej  (patrz NPI) brak identyfikacji etapów/ kamieni milowych
| Propozycje zespołu tele-TO-BE-sie: Zdefiniowanie zakresu obowiązków roli lidera IT projektu oraz zasad demokratyzacji tej funkcji wewnątrz zespołów IT Problemy z wiedzą o systemach IT, brak dokumentacji technicznej i procesowej.
Propozycje BlueMonday:
1. Problem z identyfikacją interesariuszy
2. Problem z analizą biznesową i systemową (pkt2. tele-TO-BE-sie) | Stworzenie definicji lidera IT i funkcji wewnątrz zespołów Stworzenie checklisty zespołów i wyodrębnienie z niej interesariuszy (PO+Analityk) wśród innych zespołów Powiększenie zespołu analityków
|
Wstępne szacowanie |
|
| | wycena nie bierze pod uwagę szacowania całego zespołu lider szacuje tak, jakby to on realizował prace szacowanie w SP, a wymaganie podania WH zanim zaczniemy projekt, to trochę ciężkie do pogodzenia, zazwyczaj niedostrzelone szacowania trudne powiązania między systemami brak szacowania zadań dla produktowców, ops itp różne standardy definicji story pointów szacowanie nie uwzględnia testów, odbioru, oczekiwania na review itp
| Propozycje zespołu tele-TO-BE-sie: Nieuwzględnienie w szacowaniu kosztów produktowych oraz kosztów odbioru zadań
| Angażowanie przedstawiciela QA w faze przygotowania i rozpisania projektu Egzekucja logowania czasu przez Produkt Tworzenie zadań analitycznych/obsługowych lub logowanie czasu produkowego w zadania typu story Rozdzielenie w karcie projektu/zadaniu odrebnej komórki na koszt produktowy Uwzględnienie prac PO/PM na etapie wyceny koszulkowej. Uwzględnienie prac nad dokumentacją w wycenie koszulkowej Stworzenie kalkulatora “brutto” dla szacowania kosztu projektu
|
Doprecyzowanie wymagań |
|
| potwierdzenie możliwości i wybranych opcji ze zleceniodawcą wstępne makiety i opisy dla partnera konsultacje z zewnętrznymi dostawcami zdefiniowanie ryzyk i strategii na ich unikanie wyznaczenie metryk wyznaczenie kryteriów akceptacji
| brak oficjalnego procesu zamawiania zmian przez partnerów - aktualnie jest to wymiana maili pomiędzy różnymi osobami, kończąca się luźnym stwierdzeniem partnera “tak jest okej, tak chcemy” potwierdzanie zakresu/decyzji o losie projektu poprzez czaty na teams problematyczne jest przeniesienie zebrania wymagań na sprzedaż (co wydaje mi się ok w teorii, ale w praktyce generuje to dużo zamieszania), bo potem ustalone są rzeczy, których nie ma w BM, odkręcanie tego itp (patrz NPI) kto przeprowadza analizę ryzyka i jaką metodyką (patrz NPI) jakie metryki dla projektów NON-IT?
| Change Requesty od Partnerów/Biznesu w trakcie trwania projektu
| Do decyzji PO pozostają mniejsze CR nieingerujące w istniejące procesy, a większe/krytyczne zostają zgłaszane do PM/Sponsora do podjęcia decyzji o kontynuowaniu projektu i zmianie harmonogramu.
Każde znaczące CR powinno być naniesione na istniejące wymagania i do rejestru wydarzeń. Do użycia w każdym etapie trwania projektu. Utworzenie rejestru wydarzeń w karcie projektu.
|
Pogłębione konsultacje z innymi działami |
|
| | analiza i konsultacje trwają praktycznie przez cały czas trwania projektu, co powoduje rozszerzanie się zakresu projektu brak analityka oraz brak rozrysowanej struktury powiązań między systemami. W tym miejscu powinny się odbyć konsultacje z innymi zespołami, które mogą zostać pominięte, gdy nie został zauważony wpływ na jakąś funkcjonalność. problem z przepływem komunikacji - np. dane w złym formacie, wielość narzędzi (brak standardu) np. każdy robi diagramy w innym narzędziu
| Brak standardu narzędzi do diagramów Brak kontroli nad zakresem
| Sprawdzenie możliwości wyboru ogólnodostępnego narzędzia Zaopiekowane w pkt. 1. z Doprecyzowania wymagań
|
warsztaty i konsultacje z IT |
| 
| | przydałaby się większa wprawa/ odwaga w korzystaniu z narzędzi do spotkań online (mind maps, karteczki, rysunki, diagramy itp) brak dokumentacji technicznych (diagramy procesów), dzięki której na warsztatach mogłyby się pojawiać dodatkowe analizy brak uwzględnienia wszystkich przedstawicieli obszarów, które powinny być zaangażowane ludzie nie lubią się wypowiadać focus na zadaniach technicznych, bez aspektów jakościowych oraz bez poczucia celu niepotrzebne skupianie się na szczegółach
| Propozycje zespołu tele-TO-BE-sie: Brak dokumentacji technicznych (vide punkty powyżej) Zaangażowanie w warsztatach: brak inicjatywy ze strony uczestników, drobiazgowe rozważania nad detalami
| ad 1) Doszlifowanie kart w ARCH: Struktura obecna Rozwinięcie o elementy dla AM i Analityków oraz Produkt Wyegzekwowania używania ich (np w procedurze przekazania do AM)
ad 2) Wydelegowanie prac analitycznych na Analityków i usystematyzowanie sposobu współpracy z Analitykami. Zdefiniowanie roli TechLeada projektu i wciągnięcie jej w zakres obowiazków Devów (do uwzględnienia akceptacja TechLeada w DoD)
|
Rozpisanie zakresu projektu - produktowo i technicznie |
|
| Powinny być rozpisywane user stories user stories powinny być rozbite na szczegółowe zadania ustalenie zakresu, kamieni milowych, harmonogramu, zaplanowanie komunikacji z interesariuszami
| zbyt mało szczegółowy opis poszczególnych wątków, raczej luźno rzucone hasła na ten moment zadania u nas są rozpisywane właściwie tylko technicznie, mało tu produktowego rozpisywania (user stories) problemem jest zależność od innych zespołów IT, co jest szczególnie odczuwalne w obszarze płatności, nie do końca wiem, w którym momencie powinni i w jakim zakresie być angażowani TL i PO z innych zespołów? brak uwzględnienia:
- monitoringu
- prace zespołów operacyjnych
- elementów wypisanych DoD brak określonej kolejności zadań, zależności między zadaniami i storiesami (brak znajomości lub po prostu brak korzystania z funkcjonalności JIRY) brak precyzyjnych dat testowania brak kryteriów akceptacji zadań (brak DoD dla pojedynczych zadań) brak wyznaczania etapów, punktów kontrolnych
| Propozycje zespołu tele-TO-BE-sie: Brak kryteriów akceptacji pojedynczych zadań → do podpatrzenia w Payments Online
Propozycja BlueMonday Brak kryteriów akceptacji projektu i odniesienia do DoD Brak user stories Brak Dependency Map https://confluence.atlassian.com/jiraportfolioserver/displaying-the-dependencies-map-1005805794.html
| Tworzenie DoD i kryteriów akceptacji Wprowadzenie standardu user stories + szkolenia Udostępnienie narzędzia do tworzenia zależności
|
kickoff |
|
| | | Propozycje zespołu tele-TO-BE-sie: Brak standardowej formy
| Stworzenie (skopiowanie z jakichś dobrych temaplate'ów) takiej formuły. Du-uh |
zgłoszenie projektu do kapitalizacji |
| 
| | procedura jest chyba w trakcie zmian do ułożenia, po czyjej stronie jest odpowiedzialność za decyzję “kapitalizujemy czy nie”? jakie sa terminy zgłaszania brak znajomości procesu
| Nie wiemy jak wygląda procedura i o co chodzi.
| Określenie procedury i przeszkolenie. |
Realizacja prac |
|
| dzialania cykliczne: szacowanie aktualizacja karty projektu doprecyzowywanie wymagań raportowanie postępów - konsultacje z interesariuszami update’y przekazanie funkcjonalnosci do testowania
| przed rozpoczęciem każdego sprintu poszczególne zadania są szacowane przez zespół w Story Pointach. Tu się zaczyna pierwszy rozjazd. Drugi - po zakończeniu pracy w zadaniu, gdy mamy już rzeczywiste wh. brak informowania interesariuszy o statusie projektu brak informowania o zrealizowanym i pozostającym do zrealizowania zakresie ręczna aktualizacja wszystkiego w karcie postępująca utrata wiary w scrum logujemy tylko czas IT (a jeśli logujemy, to nie kontrolujemy spalania czasu poza IT) brak trzymania się etapów, punktów kontrolnych współpraca z QA jest zaplanowana na koniec projektu, zamiast w trakcie całego trwania brak informowania QA o tym, że coś jest realizowane i że powinni się przygotować do zmiany brak standardu komunikacyjnego i zlecanie zadań do QA w swoich projektach, a nie na SD QA brak łączenia zadań dla innych zespołów z epikiem, przez co umyka prawdziwy koszt projektu i zadania brak rejestru działań w projekcie (zmiany, problemy) brak limitu projektów per zespół organizacja działa w waterfallu, a my próbujemy realizować projekty w agile mamy problem z określeniem ról i odpowiedzialności w zespołach zdarzają się niezbalansowane teamy brak metryk mierzących jakość pracy programistów
| Propozycje zespołu tele-TO-BE-sie: Review całej metodyki agile standaryzacja sposobu szacowania zadań kanaban/angile rodzaje spotkan
Zacieśnienie relacji między bieżącą pracą, a kartą projektu (automatyzacja, element procedury, aby na niej odwzorowywać zdarzenia, statusy i decyzje) - punkt do współpracy z zespołem Blue Monday Brak zasad dzialania na jirze (rodzaje zadań, łączenia zadań, logowanie czasu)
| ad 1) Stworzenie dwóch szablonów pracy: dla kanban i dla scrum, z nałożeniem schematu na wielkość zespołu. STANDARDYZACJA SPOSOBOW SZACOWANIA ZADAN - ważne z punktu widzenia KPI i benchmraku pracownika ad 2) p. optymalizacja karty projektu (Blue Monday) ad 3) Przygotowanie kompendium, FAQ, zasad korzystania z Jiry w aspekcie prowadzenia projektów |
realizacja prac (projekt NON-IT) |
|
| | gdzie lokujemy karty projektu? notatki spotkania z todo’s
logowanie czasu przez osoby pelniące role produktowe trudność w połączeniu produktowców i ich tempa spalania z deweloperami i ich tempem - Jira bedzie te godziny probowała rozdysponować bez rozróżnienia różnego charakteru tych ról
| Karta projektu.
| Odniesienie się do DoD stworzonego wcześniej na karcie projektu. Logowanie czasu zawsze przez każdego. Jeśli wycena dot. tylko IT to stworzenie filtrów w Jira gdzie wykluczone będą osoby poza IT.
|
testy |
|
| rozpisanie scenariuszy testowych zebranie dostępów, danych i informacji potrzebnych do testowania prowadzenie dokumentacji z testów przekazywanie informacji o znalezionych błędach weryfikacja procesu przez UX
| nie wszystkie przypadki testowe/ procesy wzięte pod uwagę, co częściowo wynika z braku analizy systemowej brak pomysłu na testy nie wszystkie zespoły mają swoich testerów brak schematu - jak i kiedy przeprowadzać testy; brak reguł współpracy zespołów z QA QA powinni być uwzględniani na etapie analizy problem ze środowiskami brak środowiska testowego problem z danymi testowymi (dane bankowe, dane transakcji - nie da się przestestować bez wykorzystania danych produkcyjnych; nawet jeśli wiąże się to z wpisem w BIKu)
| Propozycje zespołu tele-TO-BE-sie: nie wszystkie zespoły mają swoich testerów brak schematu - co i jak powinno być testowane, związane z fazą analizy
| Implementacja sugestii zgłoszonych przez Urszula Surmacewicz
“Ustawowe” powiązanie testerów - osób, z zespołami i “wymuszenie” współpracy 2. Stworzenie instrukcji / podlinkowanie informacji dot. schematu współpracy z QA → w tym uwzględnienie odpowiednich kroków w DoD. |
wdrożenie |
|
| | brak narzędzi pomiarowych - KPI itp brak checklist wdrożeniowych (chodzi o IT) brak pilotażu; moment wdrożenia to koniec projektu niepełna komunikacja o problemach niektóre wdrożenia powinny się odbywać w nocy, a są realizowane w wygodnych godzinach pracy (9-12) - nieatrakcyjne stawki za prace nocne brak możliwości szybkiego znalezienia informacji co i kiedy (o której godzinie) zostało wdrożone
| Propozycje zespołu tele-TO-BE-sie: brak checklist wdrożeniowych (chodzi o IT) brak możliwości szybkiego znalezienia informacji co i kiedy (o której godzinie) zostało wdrożone
| ad 1) Przygotowanie check-list i todosów do zadań i projektów. Egzekwowanie ich na poziomie Jiry i pozniejszej analizie w sytuacji występowania awarii (benchmark pracownika) ad 2) Automatyzacja pipeline wdrożeniowego |
aktualizacja dokumentacji |
|
| | szarpana dokumentacja wewnętrzna (niepełna, porozrzucana, trudna do odnalezienia) czas na wytworzenie dokumentacji nie zawsze jest uwzględniony w zakresie projektu brak trzymania się standardów w tworzeniu i utrzymaniu dokumentacji (zarówno wew. jak i zew.) brak osoby odpowiedzialnej za dokumentację jedna informacja pojawia się w wielu miejscach i nie we wszystkich jest aktualizowana
| Propozycje zespołu tele-TO-BE-sie: brak trzymania się standardów w tworzeniu i utrzymaniu dokumentacji (zarówno wew. jak i zew.) brak osoby odpowiedzialnej za dokumentację czas na wytworzenie dokumentacji nie zawsze jest uwzględniony w zakresie projektu
| ad 1) Punkt powyżej dot ARCH. Dodatkowo warsztat z analitykami, QA i AM dot wyznaczenia standardu efektywnego dla ich pracy Dodatkowo przegląd standardów dokumentacji u konkurencji i wykorzystanie dobrych wzorców ad 2) Wskazanie takiej osoby. PO/TL? Tech Lead projektu? Nowa rola, jaka? ad 3) uwzględnienie czasu na stworzenie dokumentacji. |
review |
|
| | | Jak robić review projektu?
| Szkolenie / zatrudnienie osoby od Agile/Scrum
|
poinformowanie interesariuszy, organizacja szkoleń, warsztatów, udostępnienie instrukcji |
|
| | śmierć bloga brak szkoleń z nowych procesów, brak demo, brak wdrażania procesów brak jednego źródła informacji o rzeczach, które się dzieją, m.in. o wdrożeniach
| Brak przepływu informacji
| Do zaopiekowania w późniejszych etapach jeśli wcześniejsze punkty nie wyeliminują problemu.
|
zamknięcie karty projektu |
|
| | DoD pełne komentarzy “nie dotyczy” sami jesteśmy sędzią we własnej sprawie - to interesariusze powinni potwierdzać że akceptują kolejne punkty nieuzupełniane DoD w niektórych projektach DoD nie jest definiowane na początku projektu, a powinno wynikać częściowo z zakresu nieuzupełnianie rzeczywistych WH bałagan w kartach projektu - trudno je znaleźć i odfiltrować po statusach itp. brak KPI typu “time to delivery”
| Problemy z kartą projektu
| Zaadresowane wyżej
|
retro |
|
| | nie do końca wiadomo kogo zapraszać na retro, i czy ta formuła się trochę nie przejadła powtarzalne wnioski aktualnie celem retro jest danie upustu emocjom, a nie wyciągnięcie wniosków nikt nie kontroluje czy zostały wyciągnięte jakieś wnioski i czy zostały podjęte jakieś działania naprawcze brak przygotowania do retra brak moderatora
| Jak robić retro i czy robić?
| Szkolenie / zatrudnienie osoby od Agile/Scrum
|