Jak przekonać członka zespołu, który uważa się za starszego, do nauki podstaw koncepcyjnych SVN? [Zamknięte]

Aby zacząć od pewnego zaplecza, tego lata objąłem nowe stanowisko programisty i ostatecznie zostałem najnowszym członkiem zespołu, ale z największym doświadczeniem.

Do tej pory udało mi się przeforsować inicjatywy związane z rozsądkiem ze względu na niskie koszty adopcji (pod względem czasu i wysiłku). Jednak sprawy nieco się poprawiły.

Jeden z moich kolegów z zespołu, choć ma doświadczenie, tak naprawdę nie rozumie SVN. Oczywiście puste obszary na jego mapie mentalnej przedstawiające oceany SVN powodują, że przyjmuje raczej dziwne wzorce użytkowania.

Na przykład zadeklarował zasadę „1 zatwierdzenie SVN dziennie na programistę”, ponieważ w przeciwnym razie „serwerowi wkrótce zabraknie miejsca na dysku”. Kiedy wyjaśniłem mu, że SVN to delty, a nie pełne kopie, odpowiedział wątpliwie i nawet dzisiaj nie jestem całkowicie pewien, czy rozumie, co to znaczy.

Mieliśmy również gorącą dyskusję na temat tego, czy dołączyć .projectkonfigurację Eclipse do SVN. Mój kolega z drużyny nalegał, że powinniśmy, chociaż spowodowało to wiele bezcelowych konfliktów. Byłem przeciwny przechowywaniu indywidualnych plików konfiguracyjnych programistów w SVN. W końcu okazało się, że mój kolega z zespołu ćwiczył ponowne sprawdzanie całego drzewa źródłowego po każdym zatwierdzeniu, aby upewnić się, że „kod przypisany do repozytorium działa”. Z tego powodu był tak nieugięty w utrzymywaniu konfiguracji projektu w SVN - więc łatwo byłoby ponownie zaimportować projekt. Kiedy wyjaśniłem, że zatwierdzanie synchronizuje kopię roboczą ze zdalnym bajtem po bajcie, co sprawia, że ​​ponowne sprawdzanie nie jest konieczne, mój kolega z zespołu ponownie odpowiedział wątpliwości i ostatecznie zignorował cały problem jako nieistotny.

Moim zdaniem nasz zespół marnuje czas, rozwiązując konflikty SVN w plikach konfiguracyjnych projektu, które zawierają tylko ustawienia specyficzne dla programistów, których wcale nie trzeba udostępniać SCM. Cały ten bałagan, ponieważ ktoś dostosował proces wokół błędnych założeń.

Jak przekonać członka drużyny, który uważa się za starszego, aby lepiej zrozumieć podstawy SVN?

IMO najlepiej oddzielić te problemy, które powodują bezpośrednie problemy / szkody dla projektu, od tych, które dotyczą tylko jednego dewelopera . Np. Jeśli woli sprawdzać wszystko kilka razy dziennie, to spowolni go, ale w przeciwnym razie nie wpłynie na innych. Możesz więc pozwolić mu to zrobić (dopóki w jego pracy nie wystąpi zauważalne opóźnienie) i uchronić się przed kłótnią.

Inne problemy, o których wspominasz, takie jak trzymanie .projectplików Eclipse w repozytorium lub 1 zatwierdzenie dziennie, są tym, na czym powinieneś się skupić, aby umożliwić zespołowi postępy tak płynnie, jak to możliwe. Przede wszystkim powinieneś zapytać / zebrać informacje zwrotne od innych członków zespołu , czy to też powoduje dla nich problemy. Jeśli są inne, razem możesz wywierać większą presję , a jeśli to konieczne, możesz łatwiej eskalować problem w kierunku zarządzania.

Jeśli chodzi o „SVN zabraknie miejsca na dysku”, łatwo byłoby obalić jego przekonanie, przeprowadzając eksperyment (potencjalnie w osobnym repozytorium testowym). Musisz tylko monitorować rozmiar fizycznej hierarchii plików repozytorium przed i po zatwierdzeniu zmian w jednym dużym pliku tekstowym lub nawet wielu plikach. Jeśli to go nie przekona, nic nie może.

W takim przypadku, niestety, prawdopodobnie masz problem z autorytetem, gdy drugi facet uważa, że ​​przyjęcie porady od kogoś „niższego stopnia” to utrata jego godności. Tego rodzaju konfliktów nie można rozwiązać za pomocą logicznego argumentu. Musisz go eskalować w kierunku zarządzania, ale uważaj, aby zapewnić sobie wystarczające wsparcie (od członków zespołu i / lub kierownictwa), zanim to zrobisz. Taki ruch może być postrzegany przez drugiego faceta jako atak otwarty, a zatem może mieć problematyczne konsekwencje (dla każdego z was i / lub spokoju całej drużyny). Zastanów się więc trzy razy i porozmawiaj ze współpracownikami, zanim wykonasz ten ruch.

Jeśli Twoja firma korzysta z wiki, napisz kilka wysokiej jakości postów na temat SVN:

• Dlaczego warto go używać?
• Kiedy należy go użyć?
• Jakie problemy rozwiązuje?

itp.

Przyciągnie to uwagę CTO i każdy, kto odmówi użycia, będzie musiał użyć :)

Jako lider, menedżer i członek zespołu miałem do czynienia z rozwiązywaniem konfliktów zawodowych i osobowościowych na wielu poziomach. Bez względu na to, w jakiej roli jestem zatrudniony, zazwyczaj zostaję zaakceptowany jako lider, nawet jeśli nie chcę tej roli. Powodem tego jest sposób, w jaki radzę sobie z tymi konfliktami.

W przeciwieństwie do wielu ludzi tutaj, nie zgadzam się, że poradzenie sobie z tą sytuacją jest „poddaniem się” lub „pokazaniem mu nowego narzędzia” lub „czekaniem, aż spadnie na tyłek lub rozpadnie się”. Co najważniejsze, nigdy nie jest dobrym pomysłem czekanie, aż role zostaną ściślej określone. Role te określają ludzie, którzy nie czekają, przekonania, etyka i umiejętność radzenia sobie w sytuacjach krytycznych, niezależnie od tego, czy dotyczą ludzi, czy nie.

Istnieje kilka metod radzenia sobie z typem osoby, którą opisujesz w takich sytuacjach. Pierwszym i najważniejszym krokiem jest zbadanie, dlaczego jest on zachowuje się tak, że On jest. Ma niewiele wspólnego z tym, co wie lub nie wie. Mógł łatwo znaleźć te informacje wcześniej, więc pytanie jest naprawdę jedną z dwóch rzeczy: „Dlaczego nie?” lub „Dlaczego odrzuca przekazane mu informacje?” Pomoże ci to znaleźć dokładnie to, co należy rozwiązać.

Z mojego doświadczenia wynika, że ​​programiści (w tym ja) odmawiają dobrych praktyk lub nowych narzędzi tylko z kilku powodów:

• Źródło nie jest wiarygodne. W branży, która z dnia na dzień staje się coraz bardziej spolaryzowana między „kultem Maca” a „czcicielami stwardnienia rozsianego”; między „ideologią otwartego oprogramowania” a „praktyczną własnością” ... itd. itd. - Wielu ma wątpliwości co do dostarczonych informacji i ich potencjalnego uszkodzenia z powodu stronniczości autora lub autora, nawet jeśli informacje te są zweryfikowane jako wiarygodne.
• Długotrwałe złe doświadczenia ... z podobną lub nawet tą samą technologią lub praktyką. Na początku nic nie jest idealne, a wielu zaczyna od mniej niż 1/4 funkcji niż kończy. Jest całkiem możliwe, że miał wiele godzin, dni lub nawet tygodni, pracując z gorszym produktem lub tym samym podczas słabo wdrożonej fazy.
• „Wiarygodne” źródło… koliduje z informacjami, które są mu prezentowane. Przez „wiarygodny” rozumiem osobę lub podmiot, któremu ufa. Wiele osób ma tendencję do podnoszenia ludzi, którym ufamy, do poziomów, które nie reprezentują rzeczywistości. To źródło nie musiało nawet narzucać tej wiary osobie. Najczęściej robimy to sami. Często daje nam coś lub kogoś, kim chcemy być, przynajmniej w jednym aspekcie.
• Brak bezpieczeństwa Podkreślił to poprzedni plakat. Nasze programy stają się aktywami od momentu, gdy zaczniemy nad nimi pracować. Nie tylko dla firm, dla których pracujemy, ale dla ludzi, z którymi współpracujemy. To nie jest po prostu kwestia kontroli. Niektórzy z nas chcą być w stanie pokazać nasze schludne rzeczy osobom, na których nam zależy. Niektórzy z nas chcą się upewnić, że nie wyrządzi to szkody osobie zewnętrznej lub produktowi. Dla niektórych jest to rozszerzenie nawet tego, jak myślimy i czujemy. Zawiera niektóre nasze filozofie i ideologie oraz odsłania nasze rdzenie intelektualne. Dla wielu jest to nasza przyszłość, bez względu na to, czy dotyczy to klasy, pracodawcy czy klienta. Dla niektórych jest to wszystko. „Bezpieczeństwo” w tym sensie niekoniecznie dotyczy danych lub kodu.

Ustalenie, który czynnik jest często dość łatwy. Ustaw osobę w neutralnym otoczeniu. Wyjaśnij osobie to, co obserwujesz. Zapytaj osobę szczerze, co powoduje takie zachowanie. Teraz nie zawsze idzie dobrze, ale większość dorosłych reaguje całkiem dobrze, gdy wydaje się, że chcesz pomóc komuś, kto wydaje się działać irracjonalnie. Możliwe, że nie postępuje irracjonalnie, ale nie zdaje sobie sprawy, że nikt nie może zrozumieć, co się naprawdę dzieje.

Gdy dowiesz się, na czym polega problem, możesz wyposażyć się w odpowiednie narzędzia, aby sobie z tym poradzić. Jeśli jest to scenariusz nr 1, zachęć go do przeprowadzenia badań ze źródeł, którym ufa i (jest to ważne)wróć do ciebie z własnymi ustaleniami. To powie mu, że jego informacje mają dla ciebie wartość. W przypadku scenariusza nr 2 podaj dokładne porównania z tym, co jest teraz inne niż wcześniej. Zachęć go, aby spróbował, ale przygotuj plan awaryjny na wypadek, gdyby się nie udało. W przypadku scenariusza nr 3 powiedz mu, żeby poprosił o źródło informacji o TWOICH informacjach. Możliwe, że jego źródłem nie są poglądy, o których myśli, że tak, ale kiedyś tak było. Większość z nas dostosowuje się z czasem, więc jego punkt widzenia prawdopodobnie się zmienił. Jeśli nie chce, zachęć go, by przedstawił cię swojemu źródłu. I wreszcie, w przypadku scenariusza nr 4, zapewnij go, że jego zmartwienia są twoje. (Powinny być na pewnym poziomie) Zademonstruj, w jaki sposób to „nowe” narzędzie może chronić jego interesy i zwiększać jego bezpieczeństwo. A jeśli nie może,

Wiem, że wszystko to wydaje się zbyt proste do działania, ale czasami po prostu tak jest. W rzeczywistości, im bardziej jesteś szczery, tym częściej to robi. Odpowiadając na jego potrzeby, zaspokajasz potrzeby zespołu, bez względu na to, czy jest on „seniorem”, czy nie, ponieważ jest on częścią zespołu. Pokazanie mu, że chcesz być na tej samej stronie co on, ale po prostu go nie ma, może zachęcić go do współpracy z tobą. Jeśli zrobiłeś to wszystko i nadal nie osiągnąłeś rozwiązania, to zrobiłeś wszystko, co w twojej mocy, aby porozmawiać z liderem zespołu.

FuzzicalLogic

Istnieje wiele przesądów dotyczących kontroli źródła. Jest sprzeczny z intuicją, matematyka jest tajemna i obejmuje najważniejszy zasób, jaki posiada firma programistyczna. Muszę przyznać, że część mnie wciąż nie ufa. Ale nie zrobiłbym tego bez minuty.

Jednym z rozwiązań może być przejęcie odpowiedzialności za dbanie o repo. Oczywiście, jeśli przedstawisz to jako „to dla ciebie dużo pracy, a to akurat jest obszar, w którym mam pewne doświadczenie”, zamiast „nie wiesz, co robisz”, to będzie większa szansa na pracę.

Jeśli „uważa się za starszego” oznacza to, co myślę, że tak robi, nie pozwoli mu odejść, ponieważ postrzega to jako źródło władzy i kontroli. Obejściem tego problemu może być użycie Git lokalnie do zarządzania rozsądnymi jednostkami zatwierdzania i gałęziami, a następnie po prostu naciskaj svn raz dziennie, tak jak tego zażąda. Git został zaprojektowany jako system peer-to-peer i ma pełną kopię repo na każdym komputerze lokalnym. Możesz zaoferować git innym programistom, którzy woleliby to zrobić w ten sposób, i może pozostać jedynie dodatkiem do SVN, z którego korzystają poszczególne grupy robocze (niezależnie od tego, czy jest to jeden czy więcej programistów, formalny czy ad-hoc). A kiedy nadejdzie dzień, gdy starszy facet ustąpi, przeprowadzi się do innego działu lub firmy lub zamaluje się w nieodwracalnym kącie dzięki swoim zasadom SVN, masz przewagę, by wszystko to oczyścić.

Po prostu z nimi porozmawiaj. Słuchaj, jestem starszym programistą, ale są rzeczy, których nie wiem. Taka jest natura firmy. Jeśli staną się defensywni lub agresywni, jest to problem osobowości z deweloperem na wszelki wypadek, którym powinien zająć się lider zespołu lub szef zespołu.

Rozpocznij inicjatywę brązowej torby, raz na kilka tygodni ktoś organizuje poranną rozmowę na temat czegoś, o czym wie i przedstawia ją innym.

Używasz tego jako pretekstu do szczegółowego przedstawienia SVN i być może niektóre przemyślenia stojące za niektórymi alternatywami.

Kilka tygodni później ktoś inny może spróbować.

Postaram się przekazać kilka wskazówek popartych moim osobistym doświadczeniem.

Jeden z moich kolegów z zespołu, choć ma doświadczenie, tak naprawdę nie rozumie SVN. Oczywiście puste obszary na jego mapie mentalnej przedstawiające oceany SVN powodują, że przyjmuje raczej dziwne wzorce użytkowania.

Na przykład zadeklarował zasadę „1 zatwierdzenie SVN dziennie na programistę”, ponieważ w przeciwnym razie „serwerowi wkrótce zabraknie miejsca na dysku”. Kiedy wyjaśniłem mu, że SVN to delty, a nie pełne kopie, odpowiedział wątpliwie i nawet dzisiaj nie jestem całkowicie pewien, czy rozumie, co to znaczy.

Nawet jeśli miejsce na dysku stanowi problem, zawsze możesz zatwierdzić wiele plików naraz, więc myślę, że sugeruje niewłaściwe rozwiązanie. Co więcej, można marnować dużo miejsca, sprawdzając duże pliki binarne, ponieważ SVN nie przechowuje delt dla plików binarnych. Jedno zameldowanie dziennie jest również złe, ponieważ zmusza do dokonania zmian, które nie pasują do siebie, np. W przypadku naprawy więcej niż jednego błędu dziennie.

Rozwiązaniem, które przyjęliśmy w naszej firmie, jest filtr odrzucający wszelkie zatwierdzenia zawierające pliki binarne. Możemy wymusić zatwierdzenie, używając specjalnego słowa kluczowego w komentarzu do zameldowania (musimy pokazać SVN, że wiemy, co robimy). Raz na rok lub dwa kierownik projektu archiwizuje stare oddziały i usuwa je z repozytorium. Dzięki tej strategii nie mamy problemów z przestrzenią, o których wiem (nasze repozytorium obsługuje kilka różnych projektów i zawiera ponad 100 000 wersji).

Podsumowując, możesz mu powiedzieć, że zgadzasz się z nim, że miejsce na dysku jest ważną kwestią, ale z drugiej strony

1. znaczenie meldowań związanych z funkcjami zamiast jednego monolitycznego codziennego meldowania;
2. fakt, że wpisując jeden duży plik binarny dziennie, i tak można zapełnić dysk.

Następnie możesz zasugerować spotkanie (ewentualnie z innymi programistami lub administratorami systemu), aby omówić strategie kontrolowania wykorzystania miejsca na dysku (np. Filtry plików binarnych, regularne tworzenie kopii zapasowych i czyszczenie starych nieużywanych gałęzi).

Mieliśmy również ostry spór o to, czy dołączyć konfigurację Eclipse .project do SVN. Mój kolega z drużyny nalegał, że powinniśmy, chociaż spowodowało to wiele bezcelowych konfliktów. Byłem przeciwny przechowywaniu indywidualnych plików konfiguracyjnych programistów w SVN. W końcu okazało się, że mój kolega z zespołu miał praktykę ponownego sprawdzania całego drzewa źródłowego po każdym zatwierdzeniu, aby upewnić się, że „kod przypisany do repozytorium działa”. Z tego powodu był tak nieugięty w utrzymywaniu konfiguracji projektu w SVN - więc łatwo byłoby ponownie zaimportować projekt. Kiedy wyjaśniłem, że zatwierdzanie synchronizuje kopię roboczą ze zdalnym bajtem po bajcie, co sprawia, że ​​ponowne sprawdzanie nie jest konieczne, mój kolega z zespołu ponownie odpowiedział wątpliwości i ostatecznie zignorował cały problem jako nieznaczący.

Moim zdaniem nasz zespół marnuje czas, rozwiązując konflikty SVN w plikach konfiguracyjnych projektu, które zawierają tylko ustawienia specyficzne dla programistów, których wcale nie trzeba udostępniać SCM. Cały ten bałagan, ponieważ ktoś dostosował proces wokół błędnych założeń.

Czy korzystasz z serwera kompilacji? Mamy serwer kompilacji, który sprawdza kompletny projekt i kompiluje go co noc. Następnego ranka testerzy mają gotowego do przetestowania instalatora produktu (jeśli kompilacja główna działała poprawnie), a my (programiści) mamy raport kompilacji ze wszystkimi ostrzeżeniami (i ewentualnymi błędami). Oczywiście musisz skonfigurować standardowe pliki konfiguracyjne dla serwera kompilacji i zarejestrować je. Każdy programista może następnie sprawdzić je wraz z resztą projektu, ale nie mogą wprowadzać żadnych zmian lokalnych.

W tym scenariuszu zasygnalizowałeś jego potrzebę sprawdzenia kompletnego projektu i zbudowania go w dowolnym momencie. Unikasz także spędzania czasu na scalaniu zmian, które nie powinny były być sprawdzane przede wszystkim, ponieważ nie są one częścią produktu: produkt jest kompilacją główną i należy go utrzymywać w czystości. Jeśli ktoś zepsuje kompilację główną (np. Sprawdzając własny plik .project), możesz cofnąć zmiany lub zmusić programistę do rozwiązania problemu.

Może jeśli ponownie poruszy ten problem, możesz ponownie zasugerować spotkanie (być może z innymi programistami) i znaleźć wspólną strategię.

Jak przekonać członka drużyny, który uważa się za starszego, aby lepiej zrozumieć podstawy SVN?

Myślę, że najlepszą strategią byłoby uniknięcie sprowadzania konfliktu na poziom osobisty, a raczej omawianie bieżących problemów i możliwych rozwiązań. Jeśli masz wrażenie, że szuka on osobistej konfrontacji, oto kilka sugestii (ponownie z własnego doświadczenia):

• Jaka jest dynamika twojego zespołu? Czy twoi inni koledzy mają podobne doświadczenia z tym kolegą z zespołu? Istnieje wiele małych, niezbyt wyraźnych wskazówek, które zespół może przekazać jednemu ze swoich członków, aby zniechęcić do pewnych zachowań (małe dowcipy lub spostrzeżenia) i zachęcić do konstruktywnej konfrontacji (proponowanie spotkania lub nieformalne poruszenie tematu podczas przerwy na kawę ). Czasami dobry zespół może szybko odizolować niepokojący element i przywrócić go do normy.
• Jak dobre jest zarządzanie personelem? W naszej firmie mieliśmy jeden konflikt, a szef personelu musiał interweniować, aby wyjaśnić sytuację. Nie było miło, ale czasami atmosfera pracy pogarsza się tak bardzo, że sama się nie poprawi. Mam nadzieję, że to nie twoja sprawa (nie mam wrażenia, że ​​do tej pory doszło tak daleko), ale zawsze dobrze jest wiedzieć, czy masz dobrą administrację personelu lub czy musisz samodzielnie rozwiązywać konflikty.

Dlaczego to piszę? Mówisz, że chcesz „przekonać członka drużyny, który uważa się za seniora, aby lepiej zrozumieć podstawy SVN”. Wydaje mi się, że konflikt może być zbyt osobisty. Niektórzy psychologowie utrzymują, że 70% naszej komunikacji odbywa się na poziomie emocjonalnym, jeśli ten poziom nie działa, ludzie przestają mówić o faktach, ponieważ są zbyt zajęci radzeniem sobie z emocjami.

Więc oprócz wyjaśnienia swoich punktów, możesz również spróbować zrobić coś, aby poprawić komunikację. Zaproszenie na kawę lub wspólną przerwę na lunch, krótka rozmowa na temat niezwiązany z pracą itp. Może poprawić komunikację i przywrócić uwagę kolegi na ważne fakty , które powinien zrozumieć. Jeśli zaakceptuje tego rodzaju komunikację, być może konflikty, które do tej pory miałeś, były związane z faktem, że nie znacie się dobrze i były pewne małe nieporozumienia, ale prawdopodobnie jest on otwarty na budowanie konstruktywnej współpracy. Jeśli odmówi, może być po jego stronie głębsza wrogość.

W tym przypadku myślę, że powinieneś poczekać, aż twoje role staną się jaśniejsze. Jeśli twój kolega z drużyny nie ma oficjalnie wyższej rangi niż twoja, nie ma sensu denerwować się twoimi próbami poprawy. Z czasem będzie musiał to zaakceptować lub zrobić z siebie głupca, jeśli będzie próbował pokazać, że wie lepiej. Jeśli ma wyższą rangę, powinieneś znaleźć sposób, aby uświadomić mu, że nie jest to przedmiotem dyskusji: twoje obserwacje mają na celu poprawę wydajności, a nie osłabienie jego pozycji, musi to być w 100% jasne. Kiedy role zostaną wyjaśnione, jeśli nadal nie może zaakceptować konstruktywnych sugestii lub krytyki, to naprawdę musi mieć problem z samooceną lub coś w tym rodzaju.

Więc jeśli wszystkie powyższe strategie zawiodą i nadal czujesz się (bardzo) sfrustrowany, obawiam się, że jedyną rozsądną rzeczą do zrobienia jest spakowanie swoich rzeczy i poszukiwanie lepszego miejsca. Doświadczyłem tego trzy lata temu i znalazłem lepszą firmę, w której jestem teraz bardzo zadowolony. Może to nie twój przypadek (mam nadzieję, że nie), ale spróbuj też zrozumieć ten punkt.

Tylko moje 2 centy.

Wskaż mu materiał do nauki o tym, jak działa SVN i jakie są najlepsze praktyki korzystania z SVN.

Jak mówi @Peter - starannie wybieraj bitwy i nie marnuj energii na walkę z kimś, kto oczywiście nie rozumie podstaw. SVN nie jest najnowocześniejszą technologią i istnieje już od jakiegoś czasu, więc jest wystarczająco dużo informacji na ten temat.

Spróbuj zapisać dziennik „marnowania czasu SVN”. Za każdym razem, gdy występuje problem dotyczący konfliktu / kasy / wersji, który wymaga rozwiązania, zanotuj, ile czasu zajęło Tobie / zespołowi jego rozwiązanie. Jeśli okaże się, że marnujesz znaczną ilość czasu co tydzień, eskaluj go wraz z nim i zarządem. Jestem pewien, że kierownictwo wkrótce poprosi o rozwiązania, jeśli zdadzą sobie sprawę, że produktywność można poprawić za pomocą prostych zmian w procesie pracy.

Lub spróbuj przekonać swojego kolegę, aby odbył tydzień próbny, w którym zespół korzysta z twojego systemu meldowań (jeśli jest to łatwo osiągalne przy twoich bieżących projektach i bazie kodu). Obiecaj mu, że jeśli to się nie uda, możesz wrócić do starego systemu po upływie tygodnia. Ale może przyjść po tym, jak sam to wypróbuje.

1. Pozwól Subversion rozwiązać problem za ciebie. Sposób, w jaki to mówisz, jest stosunkowo mało wyrafinowany, jeśli chodzi o Subversion. W takim przypadku dobrym rozwiązaniem może być rozwiązanie techniczne. Jeśli reszta zespołu wyrazi zgodę i możesz uzyskać błogosławieństwo swojego menedżera, dodaj global-ignorespole do pliku konfiguracyjnego repozytorium , aby można było wykluczyć pliki .project i inne , których nie chcesz kontrolować pod kontrolą wersji.

2. Pomóż mu. Zamiast narzucać mu swój sposób robienia rzeczy, spróbuj pomóc facetowi robić rzeczy po swojemu, nie powodując problemów dla wszystkich innych. Jeśli twój współpracownik pracuje we własnym oddziale, nie powinieneś przejmować się tym , co on popełni. Jeśli chce zatwierdzić swój plik .project, aby mógł pobrać nową kopię całego katalogu, to nie ma problemu. Jedyną rzeczą, na którą powinieneś zwrócić uwagę, jest to, że nie scala on swojego pliku .project z powrotem do wspólnej gałęzi programistycznej. To powinno być łatwe do zarządzania, ponownie poprzez ustawienie właściwości ignorowania w gałęzi programistycznej, aby wykluczyć plik .project.

3. Szukaj wsparcia z góry. Nie wdawaj się w kłótnię z facetem „nie jesteś moim szefem”, ale jeśli jego zachowanie stanowi dla ciebie problem, upewnij się, że twój kierownik jest świadomy sytuacji. Jeśli nie masz pewności, jak skontaktować się ze swoim menedżerem, spróbuj poprosić o radę: „Mike, próbowałem porozmawiać z Larrym, ale po prostu się nie udało. Nalega na X, Y i Z, i reszta z nas spędza dużo niepotrzebnego czasu na rozwiązywaniu problemów, które stwarza. Czy możesz mi dać jakieś wskazówki, jak radzić sobie z tym facetem? ”

4. Zignoruj ​​go. Dlaczego ktoś w zespole słucha tego faceta? Czy ma on faktyczną władzę nad projektem? Kogo to obchodzi, jeśli zadeklaruje politykę jednego zatwierdzenia na programistę, jeśli nie jest w stanie jej egzekwować? Pozwól mu myśleć, że jest Żółwiem Yertle, jeśli dzięki temu poczuje się lepiej, po prostu nie pozwól mu stworzyć dla ciebie prawdziwych problemów.

Spraw, by facet został zwolniony i skończył z przeciąganiem pięty i oczywistą skażeniem w kierunku nowszej technologii. Albo naprawdę oszaleją i zacznij używać GIT. Jeśli nie rozumie SVn, na pewno zostanie zdmuchnięty przez GIT.

Wygląda na to, że walczysz o przegraną bitwę, ale możesz się przebić. Machiavelli w Książę opisał, jak trudno jest zmienić status quo. Sugerowałbym ponowne przeczytanie tego rozdziału, a potem może nie robienie tego, co on sugeruje - może być trudne.

Powinieneś zgłosić swoje obawy prywatnemu programistowi i upewnić się, że konstruktywnie krytykujesz sposób, w jaki rzeczy są wykonywane, a nie on ani inni programiści. Następnie zaoferuj, aby porozmawiać i napisać przewodnik po najlepszych praktykach. Pokaż, jak lepsze zrozumienie SVN ułatwi ich życie. Ostatecznie chodzi przede wszystkim o koszty i wydajność. Jeśli możesz udowodnić, że twoja droga poprawia sytuację bez stawiania czoła, możesz wygrać ten.

Spróbuj zrozumieć, dlaczego starsi faceci używają repozytorium w jego obecnym kształcie. Jakie są ich obawy? Co starają się osiągnąć? Jak możesz pomóc im zwiększyć produktywność? Przede wszystkim staraj się zachować spokojne i profesjonalne podejście. Sfrustrowanie jest łatwe. Bądź asertywny: Asertywność w pracy: Praktyczny przewodnik radzenia sobie z niezręcznymi sytuacjami autorstwa Kena Backa i Kate Back to dobra lektura. Na koniec pomyśl „jak przekonałbym się do zmiany?”. Bądź uczciwym adwokatem diabła, a to może pomóc ci znaleźć dobre odpowiedzi i pytania.

Na marginesie, ostrożnie wykorzystam humor. Może to zdziałać cuda lub sprawić, że zabrzmisz jak dupek. Tak więc unikałbym tego.

Zasadniczo starannie wybieraj swoje bitwy, ponieważ możesz nie wygrać tej. W takim przypadku albo nie przejmuj się, albo poszukaj innej pracy. Trudne, wiem.

Kiedyś byłem na odwrocie twojego stanowiska około 8 lat temu, kiedy SVN była dość nową technologią. Byłem starszym programistą i zostałem poproszony / poproszony o zainstalowanie SVN przez młodszego programistę (w rzeczywistości był on dokładniejszym wsparciem IT niż programista). Mimo początkowych podejrzeń co do zwiększonego obciążenia pracą, niepotrzebnej złożoności itp. Wziąłem otwarty umysł, a potem stałem się jej wielkim fanem.

Moim zdaniem, z tego, co opisałeś, problem zdecydowanie sprowadza się do osobowości zespołu - jego upór okazuje się przeszkodą dla całego zespołu w tej kwestii. Lepiej jest po prostu wycofać się w tym momencie i pozwolić naturalnej presji reszty drużyny na wymuszenie ręki.

Jest to w zasadzie przypadek „braku autorytetu” i osoby, która stosuje moc własnego strachu, aby utrzymać wszystko „pod kontrolą”

Aby rozwiązać ten problem, znajdź kogoś, kto zainspirował twojego członka drużyny lub kogoś, kogo szanuje i który jest w stanie wyjaśnić, jak pilne jest użycie czegoś takiego jak SVN. W ten sposób jego strach przed zmianą i po prostu „utratą autorytetu” nie jest w grze, ponieważ nie jest członkiem zespołu, który mówi mu, co ma robić. Powstrzymałbym się od używania kogoś takiego jak menedżer do rozmowy z tym facetem, ponieważ to tylko zwiększa presję, a może nawet stwarza dla ciebie bardziej stresującą sytuację.

Niedawno przeczytałem Driving Technical Change: Dlaczego ludzie w twoim zespole nie postępują zgodnie z dobrymi pomysłami i jak przekonać ich, że powinni , opublikowanym przez The Pragmatic Programmers. Ta książka stanowi tło, które powinieneś znać przed próbą wprowadzenia zmian technicznych, szereg wzorców u ludzi, którzy sprzeciwiają się zmianom lub odmawiają ich wprowadzenia, techniki wdrażania zmian, a następnie strategie maksymalizacji wykorzystania tych technik i wszystkich osób w pobliżu ty.

Opierając się na twoim poście, powiedziałbym, że twój kolega z zespołu prawdopodobnie wpada w wzór niedoinformowany lub cyniczny, ale może być również przypadkiem Irracjonalnego. Niektóre z technik zalecanych w celu zwalczania tego rodzaju ludzi to zdobycie doświadczenia w środowisku docelowym, aby można było znaleźć wszelkie problemy i przedstawić odpowiedzi na problemy, na które napotkają inni ludzie, zanim się pojawią, rozwiązać odpowiedni problem, przekazać wiadomość z pasją, ale bez nadmiernej gorliwości, zademonstruj techniki, wyraźnie pokazując zalety swoich metod i narzędzi i sprzedaj je organicznie (ale nie stwarzaj problemów tylko po to, aby je rozwiązać), a także zyskuj rozgłos i kupuj od reszty swojego zespołu. Jeśli jednak jest irracjonalny,

Wreszcie, kiedy zaczniesz używać tych technik, potrzebujesz ogólnej strategii. Ważne jest, aby ci, którzy są wrogo nastawieni lub irracjonalni, nie spowalniali cię - ignoruj ​​ich. Zamiast tego znajdź osoby, które możesz wykazać i przekonać, że masz lepszy sposób, i zastosuj odpowiednie techniki oparte na nich osobno. Gdy więcej osób zobaczy ulepszenia, które oferuje twoja wiedza, wykorzystaj je, by nadal przekonywać innych. Na koniec wykorzystaj ten oddolny wysiłek, aby przekonać kierownictwo, że istnieje lepszy sposób, ale pamiętaj, aby ująć to w sposób zrozumiały (czas, pieniądze, jakość).

Nie próbuj „przekonywać” tego faceta do niczego. Ludzie (nawet programiści) nie będą odpowiadać ani szanować rozsądnych / logicznych argumentów kogoś, kogo uważają za młodszego. Więc nie marnuj oddechu. Zamiast tego pracuj nad budowaniem poziomu zaufania z tą osobą. Ta osoba będzie słuchać tego, co masz do powiedzenia, tylko wtedy, gdy będzie na to otwarty.

W międzyczasie masz prawdziwe problemy:

1. Facet sprawdza plik .project w repozytorium: po prostu zignoruj ​​go. nie musisz modyfikować pliku, podobnie jak nikt w zespole, który wie lepiej. Odpuść sobie. Jeśli daje to Twojemu „starszemu członkowi” ciepłe, szczęśliwe uczucie jak koc bezpieczeństwa, niech tak będzie.
2. Widoczny jest budżet na miejsce na dysku: z tego powodu Pan Senior dyktuje 1 zatwierdzenie dziennie. Czy niedobór przestrzeni jest rzeczywisty czy postrzegany? Nawet jeśli jest to po prostu postrzegane, być może możesz coś zrobić, aby zmienić to postrzeganie. Należy się tym zająć natychmiast - jeśli przejmiesz inicjatywę, pomoże to również zbudować zaufanie.

Mogę też dodać, że ten facet będzie chętny do przyjęcia lepszych praktyk SVN, gdy będzie myślał, że to były jego pomysły. Będzie to wymagało pewnej dogłębnej refleksji z twojej strony i prawdopodobnie odniesie on uznanie za ustanowienie lepszych praktyk - ale nie masz nic przeciwko.