Dla kierownika projektu stworzenie jakiegokolwiek produktu to przede wszystkim komunikacja z klientem, organizacja pracy zespołu i kontrola dostarczenia zadań na czas. W przypadku wdrożenia nowego specjalisty IT, często pojawia się szereg problemów, które przeszkadzają wszystkim w procesie realizacji projektu. Jakie to problemy i jak je rozwiązać, opowiedział Lead Software Engineer w SoftServe Alexey Golubev.
Problemy podczas realizacji projektu
Zbyt obszerny „task”
To częsta historia, gdy programiści mówią, że „zadanie jest obszerne i zajmie dużo czasu”, więc nie chcą się go podjąć. Są tu dwie możliwości: specjalista nie wie, że duże zadanie można podzielić na części, albo nie chce tego robić. W pierwszym przypadku Ty, jako PM, powinieneś wyjaśnić, że zwyczajem jest dzielenie dużych zadań na mniejsze podzadania. W drugim, powinieneś zastanowić się, czy zaprosiłeś do projektu właściwą osobę. Tak czy inaczej, takie zachowanie powinno Cię zaniepokoić.
Jedną z podstawowych praktyk podczas pracy nad projektem jest rozbicie dużego zadania na mniejsze części, zajęcie się każdą z nich po kolei, a następnie złożenie wszystkiego w całość. Każdy developer powinien o tym wiedzieć.
Trudne zadanie
Zdarza się, że podczas szacowania ekspert techniczny popełni błąd i w trakcie zorientuje się, że zadanie jest dla niego zbyt skomplikowane. W takim przypadku PM ma dwie opcje: zaprosić eksperta z zewnątrz (jeśli sprawa dotyczy domeny lub kwestii technicznych, z którymi nikt w zespole nie miał wcześniej do czynienia) lub zorganizować investigate dla swojego podopiecznego. Z punktu widzenia wzmocnienia i rozwoju zespołu preferowana jest druga opcja, pod warunkiem, że nie ma ryzyka opóźnienia terminu.
Investigate – proces, w którym specjalista dowiaduje się, jak wykonać określone zadanie. Może to być albo kontakt z ekspertem, albo dodatkowe poszukiwania informacji w książkach lub na specjalistycznych stronach internetowych.
Na przykład serwer otrzymuje 100 zgłoszeń jednocześnie, ale trzeba go rozbudować do 1000. Programiści w zespole nie wiedzą, co zrobić: podłączyć inny serwer, nową bibliotekę czy skonfigurować oprogramowanie firm trzecich. Aby rozwiązać problem, tworzone jest osobne zadanie, a konkretny specjalista otrzymuje określoną ilość czasu na zbadanie zagadnienia. Po zakończeniu pracownik wraca z raportem z wykonanej pracy i opcjami, co można zrobić. Na koniec wybiera się najwłaściwszy sposób rozwiązania problemu. Tę samą historię można opowiedzieć nie tylko w przypadku kwestii technicznych, ale również w przypadku biznesowej strony projektu.
Wątpliwości co do jakości pracy developerów
Każdy Project Manager przynajmniej raz w swojej karierze zadał sobie pytanie, czy pracownicy są rzeczywiście tak dobrzy zawodowo, jak wydawało się w momencie ich zatrudnienia. Najczęściej wątpliwości pojawiają się, gdy wciąż pojawiają się błędy w częściach projektu, za które odpowiedzialny jest dany specjalista. Wyraźnym wskaźnikiem, że developer nie wykonuje swojej pracy dobrze, są wyskakujące ciągle uwagi testera (QA-engineer). Jeśli więc widzisz dużo zadań od QA do konkretnego technika, wprowadź code review. To znacznie zmniejszy liczbę błędów i pomoże uniknąć refaktoryzacji.
Kolejnym problemem, który często pojawia się w projektach, są źle ustawione procesy. To, jak otrzymujesz zadania, jak nimi zarządzasz i jak je rozwiązujesz, wpływa bezpośrednio na pracę całego zespołu. Jeśli masz zlecasz zadania „z dziś na jutro” lub nawet „na wczoraj”, to specjalistom niezwykle trudno jest zaplanować jakąkolwiek stabilną pracę. Zwłaszcza, gdy w zespole są nowe osoby. Źle skonfigurowane procesy są często przyczyną „przestojów” developerów, przez co firmy IT tracą pieniądze, a pracownicy rozważają szukanie innego miejsca do realizacji swojego potencjału.
Moglibyśmy przejść do ceremonii, które są ważnym elementem pracy zespołu IT, ale pamiętajmy o potencjalnych problemach w komunikacji między ludźmi. A konkretnie o tak zwanych „toksycznych” członkach zespołu.
Problematyczną osobą może być zarówno nowicjusz, jak i ktoś ze „starej gwardii”. Ważne jest, aby PM-owie monitorowali relacje w zespole i jak najszybciej identyfikowały negatywne postacie, aby problem mógł być natychmiast naprawiony. Czasem wystarczy sama rozmowa z toksycznym pracownikiem, a czasem trzeba go usunąć z zespołu. To właśnie wtedy „łyżka dziegciu psuje beczkę miodu”. Należy pamiętać, że „toksyczne” osoby mogą ujawnić się w każdej chwili, także podczas różnych spotkań (ceremonii) roboczych.
Ceremonie: co w nich może być nie tak
Ceremonie w szerokim tego słowa znaczeniu to retro, daily i inne tego typu spotkania. Powinny one pomagać w zbliżeniu zespołu i sprawić, że będzie on pracował efektywniej. Ale nie wszyscy developerzy i inni specjaliści IT je lubią, niektórzy wręcz uważają ceremonie za stratę czasu. Stąd wynikają następujące problemy:
- Sabotaż. Specjalista ignoruje spotkania lub chodzi na nie wyłącznie dlatego, że tak każą mu szefowie. Ważne jest, aby dowiedzieć się, jaki jest powód takiego zachowania. Być może spotkań jest bardzo dużo, więc pracownicy nie mają na nie czasu, albo nie widzą w nich wartości. W pierwszym przypadku project manager powinien pomyśleć o optymalizacji liczby spotkań i czasu ich trwania. W drugim przypadku należy przekazać informację o przydatności takich spotkań dla zespołu i pracy jako całości.
- Pasywność. Często zdarza się, że część zespołu aktywnie uczestniczy w omawianiu spraw na spotkaniach, podczas gdy reszta pełni rolę biernych słuchaczy. Ostatecznie skuteczność takich spotkań jest daleka od 100%. Dlatego jeśli widzisz, że ktoś zawsze tylko „wykonuje swoje obowiązki”, koniecznie zapytaj tę osobę, dlaczego niechętnie bierze udział w dyskusjach. Być może jest nieśmiała (często zdarza się to w przypadku nowych osób w zespole). Na tej podstawie zdecyduj, jak chcesz dalej prowadzić spotkania.
- Spadek efektywności. Zwykle to się dzieje, gdy jest dużo spotkań każdego dnia lub są one niewygodnie umieszczone w ogólnym harmonogramie. W efekcie developerzy szybko się męczą, a ich efektywność pracy spada z powodu przerywanego tempa. Aby temu zapobiec, stwórz dogodny harmonogram spotkań i dostosuj ich liczbę.
To są główne problemy, które wiążą się z ceremoniami w trakcie trwania projektu. Porozmawiajmy teraz o tym, co i jak może zrobić Project Manager, aby poprawić efektywność nowicjusza i całego zespołu.
Naprawiamy pracę zespołu IT
„W domu najważniejsza jest atmosfera” – to świetne zdanie, które opisuje zasadę efektywnej pracy każdego zespołu IT. Jeśli w zespole panuje przyjazna atmosfera, wzajemne zrozumienie i właściwe współdziałanie specjalistów, to wynik całości prac jest wielokrotnie lepszy. Aby to osiągnąć, PM mogą wykorzystać następujące narzędzia:
- Spotkania jeden na jeden. Podczas samych retro nie każdy będzie mógł wyrazić swoje niezadowolenie z czyjejś pracy jako współpracownik. Podobnie jest z mówieniem o wizji swojej roli w zespole i ogólnie o problemach w zespole, o propozycjach i pomysłach na poprawę swoich wyników. Na spotkaniu tête-à-tête jest to dla wielu osób łatwiejsze, niż na zwykłych spotkaniach pod warunkiem, że PM-owie stworzą środowisko pełne zaufania. Tutaj Twoim zadaniem jako project managera jest dowiedzieć się jak najwięcej o obawach i pragnieniach podopiecznych, znaleźć do nich odpowiednie podejście i pomóc w znalezieniu rozwiązań.
- Team building. Jaki jest lepszy sposób na „sklejenie” zespołu niż spotkania towarzyskie poza pracą? Tylko że musi to być wydarzenie, z którego wszyscy będą zadowoleni. Zadaniem PM jest w tym przypadku zaplanowanie team buildingu, uargumentowanie go w rozmowach z kierownictwem (i uzyskanie budżetu), zorganizowanie go i przeprowadzenie.
- Rotacja. Oznacza to zazwyczaj usunięcie lub zastąpienie „toksycznych” osób w zespole. Zdarzają się sytuacje, gdy dana osoba ma po prostu dość danego projektu. Wtedy lepiej jest ją odpuścić i przenieść do innego projektu, tak aby pozostała w firmie. W ten sposób zawsze możesz do niej się zwrócić w razie potrzeby. Na przykład, przyjąłeś kogoś na stanowisko tej osoby i potrzebujesz szybkiego onboardingu do swojego projektu. Zazwyczaj w takich przypadkach nie odmówią małej pomocy.
- Podział na obszary odpowiedzialności. Nie zawsze jest to konieczne, ale czasami bardziej efektywne jest podzielenie części obowiązków project managera pomiędzy członków zespołu. Na przykład samo wdrożenie nowych programistów. Nie ma sensu tracić czasu na uczenie wszystkich developerów, co i jak mają robić, skoro można to zadanie zlecić jednej osobie i uczynić ją odpowiedzialną. Ważne jest, abyś jako lider zespołu wybrał odpowiednie osoby do odpowiednich zadań.
Wymienione powyżej narzędzia są bardzo skuteczne i zostały przetestowane przez wielu project managerów, dlatego koniecznie wykorzystaj je w swojej pracy jako PM. Ogólnie rzecz biorąc, lepiej jest budować pracę zespołu według pewnego planu, ale z uwzględnieniem indywidualnych cech każdej osoby. Razem można osiągnąć większy sukcesu, niż osobno.