Jak powstrzymać pracownika od trzymania firmy jako zakładnika?

What can I do to fix this situation?

Nic, you’ve only been there a few months, it’s not your role and you don’t have the power to do anything except whine about it.

Your superior have a lot of recourses, but haven’t used them in 7 years, so at this point you’re just second guessing their reasons and analysing a college instead of concentrating on your own responsibilities and tasks.

Zatrudnij dwóch lub trzech najmądrzejszych programistów, których możesz znaleźć. Podaj im cały kod. Niech sprawdzą, czy rzeczywiście mają cały kod, wszystko, co jest potrzebne do uruchomienia oprogramowania. Niech dowiedzą się, co robi kod, udokumentują go, zafaktorują, dopóki nie dotrą do punktu, w którym będą mogli naprawić problemy szybciej niż Pan A. Wszystko to oczywiście bez żadnej wiedzy o A.

W tym momencie upewnij się, że całkowicie wyłączyłeś Pana A z wszelkich zasobów firmy, przekazałeś pracę swoim nowym programistom i poinformowałeś Pana A. A, że jego praca została zakończona.

Myślę, że przy metodach rozwoju pana A, ilość pracy, jaką wykonuje jego kod jest o wiele mniejsza niż 7 lat pracy nad nim, i że kod jest zaciemniony, ale nie trudny, co czyni pracę nowych ludzi o wiele łatwiejszą.

PS. Ze względu na pewne komentarze, chcę to jeszcze raz podkreślić: Problemem nie są tylko pieniądze, problem polega na tym, że oprogramowanie jest znacznie słabiej rozwinięte niż mogłoby być, ponieważ A skupia się na tym, żeby było trudne do rozwinięcia, a nie na ulepszaniu oprogramowania.

Krótka odpowiedź: Twoja organizacja jest obecnie w poważnym niebezpieczeństwie The Bus Factor .

Dlatego nigdy nie pozwalasz jednej osobie posiadać całej wiedzy. To jest ogromne ryzyko. Co by się stało, gdyby ta osoba zdecydowała się zrezygnować, albo dosłownie została potrącona przez autobus? Jeśli sytuacja jest taka, jak ją nakreślisz, to cała firma zniknie. Musisz oznaczyć to jako ryzyko organizacyjne, a nie problem kadrowy.

Zacznij wprowadzać innych ludzi w błąd, z panem A. lub bez niego, ponieważ już zidentyfikowałeś go jako problem.

Pamiętaj, że jeśli pan A nie pomoże w ograniczeniu ryzyka w Twojej organizacji, to on sam stanowi zagrożenie dla organizacji i trzeba nim zarządzać. Odbierz mu władzę, aby jeśli naprawdę zostanie potrącony przez autobus, to nie skończy się to dla wszystkich.

Inne odpowiedzi są całkiem świetne, ale jest jeszcze jedna dodatkowa rzecz, którą chciałbym rozważyć:

Moja osobista rada to rozważenie rozpoczęcia poszukiwania innych miejsc pracy… jeśli kierownictwo nie podjęło żadnych działań w ciągu 7 lat, nie jestem pewien, czy jest to miejsce, dla którego chciałbyś pracować w dłuższej perspektywie. Dla mnie to brzmi jak znak ostrzegawczy dla innych rodzajów problemów w firmie.

and he repeated makes bad decisions on purpose to keep the software product unstable, difficult to maintenance and troubleshoot

So why is your team leting these “bad decisions” get past design review or code review? Jeśli nie masz procesu przeglądu kodu lub nawet przeglądu projektu, postaraj się o to na dłuższą metę.

Ale do tego czasu wszystko, co musisz wiedzieć, jest w artykule Joel on Software na blogu: Getting Things Done When You’re Only a Grunt

And he has a specific callout for dealing with bozos: FILE BUGS. Per Spolsky:

As a chrząkanie, your goal is damageminimization, a.k.a. containment. W pewnym momencie, jeden z tych geniuszy spędzi dwa tygodnie pisząc trochę kodu, który jest tak niewiarygodnie zły, że nie może nigdy zadziałać. Kusisz się, by spędzić piętnaście minut, które potrzeba na przepisanie kodu od nowa. Oprzyj się pokusie. Masz świetną okazję zneutralizować tego kretyna przez kilka miesięcy. Po prostu zgłaszajcie błędy wbrew ich kodowi. Nie będą mieli innego wyjścia, jak miesiącami trzymać się z dala od niego, dopóki nie znajdziemy więcej robaków. Są to miesiące, w których nie mogą zrobić żadnych szkód nigdzie indziej.

W przeciwnym razie, jako nowy pracownik w zespole, Twoim celem powinno być rozwinięcie własnej reputacji doskonałości.

Wystarczy powiedzieć to wyraźniej niż obecne odpowiedzi…

Twój problem :

nikt nie wiedział jak go naprawić.

Twoje rozwiązanie :

• Naucz się sam go naprawić.

Tam, teraz firma nie potrzebuje już tego drugiego faceta.

Umieść to na ścianie: (Będziesz musiał zmienić niektóre nazwy i miejsca).

Kilka lat temu spędziłem tydzień na wewnętrznym kursie projektowania programów w firmie produkcyjnej w środkowo-zachodniej części Stanów Zjednoczonych. W piątkowe popołudnie było już po wszystkim. Kierownik DP, który zorganizował kurs i zapłacił za niego z budżetu, zaprosił mnie do swojego biura. “Co o tym sądzisz?” zapytał. Prosił mnie, żebym opowiedział mu o moich wrażeniach z jego operacji i jego personelu. “Całkiem niezłe”, powiedziałem. “Masz tam kilku dobrych ludzi.” Kursy projektowania programów to ciężka praca, byłem bardzo zmęczony, a doradztwo w zakresie oceny pracowników jest płatne dodatkowo. W każdym razie, wiedziałam, że on naprawdę chce mi powiedzieć swoje własne myśli.

“Co sądzisz o Fredzie?” zapytał. Wszyscy uważamy, że Fred jest genialny.“ "On jest bardzo sprytny”, powiedziałem. “Nie jest zbyt entuzjastycznie nastawiony do metod, ale dużo wie o programowaniu.” “Tak,” powiedział kierownik DP. Obrócił się w fotelu, aby stanąć naprzeciwko ogromnego schematu przyklejonego do ściany: około pięciu dużych arkuszy papieru do drukarki liniowej, może dwustu symboli, setek linii łączących. “Fred to zrobił. To jest nagromadzenie płac brutto na naszej tygodniowej liście płac. Nikt inny poza Fredem tego nie rozumie.” Jego głos spadł do czarującego ucisku. “Fred mówi mi, że nie jest pewien, czy sam to rozumie.”

“Wspaniale,” mamroczyłem z szacunkiem. Wyraziłam się jasno. Fred jako Frankenstein, Fred genialny twórca niekontrolowanego monstrum flowchart. “Ale co z Jane?” Powiedziałem. “Myślałem, że Jane jest bardzo dobra. Bardzo szybko przyswoiła sobie pomysły na projekt programu.”

“Tak,” powiedział kierownik DP. “Jane przyszła do nas z świetną reputacją. Myśleliśmy, że będzie tak samo genialna jak Fred. Ale tak naprawdę jeszcze się nie sprawdziła. Daliśmy jej kilka problemów, które naszym zdaniem będą naprawdę trudne, ale kiedy skończyła, okazało się, że nie były one wcale trudne. Większość z nich okazała się dość prosta. Nie sprawdziła się jeszcze naprawdę — jeśli widzisz o co mi chodzi?”

“Widziałem co miał na myśli.”

• Fragment książki “Software Requirements & Specifications” - Michel Jackson (Cóż, warto przeczytać).

Odpowiedź jest prosta: zwolnić go. Być może będziesz musiał wypłacić niebanalną sumę pieniędzy w krótkim czasie, aby naprawić bałagan, który narobił, ale pan A nie jest mądrzejszy niż ktokolwiek inny na świecie - ktoś inny _będzie w stanie utrzymać oprogramowanie w krótkim czasie, a na dłuższą metę uczynić je lepszym.

Jest perspektywa do rozważenia.

Firma lubi to w ten sposób. Gdyby nie 7 lat, to długo by to trwało.

Jako programiści mamy tendencję do zapominania, że nie jest naszym zadaniem pisanie dobrego czy mądrego kodu. Naszym zadaniem jest stworzenie produktu do życia. Pisanie dobrego kodu po prostu sprawia, że proces ten jest lepszy, ale możesz stworzyć całkowicie niesamowity produkt z całkowicie gównianym kodem.

Firma stoi za jego decyzjami, a nawet zatrudniła go z powrotem. Oni “lubią” go i jego sposób działania. Nie zmienisz tego, nawet jeśli w jakiś sposób uda ci się go zwolnić. Prawdopodobne jest, że wybiorą nową osobę jako “faceta” i proces zacznie się od nowa.

Prowadzenie firmy nie jest twoim zadaniem. Firma dokonała swojego wyboru. Ty musisz dokonać swojego. Ucz się od faceta (ma tę samą pracę od 7 lat, musi robić coś dobrze) albo idź dalej.

Na dobre i na złe, ani nothing, ani nikt nie jest niezastąpiony. (niektórzy mogą być bardziej niż inni, ale mimo to ) Jeśli ludzie znają rozwiązanie, mogą zacząć je odwracać.

Byłem na twoim miejscu więcej niż kilka razy w przeszłości. W najbardziej podobnej sytuacji jak twoja, “Mr. A” już dawno odszedł, jednak miałem monolityczne rozwiązanie pracujące na zapleczu firmy kablarskiej, gdzie nie miałem kodu źródłowego dla lokalnych bibliotek rozwiniętych, a na domiar złego byłem debiutantem w tej branży.

Mniej więcej zaatakowałem je w podejściu modułowym, przyglądając się istniejącemu kodowi, inżynierii odwrotnej, gdzie brakowało i pisząc moduły, które zastępowały na zmianę lepszą funkcjonalność i szybkość zadań podstawowych. Każdy moduł udoskonaliłem przed przejściem do następnego. W ciągu kilku miesięcy zabiłem poprzednią aplikację.

Bycie niezastąpionym jest przesadzone.

Radzenie sobie również z odziedziczonymi rzeczami nie jest łatwym zadaniem, może twój współpracownik robi to z bezwładności lub dlatego, że nie zna się na tym lepiej.

Z biznesowego punktu widzenia, istnieją zasadniczo dwa rozwiązania:

1. Przejście stopniowe, innymi słowy, wzięcie małego kawałka funkcjonalności, ponowne wdrożenie go do wysokiego standardu i umieszczenie go w produkcji, i kontynuować to kawałek po kawałku, aż stary system będzie mógł być całkowicie wycofany z użytku.
2. Całkowicie zbuduj nowy system, a następnie przejdź do niego, albo wszystko na raz, albo stopniowo, np. zakładając na nim nowych klientów i stopniowo przenosząc do niego starych klientów. Nowy system nie musi być tak funkcjonalny jak stary na początku; jego zaletą może być niższa cena, szybsze wsparcie, itp.

Zaletą opcji 1 jest to, że nie wymaga dużej inwestycji z góry, Twój nowy kod jest testowany stopniowo zamiast wszystkich na raz, a Ty zaczynasz dostrzegać korzyści wcześnie (ponieważ firma poświęca mniej czasu i pieniędzy na utrzymanie tych części starego systemu, które nie są już aktywne).

Wadą jest jednak to, że na strukturę nowego systemu silny wpływ może mieć struktura starego systemu, a w niektórych przypadkach naprawdę trudno jest wymienić części bardzo niechlujnego systemu. Czasami potrzebna jest odrobina kreatywności - jeśli wszystko inne zawiedzie, Twój nowy kod może symulować wciśnięcia klawiszy i kliknięcia w stary system! Ale łączenie się ze starym systemem może generować tyle pracy, że lepiej po prostu iść z opcją 2.

Tak czy inaczej, tam jest coś, co można zrobić. Pytanie brzmi, ile to będzie kosztować i ile zaoszczędzi? Próba oszacowania, że dla każdej z powyższych opcji pomoże określić, którą opcję wybrać (jeśli istnieje). Będzie to zależało od wymagań funkcjonalnych, struktury istniejącego systemu oraz gotowości firmy do wydawania pieniędzy/uzyskiwania kredytu z góry na przyszłe oszczędności.

Jako członek zespołu programistycznego Twoim zadaniem nie jest zarządzanie firmą i jej pracownikami.

Twoim zadaniem jest pisanie dobrego oprogramowania. Więc martw się o oprogramowanie, nie o ludzi.

Widzisz problemy z oprogramowaniem, a z Twojego pytania wynika, że masz kilka pomysłów na ich rozwiązanie. Przynieś te pomysły swojemu menadżerowi i walcz o nie.

“Manger, to oprogramowanie nie jest testowane i jego obecna implementacja nie jest testowalna. Sugeruję pracować nad ponownym wdrożeniem w języku, który jest bardziej testowalny, używając wzorców projektowych, które pozwalają na łatwiejsze testowanie.”

Teraz, jest bardzo prawdopodobne, że:

A. Jest to duże przedsięwzięcie, w które firma nie jest skłonna inwestować, ponieważ nie widzi potrzeby

B. Pan A będzie się spierał przeciwko tym rzeczom i będzie wysłuchiwany, ponieważ jest starszy

Jeśli tak się stanie, wtedy starałeś się dobrze wykonywać swoją pracę i zostałeś stłumiony. Czas poszukać nowej pracy.

Jeśli to się skończy, a oni cię posłuchają, zapisałeś się na tonę pracy.

Celowo trzymałem się z dala od nowoczesnych frameworków programistycznych

Może po prostu najwygodniej mu będzie z tym, co zna najlepiej?

Pracowałem w dużych firmach, których potok był mozaiką starego i zupełnie nowego kodu i gdzie pewne fragmenty kodu “po prostu działały” i nigdy nie były dotykane. Na dodatek programiści, którzy go napisali dawno już nie żyli i nikt tak naprawdę nie rozumiał jak oni działają, więc po prostu dodawali nowe funkcje, aby dostosować się do zmieniających się wymagań. Ich potok był zawsze na żywo, więc każdy duży rollout mógł mieć katastrofalne (tzn. bardzo kosztowne prace i przerwy w dostawie) konsekwencje, więc nie chcieli go zbytnio dotykać.

To zły nawyk i tworzy niezoptymalizowaną infrastrukturę, ale tak naprawdę ma swoje zalety.

Co mógłbyś zrobić, zwłaszcza jeśli masz pracować nad dużą ilością lub całym kodem: Jeśli nie ma odpowiedniej dokumentacji, albo zaproponuj jej stworzenie (jeśli wiesz, że masz odpowiednie kwalifikacje i czas), albo zapytaj, czy należy ją stworzyć, aby przyspieszyć pracę.

Powinieneś (jak już to robisz) porozmawiać ze swoim menadżerem o dostosowywaniu nowych technologii lub ulepszeń, ale oczekujesz, że nic z tego nie wyjdzie, nawet jeśli on się z tobą zgodzi.

Szanse są takie, że nikt wyżej nie dostrzega korzyści płynących z wydawania środków na ten cel, a Twoja próba może wyglądać jak ah, nowa krew myśli może zmienić świat i nauczyć nas o błędach naszych dróg.

Niestety struktury firmy opierają się nagłym zmianom, a modernizacje są kwestią stopniowego znoszenia oporu lub wdrażania go po trochu, chyba że możesz pokazać, że “rewolucyjne zmiany przyniosą złotą erę zysków finansowych bez ryzyka”.

Nawet jeśli robi to złośliwie, aby utrzymać swoją pracę, nie widzę, aby twoim obowiązkiem było zdmuchnięcie pokrywy, szczególnie jeśli twój bezpośredni przełożony jest o tym poinformowany.

Co byś zrobił? Porozmawiał z przełożonym lub bez niego z wyższą kadrą zarządzającą lub z kolegą, o którym mowa?

Widząc, że Twój przełożony zdecydował się nie zajmować tą sprawą, prawdopodobnie nie będzie chciał rozmawiać ze swoim przełożonym z Tobą lub bez Ciebie, albo już to zrobił i spotkał się tam z blokadą.

Jeśli rozmawiasz z jego przełożonymi bez niego, ryzykujesz, że go wyobcujesz.

Rozmowa z kolegą z pewnością przyczyni się do powstania bardzo złego środowiska pracy, a on z pewnością zaprzeczy wszelkim zarzutom.

Jedynym sposobem na naprawienie tego jest odebranie kontroli panu A.

Najpierw uzyskać zgodę kierownictwa.

Zrób zupełnie nowy git.

1. Importuj dobry, uzgodniony punkt wyjścia.

2. Zacznij od tego miejsca i przynieś kod dalej.

3. Nie dawaj panu A dostępu w ogóle (nawet nie mów mu, że istnieje)

4. Port Mr A. zmienia się na własne repo, albo przepisuje.

5. Pozwól Mr A. robić co chce do jego repo, bo nie będziesz go używał.

6. Dokonaj fałszywych zmian w kodzie, aby wydawało się, że jest on aktywny, jeśli chcesz ukryć przed nim swoje nowe repo.

7. Ostatecznie kod będzie na tyle daleki, że stanie się automatycznie przestarzały.

Musisz podjąć krytyczną decyzję, aby zachować lub porzucić strategię modułów. Moduły niekoniecznie są złe, musisz je synchronizować i utrzymywać w stanie gotowości do pracy.

To będzie dużo pracy, ponieważ musisz przepisać wiele istniejącego kodu.

Dodatkową korzyścią, jest to, że kod w końcu rozejdzie się na tyle daleko, że nie będzie już mógł odzyskać swojego kodu. Będzie to dla niego zupełnie obce.

Bądź świadomy, że jako osoba niezarządzająca, nie musi to być twój problem do rozwiązania (poza przestrzeganiem instrukcji dotyczących wykonywania czynności, o których zadecydowano w ramach rozwiązania).

Nigdy nie interpretuj ślepo “Chcemy, aby problem XY został rozwiązany” jako stwierdzenie “…z powodu problemu XY”.

Bądź również świadomy, że gdy już podejmiesz jakąkolwiek inicjatywę, nawet za zgodą, aby zmienić sytuację, angażujesz się w politykę firmy. W polityce firmowej nie ma czegoś takiego jak “niewinny innowator bez osobistego programu, za który nie możemy ponosić odpowiedzialności za niezamierzone konsekwencje”.

Jeśli to zrobisz, zrób to _z osobistym programem, a konsekwencje poniesiesz tak czy inaczej.

@

Dla niego, aby pozostać na pozycji tak długo pokazuje, że biznes jest świadomie lub nieświadomie stosuje Hanlon’s razor :

Nigdy nie przypisać złośliwości, co jest odpowiednio wyjaśnione przez głupotę.

Brzmi jak bardzo trudno znaleźć rzeczywiste przypadki złośliwości, tylko rzeczy, które nie wyszły tak dobrze w czasie. Faktycznie to wygląda na to, że pan A pozwolił ludziom próbować zmieniać rzeczy, a następnie bohatersko je naprawiać, kiedy te poszły źle.

Należy również wziąć pod uwagę, że pan A może cierpieć na efekt Dunning-Krugera , w tym że nie jest w stanie dostrzec, że to co robi jest złe.

Może być tak, że kiedyś był dobry, ale przestał się uczyć i przestał próbować. Kto wie. Co musisz wziąć pod uwagę jako pierwszą zasadę, jest to, że bez względu na to, jak bardzo jest irytujący, masz do czynienia z nim, jakby nie był złośliwym agentem.

Twoje pytanie wydaje się wychodzić z założenia, że on jest tuż po bezpieczeństwie pracy i odmawia aktualizacji rzeczy do osadzenia tego. Możesz mieć rację, ale nie możesz mieć z nim do czynienia na tej podstawie.

Jestem pewien, że niektóre z twoich jasnych pomysłów wymyślić opór “próbowaliśmy go raz i to nie działało z powodu X.” Z biznesowego punktu widzenia ma to sens, podjęli oni ryzyko, że coś nie zadziała, więc dlaczego mieliby próbować ponownie.

Podajesz jako swój cel.

Chcę, aby oprogramowanie było nowoczesne, łatwe w utrzymaniu i stabilne.

Rozbijmy to według potrzeb biznesowych

1. Nowoczesne

W nowoczesnym nie ma żadnej ukrytej wartości biznesowej. W każdym razie jest to sporne. Ty mówisz Java 8, inni powiedzieliby, że Rust lub Golag są nowoczesne. Tak długo jak system jest obsługiwany, nie ma wielkiej wartości w jego aktualizacji.

2. Utrzymywalny

To również może być trudne do zakwestionowania. Pan A będzie twierdził, że jest to możliwe do utrzymania, ponieważ on to utrzymuje. Musiałbyś argumentować, że koszty utrzymania drastycznie by się zmniejszyły, aby uzasadnić hurtową zmianę frameworka.

3. Stable

Mówisz, że chcesz, aby system był HA, ale mówisz także, że to

oprogramowanie monitoruje zdarzenia, robi na nich pewne operacje, a następnie podejmuje odpowiednie działania.

Który nie brzmi, jakby potrzebował HA.

Więc co robić?

Twój system brzmi jak wielka kula błota zdefiniowana przez

Duża kula błota jest przypadkowo zbudowana, rozległa, niechlujna, przewód-taśma-i-baling-wire, spaghetti-code dżungla. Systemy te wykazują wyraźne oznaki nieuregulowanego wzrostu i powtarzających się, celowych napraw.

Poradzenie sobie z tą głową, przy braku współpracy dewelopera zarządzającego tym będzie bardzo frustrujące i prawdopodobnie bezowocne. Brzmi to tak, jakby wielu innych próbowało i zawiodło.

Co możesz zrobić, to zacząć go omijać:

• Jeśli nie możesz zrobić systemu HA, to użyj systemu magistrali komunikacyjnej lub takiego, który przechwytuje wiadomości w ten sposób, że jeśli system pójdzie w dół, nie stracisz danych.
• Jeśli nie możesz napisać testów jednostkowych, napisz testy systemu. Nie są one tak schludne, ale pozwolą na przeprowadzenie testów na systemie.
• Następnym razem, gdy konieczne będzie wykonanie jakiejś akcji, należy zacząć budować niezależny podsystem, który będzie mógł słuchać magistrali wiadomości i wykonywać swoje własne działania.
• Jeśli możesz zacząć wpływać na pewne efekty (np. enkapsulację podejmowanych działań), umieść je w podsystemie.

Istnieje jakiś argument, aby wspierać monolit majectic ponad microservices , ale zakłada, że monolit jest dobrze skonstruowany. W twoim przypadku system może być w porządku jako dobrze skonstruowany monolit, ale jeśli nie jest dobrze skonstruowany, musisz go rozdzielić. Ten wygląda jak dobry artykuł na początek:

Bardziej powszechnym podejściem jest rozpoczęcie od monolitu i stopniowe odklejanie mikrousług na krawędziach. Takie podejście może pozostawić spory monolit w sercu architektury mikroserwisu, ale większość nowych rozwiązań pojawia się w mikroserwisach, podczas gdy monolit jest stosunkowo cichy.

Jednak ważne jest, aby grać razem z panem A, nie mów mu, że wymieniasz system, ale że “poprawiasz niezawodność” lub dodajesz redundancję. Jeśli zaatakujesz to, co on zrobił, utrudni ci osiągnięcie twoich celów.

Możesz dostać łuk, że robisz system bardziej skomplikowany. To prawda, ale jest to konieczne, jeśli masz zamiar iść do przodu w dłuższej perspektywie.

Dlaczego wszyscy tak bardzo chcą zwolnić pana A? Chyba nie zrobił tu nic złego. Rozwój oprogramowania nie polega na tworzeniu nowych rzeczy przy użyciu fajnych narzędzi, czy frameworków. Chodzi o stworzenie stabilnej rzeczy, która po prostu “działa”. Twoja firma kocha Pana A i jest zadowolona z jego pracy.

Celowo trzymane z dala od nowoczesnych frameworków do tworzenia oprogramowania

Twój system jest w stabilnym stanie, więc dlaczego zespół musi w ogóle korzystać z nowoczesnych frameworków do tworzenia oprogramowania takich jak Scrum czy agile?

Pisana podstawowa logika biznesowa w językach, które nie mogą być testowane

Czy istnieje wymóg, aby podstawowa logika biznesowa była automatycznie testowana?

Zarcharchitekturyzowane komponenty oprogramowania w 30 modułach, aby dodać złożoność i problemy z certyfikacją wersji

Ile więcej kosztowała Twoja firma ta implementacja?

Zaprojektuj ją w sposób nieskalowalny, zapewniając brak możliwości HA (wysoka dostępność)

Wciąż to samo pytanie - ile więcej kosztowała Twoja firma ta implementacja?

Moim zdaniem wszystkie rzeczy, które tutaj piszesz, to tylko Twoja skarga na niego. Gdyby zrobił wiele “strasznych” rzeczy, sam system by się stopił w pierwszym roku i nie mógłby tak długo zostać w Twojej firmie.

Po prostu, firma musi zaoferować mu hojną podwyżkę, aby udokumentować aktualny stan oprogramowania i całą wiedzę, która nie jest dokumentowana, a następnie go zwolnić. Alternatywnie, zatrudniają firmę konsultingową do dokumentowania wszystkiego, a on zobaczy pismo na ścianie i w końcu odejdzie.