Wygląda na to, że PO jest “złapany w środek”: “podwładny” skarży się funkcjonariuszom korporacyjnym, że kierownik zespołu/kierownik projektu go odgaduje. Z różnych powodów wygląda to jak zespół programistów. Choć nie jest to ściśle istotne, to jednak może być problemem fakt, że od kogoś, kto pełni rolę “inżyniera”, oczekuje się, że będzie zarządzał swoim czasem, podobnie jak od sprzedawcy detalicznego - o 8:00 rano i o 17:00 wieczorem. Wygląda na to, że są tu również inne kwestie, ale nie są one wyszczególnione.
Pytanie, jak napisano, brzmi: “Co powinienem powiedzieć kierownictwu wyższego szczebla?”. Sugeruje to, że pierwszym problemem OP jest to, jak jest on postrzegany przez własnych menedżerów. Z punktu widzenia menedżera wyższego szczebla dwa ego to walka kotów - jeden pisze kod, a drugi zarządza projektem. Oznacza to pewien dystans społeczny pomiędzy “twórcą” a “nadzorcą”. Wydaje się, że przełożony próbuje powiedzieć podwładnemu: “Zostałeś zatrudniony, aby robić, co ci każą - nie kwestionuj autorytetu”. O ile z treści nie wynika, że faktyczna lokalizacja nie jest oczywista, to brzmi ona jak sklep gdzieś w Azji.
To, co chce usłyszeć kierownictwo, to fakt, że dwaj wojowniczcy wypracowali sposób wykonywania swojej pracy przy minimalnym tarciu. “czy przyniesie wszystkie negatywne punkty swojego przełożonego, czy co?” byłoby złym posunięciem - naprawdę złym. Wszyscy seniorzy widzą w tym momencie, że dwaj pracownicy raczej się kłócą, niż wykonują swoją pracę.
Tak więc, ryzykując, że “nie odpowiedzą na pytanie”, proponuję:
- W ramach programu operacyjnego należy określić, jakie wskaźniki mają zastosowanie do pomiaru wydajności dewelopera. Jest mało prawdopodobne, aby były to wskaźniki typu clock-in i clock-out. Prawdopodobnie będzie to produkcja produktów - kodu, dokumentacji, poprawek i wsparcia użytkownika w rozsądnym czasie. Może się to równie łatwo odnosić do innych form inżynierii - projektowania układów scalonych, projektu architektonicznego lub mostu. Wszystkie one mają złożone połączenie “projektu podstawowego”, dokumentacji, poprawek i reakcji na opinie konsumentów.
Po ustaleniu metryki, zastosuj ją do dewelopera/inżyniera. Czy pisze on kod, naprawia problemy i wspiera użytkowników w sposób zadowalający? Jeśli tak, przestań go prowokować rzeczami, które oczywiście go niepokoją. Sprawdź, czy jest możliwe zidentyfikowanie problemów z czasem, które nie są widoczne w godzinach pracy, takich jak późnonocne rozmowy telefoniczne, praca w weekendy lub inne czynności, które zakłócają normalny 40 godzinny tydzień pracy.
Istnieje pewna wartość w introspekcji. Czy OP angażuje się w grę siłową tylko po to, aby ustalić lub utrzymać “rangę”? Ludzie na stanowiskach inżynierskich cały czas walczą z “kierownikami liniowymi” o strój, przerwy, język, godziny pracy i protokoły kontaktu z użytkownikiem lub klientem. Inżynierowie postrzegają zachowanie menadżerów jako obstrukcyjne - bardziej troszczą się o pozory i warunki wstępne niż o załatwianie spraw. OP może skorzystać z tej okazji, aby dowiedzieć się, czy nawyki nabyte w innym rodzaju organizacji (lub strukturze rodziny) nie przynoszą tutaj efektu przeciwnego do zamierzonego.
Po wykonaniu tych czynności nadszedł czas, aby usiąść z deweloperem - najlepiej poza biurem - powiedzieć przy obiedzie. Zachęcaj i pozwól deweloperowi mówić o tym, w jaki sposób spędza czas dzień w dzień - kawałki dostępne do kodowania/projektowania, przerwy ze strony przełożonych, przerwy ze strony użytkowników, problemy, które sprawiają, że jest zajęty w godzinach wolnych od pracy, zmiany specyfikacji “out of the blue”, itp. Nie bądź zdziwiony, jeśli rozmowa dygresje - jeśli tak, to delikatnie.
Od tego spróbuj dowiedzieć się, jakie konkretne zdarzenia wyzwoliłyby kogoś, kto pojawiłby się z opóźnieniem lub zrobił długą przerwę - wśród rzeczy, które wyzwoliłyby tego pierwszego (z mojego osobistego doświadczenia) jest tylko mgliste zrozumienie, co robić dalej. Często siedziałem w domu na leżaku przez dwie lub trzy godziny, myśląc o tym, jak coś ułożyć, a kiedy nadeszła odpowiedź, zabierałem się do pracy i robiłem to. Miałem wielu przełożonych, którzy narzekali na mój czas przybycia - żaden z nich nie narzekał na jakość tego, co zrobiłem.
Jeśli inżynierowi często przerywa się pracę, zadaniem OP-ów jest ustalenie, jak je przechwycić, aby było ich mniej. Oznacza to w szczególności, że nie należy tworzyć ich więcej arbitralnie. Skąd biorą się te przerwy i czy można je zmniejszyć? Często właśnie to powinni robić nadzorcy - utrzymywać pokłady w czystości, aby programiści/projektanci/inżynierowie mogli skupić się na wydobyciu swoich rzeczy.
Jeśli programista nie jest w stanie wyjaśnić, gdzie się podziewa, może pojawić się problem z kompetencjami. Znowu jest on skoncentrowany na wynikach, a nie na zegarze. Czy terminy są niedotrzymywane, ponieważ nic nie jest robione lub ktoś inny zmienia zdanie? Jeśli programista musi zaczynać od nowa, to nic nie będzie zrobione. Jeśli tak, to dlaczego tak się dzieje? Nadzorcy powinni zablokować wymagania tak, aby zespół mógł pracować do ustalonego celu.
Gdyby to wszystko miało się wydarzyć, to Nadzorca mógłby poinformować kierownictwo wyższego szczebla, że wydajność się poprawia i że użytkownicy otrzymują potrzebną im infrastrukturę komputerową.