kod kowboja w zespole

Jak radzisz sobie z członkiem zespołu, który jest dla ciebie starszy i zawsze wskakuje na projekty innych ludzi i realizuje je w nocy lub w weekend? Wydaje się, że pracuje przez 80 godzin tygodniowo, niezależnie od tego, czy zdarzy się nagły wypadek, czy nie. Trudno jest przewidzieć, którą część listy rzeczy do zrobienia ma zamiar wykonać w następnej kolejności. Czasami marnujesz dni swojej pracy, ponieważ w poniedziałkowy poranek znajdujesz meldowanie kończące projekt, nad którym spędziłeś większość poprzedniego tygodnia.

Dla osób pytających o jakość: zwykle jest całkiem dobra, ale: wiąże się to również z dużym refaktoryzacją kodu, w tym kodu „będącego własnością” innych członków zespołu, bez uwzględnienia zasięgu testu, z oczywistymi wynikami.

Jest to prawdopodobnie częściowo kwestia przejrzystości; prawdopodobnie nie próbuje marnować twojego czasu. Rozmawiałbym z zarządem o tym, aby zadania, nad którymi ludzie pracują, były bardziej zrozumiałe, aby mogła łatwiej zrozumieć, że ktoś już zainwestował czas w to zadanie, i zobaczyć, które zadania nie zostały odebrane, skupiając się na nich.

Nie zapytałbym jej o to bezpośrednio. Porozmawiam z twoim przełożonym, aby można było wdrożyć jakiś proces. Chociaż problem jest prawdopodobnie najbardziej widoczny u niej, założę się, że są inni koledzy z drużyny, którzy robią to samo (przypadkowo rozpoczynając projekty, nad którymi ktoś inny już pracuje) na mniejszą skalę. Myślę, że twój menedżer jest w najlepszej pozycji, aby poprowadzić ten nowy proces, chociaż prawdopodobnie powinieneś dać mu kilka pomysłów do pracy. Jeśli praca ze swoim menedżerem nie działa, powinieneś przejść do bezpośredniej rozmowy z nią - ale zacznę od menedżera.

Nasz zespół zajął się tym problemem, umieszczając karteczki z wszystkimi pracami, które należało wykonać na białej tablicy. Każdy członek zespołu miał etykietę z nazwiskiem i przenosił przyklejoną notatkę do kolumny „w toku” i oznaczał ją swoją nazwą. Jeśli inna osoba chciała pomóc w tym zadaniu, oczekiwano od nich przedyskutowania i negocjacji z osobą, która zgłosiła się po to zadanie. Podobny system może bardzo pomóc w rozwiązywaniu problemów.

Zakładając, że jest naprawdę skuteczna, a „jack of all trade” ...

Uwzględnij jej styl. Uwolnij ją. I - odizoluj ją.

Również...

Wyraźnie wypełniaj obowiązki, które powierzasz.
Upewnij się, że Twój zespół uczy się od niej (np. Programowanie par działa doskonale).
Nie idź za wszystko - przetestuj ją i upewnij się, że masz plan awaryjny, jeśli sytuacja się pogorszy.

Najgorsze, co możesz zrobić, to zepsuć jej motywację.

Mówię to z własnego doświadczenia. Może nie jestem tak wydajny, jak bym chciał, ale z pewnością mogę przejść od interfejsu użytkownika do wytrwałości i na pewno ćwiczę kodowanie kowbojskie (co z pewnością jest mieczem obosiecznym).

Zostałem wrzucony w całkiem beznadziejny projekt sam (sprawiłem, że wszystko było jeszcze fajniejsze - zaproponowałem przepisanie tego wszystkiego i zgodziłem się na to), wszystko idzie dobrze i uwielbiam to. Nie mam nikogo, kogo można winić za błędy, oprócz mnie. Nie mam na co narzekać, kiedy spontanicznie postanawiam wszystko po refaktoryzacji .

Właściwie - ta wolność jest jedyną rzeczą, dla której wciąż tu pracuję.

Sądzę, że są gorsze problemy. Chociaż praca, którą ty (lub inni członkowie zespołu) powinniście mieć znaczenie, i wydaje się, że wyniki jej pracy skutecznie eliminują wkład wniesiony przez osobę do zespołu.

Domyślam się, że nie zdaje sobie sprawy z wpływu, jaki wywiera na zespół; raczej jej wkład prawdopodobnie sprawia, że ​​czuje się cenna dla zespołu.

Rozwiązanie (IMHO): skonfrontuj ją bezpośrednio. Oczywiście bądźcie dyplomatyczni i doceniajcie wkład i poświęcenia (80 godzin to szalony tydzień pracy i nie byłoby możliwe, gdyby nie dość skandalicznego poświęcenia w życiu osobistym).

Ale jej obowiązkiem jest zachowywać się w sposób, który nie zrazi jej współpracowników - młodszych lub w inny sposób. I wszyscy członkowie zespołu zasługują na poczucie, że ich wysiłki są znaczące - w końcu dlaczego ktoś miałby chodzić codziennie do pracy, gdyby ich obecność była bez znaczenia?

Rozważają jej znacznie więcej pracy, więc nie trzeba szukać dla Ciebie!

Czy to możliwe, że „wskakuje i kończy”, ponieważ reszta drużyny porusza się zbyt wolno lub dlatego, że poprosił ją szef?

Ile z tego jest irytacja z pominięciem, a ile to po prostu „pokazanie” przez bardziej płodny (niekoniecznie lepszy) koder?

Czy ona wie, że inni uważają to za irytujące? Sugerowałbym taktownie poruszanie jej z nią, mówiąc, że wolisz kończyć swoje projekty. Jeśli to nie zadziała lub nie czujesz się komfortowo, gdy wychowujesz to u kogoś starszego, jest to przypadek zarządzania. Jeśli nie kończysz projektów, ponieważ ona jest, może to wyglądać, jakbyś się zwlekał, jeśli kierownik nie zna sytuacji.

Również, jak powiedzieli inni, spójrz, jak ona działa, aby poprawić siebie. Spójrz na jej meldunki, aby zobaczyć, jak rozwiązała twój problem - być może była to sprytna poprawka, o której nie pomyślałbyś. Pamiętaj, że starsi programiści znają bazę kodu znacznie bardziej niż ty. Rzeczy, które wydają się trywialne, mogą być trudne dla nowszych programistów.

Jak radzisz sobie z członkiem zespołu, który jest dla ciebie starszy i zawsze wskakuje na projekty innych ludzi i realizuje je w nocy lub w weekend?

Pracuj szybciej?

Wydaje się, że pracuje przez 80 godzin tygodniowo, niezależnie od tego, czy zdarzy się nagły wypadek, czy nie. Trudno jest przewidzieć, którą część listy rzeczy do zrobienia ma zamiar wykonać w następnej kolejności.

Z definicji, jeśli jest na twojej liście rzeczy do zrobienia - nie jest zrobione. Jeśli ona ją ukończy, skreśl ją z listy rzeczy do zrobienia.

Czasami marnujesz dni swojej pracy, ponieważ w poniedziałkowy poranek znajdujesz meldowanie kończące projekt, nad którym spędziłeś większość poprzedniego tygodnia.

Zwykle nazywa się to pracą zespołową - o ile nie podoba ci się kierunek, w którym podążyła, jaki jest problem?

Dla osób pytających o jakość: zwykle jest całkiem dobra, ale: wiąże się to również z dużym refaktoryzacją kodu, w tym kodu „będącego własnością” innych członków zespołu, bez uwzględnienia zasięgu testu, z oczywistymi wynikami.

„Własność” i kod nie pasują do siebie. Jeśli masz problem z nadążeniem, poproś ją, żeby ci to wyjaśniła. Poproś ją, aby cię mentorowała, ponieważ wydaje się, że jest dość produktywna. Wykorzystaj relację i pracuj razem.

Jeśli chodzi o zasięg testu, jeśli jest to standard w twojej organizacji - podnieś go do swojego głównego / menedżera. Szybka, ale tandetna praca nikomu się nie przyda. Chociaż, jeśli jest 10 razy wydajniejsza od ciebie - możesz skończyć z nią porządnym sprzątaniem. W takim przypadku zainwestuj jeszcze więcej w związek z nią.

• Ucz się od niej i staraj się zwiększyć szybkość pracy.
• Być może twoja praca jest opóźniona.
• Być może dzieje się więcej za kulisami lub ponad twoją wiedzę ze względu na oczekiwania kierownictwa, gdy ona jest starsza.
• Możesz pomyśleć, że ona nie ma nic lepszego do roboty. Często jest to mało prawdopodobne.
• Możesz nie być świadomy sytuacji awaryjnej.
• Może to być podpowiedź do twoich wyników przez kierownictwo lub przez senior.

Tak czy inaczej, najlepiej zacznij oceniać siebie jako pierwszy. Twoje wysiłki, aby „ poradzić sobie z nią”, mogą nie działać dobrze z zarządem.

Wyraźnie czerpie swoją satysfakcję z rozwiązywania problemów i bycia bohaterem - co jest w porządku, ale musisz (cóż, kierować jej drużyną, ale w międzyczasie) znaleźć sposób, aby to wykorzystać.

Wyskakują na mnie kluczowe rzeczy:

• Ma talent do wykonywania pracy szybciej niż inni (nic nie sugerujesz, że jej kod jest zły)

Wykorzystaj to. W następnym projekcie zaoferuj jej pracę do wykonania. W ten sposób wiesz, co ona planuje robić. Jeśli jej satysfakcja wynika z rozwiązywania problemów, prawdopodobnie będzie równie szczęśliwa, jeśli zaoferujesz jej to tak, jakby robiła to w tle.

Być może pójdź jeszcze lepiej, sformalizuj to, ponieważ zespół przygotowuje pracę, która jest do zdobycia dla każdego, kto chce zrobić coś więcej - w ten sposób element kradzieży zniknie i wszyscy wygrywają.

Rozpocznij zespół od programowania w parach.

Po pierwsze, programowanie par jest męczące, szczególnie dla introwertycznych deweloperów, którzy lubią pracować przez cały weekend na własną rękę. Jej weekendy staną się cenne dla relaksu, tak jak powinny.

Po drugie, przekaże wiedzę (tak długo, jak jeździ więcej początkujących programistów), a tym samym przekaże swoje zdumiewające umiejętności pozostałej części zespołu.

Po trzecie, zmniejszy ogromne ryzyko, które obecnie ponosi w twoim imieniu, aby więcej niż jeden członek zespołu wiedział, co wie.

Po czwarte, ona - i reszta zespołu - będzie miała lepszy pomysł, nad czym pracuje. Jeśli możesz połączyć to z ukończeniem całych funkcji razem jako zespołu, będzie mniej prac w toku, a szansa na powielenie pracy przed odprawą będzie mniejsza.

Po piąte, nauczy się grać jako część drużyny . Jest całkowicie możliwe, że wywoływana przez nią motywacja, wraz z powielaniem pracy innych członków zespołu, kosztuje więcej niż produkuje. Wydajność! = Skuteczność.

Po szóste, jakość kodu zwykle wzrasta, gdy para deweloperów się paruje. Miły efekt uboczny.

Czy ona wie, jaką pracę wykonują ludzie i ich postępy? Czy kierownictwo mogłoby zapewnić jej wskazówki, aby nie powielała pracy innym osobom? Chciałbym pokusić się o rozmowę 1: 1 przed wprowadzeniem zarządzania, ponieważ być może jest ona pracoholikiem, który mógłby wykorzystać kierunek, aby wiedzieć, jakie rzeczy mogą być ważne, że inni nie robią tego, co może być dla niej bardzo przydatne robić.

Jeśli chodzi o marnowanie pracy, spójrz na nią z innej perspektywy. Czego możesz się nauczyć z tego, co zrobiłeś? Jakich części nie wykonałeś i jak to zrobiła? Tylko dlatego, że ktoś inny może przypisać sobie robienie czegoś, nie myśl, że cała krew, pot i łzy są za nic.

Kowboj wydaje się entuzjastyczny. Podchodzę do zarządzania, aby mogli dać jej mnóstwo pracy i pozwolić wam robić własne rzeczy. Może jednak mógłbyś nauczyć się czegoś od kowboja. Nie twierdzę, że 80-godzinny tydzień pracy powinien być normą (oczywiście jest to przesada), ale poświęcanie dodatkowych godzin pracy jest dość normalne w dużym środowisku korporacyjnym.