Pytanie:
Jak pracować z przełożonym, który zapomina o co prosił?
happybuddha
2015-01-08 12:40:59 UTC
view on stackexchange narkive permalink

Pracuję jako programista w małej firmie i małym zespole. Obecnie pracuję pod starszym kierownikiem / architektem. Problem, z którym się zmagam, to:

Architekt przydziela pracę poszczególnym programistom w swojej kabinie. Programiści pod koniec dnia zgłaszają swoje prace i szybko o nich rozmawiają. Teraz, mniej więcej raz na 2 tygodnie, pod koniec dnia spotkania z nim, mówi, że nigdy nie prosił mnie o kodowanie tego, co zakodowałem! Może obejmować od całej funkcji do pola w formularzu / bazie danych. Zakładając, że popełniłem błąd, od tego czasu zacząłem wszystko spisywać. To nadal trwa. Kiedy pokazuję mu, co napisałem o codziennej pracy, mówi, że nie zwracałem na to uwagi i źle to zrozumiałem. Po czym zacząłem codziennie parafrazować to, czego on ode mnie chce, ale to wciąż trwa.

Nie ma dokumentacji, przeciwko której można by kodować. I nie ma żadnych wymagań. Wszystkie utworzone bilety / wnioski o pracę mają wyłącznie charakter informacyjny. To mały sklep, który zajmuje się powtarzającymi się rządowymi systemami sieciowymi, więc wszystko, co mówi architekt, jest zwykle prawem.

Co mogę zrobić w takich sytuacjach, aby uprzejmie ujawnić fakty (bez obrażania przełożonego)?

W tej chwili tylko ja i mój przełożony pracujemy nad projektem. W tej chwili mówi: „Nigdy cię o to nie prosiłem” Jestem oniemiały - jakie są sposoby, w jakie mógłbym poradzić sobie z tą sytuacją? Niemożliwe jest obalenie mu zarzutów, a jeśli sprawy wybuchną, będzie to jego słowo przeciwko mojemu.

Nic nie istnieje, dopóki nie znajdzie się na papierze. Powiedz mu, że będziesz potrzebować instrukcji w formularzu e-mail, aby dokładnie wiedzieć, czego się oczekuje.
Czy jesteś absolutnie pewien, że nie zrozumiałeś źle jego próśb?
Hmmm. Z drugiej strony doświadczyłem mówienia juniorowi: „Nie rób XYZ. Osoba A będzie to robić”. ... tylko po to, by później odkryć, że junior zrobił to w każdym przypadku (i niesłusznie)!
Mam zamiar powtórzyć @LightnessRacesinOrbit:. Czy na pewno nie przyjmujesz prośby i nie opracowujesz jej poza tym, czego się spodziewał? Z pewnością zdarzały mi się sytuacje, gdy ktoś prosił o małą funkcję i zaimplementowałem cały system do obsługi tej funkcji i każdej możliwej odmiany ...
Czy firma używa systemu śledzenia błędów (takiego jak FogBugz lub Bugzilla) do śledzenia żądań zmian? Jeśli nie, polecam z niego skorzystać - w ten sposób każda zmiana wprowadzona w oprogramowaniu ma numer sprawy, a wyciągnięcie numeru sprawy daje ładną historię tego, czego żądano, kiedy, kto o to poprosił i kto został do tego wyznaczony.
Unikaj używania komentarzy do dłuższej dyskusji. Zamiast tego, proszę [zdobądź pokój, czat] (http://meta.workplace.stackexchange.com/q/2691/325). Komentarze mają pomóc ulepszyć post. Aby uzyskać więcej informacji, zobacz [Czym „komentarze” nie są…] (http://meta.workplace.stackexchange.com/questions/72/what-comments-are-not).
Dziewięć odpowiedzi:
Philip Kendall
2015-01-08 13:09:38 UTC
view on stackexchange narkive permalink

Sposób, w jaki podszedłbym do tego, polegałby na uzyskaniu pozytywnego potwierdzenia od przełożonego, że postępujesz właściwie - w zależności od tego, jak przydzielono Ci pracę, być może najbardziej oczywistym sposobem jest po prostu przeczytanie powrót ”na koniec spotkań z przełożonym i powiedz coś w stylu„ Dla potwierdzenia, dzisiaj powinienem pracować nad funkcjami A, B i C. Czy to prawda? ”

Jeśli parafrazowanie jest już robiąc to, napisz to na piśmie - jak tylko wrócisz do swojego biurka po spotkaniu, wyślij e-mail do swojego przełożonego z potwierdzeniem, nad czym będziesz dzisiaj pracować. W ten sposób nie ma wątpliwości co do tego, co robisz. Jak sugeruje Aleksander, język może być ważny: „Tylko potwierdzenie tego, o czym rozmawialiśmy” będzie o wiele mniej konfrontacyjne niż „Upewnienie się, że nie zapomnisz tego, co mi powiedziałeś”.

Uważam, że kiedy otrzymuję ustne instrukcje, POTRZEBUJĘ dobrze napisanych notatek, bo inaczej skończę jako osoba, która zapomina o pozycjach na liście. Zwykle kontaktuję się z drugą osobą, wysyłając e-mail w stylu „Zrobiłem te notatki podczas dzisiejszej rozmowy. Jeśli coś przegapiłem, daj mi znać”. Następnie mogę wrócić do wysłanej poczty i postępować zgodnie z instrukcjami krok po kroku, aby upewnić się, że trafiam w każdą pozycję, a nie w inne.
Może będzie mógł podpisać twoje notatki, aby potwierdzić, że spojrzał na nie i zatwierdził je?
Zaletą tej odpowiedzi jest to, że działa ona również wtedy, gdy pracownik się myli ...
ChrisW
2015-01-08 21:33:48 UTC
view on stackexchange narkive permalink

Powiedz, że aby uniknąć nieporozumień, chcesz robić / notować to, co mówi.

Miej tablicę (w jego biurze, którą oboje możecie zobaczyć), na której piszesz (w formie notatek) o co cię prosi.

Na koniec spotkania uzgodnij z nim (tj. potwierdź), że notatki na tablicy są poprawne / dokładne.

Zrób zdjęcie (np. używając telefonu) gotowych notatek na tablicy, zanim wyjdziesz z biura.

To powinno rozwiązać ten problem: „Kiedy pokażę mu, co napisałem o dniach pracy mówi, że nie zwracałem uwagi i pomyliłem się ”, ponieważ pisząc na wspólnej tablicy, może zweryfikować, co piszesz. Wspólne pisanie poprawnych notatek staje się wspólnym produktem / przedmiotem spotkania.

To może być jedyna odpowiedź, która nie powtarza tego, co już zrobiłem i może zrozumieć powagę i subtelną naturę tego problemu. Mam zamiar szczerze tego spróbować. Dzięki stary
Cieszę się, że próbowałem to opublikować, chociaż to była spóźniona odpowiedź. Korzystanie z tablicy jest „oldskulowe” (tj. Szanowane) i dyskretne: miejmy nadzieję, łatwe do wprowadzenia. Zamiast tego niektóre inne osoby (zespoły) robią to przez każdą osobę przy użyciu własnego komputera, aby jednocześnie edytować (i / lub nadzorować edycję innej osoby) udostępnionego dokumentu (notatek) w czasie rzeczywistym; lub zamiast oprogramowania i sieci do współdzielonej edycji w czasie rzeczywistym, jeden komputer z projekcją (za pomocą projektora) z komputera protokolanta (skryby) na tablicę. Wolna ręka jest dobra w przypadku diagramów „architektonicznych” ad hoc. Obyś był zdrowy.
Możesz też mieć rację, że o nim zapomniał. Z punktu widzenia osoby bezstronnej (zobacz różne komentarze do innych odpowiedzi) jest również możliwe, że zapomniałeś i / lub że doszło do nieporozumienia / braku porozumienia (wspomnienia świadków mogą być niewiarygodne). W każdym razie posiadanie / robienie * udostępnianych * notatek może złagodzić którykolwiek z tych problemów i skupić uwagę ludzi na (konstruktywnym) ulepszaniu notatek zamiast (nieprzydatnego) obwiniania innych o niedoskonałe wspomnienia.
Joe Strazzere
2015-01-08 18:20:10 UTC
view on stackexchange narkive permalink

Co mogę zrobić w takich sytuacjach, aby grzecznie ujawnić fakty (bez obrażania mojego przełożonego)?

W tej chwili tylko ja i mój przełożony pracujemy nad projektem. W tej chwili mówi „Nigdy cię o to nie prosiłem” Jestem oniemiały - jakie są sposoby, w jakie mógłbym poradzić sobie z tą sytuacją?

W momencie, gdy ktoś Cię o to pyta aby wykonać pracę, napisz e-mail potwierdzający przypuszczenia dotyczące tego, co planujesz zrobić. Na koniec umieść sformułowania takie jak „Proszę, daj mi znać, jeśli moje założenia są niepoprawne”.

Wyślij to swojemu przełożonemu i skopiuj się. Zapisz wszystkie te e-maile.

Następnie, jeśli pojawią się pytania, możesz prześledzić swoją pracę do wymagań.

To brzmi jak przełożony, który ignorowałby e-maile lub wymyślał fałszywy powód, dla którego to, co powiedział, nie było tym, co się stało. OP faktycznie robił te notatki, chociaż doceniam, że część z prośbą o potwierdzenie jest cennym ulepszeniem w przypadkach, gdy druga osoba nie jest celowo dokuczliwa. Krótko mówiąc, myślę, że to, co sugerujesz, jest zwykle warte zachodu, ale nie sądzę, że pomoże to w tym przypadku.
Drugim krokiem, jeśli to nie zadziała, byłoby stanowcze wymaganie od przełożonego, aby sam wysyłał te e-maile.
@TomW Właściwie to mogłoby pomóc. Notatki, które sam napisałeś, nie zostały podpisane przez przełożonego. Kiedy wysyłasz mu e-maila, nad czym pracujesz, nie ma on takiej wymówki. (Jeśli nigdy nie czyta e-maili, to inny problem)
@TomW Fakt, że zrobił to, co mówią jego notatki, nie wyklucza możliwości, że źle zrozumiał lub poczynił przypuszczenia w momencie robienia notatek. Po uzyskaniu ich akceptacji możesz to wykluczyć i mieć teraz coś konkretnego do przekazania szefowi w związku z tym problemem (lub Twoja „parafraza” może zostać wyróżniona jako przyczyna).
+1 jedyną rzeczą do dodania jest upewnienie się, że implikacja brzmi „Chcę potwierdzić, że dobrze zrozumiałem” i / lub „Będę bardziej produktywny dzięki pisemnemu opisowi, z którym mogę sprawdzić swoją pracę” ( a nie „Myślę, że zapomnisz”).
„możesz to wykluczyć” - cóż, możesz zmniejszyć jego częstotliwość. Nadal zdarzają się sytuacje, w których obie strony zgadzają się, że umieścisz na nim zdjęcie niedźwiedzia, „tak, każdy niedźwiedź jest w porządku”, zapisz to, podpisz, a na koniec dnia pokłóć się, czy Kubuś Puchatek to * właściwie * niedźwiedź lub fikcyjna postać / pluszowa zabawka w kształcie misia.
Alec
2015-01-08 12:50:23 UTC
view on stackexchange narkive permalink

Dobre pytanie. Myślę, że może istnieć wiele odmian tego tematu w różnych dziedzinach.

To może być trochę dziwne, ale możesz spróbować zasugerować, że możesz nagrywać dźwięk, kiedy omawiasz swoje zadania. Nie musisz wspominać, że dzieje się tak z powodu problemów, które miałeś, ale ponieważ możesz to wykorzystać, aby lepiej zrozumieć jego prośbę, gdy będziesz bardziej zaangażowany w zadanie. Dzięki temu szczegóły będą zawsze aktualne.

Pomocne może być stwierdzenie, że dzieje się tak, ponieważ nie masz pewności co do swoich wspomnień. W ten sposób nie oskarżasz go o złą pamięć.

Ponadto ta odpowiedź nie musi zakładać, że ty (pytający) jesteś tym, który pamiętanie poprawne. Równie łatwo może udowodnić, że twój przełożony ma rację.

Ciekawe, ale mało prawdopodobne.
JMK
2015-01-08 15:16:56 UTC
view on stackexchange narkive permalink

Czy używasz firmowych aplikacji do czatowania, takich jak Hipchat lub Slack?

W projekcie, nad którym pracuję, mamy kanał standup na Slacku (używany Hipchat w przeszłość), w której po każdym dniu pracy podsumowujemy, nad czym będziemy pracować w tym dniu (w zasadzie wpisując to, co powiedzieliśmy podczas debaty).

Możesz zaimplementować coś takiego i mieć każdy członek Twojego zespołu, w tym Twój szef, robi to jako część swojej rutyny.

W ten sposób wiesz, że Twój szef codziennie czyta wiadomości, a jeśli podsumujesz niepoprawnie, może Ci o tym powiedzieć.

Następnie, tydzień później, jeśli Twój szef twierdzi, że pracowałeś nad czymś, o co nie pytano, możesz wskazać swoje zgłoszenie sprzed tygodnia i zapytać, dlaczego nie zostało to wtedy z tobą poruszone.

Wolę tę wiadomość e-mail, ponieważ jest to bardziej swobodne, łatwiejsze do wykonania rutyny i ogólnie wydaje się bardziej naturalne.

Tom W
2015-01-08 17:01:15 UTC
view on stackexchange narkive permalink

Wygląda na to, że wykonałeś rozsądną ilość samodzielnych czynności, próbując rozwiązać ten problem, ale bezskutecznie. Możesz jasno wykazać dowody na to, że byłeś sumienny i proaktywny, próbując rozwiązać problem komunikacyjny. Myślę, że jest to punkt, w którym można rozważyć zaangażowanie jego szefa. Sugerowałbym otwarcie z nim na ten temat:

„[Przełożony], zauważyłem, że mieliśmy wiele nieporozumień dotyczących tego, jaką pracę mam wykonywać. Próbowałem [ środki], ale wydaje się, że nie poprawiło to sytuacji. Jeśli nie masz pomysłów na poprawę naszej komunikacji, myślę, że nadszedł właściwy czas, aby poprosić [szefa] o zasugerowanie dalszych działań ”

Podstawą tego jest Twoje wyobrażenie, że Twój przełożony jest nierozsądny. Jeśli w dobrej wierze podjąłeś próbę zrozumienia problemu i szczerze wierzysz, że masz rację, a on się myli, masz prawo bronić swojego punktu widzenia w konstruktywny i cywilny sposób i przed tym, co robisz. mówię, że nadszedł czas na taką rozmowę.

„Dobro kontra zło” może być niepotrzebnie konfrontacyjne. Zawsze określiłbym to jako „wymagane wyjaśnienie”.
deworde
2015-01-08 17:56:39 UTC
view on stackexchange narkive permalink

Rozważ jego problem; albo nie jest w stanie łatwo wyrazić tego, czego potrzebuje, albo bardzo zmienia zdanie. To pierwsze może być częściowo Twoją odpowiedzialnością za brak upewnienia się, że rozumiesz doskonale pod koniec spotkania; to drugie wszystko zależy od niego.

W obu przypadkach masz możliwość dostosowania się lub rezygnacji. Uzyskanie jasnego „wspólnego języka” pomoże w rozwiązaniu poprzedniego problemu, a skłonienie go do przeczytania i podpisania twoich notatek na temat tego, o co Cię poprosił (które powinieneś zrobić podczas spotkania ) będzie pomóż w drugiej.

Jeśli jest tyle „nieporozumień”, logiczne jest, abyś poprosił go o sprawdzenie twoich notatek, aby upewnić się, że będziesz pracować według właściwych zasad;

„w końcu wyraźnie czegoś mi brakuje”.

Niektórzy sugerowali użycie narzędzia programowego, ale osobiście zacznę od mniej inwazyjna metoda, taka jak zeszyt, która wymaga od niego minimalnego zaangażowania.

Poza tym, jak powiedzieli inni, musisz z nim o tym porozmawiać . Jeśli rozmowa 1 na 1 kończy się po prostu ślepym zaułkiem typu „nie słuchasz poprawnie”, musisz albo zaangażować jego szefa, albo poprosić neutralną stronę trzecią (np. HR), aby ta rozmowa odbyła się. Jeśli to dosłownie tylko Ty i on, możesz pociągnąć za duży spust i powołać odpowiedniego rzecznika ds. Sporów, ale może to być „posunięcie ograniczające karierę”, jeśli nie jest traktowane ostrożnie i wydaje się skrajne w Twoim przypadku (chyba że twój problem zacznie wpływać na twoje wynagrodzenie / premię / zdrowie, w którym to przypadku twoja kariera jest już ograniczona i musisz go rozwiązać o wiele pilniej).

Ponadto zdecydowanie nadszedł czas, aby przynajmniej mieć strategię wyjścia, na wypadek gdyby problem trwał w nieskończoność i czujesz, że nie możesz tego tolerować.

Brakuje Ci możliwości: lub OP naprawdę po prostu nie rozumie. Z pewnością miałem pracowników, którzy po prostu nie mogli pojąć, o co ich prosiłem, podczas gdy wszyscy inni wierzyli, że jest to krystalicznie jasne.
@ChrisLively Patrz drugie zdanie. Jeśli wszyscy, z wyjątkiem faceta, z którym tak naprawdę rozmawiałeś, myśleli, że wszystko jasne, to nie tylko ich problem. I rozwiązanie jest takie samo, nawet jeśli to ja jestem gęsty, powtórz to z powrotem, aby sprawdzić poprawność. Wylogowanie jest spowodowane rażącymi problemami z zaufaniem związanymi z tą sprawą.
Dunk
2015-01-09 03:40:44 UTC
view on stackexchange narkive permalink

Wygląda na to, że naprawdę potrzebujesz lepszego systemu lub procesu żądania zmiany oprogramowania.

Dobry system pozwoli na poddanie żądań zmiany szeregu stanów, w których wyznaczona osoba wprowadza istotne informacje dotyczące jej części procesu.

Wystarczy przejść przez przykład: Twoje bieżące zgłoszenie / żądanie pracy to tylko opis wniosku o zmianę i będzie w stanie początkowym. Ktoś decyduje, że chce popracować nad konkretnym SCR, więc przechodzi do stanu śledztwa. Stan dochodzenia identyfikuje problem i zaleca rozwiązanie. Wygląda na to, że twój architekt powinien otrzymać SCR w tym stanie. Dla każdego SCR wypełni on pole opisujące swoje ustalenia i zalecane rozwiązanie. Następnie może przypisać SCR komukolwiek, komu chce zaimplementować zalecane rozwiązanie.

Wdrażający wprowadza poprawki, dodaje dowolne notatki do pola „uwagi implementacyjne” w SCR i przenosi SCR do weryfikacji . W idealnym przypadku system SCR jest powiązany z systemem zarządzania konfiguracją oprogramowania. Pozwoli to osobie przeprowadzającej weryfikację (brzmi jak architekt) szybko zobaczyć wszystkie zmiany, które zostały wprowadzone w celu włączenia SCR.

To naprawdę bardzo prosty proces, który jest niezwykle trudny do zrobienia źle . To powinno rozwiązać twój problem, ponieważ zawsze możesz cofnąć się i wskazać to, co zalecił architekt.

Caffeine Coder
2015-01-08 12:59:49 UTC
view on stackexchange narkive permalink

Jedną z rzeczy, które można zrobić, jest wprowadzenie nowego systemu. Powiedz mu, hej, właśnie odkryłem nową aplikację, powiedz - Asana (intensywnie korzystałem z niej w naszej poprzedniej organizacji, ale nie znalazłem jeszcze czegoś, co jest lepsze). Pozwala przydzielać zadania i ustalać terminy dla każdego członka zaangażowanego w projekt. Ponieważ jesteśmy wieloma programistami, pomogłoby to w śledzeniu wszystkich zadań. W ten sposób będziesz mieć listę swoich zadań i jest dowód, że rzeczywiście przydzielił ci to zadanie.

Choć przekonanie go zajmie trochę czasu, na końcu będzie to sytuacja korzystna dla wszystkich. Upewnij się również, że poinformowałeś innych programistów o tym samym i wszyscy zgadzają się z Twoim pomysłem. Komunikacja werbalna jest najbardziej niebezpieczną rzeczą, z jaką możesz się spotkać jako programista, zawsze będziesz winny, dopóki nie pomyślisz o przyspieszeniu i wprowadzeniu jakiejś zmiany.

Skłonić starca, który wierzy, że we wszystkim ma rację, aby całkowicie zmienił sposób pracy, wprowadzając nową technologię, bez której pracował przez dziesięciolecia? Powodzenia z tym...
@phillpe, po pięćdziesiątce nie jest stary i wielu z nas po pięćdziesiątce jest więcej niż chętnych, by próbować nowych rzeczy.
W momencie wejścia do branży IT zgodziłeś się uczyć nowych rzeczy. Bez względu na wiek nie można się przyklejać do pisania w notatniku i oczekiwać, że przetworzy on wszystkie szczegóły, dlatego będzie musiał nauczyć się Excela.


To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...