Pojawienie się pomysłu/ zapotrzebowania | | |  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?
| Utworzenie karty projektu Zastosować schemat przygotowany przez SMS (link obok)
|
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)
| |
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 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
| 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 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  brak identyfikacji etapów/ kamieni milowych
| |
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
| rozważyć Story Pointy vs WH
|
Doprecyzowanie wymagań | potwierdzenie możliwości i wybranych opcji ze zleceniodawcą wstępne makiety i opisy dla partnera konsultacje z zewnętrznymi dostawcami
| 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
| |
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
| |
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
| |
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
| |
kickoff | | | |
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
| |
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
| Agile Kołcz
|
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
| 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)
| |
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
| |
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
| |
review | | | |
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
| |
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”
| |
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
| |