Pytanie:
Jak radzić sobie ze współpracownikiem, który przejmuje „nieoficjalną” własność projektu?
Crow
2017-03-15 00:01:49 UTC
view on stackexchange narkive permalink

Przydzielono mnie do pracy nad projektem ze współpracownikiem. Zanim jeszcze zaczniemy, mówi dokładnie w każdy sposób, w jaki powinniśmy robić każdą funkcję. Żaden z nas nie jest przypisany jako „właściciel produktu”.

Często kwestionowanie którejkolwiek z jego sugestii lub proponowanie innej jest ogromną, żmudną walką. Wydaje się, że ma to miejsce za każdym razem, gdy nie chcę robić czegoś dokładnie w ten sam sposób, co on, i zwykle jest to długi i żmudny proces.

ta część została zredagowana dla jasności

Załóżmy na przykład, że mam trudny problem do rozwiązania. Wybiorę jeden sposób rozwiązania tego problemu (może istnieć wiele różnych sposobów) i przekażę go do recenzji. Jeśli to nie pasuje do tego, jak by to zrobił, napotyka to duży opór. Rozważam jego podejście i jeśli to działa lepiej, przyjmuję je, ale jeśli wiem, że tak nie jest, staram się pokazać, dlaczego nie uważam, że to dobra decyzja, poprzez pojedyncze eksperymenty lub zewnętrzne źródła. Mimo to często będzie trzymał się swojego stanowiska i nie zaakceptuje tego, dopóki nie będzie pasować do jego podejścia.

Jednak czuję, że nie pozwala mi na taki sam poziom kontroli, kiedy zdecyduje się coś zrobić. Na przykład zdecydowanie nie zgodzę się z jedną ścieżką, którą wybrał, i chcę, aby została zmieniona. Odpowie w stylu „na razie tak to trzymajmy” lub coś stosunkowo lekceważącego. To daje mi dwie opcje: albo eskalować i nie ustępować, albo poddać się i po prostu to zaakceptować.

Jeśli chcę naprawdę mocno się temu sprzeciwić i mieć „coś do powiedzenia”, potrzebuję wciągnąć naszego menadżera, który będzie zmuszony wybrać stronę i zmusić nas do jej trzymania się. Niezależnie od tego, którą stronę wybierze, czuję się trochę bardziej komfortowo, wiedząc, że była to bezstronna osoba trzecia.

koniec edycji

Mój menedżer powiedział, że nie przeszkadza mu w tym mediacja, ale wydaje mi się to niewiarygodnie małostkowe z mojej strony. Co więcej, wydaje się, że tworzy między nami poczucie wrogości, co nie jest zdrowe dla środowiska pracy.

Czy jest lepszy sposób radzenia sobie z tym?

Komentarze nie służą do rozszerzonej dyskusji;ta rozmowa została [przeniesiona do czatu] (http://chat.stackexchange.com/rooms/55447/discussion-on-question-by-crow-how-to-deal-with-a-co-worker-who-zakłada-nieoficjalne).
Twój kierownik prawdopodobnie powinien był wyznaczyć jednego z was oficjalnego lidera.Widziałem pracę grup bez lidera, ale nie wtedy, gdy są ciągłe konflikty dotyczące kierunku.
Sześć odpowiedzi:
OnoSendai
2017-03-15 05:07:27 UTC
view on stackexchange narkive permalink

Miałem okazję pracować pod kierownictwem kierownika projektu, który miał ciekawe podejście do sporów dotyczących własności projektu: „ Kiedy przychodzi pora na zawołanie, lepiej mieć jednego przeciętnego kapitana niż dwóch znakomitych. "

Wygląda na to, że własność projektu jest naprawdę ważna dla twojego współpracownika. Dlaczego nie potraktować tego jako aktywa, a nie zobowiązania?

Poproś współpracownika o uznanie go za właściciela projektu ze wszystkimi obowiązkami, które się z tym wiążą. Spotkaj się ze swoim przełożonym i współpracownikiem. Podejdź do czegoś w rodzaju „ wygląda na to, że współpracownik X tutaj naprawdę lubi przejmować własność. Aby uprościć sprawy i zapewnić im odpowiednie doświadczenie w zakresie posiadania [jeśli to konieczne], pozwól im wziąć to - pomogę podążać za nimi i odkładać na decyzje dotyczące platformy, bibliotek, metod itp. Jednak następny projekt jest mój. Umowa?

Pozytywne aspekty tego podejścia:

  • Będziesz uważany za gracza, który akceptuje entuzjazm innych członków drużyny i daje im szansę na wykazanie się, jednocześnie eliminując czynnik stresu;
  • Będąc oficjalnie na tylnym siedzeniu, będziesz wybaczony wady projektowe (możesz zasugerować podejście, ale ostateczna decyzja nie należy do Ciebie);
  • Fakt, że zarówno kierownik, jak i współpracownik zaakceptują Twoją własność do następnego projektu, daje solidne podstawy do wykorzystania przejdźmy tym razem z moim podejściem, ok? ”, kiedy nadejdzie Twoja kolej na określenie specyfikacji;
  • Wdrożenie rozwiązania zgodnie z wizją współpracownika okaże się jeśli masz inny punkt widzenia na temat podejścia do definicji projektów.
Głosowano za pierwszym cytatem.:RE
@Wildcard To zasługuje na uznanie.Nie pamiętam nawet, ile projektów, które osobiście widziałem, zawodziło z powodu „zbyt wielu uderzających głów”.
To prawda, ale może przynieść odwrotny skutek.Współpracownik będzie postrzegany przez wszystkich jako lider, a plakat jako naśladowca.Kiedy pojawią się promocje, liderem będzie nowy szef.Uległość może pomóc projektowi, ale może również zaszkodzić twojej karierze.
@David jest więc powodem, dla którego `` * następny projekt jest mój * '' - zamiast być uległym, to gra zespołowa.Ponadto poszczególni liderzy projektu mogą dać menedżerowi dokładniejszy obraz tego, kto najlepiej nadaje się na lidera w oparciu o solidne wyniki i jasne role.
Podoba mi się ta odpowiedź i prawie każde podejście ma pewne ostrzeżenia, ale OP musi być ostrożny, następny projekt może nie nadejść przez jakiś czas, aw tym czasie percepcja współpracownika i PO może zostać ustalona, a oni będątrudno będzie zmienić.Również następny projekt może mieć znacznie mniejszy zakres.
Problem z tą odpowiedzią polega na tym, że nie każdy ma kwalifikacje do bycia menedżerem produktu i że istnieje wiele projektów oprogramowania, które kończą się niepowodzeniem lub są przeciągane w nieskończoność.Nie zrozum mnie źle, nie chcę twierdzić, że ten drugi facet nie ma kwalifikacji.Nie wiem.Mówię tylko, że niektóre projekty odniosą sukces bez względu na to, kogo powierzysz, ale projekt oprogramowania z drugiej strony może być zupełnie innym zwierzęciem i może łatwo doprowadzić do upadku twojego działu / kariery, jeśli postawisz niewłaściwą osobęza to odpowiedzialny.
@StephanBranczyk Myślę, że „on” odnosił się do Właściciela Produktu zasugerowanego w komentarzu nad komentarzem OP.
Ach ok, to ma sens.
Podoba mi się odpowiedź, ale może sprowadzić się do patrzenia, jak kolega ponosi porażkę i udawania, że to wszystko jego odpowiedzialność…
Oczywiście PO powinien również zaznaczyć, że ten, kto twierdzi, że chwała, ponosi odpowiedzialność (jeśli coś pójdzie nie tak)
@PierreArlaud Rozumiem, ale jeśli współpracownik przyjmuje na siebie odpowiedzialność (po wyraźnym przejęciu roli) to nie jest to udawanie - to szansa, aby współpracownik się wykazał.Jeśli już, może to być lekcja edukacyjna zarówno dla OP, jak i współpracownika, niezależnie od wyniku.
@OnoSendai Obawiam się, że część „następna jest moja” zostanie zapomniana lub celowo zignorowana.
@David to z pewnością może się zdarzyć, ale wtedy ujawniłoby wiele na temat polityki i podejścia kierownika projektu.Nadal przydatne informacje.
Własności są zwykle brane, a nie dawane - nawet jeśli przyczyniasz się do sukcesu projektu, Twój współpracownik może wydawać się lepszym „liderem”, a zatem bardziej odpowiednim do przyszłych leadów.To nie jest gra w krykieta, w której na zmianę odbijasz: P
@TCSGrad oczywiście zakładając, że współpracownik radzi sobie dobrze (niezależnie od kryteriów, których używa PM). A jeśli chodzi o zmianę kierunku - możesz być zaskoczony, ale widziałem, że dzieje się to w kilku profesjonalnych sytuacjach.To prawda, w większym stopniu dotyczy to przedsiębiorstw europejskich i południowoamerykańskich, w których konkurencyjność przybiera nieco inną formę.
Ustanawiając innego członka jako lidera, możesz ryzykować, że będziesz wyglądać, jakbyś nie miał cech przywódczych, a tym samym Twoja kariera może ucierpieć.Nawet jeśli usłyszą, jak mówisz o podjęciu następnego, kierownictwo nie spędza całego dnia na myśleniu o tobie i może o wszystkim zapomnieć.
@MarkRogers Całkowicie się zgadzam, że jest taka możliwość i OP powinien wziąć to pod uwagę, jeśli jego planowana ścieżka kariery obejmuje stanowiska kierownicze.Jednak jako specjalista nie powinno to być tak mocnym wymogiem.Ponadto OP powinien być w stanie przypomnieć Zarządowi o uzgodnionych warunkach, gdy nadejdzie czas rozpoczęcia nowego projektu.
David Schwartz
2017-03-15 00:23:38 UTC
view on stackexchange narkive permalink

Kiedy zasugeruje lub skrytykuje Twoją prośbę o ściągnięcie, wyjaśnij raz, dlaczego nie zamierzasz jej zmieniać, aby odpowiadała jego sugestii. Powinien być prosty i jasny. Na przykład:

„To nie poprawiłoby znacząco kodu.”

„Wysiłek mający na celu wprowadzenie tej zmiany nie jest uzasadniony jej wartością”.

„Obecna metoda jest prostsza.”

Jeśli nadal odmawia przyjęcia żądania ściągnięcia, eskaluj do kierownictwa. Możesz to zrobić przez e-mail, na przykład: „pull request X był otwarty przez Y czas, wciąż czekając na zgodę Z. Z nie podał wystarczającego uzasadnienia dla odrzucenia pull requesta.”

Zmusić go być tym, który opóźnia i przeszkadza, ponieważ to właśnie robi. Zwróć uwagę, że jego naleganie na ciągłe zmiany w projekcie lub odmowa terminowego zatwierdzania żądań ściągnięcia tylko dlatego, że nie są one wykonane w sposób, który według niego jest najlepszy, to marnowanie czasu.

Pamiętaj, że idziesz do zarządu po prostu zdecydować, czy Twój kod jest akceptowalny w obecnej postaci i czy żądanie ściągnięcia powinno zostać zaakceptowane. Twój kod spełnia obowiązujące standardy lub nie. Jeśli tak, należy to zaakceptować. Jeśli nie, to on ma rację, a ty się mylisz.

Jeśli tak, należy to zaakceptować.Jeśli nie, to on ma rację, a ty się mylisz.Dla mnie to jest ważna kwestia.
@coteyr I miejmy nadzieję, że po kilkukrotnym rozstrzyganiu przez kierownictwo sporów dotyczących żądań ściągnięcia, ktokolwiek nie spełnia oczekiwań kierownictwa, dokona ponownej kalibracji swoich standardów.OP może próbować przepchnąć naprawdę kiepski kod.Druga osoba może być perfekcjonistą, a nawet wręcz przeciwnie.Nie wiemy i kierownictwo powinno podjąć decyzję.
Tak, pozwól menedżerowi zarządzać.
Jedną z rzeczy, które często robię w tym kierunku, jest uznanie wartości sugestii PR, ale jeśli nie jest to wymagane, spróbuj uzyskać zgodę na otwarcie kolejnego zadania poprawy w zaległościach.W ten sposób nadal robisz postępy i masz niezły zestaw ulepszeń do wdrożenia, jeśli kiedykolwiek będziesz miał na to czas.
@SandyChapman - zakłada się, że w rzeczywistości są one obiektywnie ulepszeniami.Nie wygląda na to, że OP uważa, że tak jest.
@Martin to nieistotne.Wszyscy wiemy, że nigdy nie ma czasu na bilety na ulepszenia!Ha.Ale zwykle pozwala właścicielowi produktu ocenić, które ulepszenia są warte wprowadzenia, a które nie, skutecznie sprowadzając osobę trzecią do dyskusji w pewnym momencie w przyszłości (np. Podczas planowania sprintu).
jwsc
2017-03-15 00:10:25 UTC
view on stackexchange narkive permalink

Wciągałem menedżera i mówiłem mu, że ciągłe kłótnie zmniejszają wydajność. To jest coś, co musi rozwiązać.

Gdybym to był ja, spróbowałbym podzielić projekt. Próbuję znaleźć interfejs i dać każdemu własną część do zarządzania. Może możesz to zasugerować.

-1 Nie zgadzam się z tą sugestią.To coś, co widziałem kilka razy w różnych kontekstach i ogólnie nie jest zdrowe dla projektu.Twój jeden kod to teraz dwa i każdy będzie miał swoje własne dziwactwa i krzywe uczenia się, podwajając wysiłek związany z utrzymaniem nie tylko tych dwóch, ale wszystkich innych, którzy pracują nad tym projektem przez lata.Projekty z wieloma bazami kodów wymagają jednej nadrzędnej filozofii projektowania, aby je ujednolicić, a nie dwóch lub więcej, które je podzielą.
Całkowicie się nie zgadzam.Wolę najpierw z nim porozmawiać i zobaczyć, jaka będzie jego odpowiedź.zamiast iść do żłobie i prosić go o pomoc.
coteyr
2017-03-15 05:16:54 UTC
view on stackexchange narkive permalink

Często kwestionowanie którejkolwiek z jego sugestii lub proponowanie innej jest ogromną bitwą pod górę.

Czasami jest to normalne. W niektórych przypadkach jest to naprawdę cenne. Ty też powinieneś mieć ten poziom pewności siebie. Jeśli podejmiesz decyzję, powinieneś być gotowy na jej wykonanie.

Wydaje się, że spotyka się to za każdym razem, gdy nie chcę robić czegoś dokładnie tak samo, jak on, i jest to zwykle długi i żmudny proces.

To może być problem. Może nie. Czasami programiści mają trudności z zapamiętaniem „istnieje więcej niż x sposobów na skórowanie foo”. Możesz spróbować rozwiązać ten problem ze swoim menadżerem.

Na przykład, przypuśćmy, że wybiorę jakąś bibliotekę do wykonania jakiegoś zadania. Będę musiał mu to uzasadnić, co samo w sobie jest w porządku, ale istnieje niezwykle duży opór, nawet jeśli mogę uzasadnić jego użycie.

To bardzo dobrze. Ogromna dobra rzecz. Kiedy zarządzam zespołem, każda nowa biblioteka wymaga OGROMNEJ dyskusji. Osoba opowiadająca się za korzystaniem z biblioteki musi uzasadnić jej użycie. Musi być poważne uzasadnienie. Jeśli zamierzasz zmusić wszystkich w swoim zespole - i wszystkich, którzy kiedykolwiek do niego dołączyli - do korzystania z tej nowej zależności, lepiej, żeby było warto. Więc może to zły przykład. Jednak na etapie planowania można się spodziewać pewnego poziomu „walki o to, co chcesz”. Jeśli wykonujesz te poziomy połączeń w fazie „kodowania”, to źle na tobie. Powinny być one wykonane, omówione, zdecydowane itp. Na długo przed napisaniem pierwszej linii kodu (nowej funkcji). Dodanie zależności w czasie kodowania to dla mnie automatyczne odrzucenie żądania ściągnięcia, po którym następuje spotkanie. Następnie próba upewnienia się, że następnym razem rozłożymy zależności, zanim zaczniemy pisać kod.

Ogólnie nie czuję, że mam własną autonomię w podejmowaniu decyzji, które moim zdaniem powinny zostać przyznane;

Nie masz i to jest OK. Nie ma ja w zespole. Ponownie, jeśli są to kwestie na poziomie wdrażania, należy je wyjaśnić. Jeśli są to problemy z planowaniem poziomów, czas przygotować się do obrony.

Zamiast tego czuję, że jestem tylko jego asystentem.

Teraz to jest problem. Może być konieczne zdefiniowanie lepszych metryk dla przejścia / niepowodzenia żądania ściągnięcia. Na jakich warunkach jest przepustka? W jakich warunkach porażka? Jeśli to się nie powiedzie, czy są podane elementy do wykonania?

Jedną z reguł, których zawsze używam, jest to, że jeśli komuś nie powiedzie się żądanie ściągnięcia, musi podać elementy do wykonania, aby żądanie było akceptowalne.

Niepowodzenie: testy nie kończą się pomyślnie, popraw kod, więc testy zakończą się niepowodzeniem: Kod jest zbyt złożony, zmniejsz złożoność do akceptowalnych poziomów
Niepowodzenie: Ta logika należy do modelu, a nie do kontrolera, przenieś ją do modelu .
Niepowodzenie: nie używaj iteratorów, takich jak x, używaj rzeczywistych nazw zmiennych, w tym przypadku nazwij to „dla wpisu we wpisach” nie ”dla e we wpisach”

Wtedy przynajmniej patrząc na komunikat o niepowodzeniu masz miejsce na rozpoczęcie rozmowy.

Mój menedżer powiedział, że nie przeszkadza mu w tym mediacja, ale wydaje mi się to niewiarygodnie małostkowe z mojej strony.

Zadaniem menedżera jest zarządzanie; POZWÓL im . Jeśli twój menedżer zmęczy się obsługą tych próśb, zmusi ich do zaprzestania. Twój przełożony może preferować ten poziom nadzoru.

+1 głównie w części dotyczącej bibliotek.OP brzmi trochę samolubnie - generalnie stosujesz MAŁY.Jak powiedziałeś, każda dodatkowa (szczególnie nadmiarowa) biblioteka jest kwestią konserwacji i standaryzacji.W razie potrzeby - zrób to.Jeśli nie jest to naprawdę potrzebne, dlaczego w ogóle się kłócisz.Ta część i roszczenie do pożądanej autonomii (kosztem standaryzacji) to sygnały ostrzegawcze HUGH.
+1 za „pozwól menedżerom zarządzać. Jeśli ** się ** zmęczy, rozwiążą problem”.Mam na myśli ... najgorszy scenariusz, denerwujesz ich * tak bardzo *, że cię wyrzucają, w takim przypadku problem nadal (prawdopodobnie) zostałby rozwiązany.
Jeśli chodzi o biblioteki, to bardziej chodzi o to, że nigdy nie słyszę rozsądnego powodu _nie_ go używać.Na przykład, gdybym miał skopiować i wkleić kod bezpośrednio i nieco go sformatować, zostałby zaakceptowany.Jeśli dołączam go z paczki, uważa się to za niewłaściwe.Zwykle argument brzmi: „Nigdy wcześniej nie widziałem tego pakietu, nie może być przydatny”.Właśnie dlatego uważam to za problem.Niektóre przykłady mogą przypominać bibliotekę typu „przeciągnij i upuść” dla bardziej zaawansowanych zachowań lub bibliotek renderowania 3D
Ostatni ważny przykład: https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/
Każda biblioteka to taka, którą musisz zobowiązać się utrzymywać (lub napisać nowy kod w celu zastąpienia), jeśli pierwotni opiekunowie ją porzucą.Może to być również punkt awarii, na który nie masz wpływu.Nawet w przypadku czegoś tak dużego jak jQuery, „zgadzasz się” na utrzymywanie aplikacji w zgodzie z jej najnowszymi aktualizacjami, w przeciwnym razie spowodowałbyś problemy z bezpieczeństwem itp. Duży lub mały zawsze wiąże się z „kosztem” korzystania z zewnętrznej biblioteki.
Matthieu M.
2017-03-15 13:29:29 UTC
view on stackexchange narkive permalink

Na przykład przypuśćmy, że wybiorę użycie jakiejś biblioteki do wykonania jakiegoś zadania. Będę musiał mu to uzasadnić, co samo w sobie jest w porządku, ale jest niezwykle wysoki opór, nawet jeśli mogę uzasadnić jego użycie. Ogólnie rzecz biorąc, nie czuję, że mam własną autonomię w podejmowaniu decyzji , która moim zdaniem powinna zostać przyznana; zamiast tego czuję, że jestem tylko jego asystentem.

W zespole / firmie nie masz swojej autonomii w podejmowaniu decyzji; przynajmniej nie w przypadku decyzji na wysokim szczeblu, takich jak wybór nowej technologii, nowej biblioteki, decyzja o architekturze, ...

Pracując nad projektem w zespole, musisz być wymienne . W każdej chwili możesz zachorować / zostać potrąconym przez autobus, a inny współpracownik powinien być w stanie podejść i kontynuować z miejsca, w którym byłeś.

Im bardziej współpracownik jest zaznajomiony z Twoją pracą, tym lepiej, dlatego ma znaczenie, że:

  • korzystasz z tych samych bibliotek stron trzecich, co wszyscy inni w firmie,
  • tworzymy projekt w taki sam sposób, jak każdy inny projekt w firma,
  • ...

Oczywiście jest miejsce na eksplorację. Nowa biblioteka innej firmy, nowa struktura itp. Mogą poprawić stan rzeczy, ale są one destrukcyjne, dlatego ich korzyści powinny w dużej mierze zrównoważyć ich koszty. To musi być świadoma decyzja ze strony działu / oddziału / firmy . To nie jest twoje zadanie, chociaż możesz to zrobić.

Musimy się nawzajem zatwierdzać żądania ściągnięcia, więc jeśli zrobię coś, co mu się nie podoba, ma możliwość odrzucić go wprost, dopóki go nie zmienię, aby spełnić jego sugestie. Jeśli muszę zrealizować tę funkcję, albo muszę stanąć na swoim miejscu i spędzić dużo czasu na uzasadnianiu tego, albo muszę po prostu zmienić to na to, co sugeruje, i ruszyć dalej swoim życiem. trochę jak skała i trudne miejsce

Jeśli mogę, myślę, że jest tu problem z metodą pracy.

Projektowanie wysokopoziomowe powinno być omówione przed rozpoczęciem pracy; szkoda tylko czasu pracować nad czymś przez tydzień, przedstawiać to do zatwierdzenia i odrzucać z uzasadnieniem „Czekaj, czy rozważałeś interakcję z X? To nigdy nie zadziała!”.

Oznacza to, że przed rozpoczęciem pracy musicie zgodzić się jako zespół na ogólny kierunek. A jeśli coś pojawi się w połowie, co wymaga drastycznej zmiany, musicie uzgodnić jako zespół, dokąd stąd pójść.

Uwaga: widziałem, jak ludzie argumentowali za zatwierdzeniem swojego PR, ponieważ wykonał dużo pracy, pomimo zastrzeżeń co do jego jakości lub projektu. Boli, gdy twoje wysiłki są odrzucane ... dlatego najlepiej omówić to wcześniej.


Więc zakładając, że:

  • Ty mieć zgodę kierownictwa na technologie, biblioteki zewnętrzne i projekt projektu,
  • wcześniej uzgodniłeś ogólny kierunek żądania ściągnięcia.

Następnie omówienie Samo żądanie pull powinno skupiać się na:

  • dopracowaniu skrajnych przypadków,
  • oczyszczeniu implementacji,
  • wyjaśnieniu niejasnych bitów.

Gdy znajdziesz się w niebieskim księżycu, możesz otrzymać komentarz w stylu „O cholera, zapomnieliśmy uwzględnić przypadek X”. Zdarza się. To błąd zespołu.


To oczywiście nie rozwiązuje w magiczny sposób problemu z własnością. Twój współpracownik może nadal być trudny do opanowania podczas wczesnej dyskusji na temat ogólnego kierunku żądania ściągnięcia.

Ogólnie rzecz biorąc, to, czy ktoś ma „własność”, czy nie, nie ma znaczenia, chcesz konsensusu .

Twoim pierwszym celem powinno być zatem zrozumienie, dlaczego współpracownik jest trudny:

  • czy ma inną wizję?
  • czy jest idealistą?
  • czy jest maniakiem kontroli?
  • czy nie ufa twoim umiejętnościom?
  • ...

i spróbuj rozwiązać problem z nim.

Musisz dostosować się do wizji projektu na wysokim poziomie, zdobyć jego zaufanie co do swoich umiejętności, ...

Jeśli wszystko inne zawiedzie, w ostateczności 1 , możesz zaangażować swojego przełożonego i poprosić go o podział obowiązków. Wspomniałeś o tobie i miał różne zestawy umiejętności, więc powinieneś być w stanie podzielić obowiązki na 3 obszary: jego obszar, twój obszar i wspólny obszar. W twojej okolicy jego opinia byłaby czysto informacyjna (i odwrotnie).

1 I wreszcie, konfrontacja sprawia, że ​​ludzie są kwaśni.

`Jeśli wszystko inne zawiedzie, w ostateczności1 możesz zechcieć zaangażować swojego menedżera i poprosić go o podział obowiązków. 'Bardzo podoba mi się ten pomysł, ale nie rozumiem, dlaczego jest * ostatecznością *, a nie *pierwszy*.Można go łatwo zaproponować w sposób niekonfrontacyjny [potrzebne źródło]
@xDaizu: Jeśli potrzebujesz sędziego, oznacza to, że nie możesz znaleźć porozumienia.To bardzo źle.Dorośli powinni umieć się zgodzić, nawet jeśli zgadzają się tylko na podział obowiązków * samodzielnie *.Nie chodzi o to, jak o to prosisz, ale o konsekwencje niepowodzenia w osiągnięciu konsensusu, z którym musisz żyć.Istnieje duże ryzyko podpalenia mostów, gdy apelujesz do wyższych władz, aby przeciwstawić się komuś.To zatruje twój związek z nimi.I mówimy tutaj o koledze z drużyny.
ChrisW
2017-03-15 17:24:47 UTC
view on stackexchange narkive permalink

Czy jest lepszy sposób na rozwiązanie tego problemu?

Zastanawiam się, czy jego zdaniem każda decyzja jest binarna:

  1. Prawidłowo / poprawnie (tj. mój sposób)
  2. Źle (tj. na swój sposób, nie w mój sposób, nie zrobiłbym tego w ten sposób)

Myślę, że ważne jest, aby kategoryzować decyzje na co najmniej trzy segmenty zamiast dwóch:

  1. Zadowalające (oboje zgadzamy się, że to jest dobre)
  2. Nie do przyjęcia lub nie do przyjęcia (istnieje obiektywna, dająca się zidentyfikować szkoda związana z propozycją)
  3. Wystarczająco dobre lub do przyjęcia (np. nie zrobiłbym tego tak, jak sugerujesz, ale to, co sugerujesz, jest wystarczająco dobre, natychmiast adekwatne i lepsze niż nic)
  4. Jedno z moich doświadczeń związanych z przeglądami kodu miało miejsce, gdy byłem formalnym strażnikiem (tj. liderem zespołu lub właścicielem produktu) i pamiętam, że moja opinia o przeglądzie kodu miała trzy kategorie:

    1. To jest dobre, gotowe do odprawy
    2. To jeszcze nie jest gotowe, musisz to zmienić (potrzebuję u aby to zmienić) przed zameldowaniem
    3. Widzę, co zrobiłeś, to działa; FYI nie zrobiłbym tego w ten sposób, zrobiłbym to w inny sposób; możesz to zmienić (przed zameldowaniem, aby zrobić to tak, jak zasugerowałem) jeśli chcesz, ale nie musisz.
    4. Posiadanie tej trzeciej kategorii jest w pewnym sensie konieczne, jeśli chcesz autonomicznej pomocy.

      Zauważ, że jeśli istnieje „obiektywna, możliwa do zidentyfikowania szkoda związana z propozycją”, to oboje powinniście widzieć i zgodzić się, że szkoda istnieje. Jeśli nadal jest jakaś różnica zdań, może chodzi o kompromis, a może to jest temat, który możesz przedstawić menedżerowi produktu (np. „Szefie, czy powinniśmy używać komponentu innej firmy i polegać na nim lub zastosuj bardziej zasadę Nie wymyślono tutaj? ”).

      A może w pobliżu jest inny programista? Pracowałem z małym zespołem doświadczonych rówieśników. Rozmawialiśmy ze sobą jeden na jeden, aby omówić i zdecydować o naszych interfejsach. W rzadkich sytuacjach, gdy dwie osoby nie mogły lub nie zgadzały się co do czegoś, wprowadzaliśmy do dyskusji innego (tj. Trzeciego) programistę (w celu znalezienia konsensusu lub decyzji większością głosów).



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...