Skuteczne spotkania zespołu

Jestem liderem zespołu złożonego z 8 programistów w firmie złożonej z około 20 osób technicznych. Pracują nad wieloma projektami, w projekty te zaangażowane są także osoby z innych zespołów, które są poza moją kontrolą. Moja organizacja nie rozwija odpowiednio sprawnego rozwoju i są w pewnym stopniu odporne na zmiany, ale codziennie organizuję spotkania stand-up w moim zespole i wszyscy uważamy je za przydatne, a wszyscy są zaangażowani i jesteśmy skończeni w ciągu 10-15 minut. Mam również cotygodniowe indywidualne spotkania z każdym członkiem zespołu, w których omawiamy bardziej szczegółowo różne tematy ogólne (techniczne i nietechniczne), a także różne spotkania tematyczne ad hoc.

Jednak zmagam się z moim cotygodniowym spotkaniem zespołu. Traci moc i nie byłem w stanie zainteresować ludzi.

Nadal chcę odbyć dłuższe spotkanie, nawet jeśli musi ono odbywać się co dwa tygodnie lub co miesiąc. Celem było omówienie różnych tematów, których nie można zrobić podczas spotkania stojącego, ponieważ wymagają one więcej czasu. Aktualizacje ode mnie zawierają podsumowanie każdego bieżącego projektu, nad którym pracują (czy to zgodnie z harmonogramem, różnymi opóźnieniami itp.), Wszelkich zmian w kierunku, przyszłych projektach, zmianach w procesie rozwoju itp. Jednak ostatecznie wykład ode mnie, a co najmniej 2 osoby są oczywiście wyłączone z strefy, a reszta jest co najmniej umiarkowanie zainteresowana.

Próbowałem zachęcić ludzi do większego zaangażowania, zachęcając ich do rozmowy o swoim tygodniu, ale w przypadku 8 osób zajmuje to dużo czasu i (częściowo dlatego, że duża część ich pracy nie przechodzi zbyt wiele), większość pozostałych zespołów nie dbam o to, nad czym pracowali ich współpracownicy bardziej szczegółowo (uzyskują ogólny przegląd podczas wstawania).

Tak więc podczas tych spotkań przynajmniej niektórzy ludzie są bardzo znudzeni, a trzymanie ich jest dla mnie prawie krępujące. Jest to wyraźny kontrast do naszych energetyzujących porannych spotkań.

Wszelkie porady na temat tego, co mogę zrobić, aby ludzie byli bardziej zaangażowani i zainteresowani? I jak mogę zmusić ich do zaprezentowania swoich rzeczy lub rozpoczęcia dyskusji, w których wszyscy będą uczestniczyć, zamiast być monologiem ode mnie?

Powiedziałeś, że na spotkaniach czujesz się, jakbyś je wykładał. Jeśli tak Ci się wydaje, a zespół nie wydaje się zainteresowany tym, co masz do powiedzenia, to dlaczego nadal masz spotkanie? Jeśli po prostu rzucasz im informacje i nie przyciągają ich uwagi, dlaczego nie po prostu podsumować wszystkiego w cotygodniowym e-mailu?

Jeśli chcesz wykorzystać tę godzinę, którą masz z całym zespołem, możesz rozważyć przeprowadzenie retrospekcji. Możesz przedstawić retrospektywę z prostą szczerością ze swojej strony: powiedz im, że nie czujesz, że poprzednie spotkania były produktywne i że chcesz spróbować czegoś innego, aby pomóc wszystkim skorzystać z godziny spędzonej razem.

W retros gdzie pracuję, będziemy mieć trzy kolumny na tablicy, zwykle umieszczając Smiley, meh i smutną twarz na górze, na przykład :), :|i :(. Następnie członkowie zespołu mogą umieścić na tablicy wszystko, o czym chcieliby rozmawiać z całą grupą.

W szczęśliwej kolumnie możesz świętować sukcesy (np. Pogratulować Alice i Bobowi wydania projektu, nad którym wspólnie pracowali), a także możesz zadeklarować zwycięstwo dzięki nowym procesom, które próbujesz (np. Nowy moduł śledzenia błędów jest znacznie lepszy niż stary).

W kolumnie meh umieścisz rzeczy, które nie są do końca szczęśliwe lub smutne na ten tydzień. Być może kupiłeś licencje na nową wersję swojego IDE, a ktoś nie widział żadnych zalet nowego IDE - mogliby to umieścić na tablicy, aby dowiedzieć się, czy wszyscy uważają, że aktualizacja była bezwartościowa, czy też inni mają znalazł sposoby, które faktycznie przewyższają poprzednią wersję.

W smutnej kolumnie umieściłeś rzeczy, które nie poszły dobrze na tydzień. Zidentyfikowanie punktów bólu w tym tygodniu jest, moim zdaniem, największą zaletą retrospekcji. Cały zespół omawia rozwiązania prawdziwego problemu. W zespołach, które wszystkie pracują na przykład na jednej bazie kodu, ktoś mógłby powiedzieć, że klasa FooBar jest nie do utrzymania i była przyczyną wielu godzin debugowania. Nagle okazuje się, że wszyscy pozostali w zespole również stracili wiele godzin w tym tygodniu na FooBar, ale nikt nie spędził czasu na jego uporządkowaniu. W takim przypadku zespół może wspólnie zdecydować, że rozsądnie jest spędzić czas na refaktoryzacji tego kodu w przyszłym tygodniu.

Po tym, jak wszyscy piszą proponowane tematy na tablicy, chciałbym krótko omówić każdy temat i poprosić jego autora o 10-30 sekundowe wyjaśnienie tego tematu. Ta sekcja spotkania jest łatwa do wykolejenia, więc musisz uważać, aby utrzymać ludzi na dany temat - np. Ktoś powie, że X był problemem, a ktoś inny zacznie mówić o rozwiązaniu problemu; rozwiązania nie powinny być omawiane aż po głosowaniu. Wprowadzając tematy, możesz znaleźć sposoby grupowania wielu ściśle powiązanych tematów.

Po wprowadzeniu wszyscy otrzymują trzy głosy, które mogą rozdzielić między tematy, które uznają za stosowne. Wreszcie, głosy są zliczane, a którykolwiek temat ma największą liczbę głosów, dyskutuje zespół. Dla każdego tematu określ, czy należy podjąć działanie. Świętowanie sukcesu zwykle nie ma przedmiotu akcji, ale refaktoryzację określonego kodu można przypisać jednej osobie. Przedmioty akcji powinny zwykle być wykonane przez jedną osobę, ale czasami są to przedmioty akcji „z całego zespołu”, takie jak dbanie o dobre wiadomości o zatwierdzeniu.

Większość retrospekcji zwykle koncentruje się na tematach w smutnej kolumnie i praktycznie żadne retrospekcje nie omawiają wszystkiego, co jest zapisane na tablicy. Spotkanie kończy się zawsze, gdy upłynie czas. Natychmiast po spotkaniu sprawdź, czy elementy akcji są przypisane do konkretnych osób; rób to w dowolny sposób, który ma sens dla Twojej organizacji.

Odniosłem wielki sukces dzięki retrospektywom. To świetny sposób na budowanie spójności w zespole i świetny sposób na zastanowienie się nad poprzednim tygodniem i udoskonalenie procesu. Myślę, że jeśli wypróbujesz je ze swoim zespołem, będą bardziej zaangażowani w twoje spotkania.

Witamy w świecie średniego kierownictwa!

Przekonasz się, że tego typu problem dzieje się DUŻO!

Masz 3 opcje:

Big Stick Zrób to, bo jesteś zwolniony - nigdy nie działa. Nie rób tego

Własność Zdobądź je, aby ułatwić spotkania. Cofnij się i wyznacz kogoś innego. Niech będzie to pozycja obrotowa, w której za każdym razem gości inna osoba.

Mów niewypowiedziany Z tego, co powiedziałeś, wszyscy się nudzą - to dlaczego nie zapytać ich o to? Czy jesteś znudzony ? / Czy to strata czasu itp. Dlaczego słyszymy? Jaka jest w tym wartość?

W twoim pytaniu nie było jasne, dlaczego chcesz to zrobić. Jeśli jesteś jedynym, który uważa, że ​​są one cenne, czy chcesz się zmienić? Zapytaj ich, czego chcą. To ludzie oprogramowania, ich zadaniem jest rozwiązywanie problemów przez cały dzień - rozwiąż ten!

Spróbuj zapewnić programistom większą wartość podczas spotkań. Oto kilka przykładów:

• krótkie dema pokazujące nowe funkcje opracowane w ostatnim sprincie. (przedstawione przez wszystkich)
• dyskusja oparta na doświadczeniach, w której mają oni szansę zmienić sposób pracy i ulepszenia zespołu (dyskusja poprowadziła prawą rękę w zespole, a Ty jesteś tutaj, aby uzasadnić swoje decyzje zarządcze. podobnie jak w przypadku sesji wentylacyjnych 1 na 1 ale większe)
• wykład na temat nowego projektu typu open source, który może być odpowiedni lub inny język kodowania, taki jak funkcjonalny Lang lub Golang lub zielone wątki w pythonie. (być może prezentowany przez jednego z młodszych programistów lub w formie wideo online)
• dyskusja prowadzona przez inżyniera sprzedaży opisująca strasznie trudny problem techniczny, który jego klient próbuje rozwiązać. (to samo porozumienie z kierownikiem wsparcia / usług starającym się zmniejszyć koszty wsparcia poprzez poprawę użyteczności produktu)
• żłób, który ujawnia różne strategiczne alternatywy, które firma mogłaby podjąć, i jak wpłynęłaby na inżynierię, biorąc pod uwagę konkurencyjny krajobraz.
• zewnętrzny doradca, który udziela sesji konsultacyjnych na temat technologii, których już używasz, ale nie do maksimum (zwykle nosql, cep, RDBMS, sieci, bezpieczeństwo, monitorowanie ...)
• przegląd kodu, w którym każdy może nauczyć się nowego kodowania, debugowania lub testowania wskazówek dotyczących produktywności (przez tego programistę, który ma 10-krotną produktywność).
• sesja kodowania, w której mysz nie jest dozwolona. Naucz się skrótów IDE.
• rozmowa księgowego na temat pieniędzy 101 kwestie związane z emeryturą, inwestycjami
• rozmawiać o programach społecznościowych i karierze (wymiana stosów, Twitter, github, blogi osobiste, LinkedIn, spotkania w Twojej okolicy)

Czy spotkanie może odbywać się znacznie rzadziej? Napisz swoje wykłady w zwykłym e-mailu i wyślij je wszystkim.

Spotkania odbywają się tylko wtedy, gdy ludzie w nich rzeczywiście mają powód do wzięcia w nich udziału. W przeciwnym razie naprawdę marnujesz czas ludzi.

Nie organizuj długich spotkań i korzystaj z oprogramowania do zarządzania projektami. Jeśli chcesz zainteresować ludzi, skoncentruj się i zaznacz to, co jest ważne, a resztę zapisz dla dzienników i raportów projektu. Skoncentruj się na kamieniach milowych, dostawach, najważniejszych wydarzeniach i celach, a jeśli dotyczy tylko 1/3 osób, odłóż je na wątek dyskusyjny dotyczący projektu.

• Zadbaj o krótkie spotkania
• Wykorzystaj oprogramowanie do zarządzania projektami
• Zachowaj osobisty, celowy i połącz się z emocjami i celami
• Rozwiązywanie problemów w grupach fokusowych, a nie na forach
• Uzyskaj opinie od swoich rówieśników

Nie pozwól też, aby inni wskoczyli do rozmowy i kontynuowali swoją pracę, chyba że ustalą punkty, którymi chcą się zająć. Jeśli chcesz uzyskać informację zwrotną, przygotuj się na nią lub odłóż ją na wątek komentarza w Internecie, gdzie ludzie mają czas, aby się z nim skontaktować. Jest to jedna z najbardziej denerwujących kwestii związanych ze spotkaniami; poświęcanie czasu rówieśnikom z szacunku. Zachowaj te rzeczy na końcu po tym, jak zająłeś się wszystkim, co musisz pokonać.

Podejmij dyrektywę dotyczącą podejścia do zarządzania projektem i zachęcaj do dobrych praktyk rozwojowych, dając przykład.