03 listopada 2010

Samodoskonalenie zwinnych zespołów

3 dni wolnego, to doskonały moment, aby się chwilę zastanowić. Można się było nawet zastanawiać, nad czym by się tu zastanowić (!) Szacunek dla szczęśliwców.

Mnie wzięło na rozmyślania o terminie samodoskonalenie w połączeniu ze zwinnym zespołem. Wciąż rozmyślam, jakich sposobów używać, aby zachęcić do większej aktywności w ramach społeczności typu Warszawa JUG. Niby jest ponad 400 członków, a ruch na grupie, jakby było nie więcej niż 50. Czyżby pozostali nie posiadali własnego zdania?! Niemożliwe.

W tym kontekście, rozmyślam, jak wyglądałby mój doskonały zespół, gdyby mi przyszło prowadzić jakiś. Czy byłby zwinny i tym samym samodoskonalił się? Jak stałby się zwinny? I kiedy mógłbym stwierdzić, że jest samodokonalający się?

W moim przekonaniu samodoskonalenie jest wpisane w kontrakt zwinnego zespołu. Po prostu, jeśli jesteś zwinny (technicznie), to musisz się ciągle rozwijać. Możnaby postawić tezę, że siła zwinności liczona jest przez ilość czasu poświęcanego na rozwój siebie i "okolicy". Od ludzi posiadających taką cechę, czym ona mocniejsza, tym bardziej emanuje na innych. Taki zespół nie czeka na prośbę podzielenia się wiedzą, ale robi to regularnie i otwarcie. Jednym z "objawów" jest m.in. posiadanie własnego bloga (przez "własny" rozumiem taki, z którym się identyfikujemy - rzeczywiście własny lub całego zespołu).

Mam nieodparte wrażenie, że powszechnie pojęcie zwinnego zespołu kojarzy się głównie z posługiwanymi się narzędziami i technikami, które określa się jako zwinne - techniki Agile. Uważam, że to tylko jeden z trybików. Zgodnie z definicją słowa na pwn.pl "zwinny" to 1. «wykonujący szybkie, zręczne ruchy», 2. «o ruchach, poruszaniu się kogoś lub czegoś: szybki i zgrabny». Dokładnie odpowiada mojemu postrzeganiu zwinnego zespołu - jest zręczny, szybki i zgrabny (wszystko w kontekście jego "wyglądu" i zachowania stricte technicznego)

W moim rozumieniu zręczność techniczna zespołu jest cechą jego przygotowania do zastosowania odpowiedniego narzędzia do problemu. Tutaj liczy się znajomość wszystkich "cudów świata" - czym więcej języków programowania, bibliotek, szkieletów, produktów, tym lepiej. Niech znajomość ich będzie pobieżna, ale wystarczająca do podjęcia decyzji o zastosowaniu jednego vs drugiego.

Szybkość zespołu jest cechą, w której sama znajomość jest poparta pewnością wyboru narzędzia i umiejętnością jego wdrożenia - implementacji. Z szybkością kojarzy mi się bardziej pewność działania (ale nie arogancja!) niż czas. Tutaj liczy się posiadanie speców od danej technologi, którzy wykazują się większą niż przeciętna znajomością tematu. Nie oznacza to jednak, że całe ich dnie wyglądają podobnie - wciąż wałkują ten sam temat, a raczej szczególniej mu się przyglądają. Powiedzmy, że ta szczególność polega na poświęceniu tematowi 20% więcej czasu.

Zgrabność zespołu jest cechą, w której umiejętnie dopasowuje się do sytuacji. "Ciągłe ćwiczenia są kluczem do sukcesu" świetnie tutaj pasuje. Ciągłe próbowanie się z nowym i ciągłe dzielenie się wiedzą, aby w końcu ciągle następował przepływ wiedzy, którą można korygować, wzbogacać i ostatecznie zastosowywać. Niech wiedzą, kto wie, abyśmy wiedzieli, że wiemy :) Łatwo wpaść w zniechęcenie, kiedy człowiek sobie uzmysławia, jak niewiele wie. Pozytywne sygnały z zewnątrz mogą być niezwykle motywujące.

Kluczem jest wiedza i chęć jej zdobywania.

To, ile czasu poświęcamy na poznawanie, zależy wyłącznie od nas samych. To, ile czasu poświęcamy na dzielenie się wiedzą, również. Zastanawiam się więc, skąd tak niewielu z nas ma na to ochotę? Poznawajmy, próbujmy, dzielmy się wynikami, spostrzeżeniami i dyskutujmy. Niech Ci, co wiedzą, wiedzą, że my nie wiemy, a Ci, którzy nie wiedzą, wręcz przeciwnie, wiedzieli, że my wiemy. W końcu musi nadejść moment, w którym komuś zacznie się wszystko składać w coś sensownego i podzieli się z innymi, oszczędzając nam wysiłku, abyśmy mogli zabrać się za kolejny problem.

W jaki sposób uczyć się? Polecam czytanie, duuuużo czytania. Kiedy skończy się czytanie, warto podzielić się swoimi przemyśleniami - zacznijmy od bloga, w postaci krótkiej notki, albo wręcz mikrobloga (ala twitter lub delicious), gdzie pojawi się choćby ślad naszej aktywności w danym obszarze. Może też być podczas 30-minutowego spotkania zespołu pod koniec tygodnia, np. w czwartek, albo wystąpienia na spotkaniu JUGowym (mamy ich ponad 10 w Polsce!) W zasadzie, niech będzie wszystko po trochu. Czym szybciej wyłożymy nasze problemy do publicznego osądu, tym szybciej uda nam się dotrzeć do rozwiązania. Ludzie z natury są życzliwi i chcą pomóc. Są jednocześnie samolubni, więc widząc, że jest gość, który przygotuje, a później zreferuje, przyjdą i zadadzą pytanie bądź dwa. W ten sposób, osoba ucząca się zdobędzie postrzeganie innych, a oni w zamian dostaną naszą relację, nasze streszczenie tematu. Obie strony będą usatysfakcjonowane. Nikt nie traci.

Podsumowując: uczmy się i innych. Starajmy się dzielić wiedzą i inspirować innych do działania, ciągłego działania. Jeśli on to robi i Ty zaczniesz, to koniec końców znajdą się wreszcie inni, którzy widząc naszej sukcesy, zechcą pójść w nasze ślady (porażki również odnotowujemy w kolumnie sukcesów, bo nic tak nie "pionuje" jak solidna dawka porażki). Któż nie chciałby osiągać celu krócej? Satysfakcja gwarantowana.

Zastanawiasz się, od czego należałoby zacząć?! Zakładasz bloga i raz w tygodniu umieszczasz podsumowanie swojej tygodniowej działalności (nie masz co pisać, powinno być odczytywane jako strata tygodnia i pora zabrać się za inne, bardziej twórcze zajęcie). Potraktuj każde z wykonywanych czynności, jako możliwość nauki. Chcą, abyś coś sprawdził, sprawdź i jeszcze dodaj coś od siebie, np. niech to kolejnym razem będzie automatycznie, albo niech będzie spisane. Pomyśl o spotkaniach zespołu, podczas których dzielicie się ostatnimi doświadczeniami - coś ala retrospekcja, czy podsumowanie iteracji, czy jak to tam się mogłoby nazywać. Chodzi o bezpośredni kontakt z zespołem. Gdzieś ostatnio przeczytałem (w wolnym tłumaczeniu) "Skoro już jesteś, bądź zauważonym". Lans jeszcze nikomu nie zaszkodził :) Tylko z umiarem.

Sądzę, że po kilku tygodniach śmiało można będzie nazwać Cię liderem zwinnego zespołu. Gratulacje!

3 komentarze:

  1. Widzę, że zainspirował cię mój speech na warsjawie ;-)

    OdpowiedzUsuń
  2. Wszystko/wszyscy razem i trudno mi wskazać faworyta. Mimo wszystko, Tobie należą się słowa uznania za trud oświecania. Ave!

    OdpowiedzUsuń
  3. Kilka moich mniej lub bardziej (mam nadzieję :P) sensownych komentarzy:
    - "W moim przekonaniu samodoskonalenie jest wpisane w kontrakt zwinnego zespołu. Po prostu, jeśli jesteś zwinny (technicznie), to musisz się ciągle rozwijać."
    Oczywiście w 100% się zgadzam. Większość PM'ów niekoniecznie byłaby szczęśliwa z trafności owego stwierdzenia, gdyż dla nich liczy się jak najszybszy rezultat. Pracownik próbujący usilnie dopieścić swój kod, co zajmuje mu 4 godziny i nie przynosi korzyści funkcjonalnych w systemie, nie wydaje się być zbyt produktywny. Swoją drogą, któryś z prelegentów na Javarsovii 2010 wspomniał, że zawsze zakłada, iż programista pracuje nad projektem 4 godziny dziennie. Resztę czasu (4 godziny) spędza na kawie lub uczeniu się nowych technologii.

    - "Zakładasz bloga i raz w tygodniu umieszczasz podsumowanie swojej tygodniowej działalności (nie masz co pisać, powinno być odczytywane jako strata tygodnia i pora zabrać się za inne, bardziej twórcze zajęcie)"
    Uwaga bo w niektórych przypadkach może to oznaczać zmianę pracodawcy :P. A tak bardziej poważnie to projekty biznesowe często irytują mnie właśnie przez tego typu tygodnie. Mało w nich rzeczywiście technologii, a masa "if'ów" (www.antiifcampaign.com) i zależności czysto biznesowych. W mojej krótkiej jak na razie karierze bywały z pewnością tygodnie spędzone nad daną formatką, gdzie niczego się nie nauczyłem. Mój ratunek polega na czytaniu ebook'ów. Zawsze mam coś otwartego i czytam podczas deploy'u aplikacji, czy też gdy muszę uwolnić nad chwilę umysł od rzemieślniczej pracy.

    Wreszcie odnośnie JUG i wystąpień. Myślałem o tym kilka razy. Nie byłem na zbyt wielu spotkaniach, ale odczuwam potrzebę odwzajemnienia się choćby za nieświadomą pomoc jakiej udzielił mi Bartek Zdanowski swoją prelekcją na temat Openfire. Powstaje jednak problem o czym opowiadać oraz czasu wymaganego na przygotowanie :P. Od razu powiem, że po lutym 2011 (z powodu mgrrrrr) mógłbym wspomnieć kilka słów na jakiś temat.. Tylko czy kogoś interesuje PL/SQL :P?

    Fajny tekst Jacek. Trafiłeś w sedno.

    Pozdrawiam,
    Łukasz Antoniak
    http://lukaszantoniak.wordpress.com/

    OdpowiedzUsuń