Czy posiadanie tylko jednego programisty w zespole niesie za sobą ryzyko?

Tworząc nowy produkt, pewnie na początku skusisz się na zatrudnienie tylko i wyłącznie jednego programisty. Tworzenie oprogramowania jest kosztowne i może lepiej to zrobić nieco taniej. Oczywiście ta taktyka jest zrozumiała i na pewnym etapie może faktycznie nieco obniżyć koszty. ale czy zawsze?

Czy posiadanie tylko jednego programisty w zespole niesie za sobą ryzyko?
Photo by ThisIsEngineering from Pexels

Tworząc nowy produkt, pewnie na początku skusisz się na zatrudnienie tylko i wyłącznie jednego programisty. W końcu tworzenie oprogramowania jest kosztowne i może lepiej to zrobić nieco taniej. Oczywiście ta taktyka jest zrozumiała i na pewnym (początkowym) etapie może faktycznie nieco obniżyć koszty.

Co jednak może się stać, jeśli ten stan rzeczy będzie trwał zbyt długo?

Powiedzmy, że aplikacja okazała się sukcesem - są pierwsi klienci i wszystko zaczyna wyglądać świetnie. Jednak okazuje się, że nasz programista składa wypowiedzenie lub kończy współprace. Co teraz?

Niby prosta sprawa - rekrutujemy i zatrudniamy nowego człowieka.

I tu trafiamy na potencjalny problem numer 1:

Czas trwania rekrutacji nowego programisty

Przy obecnym stanie rynku, może to być spory problem. Jeśli osoba, która pracuje dla nas obecnie, ma tylko miesiąc wypowiedzenia, to może się okazać, że nie zdążymy zatrudnić nikogo nowego. A kto przekaże wiedzę? W końcu mamy tylko jedną osobę, która zna system i wie czemu  zostały podjęte pewne decyzje

Jakość wytworzonego oprogramowania

Drugą rzeczą, która może okazać się problemem w kontekście dalszej pracy nad projektem może być nieodpowiednia jakość rozwiązania stworzonego przez pojedynczego programistę. Z doświadczenia wiem, że jeśli programista pracuje sam, to dużo trudniej jest mu utrzymać najlepszą możliwą jakość. Techniki, które można efektywnie stosować do zapewnienia, że oprogramowanie, które powstaje jest na odpowiednim poziomie, mogą zostać zastosowane w większości w minimum 2 osobowym zespole, dlatego długi czasy wytwarzania oprogramowania z pomocą tylko i wyłącznie jednej osoby, może doprowadzić do niskiej jakości, która może być ciężka do dalszego developmentu, przez nowego programistę

Utrudnione skalowanie aplikacji

jest to poniekąd związane z poprzednim punktem. Jeśli programista, który tworzy kod sam, robi to z gorszą jakością i końcowo może doprowadzić, do sytuacji, gdzie dalszy rozwój oprogramowania będzie na tyle kosztowny, że lepiej będzie zacząć wszystko od nowa. Już kilka razy spotkałem się z taką sytuacją, że projekt prowadzony przez jednego developera, był doprowadzony do takiego stanu, że dalsze jego rozwijanie nie miało najmniejszego sensu. Trzeba było od nowa przepisywać znaczne części i wiązało się to ze znacznie większymi kosztami, niż opłacanie kolejnego programisty.

Możliwość wmuszenia stawek powyżej średniej rynkowej

Świadomy swojej wartości programista, który spędził sporo czasu w projekcie może wykorzystać sytuacje i z racji braku możliwości szybkiego zastąpienia go, może zarządzać stawki ponad jego poziom lub ponad wartości rynkowe. To powoduje, że wcześniejszy argument o tańszym wytworzeniu programu może nie być dalej prawdą, bo pensja wzrośnie do bardzo wysokiego poziomu.

A więc odpowiedź na pytanie, czy posiadanie jednego deva w projekcie może nieść za sobą ryzyko jest prosta. Może, uzależnianie się od tylko jednej osoby jest podobne do zjawiska vendor lockingu i może znacząco podnieść koszty wytwarzania oprogramowania.