Delivery 1.0 Help

Komunikat ws wytycznej KPMG

Szanowni!

Zarząd Autopay otrzymał od KPMG list z wynikami kontroli finansowej jaką wykonał za ubiegły rok. W zbiorze wytycznych znajduje się jedno wskazanie, o najwyższym priorytecie, które bezpośrednio przekłada się na naszą codzienną rutynę - logowanych roboczogodzin kapitalizowanych projektów.

Zastrzeżenia audytorów obudziła automatyczna akceptacja godzin, jakie wykazujemy w projektach.

Zdaniem KPMG godziny, które utylizujemy w ramach zadań powinny być przejrzane przez Product Ownera/Project Managera lub inną upoważnioną osobę i zaakceptowane bądź odrzucone. Dodatkowo mogą pojawić się zadania i zalogowany czas, który w ramach projektu powinien się znaleźć, lecz przez nieuwagę do tej inicjatywy nie został podpięty.

Wytyczne dostarczone przez KPMG są traktowane przez Zarząd z najwyższą powagą. W związku z tym musimy pilnie (od dziś) dokonać korekty metodyki naszej pracy i wprowadzić rytuał weryfikacji prac zgłoszonych do projektu. Proponujemy następujące metodyki:

Dla zespołów pracujących w Kanban

Zespoły pracujące w Kanban powinny mieć spotkania, na których wykonują tzw. Release.

Rekomendujemy dodać do fazy przeglądania zadań, czy zamykane zadania są należycie przypisane do projektów oraz czy godziny w zadaniach są prawidłowo zalogowane, z których wynikają.

Jeśli dane zadanie nie powinno być w projekcie, typ zadania jest niepoprawny lub niepoprawnie zalogowane godziny - od razu dokonywać korekty. Jeśli jakieś zrealizowane zadanie nie należy do projektu, a być w nim powinno, należy je powiązać.

Dokonany przegląd powinien być odnotowany w jednym z dwóch miejsc:

  1. W dokumencie, który powstaje po wykonaniu Release’u (o ile zespół praktykuje)

  2. W ramach Programu lub Epicu, jako komentarz

Sugerujemy wpis w postaci:

Dla zespołów pracujących w Scrum

Zespoły pracujące w Scrumie spotkają się na review sprintów i planowaniach. Często te dwa rytuały zamykają się w jednym spotkaniu. Rekomendujemy dodać do fazy przeglądania boardu zamykanego sprintu weryfikację, czy zamykane zadania są należycie przypisane do projektów, z których wynikają oraz czy godziny są poprawnie zalogowane w zadaniach.

Jeśli dane zadanie nie powinno być w projekcie, typ zadania jest niepoprawny lub niepoprawnie zalogowane godziny- od razu dokonywać korekty. Jeśli jakieś zrealizowane zadanie nie należy do projektu, a być w nim powinno, należy je powiązać.

Dokonany przegląd powinien być odnotowany w jednym z dwóch miejsc:

  1. W dokumencie z retrospekcją sprintu

  2. W ramach Programu lub Epicu, jako komentarz

Sugerujemy wpis w postaci:

Przegląd ostatnich 12 miesięcy

Prosimy o to, aby dokonać przeglądu zamkniętych sprintów (i wydanych release'ów) z ostatniego roku. Tam, gdzie potraficie odnaleźć zapisane retrospekcje tudzież projekty, nad którymi pracowaliście - prosimy o naniesienie w nich komentarzy, jak powyżej. Prosimy o realizację tego przeglądu do 19 Oct 2023. Czas poświęcony na tę aktywność zalogujcie w zadanie typu “Business continuity”.

Jeśli macie pytania, jesteśmy do dyspozycji.

Last modified: 30 May 2024