To jest problem z zarządzaniem.

Przed wdrożeniem krytycznego kodu należy go kontrolować pod względem wersji, przejrzeć kod i przynajmniej udokumentować jego użycie. Jeśli chodzi o bezpieczeństwo, należy wybrać odpowiednich recenzentów i chronić repo i dokumenty. Nie ma powodu, dla którego nie można tego rozpocząć od razu.

Większy problem niż bezpieczeństwo pracy.

Każdy z tych programistów może umieścić złośliwy kod w firmie, albo przez pomyłkę, albo z własnych powodów. W najgorszym przypadku, mógłby aktywnie popełnić nefarious akty wykorzystując własną sytuację (wymuszenia, sabotaż, szpiegostwo przemysłowe, itp.). W najlepszym przypadku, ich nieprzejrzystość naraża wszystkich na obawy związane z bezpieczeństwem i zawsze pozostawia znak zapytania co do wszelkich audytów lub odpowiedzialności. Jeśli coś pójdzie nie tak, kto ma powiedzieć, że nie byli w to w jakiś sposób zaangażowani?

Musisz sporządzić raport dla kierownictwa.

Napisz krótki dokument opisujący exactly dlaczego obecne podejście prowadzi firmę w dół niebezpiecznej ścieżki (np. uderzenie przez scenariusz autobusowy). Zarysuj zagrożenia dla bezpieczeństwa, może nawet przytocz ostrzeżenia pochodzące z Twojej branży, z odniesieniami do artykułów, itp.

Załącz również listę sposobów, w jakie podejście tego faceta wpływa negatywnie na Twoją własną pracę, a także na pracę Twoich współpracowników.

Na koniec upewnij się, że lista zaleceń, które mają być wdrożone natychmiast, takich jak dodanie kodu do kontroli wersji dla wszystkich, aby zobaczyć, oraz uruchomienie serwera na maszynie wirtualnej, do której każdy ma dostęp. Zarysuj w jaki sposób te środki nie powinny w żaden sposób wpływać na pracę tej osoby i po prostu dodaj bezpieczeństwo i przejrzystość do całego procesu - wyraź jasno, że nie ma uzasadnionych zastrzeżeń do tych środków.

Być może usiądź ze swoim szefem, kiedy wręczysz mu ten raport i werbalnie przedstawisz dokładnie te obawy, które tu napisałeś: że ten facet buduje sobie imperium w infrastrukturze firmy, i że ostatecznie jest potencjalnie niebezpieczny . Jeśli twoi szefowie uważają, że ta osoba może stać się nierozsądna, możesz chcieć zastosować się do rady @BillLeeper'a i przejąć kontrolę nad jego maszyną, aby nie mógł zaszkodzić twojej organizacji. Oczywiście, to oni będą decydować.

Niestety, tak naprawdę nie powiedziałeś, czy ktoś rozmawiał o tych obawach ze współpracownikiem lub zarządem. Czy to naprawdę jest złośliwe? A może twój kolega jest po prostu ślepy? A może kierownictwo jest niewidome?

Sam byłem “tym” facetem.

W mojej poprzedniej pracy miałem czasem różne zadania boczne, aby “zrobić to małe narzędzie” lub zrobić coś prostego. Okazuje się, że nigdy nie ma zasobów na wewnętrzne oprogramowanie… Zwykle chodziło o coś takiego:

– Czy ktoś może spojrzeć na rozwiązania, które wybrałem, aby powiedzieć czy są odpowiednie? – Daj spokój, potrzebujemy tylko prostego narzędzia, które po prostu wykona tę prostą operację, zrobi to i będzie dobrze.

– Czy mogę stworzyć na naszym serwerze wirtualny serwer dla tej rzeczy? – Człowieku, to jest tylko do użytku wewnętrznego. Po prostu połóż go razem z innymi rzeczami na tym zepsutym fizycznym pudełku. Albo umieścić go na tym pudełku, które robi we-dunno-what funkcje. Albo umieścić go na własnej stacji roboczej.

Oczywiście, nigdy nie było zasobów czasowych na pisanie dokumentów. Chyba, że postanowiłem to zrobić w wolnym czasie. Oczywiście, wszystko co mogłem powiedzieć, gdy niektóre narzędzia miały problemy, to “praca nad tym”.

I wtedy zdecydowałem się zrezygnować. To był pierwszy moment, w którym ktoś z mojego otoczenia zrozumiał, że “małe wewnętrzne” narzędzia są tak naprawdę ważne, a “proste” rzeczy nie są takie proste. Spędziłem kilka weekendów pisząc dokumenty, aby mniej oszukiwać moich kolegów. Minął prawie rok i nadal otrzymuję wiele telefonów miesięcznie na temat tego, jak zrobić coś z moimi wewnętrznymi narzędziami.

Edit

Niektóre komentarze wskazywały, że nie powinienem pomagać im za darmo. Jest to generalnie poprawne. Chciałem wyjaśnić, że nie poświęcam godzin swojego czasu na rozwiązywanie ich problemów, tylko poświęcam minutę na odpowiedź na pytanie. Z technicznego punktu widzenia nadal jest prawdą, że w ten sposób umożliwiam i zachęcam do istniejących praktyk Przy okazji firma zaproponowała mi pracę w niepełnym wymiarze godzin lub płacenie za godzinę w celu rozwiązania problemów, jak to robiłem wcześniej i odmówiłem.

Rzecz w tym, że nie jestem skłonny zmusić moich byłych kolegów do “lepszego badania” zamiast po prostu pytać mnie “Na jakiej maszynie działa Veeam?”, jeśli mogę po prostu powiedzieć nazwę lub adres IP bez zastanowienia lub powiedzieć “Powinien być napisany w […]”. Poza tym 2-minutowa rozmowa telefoniczna z byłą ligą jest zazwyczaj tak samo pozytywna i relaksująca jak wizyta na stackexchange.

Edytuj koniec

Więc co mogę zasugerować? Twój kolega wydaje się być całkiem zdolny, prawda? Porozmawiaj o tym z kierownictwem. Nie mów “on staje się niezastąpiony”. Po prostu ich zapytaj. Co jeśli odejdzie? Co, jeśli zachoruje na dłużej? Przekonaj ich, że problem jest prawdziwy. Powinni sami przedyskutować to z tym facetem, żeby znaleźć rozwiązanie. Może po prostu brakuje mu środków? Może potrzebuje innej osoby w zespole “wewnętrznego oprogramowania”, żeby wszystko było ładne i ładne?

Większość z tych odpowiedzi to WAY OVERBOARD na kreślenie złośliwego zamiaru ze strony danego dewelopera.

Przed zrobieniem ukrytego obrazu serwera, a następnie wyprowadzeniem faceta z biura, dlaczego po prostu nie wziąć oddechu i spróbować zrozumieć, co się dzieje?

Bardzo dobrze może być, że dana osoba jest przepracowana, nie ma wystarczających zasobów i byłaby więcej niż chętna do dzielenia się wiedzą. A może robi to w ten sposób od dłuższego czasu i nigdy nie otrzymał wskazówki, że powinien zrobić coś innego. W minimalnym stopniu, zwłaszcza jeśli jego rzeczy PRACUJĄ, zasługuje na szansę rozwiązania problemów i współpracy ze współpracownikami.

Nie widzę żadnych dowodów na to, że cokolwiek z tego było próbowane w pytaniu PO. Przed rozważeniem drakońskich opcji, spróbuj najpierw komunikacji. Jeśli osoba nie miała zamiaru zrobić krzywdy, możesz oczekiwać od niej współpracy.

Jest coś, czego jeszcze nie widziałem w innych odpowiedziach:

Casually start looking for a new job

Oczywiście, opiera się to na założeniu, że już rozmawiałeś o tym ze swoim menadżerem. Inne odpowiedzi podały powody, dla których nie jest to Twój problem, ale Twojego menadżera, a także wskazały, jak podejść do tej rozmowy z Twoim menadżerem.

Teraz, patrzę na sytuację, w której rozmawiałeś o tym ze swoim menadżerem, a potem, po upływie rozsądnego czasu, nic się nie stało. Masz wrażenie, że Twój menadżer nie uważa tego za problem, o którym wiesz, że tak naprawdę to nie jest problem.

W tym miejscu możesz zacząć szukać nowej pracy. Nieważne, czy Twój menedżer po prostu nie uważa, że jest to problem, czy po prostu nie rozumie go na tyle dobrze, aby go dostrzec, jest tu coś nie tak. (I nie mówię tu o “prywatnym” kodzie, ale o problemie menadżera, który czegoś z tym nie robi.)

Taki problem to coś, czego prawdopodobnie nie będziesz w stanie zmienić ze stanowiska developera. Są jednak inne firmy, które nie mają takich samych problemów, więc może zechcesz poszukać innego pracodawcy.

Patrząc na to z pozytywnej strony, jednak w tej chwili nie ma na Ciebie zbyt dużej presji. Masz pracę i nie oczekujesz, że ją stracisz. Nie będziesz musiał iść na kompromis, aby móc nadal płacić czynsz/hipotekę/koszty życia. Możesz po prostu spokojnie zacząć się rozglądać i nie rzucać obecnej pracy, dopóki nie znajdziesz tej, którą naprawdę lubisz.

Wygląda na to, że są tu pewne dobre środki zaradcze, aby temu zapobiec w przyszłości, ale nie to, co zrobić z tym teraz.

1. Zabezpieczyć komputer. Albo kierownictwo i ekspert ds. informatyki przejdą nad nim, gdy jest on odblokowany i bez nadzoru, albo zażądają, aby odblokował maszynę i udzielił dostępu. Potem zabierzcie tego potwora z sieci. Zrób natychmiastowy obraz HD na wypadek, gdyby miał przełącznik “dead mans”.

2. Natychmiast zwolnij tego osobnika. Wyprowadźcie go przez drzwi. Nie martw się o przyczynę, na tym jego komputerze będzie mnóstwo dowodów. Jeśli firma się martwi, niech ich prawnik zadziała jego magię.

3. Zbierz zespół. Wytłumaczcie, co się stało. Ten człowiek zachowywał się lekkomyślnie i nieprofesjonalnie. Naraził firmę na niebezpieczeństwo i został za to zwolniony. Zajmie nam to wszystkie środki, jakie mamy, by uporządkować ten bałagan.

4. Wykorzystaj zespół do ponownego zbudowania i ponownego rozmieszczenia tej pracy w odpowiedni sposób na zabezpieczonych maszynach itp. Zespół będzie musiał przejść przez aplikację po aplikacji i zająć się wszystkimi sprawami. Nie martw się od razu o przepisywanie, po prostu upewnij się, że nie ma tylnych drzwi itp.

5. Zatrudnij eksperta ds. bezpieczeństwa. Ten facet prawdopodobnie nie pójdzie cicho i spróbuje “włamać się” z powrotem, aby sabotować lub w inny sposób uzyskać dostęp do jego systemu. Może on również posiadać globalne hasła do systemów, z którymi wchodził w interakcję lub uzyskiwał hasła indywidualne w czasie. Dział IT powinien uruchomić przymusowy reset hasła dla wszystkich użytkowników i zablokować na pewien czas dostęp z zewnątrz (np. VPN).

Wszystkie aktualne odpowiedzi i większość bieżących komentarzy jedynie przedstawiają aktualną sytuację lub dostarczają sugestii do podjęcia ekstremalnych kroków.

Podsumowując: Są dwie możliwe sytuacje: Współpracownicy robią to celowo, w tym przypadku są złośliwi w taki czy inny sposób, a wtedy konieczna jest ekstremalna ostrożność. Albo współpracownicy po prostu nie widzą potencjalnych i rzeczywistych problemów i niebezpieczeństw, które powodują, wtedy są “przyjaźni”, ale powinni być wzruszeni, aby zrobić lepiej.

Tak więc, poniższa mapa drogowa próbuje dwóch rzeczy jednocześnie: 1) Spróbuj zminimalizować potencjalne szkody, które mogą wyrządzić ci współpracownicy, jeśli są złośliwi, i 2) spróbuj zatrzymać ich w firmie (aby mogli rozwinąć się do bycia współpracownikami w przyszłości), jeśli są przyjaźni:

(btw: Wiem, że nie jesteś szefem, ale z informacjami, które inni przekazali, myślę, że będziesz miał wszystko w rękach, aby przekonać swojego szefa, aby potraktować ten wątek bardzo poważnie, więc ta mapa drogowa dotyczy tego, co szef mógłby zrobić, a nie tego, co byś zrobił. Jedyne co możesz zrobić, to zwrócić uwagę na swojego szefa. btw2: Jeśli szef nadal nie słucha, poszukaj nowej pracy i odejdź jak tylko znajdziesz nową. Ponieważ ci współpracownicy tykają bomby zegarowe, niezależnie od tego, czy są przyjaźni, czy złośliwi - to nie ma żadnego znaczenia).

1). Zrób po cichu kopie zapasowe wszystkiego, do czego masz dostęp. Nie wyłączaj systemów w tym procesie, wyłączanie systemów może potencjalnie wyzwolić jakieś pułapki.

2.) Zbuduj powód, dla którego stacje robocze muszą zostać zamknięte. Jeśli potrzebujesz jakiegoś pomysłu, skontaktuj się ze mną prywatnie.

3.) Wyciągnij dyski twarde, zrób pełny obraz, włóż je z powrotem. Zrób to w weekend lub w weekend

4.) Jeśli systemy mają detekcję włamań na poziomie BIOS-u, a Ty nie możesz ich obejść, stwórz inny powód, dla którego te systemy detekcji włamań wystrzeliły.

Ci współpracownicy tworzą narzędzia do rzeczy wewnętrznych, prawda? Więc nie potrzebują dostępu do systemów klienta i tym podobnych?

5.) Jeśli mają dostęp do systemów, nie potrzebują, zmieniają hasła, upewniają się, że nie ma czegoś takiego jak logowanie klucz publiczny, sprawdzają porty pod kątem procesów umożliwiających niestandardowe logowanie. Sprawdź cron/at jobs, sprawdź inetd, sprawdź wszystko co aktualnie działa. Dla każdego pojedynczego pid-a, musisz być w stanie odpowiedzieć, dlaczego ten proces w ogóle działa.

6.) Zdobądź nowego pracownika (naprawdę nowego, zupełnie nieznanego. Musi być naprawdę dobrym ekspertem, ponieważ musi być w stanie samodzielnie przejąć jego pracę na jakiś miesiąc, jeśli będzie to konieczne. Nie można po prostu wziąć jakiegoś przypadkowego absolwenta (nawet nie tego z najwyższą oceną), potrzebujesz kilku z tych facetów, którzy nigdy nie byli na uczelni, ale nadal wszystko wiedzą) i wprowadzić go do tego zespołu, aby ich wspierać. Zwłaszcza, że to oni wywołują blokady na innych pracownikach, można to łatwo uzasadnić. Jego oficjalnym zadaniem jest wspieranie ich, jego prawdziwym zadaniem jest dowiedzieć się, jak działają.

Krok 6 jest szczególnie ważny, ponieważ w ten sposób masz szansę, aby faktycznie dowiedzieć się, czy ci współpracownicy są w ogóle złośliwi.

Jeśli nowy facet jest dobrze zintegrowany z zespołem, to można założyć, że są przyjazne, że nowy facet powinien być w stanie wdrożyć niezbędne zmiany bez konieczności informowania tych facetów, że nie było żadnych podejrzeń wobec nich w ogóle.

Jeśli nowy facet dowie się, że są złośliwi, ale integrują go, to jego zadaniem jest grać razem. Nauczyć się wszystkiego, uznać za fajne to, co robią, i tak dalej. Zapłać mu dwa razy więcej pieniędzy, bo musi pracować dwa razy, bo jak tylko wróci do domu, to musi spisać wszystko, czego się nauczył i wysłać to do jakiegoś nowo utworzonego zespołu, który powinien przejąć pracę, jak tylko wystarczająco dużo wiedzy zostanie przekazane.

Jeśli złośliwy facet nie zintegruje go, to jedyną szansą jest mieć nadzieję, że masz wystarczająco dużo danych z kopii zapasowej (tylko na wypadek) i zwolnić ten zespół. Wtedy możesz potrzebować dwóch lub więcej dodatkowych super-ekspertów, o których mówiłem powyżej, aby bardzo szybko wprowadzić nowy zespół do tego kodu.

Mam nadzieję, że ta mapa drogowa pomoże - przynajmniej jako źródło inspiracji jak sobie z tym poradzić. Może w Twojej firmie masz jakieś opcje, których nie mogę wziąć pod uwagę, może są pewne różnice kulturowe, więc musisz się jeszcze nad tym zastanowić i może dostosować plan.

Dany programista nie może otrzymać żadnej nowej pracy, dopóki sytuacja nie zostanie rozwiązana w ten czy inny sposób. Wszystkie nowe wymagania muszą być przekazane innemu programiście/zespołowi, który musi przestrzegać odpowiednich procedur kontroli źródeł i wzajemnej weryfikacji (w razie potrzeby nowi pracownicy). Programista, o którym mowa, może być zajęty usuwaniem usterek lub “gaszeniem pożarów” swojej dotychczasowej spuścizny. Zasoby muszą być przeznaczone na odtworzenie istniejącej spuścizny i ponowne wprowadzenie jej w życie za pomocą odpowiednich procesów. Koszt takiego działania musi być uzasadniony istniejącym ryzykiem - ile będzie kosztował biznes, jeśli wszystko, co ten programista zrobił, zostanie nagle utracone? Albo, co gorsza, jakie dane firmowe (firmowe) są podatne na utratę na rzecz konkurencji?

Może warto zapytać tego pracownika: “co stanie się z nami, jeśli wpadniesz w autobus lub zdecydujesz się na miesięczny rejs dookoła świata?” i zmierzyć odpowiedź, aby zdecydować, czy dobrowolnie odda swój kod. Jeśli będzie współpracował, nie ma potrzeby, aby sytuacja stała się przeciwna; jeśli nie ma oznak troski o firmę z jego strony, czas zająć się zabezpieczeniem wszystkiego, czego się dotknął.

*Jak podejść do tego zarządzania? *

Powiedz, że najlepszą praktyką jest nie dopuszczanie do tego, z wielu powodów.

Profesjonalni programiści powinni wiedzieć, że nie jest to sposób na prowadzenie biznesu; a jeśli menedżerowie nie wiedzą nic innego, powinni przynajmniej to wiedzieć (programiści powinni powiedzieć menedżerom i/lub menedżerowie powinni powiedzieć programistom). Należą do nich “kopie zapasowe”, tzn. masz kłopoty, jeśli stracisz programistę (lub jeśli zostanie on przeniesiony do czegoś innego), lub jeśli programista straci maszynę.

Przynajmniej ty _masz kontrolę nad wersjami firmowymi, więc nie musisz walczyć z tą bitwą; po prostu zrób z tego zadanie/proces, aby był on rzeczywiście używany.

Prawdopodobnie nie powinieneś uruchamiać oprogramowania produkcyjnego na maszynie dewelopera. Pierwszym krokiem może być naleganie, aby:

• Użytkownicy nie nawiązywali połączeń sieciowych z maszyną dewelopera
• Oprogramowanie jest uruchamiane z/na serwerze produkcyjnym
• Oprogramowanie uruchamiane na serwerze produkcyjnym musi być zbudowane przez kogoś innego (lub przez maszynę produkcyjną), z kontroli źródła

Wdrażanie, które wymaga sprawdzenia kodu źródłowego, instrukcji budowy opublikowanych. Sugerowałbym, abyś zrobił to jako pół-emergency. Pozwól programiście na brak dostępu do serwera produkcyjnego lub maszyny budującej (aby sprawdzić, czy kod produkcyjny jest możliwy do sprawdzenia z kontroli wersji).

Po wykonaniu tego (po tym jak wiesz, że kod źródłowy jest w kontroli wersji i instrukcje budujące są publikowane), inni programiści mogą pomyśleć o sprawdzeniu kodu źródłowego i pomocy w jego utrzymaniu.

Zauważ, że * Get Rid Of Indispensable Programmer As Quickly As Possible** został opublikowany przez Geralda Weinberga w 1971 (więc, naprawdę, każdy powinien to już wiedzieć). IIRC oryginalny cytat brzmi,

“Jeśli programista jest niezbędny, pozbądź się go tak szybko jak to możliwe”.

To nie jest twój problem, to jest odpowiedzialność i rola menedżerów, jesteś tylko współpracownikiem i prawdopodobnie nie masz wszystkich niezbędnych informacji. Bardziej martwiłbym się o własne zadania, niż chciałem zaangażować współpracowników. Nie widzę, aby cokolwiek pozytywnego wyszło z tego, że robisz zamieszanie ze swoim współpracownikiem.

Zrobisz z niego wroga, pokażesz swojego menadżera za bycie niekompetentnym i sprawisz wrażenie, że masz tak mało pracy, że masz czas na wszczęcie wewnętrznego śledztwa, nie prosząc go o to ani nie mając do tego uprawnień.

Pytanie brzmi, jak bardzo chcesz się wyrwać z tego błędnego koła? Bo nie bądźmy w tym uroczy, to będzie kosztować firmę.

1. Firma będzie musiała wydać pieniądze, aby zatrudnić kogoś do napisania kodu, który firma kontroluje.
2. Firma musi zażądać kodu od programisty, a w razie potrzeby zwrócić się do niego z pomocą prawną. Zwrócę uwagę, że kod został zlecony przez firmę, że koder wyciągnął czek z firmy podczas pisania kodu, więc kod jest firmy. Niepowodzenie ze strony programisty do produkcji kodeksu będzie w najgorszym razie uznane za kradzież, co byłoby przestępstwem.

Wolność nie jest za darmo. Jeśli firma nie jest skłonna przeznaczyć środków na uwolnienie się od tej jednostki, to wszystko, co robisz, to trzepotanie dziąsłami. Wy wszyscy będziecie musieli stawić czoła tej sytuacji, ponieważ jeśli programista odejdzie lub zostanie przejechany przez ciężarówkę, firma jest SOL.

Weź pod uwagę powód, dla którego to robią. Jest całkowicie możliwe, że narożniki są obcinane, aby dopasować się do ograniczeń czasowych, celów wydajnościowych i stale rosnących wymagań. Prowadzi to często do zadłużenia technicznego i jednego bardzo zestresowanego programisty, który nie ma innego wyjścia, jak tylko rozwiązać każdy problem.

Osoba ta może pisać rzeczy w sposób, który tylko ona może naprawić, ponieważ nie ma czasu na dokumentowanie, wersję i utrzymanie kodu w odpowiednim czasie. Zaufaj mi, kiedy mówię, że ma to całkowicie negatywny wpływ na każdego, kto znajdzie się na tym stanowisku. To nie jest wygodna rola, w której ktoś może usiąść i odpocząć.

Jeśli, jak sugeruje Twój tytuł, nie rozwiązują problemów, nie byłoby problemu. Po prostu wyrzuciłbyś kodera, z całym jego kodem, bo jest bezużyteczny.

Zapobieganie takim sytuacjom jest niezwykle podstawowym zadaniem zarządczym. Wynika z tego, że kierownictwo, które jest świadome problemu, nie jest kompetentne, a kierownictwo, które jest kompetentne, nie jest świadome.

Niestety, rozłączanie takich sytuacji jest trudnym zadaniem dla kierownictwa. Ponieważ więc menedżerowie odpowiedzialni za tego dewelopera nie byli w stanie nawet zapobiec sytuacji, nie licz na to, że będą w stanie ją naprawić.

*Jedynym sposobem na naprawienie tego jest eskalacja na wyższy poziom zarządzania. *Jeżeli są zainteresowani i są w stanie to naprawić, nie musisz nawet wyjaśniać nam niczego więcej niż to, co wyjaśniłeś - po prostu zrób to mniej osobistym, skupiając się na programach i problemach z nimi, a nie na programiście.

Powinieneś wiedzieć, że jest to opcja wysokiego ryzyka - niskiej nagrody. Jeśli to zrobisz, nawet jeśli to zadziała, ucierpi na tym programista i jego menadżer (który prawdopodobnie jest również Twoim menadżerem) i będziesz wiedział, że jesteś za to odpowiedzialny. Jedyną korzyścią, jaką odniesiesz z tego tytułu jest (prawdopodobnie) przestrzeganie własnego kodeksu etyki i honoru, ale możesz przez to stracić pracę. Dlatego też niektóre z pozostałych odpowiedzi zalecają, abyś odpuścił lub po prostu szukał lepszej pracy, co jest mądrym posunięciem.

• *

** Innym sposobem, aby to naprawić, jest samodzielne zarządzanie i naprawienie tego, ale jest kilka pułapek.

Po własnej samoocenie zdecydował, że nie ma szans na awans, a jedynym powodem, dla którego firma musiałaby go zatrzymać, jest to, że nie udostępnia im kodu.

Nie wiem, czy się z tym zgadzasz, ale jeśli się zgodzisz, kod może być prawdopodobnie zrobiony przez kogoś lepszego. Albo jeśli nie wytłumaczysz, dlaczego to zachowanie sprawia, że nigdy nie będzie mógł awansować.

Myślę, że sprowadza się to do tego, czy ta sytuacja jest warta naprawienia tak bardzo, jak i tego, jak ją naprawić.

To jest zadanie dla kierownictwa. Pierwsze kierownictwo powinno spróbować odkryć, czy jest to celowe. Jeśli tak, należy opracować plan zwalniania przestępców. Jeśli nie jest to celowe, należy opracować plan przeszkolenia przestępców.

They design their programs … so that they are gradually more difficult to replace.

Not if I was the boss!

There are two problems here:

1. Zły programista.

Niekompetentne zarządzanie.

Jest to oczywiście założenie, że prawidłowo reprezentujesz sytuację.

Nie możesz naprawić problemu #1. Istnieje niewielka szansa, że możesz rozwiązać problem #2. Ta niewielka szansa jest wtedy, gdy szef z jakiegoś powodu po prostu nie jest świadomy tego, co się dzieje. Idź do szefa i powiedz mu o problemach, które widzisz i dlaczego są one złe dla firmy. To prawdopodobnie się nie uda, ponieważ szef już wie o problemie i nie jest kompetentny, aby go rozwiązać, lub wie tak mało o oprogramowaniu i zarządzaniu inżynierami oprogramowania, że nie jest nawet kompetentny, aby zrozumieć problem.

Jedynym prawdziwym rozwiązaniem jest zacząć od naprawienia problemu #2, w którym w najlepszym przypadku można odgrywać niewielką rolę. Niekompetentny menedżer musi zostać zastąpiony.

Nowy menedżer ma następnie usiąść z tym programistą, kazać mu wyjaśnić architekturę i powiedzieć mu, aby zaprzestał tworzenia nowych programów i udokumentował wszystkie protokoły. W międzyczasie dostaje nowego inżyniera, który ma “pomóc” pierwszemu inżynierowi w udokumentowaniu protokołów, przekazaniu oprogramowania do kontroli źródłowej i upewnieniu się, że sam kod jest dobrze udokumentowany. Ten nowy inżynier wykonuje wszelkie nowe prace rozwojowe i, miejmy nadzieję, naprawia błędy i drobne ulepszenia istniejącego oprogramowania.

Pierwszemu inżynierowi nie spodoba się to. Może zrezygnować, rzucić napad szału, głośno protestować lub, co gorsza, sabotować rzeczy. Dlatego robienie kopii zapasowej jest pierwszym zleceniem w biznesie. Byłoby miło płynnie przejść od pierwszego do drugiego inżyniera, ale nie oczekuj, że tak się stanie. Plan jest taki, aby w końcu zwolnić pierwszego inżyniera, jeśli nie zrezygnuje lub nie obróci się (jeszcze bardziej) destrukcyjnie przeciwko firmie w pierwszej kolejności.

Po prostu nie możesz pozwolić, aby ten nonsens trwał dalej. Im dłużej to robisz, tym bardziej bolesne jest, aby w końcu to naprawić. Nie naprawianie tego, ponieważ będzie to już bolesne, jest absolutnie niewłaściwym sposobem, aby o tym myśleć.

W tym przypadku użyłem retorycznego “ty”. Aby odpowiedzieć na pytanie, co możesz zrobić osobiście, zacznij od przekazania swoich obaw szefowi, jak powiedziałem powyżej. Ponownie, jest mało prawdopodobne, aby przyniosło to cokolwiek użytecznego.

Następny krok zależy od tego, czego nam nie powiedziałeś. To może być bardzo niebezpieczne przechodzić przez głowę twojego szefa. Jeśli tak, to nie ma nic innego, co możesz zrobić poza oceną, czy naprawdę chcesz tam dalej pracować. Jeśli jest to wystarczająco mała firma, w której możesz wygodnie rozmawiać z wyższym kierownictwem, to idź do przodu. Jest całkiem możliwe, że kierownictwo wyższego szczebla ma już wrażenie, że menedżer niskiego szczebla jest niekompetentny, ale oczywiście nie powie ci tego. To może być dodatkowa informacja dla nich, aby podjąć bardziej zdecydowane działania.

Kolejną odległą możliwością, jeśli Twoim głównym celem jest naprawienie tego bałaganu i widzisz siebie dłużej w tym miejscu, jest zaproponowanie, aby wziąć na siebie część wewnętrznego rozwoju narzędzi. To powinno dać Ci uzasadniony powód, aby porozmawiać z pierwszym inżynierem, zrozumieć jak to działa, gdzie mieszka kod, itp. W końcu to ty będziesz facetem od narzędzi, a kierownictwo może pozbyć się pierwszego inżyniera. Następnie możesz poprosić ich o zatrudnienie kogoś na to stanowisko, abyś mógł wrócić do tego, co chcesz robić. Ponownie, nie jest to coś, co poważnie sugeruję, ale jest to alternatywa, jeśli naprawdę chcesz i chcesz.