Twoim zadaniem jako menedżera jest powstrzymywanie pracowników od rozpraszania się. Gdybym to był ja, nie wspomniałbym o złych punktach tych osób lub złym kodzie. Jednocześnie nie zachęcaj do złych rzeczy, które zrobił.

Coś w rodzaju:

Bob był naprawdę świetnym programistą i będzie mu bardzo brakowało . Postanowił skorzystać z innej okazji i życzymy mu powodzenia. Jestem naprawdę dumny z was jako zespołu i tego, jak się zbieracie razem, aby utrzymać nasze ramy czasowe w ruchu i nadal wykonywać wspaniałą pracę, do której wiem, że jesteś zdolny.

To nie oznacza cokolwiek konkretnego, ale jednocześnie chwali Twój zespół. Z biegiem czasu możesz ostrożnie rozwikłać niektóre problemy i zaostrzyć sytuację.

Gdy opadnie kurz, nadszedł czas na omówienie różnych standardów kodowania. Nie ściągaj ich z góry, ale zachęcaj zespół do ich rozwijania, a następnie poproś, aby wzajemnie się rozliczali. To powinno rozwiązać niektóre z problemów, które miałeś.

Mówiąc o nich coś negatywnego, ryzykujesz, że będziesz wyglądać małostkowo. Jako lider o wiele lepiej jest pozwolić, aby wyniki przemówiły same za siebie i pozwolą zespołowi opracować własną teorię w tej sprawie. Jeśli masz wskaźniki wydajności, które monitorujesz, zdecydowanie możesz pogratulować zespołowi „wyraźnej poprawy wskaźnika X w ciągu ostatnich Y tygodni”, aby wspierać ten pomysł, ale zdecydowanie nie wspominaj o niczym, jeśli Twoje wrażenie poprawy jest czysto anegdotyczne .

Czy mam odnieść się do tego na spotkaniu zespołu, podając fakty i powody, dla których go nie było? czy powinienem po prostu nic nie mówić? Co najlepiej zrobić w takiej sytuacji?

Myślę, że nie jest to konieczne.

Jeśli postęp jest znacznie szybszy, jak go opisujesz, zauważą również ulepszenia i wyciągną własne wnioski.

Zwołanie spotkania lub coś podobnego, aby powiedzieć „Nie czuj się źle, że odszedł, jesteśmy teraz znacznie lepsi i wydajni” nie jest czymś, co polecam (ponieważ jest to po prostu celowe rzucanie brudu na jego reputację). daj mu za to uznanie i po prostu pozwól, aby Twoja relacja zawodowa zakończyła się gładko.

Jeden z nich mieliśmy tutaj, zanim zacząłem. Uwielbiałem nowe frameworki, wzorce projektowe i narzędzia. Naprawdę ich nie rozumiał.

Problem polegał na tym, że stary zarząd był zakochany w swoich „umiejętnościach”. Pojawiło się nowe kierownictwo z rzeczywistymi umiejętnościami architektonicznymi i „Bob” * (nie jego imię) zrozumiał, że ma kłopoty. Bob * właśnie wyszedł i nigdy nie wrócił. Nie mógł poprzeć kodu, który napisał, więc to inni (jeden z powodów, dla których zostałem zatrudniony) musieli rozszyfrować bałagan, który zostawił. Duża część jego kodu została właśnie skopiowana ze stosu overflow. Problem polegał na tym, że nie rozumiał, co kopiował.

Jak radzisz sobie ze swoim zespołem? Powiedz „Bob * zrezygnował. Wiem, że niektórzy będą za nim tęsknić. Teraz to od nas zależy, czy będziemy kontynuować pracę”. Każdy doświadczony będzie wiedział, co się naprawdę wydarzyło, a młodsi programiści w końcu (kiedy będą musieli wesprzeć niektóre z rzeczy napisanych przez „Bob”), dlaczego najlepiej mu zostawił.

* Bez obrazy dla nikogo o imieniu Bob.

Zdecydowałbym się bardzo krótko (30 sekund lub mniej, jeśli to możliwe) wyjaśnić techniczne i zawodowe powody, dla których ta osoba nie była dobrze dopasowana, jednocześnie doceniając to, kim jest jako osoba. Więc nigdy więcej o tym nie wspominaj, przechodząc do dalszej pracy.

Chociaż zgadzam się z większością odpowiedzi tutaj, uważam, że odrobina przejrzystości może zrobić wiele dobrego dla ogólnego morale i kultury ludzi którzy wciąż tu są.

• Pozostawienie ich, by wyciągnęli własne wnioski, może przynieść odwrotny skutek i wzbudzić nieufność.
• Może to stanowić dobry precedens dla młodszych programistów poprzez jasne komunikowanie nie robić (w tym przypadku ulegaj pewnym samolubnym „pokusom programistów”)
• Wzmacniaj fakt, że jest to zespół i każdy powinien programować jak zespół
• Zmniejsz strach, że mogą być następni (ponieważ podziwiali umiejętności i podejście tego programisty i podziwiali je)
• Przypomnij pracownikom, że istnieje stabilna przyszłość, o ile są świadomi służenia firmie potrzebuje

Jeśli używasz zwinnego podejścia do programowania, zawsze możesz poruszyć je podczas retrospektywnego spotkania scrumowego po zakończeniu obecnego scrumu. Omawianie wydarzeń w scrumie, ich wpływu na zespół i tego, jak można je wykorzystać, aby poprawić posuwanie się naprzód, jest ich głównym celem, prawda? Wydaje się, że omawianie takich tematów pasuje do tematu.

Wspomnij o pozytywach i zignoruj ​​negatywy:

Mamy nowe możliwości wprowadzenia nowych wzorców i ulepszenia naszej architektury

jeśli nadal chcesz się rozwijać it ... lub ...

Mamy nową okazję do wprowadzenia standardów kodowania i najlepszych praktyk

Jeśli chcesz zacząć porządkować co masz i wdrażanie sprawdzonych metod.