Radzenie sobie z nieelastycznymi programistami

Czasami programiści, którzy pracują nad projektem od dłuższego czasu, stają się nieelastyczni i trudno jest z nimi uzasadnić. Nawet jeśli uda nam się ich przekonać, może nie być prawdopodobne, aby zastosowali nasze sugestie.

Na przykład niedawno dołączyłem do projektu, w którym proces kompilacji i wydania jest zbyt skomplikowany i zawiera niepotrzebne przeszkody.

Zasugerowałem, abyśmy pozbyli się części narzutów związanych z programowaniem (takich jak wypełnienie kilku arkuszy kalkulacyjnych) tylko poprzez zintegrowanie narzędzi do zarządzania defektami i kontroli wersji (oba są narzędziami IBM-Rational, więc integracja może być bardzo łatwym jednorazowym wysiłkiem). Ponadto, jeśli użyjemy narzędzi takich jak Maven & Ant (projekt obejmuje Javę i niektóre produkty COTS), kompilację i wydanie można uprościć, co powinno ograniczyć ręczne błędy i interwencje.

Udało mi się przekonać innych i jestem gotów podjąć wysiłek opracowania dowodu koncepcji. Ale „starszy” programista nie chce, być może dlatego, że obecny proces czyni go bardziej wartościowym.

Jak poradzić sobie z tą sytuacją bez rozwijania tarcia w zespole?

Jesteś nowym członkiem zespołu i chcesz zmienić niektóre podstawowe aspekty działania zespołu. Powodzenia, wyczuwam szczęśliwy zespół w twojej przyszłości.

Ok, kilka praktycznych porad:

Udowodnij się zespołowi. Musisz to zrobić z technicznego i niezawodnego punktu widzenia. Jeśli chcesz, aby ludzie cię śledzili, musisz podać im powód.

Poznaj historię metodologii. Dlaczego to istnieje? Jaki problem wtedy rozwiązywał? Upewnij się, że twoje rozwiązanie jest naprawdę korzystne dla zespołu. Być może twoje zmiany są lepsze, ale mogą nie rozwiązać problemu, który ma zespół.

Poznaj swoje przeszkody. Znajdź powody ich odporności i pracuj nad tymi przedmiotami.

Jeśli chcesz być agentem zmian, dowiedz się, jak odnieść sukces jako agent zmian . Dziesiątki dostępnych książek i innych źródeł dostarczają znacznie więcej informacji niż tutaj.

I tak, życzę powodzenia. Ale proszę, ze względu na twoje szczęście i szczęście twojego zespołu, bądź mądry. Twoje pragnienie zmiany procesu bez inwestowania energii w tworzenie właściwej ścieżki może przynieść znacznie więcej szkody niż pożytku.

Byłem w pozycji, o której wspomniałeś. Spędziłem lata jako programista Java i ostatecznie podjąłem pracę, w której wszyscy używali Smalltalk. Moją pierwszą reakcją było „OMG, używają tej przestarzałej technologii” i zacząłem próbować rozwiązywać specyficzne problemy Smalltalk z rozwiązaniami Java. Mogę sobie tylko wyobrazić, jak bolał mnie głowa innych programistów, którzy nienawidzili Javy z pasją.

Dopiero, gdy dostałem średni projekt do pracy, podczas gdy pod kierunkiem dwóch starszych programistów w ciągu kilku miesięcy zacząłem rozumieć język Smalltalk i nauczyć się go lubić. Od czasu odejścia z tej pracy i powrotu do programowania Java, czuję się bardziej elastyczny, ponieważ mogę podjąć projekt i wdrożyć go w dowolnym języku używanym przez firmę. Najważniejsze, aby ci ludzie zrozumieli, że język to nic innego jak medium. Poświęciłem też czas na naukę siebie Lisp i Erlang, ale to może nie działać u wszystkich.

Jako strategię budowania zespołu polecam osobom, z którymi masz problemy, siedem języków w siedmiu tygodniach .

Myślę, że sprowadza się to również do tego, ile czasu ci ludzie są skłonni zainwestować w zwiększenie elastyczności. Problem z większością uniwersytetów (przynajmniej tych, które widziałem) polega na tym, że są one stronnicze w stosunku do określonego języka, a jego studenci stają się „zinstytucjonalizowani”, jak wspomniałeś. Myślę, że częścią twojej strategii powinno być kultywowanie elastyczności w swoim zespole. Można to uzupełnić opracowaniem opartym na domenach .

(1) Modeluj domenę (Prostą) (2) Zaimplementuj ją, używając dwóch różnych języków (tj. Java i Lisp)

Ponownie, przy założeniu, że są oni zmotywowani do zrobienia powyższego i są gotowi poświęcić swój czas, aby to osiągnąć.

Mam nadzieję że to pomoże

Mógłbym tu być całkowicie niewłaściwy, ale wydaje mi się, że te same problemy są powszechne na szerszą skalę i dotyczą ludzkiego konserwatyzmu. Ludzie często odmawiają zmiany znanych wzorców zachowań z powodów, które są zbyt liczne, by je wymienić.

Będąc rosyjskim deweloperem (i dlatego widząc mniej racjonalnego zachodniego pragmatyzmu), widzę praktyczne rozumowanie jako o wiele mniej przekonujące niż próba chodzenia w czyichś butach.

Innymi słowy, wspomniałeś, że starszy programista ceni sobie własne stanowisko związane z bieżącym schematem pracy. Być może powinieneś go przekonać, że nowy sposób robienia rzeczy sprawi, że jego pozycja będzie jeszcze bardziej cenna i istnieje wiele sposobów, aby to zrobić. Na przykład możesz poprosić go, aby faktycznie wypowiedział twój pomysł i zdobył uznanie, lub możesz znaleźć konkretne miejsce w procesie, który może kontrolować wyłącznie itp.

Wierzę, że elastyczność poza pozornymi zaletami twojego pomysłu może być twoim magicznym zaklęciem tutaj.

Udało mi się przekonać innych i jestem gotów podjąć wysiłek opracowania dowodu koncepcji. Ale „starszy” programista nie chce, być może dlatego, że obecny proces czyni go bardziej wartościowym.

Zamiast rzucać wścibstwa na postać starszego programisty (zły ruch), być może powinieneś spróbować zrozumieć, dlaczego nie jest entuzjastyczny:

• Może myśli, że jesteś jedną z tych osób, które przeceniają swoje pomysły. Może wątpi w to, że możesz je dostarczyć.

• Może myśli, że przesadzasz z problemami. (Nie mogą być aż tak źli ...)

• Może myśli, że nie do końca rozumiesz ryzyko techniczne.

• Może myśli (wie), że są teraz ważniejsze rzeczy do zrobienia.

• Może po prostu pocierasz go w niewłaściwy sposób.

Moja rada byłaby dla niego udowodnieniem. Na przykład realizując projekty, które faktycznie otrzymałeś. Kiedy bardziej ufa twojej zdolności i osądowi, powróć do tego problemu.

Jeśli chcesz teraz realizować linię „usprawnienia procesu”, radzę robić to powoli, małymi krokami.

Należy pamiętać, że niewątpliwie istnieje ryzyko, że proponowane zmiany będą miały ogromny wpływ na produktywność grupy, a nawet na zdolność do utrzymania istniejącego oprogramowania. Jeśli tak się stanie, osoba odpowiedzialna prawdopodobnie uzyska najwięcej obrażeń od kierownictwa wyższego szczebla.

Zinstytucjonalizowany o czym konkretnie? Technologie, wzorce, praktyki?

Jeśli są w organizacji / projekcie od dłuższego czasu, są szanse, że są starszymi programistami i mają odpowiedzialność / doświadczenie, aby wykonywać te połączenia, i mieli doświadczenie w projekcie, a nie tylko warunkowane jak eksperyment z 5 małpami .

Rozwiązanie ich przekonujących zależeć będzie od tego, jaki jest temat, ponieważ jeśli wzór / technologia jest już wybrana, będzie dobry powód i będzie musiał być lepszy powód do zmiany, aby uzasadnić rzucenie pracy i zapoznanie się itp. ., jeśli tak, rozwiązaniem jest zorganizowanie spotkania przez architekta / starszego programistę w celu demokratycznego wyboru najlepszego rozwiązania.

Jeśli zespół naprawdę MASUJE niepotrzebne blokady dróg, to prawdopodobnie będzie bardzo szczęśliwy, że pomożesz im je naprawić. Zauważ jednak, że może istnieć bardzo dobry powód, dla którego tam są, i będziesz wyglądać głupio, jeśli będziesz musiał powiedzieć „och, cóż, mój fantastyczny pomysł nie działa wtedy” po tym, jak sprzedał go wszystkim przez długi czas.

Najpierw zbadaj, a następnie wystąp. Zauważ też, że możliwość POKAŻENIA, w jaki sposób sugerujesz poprawę, jest znacznie lepsza niż falowanie ręczne.

Skłaniam się do stwierdzenia, że ​​to ty jesteś „nieelastycznym programistą”. Jesteś nowy w tym projekcie, ale nalegasz, aby Twój pomysł był najlepszy, a facet, który prowadzi projekt, który był ich dłużej i wie, że system wewnątrz i na zewnątrz jest tuż za nim.

Jestem dość doświadczony i bardzo dobrze oceniany i często przydzielam się do naprawy trudnych projektów jako członek zespołu tygrysów. Nawet wtedy wciąż poświęcam czas na naukę howsa, dlaczego, dynamiki zespołu, projektu i ich praktyk, a nie szalonego wchodzenia i mówienia im, jak to jest złe. W rzeczywistości nigdy nie mówię, że to, co robią, jest złe, ponieważ nie otrzymuję pożądanej odpowiedzi, a zazwyczaj to, co robią, nie jest złe, po prostu wymaga drobnych poprawek.

Każdy projekt jest wyjątkowy. Każda drużyna jest wyjątkowa. Twoje rozwiązanie może być lepsze dla Ciebie i programistów, ale może nie być lepsze dla lidera, klienta, firmy lub projektu, ale ponieważ nie masz doświadczenia z projektem, aby wiedzieć lepiej, nie wiedziałbyś odpowiedź na to.

Najlepszym sposobem, aby zachęcić ludzi do robienia tego, co chcesz, jest przekonanie ich, że wszystko jest ich pomysłem. Zamiast bezpośrednio sugerować, przedstaw opcje. Jeśli twoje pomysły są wyraźnie lepsze niż alternatywy, daj starszemu deweloperowi możliwość ich wybrania i uczynienia ich własnymi. Nie martw się o uzyskanie kredytu. Ludzie, którzy mają znaczenie, będą wiedzieć, co się dzieje.