Grzecznie mówiąc niekompetentny wolontariusz projektu oprogramowania są zbyt niedoświadczeni

Możesz całkowicie pominąć ten problem.

Nie musisz nawet być oszukiwany.

Po prostu powiedz im, że ta część projektu, w której mogą realnie pomóc, jest już zakończona (ponieważ tak jest, to cała prawda) i że skontaktujesz się z nimi ponownie, jeśli pojawi się coś innego, w czym mogą pomóc. Ma to kluczowe zalety:

• Nie palisz żadnych mostów.
• To może skłonić młodszego programistę do większej nauki w celu zdobycia umiejętności bardziej adekwatnych do projektu.
• Nie zwalniasz ich ani nie insynuujesz, że są w ogóle niekompetentni.
• To normalne w przypadku wspólnych projektów w wolnym czasie. W pewnym momencie rzeczy, które ktoś bez pewnych umiejętności może zrobić, kończą się.

Używając tej strategii, całkowicie unikasz problemu “zwalniania” ich w ogóle.

Alternatywnie, możesz przydzielić je do zadań, które muszą być wykonane, ale nie potrzebujesz dewelopera do ich wykonania, lub zadań, które są drugorzędne (miło jest mieć). Zwykle obejmuje to:

• Pisanie dokumentów
• Przegląd kodu
• Obszerne testy Q/A

Bądź na bieżąco z zadaniami, które nie kosztują Cię nic, jeśli są źle wykonane, ale bardzo pomagają, gdy z entuzjazmem je wykonują.

Nie jestem pewien, czy musisz ich całkowicie zwolnić z projektu, możesz też przesunąć ich do pozycji, w której nie będą blokować innych ludzi (w tym Ciebie).

Po pierwsze, brzmi to tak, jakby głównym problemem dla Ciebie był coaching - więc ogranicz go do minimum. Mógłbyś powiedzieć coś w stylu:

Hej Bob, obecnie wiele się dzieje w moim życiu i po prostu nie mogę znaleźć czasu na nasze sesje treningowe [lub jakkolwiek je nazwiesz], przepraszam za to.

Następnie przenieś ich “z drogi”, przydzielając im jedno lub dwa proste zadania o niepilnym priorytecie. Jeśli mogą nauczyć się i wykonać zadanie samodzielnie: świetnie, daj im coś bardziej wymagającego i powtarzaj, dopóki nie znajdziesz ich poziomu kompetencji. Jeśli nie, wróć do nich, gdy zadanie będzie miało wyższy priorytet (gdy będzie wkrótce potrzebne). Jeśli chcesz być dyplomatą w tej kwestii, możesz wtedy powiedzieć:

Hej Bob, potrzebujemy dokumentacji / tłumaczeń / testów wykonanych / wkrótce. Czy mógłbyś się tym zająć, a ja w międzyczasie zajmę się defrobulatorem?

Naprawdę pomaga, jeśli możesz przekonać się, że dokumentacja i testy to ważne zadania - bo one are. Wiele devów nie chce pisać dokumentacji i to przypieczętowuje los wielu małych projektów open source'owych: ich oprogramowanie rozwiązuje pewien problem, ale większość ludzi nie potrafi wymyślić jak go używać, więc nikt go nie używa.

Na koniec: wspominasz “Nigdy wcześniej nie pracowałem z innymi programistami” i nie jest dla mnie całkiem jasne jak organizujesz pracę w swoim projekcie. Organizowanie rozwoju oprogramowania jest bardzo cenną umiejętnością, więc może zechcesz skorzystać z tej okazji, aby się uczyć i rozwijać. Naucz się rozkładać pracę na zadania i podzadania, ustalać zależności, szacować potrzebny czas, ustalać priorytety, co jest ważne, a co może poczekać, oceniać, kto co może zrobić. Dowiedz się, jak najlepiej komunikować się z innymi dewiantami i jak przesadzać, gdy sprawy nie układają się tak, jak się spodziewałeś. Korzystaj z narzędzi do współpracy (issue tracker, system wersjonowania, itp.).

Może metodologie en vogue w świecie biznesu w tej chwili (Scrum, Kanban, itp.) dadzą Ci kilka przydatnych wskazówek.

Po pierwsze, zgadzam się z tą częścią o podziękowaniach dla wolontariusza za jego dotychczasowy czas/wysiłek i stwierdzam, że część pierwotnego rozwoju, na którym go potrzebowałeś, jest zakończona.

Mogę polecić, dla waszego dobra, zainwestowanie w jeszcze jedną sesję mentorską. Temat: pokazać swojemu złemu ja, jak pisać testy jednostkowe. Następnie powiedz mu, że jeśli chce zrobić więcej pomocy technicznej (w przeciwieństwie do innych rodzajów), powinien zacząć rozbudowywać stajnię DeepL. Zalety:

• Dostajesz testy jednostkowe!

• Wolontariusz zostaje wprowadzony w ważną naturę testów jednostkowych!

• Jeśli wolontariusz jest powolny lub utknął, to nie przeszkadza w rozwoju mainline

Następnie, jak w przypadku innych odpowiedzi, można błagać o więcej szkoleń, jak straciłeś luzu w harmonogramie.

Ponieważ są oni wolontariuszami, nie sądzę, aby konieczne było “zwalnianie” ich w ogóle, ponieważ takie sformułowanie byłoby niegrzeczne. Zamiast tego stwierdzenie, że praca wolontariuszy, do której ich potrzebujesz, jest na razie skończona, może być bardziej odpowiednie. Pamiętaj również, by podziękować im uprzejmie za pracę, którą już wykonali, skomentować jej sukces i ich osobisty rozwój, po prostu nie dawaj im żadnych nowych zadań.

To działa szczególnie dla wolontariuszy, ponieważ nigdy nie byli technicznie zatrudnieni, tylko pomagali tam, gdzie byli potrzebni i jeśli możesz to sformułować w taki sposób, by pokazać, że udało im się wykonać swoje zadanie, to nie otrzymywanie kolejnych zadań powinno być spotykane z pozytywnymi uczuciami, a nie negatywnymi.

Thank you so much {name}, {X} part of the project is up and working well! Zrobiłeś wszystko, czego potrzebowałem, ale jeśli to jest w porządku z tobą, mogę poprosić cię o więcej pracy w przyszłości?

Pytanie, czy to jest w porządku za coś, czego chcą jest całkiem poręczne, ponieważ trzyma metaforyczny most, o którym wspomniałeś, sprawia, że się z tobą zgadzają, daje im opcje, które kiedykolwiek wybiorą, aby osiągnąć swój cel powstrzymania ich od pracy nad obecnym projektem i jest uprzejme.

Niestety to nie zadziała we wszystkich przypadkach i nie znam szczegółów Twojego projektu/ tego, co zostało mu przydzielone. Jeśli musisz wybrać pomiędzy byciem nieco bardziej tępym a kłamliwym, bycie tępym prawdopodobnie pomogłoby na dłuższą metę (to nie znaczy, że powinieneś skupić się na tym co złe!).

Pomogłeś nam i znacznie się poprawiłeś, ale myślę, że byłoby lepiej jeśli {inne} i wykonałem pozostałe zadania.

i

Jeśli coś lepiej pasującego do twoich umiejętności pojawi się w przyszłości, na pewno wyślę to po twojemu.

Może być bardziej odpowiednie w niektórych przypadkach.

Moja lektura tej sytuacji jest… powiedzmy trochę cyniczna. Nieustannie pojawiają się rady dla nowych programistów, aby uzyskać ich nazwiska na prośbę pull, jako sposób na zwiększenie wiarygodności ich GitHuba dla potencjalnych pracodawców. Patrząc tam na innych stronach, jest stałe porady dla nowych devs dołączyć do projektu open source jako sposób na zdobycie doświadczenia. Doświadczenie to odbywa się kosztem czasu spędzonego na mentoringu bardziej zaawansowanych devów w tych projektach.

Chociaż tak, junior dev rezygnuje z wolnego czasu - nie widzę tego jako takiego. Młodszy dev otrzymuje darmowy mentoring i wznawia budowanie na koszt prowadzonego przez siebie projektu wolontariackiego. (Moim zdaniem) koszty mentoringu w projekcie wolontariackim rzadko są warte zachodu, chyba że dana osoba jest zaangażowana w projekt i jest nim autentycznie zainteresowana, co wykracza poza zakres uprawnień GitHub.

Istnieją dwie ścieżki, które należy rozważyć.

Mentor juniora dev. Będziesz kontynuował pasterstwo każdego zaangażowania i upewnij się, że przesłane materiały odpowiadają Twoim standardom projektu. Pierwszorzędną rolą opiekuna jest zapewnienie, że zarówno Twój projekt jak i zobowiązania juniora dev są zgodne z Twoimi oczekiwaniami.

Nie udzielaj opiekuna juniorowi dev. Twój czas poświęcony na wolontariat w pracy nad projektem jest tak samo cenny, jeśli nie bardziej, jak jego czas. Prawdopodobnie wiele osób zamyka sklep w przygotowaniu, by powiedzieć “to zrobione” i przejść do innego projektu. Często są to żmudne i nudne zadania, ale trzeba je jeszcze wykonać. Rzeczy takie jak:

• dokumentacja - poproś inną osobę, aby przeczytała cały napisany tekst i upewniła się, że ma on prawidłową pisownię, interpunkcję, gramatykę, formatowanie, i tak dalej.
• czyszczenie stylu - chwyć za swój ulubiony linter i przeprowadź przez niego kod zgodnie ze stylem, który chcesz. Zaloguj wszystkie style czyszczenia elementów jako problem w pliku, który ma być czyszczony.
• pisanie testowe - praca nad poprawą pokrycia kodu. Zawsze są testy do napisania.

Zrozum i pamiętaj, że jeśli jest jakieś zadanie, które zajmie Ci 4h do zrobienia samemu lub 3h Twojego czasu i 8h czasu junior dev, nie ma większego sensu, aby junior dev to robił, chyba że weźmiesz pod uwagę wartość zdobywania doświadczenia przez junior dev.

Spójrz na to, co każda osoba (Ty i junior dev) wychodzi z układu. Obaj jesteście wolontariuszami. Jeśli nie ma czegoś dla wolontariusza do zrobienia - to jest w porządku.

Powiedz im prawdę, ale trzymaj się faktów.

Bądź szczery i uczciwy i przedstaw fakty tak, jak je tutaj zaprezentowałeś:

• Z perspektywy czasu widzisz, że ilość pomocy jakiej potrzebują jest bardzo czasochłonna. Zaczęło to ograniczać Twoją zdolność do pracy nad projektem.
• Zwijasz projekt w dół. Zbliżasz się do punktu, w którym nie będziesz już pracował nad projektem. Daj im znać, jakie są tego przyczyny. (Na przykład, być może zastąpi go nowy projekt z lepszym wsparciem/finansowaniem lub po prostu nie pozostało wiele do zrobienia.)
• Podziękuj im za cały wysiłek, który włożyli w ten projekt i powiedz im, że masz nadzieję, że to doświadczenie było pomocne w rozwijaniu ich umiejętności.
• Być może zaoferuj im pomoc w znalezieniu innego projektu, w którym będą mogli kontynuować pracę nad rozwojem, być może jeszcze jednego zgodnego z ich obecnym poziomem umiejętności.

Bądź świadomy, że mogą odpowiedzieć pytając, czy mogliby kontynuować pracę bez tak ścisłej kontroli. Jeśli jest to wykonalne, możesz rozważyć celowe oderwanie się od nich, a następnie po prostu przejrzeć ich pracę, gdy jest done (np. jako prośba o pociągnięcie). To od Ciebie zależy, czy jest to wykonalne. Jeśli możesz znaleźć dla nich małą zmianę do wdrożenia, możesz to rozważyć. Jeśli spróbujesz i nie pójdzie dobrze, możesz pokazać im konkretnie co jest nie tak z ich pracą, i być może będziesz musiał wrócić do tej dyskusji o braku czasu i zakończeniu projektu.

Rzeczy nie powiedzieć:

• Zwalniasz ich.
• Nie cieszysz się już projektem z ich powodu.
• Są niekompetentni lub cokolwiek innego o ich wrodzonych zdolnościach.

Czasami lepiej nie mówić wszystkiego co myślisz i czujesz. Nie dlatego, że jesteś nieuczciwy, ale dlatego, że wiesz, że twoje uczucia i myśli nie są całkowicie obiektywne. Nasze osądy są czasami zaciemnione przez nasze niespełnione pragnienia, więc czasami trzymamy usta zamknięte na temat myśli i uczuć, o których wiemy, że nie są naprawdę ważne.

Tak, istnieje pewne nieodłączne ryzyko, że możesz zranić ich uczucia. Każde podejście tutaj niesie ze sobą ryzyko. Nie robienie niczego niesie ze sobą ryzyko, że staniesz się sfrustrowany i uwolnisz go w niekonstruktywny sposób, a kłamstwo lub fałszowanie prawdy grozi drugiej osobie dowiedzeniem się, co naprawdę się stało. Bycie szczerym ma tę zaletę, że można zaufać drugiej osobie, że sama oceni sytuację i przyjdzie zobaczyć rzeczy tak, jak ty to robisz. Osoba ta może zobaczyć, że nie jesteś niesprawiedliwy i że starasz się podejść do sytuacji obiektywnie. Jeśli nie rozumie twojego punktu widzenia, możesz to z nią omówić i wyjaśnić; nie jest to możliwe, jeśli nie jesteś szczery.

Jeśli czujesz, że druga osoba zaczyna wątpić w to, że twoja przyjaźń będzie kontynuowana, daj jej jasno do zrozumienia, że chcesz ją kontynuować. Jak to zrobić jest poza zakresem tego pytania, ponieważ zależy to od specyfiki reakcji drugiej osoby.