Jak upewnić się, że Twoja firma nie zejdzie pod wodę, jeśli programiści wygrają na loterii [zamknięte]

Mam pod sobą kilku programistów, wszyscy świetnie sobie radzą i oczywiście są bardzo inteligentni. Dziękuję Ci bardzo.

Problem polega jednak na tym, że każdy z nich jest odpowiedzialny za jeden główny obszar, o którym nikt w zespole nie ma najmniejszego pojęcia, co to jest. Oznacza to, że jeśli ktoś z nich zostanie zabrany, moja firma jako firma nie żyje, ponieważ nie można ich wymienić.

Zastanawiam się nad wprowadzeniem nowych programistów na ich wypadek, na wypadek, gdyby zostali potrąceni przez autobus, zrezygnowali czy cokolwiek innego. Ale obawiam się, że

1. Starzy programiści mogą aktywnie opierać się idei transferu wiedzy, obawiając się, że tworzenie kopii zapasowych może obniżyć ich wartość.
2. Nie mam systemu ułatwiającego transfer technologii między różnymi programistami, więc nawet jeśli ich poproszę, nie mam gwarancji, że zrobią to poprawnie.

Moje pytanie brzmi,

1. Jak przekazać to starym programistom, aby się zgodzili
2. Z jakich systemów korzystasz, aby ułatwić tego rodzaju „tworzenie kopii zapasowych”? Rozumiem, że możesz dokonać przeglądu kodu, ale czy istnieje prosty sposób, aby to zrobić? Myślę, że nie jesteśmy gotowi na pełne sprawdzenie, zameldowanie przez sprawdzenie kodu odprawy.

Jak przekazać to starym programistom, aby się zgodzili

Przedstaw im problem otwarcie, oczywiście w taki sposób, aby nie postrzegali go jako zagrożenia, a raczej jako okazję do poprawy pracy zespołu i projektu. Np. „Chciałbym, aby inni wiedzieli, co wiesz na wypadek, gdybyś został zwolniony” jest oczywiście niewłaściwym podejściem :-) „Chciałbym zapewnić sprawne działanie projektu, nawet jeśli niektórzy z was wyjeżdżają na wakacje lub chorują „ jest znacznie lepszy.

Zwykle sami programiści sami doświadczają problemów za każdym razem, gdy niektórzy z nich są na wakacjach i muszą się przed nim ukryć. Co więcej, dobrzy programiści czują odpowiedzialność za projekt, nad którym pracują, więc prawdopodobnie zgodzą się z tym pomysłem. Daj im jednak czas na dyskusję i (miejmy nadzieję) zaangażuj się w ten pomysł. Pozwól im także wypowiedzieć się na temat tego, jak i z kim dzielić się wiedzą w zespole. Może się okazać, że Joe czuje się dobrze, pracując (i dzieląc się swoją wiedzą) z Jimem, ale nie z Jackiem itp.

Z jakich systemów korzystasz, aby ułatwić tego rodzaju „tworzenie kopii zapasowych”? Rozumiem, że możesz dokonać przeglądu kodu, ale czy istnieje prosty sposób, aby to zrobić? Myślę, że nie jesteśmy gotowi na pełne sprawdzenie, zameldowanie przez sprawdzenie kodu odprawy.

W naszym zespole, oprócz recenzji kodu / projektu, używamy

• Rotacja zadań i obszarów odpowiedzialności między członkami zespołu (każdy z nas ma swoje główne obszary odpowiedzialności, ale od czasu do czasu wykonujemy zadania w obszarze lepiej znanym przez innego członka zespołu)
• Sesje bezpośredniego transferu wiedzy (zwykle gdy wymagają tego powyższe zadania, ale także zanim ktoś opuści zespół)
• Zespół / projekt wiki

Przegląd kodu sam w sobie może nie wystarczyć, ponieważ w wielu obszarach programiści zwykle wiedzą o wiele więcej niż to, co można bezpośrednio odczytać z kodu. Innymi słowy, istnieje również model domeny . Możesz przeczytać, co faktycznie robi kod, ale bez modelu nie będziesz wiedział, dlaczego .

Jednym ze sposobów motywowania ich do dzielenia się wiedzą byłoby poproszenie ich o krótką prezentację swojej pracy innym osobom. Programiści zwykle są dumni ze swojej pracy, a to byłaby okazja, aby się tym pochwalić. Prezentacja to dobra okazja, aby pokazać niektóre dziwactwa rzadko znane przez osoby z zewnątrz.

A może po prostu bądź otwarty i powiedz wszystkim, że wszyscy musisz wymyślić schemat dzielenia się wiedzą na wypadek, gdyby ktoś został potrącony przez autobus. Nie uważam tego za nierozsądne. Obecnie dzieje się to w mojej firmie i chociaż niektórzy są na to defensywni, wiedzą, że należy to zrobić.

Może mogliby pracować parami nad niektórymi rzeczami, jeśli mają charakter dociekliwy, nie powinno być problemu.

Uaktualnienie wewnętrznej dokumentacji oprogramowania powinno być pierwszym krokiem, zanim zaczniesz zatrudniać nowych ludzi. Jasne, oznacza to, że twoi cenni programiści spędzą trochę czasu z narzędziami Office i UML zamiast IDE, ale myślę, że i tak warto.

Gdy masz aktualną dokumentację, możesz pozwolić swoim programistom sprawdzić ją, aby upewnić się, że wszyscy rozumieją, co napisali inni. Nadal nie ma potrzeby nowych ludzi.

Następnie możesz rozważyć zatrudnienie nowych osób. Lub nie, w zależności od obciążenia pracą w Twojej firmie.

Jeśli jesteś w dużej firmie, możesz zadzwonić do HR i porozmawiać o tym problemie. Uwierzcie, faceci z księgowości mają ten sam problem, jeśli autobus trafi kluczowego personelu. Marketingowcy będą mieli również wiele problemów, jeśli kluczowy sprzedawca stanie się zombie w trakcie ważnych negocjacji - zdarza się to często, a przynajmniej tak mi powiedziano.

Uważam, że poprawnym językiem HR jest planowanie sukcesji . Twoja firma może mieć już zasady i ramy postępowania w tym zakresie.

Jedno miejsce, w którym pracowałem, miało ten sam problem. To, co zrobili, to zatrudnienie jednego młodszego programisty do współpracy z każdym z nich. Stworzyli małe 2-osobowe zespoły, które wspólnie pracowały nad projektami. Co kilka miesięcy lub projektów obracali młodszych programistów między zespołami. W ten sposób starsi programiści pozostali ekspertami merytorycznymi, ale młodsi programiści zaczęli dobrze rozumieć wszystkie systemy i sposób ich współpracy. Dodatkowo dzięki projektom podwojenia wielkości zespołu wykonano szybciej.

W przypadku większych projektów, które się pojawiły, programiści byli czasem proszeni o działanie jako młodszy programista w innej części systemu na czas trwania projektu, aby mogli zacząć uczyć się innych systemów.

Kluczem do sukcesu było szanowanie wiedzy i stażu pracy istniejących programistów przy jednoczesnym powiększaniu i powiększaniu zespołu. To był powolny proces, ale z czasem działało dobrze.

Jedną z rzeczy, która sprawia, że ​​udane projekty open source są tak skuteczne, jest brak „własności” kodu. Rozumiem przez to, że nikt nie jest jedynym opiekunem obszaru aplikacji - każdy może i jest zachęcany do wniesienia wkładu do dowolnej części aplikacji. W to mocno wierzę.

To, co chcesz zrobić, to wyjaśnić, że to, co się dzieje, szkodzi zespołowi, który masz teraz. Oto punkty, które chcesz przejść, a najlepiej w tej kolejności:

• Nie mogę uwolnić cię do pracy nad innymi fajnymi rzeczami schodzącymi na szczupaka, jeśli tylko ty wiesz, jak to działa.
• My chcemy , aby być w stanie podjąć dobre wakacje, ale nie może sobie pozwolić, bo nikt inny nie może robić to, co robisz.
• Nieprzyjemnym jest fakt, że ludzie zmieniają pracę, ponieważ nie są zadowoleni z obecnej pozycji, nie chcemy cię stracić, ponieważ czujesz się uwięziony w obszarze, w którym pracujesz.

Osobiście musiałem poradzić sobie z odejściem współpracownika. Chociaż nie było żadnych silosów informacyjnych, strata wciąż mocno uderzyła. Szanse na to są znacznie niższe niż trzeci punkt powyżej.

Po przedstawieniu sprawy poproś o pomoc, aby uzyskać pomysły na rozwiązanie problemu. Oczywiście przyjdź z własnym. Ich pomysły pomogą im uświadomić sobie, że są częścią zespołu i są potrzebne nie tylko do ich specjalizacji. Być może Jane może być zainteresowana tym, co robi Joe, ale czuje się trochę zastraszona. Wiedząc, że może to sprawić, że transfer wiedzy będzie przyjemniejszy. Niektóre rzeczy, które chcesz zrobić, to:

• Przećwicz obecny zespół. W krótkim okresie możesz stracić trochę wydajności, ale w jednym rogu aplikacji można wyciągnąć pewne wnioski, które można zastosować w innych częściach aplikacji. Niech Jane i Joe pracują przez jakiś czas nad swoim projektem.
• Wspieraj kulturę dzielenia się wiedzą. Firma, w której pracowałem, miała program „rozmowy na temat technologii brązowej torby”. Każdy może przedstawić dowolny zatwierdzony temat (zwykle przedstawiający technologię lub procesy oprogramowania). Firma przygotowała lunch, a prezenter otrzymał kilkaset dolarów za ich wysiłek.
• Mentoring powinien być sposobem na życie. Celem mentorowania innych ludzi jest uwolnienie Cię od robienia nowych rzeczy i uczynienie Cię jeszcze bardziej wartościowym dla firmy.
• Znajdź sposoby na przekroczenie granic silosu informacyjnego bez rangi. Im więcej radości sprawisz, tym będzie mniej groźny. Jeśli ludzie w twoim zespole są tak dobrzy, jak mówisz, prawdopodobnie nie są do końca zadowoleni z tego, jak są rzeczy. Będziesz musiał ocenić, czy zespół sobie z tym poradzi, ale możesz mieć tydzień „wybierzmy tak i tak”. Zawsze zaczynaj od siebie tutaj. Chodzi o to, aby zwrócić uwagę wszystkich na to, jakie są obowiązki „takich a takich”, i jak mogą rozwiązać problemy, które mają lepiej. Tak długo, jak zaczniesz od szyi na linii, będą mieli pomysł, że nikt nie przyjmie ich pracy

Ogólnie staraj się wywrzeć na nich wrażenie, że chcesz sprawić, by praca była przyjemniejsza i potrzebujesz do tego ich pomocy.

Stażyści mogą być dobrym pomysłem, będą bezpośrednimi podwładnymi dla obecnych programistów, więc nie poczują się zagrożeni.

W miarę rozwoju firmy będziesz potrzebować zarówno starych programistów, jak i tych, którzy zrobili to po stażu.

Myślę, że to może zadziałać.

Zasadniczo, gdy jakiś menedżer nagle zaczyna dbać o dokumentację i planowanie sukcesji, jest to silny znak ostrzegawczy, że programiści zostaną zwolnieni lub zwolnieni. Jest to takie odejście od typowych zachowań menedżerskich i obaw, że wywołuje wszelkiego rodzaju sygnały ostrzegawcze u programistów.

Każdemu poleca się udokumentowanie wszystkich procedur i procesów

Poziom 3 „ Znaki ostrzegawcze przed zgubą firmy ”.

Alternatywnie, jeden esej sugeruje, że zachęcamy do kultury „ up or out ”, chociaż kontrargumentem jest to, że bardzo niewiele firm ma techniczną drabinę kariery, która w jakikolwiek sposób przypomina spektrum finansowe i energetyczne, które (błędna) drabina kariery menedżerskiej zawiera.

Opierając się na koncepcji pełnej dokumentacji, którą @ammoQ rozpoczął w swojej odpowiedzi ...

Dobry menedżer pracuje nad rozwijaniem umiejętności swoich bezpośrednich raportów, tak aby każdy z raportów mógł je zastąpić. Spraw, aby programiści zrozumieli, że pracownik, który zapewnia pełną przejrzystość swojej pracy, jest cenniejszy niż ten, który ukrywa całą swoją pracę. Gdyby „tajny” deweloper zmarł dziś, odzyskanie utraconej wiedzy byłoby ogromną odpowiedzialnością dla firmy. Gdyby pracownik „ujawnienia” zmarł dzisiaj, firma nadal byłaby w stracie, ale byłoby to mniej katastrofalne. Dlatego pracownik „pełnego ujawnienia” ma większą wartość.

Każdy pracownik, który stara się zachować ukrytą wiedzę w celu uniezależnienia się od zwolnienia, również staje się odporny na awans. Nie możesz przenieść dewelopera na bardziej wymagającą i satysfakcjonującą pozycję, jeśli nie ma nikogo, kto mógłby wykonać codzienne zadania, które są dla niego ciężkie. Jeśli przyziemne zadania są w pełni udokumentowane i w pełni ujawnione, możesz zatrudnić nowego młodszego programistę, aby wypełnić i awansować poprzedniego programistę na wyższe stanowisko.

Oznacza to, że Ty również musisz udokumentować swoje działania i zapewnić szkolenie każdemu z twoich bezpośrednich raportów. W ten sposób, jeśli jesteś zmarł dzisiaj, jeden z nich mógł wypełnić dla ciebie aż zastępstwo w pełnym wymiarze czasu został znaleziony.

Zanim zacznę wprowadzać nowych programistów, poprosiłbym każdego z nich o pomoc w stworzeniu własnego udokumentowanego dziedzictwa.

Albo z wiki, albo z 3-dzwonkową biblią dokumentów na temat każdego aspektu ich pracy.

Lub jeśli chcesz naprawdę szczegółowej i dokładnej dokumentacji, zatrudnij pisarza technicznego, aby przesłuchał każdego programistę, a następnie utwórz dokumentację wszystkiego, każdy robi to codziennie, co tydzień, co miesiąc, co rok.

Następnie utwórz wersję wiki, którą twój programista może aktualizować / edytować / uczestniczyć / komentować.

Następnie masz system, który z czasem będzie się rozwijał i będzie ulepszoną krzywą uczenia się dla każdego nowego programisty.

Również szczerze mówiąc, nie jest rozsądne, aby programista utknął w jednym rdzeniu, naprawdę opłaca się trenować, pracować między rdzeniami.

Następnie możesz skorzystać z istniejącego personelu, gdy 1 osoba bierze urlop lub coś w tym rodzaju.

Za każdym razem, gdy jeden z programistów jest chory, zadzwoń do niego wielokrotnie z pytaniami i problemami.

Za każdym razem, gdy jeden z programistów jest na wakacjach, zadzwoń do niego wielokrotnie z pytaniami i problemami.

Wkrótce zdadzą sobie sprawę, że lepiej zarówno dla nich, jak i dla firmy, nie mieć osób odpowiedzialnych za kluczowe obszary.

Nikt nie chce zostać potrącony przez autobus, ale nie chce też przejmować czyjegoś projektu w krótkim czasie i utrzymywać swój projekt. Wtedy wszyscy ryzykują, że przestaną działać.

Jeśli rozwijasz się w silosach, musisz zacząć przenosić ludzi z jednego projektu do drugiego. Zacznij od dokumentacji, przeglądu kodu lub naprawienia prostego błędu. Wszelkie drobne akty ochrony / terytorialności kodu powinny zostać rozwiązane, zanim wymknie się to zbyt daleko spod kontroli.

Posiadanie samotnego specjalisty od kodu jest iluzją wydajności.

Czy ktoś chciał kiedyś pojechać na wakacje?

Wiele innych firm upadło z powodu głupich błędów kierownictwa. Nie rozbijesz się i nie spalisz, jeśli jeden lub dwóch inżynierów odejdzie, będziesz musiał tylko trochę popracować. Sheesh, zarządzam zespołem offshore, który co kwartał traci kogoś. Zacznij przenosić zadania. Dzisiaj.