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

40

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?

ereOn
źródło
10
„Kilka miesięcy temu postanowiłem coś z tym zrobić”… „Pokazałem wynik mojemu szefowi”. Wygląda na to, że źle pomyliłeś zamówienie.
3
@ ThorbjørnRavnAndersen: Nie wiem, jak to zrobić: jak mam pokazać coś, czego jeszcze nie zrobiłem? A może miałeś na myśli, że powinienem był zapytać, zanim to zrobisz?
ereOn
21
Byłem tam i IMO, musisz się stamtąd wydostać, ponieważ, jak mówi przysłowie: „idiota zawsze będzie cię bił - najpierw ogłuszy cię do swojego poziomu, a następnie pobije swoim doświadczeniem „. Jeśli ludzie nie rozpoznają potrzeby aktualizacji, oznacza to profesjonalną stagnację, a stagnacja w naszej dziedzinie to śmierć. Możesz umieścić rzeczy, które zrobiłeś w swoim CV, a jeśli jesteś dobry, prawdopodobnie dostaniesz dobrą pracę w ciągu miesiąca.
TC1
8
Święta krowa, 8000 programistów? Dla kogo pracujesz, Facebook? Google? Microsoft?
Kyralessa
5
@ Kyralessa: nie sądzę, aby Facebook lub Google korzystali z VSS.
Jake Berger,

Odpowiedzi:

46

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.

Theo Lenndorff
źródło
3
Podobne do „rozwijać masę krytyczną”: youtube.com/watch?v=V74AxCqOTvg
back2dos
2
@Farmor, jeśli nie możesz ich przekonać bez powiedzenia „idź przeczytać stronę internetową”, być może to Ty musisz odświeżyć umiejętności komunikacyjne.
1
Mam na myśli, jeśli są uparci i nie słuchają młodych. Możesz to zrobić, odwołując się do dokumentacji. Na przykład, jeśli powiedzą, że twoje punkty są niepoprawne i prawie wszyscy eksperci od wersjonowania napiszą twoją opinię, będą zmuszeni ją przesłać. I lubię droczyć się z arogantem, na przykład jeśli lubią Torvaldsa, możesz powiedzieć, że Torvals mówi „Jeśli lubisz SVN, jesteś głupi i brzydki”, tak jak to zrobił w swoim mowie Google. Nie rozumiem, dlaczego powoływanie się na dokumentację, kiedy uparta osoba nie wierzy, że to coś złego. Możesz to zrobić nawet na telefonie i od razu je pokazać.
Farmor
6
-1 dla ageizmu. Czasami trzeba uważnie słuchać „eksperta od skamielin” i pozwolić sobie na odrobinę pokory. Dzięki zdobytej wiedzy uczyń swój pomysł jeszcze lepszym. Odsuwanie na bok innych tylko dlatego, że są starzy, jest pewnym sposobem na utratę cennego know-how i wsparcia wpływowych starszych programistów.
Doug T.
1
@Lundin: Menedżerowie powinni mieć wiedzę techniczną, ale im wyżej wspinasz się po drabinie, tym więcej pieniędzy i czasu stają się ważne. Nie ma w tym nic złego, ponieważ ktoś musi śledzić komercyjne aspekty firmy. Ważne jest, aby dać menedżerom odpowiednie argumenty w ich ręce, aby mogli uzasadnić swoje decyzje swoim kierownikom. Jako programista możesz zdobyć menedżera, jeśli podasz mu odpowiednie argumenty.
Theo Lenndorff
30

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

wałek klonowy
źródło
4
Dziękuję Ci. Szczerze mówiąc, na początku, kiedy przyjechałem, przez kilka tygodni byłem wszystkim: „Co do cholery, ci faceci nie mają pojęcia!” wtedy zdałem sobie sprawę, jak bardzo się myliłem w wielu kwestiach. Ale po dwóch latach jestem pewien, że niektóre procesy można ulepszyć i mogę rozwiązać wiele skarg, które usłyszałem. Rozumiem, że to także kwestia opinii, ale jeśli ktoś przyszedłby do mnie z dowodem, że robię coś nieefektywnego, przynajmniej posłuchałbym faceta, ponieważ wyświadcza mi przysługę. Mój dział składa się tylko z 40 osób i tylko my robimy tego rodzaju rozwój.
ereOn
1
Jestem pewien, że mogą się poprawić, ale tak jak powiedziałem, zmienianie moich zachowań i praktyk w celu poprawy jest inne niż szkolenie i zmuszanie 40 programistów do tego. Kierownik nietechniczny nie będzie cię słuchać bez ważnej politycznie osoby starszej popierającej ten pomysł.
wałek klonowy
To nie tylko „czy można lepiej zrobić?”. Zastąpienie repozytorium źródłowego to ogromna zmiana. przejście na ten system wiąże się z dużymi kosztami, między innymi z przekwalifikowaniem całego personelu. Istnieje ryzyko. Czy jesteś w 100% pewien, że stare repozytorium kodu źródłowego nie będzie miało możliwości, o których nie wiesz, a których nowe nie miałoby?
DJClayworth
@DJClayworth: repozytorium VSS jest używane tylko jako podstawowy system pamięci. Nikt nigdy nie patrzy na historię i zwykle usuwa wszystko przed ponownym skopiowaniem całego katalogu.
ereOn
1
@ereOn Pamiętaj, że pracujesz dla firmy, a firma zarabia pieniądze, a nie koduje. Chyba że nie jest to zysk. W każdym razie twoją główną wartością dla klientów prawdopodobnie nie jest „dostarczymy ci kod z najszybszymi kompilującymi makefile w branży”. Powinieneś ustalić, co jest ważne dla twojego szefa (np. Obniżyć koszty), a następnie obliczyć koszty. Uwzględnij ludzi i koszty narzędzi.
jasonk
7

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.

Bill jaszczurka
źródło
5

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

Emilio Garavaglia
źródło
1
Twoje domysły są trafne: jestem rzeczywiście jednym z najmłodszych w moim dziale. Niektórzy zdają się zdawać sobie sprawę, że mimo młodego wieku mam cenną wiedzę. Wiem i rozumiem, że wciąż muszę się wiele nauczyć (i wierzę, że tak będzie do dnia mojej śmierci), ale wielu z nich wydaje się obrażonych przez rzeczy, których nie wiedzą. Nie chcę ich odepchnąć ani ukraść ich pracy, czy cokolwiek innego: chcę tylko poprawić rzeczy, aby każdy mógł lepiej pracować / żyć. Czy będę musiał czekać, aż będę starszy, aby przytyć?
ereOn
1
@ereOn: Twoja jazda jest tak szlachetna, że ​​każda rozsądna osoba powinna chcieć z tobą pracować.
o0 ”.
@ereOn: „Czy będę musiał czekać, aż będę starszy, aby przytyć?” Niekoniecznie. Wiek jest wartością pod względem doświadczenia w zarządzaniu złożonością. Nie ma znaczenia w zrozumieniu nowych rzeczy (są one nowe dla każdego, a brak zaległości może być zaletą). To nie jest „osobisty” problem. Jest to problem „masy krytycznej”. Dopóki ludzie, którzy chcą zmiany, będą mniej niż 20%, będą uduszeni. Jeśli są więcej, przywództwo staje się widoczne (i nie jest to kwestia wieku). Jeśli lider może dotrzeć do 40% populacji, „nowa rzecz” będzie miała odpowiednie obywatelstwo. Od 60% zmiana jest spontaniczna.
Emilio Garavaglia
3

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

Joshua Drake
źródło
2
Uważam, że GTDWYOG nie jest zbyt pomocny. Moim zdaniem tytuł przynajmniej wprowadza w błąd: ktoś, kto „jest zaangażowany w zatrudnianie” lub ma swobodę ignorowania reszty świata podczas pracy w stołówce, nie jest chrząknięciem. Chrząknięcie to ktoś, kto musi postępować zgodnie z zaleceniami, bez żadnej kontroli nad okolicznościami, w których się znajduje. Z mojego doświadczenia wynika, że ​​pomimo idealistycznego obrazu namalowanego podczas wymiany stosów, dotyczy to większości programistów. A dla nich GTDWYOG jest bardziej receptą na to, że zostaniesz zwolniony za nieposłuszeństwo.
keppla
1

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.

Amy
źródło
2
ah, ale ile razy słyszałem „przepiszmy, będzie o wiele lepiej i fajniej w nowej technologii x” tylko po to, by przekonać się, że nowy nie był lepszy od starego (aw wielu przypadkach gorszy). Dość często, dopóki nie zajdzie taka potrzeba , najlepiej nie łamać czegoś, co działa.
gbjbaanb
1

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.

Lionel Barret
źródło
Dziękuję za twoje porady. Chodzi o to, że osoba odpowiedzialna wydaje się bardzo lubić wszystkich starych programistów (ponieważ ostatecznie wykonują zadanie i nie liczą godzin). Czuję, że mam bardzo małą wagę, ponieważ jestem młoda. Kilka osób w moim dziale przyjeżdża jednak, aby zapytać mnie o dobre praktyki, ale nawet kiedy wyjaśniam to bardzo pokornie, w pewnym momencie nie chcą pokazać, że nie wiedzą o tym zbyt wiele i starają się bronić swoich starych sposobów.
ereOn
1

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

Ben DeMott
źródło
-1

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ń!

falowany
źródło