Disappointment, focus and solution for all problems ;-)

Many of us dream of a situation, when we can work with sustainable pace, having enough time for everything and be able to comfortably do our job. But it doesn’t work. I’ll tell you why.

When you get too comfortable and you have much (time) space for work, you start to distract yourself. You usually say to yourself: “I can dig it a little bit deeper. It would be worth to find out more about it. I should look around for another sources of information. It is necessary to expand my network so I’ll take a look at LinkedIn”. It sounds quite reasonable at first. You start to read about subject A, then you come across another interesting subject B, which turned out to be also important and then the subject C appears. And so on. After a while (sometimes a few days, weeks or even years, you are doing something completely different.  

And there disappointment appears. You start feeling in your guts that you are not doing what you wanted to do. Disappoinment is a kind of emotion that aims to move you a little bit, so that you wouldn’t feel too comfortable. Wow! What a contradiction because you wanted to feel comfortable.

You can imagine such internal dialog:
“Strange. Why this disappointment? I wanted to feel comfortable.”

“But you know you are off course. It’s time to wake up. It’s not fulfilling in a long term. And you might lose your comfort in a while. ”

Sometimes also guilt appears. You wanted comfort, you had gained it and started to lose it. It is not pleasant but it forces you to do something. It is a kind of warning.

 

So the question is: “How can I consciously do it in a different way? How can I develop different kind of warning system." There’s a good news for you. There is such a system already. The main thing is that you want to be sure that you are on course or sometimes you might want to change the course a little bit but doing it with full awareness. And you want to see the progress of your work, this is what gives a sense of purpose and meaning. In other words you want to be strongly focused.

To achieve these goals you may use kanban board (http://en.wikipedia.org/wiki/Kanban_board) and retrospectives (http://agilediary.wordpress.com/2008/12/15/agile-retrospectives-start-stop-continue/). Kanban board gives ability to see what you are doing, to see progress you make, to roughly plan what you want to do. It keeps your focus sharp because it is physical. Our minds distract not having something they can stick to. And retrospectives help you to verify your course and modify if necessary.

The story described above applies also to teams. It’s quite common that teams after weeks of very hard overhours work tend to do their job many weeks in a very lazy manner, which is not good for anybody in a longer term. Such kind of work is simply not satisfying.

So, stay focused, feel fulfilled.

P.S. (This is first time I write in English and this is direction I decided to choose for my later writings. Now it is experimental activity and I am sorry for language mistakes in advance. Have a good fun!)

Read More

Unknown 10:10  3 comments

Budowanie wiedzy w zespole. Główne błędy i strategie.

Temat zarządzania wiedzą w zespole to obszar pustynny jeśli chodzi o liderów IT. Jest takie ciche założenie, że to dzieje się samo. I rzeczywiście w pewnym stopniu się dzieje, bo jako programiści jesteśmy przyzwyczajeni do tego, że w naszej działce, trzeba cały czas poznawać nowe rzeczy, żeby się utrzymać na fali. Jednak to nie wystarcza. Nie wystarczy, że każdy (a w rzeczywistości połowa), będzie coś tam sobie poznawać na własną rękę. Jeśli zespół ma działać efektywnie, potrzebna jest spójna i aktualna wiedza. I w tym przypadku wiedza o nowych technologiach/rozwiązaniach ma niewielką (choć pewną ma) wartość.

Zatem drogi liderze - świadome kierowanie rozwojem wiedzy w zespole jest ważne. Jest to często spychane na dalszy plan albo w ogóle ignorowane, no bo to nie jest kodowanie, trudno wrzucić w harmonogram, a poza tym ludzie sobie jakoś radzą. No właśnie, jak zwykle diabeł tkwi w szczegółach i to "jakoś" robi wielką różnicę. Osobiście najlepiej funkcjonujące zespoły, które spotkałem, miały bardzo dobrze rozwinięty sposób zarządzania wiedzą w zespole.

Dlaczego to ważne? Oto wybrane patologie, które się zdarzają i heurystyki, które się bardzo dobrze sprawdzają:

• brak dokumentacji odnośnie architektury - Tak... tak... wszyscy obecnie jesteśmy Agile, więc dokumentacja nam nie jest potrzebna. Czas definitywnie skończyć z takimi wymówkami. Dokumentacja jest potrzebna i to bardzo. Szczególnie ta high level. Mam na myśli rysunki, które z lotu ptaka dokumentują system - diagram/rysunek kontekstowy, diagram/rysunek komponentów, mantra architektoniczna, diagram/rysunek głównych mechanizmów, które stworzyliśmy (czytaj: frameworków). Jeśli nie ma tego typu dokumentów, rozmowa o rozwiązaniach, zmianach w systemie czy wprowadzenie nowej osoby jest szczególnie trudne, no bo gdzie jest wspólny punkt odniesienia, skąd wiemy, że mówimy o tym samym, skąd wiemy, jak nasz system jest zbudowany? Dokumentacja low level (diagramy sekwencji, diagramy dokumentujące konkretne funkcjonalności) jest nam potrzebna mało, jest to raczej dokumentacja tymczasowa, przydatna na czas dewelopmentu, więc wystarczy prosty rysunek adhoc na tablicy;
• brak strategii wprowadzenia nowych osób - czasami nawet jest, ale rzadko jest to robione dobrze. Najczęściej (jeśli taka strategia jest) polega ona na kilkudniowym chaotycznym wprowadzeniu, które i tak w większości schodzi na sprawy organizacyjne (procedury firmowe), skonfigurowanie środowiska, repo itp. No i może kilka słów o systemie... "A resztę znajdziesz w kodzie". I co taki gość robi? Poznaje system na podstawie kodu. Zamiast 2 tygodnie spędza na tym 3-4 miesiące, żeby mniej więcej zorientować się jak działa system, z jakich klocków jest zbudowany, jakie rozwiązania są preferowane w danym zespole, a które nie, na czym mniej więcej polega dziedzina, której system dotyczy. Tak! Poznawanie samodzielnie systemu, jest kilkukrotnie (często o rząd wielkości) dłuższe niż wprowadzenie poprowadzone przez osobę z zespołu (tzw. mentoring). "No tak, ale ktoś musi poświęcić na to tyle a tyle czasu, zamiast kodować".
  
  Tutaj najczęściej liderzy/kierownicy nieświadomie stosują lokalną optymalizację, która polega na tym, żeby nową osobą jak najszybciej zutylizować. A co z tego, jeśli przez pierwsze miesiące taki delikwent jest po prostu niewydajny.
  
  Oprócz strategii wprowadzania osób (czyli 2-3 tygodniowego planu określającego co, kiedy, od kogo i jak dużo powinien taki delikwent się nauczyć), potrzebna jest realizacja poprzedniego punktu - czyli dobra dokumentacja high level, która znacząco skraca czas potrzebny na wprowadzenie nowej osoby do projektu. ALE! Ważne bardzo jest do, że dokumentacja nie służy jako dokument do przeczytania ("No to masz - zapoznaj się"), ale jako narzędzie do dyskusji w rękach mentora. Sam dokument, nawet najlepszy, jest nic nie wart;
• ludzie nie znają kodu/systemu - ten problem jest naturalną konsekwencją powyższych dwóch problemów. Ponieważ ludzie się słabo orientują w systemie, mają fragmentaryczną wiedzę, toteż tracą mnóstwo swojego czasu na szukanie, a także czasu innych poprzez ciągłe dopytywanie. Poza tym ponieważ muszą uczyć się systemu "na żywo", najczęściej powielają rozwiązania, które znajdują, nie zawsze rozróżniając, które są pożądane, a które nie;
• brak spójnych zasad - obecnie uwspólniony standard kodowania w zasadzie stał się (nomen omen) standardem, jednak to nie wystarcza. Ponieważ jest wiele innych czynników, które wpływają na czytelność kodu czy też czystość architektury, które powinny być uspójnione - weźmy chociażby zasady czystego kodu, stosowane wzorce implementacyjne, bloki budujące (mantra architektoniczna). Jeśli to nie zostało ustalone i nie jest monitorowane w efekcie powoduje erozję architektury poprzez powstające niespójne rozwiązania. To jest praktycznie nieodczuwalne na początku, jednak wraz ze wzrostem skali projektu oraz upływem czasu, uzyskujemy efekt kuli śnieżnej;
• brak wymiany wiedzy w zespole/zespołach - często nie ma czasu czy też pieniędzy na szkolenia, natomiast mam wrażenie, że liderzy/kierownicy nie doceniają najcenniejszego narzędzia, jakie posiadają - wiedzę i doświadczenia ich własnych ludzi zdobytych na ich własnym projekcie. Czy jest gdzieś lepsze źródło dopasowanej do zespołu wiedzy? Stwórz zatem środowisko wymiany wiedzy - niech częścią review będzie zgłaszanie dobrych rozwiązań, które warto rozpowszechniać, twórz bazę przykładów kodu (np. jak wygląda dobrze napisany serwis, kontroler), stymuluj organizowanie wewnętrznych, krótkich szkoleń typu "czego się nauczyliśmy korzystając z biblioteki X", umożliwiaj pracę parami - nawet jeśli nie cały czas, to na początku i na końcu tworzenia rozwiązania. Ponieważ nie wszyscy programiści potrafią dobrze pracować razem - czasem trzeba włożyć wysiłek, aby ich tego nauczyć - chociażby tego, jak znaleźć wspólne rozwiązanie, kiedy mamy różne zdania.
  
  Zbudowanie środowiska ciągłej nauki powinno być jednym z głównych Twoich celów, liderze. Będziesz miał zmotywowanych i efektywnych ludzi, którzy będą tworzyć spójne rozwiązania.
  Co dostaniesz, jeśli nie zorganizujesz takiego procesu? Pewnie to znasz - będą powstawać implementacje tych samych mechanizmów w różnych miejscach. Będziesz miał problem, kiedy ktoś Ci odejdzie z zespołu, bo wiedza i doświadczenia będą skumulowane w poszczególnych osobach.
  
  Brak wymiany wiedzy, to brak motywacji, nudne środowisko, więc z czasem rotacja będzie dawała się we znaki, więc i wypływ wiedzy i doświadczenia będzie większy. Poza tym poziom merytoryczny Twojego zespołu będzie spadał. Tak naprawdę będzie stał w miejscu, a w działce programistycznej to oznacza regres;
• brak aktualizacji wiedzy o systemie - każdy programista czy lider, która ma już kilka lat doświadczenia za sobą, wie, że systemy się zmieniają - dużo szybciej niż nam się wydaje i najczęściej w innym kierunku niż przewidywaliśmy. Toteż ustalenia odnośnie architektury systemu, stosowanych bibliotek, mechanizmów - będą modyfikowane. Liderzy najczęściej zapominają o tym, że trzeba włożyć energię, aby zmiana została wdrożona i było utrzymana. Często powtarzanym błędem jest to, że tylko liderzy i (główni) architekci wiedzą w jaką stronę zmierza system i jaka jest obecna "poprawna wersja architektury". Czasem nawet zapominają to ogłosić (absurdalne, prawda?). Czasem napiszą maila lub wyślą dokument... A to za mało.
  
  Po pierwsze należy zebrać feedback od ludzi, odnośnie tego, jakie widzą trudności we wdrażaniu, jakie potrzebne są im zasoby. Po drugie należy przez pierwszy okres wdrażania znaleźć sposób monitorowania zmian. Szczególny nacisk na zmiany podczas przeglądów kodu, listy weryfikacyjne (checklisty) kluczowe założenia. I retrospekcje, które poprzez anlizę problemów i sukcesów, pozwolą monitorować efektywność wprowadzania zmian.
• brak miejsca na zdobywanie nowej wiedzy - wiele firm ma strategie - u nas ludzie sami się uczą. To jest bardzo w porządku. Sam jestem przedstawicielem tej rasy;-) Jednak takie podejście ma pewne wady.
  
  Po pierwsze - jeśli uczysz się sam, to ograniczasz się tylko do kontekstu, który znasz, trudno jest poza niego wyjść. W związku z tym trudniej o istotnie inne, nowatorskie rozwiązania, inne podejście do rozwiązywanych problemów, gdyż twoja percepcja jest ograniczona poprzez dotychczasowe doświadczenia. Po drugie samodzielne uczenie się najczęściej ma charakter fragmentaryczny, zdobywa się dużą ilość informacji, ale trudno je poskładać w spójną całość. Dlatego samouctwo prowadzi do efektu, że ma się wrażenie, że cały czas jeszcze jest bardzo dużo do poznania. Trudno określić, co jest rzeczywiście ziarnem, a co jest chwastem. Trzeba często kilku lat doświadczenia, aby nabrać umiejętności rozróżniania i stwierdzenia: to już wystarczy. Po trzecie inne osoby są najlepszym źródłem inspiracji, której nie zastąpi praca indywidualna. Większość naszych pomysłów, ma źródło w kontaktach z innymi osobami, jeśli nie osobiście (co uważam za najbardziej efektywne), to poprzez sieć.
  
  Dlatego nawet szkolenia, konferencje czy wydarzenia, które nie są w 100% związane z tym czym programiści zajmują się na co dzień, mają ogromną wartość. Twoim zadaniem lidera, jest zogniskowanie, skatalizowanie zdobytej wiedzy, doświadczenia: chociażby poprzez pytanie: "Jak to czego tam się dowiedziałeś, możesz wykorzystać?". I nie dawać się zbyć szybkimi, prostymi odpowiedziami. Drąż, a zdobędziesz bardziej świadomego członka zespołu.

Poniżej mała ściąga.

A tu wersja z książki Technical Leadership:

Read More

Unknown 13:04  6 comments