sobota, 8 listopada 2014

W tym tygodniu w pracy na przypdatkowo wziętym kubku przeczytałem taki tekst:

"Nie ograniczaj się! Co byś robił gdybyś wiedział, że porażka jest niemożliwa? Czy byłoby to co robisz obecnie?"

Inne, ciekawe zadanie, które wiąże się się z tym wyżej, usłyszałem na dotNetConfPL 2014 w nagraniu Patryk Góralowski - Talent za 2 dolary. Skusisz się!:

"Dopóki robisz to co zawsze - będziesz miał to co zwykle!"

poniedziałek, 12 maja 2014


"Rozpoczęcie pracy od połknięcia "żaby" gwarantuje przez cały dzień poczucie zadowolenia wynikającego ze świadomości, że już nic gorszego nie może ci się dzisiaj przytrafić
Brian Tracy "Zjedz tę żabę."

Zjadłem tą żabę, kęs po kęsie, słuchając audiobooka w samochodzie, w każdym momencie, kiedy tylko moja podróż była dłuższa od przeciętnej długości jednego rozdziału czyli od około 5 minut i 45 sekund..

Audiobook jest profesjonalnie nagrany. Intonacja oraz dykcja czytającego ułatwia utrzymać uwagę na czas całego rozdziału. Podczas słuchania nie łapałem się na tym, że od kilku minut myślę o czymś kompletnie innym, nie pamiętając ni w ząb co było w danym rozdziale.

Przesłuchanie tego audiobooka nie można jednak porównywać do zjadania żaby, a bardziej do wypijania zimnego piwa, łyk po łyku.

Jest masa książek na temat samo-motywacji i organizacji swoich zadań w czasie. Prawdopodobnie w większości z tych książek jest coś wartościowego co gdyby się zastosowało, to odniosłoby się sukces lub chociaż do niego zbliżyło. Trzeba jednak czytać tylko książki bardzo dobre, bo na dobre brakłoby nam życia. Uważam, że książka "Zjedz tę żabę" należy do książek bardzo dobrych.

21 Technik poprawiających wydajność w pracy oraz przy okazji spis treści:
1. Nakryj do stołu
2. Planuj każdy dzień z wyprzedzeniem
3. Stosuj zasadę 80/20 gdzie się da
4. Zastanów się nad konsekwencjami
5. Zwlekanie kontrolowane
6. Nieustannie stosuj metodę ABCDE
7. Koncentruj się na zagadnieniach kluczowych
8. Prawo trzech zadań
9. Dobrze się przygotuj, zanim rozpoczniesz
10. Krok po kroku, czyli od beczki do beczki
11. Podwyższaj swoje kwalifikacje
12. Okaż swoje szczególne zdolności
13. Rozpoznaj swoje główne ograniczenia
14. Zmobilizuj się
15. Maksymalne wykorzystanie energii 
16. Zmuś się do działania
17. Nie daj się uzależnić technice
18. Plasterki salami i ser szwajcarski
19. Strategia wydzielania czasu
20. Stan wyższej konieczności
21. Każde zadanie traktuj indywidualnie

środa, 5 marca 2014

Według Prince 2, cel to pożądany stan, który powinien zaistnieć we wskazanym terminie.

Sukcesywne osiąganie kolejnych celów, które regularnie sobie wyznaczamy, jest bardzo ważne zarówno w pracy jak i w życiu prywatnym.

Uczestnictwo w szkoleniu Pronce 2 pozwoliło mi trochę inaczej spojrzeć na definiowanie i osiąganie celów. Metodyka ta w swojej definicji dokonuje jasnego rozróżnienia między celem, a korzyściami związanymi z osiąganiem danego celu.

Uważam, że każdy z nas często popełnia ten błąd, że zamiast wyznaczać sobie cel, który będziemy osiągać wyznaczamy sobie korzyść jaką chcemy mieć. Łatwo się domyśleć, że od samego chcenia jakiejś korzyści ona sama się nie pojawi. Należy najpierw osiągnąć cel w wyniku, którego odetniemy kupony z korzyściami.

Przykład korzyści, którą błędnie traktujemy jako cel: "Chcę jeździć motorem na wycieczki."

Przykład jednego z celów, którego osiągnięcie da nam wyżej zdefiniowaną korzyść: "Zdanie egzaminu na prawo jazdy kategorii A."

Według Prince 2: cel określa "CO?", nie próbując podpowiedzieć "JAK?" Cel powinien być SMARTER:

  • Specific - ściśle określony
  • Measurable - mierzalny
  • Agreed - uzgodniony
  • Reasonable - racjonalny
  • Time-framed - umieszczony w ramach czasowych
  • Exciting - ekscytujący
  • Recorded - zapisany
Natomiast według dr Kena Blancharda cel powinien być: KOMOZI:
  • Konkretny i wymierny
  • Motywujący
  • Znaczący
  • Identyfikowalny
Należy tutaj dodać, że Prince 2 definiuje cel pod kątem projektu, a dr Kena Blanchard pod kątem motywacji pracowników. Ja uważam, że niezależnie od kontekstu cel powinien posiadać przynajmniej wszystkie jedenaście wyżej wymienionych przymiotników.

niedziela, 9 lutego 2014

Kilka lat temu, ucząc się programowania w języku C++, natknąłem się na ten tekst. 

"Komputery są jedynie urządzeniami elektronicznymi. Nie mają pojęcia o oknach czy menu, nie znają programów ani instruk­cji, a nawet nie wiedzą nic o zerach i jedynkach. W rzeczywistości jedyne zmiany, jakie zauważają, to zmiany napięcia mierzonego w odpowiednich punktach układów elektronicznych. Nawet to jest dla nich pewną abstrakcją: w rzeczywistości elektryczność jest tylko wygodną intelektualną koncepcją dla zaprezentowania działania cząstek subatomowych, które z kolei są abstrakcją dla czegoś inne­go."

"C++ dla każdego" Jesse Liberty

środa, 5 lutego 2014

Tworzenie historyjek użytkownika to pomysł twórców Extreme Programming (EX) czyli Kenta Becka i Martina Fowlera, który został później przejęty przez Scruma jako jeden z artefaktów. Historyjki realizują manifest Agile a w szczególności dwa jego elementy:

Działające oprogramowanie ponad obszerną dokumentację.
Współpracę z klientem ponad formalne ustalenia.

Przykładowy szablon historyki:

JAKO <TYP UŻYTKOWNIKA> CHCĘ WYKONAĆ <NAZWA ZADANIA> ŻEBY OSIĄGNĄĆ <CEL>.

Inny możliwy szablon to:

JAKO <ROLA UŻYTKOWNIKA> CHCIAŁBYM <AKCJA/FUNKCJONALNOŚĆ> ABY <CEL>.

Pamiętajcie, że od tego, jak zapiszecie historyjkę klienta, dużo ważniejsza jest rozmowa, o której papierowy kartonik ma nam przypominać. Historyjki użytkownika muszą opisywać funkcjonalność, która ma określoną wartość dla użytkownika.

Ron Jeffries w XP Magazine zdefiniował zasadę "Trzy k"
  1. K - karta: historyjka jest zapisana na małym kawałku papieru.
  2. K - konwersacja: mała kartka papieru, z krótkim tekstem jest katalizatorem rozmowy na jej temat.
  3. K - konfirmacja: czyli testy akceptacyjne najczęściej zapisywane są na odwrocie papierowych kartoników.

Poprawnie zdefiniowane historyjki są zgodne z cechami opisanymi za pomocą akronimu INVEST:

  • Istniejące samodzielnie (ang. Independent)
Historyjki są niezależne, gdy możemy je implementować w dowolnej kolejności. Niesie to za sobą dwie korzyści: Właściciel Produktu może dowolnie ustalać priorytet względem innych historyjek oraz ocena historyjki nie jest zależna od stopnia wykonania innej historyjki.

  • Negocjowalne (ang. Negotiable)
Historyjki nie są specyfikacją wymagań rozumianą w tradycyjny sensie. Zawierają jedynie krótki opis funkcjonalności zapisany na małej kartce papieru. Na więcej nie ma miejsca. Reszta - wszystkie szczegóły i drobnostki - dopracowuje się w rozmowie.

  • Wartościowe (ang. Valueable)
Historyjka użytkownika jest funkcjonalnością, której implementacja przenika przez wszystkie warstwy systemu. Przykładowo, treścią historyjki użytkownika nie może być projekt bazy danych. Wykonanie warstwy bazodanowej jest dla użytkownika kompletnie obojętne. Użytkownik systemu wymaga pojedynczej funkcjonalności, która realizuje dany scenariusz. Sama baza danych jest bezużyteczna. Przykładem wartościowej historyjki użytkownika jest zaimplementowanie możliwości logowania się do szytemu za pomocą loginu i hasła. Aby taka funkcjonalność była udostępniona użytkownikowi wymagane jest zaimplementowanie kawałka bazy danych, dostępu do tych danych, logiki oraz interfejsu użytkownika.

  • Estymowalne (ang. Estimable)
Historyjka musi być do tego stopnia czytelna, żeby na jej podstawie, Właściciel Produktu mógł ją jakoś umiejscowić względem pozostałych, a także z grubsza zaplanować prace. Trzy czynniki czyniące historyjkę estymowalną to:
  1. Konwersacja - Właściciel Produktu odpowiada za przygotowanie historyjek, nadanie im odpowiednich priorytetów a także utrzymanie porządku ale historyjki PISZECIE WSPÓLNIE WSZYSCY.
  2. Rozmiar - Nie większe niż możliwe do zaimplementowania w jednej iteracji.
  3. Zespół - Łatwość szacowania historyjek użytkownika zależy również od doświadczenia i wiedzy zespołu, który nad nim pracuje.

  • Są małe (ang. Small) 
Historyjki są małe wtedy, gdy da się je wykonać w jednej iteracji. Historyjki, które będziemy implementować w pierwszej kolejności powinniśmy się starać historyjki rozbijać na mniejsze, przechodząc od ogółu do szczegółu. Funkcjonalności, które będziemy implementować kiedyś w przyszłości powinny być ogólnym zapisem idei. Nie ma sensu poświęcać energię na coś co ma się stać w dalekiej przyszłości. Może się okazać, że wyniku przebiegu zdarzeń w projekcie ta dana historyjka nigdy nie wejdzie w skład iteracji.

  • Testowalne (ang. Testable)
Testy akceptacyjne są bardzo ważnym elementem każdej historyjki. Są jej nieodzownym elementem. Nie ma historyjki jeśli nie ma testu akceptacyjnego. Nie ma mowy o tym, że napisaliśmy dobrą historyjkę, gdy nie jesteśmy wstanie jej przetestować.

Mike Cohn w książce "User Stories Applied"  podał przykład nietestowanlną a potem testowaną historyjkę.

Błędna wersja:
UŻYTKOWNIK NIGDY NIE POWINIEN DŁUGO CZEKAĆ NA WYŚWIETLENIE SIĘ DOWOLNEGO EKRANU.

Poprawna wersja:
CZAS WYŚWIETLANIA SIĘ NOWEGO EKRANU WYNOSI 2 SEKUNDY W 95% PRZYPADKÓW.


Bibliografia:
"SCRUM O zwinnym zarządzaniu projektami" Mariusz Chrapko

niedziela, 2 lutego 2014

Trzymaj się wybranego sposobu rozwiązania, nie zmieniaj go co chwilę, nie wymyślaj nowych zasad. Często zmieniając swoje zachowania, zasady, cele, sposób postępowania, za każdym razem zaczynamy wszystko od nowa i nigdy nie dochodzimy do rezultatów. Trzeba wierzyć w to co się robi i nigdy nie wolno się zniechęcać. Wytrwałość jest kluczem do sukcesu.
Andy Brand udostępnił ciekawą klasyfikację błędów oraz sposób postępowania z nimi w Scrum'ie. Tutaj jest link, dostępny w dniu (15.10.2013) do tej prezentacji http://www.scrum.org.pl/2012/10/scrum-i-bugi/.

Niżej streszczenie wraz z moimi komentarzami.

Bugi klasyfikujemy ze względu na DOLEGLIWOŚĆ oraz ZŁOŻONOŚĆ. Każda z tych klasyfikacji może osiągnąć poziom najwyższy lub najniższy.

Dolegliwość najwyższa jest wtedy gdy system stoi, klienci dzwonią, szef grozi brakiem premii, której i tak już nikt się nie spodziewa po takiej akcji.

Dolegliwość najniższa jest gdy błąd nikomu nie przeszkadza, np. jakaś ikonka nie jest w odpowiednim miejscu lub wygląda inaczej. Inny przykład to taki gdzie zapomniano obsłużyć klawisz enter i dana opcja dostępną jest tylko po kliknięciu w dany element, itp.

Złożoność to inaczej czy to jest prosty bug, czy to jest złożony bug.

Prosty bug to taki którego usunięcie zajmuje znacznie mniej czasu niż jego zdiagnozowanie. Usuwalny w czasie nie dłuższym niż jeden dzień.

Złożony bug to taki, który wymaga przepisania jakiegoś popsutego modułu aplikacji, jego usunięcie wymaga zastosowania innego algorytmu, zmiany technologi, itp. Najczęściej nniska wydajność jest złożonym bugiem.

1. Wysoka złożoność i wysoka dolegliwość

Nic nie działa i nie wiadomo jak to naprawić, a jak już wiadomo to aby to naprawić należy poświęcić bardzo dużo czasu/zasobów.
Rozwiązanie: Przerywamy sprint, przestajemy się skupiać na dowiezieniu wszystkich punktów w iteracji, stawiamy system na nogi. Wszyscy na pokład. Taka sytuacja występują tak rzadko że nie ma sensu obudowywać tego typu zachowania w zasady Scrum'a. Nie ma sensu stosować również innych metodyk. Po prostu ratujemy się. Gdy zaczynają się zdarzać takie sytuacje często wówczas zastanawiamy się nad sensem pisania w tym projekcie nowych funkcjonalności.

2. Niska złożoność i wysoka dolegliwość

To błędy związane z zapuszczeniem się w dług technologiczny, które często są spowodowane niedostatecznym przetestowaniem aplikacji przed wdrożeniem na produkcję. Po wgraniu systemu wyskakują dziwne kwiatki, które trzeba jak najszybciej naprawić. Często się mówi że projekt musi się wygrzać - czyli muszą pospływać błędy od klienta, które naprawimy. Wtedy mamy sytuację z dużą ilością błędów, które nie mogą poczekać do końca iteracji.

Rozwiązanie: Jeśli takich błędów pojawia się dużo wówczas zespół wyznacza wśród swoich członków zespołu dyżurnego, który zajmuje się naprawą takich zgłoszeń. W każdej iteracji lub co pół iteracji dyżurny zmienia się, tak aby nie był dyskryminowany i zdemontowany.

Inne rozwiązanie jakie według mnie jest równie dobre i które uważam, że się sprawdza to takie gdzie zakładamy pewien bufor punktów, który przeznaczamy na naprawę błędów nie wyznaczając konkretnej osoby w zespole. Scrum'owy zespół to przecież zespół samo organizujący się. Zespół sam sobie decyduje kto dany błąd naprawi, korzystając z przyznanych punktów na tego typu zadania. Po wyczerpaniu bufora punktów, decydujący głos ma Product Owner, który nadaje nowe priorytety pozostałym zadaniom. Wskazuje, które zadanie nie muszą być wykonane w tej iteracji na rzecz naprawy konkretnych błędów. Nawet gdy tych błędów jest bardzo dużo tego typu podejście się sprawdza. Czarno na białym widzimy ile nowych funkcjonalności jesteśmy w danej iteracji wykonać a ile czasu zabiera nam naprawianie błędów. Takie rozwiązanie ma sens gdy systemy wdrożone na produkcję generują przewidywalną ilość zgłoszeń. W takiej sytuacji nie widzę sensu wyznaczania dyżurnego. Osoba która najbardziej zna się w temacie błędu, naprawia go w ramach przyznanego bufora. Za każdym razem może to być inna osoba lub zawsze taka sama ale zespół dogaduje się w tym temacie po swojemu.

Inna sprawa, że gdy takie sytuacje są tak częste i uciążliwe że, nie pozwalają na pracę zespołu zgodnie z, metodyką Scrum, należy w pierwszej kolejności wziąć się za wprowadzenie poprawnych technik wytwarzania oprogramowania oraz zaprzestać zaciągać dług techniczny.

3. Niska dolegliwość i wysoka złożoność

Przykładem może być wyciek pamięci w aplikacji po stronie serwerowej. Wyciek ten jest stały w czasie i stopuje system raz na półtora miesiąca. Wówczas jeśli specyfika działania systemu na to pozwala, można zaplanować restart tego systemu raz na miesiąc, w nocy, który trwa 5 sekundy, podczas gdy mamy pewność że w tym czasie nikt na tym systemie nie pracuje.

Rozwiązanie: Trafiają do Backloga i są kolejkowanie do wykonania przez Product Owner'a. Skoro jest wysoka złożoność błędu a dolegliwość jest nie wielka to w danym momencie może po prostu nie opłacać się poświęcać dużo czasu na poprawę błędu, który nie jest istotnym błędem. Możliwe, że są o wiele ważniejsze zadania na tą chwilę. Decyzję ma w tym przypadku właściciel produktu.

4. Niska dolegliwość i niska złożoność

Jeżeli takich błędów jest niewiele, wówczas należy poprawiać je w ramach dobrowolnych działań programisty, gdy powstanie do tego stosowny moment. Jeśli tych błędów jest bardzo dużo, wówczas należy zaplanować określoną liczbę punktów na poprawianie tego typu błędów. Wybór błędów i ich kolejność dokonywana jest przez programistów - szkoda czasu Product Owner'a na błędy które mają niską dolegliwość a ich naprawa jest trywialna.

POWSTAJE PYTANIE CO Z SLA?

Co robimy z błędami opisanymi w punkcie 3 i 4, które jesteśmy zobowiązani do naprawy w ściśle określonym czasie opisanym w umowach serwisowych. Rozwiązanie jest proste: skoro to jest zgłoszenie w ramach SLA a my musimy się wywiązać z czasów zawartych w umowach to te zadania z definicji są o wysokiej dolegliwości więc postępujemy w sposób opisany w punkcie 1 i 2.
To czy firma programistyczna osiągnie sukces na rynku zależy od warunków pracy.

Najlepsze warunki pracy,
przyciąga najlepszych programistów,
którzy piszą najlepszy kod,
który przynosi zysk.

Nawet bardzo liczna grupa przeciętnych programistów, nie zależnie od czasu jaki poświęci na tworzenie kodu zawsze napisze oprogramowanie, które jest tylko przeciętne podczas gdy zaledwie kilku bardzo dobrych programistów w krótkim czasie jest wstanie napisać bardzo dobre oprogramowanie.

W wielu branżach należy optymalizować funkcję kosztów do jakości. Często zwiększenie jakości powoduje zwiększenie kosztów produkcji, które nie przekładają się wprost proporcjonalnie na wzrost zysków. W firmach programistycznych na ogół nie ma tego typu problemu. Raz napisany kod można sprzedać n-razy bez konieczności ponoszenia dodatkowych kosztów poza handlowymi.

Według Joel'a Spolsky pracownicy Creative lub Microsoftu choćby spędzili 10 lat na projektowaniu nigdy nie wpadną na pomysły jakie zaimplementowano w iPod'zie, ponieważ nie mają w swoich szeregach Jonathana Ive'a.

Dużo bardziej opłacalne jest zainwestowanie w bardzo dobre warunki pracy, które przyciągną do firmy bardzo dobrych programistów, którzy z kolei stworzą coś co jest bardzo dobre i świetnie się sprzeda, niż utrzymywać średnich programistów w przeciętnych warunkach, którzy nigdy nie przysporzą firmie sławy a czasami mogą doprowadzić do ich upadku.

Wśród nawet tysiąca CV skompletowanych na naszym biurku z dużym prawdopodobieństwem nie znajdzie się CV bardzo dobrego programisty. Dobrzy programiści najczęściej nie trafiają na rynek pracy i nie składają podań o pracę. To firmy składają aplikację współpracy z bardzo dobrymi  programistami a nie programiści.

Jeśli mamy dużo szczęścia to taki bardzo dobry programista przeprowadza się do innego miasta - do tego w którym znajduje się nasza firma. Dodatkowo przeprowadzka nie jest związana z poszukiwaniem lepszej pracy. Przyczyna musi być całkowicie niezwiązana z karierą zawodową, jak na przykład przeprowadzka do miasta gdzie mieszka nowo poznana dziewczyna. Wówczas bardzo dobry programista składa CV do wszystkich firm między innymi do naszej.

Jak pozyskać bardzo dobrych pracowników. Sposobów jest kilka.

Wyłuskać ich jeszcze na studiach, wyrabiając sobie znajomości u profesorów, którzy dają nam cynk jeśli zaobserwują osobę, która rokuje na bardzo dobrego programistę. Z puli wielu studentów zarekomendowanych z wielu uczelni, po przeprowadzeniu rozmowy telefonicznej wybieramy maksymalnie dwóch najlepszych, z którymi oferujemy rozmowę kwalifikacyjną w siedzibie naszej firmy.

Zapewniamy tym naszym potencjalnym praktykantom dojazd, nocleg i wyżynie w jak najwyższym standardzie. Fundujemy przepych nie zachowując żadnego umiaru w tym temacie. Po rozmowach kwalifikacyjnych wybieramy jednego i oferujemy mu dobrze płatną praktykę. Zapewniamy mieszkanie w wysokim standardzie. Podczas praktyk organizujemy wiele imprez podczas których praktykant ma okazję poznać miasto oraz pracowników naszej firmy. Po odbytej praktyce student wraca na studia. Zapewniamy go, że po ich skończeniu ma w naszej firmie zapewnioną pracę bez dodatkowych rozmów i egzaminów.

Tego typu zachowanie nie stosujemy w przypadku osób, które już ukończyły studia. Skoro dany programista ukończył już studia to już powinien mieć zapewnioną pracę. Absolwent, który odbył w naszej firmie praktyki z dużym prawdopodobieństwem wybierze naszą firmę.

Innym sposobem pozyskiwania bardzo dobrych pracowników jest zbudowanie społeczności w obrębie własnej firmy. Jak to zrobić - ciężko powiedzieć. Społeczność tworzy się w obrębie dobrych firm. Firmy takie są znane każdemu programiście. Takie firmy często wyznaczają trendy technologiczne. Często temu zjawisku towarzyszą opowieści o niespotykanie wysokich standardach i wygodach w pracy takich jak stoły do bilarda, masaże, bułki w lodówce, które czekają na programistów gdy rano przyjdą do pracy, itp.

Bardzo dobrzy programiści bardzo często przebywają na określonego typu konferencjach (np. na spotkaniach Krakowskiej Grupy Deweloperów .NET), i uczestniczą w określonego typu projektach open sourc'owych, a wśród swoich zainteresowań wymieniają określone technologie, plus pracują/pracowali w określonych firmach.

Nie zatrudniamy pracowników z polecenia innych pracowników, a tym bardziej nie oferujemy za tą czynność gratyfikacji pieniężnej, ponieważ może to spowodować, że nasi pracownicy będą chcieć przeforsować kandydaturę znajomego tylko dlatego, że otrzymają za tą czynność określoną kasiurę.

Bibliografia: 
1. "Programista poszukiwany" Joel Spolsky
1. Boksy i inne wydzielone przestrzenie są wyjątkowo niefortunne w kontekście relacji towarzyskich.

2. Biuro naszej firmy oraz pomieszczenia pracy programistów muszą być zrobione na bogato. Ma być grubo.

3. Co najmniej dwa wielkie, dobrej klasy monitory, z możliwością piwotu.

4. Fotel biurowy może być taki jak ten: "Fotel biurowy Ergomax Ergohuman elite"

5. Możliwość zakupu na koszt firmy dowolnej książki technicznej związanej z programowaniem, bez pytania kogokolwiek o zgodę, plus wykupiony dostęp do kursów dostępnych na stronie: http://www.pluralsight.com.

6. Licencja na najnowszego ReSharpera i inne tego typu narzędzia.

7. Traktowanie na specjalnych warunkach jako osoby nieliczne z całej populacji, które posiadają wiedzę nieosiągalną dla zwykłego pracownika firmy.

8. Niezależność i autonomia oraz żadnej polityki.

9. Niech najlepsi nowo przyjęci programiści sami wybierają swoje projekty.

10. Stosowanie ciekawych, nowych technologii. Nawet gdy wydają się zbyteczne nie są ponieważ najlepsi programiści często będą dla nas pracować tylko z powodu stosowania tych technologii.

11. Bardzo dobrzy programiści nie myślą o jednym - o pieniądzach - chyba, że kompletnie zaniedbamy pozostałe kwestie.

12. 20% czasu w pracy przeznaczone na rozwijanie hobbistycznych projektów, które z czasem jeśli okażą się wartościowe mogę zostać projektami rozwijanymi przez tą firmę.

Bibliografia: 
1. "Programista poszukiwany" Joel Spolsky
Podczas rekrutowania bardzo dobrego programisty rozmowa telefoniczna pełni funkcję filtrującą. Jeśli podczas takiej rozmowy nie możemy się dogadać, to jest to wystarczający powód do tego aby już na tym etapie zdecydować, że danej osoby nie zatrudnimy. Przed zaproszeniem kandydata na właściwą rozmowę kwalifikacyjną zwykle dzwonimy do niego, aby się upewnić, że organizacja tej rozmowy nie będzie zwykłą stratą czasu i pieniędzy.

Rozmowa telefoniczna jest tania. W krótkim czasie eliminujemy masę kandydatów, którzy na papierze sprawiali wrażenie na prawdę dobrych.

Rozmowa kwalifikacyjna powinna składać się z trzech etapów:

Pierwszy to: zapytanie o dotychczasową karierę oraz zaprezentowanie swoich największych osiągnięć programistycznych. Tutaj należy wypytać o wszystkie technologie z jakimi kandydat pracował. Należy to robić w sposób bardzo szczegółowy, aż do momentu gdy mamy pewność, że znajomość tematu u tego kandydata jest bardzo duża i że rzeczywiście odgrywał ważną rolę w danym projekcie. Eliminujemy osoby, które powiększają swój wkład w projektach w stosunku do rzeczywistości. Wypytujemy również o aspekty polityczne. Sprawdzamy czy dany pracownik jest osobą, która potrafi wyznaczać nowe trendy, która może wnieść nowe postrzeganie tych samych zagadnień. Poszukujemy osób kreatywnych i pewnych swojej wiedzy.

Drugi etap to: pytanie techniczne. Najlepiej sprawdza się takie: "Jak zaprojektowałbyś strukturę danych lub blok kodu odpowiedzialny za realizację zadania x." Do tego pytania należy mieć przygotowaną pulę dodatkowych pytań naprowadzających. Po tym jak szybko kandydat dociera do prawidłowego rozwiązania i po ilości dodatkowych pytaniach można określić inteligencję kandydata.

Trzeci etap: umożliwienie kandydatowi przepytania mnie. Na tym etapie opinia powinna być już wyrobiona na temat kandydata. Ten trzeci etap nie wpływa znacząco na podjętą decyzję. Trzeba jednak, podczas takiej rozmowy zaprezentować własną firmę w jak najlepszym świetle. To jest moment gdzie niezależnie czy zaprosimy czy nie kandydata do następnego etapu, mamy możliwość puszczenia w świat jak najlepszej opinii na temat naszej firmy.

Pozytywne przejście rozmowy telefonicznej nigdy nie jest warunkiem wystarczającym do przyjęcia bardzo dobrego programisty.

Bibliografia: 
1. "Programista poszukiwany" Joel Spolsky
Na dwanaście poniższych pytań odpowiadamy TAK lub NIE. Wynik 12 punktów jest wprost doskonały, wynik 11 punktów jest do zaakceptowania, ale już wynik dziesięciopunktowy lub niższy wskazuje na poważne problemy. Prawda jest taka, że większość firm wytwarzających oprogramowanie może się "pochwalić" wynikiem na poziomie 2 lub 3 punktów. Firmy utrzymujące największe sukcesy stale dbają o wynik 12 punktów.

1. Czy wykorzystujesz mechanizm kontroli wersji?

2. Czy możesz skompilować cały system w jednym kroku?

3. Czy przeprowadzasz kompilację w każdym dniu?

4. Czy utrzymujesz bazę danych z informacjami o wykrytych błędach?

5. Czy usuwasz istniejące błędy przed napisaniem nowego kodu?

6. Czy realizujesz projekt zgodnie z ustalonym wcześniej planem?

7. Czy korzystasz ze specyfikacji?

8. Czy programiści w Twoim zespole mają zapewnione właściwe warunki pracy (czyli przede wszystkim ciszę)?

9. Czy wykorzystujesz najlepsze narzędzia dostępne na rynku?

10. Czy korzystasz z pomocy testerów?

11. Czy kandydaci do pracy w zespole muszą napisać próbkę kodu w trakcie rozmowy kwalifikacyjnej?

12. Czy wykonujesz z zespołem tzw. korytarzowe testy użyteczności?

P.S. Wynik 12 punktów jest warunkiem koniecznym ale nie wystarczającym aby nasza firma osiągała największe sukcesy. Na to składają się jeszcze inne czynniki wykraczające poza treść tego posta.

Bibliografia: 
1. "Programista poszukiwany" Joel Spolsky
W tym poście spisałem wskazówki dotyczące prowadzenia rozmów kwalifikacyjnych na stanowisko programisty jakie doczytałem się w książce "Programista poszukiwany" Joel'a Spolsky'iego. Co do uzasadnienia słuszności poniższych wskazówek odsyłam w tej książce do rozdziału: "Podręczna instrukcja prowadzenia rozmów kwalifikacyjnych", gdzie znajdują się rzeczowe i zwięzłe argumentacje.

§1

Zawsze należy podjąć próbę zaangażowania przynajmniej sześciu osób do procesu rekrutacji, z czego pięć powinno pochodzić z grupy potencjalnych pracowników. Patrząc z punktu widzenia kandydata, rozstrzygnięcie na swoją korzyść jednej rozmowy kwalifikacyjnej jest po prostu zbyt łatwe.

§2

Jeśli przynajmniej dwóch z sześciorga pracowników prowadzących rozmowę uważa, że dany kandydat nie zasługuje na zatrudnianie - nie zatrudniamy go. W praktyce oznacza to, że już po dwóch rozmowach możemy zakończyć rekrutację nie tracąc więcej czasu i pieniędzy. Nie odrzucamy kandydata sugerując się opinią tylko jednego programisty biorącego udział w rekrutacji.

§3

Należy unikać prowadzenia rozmowy jednocześnie z kilkoma potencjalnymi programistami. To po prostu jest nieuczciwe. Zaznaczam tutaj słowo "programistów". Istnieją stanowiska gdzie podczas rozmowy należy sprawdzić zachowania w grupie, umiejętność ubierania czapeczki lidera, itp. Jednak poszukując programistów możemy sobie taką rekrutacją tylko zaszkodzić uwypuklając nieistotne umiejętności, które mogą być potrzebne na innych stanowiskach, nie sprawdzając przy tym umiejętności programistycznych.

§4

W czasie rozmowy mamy do czynienia z trzema typami kandydatów:
  1. Kandydaci, których wartość dla firmy jest praktycznie zerowa - brakuje im podstawowych kompetencji do pracy.
  2. Prawdziwi geniusze programowania, gwiazdy piszące kompilatory dla zabawy w wolnym czasie.
  3. Mnóstwo kandydatów do rozważenia, których przydatność do tworzenia danego projektu nie jest na pierwszy rzut oka oczywista.
§5

Po przeprowadzeniu rozmów kwalifikacyjnych, musimy podjąć decyzję: zatrudniamy albo nie zatrudniamy. Nigdy nie może być trzeciej odpowiedzi, takiej jak np. zatrudniamy ale za pół roku, lub zatrudniamy ale nie do mojego zespołu.

§6

Jeśli mamy kandydata, który pasowałby do zadań w naszym zespole i na daną chwilę byłby dla nas przydatny, ale wiemy, że w innym zespole lub za jakiś czas gdy projekt się zmieni, ta osoba nie sprawdzałaby się, to odpowiedź brzmi: nie zatrudniamy. W świecie programowania, technologie tak często się zmieniają, że potrzebujemy ludzi którzy skutecznie potrafią zając się dowolnym zagadaniem programistycznym. Osoba, która dzisiaj znakomicie zna się na XAML'u powinna potrafić równie świetnie poradzić sobie w przyszłości z JavaScript'em.

§7

Jeśli nie jesteśmy wstanie ocenić kandydata i nie wiemy jaka jest poprawna decyzja wówczas odpowiedzieć brzmi: nie zatrudniamy. Gdy mówimy: "... ten kandydat jest naprawdę dobry ale nie jestem pewien czy ...:", wówczas odpowiedź brzmi: nie zatrudniamy. Tego typu podejście znacznie podnosi jakość zatrudnionych osób. Odrzucenie dobrego kandydata jest o wiele mniej inwazyjne dla firmy niż zatrudnienie kiepskiego. Zły kandydat nie tylko będzie kosztował firmę masę pieniędzy, ale też będzie zabierał czas pozostałym pracownikom. Odrzucając dobrego kandydata można by się zastanawiać czy to jest etyczne. Jeśli dany kandydat na prawdę jest bardzo dobry, to i tak prędzej czy później znajdzie sobie dobrą pracę - jesteśmy usprawiedliwieni.

§8

Nie należy obniżać standardów, niezależnie od tego jak trudno jest znaleźć dobrego kandydata.

§9

Szukamy osób które:
  1. są inteligentne 
  2. doprowadzają sprawy do końca
Krótka rozmowa kwalifikacyjna nie jest wstanie dostarczyć więcej informacji na temat kandydata.
Osoby inteligentne ale pozbawione umiejętności doprowadzania spraw do końca nierzadko mogą się szczycić doktoratami i zatrudnieniem w wielkich korporacjach, w których nikt z ich zdaniem się nie liczy. Zamiast dostarczać na czas gotowe rozwiązania, grzęzną w bezproduktywnych rozważaniach akademickich.
Pracownicy z umiejętnością doprowadzanie spraw do końca, ale nieinteligentni podejmują głupie decyzje. Takie osoby sprawiają wrażenie osób działających bez zastanowienia, a ich błędy muszą być poprawiane przez innych pracowników. Jednym z czynników, które mogą zdradzać, że rozmawiamy z inteligentnym kandydatem to brak konieczności wielokrotnego wyjaśniania tej samej kwestii. Rozmowa z inteligentną osobą przebiega sprawnie.

§10

Dajemy się wypowiedzieć. Nie zadajemy pytań na które kandydat może tylko podpowiedzieć: "tak to prawda", "tak to jest najlepsze rozwiązanie".

§11

Najgorszą opcją jest przeprowadzanie quizów. Inteligencja nie jest tożsama z umiejętnością pamiętania mnóstwa faktów. Pytania typu: "Jaka jest różnica między typem varchar a varczar2 w systemie Oracle 8i?" jest przykładem najbardziej debilnego pytania. Gdy podczas pracy, dany inteligentny pracownik będzie potrzebował poznać odpowiedź na to pytanie to sprawdzi ją w czasie 15 sekund w internecie. Umiejętność odpowiadania na tego typu pytania nic nie wnoszą do oceny, nie przybliżają kandydata do określenia go mianem bardzo dobrego programisty. Każdy zbiór umiejętności jakim dysponuje kandydat w momencie rozmowy kwalifikacyjnej będzie przestarzały za kilka lat. Wiedza encyklopedyczna sprawdzona za pomocą quizów stanie się wówczas nieprzydatna.

§12

Najlepszym sposobem na rekrutację jest umożliwienie kandydatowi mówienia. Należny zadać otwarte pytanie lub wskazać jakiś ogólny problem do rozwiązania.

§13

Przed rozmową notujemy plan rozmowy, który może wyglądać tak jak poniżej:
  1. Wprowadzenie 
  2. Pytanie o ostatni projekt realizowany przez kandydata 
  3. Proste pytanie związane z programowaniem 
  4. Pytanie na temat wskaźników lub rekurencji 
  5. Czy jesteś zadowolony? 
  6. Czy masz jakieś pytania? 
§14

Nie należny wyrabiać sobie opinii o kandydacie przed rozmową z nim. Nie należny sugerować się tym, że pochodzi z takiego czy innego regionu lub, że studiował na takiej czy innej uczelni, lub sugerować się opinią innych osób, które nie są niedopowiedziane za podjęcie decyzji, a które skłonne są do wyrażania opinii na podstawie, np. znajomości. Jeśli ulegniemy tej pokusie, wówczas poprowadzimy rozmowę nieobiektywnie na korzyść lub niekorzyść kandydata.

§15

 Faza: "Wprowadzenie" ma na celu rozluźnić atmosferę. Pada pytanie o podróż oraz później poświęcamy 30 sekund na przedstawianie się.

§16

Pytamy tylko o ostatni projekt, a jeśli jest to absolwent to pytamy o pracę dyplomową lub o ulubiony przedmiot na studiach.

§17

Jeśli spada tempo wypowiadania się, należny zadawać dodatkowe pytania w stylu: "Powiedz coś więcej na ten temat." Niech kandydat mówi jak najwięcej, a my tylko słuchamy.

§18

Warto sprowokować kandydata do obrony swoich racji - to proste - wystarczy poczekać aż powie coś w 100% prawdziwego i powiedzieć: "To niemożliwe!". Wówczas kandydat zacznie bronić swoich racji.

§19

Szukamy dowodów pasji, zaangażowania. Inteligentni programiści wkładają serce w wytwarzanie i rozwijanie oprogramowania. Tacy kandydaci mówią płynnie, szybko i żywo gestykulują. Dobrze gdy kandydat reagują podobnie omawiając negatywne aspekty poprzedniej pracy. Kiepscy programiści nie wykazują większego zainteresowania swoją pracą.

§20

Nieumiejętność opowiedzenia o danym projekcie na odpowiednim poziomie szczegółowości, jest sygnałem do odrzucenia kandydata. Inteligentny programista powinien potrafić opowiedzieć o wytwarzanym oprogramowaniu, zarówno osobie która kompletnie nie zna się na programowaniu, jak innemu programiście. Aby to sprawdzić należny poprosić kandydata o to, żeby opowiedział o swoim ostatnim projekcie w taki sposób jakby opowiadał o nim swojej ciotce.

§21

Należy sprawdzić czy kandydat w opisywanym przez siebie projekcie wykazywał predyspozycje do osiągania pozycji nieformalnego lidera. Możemy zapytać kogo inicjatywą był wybór tych technologii oraz poprosić o wyjaśnienie dlaczego ten wybór był najlepszy. Jeśli kandydat uważa, że nie był najlepszy to należny zapytać czy lobbował za innymi technologiami. Można wprost zapytać o ostatni projekt, w którym kandydat brał udział w roli leadera.

§22

Większa część rozmowy kandydata powinna być poświęcona stwarzaniu kandydatowi możliwości dowiedzenia, że potrafi pisać kod.

§23

Proste pytanie związane z programowaniem - należy wybrać zadanie, które przeciętnemu programiście nie powinno zająć więcej niż jedną minutę. Jest to bardzo szybki sposób wstępnego odrzucania kandydatów którym nie warto poświęcać więcej czasu i pieniędzy. Przykładem takich pytań są:
  1. Napisz funkcję określającą, czy łańcuch rozpoczyna się od wielkiej litery z przedziału od A do Z. 
  2. Napisz funkcję obliczającą pole powierzchni koła o danym promieniu. 
  3. Zsumuj wszystkie wartości tablicy. 
Jeśli nie jesteśmy wstanie poruszać się w świecie prostych zagadnień z prędkością 100 km/h, nigdy nie odnajdziemy się wśród bardziej złożonych problemów.

§24

Zadajemy pytanie, w którym kandydat musi się wykazać rozumieniem referencji i wskaźników.
Po 15 latach doświadczenia w rekrutowaniu Joel'a Spolsky doszedł do wniosku, że rozumienie wskaźników i referencji nie należy traktować jako umiejętność - to raczej kwestia talentu.

Z jakiegoś powodu większość programistów (w tym duża część programistów, która wydaje się być dobra) rodzi się bez ośrodka w mózgu odpowiedzialnego za rozumienie wskaźników. Najlepsi kandydaci bez trudu radzą sobie w rozumieniu zagadnienia na różnych poziomach abstrakcji, co pozwala na implementację algorytmów rekurencyjnych lub złożonych algorytmów operujących na wskaźnikach.

Aby sprawdzić, czy dany programista posiada ten rodzaj talentu, należy zadać pytanie gdzie użycie wskaźników pozwala rozwiązać zadanie. Takie przykładowe zadanie to: napisz kod odwracający kolejność elementów tablicy.

Wszystkich tych, którzy uważają że w C# czy w Javie lub w innych językach nie będących językami C/C++ ten rodzaj talentu nie jest wymagany odsyłam do książki "Programista poszukiwany", do rozdziału "Podręczna instrukcja prowadzenia rozmów kwalifikacyjnych".

§25

Poniżej kilka dodatkowych pytań, które należy zadać po ukończonym zadaniu. Celem tych pytań jest nawiązanie dyskusji.
  1. Dlaczego zrobiłeś to w ten sposób?
  2. O czym zapomniałeś?
  3. Czy jesteś zadowolony z tego kodu?
  4. Gdzie popełniłeś błąd?
To jest kwintesencja części rozmowy poświęconej otwartemu zadaniu. Bardzo rzadko zdarza się, że programista nie popełnił ani jednego błędu ale nie o to tutaj chodzi. Sprawdzamy umiejętność poprawiania błędów oraz sposób analizy kodu. W tym etapie sprawdzamy również umiejętność bronienia swoich racji.

§26

Na ostatnim etapie rozmowy kwalifikacyjnej sprawdzamy, czy kandydat ma jakieś pytania. Musimy pamiętać, że chociaż to my prowadzimy rozmowę kwalifikacyjną, najlepsi kandydaci mają do wyboru wielu pracodawców i podczas rozmów w naszej firmie sami oceniają, czy chcieliby dla nas pracować.

§27

Nie należy przywiązywać wagi do sensowności zadawanych pytań. Na tym etapie powinniśmy mieć już wyrobione zdanie na temat kandydata.

§28

Zawsze zostawiamy sobie 5 minut na końcu rozmowy aby zaprezentować naszą firmę i jego ewentualne stanowisko pracy. To bardzo ważne, nawet gdy nie planujemy przyjąć danego kandydata. Mamy swój czas aby wypuścić w obieg jak najlepszą opinię o naszej firmie.

§29

Należny unikać łamigłówek typu: "Jak ułożyć cześć zapałek, aby tworzyły dokładnie cztery trójkąty równoboczne. Większość tego rodzaju pytań należy do kategorii "Aha" - zwykle znamy odpowiedź albo nie. Znajomość odpowiedzi na taką łamigłówkę dowodzi tylko, że zetknęliśmy się kiedyś z nią.

§30

Nie należy zadawać pytań, których odpowiedź jest oparta o zgadywanie. Na przykład: "Ilu stroicieli pianin mieszka w Krakowie". Można zacząć rozkminiać ile jest mieszkańców w Krk, zacząć szacować jaki procent ludzi ma pianino i na tej podstawie obliczyć ilu stroicieli pianin mogłoby nasycić rynek. Tego typu pytanie może posłużyć jako test na inteligencję ponieważ pokazuję tok rozumowania, ale pod warunkiem, że sami dysponujemy bardzo dobrymi pytaniami pomocniczymi, które mogą naprowadzić kandydata na poprawną odpowiedź. Jeśli nasza pomoc w rozwiązaniu ma polegać na podaniu poprawnej odpowiedzi wówczas usłyszymy od kandydata odpowiedz: "Aha".

§31

Optymalny czas na podjęcie decyzji o zatrudnieniu lub nie, to trzy minuty po rozmowie. Każda większa zwłoka w naturalny sposób wymazuje z naszej pamięci coraz więcej szczegółów, co wymusza na nas podjęcie decyzji na podstawie co raz mniejszej ilości informacji o kandydacie.

§32

Musimy być gotowi na poniesienie dodatkowych kosztów niezbędnych do wyeliminiowania przeszkód jakie stoją przed zatrudnieniem bardzo dobrego programisty.
  • przeprowadzka - zapłacimy Ci za to
  • prawnik pomagający w imigracji - zapłacimy Ci za to
  • praca dla małżonki / małżonka- pomagamy w znalezieniu
  • potrzeba brokera nieruchomości - zapłacimy Ci za to
  • chcesz obejrzeć kilka domów - zapłacimy Ci za to

§33

Jeśli jesteśmy zmuszeniu odmówić kandydatowi, powinniśmy zrobić to możliwie szybko i z szacunkiem. Nie mamy obowiązku tłumaczyć kandydatowi swojej decyzji.

§34

Nie możemy się poddawać. Bardzo dobrzy programiści są średnio od trzech do dziesięciu razy wydajniejsi od przeciętnych, a kosztują zaledwie 20 do 30 procent więcej. Co więcej, bez trudu osiągają to, co dla innych jest poza zasięgiem.

Bibliografia: 
1. "Programista poszukiwany" Joel Spolsky
  1. Sztuka polega na łapaniu ludzi na tym jak robią coś dobrze a nie źle.
  2. Diagnozuj i poprawnie stosuj style przywództwa w zależności od poziomu rozwoju podwładnego.
  3. Diagnozuj i poprawnie stosuj style przywództwa w zależności od poziomu rozwoju grupy/zespołu.
  4. Zarządzaj drogą do decyzyjności grup
  5. Zarządzaj konsekwencjami i zachowaniami. Nie skupiaj się tylko na aktywatorach czyli na wyznaczaniu zadań.
  6. Reprymendy stosuj tylko wobec doświadczonych pracowników. Reprymendy nie zwiększają wiedzy podwładnych a jedynie zmieniają ich nastawienie. Niedoświadczonym pracownikom ponownie wyznaczaj cele i określaj obszary odpowiedzialności.
  7. Dawanie pochwał lub reprymend nie uzależniaj od własnego samopoczucia - staniesz się niewiarygodny.
  8. To jakim jesteś nie zależy od tego jak sam się postrzegasz a od tego jak jesteś postrzegany przez innych.
  9. Każdy podwładny powinien jasno wiedzieć co należy do jego obowiązków.
  10. Demonstruj poprawne wykonanie zadania podwładnemu, gdy tego wymaga.
  11. Ustal standardy efektywności.
  12. Nie dawaj zbyt wielkiej odpowiedzialności wobec pracowników, u których w dłuższej perspektywie może to spowodować spadek zaangażowania zbyt dużą trudnością zadań.
  13. Obserwuj postępy.
  14. DELEGUJ a nie ZRZEKAJ się odpowiedzialności. Aby móc poprawnie delegować, podwładny musi posiadać odpowiednie kompetencje. Gdy zlecamy zadanie pracownikowi niekompetentnemu to zwyczajnie zrzekamy się tego zadania (jest to zwykła spycholizna).
  15. Pominięcie obowiązku obserwacji oraz zarządzania konsekwencjami prowadzi do katastrofy.
  16. Zaufanie jest dobre ale kontrola jeszcze lepsza.
  17. Reaguj poprawnie na złe wyniki. Nie ignoruj i nie staraj się chwalić pracownika gdy osiągane wyniki są niezadowalające. Zarówno chwalenie jak i ignorowanie nie zwiększy zaangażowania. Cofnij się o jeden styl przywództwa i ponownie zdefiniuj cele i określ obszary odpowiedzialności.
  18. Umów się w sprawie stylu przywództwa. Zawsze należny jasno mówić co się robi i jak się postępuje.
  19. Wyznaczaj cele które są: konkretne i wymierne, motywujące, osiągalne, znaczące, identyfikowalne.
  20. P.S. Stosuj się do zasad opisanych w poście: Kilka zasad jednominutowego menedżera
  21. Każde zadanie musi dać się zmierzyć i ocenić.
... kodeks ten będę uzupełniał z czasem ...


Bibliografia:
1. "Jednominutowy menedżer i przywództwo" dr Ken Blanchard
Nie jest najważniejsze to aby wszystko od początku robić jak należy, a to żeby w ogóle zacząć. Nic co jest warte zrobienia nie musi być od razu zrobione idealnie. 

Należy przestać próbować coś robić. Trzeba daną rzecz po prostu robić lub w ogóle nie robić.

Jeśli coś wiesz ale nie stosujesz tego w praktyce, to znaczy, że jeszcze nie wiesz.

Bibliografia:
1. "Techniki jedominutowege menedżera w praktyce" dr Ken Blanchard
Codziennie należy zarezerwować sobie przynajmniej jedną minutę na popatrzenie w oczy każdemu pracownikowi. Nie można opierać rozwój firmy na kilku bardzo wydajnych jednostek a na całych zespołach. Dla pracowników oprócz dobrej pracy bardzo ważne jest dążenie do samorealizacji. Poczucie bycia członkiem zespołu jest bardzo motywujące. Należy nieustannie wspierać i pracować nad kształtowaniem wydajnych zespołów.

Średnio 50 - 60% działań w pracy menedżera to praca w grupie. Produktywność grupowa jest dużo ważniejsza od pojedynczych działań. Należy wzbudzić poczucie współwłasności. Ważna jest realizacja misji zespołu po przez pracę zespołową. Gdy mamy do czynienia z prawdziwym, dobrze współpracującym zespołem nie słyszy się: "To nie należy do moich obowiązków!".

Zespoły posiadają etapy rozwoju: od zbieraniny jednostek do dobrze pracującego zespołu. Grupy powyżej piętnastu osób stają się nieefektywne. Scrum zakłada, że najwydajniejsze zespoły są nie mniejsze niż pięcioosobowe i nie większe niż dziewięcioosobowe. Większe grupy są nieefektywne i należy je podzielić na kilka mniejszych. Podział powinien przebiegać w poprzek umiejętności – nie dzielimy na programistów, serwisantów i testerów. Tworzymy zespoły złożone z kilku programistów, kilku testerów i kilku serwisantów.

Wszystkie grupy są jedyne w swoim rodzaju. Każda grupa różni się od siebie. Grupy, podobnie jak jednostki również przechodzą etapy rozwoju niezależnie od rodzaju zadań.

Ważne aspekty efektywnych zespołów:
  • Mają stałą liczbę członków przez długi czas.
  • Codziennie stają twarzą w twarz ze sobą.
  • Posiadają wspólne zadania.
Charakterystyka wysokowydajnego zespołu wymawiana przez jednego z członka zespołu:
  • Wiemy co mamy robić a cele zespołu są jasne.
  • Każdy w zespole przejmuje częściowo odpowiedzialność za przywództwo.
  • Wszyscy aktywnie uczestniczą w pracy zespołu.
  • Czuję się doceniany i wspierany przez innych.
  • Członkowie zespołu słuchają kiedy mówię.
  • Szanujemy odmienne opinie.
  • Lubimy wspólnie pracować i dobrze się bawimy.
Bibliografia: 
1. "Jednominutowy menedżer buduje wydajne zespoły" dr Ken Blanchard
Zespoły zawsze osiągające swój cel bez wysiłku, w sposób wydajny i kreatywny, oraz zmotywowany do ciągłego rozwoju, to zespoły, które można opisać za pomocą akronimu PERFORM.

Purpose and values – CEL NADRZĘDNY I WARTOŚCI
  • Zespół posiada jasno zdefiniowany cel nadrzędny.
  • Zespół jest zaangażowany w osiąganie wspólnego celu nadrzędnego.
  • Zespół wie doskonale na czym polega ich praca.
  • Poszczególne cele zespołu są klarowne, ambitne, uzgodnione i związane z celem nadrzędnym.
  • Role poszczególnych członków zespołu są jasne a ich związek z celami jest zrozumiały.
Empowerment – DECYZYJNOŚĆ
  • Zespół ma otwarty dostęp do wszystkich informacji organizacyjnych.
  • Zespół ma władzę w ustalonych granicach.
  • Instrukcje i szkolenia wspierają rozwój poszczególnych członków i całego zespołu.
  • Zespół jest zaangażowany w stały postęp i rozwój wszystkich członków zespołu.
Relationship and comunication – RELACJE I KOMUNIKACJA
  • Atmosfera w zespole zachęca do wyrażania różnych pomysłów.
  • Wszyscy słuchają się nawzajem aby zrozumieć a nie oceniać.
  • Ceni i szanuje się różnice kulturowe.
  • Uczciwe informacje zwrotne pomagają zespołowi dostrzec swoje mocne i słabe elementy.
Flexibility – ELASTYCZNOSĆ
  • Członkowie zespołu wspólnie ponoszą odpowiedzialność za jego rozwój i przywództwo.
  • Zespół potrafi stawać na wysokości zadania wykorzystując umiejętności pojedynczych jednostek.
  • W zależności od potrzeb członkowie zespołu bardziej lub mniej angażują się do wykonywanych różnych zadań aby osiągnąć cel zespołu.
  • Zespół jest otwarty na analizę różnych rozwiązań oraz na adaptowanie się do zmian, które pomogą zespołowi być bardziej efektywnym.
  • Zauważone błędy postrzega się jako okazję do nauki.
Optimal performance – OPTYMALNE WYNIKI
  • Zadania są wykonywane.
  • Zespół utrzymuje wysokie standardy.
  • Zespół uczy się na błędach i poprawia wyniki.
  • W zespole promowana jest kreatywność.
  • Posiadają umiejętność koordynacji zadań z innymi zespołami
Recognition and approximation – DOSTRZEGANIE WKŁADU I DOCENIANIE
  • Osiągnięcia są doceniane w zespole i przez przełożonych.
  • Członkowie zespołu czują się ważni.
  • Zespół świętuje sukcesy.
Moral – MORALE
  • Zespół zachęca do ciężkiej pracy a także do zabawy.
  • Członkowie zespołu mają silne zaufanie do siebie.
  • Członkowie zespołu pomagają sobie nawzajem.
  • Członkowie zespołu mają silne poczucie dumy z uczestnictwa w danym zespole.
  • Członkowie zespołu wypracowali relacje dzięki, którym dają sobie wsparcie
Nikt z nas nie jest tak bystry jak my wszyscy. Takich dziesięciu jak nas pięciu to nie ma ani jednego.

Bibliografia: 
1. "Jednominutowy menedżer buduje wydajne zespoły" dr Ken Blanchard
Pierwszą rzeczą jaką należy zrobić to ustalić wspólny cel nadrzędny dla naszego zespołu. Najważniejszą potrzebą każdego z pracowników jest możliwość samorealizacji. Stworzyć wspólny cel nadrzędny – to podstawa.

Należy uzgodnić z zespołem wartości jako wyznaczniki w jaki sposób będziemy osiągać cel nadrzędny. Wspólny cel nadrzędny określa co uczestnicy zespołu chcą osiągnąć i dlaczego ze sobą współpracują, nadaje znaczenie i sens pracy, wszyscy wiosłują w tym samym kierunku. Zespół musi wyznaczyć zasady (wartości), które będą służyły podczas dokonywania wyborów aby osiągnąć cel nadrzędny.

Cel nadrzędny zawsze zachęca do uzyskiwania wyników. 

W kamieniołomie na postawione pytanie: „Dlaczego walisz młotem w ten kamień?” jeśli uzyskamy odpowiedź: "Moim zadaniem jest rozłupywanie kamieni, za wykonywanie, którego otrzymuję wypłatę.", to oznacza, że dany pracownik nie czuje się członkiem zespołu realizującego jakiś ważny nadrzędny cel. Możemy wnioskować, że jego zaangażowanie w pracę jest minimalne przez co nie osiąga nawet połowy swojej potencjalnej wydajności. Zespół posiadający jasno zdefiniowany cel nadrzędny pracuje dużo wydajniej. Na wyżej postawione pytanie otrzymamy wówczas odpowiedź: "Rozłupuję kamień aby przyczynić się do budy tej katedry."

Bibliografia: 
1. "Jednominutowy menedżer buduje wydajne zespoły" dr Ken Blanchard
Cały proces tworzenia wysokowydajnego zespołu wiąże się z trzema najważniejszymi umiejętnościami: diagnozą, adaptacją, decyzyjnością.

Diagnoza to poprawne rozumienie wzorców zachowań w grupie oraz procesów dynamicznych. Należy obserwować działania zespołu. Im większa liczba osób w grupie tym większa liczba interakcji – liczba ta rośnie geometrycznie. Interakcje możemy nazwać inaczej procesem i treścią.

W pracy grupy można wyróżnić tak zwane: treść oraz proces. Treść oznacza to czym grupa się zajmuje czyli inaczej mówiąc co zostało zrobione. Proces opisuje jak funkcjonuje grupa. Proces charakteryzuje to, jak zachowuje się grupa czyli jakie interakcje zachodzą w grupie, np. walka o przywództwo, sposoby komunikowania się oraz podejmowania decyzji.

Obserwowanie procesu jest krytyczne dla poprawnego budowania zespołu. Nie obserwowanie procesu może powodować niezrozumienie sytuacji, w której pracownicy są niezadowoleni mimo, że wszystkie zadania zostały zrealizowane. Jeśli pracownicy są niezadowoleni z powodu nie umiejętnego obserwowania procesu przez menedżera wówczas mnożą się spotkania na schodach, korytarzach po tytułem: „szkoda że nie powiedziałem …”.

Co należy obserwować w grupach:
  • Komunikację i uczestnictwo
    • kto z kim rozmawia 
    • kto jest wykluczany 
    • kto mówi najczęściej 
  • Podejmowanie decyzji - sposób w jaki grupa podejmuje kurs działań 
    • na zasadzie większości głosów 
    • osiągając konsensus 
    • brak ustaleń
  • Konflikty - jest nieunikniony i niezbędny do osiągnięcia wyidealizowanego celu. Sposoby radzenia sobie z konfliktem: 
    • po przez unikanie
    • kompromis
    • rywalizację
    • współpracę
  • Przywództwo, cele i role 
    • musi być jasność co do swoich ról 
    • kto na kogo ma wpływ 
    • muszą być jasne cele jakie grupa ma osiągnąć
  • Normy grupy - to podstawowe zasady regulujące zachowanie grupy 
  • Rozwiązywanie problemów
    • zidentyfikowanie i sformowanie problemu 
    • wygenerowanie alternatywnych rozwiązań 
    • analizę konsekwencji 
    • zaplanowania i ocenę działań 
    • w jaki sposób grupa rozwiązuje problemy 
  • Atmosferę w grupie - odczucia i ton grupy – czy jest przyjazny 
  • Zachowanie poszczególnych osób 
    • co członkowie grupy robią aby pomóc sobie w realizacji zadań 
    • kto skupia się tylko na sobie
Poprawną formą obserwacji jest tak zwana obserwacja uczestnicząca. Obserwacja uczestnicząca to sztuka bycia zaangażowanym w podejmowaniu decyzji i równocześnie bycia świadomym w jaki sposób te decyzje są podejmowane.

Jeśli przeforsuje jeden lub dwóch członków zespołu decyzję i nie sprawdzisz czy wszyscy się zgadzają, wówczas jesteś w sytuacji kajakarza płynącego bez wiosła w górę potoku – po prostu nie będziesz miał poparcia wprowadzając daną decyzję w życie. Obserwację uczestniczącą podobno da się wyćwiczyć.

Bibliografia: 
1. "Jednominutowy menedżer buduje wydajne zespoły" dr Ken Blanchard
Każdy nowo-powołany zespół przechodzi etapy rozwoju. Najczęściej tych etapów jest cztery, gdzie czwarty etap to cel, który należy osiągnąć wraz z zespołem. Niektóre zespoły rozpoczynają, od razu, od etapu drugiego, jednak żaden z zespołów nie pomija etapów drugiego i trzeciego. Poniżej przedstawiam definicję każdego z tych etapów. Po więcej szczegółów odsyłam do książki "Jednominutowy manager buduje wydajne zespoły" dr Ken'a Blanchard'a.

Etap 1 – Rozpoznania

Charakterystyka: 
  • umiarkowany zapał,
  • wysokie często nierealne oczekiwania
  • obawy związane z rolami, akceptacją, zaufaniem do innych, oczekiwaniami
  • niepewne, uprzejme, spolegliwe zachowanie
  • brak jasności co do celu nadrzędnego, norm, ról, zadań, struktury
  • oczekiwanie instrukcji i wsparcia ze strony menedżera
  • testowanie granic
Potrzeby:
  • wspólne zrozumienie nadrzędnego celu zespołu
  • zgoda co do wartości i norm wspólnej pracy
  • zgoda co do ról poszczególnych celów i standardów
  • zgoda co do posiadanej władzy związanej z podejmowaniem decyzji i odpowiedzialnością
  • zgoda co do struktury i granic w jaki sposób zostanie wykonana praca i przez kogo, wyznaczniki czasu
  • informacja o dostępnych środkach
  • poznanie wspólnych zdolności, aby zbudować wspólne więzi
Ważne kwestie:
  • dobre samopoczucie
  • akceptacja
  • zrozumienie
  • zawsze gdy zbiera się zespół jego członkowie odczuwają obawę czy zgrają się z resztą
  • na początku zawsze jest ostrożność i brak zaufania
  • początkowo panować będzie atmosfera ostrożności i podekscytowania
  • początkujący zespół powinien mieć jasno zdefiniowane ogólne poczucie celu, rozumieć swoje własne cele i role a także podstawowe zasady obowiązujące w zespole
  • model kodeksu zespołu
  • wizja, cel nadrzędny i wartości organizacji – to rdzeń kodeksu
  • wizja, cel nadrzędny i wartości zespołu – muszą być związane z wizją, celem nadrzędnym i wartościami organizacji
  • wizja to obraz idealnego rezultatu końcowego
  • cel nadrzędny określa prace zespołu i określa dlaczego jest ona ważna
  • wartości to trwałe przekonania, które kierują zachowaniami zespołu
  • normy zespołu to podstawowe zasady określające właściwe zachowania członków zespołu
  • role członków zespołu określają indywidualne obowiązki
  • cele określają wymierne rezultaty i limity czasu niezbędne do odniesienia sukcesu
  • strategie komunikacji zapewniają dzielenie się informacjami między członkami zespołu
  • władza zespołu definiuje zakres odpowiedzialności zespołu
  • odpowiedzialność dotyczy strategii zapewniających dotrzymywanie zobowiązań
  • środki to zasoby materialne oraz wsparcie niezbędne do osiągnięcia celu zespołu

Etap 2 – Niezadowolenie

Ten etap przechodzi każda grupa. Niektórzy członkowie zespołu są wyraźnie źli. Menedżer musi przejmować kontrolę nad zespołem. Zespół próbuje kwestionować władzę menedżera. Wówczas niektórzy uważają, że zebranie to okazja na zrobienie protokołu i na stratę czasu. Wielbłąd to koń zaprojektowany przez komisję.

Charakterystyka:
  • rozbieżność między oczekiwaniami a rzeczywistością
  • frustracja i niepewność co do ról i celów 
  • niezadowolenie od zależności wynikającej z władzy zwierzchniej
  • wyrażanie niezadowolenia
  • tworzenie się koalicji
  • odczucia niekompetencji, dezorganizacji, niska pewność siebie
  • rywalizacja o władzę, autorytet i uwagę
  • niewielkie zaufanie
  • realizacja niektórych zadań
Potrzeby:
  • ponowne nakreślenie celu nadrzędnego, ról celów podrzędnych oraz struktury
  • ponowne opowiedzenie się za wartościami i normami
  • rozwijanie zespołu i umiejętności związanymi z zadaniami
  • rozwijanie procesów komunikacji obejmujące aktywne słuchanie, nie osądzające informacji zwrotnych, radzenie sobie z konfliktami
  • dostęp do informacji i środków
  • zachęta i wsparcie
  • uznanie dotychczasowych osiągnięć
  • otwarta i uczciwa dyskusja dotycząca kwestii emocjonalnych
  • wspólne uznanie obowiązków i odpowiedzialności za nie 
Ważne kwestie:
  • władza
  • kontrola
  • konflikt
  • wszystkie grupy pokonują etap drugi w drodze do produktywności
  • to nie jest zły etap – to po prostu proces dochodzenia do produktywności
  • ten etap charakteryzuje się dużą walką o pozycję, kreatywnością oraz pozwala na wyłonienie wartościowych cech poszczególnych osób
  • pojedyncze osoby jednak nie są zadowolenie – dzieje się tak ponieważ zadania okazują się trudniejsze niż przypuszczali, spada morale
  • często zespół jest niezadowolony z kierownika lub z siebie
  • czasami jest tak że grupa od razu zaczyna od poziomu drugiego – dzieje się tak, gdy zadania im powierzone nie są zadaniami upragnionymi

Etap 4 – Produkcja 

Na tym etapie jest brak widocznego lidera zespołu. Uczestnicy często dyskutują i mają różne zdania, jednak zawsze dochodzą do konsensusu. Zespół pracuje dzieląc się pomysłami, zespół działa szybko. Członkowie żartują ze sobą i z siebie nawzajem. Różne osoby przejmują przywództwo w różnych momentach. Zespół działa jak jeden organizm a nie zbiór indywidualności. Na etapie produkcji menedżer wycofuje się z pracy pozwalając grupie działać. Nie da się przejść z etapu drugiego do etapu czwartego bez pośredniego etapu jakim jest etap "integracja". Na etapie produkcji członkowie zespołu żądzą się sami jako grupa.

Charakterystyka:
  • jasność co do celu nadrzędnego, ról i celów pośrednich
  • relacje i komunikacja oparta na zaufaniu, szacunku i otwartości
  • elastyczność i współdzielone przywództwo
  • optymalna produktywność i wysokie standardy
  • dostrzeganie i docenianie osiągnięć indywidualnych
  • wysokie morale 
Potrzeby:
  • dalsze skupianie się na produktywności
  • nowe wyzwania
  • dostrzeganie i świętowanie osiągnięć zespołu
  • uznawanie osiągnięć jednostek
  • autonomia w podejmowaniu decyzji w wyznaczonych granicach 
Ważne kwestie:
  • nowe wyzwania
  • dalszy rozwój
  • nauka

Etap 3 – Integracja

To most pomiędzy niezadowoleniem a skutecznością. Ten etap bywa stosunkowo krótki. Zespół akceptuje swoją obecność, żartuje między sobą i z siebie. Można zauważyć optymizm, mimo, że wcześniej w etapie drugim często dochodziło do ostrych kłótni. Grupa jest zaangażowana. Bez większych trudności osiąga zgodę. Wszystko idzie gładko i łatwo. Kontrolę nad spotkaniami obejmuje dowolny członek zespołu w zależności od tematu dyskusji. 

Z czasem może jednak dojść do spadku tempa wypowiedzi. Niektórzy członkowie mogą się wycofywać z rozmowy. Wówczas rolą menedżera jest podkręcanie dyskusji po przez zadawanie pytań konkretnym osobom. Menedżer zachęca do podzieleniu się różnicą zdań.  Stymuluje i wywołuje różnicę zdań, po czym trzyma nad tym kontrolę, łagodząc zbyt ostrą dyskusję. Menedżer rozwija i podkreślał zalety każdego z argumentów i dodaje własną opinię, dając tym samym przykład innym członkom zespołu, którzy zaczynają postępować w taki sam sposób jak menedżer. Spotkania kończą się w atmosferze zapału. Etap ten charakteryzuje się tym, że przywództwo nad zespołem po części zostawia się zespołowi ale jest potrzeba monitorowania zachowania.

W tym etapie może dojść do zbyt pobłażliwego przyznawania racji, sobie nawzajem, na korzyść unikania konfliktów. Najważniejsza jest jednak różnica zdań, ponieważ to ona pozwala na wypracowanie najlepszego rozwiązania.

Trzeba uważać, żeby nie doszło do gromado-myślenia. Gromado-myślenie to inaczej myślenie zbiorowe gdzie podczas presji społecznej członkowie zespołu boją się wyrazić różnicę zdań – w takiej sytuacji rolą menedżera jest zachęcanie do wyrażania różnych opinii.

Charakterystyka:
  • wzrost zrozumienia i zaangażowania w role, i strukturę
  • większe zaanagarzowanie w przestrzeganie norm i wartości
  • lepsza realizacja zadań - od umiarkowanej do wysokiej
  • wzrastające zaufanie, spójność, harmonia i szacunek
  • chętne dzielenie się odpowiedzialnością, przywództwem i kontrolą
  • rozumienie i docenianie różnicy zdań
  • tendencja do unikania konfliktów
  • rozumienie zespołowe – my zamiast ja
Potrzeby:
  • integracja zespołowych norm i struktury
  • dalsze doskonalenie umiejętności
  • zachęta do dzielenia się różnymi punktami widzenia lub do niezgody
  • dalsze budowanie zaufania i pozytywnych relacji
  • współdzielona odpowiedzialność za przywództwo
  • skupienie na wzroście produktywności
  • ocena i wyciąganie nauki z każdego doświadczenia
  • celebrowanie sukcesów
Ważne kwestie:
  • dzielenie się kontrolą
  • unikanie konfliktów
Bibliografia: 
1. "Jednominutowy menedżer buduje wydajne zespoły" dr Ken Blanchard
Każda grupa przechodzi etapy rozwoju. Większość grup rozpoczyna od etapu "Rozpoznanie", niektóre grupy rozpoczynają rozwój od etapu drugiego "Niezadowolenie". Wszystkie grupy przechodzą przez etap trzeci i czwarty jakim są odpowiednio: "Integracja" i "Produktywność".

Etapy te zostały opisane w poście "Etapy rozwoju grup".

Podstawową umiejętnością menedżera jest umiejętność zastosowania przywództwa sytuacyjnego. Często menedżerowie preferują, albo styl demokratyczny, albo autokratyczny. Niestety, nie jest to dobre rozwiązanie. Gdy przywódca jest zbyt autokratyczny, zespół na dłuższa metę demotywuje się. Będąc przywódcą demokratycznym, spotkania zaczynają trwać zbyt długo a pracownicy czują się jak ciepłe kluchy.

Cztery podstawowe style przywództwa odpowiednie dla każdego z etapów to:
  • Styl zatwierdzania – mało instruowania, mało wspierania - dla etapu Produktywność
  • Styl współpracy – mało instruowania, dużo wspierania - dla etapu Integracja
  • Styl analizy i rozwiązywania – dużo instruowania, dużo wspierania - dla etapu Niezadowolenie
  • Styl strukturyzacji – dużo instruowania, mało wspierania - dla etapu Rozpoznanie
Instruowanie to napełnianie zbiornika wiedzą – właśnie tego trzeba gdy zespół znajduje się na etapie rozpoznania. Pracownicy nie są pewni swoich ról i celów. Na pierwszym etapie zespół ma dużo zapału więc nie jest konieczne silne wspieranie. Udzielanie wsparcia ważne jest wtedy gdy zespół współpracuje już ze sobą jakiś czas ale utknął na jakimś zadaniu.

Wspieranie to inaczej wydobywanie ze zbiornika wiedzy. Menedżer słucha i wyciąga z grupy informacje, które wystarczają im do podjęcia decyzji.

Wraz z rozwojem zespołu następuje płynna zmiana przywództwa, gdzie menedżer wycofuje się ze swoich funkcji. 

Na etapie rozpoznania w zespole jest entuzjazm i zaangażowanie ale niewiele wiedzy - grupa potrzebuje instruowania – Strukturyzacja (S1).

Na etapie niezadowolenia członkowie zespołu nie są ani wysoce kompetentni ani zaangażowani, zmagają się z zadaniem oraz z samą współpracą – tak więc potrzebują zarówno instruowania jak i wsparcia – Analiza i rozwiązywanie (S2).

Na etapie integracji członkowie posiadają już wiedzę niezbędną do wykonywani zadań ale nadal potrzebują podbudowania pewności siebie – potrzeba im wsparcia i zachęty – Współpraca (S3).

Na etapie produkcji zespół posiada wysokie umiejętności i morale – lider może odsunąć się na bok – Zatwierdzanie (S4).

Funkcje lidera można podzielić na dwa rodzaje. Wyróżniamy funkcje zadaniowe oraz serwisowe.

Funkcje zadaniowe: to zachowania mające na celu realizację zadań. W ramach tych funkcji lider skupia się nad tym co grupa ma robić. W ramach tej funkcji, zadania lidera to:
  • ustalanie planu działania, 
  • wyznaczanie celów
  • instruowanie, inicjowanie dyskusji
  • wyznaczanie ograniczeń czasowych
  • udzielanie i poszukiwanie informacji
  • podsumowywanie.
Funkcje serwisowe: polegają na rozwijaniu i utrzymywaniu spójności grupy. Działania te dotyczą samego funkcjonowania grupy, czyli:
  • dostrzeganie wkładu i osiągnięć
  • słuchanie, zachęcanie do udziału
  • rozwiązywanie konfliktów i budowanie relacji.
Podział funkcji ze względu na etapy rozwoju:
  • na etapie rozpoznania lider troszczy się o funkcje zadaniowe
  • na etapie niezadowolenia lider troszczy się o funkcje zadaniowe i serwisowe
  • na etapie integracji lider troszczy się o funkcje serwisowe
  • na etapie zatwierdzania nie jest wymagane aby były pełnione ani funkcje serwisowe ani zadaniowe

Bibliografia:
1. "Jednominutowy menedżer buduje wydajne zespoły" dr Ken Blanchard
W postach: "Etapy rozwoju grup" oraz "Zmiany w produktywności i morale zespołów oraz style przywództwa" opisałem etapy rozwoju przez jakie grupa przechodzi oraz potrzeby i sposoby zarządzania tymi grupami. Poniżej znajduje się zwięzły plan gry, który doprowadzi zespoły do decyzyjności.

Droga do decyzyjności podwładnych zaczyna się od diagnozy etapu na jakim znajduje się grupa. Każdy menedżer i podwładny powinien znać akronim PERFORM. Po zdefiniowaniu etapu rozwoju kolejnym krokiem powinno być określenie właściwego stylu przywództwa w oparciu o odpowiednią  ilość zachowań instruujących i wspierających.

Plan gry:
  • Określ cel nadrzędny i wartości
  • Wyznacz poszczególne cele i role
  • Opracuj kodeks zespołu
  • Wykonaj diagnozę: ustal poziom rozwoju grupy pod względem produktywności i morale na danym etapie rozwoju zespołu
  • Dopasuj odpowiedni styl przywództwa
  • Zastosuj właściwy styl przywództwa
  • Zacznij zarządzać drogą do decyzyjności grupy
Być dobrym liderem zespołu jest o wiele trudniejsze od bycia liderem autokratycznym. Należy się dzielić z zespołem rozpoznaniem danego etapu rozwoju. Decyzyjność sprowadza się do wypuszczenie spraw z własnych rąk tak aby inni mogli wziąć je przejąć we własne ręce.

Bibliografia:
1. "Jednominutowy menedżer buduje wydajne zespoły" dr Ken Blanchard
  • Pracuj sprytnie a nie ciężko.
  • Wytrwałość w dążeniu do celów pozwala je osiągnąć.
  • Nie ma większej niesprawiedliwości niż traktować nierównych równo. Jednych należy głaskać z włosem a niektórych pod włos.
  • Należy nauczyć się delegowania, ale aby móc delegować należy wcześniej przeszkolić pracowników, aby oddelegowane zadania były wykonywalne. Gdy nie mamy czasu na przeszkolenie pracowników oznacza to, że jesteśmy w dużych tarapatach. Pierwszą rzeczą jaką należy zmienić w swoim postępowaniu to zacząć pomagać pracownikom wykonywać zadania, czyli należy pomóc im wygrywać. Nie chodzi tutaj o wykonywanie zadań za naszych pracowników a o szkolenie. Każdy pracownik, nie zależnie od stanowiska, wymagane jest aby posiadał odpowiednie kompetencje do wykonywania konkretnych czynności.
  • Twoi ludzie są odpowiedzialni a Ty zapewniasz im środki do wydajnego pracowania.
  • Nie trzeba ściśle współpracować ze wszystkimi tylko z tymi, którzy tego wymagają.
  • Należy stosować różne style przywództwa. Różnicuj style pod względem osób oraz rodzajów zadań, obowiązków.
  • Należy postępować tak aby inni postrzegali Cię za osobę którą uważasz, że jesteś. Jeśli postrzegasz się za osobę którą inni Cię nie uważają to oznacza, że Twoje postrzeganie samego siebie jest błędne.
  • Menedżer rzadko podejmuje decyzje za swoich ludzi.
  • Należy nauczyć się trzech umiejętności:
    • rozpoznawania i zaspakajania potrzeb czyli elastyczności
    • stosowania różnych stylów poprzedzając poprawną diagnozą
    • zawierania umów jakie style potrzebują podwładni czyli współpraca, partnerstwo 
  • Kiedy zwalniam – przyspieszam – najpierw pomyśl a potem działaj.

Bibliografia:
1. "Jednominutowy menedżer i przywództwo" dr Ken Blanchard
Od czasu do czasu należy przekazać złe wieści. Reprymendę tak należny udzielić aby pracownik nie zastanawiał się nad sposobem przekazania reprymendy a nad jej treścią. Przykład źle udzielonej reprymendy to: „Jeśli wydaje Ci się, że otrzymasz awans to masz rację – tylko Ci się wydaje!”. Poprawna reprymenda może brzmieć tak: „Ty jesteś w porządku ale twoje zachowanie pozostawia wiele do życzenia!”. Gdy reprymenda zostaje zakończona pochwałą to wówczas pracownik nie będzie się zastanawiał nad sposobem przekazania reprymendy a nad błędem jaki popełnił. Reprymenda powinna składać się z 30 sekund na przekazanie odczuć a potem następuje krótka pauza, która pozwoli opanować emocje i zaznaczyć powagę sytuacji, po czym następuje pochwała typu: "Stać Cię na więcej, jestem pewien, że więcej już tego nie zrobisz więc idź i zrób to tak jak potrafisz czyli bardzo dobrze".

Doświadczeni pracownicy są łatwi w zarządzaniu – wystarczy wyznaczyć cele a oni sami je osiągają. Najlepsi pracownicy sami sobie zdają sprawę z popełnionego błędu i sami je naprawiają. Od czasu do czasy, nawet najlepsi mogą się pomylić lub mieć niedociągnięcia. Reprymendę stosuje się tylko wtedy gdy mamy pewność, że pracownik może wykonać dane zadanie lepiej.

Nie można postępować według metody "na kanapkę", czyli pogłaskać, kopnąć, pogłaskać. Pracownik przyzwyczaja się do pierwszej pochwały i potem będzie czekał na reprymendę. Dodatkowe kary nie są konieczne – z reguły wystarczy samo upomnienie. Nie ma sensu strofować wielokrotnie za ten sam błąd – nie poruszamy danego tematu więcej niż jeden raz.

Kilka wskazówek:
  • Reprymendy są dopuszczalne tylko dla poziomów rozwoju R3, R4 i niekiedy dla R2.
  • Reprymendy nie służą do edukacji i uczenia podwładnego.
  • Reprymendy są skuteczne tylko gdy trzeba kogoś zmotywować do pracy.
  • Należy uważać czy reprymenda jest potrzebna – możliwe że lepsze może być wsparcie.
  • Zamiast stosować reprymendę lepszym wyjściem jest zmiana podejścia o jeden styl przywództwa w dół, co pozwoli na ponowne zdefiniowanie celów i zakresów odpowiedzialności.
  • Zawsze dokładnie przeanalizuj czy reprymendę którą masz zamiar udzielić będzie sprawiedliwa.
  • Dokładnie zbadaj czy nie ma innej przyczyny źle wykonanego zadania.

Bibliografia:
1. "Techniki jedominutowege menedżera w praktyce" dr Ken Blanchard