Mój współpracownik jest miłym facetem, ale jego wydajność jest słabsza. Czy mówię mojemu szefowi? [Zamknięte]

Około trzy miesiące temu zostałem przydzielony do projektu, który był do tej pory opracowywany przez jednego, nowo zatrudnionego programistę, ponieważ był opóźniony. Szczerze mówiąc, projekt jest interfejsem do urządzenia medycznego, które ma wiele subtelności i jest stosunkowo złożone, więc umieszczenie jednej osoby w projekcie, która nie miała doświadczenia w firmie, było prawdopodobnie złą decyzją z perspektywy zarządzania.

W każdym razie, kiedy zacząłem nad tym pracować, zdałem sobie sprawę, że ... cóż, to po prostu w ogóle nie działało. Interfejs użytkownika wyglądał ładnie, ale tak naprawdę nic nie zrobił, a to, co zrobiło, działało nieprawidłowo. Ponownie, żeby być uczciwym, wiele z tego wynikało z faktu, że ten programista nie był odpowiednio przygotowany do napisania interfejsu do naszego urządzenia. Szybko jednak zdałem sobie sprawę, że kod, który był na miejscu, był kruchy i niezwykle trudny w utrzymaniu.

Teraz nie twierdzę, że jestem najlepszym programistą na świecie. Pracuję z wieloma bardzo inteligentnymi ludźmi, którzy są lepszymi programistami niż ja. Staram się jednak pisać kod, który jest tak prosty, jak to tylko możliwe i solidny. Testuję moje kontrole. Jeśli widzę, że mój kod robi się niechlujny i ciężko pracuje z nim wcześniej, zmieniam go. Rozmawiałem kilka razy z moim współpracownikiem, próbując pomóc mu napisać lepszy kod. Jest to nieco trudne, ponieważ a) ma ponad 20-letnie doświadczenie w tej dziedzinie, a ja mam tylko 5, oraz b) został zatrudniony jako tak zwany „ekspert UX”, a inni postrzegają go jako osobę doświadczoną.

To powiedziawszy, po prostu tego nie widzę. Jest bardzo miłym facetem i jest rozsądny, ale za każdym razem sprawdza delikatny kod, działa tylko w najbardziej optymistycznych przypadkach i 9 razy na 10 kończę naprawianie błędów w jego pracy. Jego kod wydaje się po prostu amatorski i oczywiście nie ma takiego poziomu doświadczenia, jak twierdził, kiedy był zatrudniony. Doszło do tego, że dodatkowe godziny, które spędzam na poprawianiu kodu i naprawianiu błędów, odbiły się na mnie. Widzę, że mam dwie opcje:

1. Nie rób nic, walnij mnie w tyłek, aby upewnić się, że ten produkt wyjdzie na czas i będzie solidny i zaczekaj, aż upadnie w przyszłości (nie będę z nim współpracował przy tym projekcie po początkowej wersji).
2. Opowiedz mojemu szefowi o jego występie. Mój szef jest rozsądnym człowiekiem, ale po prostu czuję się niezręcznie przy takim podejściu. Nie lubię „walić” (z braku lepszego terminu) moich współpracowników i nie wiem, jak on to weźmie.

To tyle. Próbowałem rozwiązać ten problem z moim współpracownikiem, wyjaśniając, dlaczego jego implementacja nie działa lub w jaki sposób jego kod może być łatwiejszy w utrzymaniu, ale nadal popełnia te same błędy. Jestem bardzo zainteresowany, aby usłyszeć, jak inni poradzili sobie z podobnymi sytuacjami, zwłaszcza w zarządzaniu. Z góry dziękuję za wszelkie porady, które możesz mi zaoferować.

Rozważyłbym przynajmniej możliwość, że gdyby został zatrudniony jako facet UX, może się zdarzyć, że nikt tak naprawdę nie oczekuje od niego naprawdę świetnego kodu - mogą oczekiwać, że jego kod powinien być w zasadzie prototypem opisującym UX i pisanie kodu produkcyjnego na podstawie tego zależy od innych programistów.

Z pewnością nie twierdzę, że tak jest , ale nie byłoby to dla mnie tak zaskakujące. Przynajmniej z mojego doświadczenia, wcale nie jest rzadkie, że ludzie UX produkują przede wszystkim takie rzeczy, jak prototypy i scenorysy. Jeśli już, jeśli ten facet był naprawdę zatrudniony specjalnie jako specjalista UX, jestem zszokowany na samą myśl o tym, że w ogóle sprawdza kod. Jestem prawie pewien, że nigdy tego nie widziałem.

Jeśli facet naprawdę jest specjalistą od UX, lekarstwem może nie być próba zmuszenia go do stworzenia lepszego kodu, ale całkowite wyeliminowanie kodowania (przynajmniej niczego poza prototypami). Jeśli jest naprawdę dobry w projektowaniu UX, prawdziwym błędem jest prawdopodobnie nawet prośba o napisanie kodu produkcyjnego. Zamiast tego prawdopodobnie powinien (co najwyżej) pracować w piaskownicy do prototypowania UX, gdzie jego wynik jest wykorzystywany do kierowania następną rundą wygenerowanego prawdziwego kodu, ale nigdy nie jest rejestrowany jako kod produkcyjny.

Staram się mieć zasadę, że zawsze informuję mojego szefa o sprawach mających wpływ na projekt. Pozytywnie i negatywnie ... aw takich przypadkach staram się obwiniać takie rzeczy jak kod, a nie osobę, która go napisała. Brzmi o wiele mniej, niż to, że walisz współpracownika, a bardziej, że próbujesz poprawić jakość produktu.

Z punktu widzenia zarządzania istnieją 3 typowe sposoby radzenia sobie z pracownikami w takiej sytuacji:

1. Przejmij kontrolę nad swoimi słabościami
2. Zagraj w ich mocne strony
3. Pozbądź się ich (naprawdę nie twój wybór)

Przejmij kontrolę nad swoimi słabościami, szukając pomocy z zewnątrz.

Hej, szefie, trochę martwię się o stan kodu ... jest dość delikatny i bardzo psuje się. Doprowadzenie go do stanu, w którym czuję, że można mu zaufać, zajmie trochę pracy. Czy jest możliwość, żebym mógł pożyczyć jednego z architektów na dzień lub dwa, aby sprawdzić, czy uda nam się wymyślić dobry projekt?

Nie prosisz o dołączenie do projektu innej osoby, tylko o „ekspercki wkład” na krótki czas. Utwórz potrzebne dokumenty, diagramy UML i fragmenty kodu, jeśli tego chce architekt. Zobaczą, w jakim stanie jest kod, a wtedy twój szef będzie miał kogoś, kto powtórzy twoje opinie.

Na spotkaniu, mam nadzieję, otrzymasz lepszy projekt, który ty i drugi deweloper możecie podążać bez jego popieprzenia. Do tego właśnie służą projekty i specyfikacje w wielu przypadkach: zmniejszanie szkód, jakie mogą wyrządzić źli deweloperzy.

Zagraj w ich mocne strony

Hej, szefie, pracuję z kodem dla projektu x, i jest wspaniały. Z drugiej strony, kod może wymagać sporo pracy. Myślę, że lepiej byłoby, gdyby projekt [ux guy] był w stanie skupić się bardziej na UX, podczas gdy ja robię trochę refaktoryzacji, aby uzyskać bardziej stabilny stan. Gdy UX jest już stabilny, projekt b prawdopodobnie użyje dotyku Midasa.

Tutaj twój szef prawdopodobnie przejdzie przez to; że mówisz mu, że drugi deweloper nie jest zbyt dobry ... ale przynajmniej nie jesteś tym dupkiem. A jeśli naprawdę jest naprawdę dobry w pracy z UX, może znaleźć stabilną pozycję, wskakując na każdy projekt i czyniąc go świetnym z punktu widzenia użyteczności. Wyobrażam sobie, że on też polubiłby to w ten sposób.

Przestań wielokrotnie naprawiać swoje błędy. Nie nauczy się; Wiem, że nie.

Programowanie jest w dużej mierze logicznym zadaniem, ale wymaga również przypomnienia pamięci. Kiedy często piszesz wspólny kod, przypominasz sobie, jak ostatnim razem zaimplementowałeś rozwiązanie , zamiast zastanawiać się nad tym ponownie. Jeśli nigdy nie wdrożył poprawnego kodu, rozumiem, dlaczego ciągle powtarza te same błędy.

Pokaż mu, co zrobił źle, i być może naprawię to za pierwszym razem. W przypadku dalszych zdarzeń tego samego incydentu poproś go o wprowadzenie poprawki, którą mu pokazałeś.

Byłbym bardzo ostrożny z kilku powodów:

1. Skąd masz pewność, że po pierwszym wydaniu nie będziesz z nim współpracował? Twoje kierownictwo może pomyśleć: „Co za zespół, spójrz, jak wspólnie stworzyli tę wspaniałość!” i chcę cię trzymać razem.

2. Jeśli pójdziesz do szefa, jak technicznie chcesz spróbować wyjaśnić swoje stanowisko? Ile masz dokumentacji na temat słabej wydajności współpracowników?

To byłyby bzdury, które zanotowałem z tego, o co prosiłeś. Sugeruję, żebyś zapytał go o kod i sprawdził, czy ma jakieś uzasadnienia, dlaczego tak jest. Być może biegnie w kółko podczas kodowania, co powoduje pewne problemy. Koło to miejsce, w którym coś kodujesz, a następnie poprzez serię zmian kończy się w dokładnie tym samym punkcie, co zacząłeś, gdy czyjaś lista zmian ostatecznie się kończy. Byłem w sytuacjach, w których to się zmienia i cofam zmianę po zmianie, która dość szybko się męczy.

Jakie są konsekwencje, jeśli nie przerobisz całej jego pracy i po prostu dopuścisz do niepowodzenia projektu? Mam na myśli konsekwencje dla ciebie.

Z pewnością ktoś z jego poziomem doświadczenia i pozycji nie dostał się przypadkiem, więc albo jego praca nie jest tak zła, jak ją postrzegasz, lub cała jego kariera składa się z ludzi takich jak ty, którzy go niosą.

Jeśli pracujesz więcej niż 50 godzin tygodniowo nad jakimkolwiek projektem, to jest to coś poważnie złego i wyniszczasz siebie, nie zwracając się do szefa rządu ani nie odchodząc. Jestem zdecydowanym zwolennikiem pracy SMARTER, a nie trudniejszej.

Pracuj mądrze 50, a jeśli projekt się nie powiedzie, TO NIE JEST WAS WADA. Jeśli zawodzi z powodu jego niekompetencji i obwiniają cię, to prawdopodobnie nie jest to środowisko, w którym chciałbyś pracować.

Tak wielu moich przyjaciół DOBRZE pracuje nad typowym 40 / tygodniem przy źle zarządzanym projekcie, ponieważ boją się porażki, gdy nie zdają sobie sprawy, jak niewielka porażka LUB sukces wpływa bezpośrednio na całą twoją karierę.

Ponad 80% projektów kończy się niepowodzeniem, nie ma w tym wstydu.

Nazywa się to recenzją. Twój menedżer oczekuje tego od ciebie i musi zostać poinformowany, gdzie spędzany jest czas jego cennego programisty. Dziwię się, że już o tym nie wie - ale znowu widziałem gorzej.

Nie rozmawiaj z nim w kategoriach drugiego faceta, mów z nim o codziennej pracy, którą wykonujesz. Jeśli to oznacza zniesienie jego kodu, niech tak będzie. Uzbrój się w linki do zameldowania itp., Aby dać jakiś dowód swojej codziennej pracy. Twój menedżer może chcieć tego dokładnie od ciebie - on wprowadza 20 lat UX, a ty dostajesz solidny kod. Zamiast robić szkielety, po prostu pisze prototypowy kod poziomu. Porozmawiaj ze swoim menedżerem.

I mam nadzieję, że nie zostałeś zatrudniony jako jego opiekunka. Powodzenia.

Czy projekt rozpocznie się wcześniej, jeśli nie będziesz musiał przepisywać / przerabiać jego pracy? Czy pomoże to w przekroczeniu budżetu? Nie musisz walić, aby prywatnie zgłosić swoje obawy. Oto, gdzie większość ludzi popełnia błąd, narzekają bez oferowania rozwiązań.

Czy są jakieś konkretne zalecenia, które możesz zaoferować swojemu szefowi, które poprawią wynik. Lepsza dokumentacja? Solidne testy użytkowników? Twoim celem jest sprawienie, aby firma, projekt, twój kolega i ty osiągnęli sukces. Udawanie, że nie ma problemu, zapewnia w ogóle porażkę trzech z czterech --- i nie jesteś szczęściarzem.

Musisz jak najszybciej udać się do szefa i po prostu powiedzieć mu, co tu powiedziałeś.

Po pierwsze, jest to urządzenie medyczne. Czy ktoś może zostać ranny lub umrzeć, jeśli wystąpi błąd? Kod, od którego zależy życie lub zdrowie ludzi, musi być tak niezawodny, jak to tylko możliwe, a nie błędne śmieci napisane przez optymistę dla najlepszego scenariusza.

Okej, zakładając kapelusz byłego menedżera ... nie masz pojęcia, czy twój szef wie o tym, ani jaka będzie jego odpowiedź, jeśli będzie to dla niego wiadomość. Ale jeśli nie wie, musi i nie powinieneś zgadywać go, ukrywając te informacje. Jeśli nic mu nie jest, gdy twój współpracownik koduje w ten sposób, da ci znać.

Wiele lat temu wpadłem na taką sytuację. „Guru sieci” wraz z kontrahentami pracowaliśmy nad koncepcją koncepcji. W rzeczywistości prawie nic nie robił, a głównie wygłupiał się. Pewnego dnia nasz szef powiedział nam, że nadchodzi demo. Wkrótce „guru sieci” zaczął odbierać wiele rozmów telefonicznych w ciszy i w końcu powiedział mi, że zamierza odejść przed demonstracją, aby wziąć udział w kolejnej umawiającej się imprezie. Gdy tylko udało mi się pozbyć naszego szefa w spokoju, powiedziałem mu o tym. Zrzucił „guru sieci” i przyprowadził kogoś, kogo poleciłem, który w ciągu trzech dni wykopał więcej kodu niż „guru” w ciągu trzech miesięcy. Demo było hitem - ale gdybym się nie odzywał, projekt kompletnie by się nie powiódł.

Tak, powiedz swojemu szefowi. Wtedy zobaczysz, czy to nie ty jesteś nie na miejscu. Zadaniem menedżera jest wiedzieć, jak sobie radzi zespół, a jeśli szef jeszcze tego nie zauważył, być może nie zależy mu tak samo jak na poprawnym kodowaniu - jak w wielu, wielu miejscach, w których byłem.

A wśród wszystkich tych różnych miejsc pracy, jeśli dostałem pełną rękę (czyli 5) przyjaciół od wszystkich z nich, to już duża liczba. Wszyscy mieli fajnych facetów i dziewczęta, ale nie stracisz przyjaźni po wykonaniu swojej pracy - jeśli stracisz ich, to dobrze. W twoim przypadku ceniłby tę pracę bardziej niż ciebie.

To prawda, to nie jest próba wyrzucenia go z pracy. To po prostu pokazuje troskę o dobre samopoczucie projektu i dlatego wszyscy jesteście (lub powinniście) tam być.

W końcu próbowałeś z nim porozmawiać, a jeśli nic nie zrobisz, ryzykujesz tam swoją pracę.