Co można zrobić, gdy „dawanie przykładu” nie działa? [Zamknięte]

Od prawie 2 lat pracuję w dużej firmie (ponad 8000 pracowników) i zostałem zatrudniony zaraz po ukończeniu studiów.

Każdy tutaj musi codziennie radzić sobie ze starszym kodem, który często jest bardzo źle zaprojektowany i pełen hacków. Na początku utrzymywałem niski profil, starając się nie krytykować zbyt wiele rzeczy. Jednak obecna sytuacja stała się bardzo trudna i wydaje się, że nikt nie chce ulepszać / wymieniać narzędzi, których używamy.

Aby być bardziej precyzyjnym, mamy:

• Przestarzałe narzędzie kontroli źródła (Visual SourceSafe)
• Zwykłe stare pliki makefile, które obsługują tylko pełną odbudowę
• .def pliki, które muszą być obsługiwane ręcznie i osobno dla wszystkich istniejących architektur
• monolityczne pliki nagłówków i projekty z bardzo małą liczbą różnych plików (ale każdy zawiera około 3000 linii kodu, co czasem zajmuje się bardzo różnymi zadaniami)
• brak korzystania z „nowych” języków (cóż, std::stringnie jest tak nowy, ale nikt oprócz mnie z niego nie korzysta)

Kilka miesięcy temu postanowiłem coś z tym zrobić, projektując nowe środowisko kompilacji. Mogłem uzyskać przyrostowe kompilacje do niezawodnej pracy, szybsze czasy kompilacji, lepiej ustrukturyzowane projekty, automatyczne .defgenerowanie plików. Utworzyłem nawet mostek z / do Git do / z Visual SourceSafe.

Pokazałem swoje osiągnięcia kilku kolegom i naszemu szefowi, ale było tak, jakby nikogo to nie obchodziło. Wszyscy mówili: „Cóż… ludzie są przyzwyczajeni do robienia tego w ten sposób. Dlaczego mielibyśmy to zmieniać?”

Zmiany, które zasugerowałem, zostały zaprojektowane tak, aby umożliwić łagodne przejście ze starego systemu do nowego. Każde ulepszenie można zastosować osobno i bezpiecznie.

Próbowałem nawet zaangażować niektórych moich współpracowników w zmiany. Ale jak dotąd brak sukcesu.

Czy miałeś już podobną sytuację? Co można zrobić, gdy „dawanie przykładu” nie działa?

Celuj w głowę : „Dawaj dobry przykład” powinno mieć na uwadze poprawę, ale powinno być skierowane do ludzi, a nie do technologii. Być może poświęciłeś zbyt dużo czasu na doskonalenie technologii, ale za mało czasu na to, co dzieje się w ich głowach. Pomyśl o czynnikach napędzających, dlaczego istnieje sprzeciw wobec nowych rzeczy. W wielu przypadkach obawiają się po prostu ryzyka. Zidentyfikuj te zagrożenia i znajdź dla nich kontrargumenty.

Złap świeże mięso : łatwiej jest pozyskać pracowników, którzy chcą coś zmienić. Zauważysz je natychmiast, gdy je zobaczysz.

Unikaj zgniłego mięsa : niektórzy nigdy nie zrozumieją twoich pomysłów. Zostaw je na boku.

Dorastaj do masy krytycznej : znajdź ludzi, którzy sympatyzują z Twoimi pomysłami. Wygraj jeden po drugim. W pewnym momencie, gdy zostanie osiągnięta masa krytyczna, coraz więcej osób dobrowolnie pójdzie za twoim przykładem.

Słownictwo związane z zarządzaniem : Menedżerowie nie są zainteresowani lepszymi projektami. Ich językiem są pieniądze i czas. Wyjaśnij, ile roboczogodzin marnuje się na błędy. Wyjaśnij, że niezadowoleni klienci napotykający błędy nie są opłacalni. Zademonstruj, o ile szybciej możesz wdrożyć nową funkcję. Musisz wybrać inne słownictwo dla menedżerów.

Chodzi przede wszystkim o procesy : lepsze technologie nie tworzą lepszych programistów i programów. Jeśli masz dobrze działające procesy, nawet przestarzałe technologie prowadzą do dobrych wyników. Pomyśl o wysiłku i marnowaniu czasu. Może to nie jest technologia, ale coś w tych procesach idzie strasznie nie tak. W większości przypadków jest to brak komunikacji.

Znajdź nową firmę : już wiele zrobiłeś. Nadal możesz próbować ulepszać, ale to Ty decydujesz, jak długo chcesz spróbować i ile energii chcesz zainwestować. Pamiętaj: nawet jeśli nie możesz wiele ulepszyć, wiele się nauczysz ze swoich wysiłków. W pewnym momencie musisz przejść dalej.

Czy kiedykolwiek przestałeś myśleć, że możesz się mylić?

Więc czytasz w szkole kilka wzorów i wzorów i nie jesteś pozbawiony praw, które wydają się być stosunkowo przestarzałymi praktykami w miejscu pracy. Bez wątpienia są to prawdopodobnie lepsze pomysły i nowe projekty powinny zaczynać z myślą o nich, ale wygląda na to, że jesteś na zupełnie innym poziomie.

Twórcy Herding są jak stada kotów, z natury mają własny umysł i preferują sposób robienia rzeczy, czy to dobrze, czy nie. Mam dość czasu na egzekwowanie najlepszych praktyk i zarządzanie zespołem 2 programistów, ale pracujesz dla firmy, która ma 8000.

To zadziwiająco duża liczba. Nawet prosta zmiana procesu, w której stwierdza się, że wszyscy programiści muszą planować spotkania i czas nieobecności w kalendarzu publicznym, staje się niezwykle złożoną i trudną polityką do wdrożenia we wszystkich obszarach. Wymagałoby to również znacznego nacisku ze strony kierownictwa, aby upewnić się, że polityka została zaakceptowana i przyjęta we wszystkich obszarach.

Możesz tego nie myśleć, ale coś tak prostego, jak przejście z monolitycznego do wielu plików nagłówkowych lub przeniesienie kontroli wersji z SourceSafe na Git wymaga ogromnego wysiłku i inwestycji ze strony wszystkich zaangażowanych. Wymagałoby to:

• Znaczące wsparcie zarządzania

• Akceptacja w całej firmie

• Inwestycja godzin spotkań dla wszystkich programistów w celu poinformowania ich o nowych inicjatywach (Spotkania kosztują roboczogodziny, roboczogodziny kosztują pieniądze)

• Szkolenie należy zaplanować i ustalić, aby nawet najgłupsi programiści wiedzieli, co robią

• Nawet przy założeniu godziny szkolenia dla 8000 programistów x 50 € / godz. = 400000 € koszt szkolenia. To więcej pieniędzy niż mój jeden zespół zajmujący się tworzeniem oprogramowania przez cały rok budżetuje na wynagrodzenie, oprogramowanie i sprzęt. To wyjątkowa inwestycja, którą proponujesz.

Ale mówisz: „Pomyśl o tym, ile czasu można by zaoszczędzić dzięki wzrostowi wydajności”. Słusznie, ale znaczna inwestycja wiąże się ze znacznym ryzykiem, więc niech mnie szlag, że masz rację co do tego, zanim się na to zdecyduję. Jeśli żaden ze starszych ludzi cię nie popiera, nie mogę uzasadnić kosztów. Ostatecznie możemy być nieefektywni, ale jesteśmy konsekwentni i przy 8000 programistów w całej firmie, spójność jest najważniejsza.

Aby to zrobić, musisz wypisać się z wielu osób na wyższym szczeblu, a także dokładnie i obiektywnie znaleźć sposób na zmierzenie utraconego czasu programisty na nieefektywność. Czas ten równa się dolarom i tylko dolary, a polityka pomoże ci wygrać tę bitwę.

To, co opisałeś, nie brzmi dla mnie jak „dawaj przykład”, wygląda na to, że złożyłeś propozycję i zostałeś odrzucony. Aby dać przykład, musisz pokazać ludziom, że twoja droga jest lepsza. Spośród wymienionych przez ciebie problemów widzę trzy, że możesz sam zacząć korzystać z własnych zmian.

Zwykłe stare pliki makefile, które obsługują tylko pełną odbudowę.

Utwórz lokalnie własne pliki makefile i pokaż, o ile bardziej wydajnie możesz z nimi pracować.

monolityczne pliki nagłówków i projekty z bardzo małą liczbą różnych plików (ale każdy zawiera około 3000 linii kodu, co czasem zajmuje się bardzo różnymi zadaniami)

Rozbij istniejące, gdy ich dotkniesz (bez przerywania kompilacji) lub wprowadź mniejsze pliki nagłówkowe podczas pisania nowego kodu. Gdy ludzie zaczną z nimi pracować, zdają sobie sprawę, że nie potrzebują duplikacji.

brak korzystania z udogodnień „nowych” języków (well std :: string nie jest tak nowy, ale nikt oprócz mnie go nie używa)

Kontynuuj wprowadzanie nowych funkcji językowych za każdym razem, gdy dotkniesz starego kodu lub wprowadzisz nowy kod. Upewnij się, że upraszczasz rzeczy. Nie zniechęcaj się tym. Większość z nas jest leniwa. Jeśli zobaczymy, że nowa funkcja językowa ułatwia sprawę, zastosujemy ją.

Po kilku miesiącach, jeśli inni programiści zaczną wprowadzać ulepszenia, możesz ponownie zwrócić się do szefa o bardziej radykalne zmiany, takie jak uaktualnienie systemu kontroli źródła. Musisz jednak upewnić się, że inni programiści dostrzegą korzyści, w przeciwnym razie nigdy nie przejdą. Jednym ze sposobów podejścia może być zasugerowanie wypróbowania Git w małym projekcie, w którym działa tylko kilku programistów. W ten sposób możesz promować go jako ocenę, a nie przejście na pełną skalę do nieznanego systemu.

Wreszcie, jeśli po kilku miesiącach prób nikt nie wydaje się zainteresowany poprawą sposobu wykonywania zadań w firmie, musisz naprawdę zastanowić się, czy jest to dla Ciebie odpowiednie.

Oprócz Lionela Barreta (który w większości się zgadzam), rozważ także możliwą motywację do oporu.

• Oceń koszt rzeczywistego procesu
• Oceń koszt procesu, ponieważ będzie on podobny do twojego

Ale również:

• Oceń koszt zmiany terminu
  • Pieniądze do wydania na stworzenie nowego środowiska dla każdego
  • Czas na szkolenie wszystkich, aby przyzwyczaili się do nowego trybu (może to być dla ciebie łatwe, ale nie takie łatwe dla osób, które nie są świadome tego, co robisz)
  • Upłynął czas potrzebny na zarządzanie zmianą w sposób niezakłócający pracy.

Mam podejrzanego: ilu jest w twoim towarzystwie ludzi takich jak ty pod względem wieku i kultury (ja „szkoła” i „typ szkoły”)? Ile osób, takich jak Ty, zostanie zatrudnionych w ciągu najbliższych 2/3 lat i ilu z nich przejdzie na emeryturę lub zmieni swoją rolę w organizacji?

Podejrzewam, że jesteś w sytuacji, w której nie masz wystarczającej siły, aby zmienić firmę. W takiej sytuacji albo firma cię zmieni, albo „wydali” (w tym sensie, że stanie się to twoją wolą odejścia), jeśli nie będziesz w stanie czekać dłużej.

Ale być może firma ocenia, że ​​dodatkowe koszty, o których ci mówiłem, można zaoszczędzić, umożliwiając spontaniczny proces zmiany, czekając na naturalne zastąpienie ludzi. Jesteś dopiero na początku procesu, którego nie możesz zobaczyć, ponieważ nie ma (jeszcze) nic za sobą.

W tym momencie mogę jedynie dodać odniesienie do artykułu Joela Pierwsze rzeczy zrobione, gdy jesteś tylko chrząkiem . Sekcje obejmują:

Strategia 1 Po prostu zrób to

Strategia 2 Wykorzystaj moc marketingu wirusowego

Strategia 3 Stwórz kieszeń doskonałości

Strategia 4 Zneutralizuj Bozo

Strategia 5 Odejdź od przerw

Strategia 6 Zostań bezcennym

Podsumowałbym ten artykuł jako „Zmiana musi zaczynać się od ciebie”.

Niestety ludzie utknęli w rutynie i rozwijali mentalność, że „to działa, wszyscy używają tego dobrze, po co to zmieniać” I robi się irytujące.

Postąpiłeś właściwie, nie tylko narzekając, ale opracowując praktyczne rozwiązanie zastępcze, teraz potrzebujesz tylko wpisowego.

Pokaż swojemu bezpośredniemu przełożonemu (lub przewodowi technicznemu). Jeśli nie są zainteresowani, czy masz kogoś odpowiedzialnego za kontrolę zmian lub innowacje?

Potencjalnie jednak twoje pomysły i prace mogą zostać zignorowane, a sytuacja pozostanie niezmieniona.

Musisz przedstawić swoją sprawę w taki sposób, aby twój szef był po twojej stronie. BTW, Ten rodzaj zmiany jest proponowany przez dyrektora technicznego lub kierownika projektu, więc musisz zaangażować się w projekt. (Alternatywnie możesz zaproponować audyt techniczny, osoba postronna może powiedzieć to samo, co Ty, ale będzie miała większą wagę).

Jak dotąd nie widzi potrzeby zmiany, wygląda na to, że zmieniają się w nim kosmetyki: Kosztowne bez oczywistych korzyści, poza zaspokojeniem fantazji twórcy. Ważne są dla niego tylko dwie rzeczy: przepływ pieniędzy i stabilny zespół. Technologia to czarna skrzynka, jeśli działa, to wystarczy.

Po pierwsze pieniądze, musisz udowodnić, że obecna konfiguracja kosztuje go pieniądze. Jaki koszt / godzina pracy programisty i ile godzin szybszych czasów kompilacji by go uratowało? Zrobić matematykę. Ponadto, skompiluj artykuły lub zeznania na temat ryzyka związanego z bieżącym potokiem kodu i pokaż mu przerażające liczby: „z powodu praktyk SourceSafe / Bad Coding nasza firma straciła XXXK $”.

Po drugie, twój szef może utknąć w starych, zrzędliwych programistach, którzy nie chcą zmieniać swoich zachowań. Jeśli pierwszy punkt zostanie ustalony, musisz również zaproponować rozwiązanie tego problemu. Ile masz Ciekawe może być podkreślenie, że trudno będzie kogoś zastąpić, ponieważ obecny potok kodowania jest dziwaczny. Musisz zaproponować plan aktualizacji zespołu. Naucz się najlepszych praktyk branżowych i sprawdź, czy przestrzegają nowych zasad.

Wreszcie, musisz zaproponować plan zmiany bazy kodu, podzielonej na małe projekty, z kamieniami milowymi i alokacją zasobów. W rzeczywistości sprzedajesz się jako kierownik projektu, a zmiany są obowiązkowe, aby mieć solidny potok kodu.

Czy pracujesz w organizacji, która uważa, że ​​robienie rzeczy dobrze, wydajność i innowacje prowadzą do sukcesu i rentowności; czy że dążenie do przychodów i koncentracja na utrzymaniu sprzedaży to najemcy sukcesu?

Firmy, które zachowują się tak, jak opisujesz, są technologicznie zakorzenione. Na konkurencyjnym rynku nie byliby w stanie konkurować z firmą skoncentrowaną na jednostkach i innowacjach.

Jeśli jesteś osobą, o której mówisz, że pracujesz, to pracuj w miejscu, które szanuje i nagradza twojego ducha. W końcu po latach osiedlania się zaczniecie iść na kompromis w kierunku tej samej filozofii, którą wyznają przełożeni. Idź do pracy gdzie indziej (prawdopodobnie mniejszej organizacji), która ceni ciężką pracę, inspirację, kreatywność i postęp.

Jeśli nie podejmiesz ryzyka i zrobisz to wkrótce, w końcu się osiedlisz i nie będziesz w stanie nadal karmić swojej ciekawości i kreatywności, ponieważ jest to filozoficznie przeciwne w obecnej grupie rówieśniczej.

Doskonałość to postawa i światopogląd.

Po prostu wiedz, że to doświadczenie dało ci wgląd w to, czego należy unikać, uważnie obserwuj samozadowolenie i protekcjonizm, abyś mógł je wcześnie wykryć.

W następnym wywiadzie zadaj pytania takie jak: „Jakie innowacje pochodzą od Twoich pracowników”, „Jakie zmiany przyniosły indywidualna kreatywność?”, „Jakie indywidualne talenty mogę wnieść do tego zespołu?”, „Co napędza sukces organizacji ? ”,„ W jaki sposób Twoja organizacja nieustannie stosuje innowacje technologiczne? ”... Odpowiedzi na takie pytania są niezwykle wymowne. Wiele organizacji nie ma wizji lub te, które ją stworzyły, zniknęły, a organizacją zarządzają księgowi. Jeśli przeprowadzasz wywiad z Dyrektorem Technologicznym - zapytaj go, czy postrzega tę organizację jako firmę technologiczną.

Jeśli nie podoba ci się środowisko, w którym pracujesz, wyrządzasz sobie krzywdę. Musisz być otoczony ludźmi, którzy mają podobne zainteresowania i cele jak ty zawodowo. Wiem, że czasem łatwiej to powiedzieć, niż zrobić, ale uczucie spoglądania wstecz na kilka lat i poczucie, że zmarnowałeś swój czas, jest gorsze niż strach przed podjęciem ryzyka.

Alternatywnie, jeśli chcesz rozwijać się w systemie lub środowisku wykorzystującym określone technologie i / lub metodologie, proponuję znaleźć projekt poza pracą, do którego możesz się przyłączyć. Przynajmniej różnorodność pracy na obu systemach zaspokoi potrzebę czegoś innego, podczas gdy ty znajdziesz swoje miejsce.

Wydaje mi się, że jesteś rybą z wody. Znajdź swoje ciało oceanu i płyń!