Czy zdarzyło Ci się kiedyś prowadzić projekt, w którym zespół:
– z miesiąca na miesiąc zaczął pracować dwa razy więcej?
– zamiast w szacowane 2 tygodnie naprawił błąd krytyczny w aplikacji w 12h?
– zaoszczędził 200.000 zł w 3 miesiące przy organizacji wielkiego wydarzenia?
– w 4h zorganizował 100 osób do pracy na ten sam dzień?
– podczas pracy nad oprogramowaniem trafiał w oczekiwania użytkowników końcowych w 99%?
Ja prowadziłam projekty w których zespoły osiągały właśnie takie wyniki. Ważna poprawka, z takimi zespołami się nie pracuje, z takimi zespołami miałam zaszczyt pracować! W projektach stawiam na pełną świadomość w budowaniu takich zespołów, które nie tylko wspinają się na szczyt, ale dokonują niemożliwego i są w stanie przenosić góry:)
Po czym poznać w jakim punkcie jest obecnie zespół? Ciemna mgła? Wspina się na szczyt? Czy może właśnie z niego spadł i trzeba opatrzyć rany? Po czym poznać, że zespół jest o wysokiej wydajności tzw. high-performing jeszcze zanim zobaczymy pierwsze wdrożenie na produkcję albo po prostu koniec projektu?
Zgodnie z Agile poniżej 8 cech charakterystycznych dla zespołów o wysokiej wydajności:
- Self-organizing (samo-organizujący się)
- Empowered (uprawiony, upoważniony)
- Believe they can solve any problem (wiara, ze można rozwiązać każdy problem)
- Committed to team success (oddany sukcesowi zespołowemu)
- Owns its decisions and commitments (odpowiedzialny za decyzje i zobowiązania)
- Motivated by trust (zaufanie jako podstawa motywacji)
- Consensus driver (prowadzący do konsensusu)
- Participate in constructive disagreement (uczestniczy w konstruktywnym sporze)
Lista powyżej nie była dla mnie wystarczająca, więc stworzyłam swoją… Poniżej moja tajna checklista Tahari:
- Każdy członek zespołu wie jaki jest cel projektu.
- Każdy członek zespołu wie dlaczego robi projekt – jaka jest jego wartość, jakie problemy będą rozwiązywane oraz kto jest użytkownikiem końcowym.
- Każdy z członków zespołu rozwija się/uczy przy projekcie – niesie on indywidualną wartość.
- Manager/szef/itp. ufa członkom zespołu i pozwala im decydować o swojej pracy i brać za nią odpowiedzialność.
- Zespół może samodzielnie zdecydować jak będzie pracować (biorąc pod uwagę panujące standardy w firmie).
- Na spotkaniach zespołu otwarcie mówi się o problemach, które mogą wystąpić (czyli jeszcze nie wystąpiły) w projekcie. Na przykład „postawiona wcześniej wersja aplikacji może nie dać rady wydajnościowo jeśli zrobimy dwie integracje z systemami x i y. Czy coś z tym robimy?”
- Członkowie zespołu zgłaszają swoje pomysły na ulepszenia w trakcie pracy nad wymaganiami. Jeśli jest napisane w przepisie tzn. w wymaganiu żeby ubić jajko w plastikowym naczyniu to ktoś się odezwie i powie: „Lepiej ubijmy w szklanym – będziemy mieć większe szanse na to, że ta piana się dobrze ubije!” Druga osoba odpowie: „mamy zwykłe jajka hm a wiem, że w dziale X właśnie testują te z wolnego wybiegu – dowiem się czy lepiej się ubijają!”
- Jak rozmawiamy o tym, co jest do zrobienia to nie muszę robić losowania lotto kto ma co zrobić – bo każdy wie po co jest w tym projekcie i wie jaką pracę ma do wykonania.
- Przy pracy w zespole się żartuje (tak tak żarty prowadzące do śmiechu).
- Członkowie zespołu dbają o pracę nie tylko swoją ale innych w zespole. Takie zaangażowanie to również budowane relacje, które zostają na długo po projekcie.
- W trakcie prac regularnie występują porażki.
Dzięki temu zespół się uczy i każda następna iteracja jest lepsza. Jeśli nie ma małych i średnich porażek w trakcie trwania projektu to wystąpi jedna wielka porażka na końcu projektu;) Na koniec zapraszam na scenę Pana Winstona Churchilla: „Sukces polega na przechodzeniu od porażki do porażki bez utraty entuzjazmu”. Tak pięknie powiedziane ale to jest w tym wszystkim najtrudniejsze.
Lista jest gotowa do użycia, więc z marszu możesz przejść do mini audytu w zespole.
Wypróbowałeś/aś powyższe punkty? Koniecznie daj mi znać jak wrażenia! Czy Ty masz swoją checklistę Tahari? Może uważasz, że warto by było coś do tej listy dodać? Daj mi koniecznie znać.