Employee Assessment System - Q & A
Wideo z sesji Q&A https://bluemediasa.sharepoint.com/:v:/r/sites/ITDelivery/Shared%20Documents/General/Recordings/employee_assessment_20230515.mov?csf=1&web=1&e=j0Mabu&isSPOFile=1
Ogólne
Q: Jaki jest cel wprowadzenia oceny pracy?
A: Wystandaryzowany model ocen ma posłużyć do ujednolicenia oceny pracy na danym stanowisku. Narzędzie pozwoli na:
- stawianie celów pracownikom
- wykorzystanie do rozmów rozwojowych pracownika
- skuteczną analizę osiągnięć
Q: Dlaczego niektóre zespoły maja 2 KPI, a niektóre 5 ?
A: Na ten moment nawet po konsultacjach z Team Leaderami niektórych zespołów nie byliśmy wstanie wybrać odpowiedniego KPI (wartościowego i dającego się łatwo pomierzyć). Nie chcieliśmy też na siłę dodawać mało wartościowych KPI. Standardem ma być taka sama liczba KPI per stanowisko.
Q: Dlaczego w ocenie pracy danego stanowiska nie uwzględnia się wszystkich aspektów pracy na danym stanowisku?
A: Ocena dotyczy obecnie małego wycinka pracy każdego z nas system będzie rozbudowywany, na start nie chcieliśmy go przeciążyć.
Q: Czy nie macie obaw przed tym, że pracownicy zamkną się w swoich bańkach realizując tylko zadania, za które są w stanie otrzymać punkty a wszystko inne zostanie zrzucone na dalszy plan i ucierpi na tym np. współpraca międzyzespołowa, wsparcie na chatach, service desk?
A: Tak przewidzieliśmy taką sytuację dlatego jest też cześć uznaniowa oceny, która będzie uwzględniała pozostałe aspekty pracy. Większa liczba KPI też ma zapobiegać takim sytuacjom.
Utylizacja czasu pracy
Komentarz: jeżeli w miesiącu są 22 dni robocze musi być zalogowane 22 * 8 = 176h
Q: Czy ustawowa przerwa 15 min powyżej 6h pracy + 5min per każda godzina przed komputerem ma być logowana do losowych zadań nad którymi aktualnie spędzamy czas ?
Q: Co z sytuacją gdzie zalogowane jest ponad 100% czasu w miesiącu ?
A: Unikamy wykonywania nadgodzin. Jeżeli wystąpią to logujemy i raportujemy do przełożonego.
Q: Co do logowania czasu pracy - jak 8h zalogowanego czasu ma się do różnych ustaleń czy wewnętrznych, czy zewnętrznych (przerwy etc.) Czy w takim układzie zalogowany czas w Jirze nie powinien być proporcjonalnie przeliczony?
A: j.w. Jak logować czas pracy
Q: Czy to oznacza, że jak zabraknie nam 1h zalogowanej w miesiącu to mamy 0 pkt?
A: Tak.
Q: Co w przypadku przekroczenia czasu pracy w danym miesiącu. Czy “nadwyżka” przechodzi na następny i wtedy może być zalogowanych godzin mniej?
A: Jeżeli jest przełom dnia to nie ma znaczenia. Jeżeli wystąpi na przełomie miesiąca to raportujemy przełożonemu i możemy godziny odebrać w kolejnym miesiącu.
Zgłoszenie awarii
Komentarz: Każdy pracownik, który dowiedział się o awarii (np. sam, na podstawie alertu, przez zgłoszenie klienta) ma obowiązek zgłosić incydent niezwłocznie przez formularz Każdy pracownik, który dowiedział się o awarii (np. sam, na podstawie alertu, przez zgłoszenie klienta) ma obowiązek zgłosić incydent niezwłocznie przez formularz https://incident.bm.pl/ w celu uruchomienia procesu zarządzania incydentem. w celu uruchomienia procesu zarządzania incydentem.
Q: Jakich godzin w ciągu doby to dotyczy? Poza godzinami pracy nawet jeśli coś wpada na mój tel. to nie mam obowiązku na to reagować.
A: Dotyczy tylko godzin pracy (standardowe 8h i dyżury).
Q: Zgłaszanie awarii przez pracownika jako miernik czy składowa oceny?
A: I jedno i drugie. Domyślnie ten KPI jest na poziomie 100% (1pkt), ale jak w danym miesiącu zaniedbasz i nie zgłosisz awarii spadnie do 0% (0 pkt)
przy czym mówimy to o jakimś rażącym niedbalstwie, np. pomimo prośby kroś nie zgłosił, albo zgłosił dopiero w następny dzień, wyszło po paru dniach, że nie zgłosił
Q: rozumiem że tu chodzi o sytuację, w której ktoś jako pierwszy dostał alert/maila, który skutkował póżniej jakimś incydentem/awarią i przy analizie incydentu wyszło, że informacje o incydencie miał ten "pierwszy", ale nic z tym nie zrobił?
A: tak dokładnie, albo zrobił cos z tym ale nie zgłosił incydentu i przez to np. nie wyszły powiadomienia do klientów
Sonar (Jakość kodu)
Komentarz: Warunki konieczne przyznania punktów:
wszystkie projekty zespołu otagowane NEW, LEGACY podpięte do Sonar
Q: Ciężkie do oceny - to co jest wrzucone do sonara w wielu przypadkach ciężko jest przypisać do tej listy Lista systemów (krytyczne, tagi)
A: Na początku będziemy weryfikować to ręcznie, a docelowo wypracujemy jakiś standard.
Komentarz: https://sonar-k8s-common.blue.pl/issues
filtrując po Author i Assingee można zobaczyć issues wprowadzone per developer
Q: Tutaj jest problem bo nie można tego przefiltrować dla projektów oznaczonych jako new lub legacy.
Taka opcja jest w https://sonar-k8s-common.blue.pl/projects ale już nie można zaznaczyć dat ani autora.
A: Na początku będziemy weryfikować to ręcznie, a docelowo wypracujemy jakiś standard.
Czas na Story Point
Q: jeśli szacujemy złożoność i w ogóle szacujemy w SP, to w jaki sposób mamy przeliczać ten spadek czasu na SP? skąd będą ramy? pomysł wygląda dość karkołomnie.
A: Liczone m/m wartość startowa średnia z 3m, wszystkie dane z JIRA.
Q: SP określa poziom wysiłku/trudności/skomplikowania zadania a nie powinien być przeliczany na WH, Czy ten KPI znaczy, że zmieniamy nasze podejście do SP?
A: Zostajemy przy definicji Scrumowej, główną intencją jest spowodowanie rozbijania zadań na mniejsze przez co zadania bedą dokładniej opisane i dużo większa szansa dowożenia zadań na sprincie
Q: jeżeli taki jest cel KPI to należy zmienić jego nazwę. Aktualna nazwa tego KPI jest bardzo wprowadzająca w błąd. Aktualnie to brzmi 'jak pracujesz szybko, to dostaniesz punkt. Jak wolniej to nie dostaniesz'. Często dopiero przy pracy wychodzi, że zadanie wycenione na 2 okazuje się być 8, albo zadanie na 5 okazuje sie być 2.
A: Dlatego celem jest mierzenie tego w długim okresie więc te odchyłki przeszacowania/niedoszacowania powinny się kompensować.
Q: Czy nie macie obaw przed tym, że uzależnienie oceny pracownika od spalanych SP spowoduje, że pracownicy będą za wszelką cenę zamykać zadania nawet kosztem obniżenia jakości ich realizacji? Zdarzają się sytuacje, kiedy pracownik podczas realizacji zadania wpada na lepszy pomysł na jego rozwiązanie ale wiąże się to z poświęceniem większej ilości czasu na dane zadanie co odbije się finalnie na spalonych SP w sprincie. W tej sytuacji jest obawa, że pracownik, porzuci pomysł i wykona zadanie tak, żeby tylko spalić SP kosztem obniżenia jakości rozwiązania.
A: W dłuższym okresie to się skompensuje bo będą też sytuacje, że wpadnie na leszy pomysł i zrealizuje zadanie szybciej.
Q: Dlaczego ocena punktowa “Story Pointów” dotyczy tylko części zespołów, które używają Scruma? a co z zespołami, które korzystają z Kanbana? Może warto iść w inną stronę, która wzmacnia kontakty międzyzespołowe przez np. ocena punktowa łącznego czasu realizacji projektu w stosunku do przewidywanego czasu realizacji projektu (przy każdym projekcie produkt zakłada ile WH to zajmie)
A: Dla Kanbana wprowadzimy KPI w kolejnych iteracjach.
UPDATE: Jest już KPI mierzący przepustowość realizowanych zadań w Kanbanie - https://bluemedia.atlassian.net/wiki/spaces/ITD/pages/1767735390/Employee+Assessment+System#DevNetOps%2FDevFrontend%2FSRE%2FQA
Q: Czy nie macie obaw przed tym, że uzależnienie oceny pracownika od spalanych SP spowoduje, że każdy skupi się tylko i wyłącznie na swoim zadaniu, bo z niego jest rozliczany, przez co pracownicy przestaną sobie nawzajem pomagać, nie będą dzielić się wiedzą?
A: Takie aspekty będą uwzględnianie w części uznaniowej oceny.
Q: Jak chcecie zliczać spalane SP skoro przypisana do zadania jest jedna osoba a przecież wiele zadań jest realizowanych przy wsparciu innych osób z zespołu, chociażby poprzez konsultacje, review rozwiązania, asystę przy wdrożeniu?
A: Będzie liczone tylko dla zadań, których właścicielem jest pracownik. Jeżeli pomagał komuś w innym zadaniu to taka sytuacja występuje też w drugą stronę i w skali miesiąca to się uśredni.
Q: Co z zadaniami realizowanymi poprzez SD? One nie mają SP a są równie ważne jeśli chodzi o ich zamykanie na bieżąco. W wielu przypadkach są nawet ważniejsze jeśli wpadają jako blockery i dotyczą klientów VIP. Jeśli realizacja takich zadań nie będzie punktowana w ocenie pracownika nie będzie chętnych do ich realizacji.
A: Realizacja zadań przez strażaka nie wpływa na metrykę Czas na Story Point. Taka sytuacja miałaby wpływ gdybyśmy mierzyli zespołową metrykę liczby zrealizowanych SP.
Q: Co z zadaniami typu "warsztaty" gdzie główkujemy w kilka osób jak rozwiązać dany problem? Do takich zadań również może być przypisana tylko jedna osoba a nad zadaniem pracuje ich kilka.
A: Jeżeli jest np. 2 realizujących można podzielić zadanie na 2 części i do każdej przypisać osobnego właściciela.
Q: Jak chcecie zliczać spalone SP skoro nie są one przypisane na stałe a ulegają pomniejszeniu w przypadku, kiedy zadanie wymaga realizacji np. na dwóch sprintach (wtedy zadanie jest przeszacowywane i ilość SP zostaje pomniejszona o tym ile już zostało zrobione)?
A: Nie można w SCRUM zamykać zadań niezrealizowanych, zrealizowane SP w danym spricie przejdą jako zrealizowane w następnych. To ile zostało w danym zadaniu do realizacji zapisujemy sobie pomocniczo w nawiasach kwadratowych w temacie zadania.
Q: Co w przypadku kiedy ktoś zaczął realizować zadanie, zrobił połowę i poszedł na urlop, a zadanie przejęła inna osoba z zespołu? Spalanie SP zostanie wtedy sprawiedliwie podzielone?
A: Nie mierzymy spalonych SP tylko Czas na Story Point więc taki przypadek nie będzie miał znaczenia w całej masie zadań.
Q: Biorąc pod uwagę wcześniejsze moje pytania 5-10 proszę o informację jaki jest mechanizm liczenia czasu na SP, jak działa. Chciałbym się upewnić, czy bierze pod uwagę wszystkie aspekty poruszone przeze mnie we wcześniejszych pytaniach.
A: Mechanizm nie uwzględnia wyjątków opisanych powyżej. Na bieżąco będziemy rozwiązywać jeżeli będą pojawiały się jakieś zaburzenia. Bazujemy na trendach.
Team Leader
Q: Kodujący TL jest oceniany jako TL czy Dev?
A: Team Leader oprócz KPI dla TL będzie miał metryki związane z pracą którą realizuje. Na przykład kodujący TL będzie miał metryki Developera, TL analityk będzie miał KPI analityka jak takie powstaną.
% poprawnie wypełnionych Incydentów i Post-Mortem
Q: z jakich incydentów będę rozliczany? Z tych gdzie przypisany jest między innymi nasz obszar, z tych gdzie przypisano konkretnie mnie czy w jeszcze inny sposób?
A: Na podstawie Incident Owner Team. Jeżeli będzie wyjątkowa sytuacja, że na czas nie zostanie przypisany Incident Owner Team to nie uwzględnimy w tej metryce. Natomiast AM będzie pilnował żeby Owner był ustawiany na czas jeżeli nie zostanie ustawiony z automatu.
Prowadzenie projektów kapitalizowanych zgodnie z wytycznymi
Q: Wg https://bluemedia.atlassian.net/wiki/spaces/ITD/pages/1663631424/Framework+Wsp+pracy+w+Organizacji#Kwalifikacja-do-kapitalizacji przegląd i kwalifikację programów do kapitalizacji wykonuje Dział Finansów
A: Zmieniliśmy nazwe KPI, żeby był bardziej zrozumiały z Zgłoszenie projektów do kapitalizacji na Prowadzenie projektów kapitalizowanych zgodnie z wytycznymi
Q: odpowiednie labelki powinny być przypasane do epik czy programów?
https://bluemedia.atlassian.net/jira/servicedesk/projects/PRODUKT/queues/custom/489
A: Na poziomie Programu i są propagowane w dół automatami. Po stronie PO pozostaje upewnienie się, że wszystkie zadania mają odpowiednio przypisane etykiety “kapitalizacja” albo “nie_do_kapitalizacji”.
Liczba zrealizowanych zadań na SD
Q: Wpada mi task na zmianę dajmy na to ilości replik, albo zasobów czegoś tam. W teorii zadanko na 15 minut i done. Co w przypadku gdy okazuje się, że żeby zaaplikować taką prostą zmianę mam do wyrównania 70 plików? Jak liczyć w takim przypadku punkty, gdzie muszę powiedzmy poświęcić pełne 2-3 dni robocze, żeby coś takiego doprowadzić do ładu i składu?
Q: Randomowo wybierany priorytet - kwestia wyboru priorytetu jest zawsze po stronie zgłaszającego to jest jasne. Pytanie co w przypadku gdy jakiś temat został zapomniany, albo nagle wychodzi, że coś trzeba zrobić na wczoraj? DevNetOps jest rozliczany za zapomniane tematy, które zgłaszane są do realizacji przez inne obszary? Takie tematy bardzo często nie polegają na prostej zmianie, tylko trzeba usiąść pomyśleć jak to zrobić dobrze, a w przypadku priorytetów typu Important, Blocker z góry jesteśmy skazani na porażkę.
A: Oba pytania sprowadzają się do tego, że trafiają się zadania wymagające więcej czasu niż np. prosta zmiana konfiguracji.
Wyjaśnienie w komentarzu do tego KPI: w części uznaniowej przełożony może patrzeć na stopień skomplikowania realizowanych zadań.
Q: Dostajemy punkty za liczbę zrealizowanych zadań na naszym SD patrząc miesiąc do miesiąca. Zdarzają się okresy, kiedy zadań jest mniej - więc siłą rzeczy nie będziemy w stanie osiągnąć wzrostu tempa realizowanych zadań, a może się zdarzyć że nawet utrzymania tempa. Co w takim przypadku?
A: Znormalizujemy to względem łącznej liczy zadań.
Liczba reopen-ów dla zadań na SD
Q: Współpraca Produkt z innymi: Co w przypadku gdy mamy zadanie na SD w need feedback, automatycznie przechodzi w zamknięte ponieważ Partner nam nie odpowiada. W momencie gdy uzyskamy informacje i zrobimy Reopen to możemy popsuć statystyki innym
A: Nie będziemy zliczać reopen-ów gdzie wcześniej zadanie zamknął automat.
Q: Reporter robi komuś Re-open na zadaniu (to też dobre pytanie w przypadku AM) - Co w przypadku gdy jest to re-open niesłuszny i nie wynika z błędu osoby realizującej zadanie?
Są sytuacje w których reporter zakłada zadanie, jest ono za mało doprecyzowane, zadajemy dodatkowe pytania, zadanie wpada na need response, po 60h jest zamykane jako porzucone i wtedy reporter sobie o nim przypomina i robi reopen bo temat jest turbo ważny, czy takie reopeny również będą liczone ?
A: Nie będziemy zliczać reopen-ów gdzie wcześniej zadanie zamknął automat.
Wszystkie programy zaakceptowane na T2 NPI, które przechodzą w fazę “implementation” posiadają utworzone epiki per zespół współpracujący we wdrożeniu i mają określone daty realizacji
Q: Co w przypadku rozbicia określonej inicjatywy na etapy, gdzie jeden możemy już oszacować i zdefiniować terminy oraz zaczać implementacje, a kolejny/e jeszcze nie ze względu na pogłębioną analizę/zależność od czynników zewnętrznych czy inne. Program powinien zostać w fazie Analisys mimo implementacji Etapu 1 (tj danej Epiki1), aby zgadzało się w KPI, co będzie przekłamaniem statusu Programu czy Program powinien przejść w Implementation, ale PO będzie za to niżej oceniany?
A: Każdy program będzie analizowany indywidualnie przez Product Managera.