Stary programista zniknął. O zatrudnienie innego programisty. Jak do tego podejść? [Zamknięte]

Po ponad roku pracy nad projektem sieci społecznościowej dla mnie przy użyciu WordPress i BuddyPress mój programista zniknął, mimo że zarabiał co tydzień przez cały okres. Tak, nie jest martwy, ponieważ użyłem modułu do śledzenia wiadomości e-mail, aby potwierdzić i zobaczyć, jak otwiera moje e-maile, ale nie odpowiada. Wygląda na to, że dostał inną pracę. Zastanawiam się, dlaczego po prostu nie mógł tego powiedzieć. I nawet wypłaciłem mu zaliczkę za pracę, której nie wykonał.

Problem polega na tym, że nigdy nie prosiłem o pełną dokumentację dla większości funkcji, które napisał. I było WIELE funkcji dla tego ponad 1-letniego okresu, a niektóre z nich mają błędy, których wciąż nie naprawił. Teraz wszystko wydaje się mylące.

Jaka powinna być teraz pierwsza rzecz? Jak postępować?

Myślę, że pierwszą rzeczą do zrobienia będzie zdobycie innego programisty, ale chcę zacząć od właściwej stopy, dokumentując cały bieżący kod, aby każdy programista mógł pracować bezproblemowo ze wszystkimi funkcjami.

Czy to pierwsza rzecz, którą powinienem zrobić? Jeśli tak, jak mam to zrobić?

Jaki jest standardowy typ dokumentacji wymagany dla czegoś takiego? Czy mogę uzyskać programistę, który wykona dokumentację dla wszystkich kodów i naprawi błędy lub czy dokumentacja nie jest naprawdę ważna?

Poza tym, czy uważasz, że znalezienie innego „indywidualnego” programisty jest lepsze, czy też firma, która ma programistów pracujących dla nich, tak że jeśli programista przypisany do mojego projektu zniknie, inny może go zastąpić, bez mojego udziału? Wydaje mi się, że takie podejście powinienem przyjąć na początku.

W oparciu o interakcję, którą mieliśmy w komentarzach, założę, że nie odepchnąłeś swojego jedynego programisty z powodu rzeczy osobistych. Opierając się na tej rozmowie, jeszcze raz zgadnę, że to niepowodzenie jest nadal w większości obowiązkami jako menedżera ds. Zatrudnienia. Jak już wspomniałeś, nie masz wcale doświadczenia z programistami, ale w jaki sposób decydujesz, jak je zatrudnić?

Wygląda na to, że dałeś z siebie wszystko, ale zatrudniłeś kogoś, kto po prostu nie mógł znieść skali tego projektu, zbudował chwiejny fundament, który rozpadł się pod nim, a potem po prostu odszedł. Niestety, różnica między deweloperami a przedsiębiorcami polega na tym, że ci pierwsi otrzymują wynagrodzenie za godzinę / pensję, ale mogą zdecydować się przyjść i odejść, jak chcą. Otrzymał zapłatę za przepracowane godziny i odszedł, kiedy postanowił nie otrzymywać już zapłaty. Nic nie możesz na to poradzić.

Co teraz? Wygląda na to, że zacząłeś podążać ścieżką zastępowania ludzi procesami. Gdybyś tylko miał wystarczającą dokumentację, ludzie mogliby odejść, a inni mogliby rozpocząć tam, gdzie przerwali. IMO, które nie działa, a jeśli działa, nadal będzie znacznie droższe niż posiadanie niezawodnego zespołu stałych pracowników. Kierownictwo w różnych firmach w ciągu ostatnich 30 lat próbowało zastąpić ludzi wystarczającą dokumentacją (w tym moją ostatnią pracą) i za każdym razem kończyło się to niepowodzeniem. Dlatego zdecydowałem się zmienić pracę, a teraz utknęli ze swoimi przestarzałymi i nigdy dokładnymi dokumentami, a ja mam czas w moim nowym startupie.

Gdybym był, chciałbym znaleźć odpowiednią osobę z wystarczającymi umiejętnościami i doświadczeniem, aby podnieść ten projekt i doprowadzić go do końca. Obejmuje to nie tylko umiejętności kodowania, ale także projektowanie, architekturę, a także podstawowe zarządzanie projektami. Nie próbuj określać, w jaki sposób wykonuje swoją pracę ani ile dokumentów musi przedstawić. Skoncentruj się na znalezieniu właściwej osoby i przygotuj się na odpowiednią zapłatę. Kiedy go znajdziesz, upewnij się, że Twoim zadaniem jest wspierać go i usuwać przeszkody z jego drogi, a nie monitorować / zarządzać. Nie sugeruję, że robiłeś to wcześniej, ale wiem, że wielu menedżerów to robi, a to po prostu przynosi efekty.

Porozmawiaj z innymi przedsiębiorcami, być może z doświadczeniem w inżynierii oprogramowania. Przeczytaj te fora i znajdź zestaw pytań, które możesz zadać potencjalnemu pracownikowi. Przedstaw problem i zapytaj, jakie byłoby podejście. Jeśli jest właściwym facetem (i zakładając, że nie widział tej strony), powinien być w stanie zasugerować wiele rzeczy, które inne osoby już zasugerowały w zakresie tego, co należy zrobić w Twojej firmie, gdy zaczniesz zdrowieć. Poproś go, aby określił plan od momentu zatrudnienia do momentu, gdy Twoja wersja 1.0 zostanie wysłana. Jak on cię tam doprowadzi? Poproś o pomoc podczas rozmowy z taką osobą.

Tylko kilka moich własnych myśli: śledzenie błędów jest koniecznością (Jira kosztuje 10 USD za zespół do 10 osób). Kontrola źródła jest koniecznością (git jest darmowy. Perforce kosztuje orzeszki ziemne dla zespołu do 5 osób). Twój kod jest twoją dokumentacją. Nie twoje pisemne dokumenty słowne. Powinien przejrzeć kod i zachować to, co jest możliwe do odzyskania; wyrzuć resztę i skup się na pisaniu łatwego do utrzymania i czytelnego kodu. Zapisz dokumentację dla kilku dokumentów projektowych na wysokim poziomie i kilku stron. Musi znać technologię, nad którą pracujesz. Nie zatrudniaj kogoś z dobrymi intencjami; nie możesz sobie pozwolić na to, aby uczyły się na swój czas. Zapytaj ich, jakie inne projekty wykonali (niestety ty lub ktoś, kogo znajdziesz, może nadążyć za technicznym aspektem rzeczy). Szukasz kogoś z wystarczającym doświadczeniem, ale jednocześnie nie za bardzo, że ta iskra podniecenia już się wypaliła. Znajdź kogoś, kto jest głodny, aby wywrzeć wpływ. Metodologia, którą proponuje lub stosuje, powinna umożliwiać ci regularne obserwowanie pracy (okresy jednego lub dwóch tygodni) oraz natychmiastowe przekazywanie informacji zwrotnych. Nie zatrudniaj nikogo, kto mówi, że będzie gotowy dokładnie za 7,4 miesiąca, dam ci znać, kiedy to się skończy.

Powodzenia

To dziwna sytuacja i jestem pewien, że nie opowiadasz całej historii. Pracowałem z wieloma ludźmi, z których niektórzy wyjechali z różnych powodów (ja jestem ich kolegą), ale nie próbuj nam mówić, że wszystko było super dobre i pewnego dnia po prostu nie miałem kontaktu.

Ale to nie problem. Przynajmniej już nie; powinieneś uczyć się na swoim błędzie i starać się go nie powtarzać w przyszłości. I tak, zdecydowanie sugeruję, że 50% jest twoją winą za jego / jej odejście.

Teraz o rozwiązaniu bieżącego problemu:

1. Spróbuj skontaktować się z programistą. Czyta twój e-mail - zaoferuj mu pieniądze na dokumentację / naprawienie najważniejszych błędów. Nikt inny nie będzie w stanie naprawić tych szybciej niż on. Nie działa? Spróbuj znaleźć, gdzie on pracuje, skontaktuj się z tą firmą i opowiedz swoją historię. Dobra firma nie zatrudni osoby, która mogłaby zrobić dla nich to samo. Przynajmniej powiedzą mu, żeby dokończył dla ciebie dokumentację.

   UWAGA: nie chcesz tej osoby z powrotem, potrzebujesz tylko gotowej dokumentacji

2. Przygotuj się, że Twoja roczna praca będzie nieważna. Mógł uciec, kiedy poprosiłeś o wyniki, i wiedział, że nie jest w stanie tego zapewnić. Możliwe, że kod jest pełen włamań, brudnej implementacji i ogólnie niskiej jakości. Nawet jeśli wróci - prawdopodobnie nie będzie miał umiejętności ani nawet czasu, aby zrobić to dobrze.

3. Poszukaj innej osoby. Musi znać te same technologie (język programowania, frameworki itp.). Jeśli jakość kodu jest dobra - mógłby kontynuować, jeśli nie, będzie mógł go refaktoryzować. Tak, refaktoryzacja wymaga czasu bez implementacji nowych funkcji, ale umożliwia utrzymanie kodu i tego właśnie potrzebujesz. Co więcej, osoba, która może zmienić zły kod, jest naprawdę dobrym programistą, trzymaj się go.

   UWAGA: głupio jest płacić z góry. Cała idea wynagrodzenia polega na płaceniu za wykonaną pracę. Nie za złożoną obietnicę :)

4. Twórz listy. W twoim najlepszym interesie jest mieć plan. Specyfikacja techniczna, która raz przeczytana, pozwoli nowemu programistowi zrozumieć zadanie i kamienie milowe. Posiadaj co najmniej trzy ważne dokumenty:

   • Ogólny opis projektu - dokument, który pozwoli nawet nie-programistom dowiedzieć się, o czym jest projekt.

   • Oś czasu - w jakiej części i kiedy spodziewasz się być gotowy? Co już zostało zrobione?

   • Specyfikacja techniczna - jest długa. Jest to dokument, który programista chce przeczytać. Podziel go na logiczne części i opisz tak szczegółowo, jak to możliwe, funkcje i przepływ pracy tej konkretnej części.

Współpraca z firmami nie jest wcale taka dobra; twoje szanse się nie poprawią. I przepłacisz 10 razy, jeśli zatrudnisz tylko jednego programistę. Jeśli masz mały zespół, powiedzmy 3-5 osób, po prostu zatrudnij programistę, który chce być liderem zespołu. Wykona znacznie lepszą robotę, kierując zespołem.

Dokumentujesz kod później przez innego programistę? Z mojego własnego doświadczenia i opinii wynika, że ​​nie należy podążać tą drogą.

Bez bardziej szczegółowej wiedzy na temat jakości tej bazy kodu, moim zdaniem najlepszym rozwiązaniem jest zatrudnienie nowego programisty, który naprawi błędy, utrzyma i ewentualnie dokona wymaganych modyfikacji.

Opinia ta ma kluczowe znaczenie dla ewentualnych modyfikacji (zmiany lub dodania), ponieważ wymagają one spełnienia wymogu. Oznacza to, że należy napisać specyfikację wymagań. To jest dokument.

Co prowadzi do punktu utrzymania całego projektu. W swoim pytaniu nie powiedziałeś, czy istnieją bieżące wymagania dotyczące programów, a nawet przybliżona dokumentacja funkcjonalna, ale na tym właśnie powinieneś się skupić.

Jeśli w ogóle nie masz żadnej dokumentacji, wypełnienie tej luki należy do ciebie. Nie można zatrudnić programisty do inżynierii wstecznej aplikacji i cudownie z tego tworzyć dokumentację . Musisz „wyjaśnić”, co chcesz, aby program robił (nawet jeśli oznacza to wyjaśnienie tego, co zostało już zaprogramowane).

Po napisaniu tego dokumentu (w formie specyfikacji wymagań lub funkcjonalności) uzyskasz znacznie lepsze wyniki z wynajmu nowego programisty, ponieważ możesz przekazać dokumentację i zacząć od tego pracować.

Istnieje również wiele programów, które wytwarzają dokumenty z kodu źródłowego, co jest dobrym sposobem na stworzenie szkieletu wyjaśniającego rzeczywisty kod źródłowy (jest to w zakresie specyfikacji technicznej), który można pracować tylko w kontekście wyjaśnienia technicznych aspektów funkcjonalność określona w specyfikacji funkcjonalnej, która określa funkcjonalność wymagań określonych w specyfikacji wymagań.

Więc tak, moim zdaniem jest zatrudnienie programisty do naprawy błędów. Po tym, jak naprawił błędy, które zgodziłeś się naprawić, możesz omówić aspekt dokumentacji jako kolejną umowę. Przy odrobinie szczęścia zatrudniliście programistę, który ma pewne doświadczenie i może przyczynić się do podjęcia dalszych kroków.

Oto jak podejdę do problemu:

• Masz wiedzę dotyczącą domeny. Wiesz, które funkcje są teraz dostępne na stronie, które chcesz dodać w przyszłości, i prawdopodobnie możesz wymienić kilka błędów, które zostały zgłoszone również przez użytkowników.

• Jest tam ten stos kodu, pozostawiony samemu sobie w kącie. Może być wadliwy, ale nadal zapewnia wartość, ponieważ witryna ma aktywnych użytkowników. Całkowite przepisanie byłoby zatem błędem IMO.

Mostek między Twoją domeną a kodem został zerwany, gdy programista odszedł. Musisz go odbudować, aby baza kodu mogła zostać ponownie zsynchronizowana z Twoimi wymaganiami i aby można było opracować przyszłe aktualizacje.

Chodzi o to, że ten most nie może być w całości wykonany z dokumentacji. Oprogramowanie jest zarówno kwestią ludzką, jak i techniczną. Jeśli nie wyjaśnisz nowemu programistowi, czego oczekujesz ze szczegółami, będzie mu ciężko wydedukować to z samego kodu - tym bardziej, jeśli poprzedni programista napisał tajemniczy, słabo udokumentowany, źle przetestowany kod. A jeśli nie pracujesz w ścisłej współpracy z nowym programistą, aby znaleźć zautomatyzowany, ciągły sposób na sprawdzenie, czy kod spełnia twoje wymagania, innymi słowy, aby most był bardziej niezawodny, problem jest skazany na powtórzenie się.

• Regularnie siadaj (nawet wirtualnie) z nowym programistą do sesji przetwarzania wiedzy w domenie. Podczas każdej z tych sesji napisz razem specyfikacje dotyczące małej części produktu. Może to być pojedyncza strona internetowa, może to być funkcja. Uczynienie ich wykonywalnymi specyfikacjami (a la Behavior-Driven Development ) zwiększy poziom pewności, że most działa, ponieważ można je uruchamiać w sposób ciągły i ostrzegać, gdy coś jest nie tak. Ułatwi także życie programisty.

  Po sesji programista jest w stanie wrócić do swojej pracy i napisać testy niższego poziomu, które potwierdzają zgodność bieżącego kodu ze specyfikacją. Jeśli nie jest zgodny, programista ma wszystko, czego potrzebuje, aby to naprawić. Ważne jest również, aby pozostać dostępnym na wszelkie pytania, które mógłby mieć.

• Staraj się utrzymywać ścisłą, ciągłą współpracę między tobą a programistami w swoim projekcie i upewnij się, że tak jest również między nimi. Jest to konieczne, jeśli chcesz, aby kultura funkcjonalna i techniczna wokół twojego projektu przetrwała, unikając problemów takich jak ten, który masz teraz. Wymaga to oczywiście nie tylko ponad 2 programistów pracujących nad Twoim projektem, ale także dzielenia się wiedzą o wszystkim, co piszą. W ten sposób można działać jako przełączenie awaryjne, gdy brakuje innego. Techniki takie jak programowanie par i przeglądy kodu są dobrym sposobem na osiągnięcie tego.

Po prostu dodając do tego, co wszyscy powiedzieli,

Jeśli nie możesz zmusić starego programisty do udokumentowania swojego kodu nawet za pewną cenę, nie oczekuj, że ktoś inny będzie mógł go udokumentować lepiej. Oto kilka opcji, dzięki którym nowy programista będzie produktywny już pierwszego dnia.

1. Zdobądź bazę danych błędów i zacznij wprowadzać do niej wszystkie znalezione błędy. Jest to priorytetowa lista rzeczy do zrobienia dla programisty. Dokumentuj to dobrze i podaj jak najwięcej szczegółów (plik źródłowy / przyczyna źródłowa, co robi i co powinien zrobić). Istnieje wiele bezpłatnych programów do śledzenia błędów, takich jak Bugzilla , Redmine i JIRA . Używaj tego, co chcesz.
2. Utwórz arkusz specyfikacji dla swojego projektu. To da nowemu programistowi pewien kierunek po usunięciu błędów. Możesz sprawdzić przewodnik Joela na temat pisania specyfikacji .
3. Utwórz harmonogram lub oś czasu dla swojego projektu. Powinny mieć terminy i etapy, w których otrzymują wynagrodzenie za wykonaną pracę, zamiast płacić je z góry.

Teraz to już nie przeszkadza, możesz zacząć szukać programisty. I jak powiedział Creative Magic, zlecanie pracy firmom może prowadzić do katastrofy lub podnieść cenę do nieskończoności i nie tylko.

Tym razem zacznij właściwie planować współczynnik autobusu przy zatrudnianiu programistów. Ludzie przychodzą i odchodzą i nic nie można na to poradzić, więc tym razem przygotuj się na najgorsze, zdobywając dwóch programistów lub, jak powiedział Uooo, zdobądź jednego programistę i jednego testera.

Teraz, gdy programiści będą z tobą w sklepie, możesz zacząć prosić ich o udokumentowanie kodu, zamiast prosić o udokumentowanie starego kodu, naprawdę, zapomnij o tym.

Inne rzeczy do rozważenia przy zakupie nowego programisty, upewnij się, że znają kontrolę źródła i automatyczne testowanie. Z ich pomocą postaraj się uzyskać jak najwięcej kontroli testu Joela, tyle możesz zrobić samemu.

Więc twój jedyny programista został potrącony przez autobus i teraz potrzebujesz wymiany.

Możesz spróbować pozwać swojego byłego programistę na podstawie umowy lub dowiedzieć się, co jest z nim nie tak. Zakładając, że nie wróci, to ci nie pomoże.

• Chcesz, aby Twój produkt był gotowy, więc poszukaj programisty, który ma doświadczenie w utrzymywaniu i rozwijaniu istniejących systemów. Nie skupiłbym się na informowaniu programisty, co robić w jakiej kolejności. Upewnij się, że zatrudniono kogoś profesjonalnego, który w razie potrzeby pisze dokumentację i testy jednostkowe.
• Ze swojej strony możesz upewnić się, że nowy programista ma wszystko, co potrzebne do jego pracy : specyfikacje wymagań, wydajną maszynę i tak dalej. Potrzebujesz profesjonalnego programisty, więc zapewnij mu profesjonalne środowisko pracy.

Pomyśl także o zatrudnieniu drugiego programisty, aby w przyszłości ułatwić tego rodzaju trudne sytuacje. Tester byłby również przydatny do zapewnienia jakości.