Ostatnio coraz więcej pracuję z liderami zespołów programistycznych i mocno mnie zastanawia temat dynamizmu i najczęściej idącej za nią charyzmy lidera.
Z czym najczęściej kojarzy się dynamizm - z osobą, która jest bardzo energiczna, bardzo szybko mówi, bardzo szybko myśli, działa. Tymczasem dostrzegam, że szczególnie w projektach programistycznym, większość liderów i to takich, KTÓRZY RZECZYWIŚCIE SĄ ŚWIETNI W TYM CO ROBIĄ, taka nie jest. A ludzi ich słuchają, podążają za nimi i skupiają ogromną ilość uwagi.
Kilka dni temu doświadczyłem następującej sytuacji, która w efekcie spowodowała olśnienie. Ponieważ ostatnio rekrutujemy intensywnie, toteż pewnego dnia brałem udział w procesie rekrutacyjnym dwóch osób. Jedna z nich była dość wyciszona, zrównoważona, zaś druga bardzo energiczna.
Co się okazało na spotkaniu - w tym drugim przypadku mimo ogromnej energii, wypowiadanych setek słów na sekundę, pozostali uczestnicy spotkania poczuli się szybko znużeni. Po piętnastu minutach już zwyczajnie odpływałem. Wysoka energia z czasem zmieniała się w monotonny (!) usypiający szum.
Druga osoba dość powoli odpowiadała na pytania, często zadawała pytania, tym samym wciągając nas w rozmowę. Dwie godziny minęły, nawet nie wiedziałem kiedy... i chciałem jeszcze.
- WTF? - pomyślałem. - JAK TO MOŻLIWE, ŻE ENERGICZNY GOŚĆ NAS ZNUŻYŁ, A MNIEJ ENERGICZNY, ZRÓWNOWAŻONY WCIĄGNĄŁ W TO, O CZYM MÓWIŁ I CO MÓWIŁ.
W pewnym momencie doznałem olśnienia! DYNAMIKA. To dynamika sprawia, że angażujemy się w to, co się dzieje. Tylko uwaga! Słowo dynamika jest tu bardzo niebezpieczne, bo niesie ze sobą potoczne niezbyt precyzyjne skojarzenie. Idąc za definicją DYNAMIKI dzwięku z wikipedii (http://pl.wikipedia.org/wiki/Dynamika_%28elektroakustyka%29) jest ona duża wtedy, kiedy raz jest cicho, raz głośno, idąc dalej - raz powoli, raz szybko. Dlatego ludzie charyzmatyczni to ludzie dynamiczni, co wcale nie oznacza, że głośni. Jedną ze sprytnych metod na uspokojenie niemowlaka jest włączenie mu czegoś jednostajnie głośnego (np. odkurzacza), dziecko łatwo usypia. Jednostajny hałas, głośność usypia!
Szczególnie w IT hałas nie ma to większego sensu, gdyż trzeba podejmować przede wszystkim racjonalne decyzje. JEŚLI CHCESZ ABY LUDZIE CIĘ SŁUCHALI Z CIEKAWOŚCIĄ, PODĄŻALI ZA TOBĄ, Z PEWNOŚCIĄ MUSISZ NAUCZYĆ MÓWIĆ I DZIAŁAĆ DYNAMICZNIE, I WCALE NIE OZNACZA TO, ŻE MUSISZ BYĆ GŁOŚNY, TRYSKAJĄCY POTOKIEM SŁÓW :)
piątek, 31 sierpnia 2012
Tagged under: efektywność, rozwiązywanie problemów, software craftsmanship, strategie doskonałości
Nie bądź zbyt szybki, zacznij myśleć!
Czasami sobie myślę, że świat obecnie stał się zbyt szybki. Wszystko wokół dzieje się tak szybko, iż wskakujemy na autopilot i przestajemy myśleć dlaczego i po co robimy dane zadanie, czy muszę je robić w taki sposób w jaki sobie wymyśliłem albo ktoś mi wymyślił.
Jest to tym bardziej niebezpieczne w pracy programisty, ze względu na wskakiwanie po kilkunasty minutach w stan transowy, wtedy to już stajemy się kompletnie bezmyślni...
Pewnie sobie mówisz: "Ale gość pierdzieli - przecież programowanie to ciągłe myślenie, wymyślanie koncepcji, rozwiązań, weryfikowanie, muszę powiązać ze sobą 10 bibliotek jednocześnie i uwzględniać wydajność mojego kodu. Cały czas do cholery muszę myśleć!"
Masz rację. Warto jednak rozróżnić kilka rzeczy, nad którymi musisz myśleć, aby zrobić to, co masz do zrobienia:
* dlaczego i po co robię TO - to jest kluczowe pytanie, szczególnie, jeśli pracujesz w zmiennym środowisku, gdzie zadania bombardują Cię z wielu stron (np. utrzymanie, ale też w dziale programistycznym, który dostaje "luźne" zlecenia z różnych departamentów), czy rzeczywiście jest to tak bardzo potrzebne, co się stanie z efektem pracy jak ją wykonam, czy jak odłożę to zadanie z determinacją, czy ktoś będzie wkurzony? A jeśli tak to dlaczego? Czy tylko dlatego, że nie zrobiłeś tego zadania, czy dlatego, że "czyjeś życie z tego powodu ucierpi"? Często nawet 30-40% zadań jest niepotrzebnych. Tak! A wiesz dlaczego? Bo Ci którzy je zlecają, nie MAJĄ CZASU, aby przemyśleć ich sensowność. Oczywiście to nieprawda, że nie mają czasu, oni go po prostu na to NIE POŚWIĘCAJĄ.
* jak chcę podejść do zrobienia tego CZEGOŚ - często to, co mamy do zrobienia, można zrobić na wiele różnych sposobów. Np. daną funkcjonalność, która polega na zebraniu złożonych informacji mogę zrealizować za pomocą jednego formularza lub kreatora. Daną usługę mogę zrobić za pomocą kilku ifów lub za pomocą wzorca Strategii. Czy warto sięgać po ten wzorzec lub jakieś inne niesamowicie elastyczne (i pozornie eleganckie) rozwiązanie, kiedy jeśli się dobrze zastanowić już nigdy nikt nie wróci do tego kodu. I przeciwnie czy warto wstawiać kilka ifów, jeśli wiadomo, że np. będą się pojawiać wraz z rozwojem aplikacji kolejne wersje algorytmów, które będą działały inaczej. Czy wtedy wzorzec Startegii nie będzie bardziej adekwatny?
* jak chcę TO wykonać - czyli jakich klas, jakich bibliotek, jakich konstrukcji użyć, jak to napisać.
W najlepszym przypadku, na autopilocie, odpowiadamy sobie co najwyżej na pytanie, jak chcę konkretnie TO wykonać. Wtedy wpadamy wir rozwiązywania problemów, przeskakiwania z jednego pomysłu do drugiego. Rozważania tysiąca szczegółów. Bo tak jest szybciej. Ale w tym przypadku szybko oznacza bezmyślnie. Robisz dużo i natychmiast, ale BEZ SENSU (no dobrze - bez przeanalizowania sensu samego zadania - HA!).
Nie bądź zbyt szybki, zacznij myśleć :)
Jest to tym bardziej niebezpieczne w pracy programisty, ze względu na wskakiwanie po kilkunasty minutach w stan transowy, wtedy to już stajemy się kompletnie bezmyślni...
Pewnie sobie mówisz: "Ale gość pierdzieli - przecież programowanie to ciągłe myślenie, wymyślanie koncepcji, rozwiązań, weryfikowanie, muszę powiązać ze sobą 10 bibliotek jednocześnie i uwzględniać wydajność mojego kodu. Cały czas do cholery muszę myśleć!"
Masz rację. Warto jednak rozróżnić kilka rzeczy, nad którymi musisz myśleć, aby zrobić to, co masz do zrobienia:
* dlaczego i po co robię TO - to jest kluczowe pytanie, szczególnie, jeśli pracujesz w zmiennym środowisku, gdzie zadania bombardują Cię z wielu stron (np. utrzymanie, ale też w dziale programistycznym, który dostaje "luźne" zlecenia z różnych departamentów), czy rzeczywiście jest to tak bardzo potrzebne, co się stanie z efektem pracy jak ją wykonam, czy jak odłożę to zadanie z determinacją, czy ktoś będzie wkurzony? A jeśli tak to dlaczego? Czy tylko dlatego, że nie zrobiłeś tego zadania, czy dlatego, że "czyjeś życie z tego powodu ucierpi"? Często nawet 30-40% zadań jest niepotrzebnych. Tak! A wiesz dlaczego? Bo Ci którzy je zlecają, nie MAJĄ CZASU, aby przemyśleć ich sensowność. Oczywiście to nieprawda, że nie mają czasu, oni go po prostu na to NIE POŚWIĘCAJĄ.
* jak chcę podejść do zrobienia tego CZEGOŚ - często to, co mamy do zrobienia, można zrobić na wiele różnych sposobów. Np. daną funkcjonalność, która polega na zebraniu złożonych informacji mogę zrealizować za pomocą jednego formularza lub kreatora. Daną usługę mogę zrobić za pomocą kilku ifów lub za pomocą wzorca Strategii. Czy warto sięgać po ten wzorzec lub jakieś inne niesamowicie elastyczne (i pozornie eleganckie) rozwiązanie, kiedy jeśli się dobrze zastanowić już nigdy nikt nie wróci do tego kodu. I przeciwnie czy warto wstawiać kilka ifów, jeśli wiadomo, że np. będą się pojawiać wraz z rozwojem aplikacji kolejne wersje algorytmów, które będą działały inaczej. Czy wtedy wzorzec Startegii nie będzie bardziej adekwatny?
* jak chcę TO wykonać - czyli jakich klas, jakich bibliotek, jakich konstrukcji użyć, jak to napisać.
W najlepszym przypadku, na autopilocie, odpowiadamy sobie co najwyżej na pytanie, jak chcę konkretnie TO wykonać. Wtedy wpadamy wir rozwiązywania problemów, przeskakiwania z jednego pomysłu do drugiego. Rozważania tysiąca szczegółów. Bo tak jest szybciej. Ale w tym przypadku szybko oznacza bezmyślnie. Robisz dużo i natychmiast, ale BEZ SENSU (no dobrze - bez przeanalizowania sensu samego zadania - HA!).
Nie bądź zbyt szybki, zacznij myśleć :)
Subskrybuj:
Posty (Atom)
