Jak zasugerować zmiany jako niedawno zatrudniony pracownik? [Zamknięte]

Niedawno zostałem zatrudniony w dużej firmie (tysiące ludzi, aby dać wyobrażenie o wielkości). Powiedzieli, że mnie zatrudnili z powodu mojej dyscypliny i dlatego, że pomimo mojej młodości (mam 25 lat), byłem programistą C / C ++.

Teraz, gdy jestem w środku, widzę, że cały system jest stary i często korzysta z przestarzałych technologii. Nie ma konwencji nazewnictwa (pliki, funkcje, zmienne, ...), nie używają Kontroli wersji, nie używają wyjątków ani polimorfizmu i wygląda na to, że prawie wszyscy stracili pasję (niektóre z nich mają zaledwie 30 lat) ).

Chciałbym zasugerować jakieś zmiany, ale nie chcę być „nowym facetem, który chce wszystko zmienić tylko dlatego, że nie chce się dopasować”. Próbowałem „wpasować się”, ale tak naprawdę zajęło mi tydzień, aby zrobić to, co zrobiłbym w jedno popołudnie, tylko z powodu słabych narzędzi, z których jesteśmy zmuszeni korzystać. Bardzo często moi koledzy nigdy nie patrzą na nowe „rzeczy” i techniki, z których ludzie korzystają obecnie. To tak, jakby się poddali. Sytuacja jest naprawdę frustrująca.

Czy kiedykolwiek byłeś w podobnej sytuacji, a jeśli tak, jakie rady dałbyś mi? Czy istnieje subtelny sposób zmieniania rzeczy bez stawania się tutaj czarnymi owcami ? A może powinienem po prostu zrezygnować z pasji i energii?

Dziękuję Ci.

Aktualizacje

Zgodnie z cennymi radami mogłem zasugerować zmiany i kieruję teraz zespołem, który musi stworzyć i wdrożyć Subversion: D Dziękuję wam wszystkim!

6 miesięcy później

Zrezygnowałem i znalazłem o wiele ciekawsze środowisko, o wiele lepsze wynagrodzenie i ciekawsze wyzwania. Po nic bym nie wrócił.

Byłem w podobnej sytuacji w mojej poprzedniej firmie, w której byłem przez 5 lat. Kiedy dołączyłem w 2004 r., Byli to:

• nadal używa Microsoft Access do swoich baz danych (nawet tych krytycznych dla biznesu)
• za pomocą Visual Basic 6 lub Access / Excel VBA do programowania
• korzystanie z wielu zewnętrznych firm zamiast wewnętrznych zasobów programistycznych (menedżerowie biznesowi prowadzili własne projekty programistyczne i 90% czasu wystawiało kontrakty bez wiedzy IT)
• z trudem łapie kontrolę wersji.

Kiedy wyjechałem w zeszłym roku, firma była:

• używając wyłącznie .NET i C #
• wyrzucił cały program Access
• za pomocą SVN do kontroli wersji
• miał 2 rozbudowane skrzynki SQL Server i migrował istniejące bazy danych Access do SQL
• wszystkie prace rozwojowe przeszły wewnętrzne zespoły i wyszło na przetarg tylko wtedy, gdy zasoby były ograniczone

W tym czasie nie ukończyłem 21 lat, a następny najmłodszy z zespołu programistów miał 30 lat. Nie zrobiłem tego sam. Kierownik działu IT dołączył do firmy w tym samym czasie i chciał wnieść cały rozwój poprzez IT.

SVN było moim pierwszym osiągnięciem. Spotkałem się z moim kierownikiem liniowym i podkreśliłem kilka sytuacji, w których kod został wprowadzony na żywo lub zmieniony, co spowodowało problemy, i podkreśliłem fakt, że nie ma odpowiedzialności - zasadniczo nie można go winić - a potem zaczął słuchać.

Następnie złożyłem prezentację zespołowi i wyjaśniłem koncepcję kontroli wersji oraz przedstawiłem kilka sytuacji, w których SVN może pomóc nam programistom. Młodsi brali to jak kaczka do wody, starsi nie tyle, ale próbowali i nie narzekali na tych, którzy z niej korzystali.

Kolejnym ważnym osiągnięciem było wprowadzenie kompletnego systemu na miejscu - kierowałem projektem, który pozwolił firmie zaoszczędzić 120 000 funtów rocznie na licencjonowaniu. Wolny czas spędziłem około 2 miesięcy na pisaniu nowego systemu, przedstawiłem go kierownikowi IT i wyjaśniłem oszczędność kosztów. Następnie pozwolił mi przedstawić to firmie i wyjaśnił, w jaki sposób możemy wdrożyć do systemu wszystko, co im się podoba - bez ograniczania się do systemów „z półki”.

4 tygodnie później mój system był pilotowany w 10 lokalizacjach, a 6 miesięcy później został uruchomiony. Rok później anulowali umowę z firmą zewnętrzną, usunęli wszystkie jej ślady z sieci i przyjechali do nas z prośbą o duże ulepszenie naszego wewnętrznego systemu.

Moja rada dla ciebie:

• jeśli zależy ci na firmie, wystaw ją. Jeśli inni nie lubią twojego podejścia, pozwól im się tym zająć - chodzi o kompromis
• Dostosuj sugestie do osoby, z którą rozmawiasz - menedżerowie lubią słyszeć o tym, jak mogą a) oszczędzać pieniądze, b) dokładnie winić ludzi, gdy coś jest nie tak, ale programiści lubią słyszeć, jak mogą a) oszczędzać czas, b) trzymać się na przykład dla siebie
• jeśli jesteś pasjonatem zmian (które brzmi jak jesteś), pokaż ludziom swój entuzjazm i nie zniechęcaj się, gdy są mniej niż entuzjastyczni
• Nie mów o wprowadzaniu zmian. Zrób je. Kiedy zaczniesz rezygnować z fantastycznej pracy w krótszym czasie niż bardziej doświadczeni ludzie, ludzie zaczną pytać „dlaczego?”.

Powiedzieli, że mnie zatrudnili z powodu mojej dyscypliny i dlatego, że pomimo mojej młodości (mam 25 lat), byłem programistą C / C ++.

Bardziej prawdopodobne, ponieważ jesteś tańszy.

Czy kiedykolwiek byłeś w podobnej sytuacji

Tak.

jakie rady byś mi dał

Opuszczać.

Czy istnieje subtelny sposób zmiany rzeczy bez stawania się tutaj czarnymi owcami?

Może być. Wprowadź zmiany i zademonstruj, jak poprawiają rzeczy dla wszystkich. Po zrobieniu tego wiele razy, możesz zyskać uznanie tych, którzy nie są zgubieni.

A może powinienem po prostu zrezygnować z pasji i energii?

Nie ma mowy. Jesteś młody i musisz w pełni czerpać z okazji. Nie marnuj lat „gdzieś”. Spójrz na to stanowisko i zrozum, czy da ci cenne doświadczenie w dalszym rozwoju kariery. Jeśli widzisz możliwości, odkryj je. Jeśli ich nie ma, a to tylko „praca”, wynoś się. Praktyka pokazuje, że ci, którzy stracili pasję (lub nigdy jej nie mieli), nie mogą jej odzyskać. Poszukaj zespołu pasjonatów i dołącz do nich.

Dawaj dobry przykład . Stopniowo niewielka zmiana w czasie. Przyciągnij kolegę i zaprezentuj mu coś. Jeśli nie dostaną, nieważne, spróbuj jeszcze raz.

To zajmie czas. Po prostu nie odrywaj ludzi zbyt szybko od stref komfortu.

Smutne, ale dlatego tu jesteś i nie ma ich.

Na przykład. Skonfiguruj kontrolę wersji lokalnie i pokaż im, jak może pomóc. Następnie daj im trochę zasobów (proste czytanie), które mogą cię wykonać kopię zapasową.

Kolejna rzecz na temat narzędzi . Czasami musisz wydawać własne pieniądze, kupując lepsze narzędzia. Wiem, że nie jest to „zrobione”, ale rozmawiając z innymi branżami, znajduję wielu „prawdziwych” inżynierów modowych / kupujących własne zestawy narzędzi, aby lepiej wykonywać swoje zadania. Po pierwsze zawsze tak robiłem, gdy widzę, że ratuję się przed zanikiem umiejętności.

Jestem starcem (51) i miałem ten sam problem przy każdej pracy, jaką kiedykolwiek miałem. Może po prostu pochodzi od bycia najmądrzejszym facetem w pokoju! :-) Poważnie jednak, kiedy wiesz, jak zrobić to dobrze, a oni nie, często myślisz: „Hej, pokażę wszystkim tę nową i ulepszoną technikę, wszyscy będą pod wrażeniem i będą chcieli wskoczyć do korzystania z niego ”. Ale w prawdziwym życiu, w 90% przypadków, pokazujesz ludziom lepszy sposób, a oni wymyślają długą listę wymówek, dlaczego sposób, w jaki robili to przez cały czas, jest lepszy. Kiedy wykażesz, że ich powody są nieważne, wymyślają nowe, nawet lżejsze powody. Miałem wiele razy, że

Nawet jeśli naprawdę jesteś geniuszem, musisz zaakceptować fakt, że nikt inny nie wie, że jesteś geniuszem, dopóki tego nie udowodnisz. Przypomina mi się Kris, mój przyjaciel, który rozpoczął nową pracę po spędzeniu 10 lat w jednej firmie. Krótko po rozpoczęciu nowej pracy był na spotkaniu, na którym dyskutowali na temat jakiegoś problemu technicznego i zaczął proponować proponowane rozwiązanie. Potem ktoś inny przerwał i powiedział: „Tak, dzięki. Bob, co myślisz?” Na początku był zirytowany: znał właściwą odpowiedź, ale nikogo to nie obchodziło! Zamiast tego poszli z opinią kogoś, kto wiedział o wiele mniej niż on. Ale potem zdał sobie sprawę, hej, w mojej starej pracy zyskałem reputację kogoś, kto wiedział, o czym mówi, więc kiedy rozmawiałem, ludzie słuchali. Tutaj nie mam jeszcze reputacji, więc nikogo nie obchodzi, co myślę.

Jestem na mojej obecnej pracy 2 lata i dopiero w ciągu ostatnich kilku miesięcy moja opinia zaczęła mieć jakąkolwiek realną wagę. Musisz być cierpliwy.

Z drugiej strony, nowi ludzie często mają milion propozycji ulepszeń, które są naprawdę niepraktyczne, ponieważ nie wiedzą jeszcze wystarczająco dużo o organizacji i dlatego nie wiedzą, dlaczego rzeczy są robione tak, jak są. Czasami ludzie robią coś w ten sam sposób przez 20 lat, ponieważ zawsze tak było i zawsze nikt nie pomyślał o lepszym sposobie; ale czasem ludzie robią coś w ten sam sposób przez 20 lat, ponieważ doświadczenie pokazało, że jest to dobry sposób, a za każdym razem, gdy próbują czegoś innego, jest to katastrofa. Nie bądź więc zbyt szybki, aby stwierdzić, że wszyscy ci ludzie są idiotami. Dowiedz się, dlaczego robią to po staremu, zanim przedstawisz swoją nową, genialną sugestię. Miałem wiele razy w życiu, kiedy „

Znajdź sojuszników, którzy również chcą ulepszyć firmę.

Jest coś do powiedzenia na temat ratowania i pozostawienia ich do zgnilizny. Jednak po wznowieniu będzie wyglądać niesamowicie, jeśli uda ci się opanować kontrolę wersji i inne ulepszenia.

Skorzystaj z testu Joela podczas przyszłych wywiadów. Pamiętaj, że przeprowadzasz również wywiad z firmą.

Moja pierwsza rada: nie próbuj zbyt szybko zmieniać zbyt wiele. Najpierw zdobądź reputację dobrego, niezawodnego programisty, który potrafi załatwić sprawę. Teraz, jako nowicjusz, wszystko, co sugerujesz, jest podejrzane; jeszcze cię nie znają i nie szanują. Zdobądź ten szacunek jako swój pierwszy krok. Nadszedł czas, aby zacząć wprowadzać zmiany.

Wybieraj ostrożnie. Zacznij od kontroli wersji, a nie nowych technologii. Ponieważ to naprawdę najważniejsza zmiana. Możesz to zrobić tylko za pomocą swojego kodu, a następnie upewnij się, że kiedy musisz wrócić do poprzedniej wersji lub copmpare, aby dowiedzieć się, co się zmieniło, daj innym znać, jak łatwo było w swobodnej rozmowie.

Wykorzystaj swoją aktualną wiedzę, aby być osobą, która świeci, a wtedy ludzie zaczną pytać, jak to robisz. Kiedy komputery osobiste pojawiły się w miejscu pracy, pracowałem dla agencji kontroli rządowej. Wszyscy seniorzy byli bardzo przeciwni posiadaniu własnych komputerów (ponieważ była to praca dla sekretarek). Juniorzy złapali wszystkie pierwsze komputery i zaczęli robić rzeczy, których seniorzy nie mogli zrobić z Lotus 1-2-3 i Harvard Graphics, i nagle starsi ludzie byli zainteresowani, ponieważ młodzi chłopcy zwracali uwagę bardzo kierownictwa wyższego szczebla.

Zmiana kultury organizacyjnej nie jest kwestią techniczną, lecz kwestią polityczną. Przeczytaj trochę na temat zarządzania polityką biurową. Będziesz potrzebował wsparcia politycznego na wysokim szczeblu.

Podobną sytuację spotkałem w mojej obecnej pracy. Zostałem zatrudniony zaraz po ukończeniu szkoły, aby pracować w zespole złożonym głównie z inżynierów, którzy są tu ponad 15 lat. Wprowadzanie zmian nie było łatwe (wciąż naciskam na pewne rzeczy do zrobienia), ale jest to możliwe.

Na przykład mój zespół utrzymywał, aktualizował i korzystał z 16-bitowego narzędzia testowego DOS. Narzędzie to było bardzo trudne do zaktualizowania, ponieważ aplikacja przesunęła granice 16-bitowego linkera do tego stopnia, że ​​jeśli dodałeś kod, musiałeś usunąć coś innego, aby go dopasować. Zapytany, dlaczego marnujemy tyle czasu i energii na 16-bitowy kod, odpowiedział: „ponieważ potrzebujemy go do uruchomienia w systemie DOS, abyśmy mogli uruchomić go z rozruchowego dysku flash”. Próbowałem przekonać ich do przeniesienia narzędzia do 32-bitowego systemu Linux, ale zarząd nie chciał zainwestować czasu, aby to zrobić (mieliśmy już za dużo pracy do wykonania). Więc poszedłem naprzód i przeniosłem narzędzie w czasie przestoju (15 minut tu i tam na lunch, w weekendy lub kiedy czekałem na inny kod do skompilowania). W ciągu kilku miesięcy Miałem to narzędzie całkowicie przeniesione, wzbogacone o wszelkiego rodzaju rzeczy, z którymi oryginalna 16-bitowa aplikacja nie mogła sobie poradzić, i uruchamianie z dysku flash Linux. Ludzie zauważyli, kiedy zacząłem go używać, i komentowali, w jaki sposób mogę szybciej załatwić sprawę i jak moje narzędzie generuje lepsze wyniki debugowania. Wkrótce zarząd usłyszał o tym. Gdy zobaczyli korzyści (a co najważniejsze, że praca została już wykonana), nie byli już przeciwni temu pomysłowi.

Lekcja, której nauczyłem się z tej historii, jest następująca: jeśli uważasz, że możesz coś poprawić, porozmawiaj o tym ze swoim menedżerem. Jeśli nie chcą wydawać na to zasobów, zrób to sam i udowodnij im, że Twój pomysł jest ważny i użyteczny. O wiele łatwiej jest odmówić pomysłowi, który ktoś proponuje, niż temu, co widzisz przed sobą, co ma oczywistą wartość.

Gdy Twój zespół / menedżer wdroży Twój pomysł i zacznie dostrzegać jego zalety, chętniej wysłucha Twoich pomysłów w przyszłości. Użyłem „ulicznej wiarygodności”, którą zdobyłem z mojego narzędzia testowego, aby ponownie napisać, aby przekonać mój zespół, że musimy porzucić nasz obecny, archaiczny system kontroli wersji (który pozostanie anonimowy, aby uniknąć zakłopotania) i przejść na Subversion. Zgłosiłem się na ochotnika, aby poprowadzić wysiłki związane z konfiguracją / migracją, aby zapewnić, że kierownictwo to zatwierdzi.

To rodzaj „jednego kroku”. Prawdopodobnie jest mnóstwo rzeczy, które chciałbyś zmienić, ale na początek wybierz coś małego (ish). Zademonstruj jakość swoich pomysłów w taki sposób, aby Twój zespół i kierownik nie mogli odmówić. Podobnie jak Twoje konto stackoverflow, im więcej masz dobrych pomysłów, tym lepsza będzie Twoja reputacja i łatwiej będzie zaakceptować Twoje pomysły.

Zdecydowanie zacznij korzystać z narzędzi, które chciałbyś mieć lokalnie (tam, gdzie to możliwe - niektóre firmy wydają się również kontrolować to, co możesz zainstalować na swoim pudełku z dziwnie ciasną pięścią). Skonfiguruj swój ulubiony system kontroli wersji i zacznij go używać. W każdym dotkniętym kodzie wprowadzaj niewielkie zmiany, które czynią kod czystszym, szczególnie tam, gdzie możesz napisać nowy kod. Jeśli zatrudnili cię za twój rygor i doświadczenie, oznacza to, że już cię szanują.

Niedawno przeczytałem Hiring Ren i Stimpy i okazało się, że przykład Stimpy był wielkim wyzwaniem. Jeśli podążysz za jego przykładem, ostatecznie poprosisz (ładnie) o wszelkiego rodzaju perspektywy od współpracowników, dając ci wiedzę, której nie zrobi beznamiętny programista. Spędzisz każdy wolny czas na wymyślaniu sposobów na ulepszenia. Jeśli firma uzna twoją pracę za wartościową, staniesz się bezcenny. Jeśli nie, prawdopodobnie będziesz chciał szukać pracy.

Wiele osób odpowiedziało sugestiami, aby skupić się na jednej małej rzeczy na raz, a kilka sugerowało kontrolę wersji. Pójdę o krok dalej: utwórz repozytoria na komputerze stacjonarnym i pracuj z tych repozytoriów. Aktualizuj je regularnie z dowolnego głównego repozytorium, z którego korzysta firma. Gdy (nie jeśli) nastąpi kryzys, ponieważ ktoś uszkodził wzorzec, powiedz mu, że możesz wyciąć nową kopię z osobistego repozytorium.

Nie należy jednak w żadnym wypadku umieszczać kodu firmy na komputerze, który osobiście posiada się lub zabiera do domu . Ponieważ wtedy może się okazać, że zamiast być bohaterem, jesteś po złej stronie biurka od prawnika (w najlepszym wypadku) lub organów ścigania (w najgorszym przypadku).

Pochodzisz z innego młodszego programisty ... czy masz świetne umiejętności ludzi? Czy masz doskonałe poczucie powściągliwości i rozumiesz, kiedy zaproponowanie pomysłu jest właściwe, a jak najlepiej sprzedać ten pomysł? Nawet jeśli to zrobisz, nadal możesz być „tym facetem”, który mówi innym ludziom, jak wykonywać swoją pracę, nie udowadniając swojej wartości.

W ten sposób nadal buduję swoją wiarygodność jako młodszego programisty: identyfikuję załamanie / kludge / marnowanie czasu. Następnie naprawiam to, automatyzując (pliki wsadowe, skrypty PowerShell, prosty program, nowe darmowe oprogramowanie, cokolwiek w weekend), nie przeszkadzając nikomu innemu. Dbam o to, aby był to element mojego ciągłego samokształcenia technicznego, dzięki czemu mogę myśleć o nim jako o „poświęceniu dodatkowych godzin na nauczenie się nowej rzeczy ORAZ pomóc firmie”.

Jeśli moja poprawka jest szczególnie fajna, dzielę się nią i mówię: „Hej, stworzyłem to fajne narzędzie, automatyzuje XY i Z i robi to szybko”. Zachowaj na nim swoje imię. Powtarzać. Problem wiarygodności rozwiązany w ciągu kilku miesięcy, jeśli masz wysoki odsetek wykonawców na swoim poziomie, a ludzie powyżej ciebie będą bardziej otwarci na twoje sugestie, jeśli będziesz gotowy wyjaśnić, dlaczego Twój pomysł jest dobry i jak może rozwiązać ich problemy.

Ostatnio byłem w stanie zaproponować wyższemu kierownictwu nowe pomysły, które zostały zaakceptowane, głównie dlatego, że poświęciłem czas na wyjaśnienie mojego rozumowania, wysłuchałem ich opinii i miałem wiarygodność mojej przeszłej pracy.

DODATEK: Jeśli Twój menedżer kwestionuje twoje zachowanie ... nie rób tego, dopóki nie poczuje, że Twoja wydajność utrzymuje się na poziomie „co najmniej 25%”, tj. Upewnij się, że twój szef jest z tobą zadowolony, zanim zaczniesz wymyślać wszelkiego rodzaju sprytnych poprawek, które popychają cię wyżej do tego najwyższego%, albo pomyśli, że marnujesz czas. Jeśli rzucasz nowe narzędzia i rozwiązania, a jednocześnie pozyskujesz pozytywne opinie na temat wydajności, a on nadal nalega na zarządzanie Tobą, możesz mieć problem, który wykracza poza zakres tego tematu.

Wmieszaj.

Jak powiedziałeś, nie chcesz być czarną owcą. Ponieważ jednak (podobnie jak ja) chcesz dodać użyteczną zmianę:

Dodaj wartość w tle.

Skonfiguruj cronjobs, aby sprawdzać kod ludzi w svn / hg / git. Twórz własne narzędzia w swoim własnym czasie, które w widoczny sposób mogą poprawić wysiłki programistyczne. W szczególności chcesz wprowadzić ulepszenia w firmie, dzięki którym możesz pokazać swoim seniorom we własnej kabinie. A oto dlaczego:

współczynnik WOW

Jeśli możesz powiedzieć „Cześć Alice, wiesz, jak Bob właśnie złamał kompilację? Mogę cofnąć jego edycję, a kompilacja znów działa”. A kiedy twój senior powie święte gówno, może obudzisz się w nich wystarczająco dużo pasji, aby przeforsować lub przynajmniej zachęcić do nowych praktyk.

Oto moja rada.

Byłem w podobnej sytuacji, powinienem najpierw powiedzieć, że moja firma jest dość mała, ma około 6 programistów, jestem rodzajem programisty, który lubi korzystać z nowej technologii, nowych narzędzi i wszystkiego, co ułatwi moją pracę i produkuje oprogramowanie lepszej jakości .

Kiedy zacząłem, korzystaliśmy z programu Visual Studio 2005, kiedy VS2008 był już od dłuższego czasu, ale nakłonienie mojego szefa do wydania pieniędzy na uaktualnienie wszystkich naszych programistów nie było łatwe, musiałem powoli wymyślać ten pomysł, ponieważ „byłoby miło, gdybyśmy mogli to zrobić”, ale zanim przedstawiłem to mojemu szefowi, upewniłem się, że inni programiści byliby dobrzy w tym pomyśle, ponieważ to oni używają go i mają grupę ludzi w przysługa wyglądałaby mniej jak decyzja jednej osoby.

Myślę, że zamiast po prostu przekazać pomysł swojemu szefowi, może powoli wprowadzę wszelkie możliwe zmiany, ponieważ czuję, że jeśli zasugerujesz pomysły, które zmienią firmę w lepszy sposób, pokazuje również, że zależy Ci na pracy i pokazuje, że planujesz na zrobienie tam domu.

Zależy to również od środowiska pracy, w którym się znajdujesz, i osobowości twojego szefa, jeśli są wyluzowani i traktują cię jak rodzinę i zasięgają porady, to sugerują, ale jeśli traktują cię jak liczbę, byłbym bardzo ostrożny, jak zbliżasz się do tego.

Może to być szansa na całe życie - zmiana sposobu działania firmy w wieku 25 lat. Jeśli jednak będą się opierać i okazywać wrogość przez cały czas, nie jest to miejsce dla ciebie.

Pamiętaj, że twój wywiad był procesem dwukierunkowym. Można było poczuć, jak archaiczne i odporne na zmiany.

Ps, ja też mam 25 lat i wiem, jak się czujesz. Prawdopodobnie jesteś o wiele chętniejszy do nauki i próbowania nowych rzeczy niż twoi koledzy. W każdym razie muszę wrócić do tej pracy .NET4, którą przedstawiam;)

Przeczytaj „ Robiąc rzeczy, gdy jesteś tylko żartem” Joela Spolsky'ego.

... czasami nie masz siły, by wprowadzić zmiany w swojej organizacji przez wykonawczego fiat. Oczywiście, jeśli jesteś zwykłym programistą na dole totemu, nie możesz dokładnie nakazać ludziom, aby zaczęli tworzyć harmonogramy lub bazy danych błędów. I nawet jeśli jesteś menadżerem, prawdopodobnie odkryłeś, że zarządzanie programistami przypomina hodowanie kotów, ale nie jest tak zabawne. Samo powiedzenie „zrób tak” nie czyni tego.

To może być frustrujące, gdy pracujesz w organizacji, która ma niski wynik w teście Joela . Bez względu na to, jak dobry jest twój kod, twoi współpracownicy piszą tak zły kod, że wstydzisz się być związany z projektem. Lub kierownictwo podejmuje złe decyzje dotyczące tego, jaki kod napisać, więc jesteś zmuszony zmarnować swój talent na debugowanie wersji AS / 400 gry planowania emerytury dla dzieci.

... radzenie sobie z życiem w złym zespole może być irytujące. Istnieją jednak strategie poprawy zespołu od dołu i chciałbym podzielić się kilkoma z nich ...

Praca z zarządem; nie „zbuntuj się”. Pracuj w ramach procesu i ujmuj rzeczy w sposób zrozumiały dla ludzi, np. „Wdrożenie svn zajmie nam miejsce na serwerze, dwa dni na skonfigurowanie i będziemy musieli wykonać kopię zapasową, ale zyskamy x, y, z , co pozwala nam zaoszczędzić dużo pieniędzy ”.

Porzucić. Istnieje wiele miejsc pracy. Naprawianie losowej firmy, która cię zatrudniła, nie jest twoim zadaniem. Podoba im się taki, jaki jest, w przeciwnym razie zatrudniliby nowego CTO lub coś takiego.