Posłuchaj podcastu:
Jest projekt związany z technologią, nad którym pracował zespół developerów. Projekt jest zakończony, ale trzeba wdrożyć poprawki. Członkowie zespołu developerskiego nie chcą jednak podjąć zadania. Dlaczego i co robić w takiej sytuacji?
Niechęć i brak motywacji zespołu - przyczyny
Projekt dla developerow jest zakończony. Być może wpadła już premia, być może po prostu jest już mnóstwo innej pracy. Jednak dla organizacji proces wdrażania ciągle trwa. Rodzą się konflikty, nikt nie chce podjąć się zadania, menedżer musi wyznaczyć pracowników na siłę, powstają sytuacje konfliktowe. Zespoły developerskie pracują bowiem od projektu do projektu, liczy się aktualny cel, aktualny deadline. Z ich perspektywy przerwanie pracy, żeby wrócić do czegoś, co zostało już zakończone, jest stratą czasu.
Co więcej - developerzy po skończonym projekcie, biorą się za kolejny. Kiedy poprzedni projekt przynosi sukces, cała firma świętuje, a oni już zajmują się następnym zadaniem. Często nawet nie wiedzą o tym, jak bardzo pomogli w codziennej pracy np. działowi sprzedaży. Nie mają informacji, co dzieje się z projektem, nie są zapraszani na świętowanie.
Współodpowiedzialność członków zespołu developerskiego
Przez to, o czym piszę w poprzednim akapicie, developerzy nie mają poczucia współodpowiedzialności, bycia częścią całego sukcesu. Bo wiedzą, że ich projekt się udał, a mogą nie wiedzieć, ile dzięki niemu zarobiła firma. Kiedy więc słyszą o konieczności wprowadzenia zmian czy poprawek, budzi się w nich opór.
Nie mają poczucia, że to dalej ich projekt, ich sprawa, ich odpowiedzialność. W końcu projekt został przyjęty, był dobry, stworzony zgodnie z wymaganiami, a teraz ktoś chce zmian? W ich pojęciu nie jest to już ich problem.
Jak zmotywować zespół developerski do zmian w projekcie?
Co więc zrobić w takiej sytuacji?
- Zacznijcie od początku. Już przy omawianiu projektu dobrze jest przedstawić szerszy kontekst. Nie tylko wymagań technicznych, ale także temu, czemu ma służyć, dlaczego jest ważny, co osiągniecie dzięki niemu jako organizacja, jako całość
- Świętujcie wszyscy razem. Nawet, jeśli od Zakończenia zadań developerskich w projekcie minęło już sporo czasu i developerzy są zajęci czymś innym, zaproście ich na wspólne świętowanie, niech uczczą wspólny sukces, a nie tylko pomagają w kłopotach.
- Kiedy poprawki są konieczne, dobrze jest pokazać developerom, dlaczego - w czym poprawki pomogą innym pracownikom? Dlaczego to będzie dobre dla całej organizacji, a więc i dla nich samych? Nie ma tu potrzeby skupiania się na błędach i na szukaniu winnych. Poprawki nie oznaczają błędów, a np. dostosowanie produktu do rynku, wprowadzenie funkcjonalności, których wcześniej nie potrzebowaliśmy.
Takie podejście pomoże w zwiększeniu motywacji zespołu developerów, a także w polepszeniu komunikacji i zmniejszeniu liczby konfliktów pomiędzy zespołami.