Jak radzić sobie z powolnym i niededykowanym kolegą w zespole? [Zamknięte]

Pracowałem nad nowym projektem. Projekt działa w ten sposób: użytkownik końcowy może uzyskać dostęp do aplikacji internetowej za pomocą linku, może dodać wiele systemów w swojej sieci i zarządzać szczegółami poszczególnych systemów. Moja część dotyczy interfejsu i serwera WWW, co odbywa się w Pythonie. Moje python faktycznie komunikuje się z innym projektem, który jest całkowicie wykonany w c & c ++. Projekt c / c ++ jest główną aplikacją, która wykonuje całą funkcjonalność. Moje python wysyła do niego żądanie użytkownika i wyświetla odpowiedź od niego do użytkownika.

Bardzo dobrze znam swoją pracę i niedługo ją ukończę. Ponieważ nie ma w tym wiele pracy. A ja jestem osobą, która uwielbia pracować. Większość czasu spędzam w biurze i wracam do domu tylko wtedy, gdy czuję się śpiący.

Aplikacja c / c ++ jest zarządzana przez innego kolegę, który ma ponad 5-letnie doświadczenie i może robić rzeczy znacznie szybciej niż ja, ale nigdy tego nie robi. Być może on nie lubi tego robić. Jego aplikacja ulega awarii często, gdy mój python komunikuje się z nią lub zwraca nieprawidłowe wartości. Jest pełen błędów. Ponieważ moja aplikacja zależy od tego, trudno mi ją zbudować. Zamiast naprawiać błędy, prosi mnie o spowolnienie mojej pracy. Prosi mnie, abym powiedział kierownikowi, że moja praca wymaga dużo czasu. Prosi mnie o oszukanie kierownika, a nawet zmuszanie mnie do powolnej pracy jak on.

Kiedy podczas spotkania projektowego menedżer pyta go o błędy, mówi, że naprawił wszystko i działa dobrze. Ponieważ jest moim kolegą, nie mogłem nic powiedzieć kierownikowi. Oczywiście muszę utrzymywać dobre relacje z moimi kolegami bardziej niż z moim kierownikiem, ponieważ przez większość czasu będziemy z naszymi kolegami, a nie z kierownikiem.

Nie jestem w stanie powiedzieć kierownikowi niczego na ten temat, ponieważ jeśli menedżer zapyta go dlaczego, to może pomyśleć, że narzekałem na niego. I wciąż leży na spotkaniu. A ponieważ powoli naprawia błąd, spowalnia to nawet moją pracę. Teraz pomyślałem o pracy nad front-endem mojej aplikacji i dokończeniu jej, aby w międzyczasie mógł ustabilizować swój projekt. Teraz prosi mnie, abym powiedział menadżerowi, że moja część frontonu wymaga dużo pracy i może potrzebuję więcej czasu, po prostu, aby mógł przeciągnąć projekt w dół. Smutne jest to, że nasz faktyczny menedżer pojechał do USA, więc mamy tymczasowego kierownika i ten facet nie wie dużo o projekcie, więc c, c ++ go po prostu oszukuje.

Czy ktoś może mi zasugerować, jak sobie z tym poradzić? Chciałem wkrótce zakończyć projekt. Jak sprawić, by pracował, nawet utrzymując z nim dobre relacje?

Odpowiedzi na komentarze:

Jeśli naprawdę celowo wprowadza w błąd firmę, powinieneś zgłosić go zarządowi.

Jestem nowy w tej firmie, a drugi facet jest tam od wielu lat. Właśnie zacząłem poznawać moich kolegów. Jeśli pójdę bezpośrednio do niego i narzekam, nie sądzę, żebym mógł nawiązać dobre stosunki z innymi kolegami. Nawet on ma moc ich wprowadzić w błąd. Nie mówię, że jest złym facetem, może wykonać pracę, ale tego nie robi.

Czy Twoja firma nie ma systemu śledzenia błędów?

Tutaj nie ma rzeczywistego systemu śledzenia błędów. Firma stara się jak najszybciej zakończyć projekt i przekazuje go do kontroli jakości. A następnie naprawia błędy zgłoszone przez QA.

Dlatego firmy powinny dawać pracownikom akcje / opcje lub jakąś własność. W ten sposób możesz dosłownie powiedzieć facetowi: „Kosztujesz mnie wzrostem pieniężnym ... nie chcesz też zarabiać pieniędzy?”.

Firma ma opcje na akcje, które dali mi 2500 akcji, głównie on też dostałby trochę więcej.

Starszeństwo zasługuje na pewne wątpliwości. Naprawdę musisz najpierw z nim porozmawiać i spróbować zrozumieć problem. Być może jest z głębi, możesz mu pomóc, łatwo mogą istnieć zmienne, których nie znasz. Teraz może być ciężko, ale możesz łatwo pogorszyć sytuację, skacząc z pistoletu.

Nawet to robię, najpierw jego aplikacja nie obsługiwała wielu żądań na raz, korzystał z kolejki do obsługi żądań, które mu wysłałem. Zasugerowałem mu nawet kilka moich pomysłów. Powiedział, że ma już te pomysły i będzie je realizował. Wyjaśnił: „Wszystko wymaga pewnego czasu i jest to projekt, który może potrwać dwa lata, a my jesteśmy proszeni o ukończenie go za dwa miesiące”. Przez pierwsze kilka tygodni miałem trudności z kodowaniem z powodu tego błędu. Ale teraz to naprawił. Ale używa pojedynczej kolejki do żądań użytkowników, co spowalnia aplikację, ponieważ przetwarza ona jedno żądanie na raz.

Co QA robi to cały czas? Dlaczego nie raportują / nie potwierdzają statusu projektu (projektów)?

Kierownik to osoba, która decyduje, kiedy przekazać kontrolę jakości. Na razie nie przekazał jeszcze kontroli jakości. Powiedział, że powinniśmy dać to do końca tego miesiąca.

Jesteś w złej sytuacji, nie chciałbym być w twoich butach. Jest mało prawdopodobne, abyś mógł to rozwiązać bez konfliktu ze swoim kolegą.

Oto co bym zrobił:

• Nie zostań jego partnerem w zbrodni. Nie kłam o statusie swojego projektu lub jego projektu.

• Zaimplementuj (w razie potrzeby w wolnym czasie) zgłaszanie błędów do aplikacji, aby wszystkie błędy były wysyłane pocztą elektroniczną do współpracowników i kierownika. Jeśli błąd jest spowodowany przez jego aplikację, spraw, aby była widoczna w wiadomości e-mail (wpisz [BŁĄD APLIKACJI XYZ] w temacie wiadomości e-mail lub coś takiego).

• Utrzymuj bazę danych błędów (oprócz wysyłania błędów pocztą e-mail). Można powiedzieć, że jej głównym celem jest śledzenie swoich błędów, podczas gdy w rzeczywistości będziesz śledzić głównie jego błędów. Między innymi powinien śledzić, ile czasu zajmuje naprawienie określonego błędu.

• Miej całą komunikację międzyprocesową z jego aplikacją objętą testami („kiedy ci to przysłałem, powinieneś mi zwrócić ten styl”). Możesz skonfigurować zadanie cron, które uruchamia te testy każdego dnia, a jeśli się nie powiedzie, wiadomość e-mail zostanie wysłana do wszystkich.

Zasadniczo staraj się nie marnować czasu na kłótnie z nim na temat błędów i zamiast tego skup się na swojej pracy. Jeśli jego aplikacja jest zepsuta, a więc nie możesz pracować nad aplikacją, a menedżer nic z tym nie robi - to jest problem z zarządzaniem i masz bazę danych błędów, e-maile i raporty z testów.

Uważaj jednak i nie lekceważ go. Długoletni leniwiec taki jak on może mieć podstęp lub dwa w rękawie. Może obrócić całą drużynę przeciwko tobie lub coś, ale to zależy od twojej konkretnej sytuacji i to trochę nie wchodzi w zakres tego pytania.

Przedstawię nieco kontrowersyjny pogląd: mówisz, że pracujesz tyle godzin, ile możesz, żeby nie zasnąć. Może więc nie jest szczególnie niesprawiedliwy, mówiąc: „Sprawiasz, że wyglądam źle, a ja pracuję tyle godzin, ile chcę”. Może był tam i zrobił to, a może się wypalił. Obiecuję wam, że tak będziecie, jeśli będziecie to utrzymywać.

Jedź z nim na drinka pewnej nocy i sprawdź, czy nie możesz zbudować lepszej relacji osobistej, na której mógłbyś oprzeć swojego profesjonalistę. Być może, zgadzając się na nieco więcej, a na mniej, obaj możecie pracować razem znacznie lepiej.

Gdybym był tobą, byłbym bardzo ostrożny z całym podejściem „moja praca, twoja praca”. Między wami macie produkt, który się tam wydostanie, a to nie może być dobre dla tego produktu, co z kolei nie jest dobre ani dla firmy, ani dla klienta i płacą za oboje do pracy .

Nadal jednak zgadzam się z innymi poglądami, że należy ponownie rozważyć znaczenie swoich relacji z przełożonym i należy uważać na zaufanie swojemu współpracownikowi. Mówię tylko, że może, może po prostu musisz spojrzeć na swoje czyny, a także na jego.

Prowadzić dokumentację. Dokumentuj każdy błąd, który pojawia się podczas komunikacji ze swoją stroną, kiedy poprosiłeś go o naprawę i kiedy (jeśli w ogóle) to zrobił. To jedyny znany mi sposób radzenia sobie z tą sytuacją. Kiedy więc przychodzi do ciebie menedżer z pytaniem, dlaczego sprawy nie postępują, możesz wyraźnie pokazać, że nie jesteś postrzegany jako słabszy lub zły kolega.

Chciałbym wskazać inną możliwość, która nie została podniesiona. Mówisz, że chce, żebyś spowolnił pracę. Czy masz na myśli dosłownie, że mówi „pracuj mniej godzin” lub że mówi „napisz kilka testów, przetestuj to więcej, napisz dokumentację” i inne rzeczy, które Twoim zdaniem spowolnią cię? Widziałem, jak nowe osoby biegają przez 16 godzin dziennie, a potem narzekają na błędy w kodzie, który wywołują, gdy w rzeczywistości przekazują nieprawidłowe parametry, nie sprawdzają zwracanych wartości itd. Nie mogę wykluczyć, że twój współpracownik myśli o tych rzeczach.

Następnym razem, gdy będziesz na spotkaniu, a on powie, że cały jego kod jest w porządku, powiedz „och, dobrze, rzecz, o której mówiłem godzinę temu, gdzie pojawia się, gdy dzwonię do XYZ z datą, która nie jest dniem roboczym, jest teraz naprawiony? ” Stanie się jedna z trzech rzeczy:

• Skłamie i powie, że nie ma takiego problemu, a ty powiesz: „tak jest! Omówiliśmy to! Wysłałem ci e-mailem!” a całość zwróci uwagę menedżera
• Powie ci, że tak naprawdę nie jest to błąd w jego kodzie, to błąd w twoim kodzie, ponieważ masz tylko minąć dni robocze, a wkrótce dowiesz się, o czym myślał, ale nie powiedział
• Powie „nie, ten, o którym właśnie mi powiedziałeś, że zajmę się dzisiaj, ale wszystko inne jest dobre”. Jeśli to powie, po prostu mu teraz podziękuj.

Możesz się dowiedzieć, że twoje długie dni szybkiego kodowania nie dają dobrego kodu, a ktoś (być może twój menedżer) może przetłumaczyć, aby inny programista wyjaśnił ci, na czym polega problem. Lub możesz dowiedzieć się, że pracujesz z leżącym wężem, który sprawi, że będziesz wyglądać źle, aby chronić jego wygodną pozycję. Wydobywanie rzeczy na jaw nie może tak naprawdę pogorszyć sprawy. Lub możesz uzyskać od niego wystarczająco dużo ruchu, abyś mógł to znieść, bez angażowania się w politykę.

To, co masz, to problem polityczny. Po pierwsze, opinia Twojego menedżera jest o wiele ważniejsza niż myślisz. Ten facet obwinia cię za opóźnienia i pozwalasz mu. To ty zostaniesz zwolniony, jeśli ktoś zostanie wyrzucony pod autobus. O ile kierownik wie, to ty nie jesteś w stanie wykonać pracy na czas.

Chroń się w jakikolwiek sposób, za pomocą śledzenia błędów, e-maili itp., Ale NIE udawaj, że to twoje opóźnienie, a nie jego. Nigdy nie dawaj szefowi fałszywego raportu o stanie, wróci cię ugryźć. Powiedz szefowi prawdę o problemach, które masz (i pokaż dowód), że jego kod nie działa.

Ta osoba, która prosi cię o obluzowanie, aby nie wyglądał źle, jest wężem (cóż, to obraza społeczności węży (subtelne odniesienie do Firefly), przepraszam za wszystkie prawdziwe węże). Zrobi wszystko, aby rzucić cię pod autobus zamiast niego. Nie ufaj mu.

Po pierwsze i najważniejsze:

Ponieważ jest moim kolegą, nie mogłem nic powiedzieć kierownikowi.

Absolutnie możesz i powinieneś upewnić się, że twój kierownik zna prawdę, nawet jeśli twój współpracownik kłamie mu w twarz. Jeśli nie chcesz nic mówić na spotkaniu z tobą w sali, jest to całkowicie zrozumiałe. Ale powinieneś przynajmniej odciągnąć swojego menedżera (prawdziwego, nie tylko tymczasowego) na bok i poinformować go, że twoja praca jest prawie skończona i czeka na poprawki błędów od końca drugiego dewelopera, zanim cała aplikacja będzie gotowa do uruchomienia . Nie oskarżaj współpracownika o kłamstwo, ale nie siedź tam i pozwól swojemu szefowi działać z niekompletnymi informacjami.

Szczerze zgłaszaj swoje statusy. Jeśli twoje prace są wstrzymywane przez błędy po stronie innego programisty, udokumentuj, że znalazłeś błędy w C / C ++ i je zgłosiłeś (proszę powiedz mi, że używasz jakiejś formy dokumentacji, która pozostawia ślad papierowy).

W międzyczasie idź dalej i podsumuj swoją pracę, i poinformuj swojego szefa, kiedy skończysz. Jeśli Twój menedżer chce wiedzieć, dlaczego reszta projektu nie jest jeszcze uruchomiona, możesz skierować go do innego programisty i być może wspomnieć, że prawdopodobnie jest bardzo skomplikowany / duży / wymaga wielu testów / inny programista jest bardzo zajęty / itp. Jeśli znasz C / C ++, możesz zaoferować pomoc w zakresie logiki głównej aplikacji, aby również działało. Tak, będziesz wykonywał pracę drugiego faceta, ale wyraźnie widać, że jesteś pracownikiem ciężko pracującym i produktywnym, a ten drugi nie jest, nie wspominając o tym, że jesteś jeszcze bardziej wartościowy dla swojego szefa. Może nawet wywrzeć presję na innego programistę, aby przyspieszył i przyspieszył.

W pracy występuje wiele problemów. Miej świadomość, że:

1. Robisz założenia dotyczące motywacji innych ludzi
2. Kolorujesz fakty opiniami.
3. Osoby postronne (ktokolwiek inny) nie są świadome historii i nie są świadome twoich frustracji ze swoim kolegą.
4. Możesz wyglądać dziecinnie, jeśli wydaje się, że grasz w grę „gotcha”. Twój kolega prawdopodobnie lepiej to zagra - w końcu wciąż ma pracę, prawda?

Dlatego przedstawiając status swojego projektu:

1. Nie wspominaj o drugiej osobie.
2. Zgłaszając błędy lub problemy z kodem - nie programista. Powiedz „Wywołanie metody FooBar () zwraca 1, gdy powinno zwracać 2”. Zatem żaden problem nie jest osobistym atakiem, mówisz tylko o kodzie - nie o ludziach.
3. trzymaj się faktów, na które masz dowód.
4. Jeśli twój kolega staje się defensywny lub wrogi, zadawaj pytania. „Nie rozumiem, dlaczego uważasz, że powinienem zrobić _ ”
5. Nie zwracaj uwagi na bzdury społeczne i insynuacje. Udawaj, że nie dostałeś osobistego ataku.
6. Prześpij się w nocy przed jakimkolwiek spotkaniem o statusie, dzięki czemu jesteś zwinny.
7. Dokument, dokument, dokument.
8. Nie wstydź się prosić tego faceta, aby pomógł ci z jakimś interesującym problemem, może cię zabrać, jeśli czuje, że go szanujesz. Chodzi o budowanie relacji. (zwróć uwagę, że to nie jest ssanie - to coś innego)
9. Przygotuj się na odejście, jeśli będziesz musiał, aby nie być potrzebującym ani uwięzionym emocjonalnie. Pomoże to utrzymać głowę na spotkaniach.

„Jestem osobą, która uwielbia pracę. Większość czasu spędzam w biurze i wracam do domu tylko wtedy, gdy czuję się senna”.

Nie jest to zdrowe i nie można oczekiwać od współpracowników, chyba że otrzymujesz rekompensatę do tego stopnia, że ​​możesz wziąć lata wolnego od nieuchronnego wypalenia zawodowego. (Coś w rodzaju> 10% udziałów w firmie lub ponad 200 $ rocznie). Utrzymanie fachowej wiedzy, aby szybko rozwinąć się, wymaga czasu. Poświęć trochę czasu na rozwój wiedzy specjalistycznej.

„Projekt c / c ++ jest główną aplikacją, która wykonuje całą funkcjonalność. Mój python wysyła do niego żądanie użytkownika i wyświetla odpowiedź od użytkownika. ... Być może nie lubi tego robić”.

Python jest bardziej zwinnym językiem niż C / C ++. Jego aplikacja wydaje się zawierać całą funkcjonalność; Twoja aplikacja to tylko interfejs użytkownika. Bardziej prawdopodobne niż to, że nie są one równe pod względem trudności. Być może nie tworzy kodu szybko; ale kodowanie jakościowe jest znacznie lepsze niż kodowanie ilościowe. Bardzo dobrze możesz mieć nierealistyczne oczekiwania co do tego, jak szybko potrafi kodować w godzinach, które chce / powinien pracować (zwykle około 40 godzin w tygodniu; pamiętaj, że był tam od lat, prawdopodobnie wykonał inne zadania, takie jak zarządzanie innymi lub utrzymanie starszych) projekty, które zajmują znaczną część tygodnia pracy).

Nie okłamuj go; ale znowu go nie krytykuj. Porozmawiaj o tym, jak jego system jest świetny; przyznano, że potrzebuje więcej pracy, aż do końca. Daj swojemu menedżerowi dokładną aktualizację statusu bez nazywania nazwisk i przypisywania winy. Napisz makietowaną wersję swojego systemu, która jest zgodna z tym samym standardem, z którym powinien być zgodny jego system. Upewnij się, że Twój system działa idealnie z modelem na symulatorze dzięki zautomatyzowanemu pakietowi testowemu. Wtedy twój system może zostać ukończony (np. Idealnie synchronizuje się z makietą), nawet jeśli system na żywo jest nadal wadliwy.

Następnie możesz napisać automatyczny zestaw testów dla jego systemu nazywanego zewnętrznie, który jest zgodny z ustalonymi standardami. Np. Test niż Foo (1,2,3) daje odpowiedź „t. 4 5 6”. Może to pomóc mu zidentyfikować błędy i przyspieszyć jego rozwój (i nie musi zepsuć kodu). Po wykonaniu tych czynności będziesz mógł przejść do innego projektu / zadania (np. Pomóc mu z częściami C / C ++).

Jak wspomnieli inni, profesjonalne zachowanie jest najważniejszą rzeczą w twojej długofalowej karierze. I szczerze mówiąc, dopóki zachowujesz się profesjonalnie, będziesz w całkiem niezłej formie, bez względu na to, jak zachowają się wokół ciebie.

W tej sytuacji należy wziąć pod uwagę kilka czynników.

Po pierwsze, musisz zrozumieć, że jesteś odpowiedzialny za swój program działający zgodnie z pożądanymi specyfikacjami, w podanym terminie. Jeśli Twój program współpracuje z programem innej osoby, jesteś również odpowiedzialny za upewnienie się, że ten inny program działa również w tym samym terminie. Innymi słowy: jeśli druga osoba nie dotrzyma terminu, oznacza to, że również nie dotrzymałeś terminu, nawet jeśli Twoja część projektu była na czas. Pod względem zarządzania nazywa się to posiadaniem danych wejściowych .

Prawidłowo zauważyłeś, że kiedy twój kolega oświadcza na spotkaniu, że błędy jego programu są naprawione, nie możesz natychmiast zadeklarować go jako niepoprawnego kierownikowi (twój kierownik uznałby to za „wyrzucenie współpracownika pod autobus”; bardzo zły ruch kariery). Inni natomiast zwrócili uwagę, że nieprofesjonalne jest nie zgłaszanie kierownikowi prawdziwego stanu projektu. Obie strony są całkowicie poprawne.

Więc jeśli źle jest zaprzeczyć swojemu koledze przed kierownikiem, a także źle jest mu nie zaprzeczyć, to co robisz?

Odpowiedź jest w rzeczywistości dość prosta: musisz porozmawiać ze swoim kolegą na długo przed spotkaniem z kierownikiem i poinformować go, że na nadchodzącym spotkaniu będziesz musiał powiedzieć kierownikowi o problemach, z którymi się borykasz ich program i że wpływa to na twoją zdolność do terminowej realizacji projektu i czy jest coś, co możesz zrobić, aby pomóc im rozwiązać problemy, które miałeś. Musisz odbyć tę rozmowę co najmniej dwa pełne dni przed spotkaniem, gdzie powiesz kierownikowi, a najlepiej pełny tydzień wcześniej.

W większości przypadków po prostu powiedzenie swojemu współpracownikowi, że będziesz musiał wymienić jego program jako ryzyko na danym spotkaniu, zmotywuje go do zajęcia się twoimi problemami i nigdy nie będziesz musiał rozmawiać z kierownikiem . W innych, gdzie problemy są bardziej zależne od harmonogramu, kolega często się z tobą zgadza, a oboje możecie iść razem do kierownika.

Nigdy nie miałem kolegi, który nie naprawiłby mnie szybko ani nie zgodziłby się z moimi obawami wyrażonymi w ten sposób. Ale gdyby tak się stało, ostrzegając kolegę z wyprzedzeniem, nadal będziesz w lepszej pozycji podczas rozmowy z kierownikiem. Ponieważ rozmawiałeś ze swoim kolegą i próbowałeś samodzielnie znaleźć rozwiązanie, i ostrzegłeś ich z dużym wyprzedzeniem, że będziesz musiał poruszyć ten problem na tym spotkaniu, twój kolega nie będzie zaskoczony, kiedy to zrobią, a kierownik wygrał nie sądzę, że po prostu próbujesz zrzucić winę.

Pamiętajcie, że kiedy wyrażacie swoje obawy, albo koledze, albo przełożonemu, to wasze obawy dotyczą programu współpracownika, który zwraca złe dane (lub cokolwiek innego, co robi); są to mierzalne rzeczy, które można zweryfikować i naprawić. Twoje obawy nie dotyczą powolności lub braku poświęcenia ze strony kolegi; nie są to rzeczy mierzalne, które mogą, ale nie muszą być prawdą, i które prawdopodobnie nie zostaną naprawione poprzez spotkanie ich przed szefem.

Z jakiego systemu śledzenia błędów korzystasz? Spodziewałbym się, że przynajmniej podkreślę, gdzie błędy nie zostaną naprawione we właściwym czasie. Tam, gdzie kod oczekuje na dane wejściowe z drugiej warstwy, opóźnienia powinny być wyróżnione w dokumentacji śledzenia projektu. Czy to też się nie dzieje?

Wydaje mi się, że zarządzanie projektami jest tutaj nieodpowiednie. Musisz a) śledzić błędy, które Cię dotyczą, oraz b) śledzić na piśmie dyskusje.

Twój kolega nie powinien prosić cię o wydłużenie czasu na rozwój, aby zaspokoić jego brak woli. W pewnym momencie jest to kwestia, którą należy porozmawiać z kierownikiem. W obecnej sytuacji kryjesz się za kolegą, a to prawie na pewno się odwróci.

Nie ma nic złego w utrzymywaniu kolegi, ale ktoś musi oczekiwać, że codziennie okłamujesz swojego szefa. Nie mogłem go szanować jako osoby i nie chciałbym mieć tej osoby jako zwykłego znajomego. On chce być wrogiem, włącz go.

Jak można argumentować opóźnienia w warstwie aplikacji z powodu interfejsu? Dlatego to robisz, aby mogły być oddzielne. Co dalej, ma jeszcze więcej opóźnień, ponieważ ktoś chce zbudować mobilny interfejs?

Wykonaj swoją pracę. Dokumentuj wszelkie problemy związane z awarią jego aplikacji. A potem GO HOME! Nie obchodzi mnie, czy jesteś śpiący, czy nie. Znajdź znajomych, których warto mieć.

Właśnie przeczytałem „The Clean Coder” RC Martina (wujek Bob). Głównym punktem książki jest to, że programiści w ogóle nie mają większego szacunku, ponieważ nie zachowują się profesjonalnie . Oznacza to przede wszystkim, że nie komunikują się skutecznie z zarządem na temat statusu projektu.

Kłamstwo jest z pewnością bardzo złą formą komunikacji. Twój kolega jest bardzo nieprofesjonalny, podobnie jak Ty. Oboje nie robicie nic dobrego, aby poprawić postrzeganie programistów.

Radziłbym od razu przejść do zarządzania. Jednak w przeszłości miałem kłopoty z powodu zbyt „uczciwości” (w jakiejś niepowiązanej sytuacji), więc nie jestem pewien, czy powinieneś posłuchać mojej rady. Ponadto, jak wielu zauważyło, być może twoje postrzeganie sytuacji nie jest tak dokładne, jak myślisz.

Oszacowanie względnego wysiłku i złożoności innego projektu jest trudne i nierozsądne, jeśli nie znasz podstawy kodu. Mówisz, że jego kod jest podatny na błędy, ale może być w świetnej formie ze wszystkimi pozostałymi problemami na bardzo wysokim poziomie abstrakcji ... Problem w tym, że jest to jedyny kod, którego potrzebuje Twój interfejs!

A może jest złym pracownikiem i zabiera firmę na przejażdżkę. Nie mogę powiedzieć, a ty możesz nie mieć wszystkich informacji, które musisz znać z pewnością.

Sugerowałbym taktykę w połowie drogi. Następnym razem, gdy się spotkasz, przedstaw kilka szczegółów poważnego błędu w jego kodzie, który ma na ciebie wpływ. Kiedy mówi, że wszystko jest w porządku, uprzejmie powiedz, że jest jeden nierozstrzygnięty problem, który blokuje twoje postępy.

Mówiąc tak, politycznie twierdzimy, że nie jest całkiem poprawny, a jednocześnie daje mu szansę na głupie zachowanie i nie daje się obronić.

Twój menedżer powinien zapytać na następnym spotkaniu, czy jest to naprawione. Jeśli nie, presja spada na niego, aby naprawić jeden błąd. Jeśli jest to poprawione, powiedz dzięki, działa teraz świetnie i znalazłeś nowy bloker. Jeśli chcesz być szczególnie miły, powiedz, że wpadłeś na to krótko przed spotkaniem.

Nie kłamiesz sam w sobie, ani nie jesteś po stronie. Grasz w politykę, zwracając uwagę na problemy i pozwalając swojemu koledze zachować twarz, jeśli naprawdę nie wszystko idzie dobrze.

Kuszenie jest po prostu porozmawiać ze swoim menedżerem, ale nie zapomnij, z którym z nich musisz najczęściej pracować.

Odpowiedź Pat była świetna. Zgadzam się w 100%. Nie idź na spotkanie z szefem. Albo weź to ze swoim kolegą między 4 oczami lub zrób to ze wszystkimi 3 z was. Ale sugestia Pata, aby skupić się na kwestiach związanych z kodem, a nie na ludziach, jest właściwą drogą.

Btw, 40h / tydzień wystarczy, stary. Musisz utrzymać wysoką motywację!

Poproś o pomoc w testach integracyjnych. Osoba musi być w stanie powiedzieć, gdzie występuje problem. Jak zauważył temptar, zastanawiam się, dlaczego nie ma nawet doskonałego narzędzia do śledzenia problemów! skoro nie ma śledzenia, to tak, jak za każdym razem, gdy drugi facet ucieka, mówiąc, że wszystko jest w porządku! to nie działa w ten sposób!

To twój moduł, jeśli chcesz to zrobić, musisz podnieść czerwoną flagę na tym, co powoduje opóźnienie po twojej stronie. Doświadczenie w MERE Years nie ma nic wspólnego, to tylko wiedza i właśnie na to powinien nalegać Twój menedżer. Jak już powiedziano, wydaje mi się, że dzieje się tutaj słabe zarządzanie projektem.

1. Najlepszym sposobem na zdobycie zaufania jest wykazanie inicjatywy poprzez zlecenie dodatkowych zadań i pytanie, w jaki sposób można zwiększyć wartość organizacji.

Twój menedżer może nie być wystarczająco techniczny, aby dowiedzieć się, kto spowalnia projekt, ale prawdopodobnie jest na tyle sprytny, aby rozpoznać, że programista, który aktywnie poszukuje nowego zadania, rozkwita w trakcie bieżącego zadania. Doprowadzi to do rozmowy, w której możesz wyjaśnić, że czekasz na poprawki błędów od innych osób w bieżącym zadaniu. Opracuj dyskusję pod kątem tego, jak możesz wnieść dodatkową wartość do organizacji , efektywnie wykorzystując swój wolny czas, a nie to, jak kolega jest zbyt wolny dzięki swoim poprawkom.