blog.testowka.pl

Praca

Kto chciałby być Scrum Masterem?

opublikowany przez 27, Wrz, 2012, w kategoriach Agile, Praca, Scrum, Zarządzanie

Rola Scrum Mastera jest kluczowa podczas wdrażania Agile w organizacji zwłaszcza, gdy to wdrożenie dopiero się rozpoczyna. Na czym polega rola Scrum Mastera?

Według najnowszej wersji Scrum Guide Scrum Master jest rolą managerską – warto tutaj zastanowić się nad znaczeniem słowa Manager. W języku polskim manager to osoba zarządzająca przedsiębiorstwem lub jego częścią, kierownik, dyrektor w języku angielskim a zwłaszcza w USA słowo to ma znacznie szersze znaczenie. Może odnosić się nie tylko do bezpośredniego zarządzania organizacją ale także do zarządzania procesami, sprawiania, że rzeczy się po prostu dzieją. Manager zwłaszcza w kontekście Agile pełni rolę typu servant leader (Andy pisał o tym jakiś czas temu), ma za zadanie usuwać wszelkie przeszkody stojące zespołowi na drodze do efektywnego wykonywania powierzonych mu zadań.

Scrum Master to także strażnik procesu. To do niego należy pilnowanie by wszystkie zasady Scrum były przestrzegane. Bardzo często podczas transformacji organizacji w kierunku Agile Scrum Master musi stanąć naprzeciw organizacji, która naturalnie broni się przed zmianą. Jest to niezwykle trudne – w wielu przypadkach, naprawdę dobrzy Scram Masterowie bywali nawet zwalniani z powodu tego, że nie zgadzali się na naginanie procesu i nie ustępowali presji.

Scrum Master poza zdolnościami managerskimi i szeroką wiedzą na temat procesu – Scrum powinien wykazywać się także specyficznymi zdolnościami interpersonalnymi. Umiejętność dostrzegania problemów oraz ich rozwiązywania są bardzo pożądane. Scrum Master ma także za zadanie „chronić” zespół przed zbyt dużymi naciskami z zewnątrz. Często obserwuje zwłaszcza w dużych organizacjach pewnego rodzaju parasole ochronne roztoczone nad zespołem przez Scrum Mastera, dzięki czemu zespół może efektywnie pracować nawet w bardzo niesprzyjającym, korporacyjnym środowisku. To na Scrum Masterze zatrzymują się wszelkie naciski i próby naginania procesu lub po prostu głupota.

Rola Scrum Mastera jest niezwykle trudna, a nawet ryzykowna. Jeśli chcesz być dobrym Scrum Masterem powinieneś liczyć się z tym, że ktoś może próbować się ciebie pozbyć. Organizacje bez względu na rozmiar mają tendencje do naturalnego oporu przeciw jakimkolwiek zmianom, naturalnymi są więc próby pozbycia się przyczyn zmian. Żeby być Scrum Masterem trzeba mieć więc odwagę (mieć jaja jak to mój znajomy mawia) by przeciwstawić się czasem całemu światu, a czasem nawet poświęcić własne dobro by coś ulepszyć.

A na zakończenie krótki filmik o tym jak powinien pracować dobry Scrum Master: Funny Scrum master

2 komentarze więcej...

Jakość to tylko efekt motywacji

opublikowany przez 11, Lip, 2012, w kategoriach Agile, Praca, Programowanie, Testowanie, Zarządzanie

Po raz kolejny zadaje sobie (i wszystkim na około) pytanie: czym tak na prawdę jest jakość? Jakość w oprogramowaniu ma wiele wymiarów, pisałem już o tym kilka razy. Bez względu jaką definicję jakości wybierzemy to problem z tym jak tą jakość zapewniać pozostaje niemal niezmienny.

Próby wprowadzania tzw. „metryk jakości” dają jakieś efekty – ale czy to jest zapewnianie jakości? Prędzej to „zapewnianie” ogranicza się do reagowania w sytuacjach, gdy jest już na prawdę źle – za późno na zapewnianie jakości. Może spróbujmy zadać sobie pytanie skąd w takim razie bierze się jakość?

Wielokrotnie zastanawiając się nad kluczowymi czynnikami wpływającymi na jakość produktu dochodziłem do jednego wniosku – podstawą w procesie zapewniania jakości są ludzie. Nie mówię tutaj o specjalistach QA czy testerach, bo szczerze powiedziawszy oni akurat mają wbrew pozorom stosunkowo niewielki wpływ na jakość. Jakość jest implementowana od samego początku projektu i jest implementowana przez wszystkich ludzi, którzy w tym projekcie biorą udział. Idąc tym tropem można by wyciągnąć wniosek, że kluczowym elementem zapewniania jakości w oprogramowaniu jest zatrudnienie odpowiednich osób, które będą o jakość dbać na każdym kroku oraz danie tym osobom możliwości zapewniania jakości. Proste!

Nie do końca… Bob Marshall wysunął ostatnio teorię, że pierwotną przyczyną implementowania błędów w oprogramowaniu jest brak motywacji ludzi to oprogramowanie wytwarzających. Jeśli się temu bliżej przyjrzymy to bez problemu możemy przyznać mu rację.

Poniżej kilka standardowych powodów występowania błędów:

  • brak wiedzy programistów – tak technologicznej jak i domenowej,
  • niekompletne wymagania,
  • problemy komunikacyjne,
  • zbyt mało czasu,
  • inne problemy.

Spróbujmy przyjrzeć się każdemu z powyższych i zastanowić się jaki wpływ na uniknięcie takich błędów ma motywacja.

Brak wiedzy programistów (i innych osób zaangażowanych w projekt) – w rezultacie powstaje sporo błędów na poziomie implementacji. Dlaczego programiści nie posiadają wystarczającej (wystarczającej do zminimalizowania ilości implementowanych błędów, a nie do zaimplementowania funkcjonalności) wiedzy? Ja nie mam z tym większego problemu – jeśli czegoś nie wiem, albo nie jestem pewien to sprawdzam tak, by mieć pewność, że to co robię będzie najwyższej jakości. Spowodowane jest to wysoką motywacją do tego czym się zajmuje. Jeśli człowiek przychodzi do pracy po to by odsiedzieć swoje 8h i w tym czasie tylko zakodować to co od niego wymagają, a później najlepiej o tym zapomnieć, to ciężko tutaj mówić o zmotywowanym pracowniku. Znam co najmniej kilku programistów, w których kodzie na prawdę rzadko zdarzało nam się znajdywać błędy. Spowodowane było to pewnym perfekcjonizmem i motywacją do ciągłego rozwijania się i robienia rzeczy coraz lepiej. Nawet jeśli już udało nam się znaleźć błąd to szanse na to by podobny błąd został przez tą osobę w przyszłości zaimplementowany były wręcz zerowe. Niestety znam też „programistów”, którym 10 prawie identycznych błędów zdarzało mi się zgłosić w ciągu miesiąca pracując z nimi równolegle. To właśnie brak motywacji do nauki, zdobywania wiedzy, czy nawet uczenia się na własnych błędach jest główną przyczyną powstawania błędów i tworzenia bylejakości.

Niekompletne wymagania – to lubię, nie pamiętam ile razy już słyszałem: „to nie nasza wina, dali nam takie wymagania, od początku wiedzieliśmy, że to się nie uda, ale teraz mają to co chcą, więc w czym problem”. Pierwsze podstawowe pytanie: skoro wiedzieliście, że wymagania są złe, niekompletne, albo nie byliście pewnie o co tak na prawdę w nich chodzi to dlaczego nie poszliście do osób, które te wymagania tworzyły, albo tych dla których ten produkt tworzycie i nie zapytaliście ich o co tak na prawdę chodzi, lub nie przekonaliście ich do tego, że to nie ma sensu? Brak motywacji i wiążącego się z nią poczucia odpowiedzialności za produkt jest przyczyną tego, że tworzymy rzeczy źle, albo nawet złe rzeczy.

Problemy komunikacyjne – jak często zdarza się Wam wysłać maila z pytaniem do kogoś w tym samym pomieszczeniu (tudzież w zasięgu 50 metrów od Was)? Dlaczego tak jest? Dlaczego nie wstaniecie i nie podejdziecie do tej osoby by przedyskutować problem, zadać pytanie, wspólnie coś stworzyć – bez błędów, niedomówień, oraz czasu straconego na oczekiwanie na odpowiedź. Prosta zasada – nie po to mamy dwie nogi by 8h dziennie siedzieć przykutym do biurka! Znowu kwestia motywacji do tego by jak najlepiej i najszybciej wykonać zadanie – no bo po co skoro, można wysłać maila i czekać 2h na odpowiedź – w tym czasie można zrobić przecież tyle ciekawych rzeczy, jak przeglądanie facebooka, zakupy przez internet, czatowanie z sekretarką, i co tam jeszcze wymyślicie – ważne, że takie oczekiwanie przybliża nas do [tu wstaw „godzina przyjścia do pracy” + 8h]. To najprostszy przykład problemów komunikacyjnych. Oczywiście można by znaleźć ich znacznie więcej, ale każdy z nich można rozwiązać łatwiej bądź trudniej – pozostaje jedynie kwestia motywacji do tego by to zrobić. Kolejny problem to przekładanie relacji osobistych ponad relacje zawodowe – mi też się to wiele razy zdarzało i dopiero z perspektywy czasu mogę stwierdzić, jak bardzo wpływało to negatywnie na projekty, nad którymi pracowaliśmy. Będąc (stając się) profesjonalistą, dobrze zmotywowanym profesjonalistą uczymy się radzić sobie także z takimi problemami.

Zbyt mało czasu – w zasadzie powinienem pozostawić to bez komentarza, bo mamy już rok 2012 i powszechnie wiadomo na całym świecie, że nie robienie rzeczy szybciej oznacza robienie ich gorzej co w efekcie skutkuje poświęceniem większej ilości czasu na poprawki i ostatecznie okazuje się być znacznie dłużej niż początkowo planowano. A gdzie tu motywacja? Przede wszystkim to od nas zależy czy będziemy wystarczająco zmotywowani do tego by powiedzieć „NIE!”, gdy ktoś wymaga od nas implementowania bylejakości na wczoraj. Pisałem już o tym kilka razy – rynek pracy w branży IT jest teraz tak szeroki, że nie ma najmniejszego problemu ze zmienieniem pracodawcy, gdy obecny nam nie odpowiada. Umiejętność mówienia nie staje się coraz bardziej pożądaną cechą dobrego pracownika IT.

Inne problemy – jakiekolwiek przyczyny powstawania błędów w oprogramowaniu znajdziecie i wymienicie, powinniście zadać sobie pytanie dlaczego jeszcze tych przyczyn nie usunęliście i nie rozwiązaliście problemów? Wiem, fajnie jest narzekać i czekać, aż może ktoś coś zrobi ale dużo trudniej jest samemu wstać z miejsca i rozwiązać problem. Zawsze znajdzie się milion powodów przez które „nie da się”, pytanie tylko czy na prawdę się nie da i czy chociaż próbowaliście?

Zatem pozostaje temat jak motywować pracowników (pytanie, które słyszę prawie na każdej konferencji i szkoleniu) – prosta odpowiedź: Nie da się! Jedyne co możemy zrobić to stworzyć odpowiednie środowisko, w którym ludzie będą mogli być zmotywowani i czuć, że to co robią ma sens oraz jest częścią czegoś większego. Najważniejsze to nie przeszkadzać i nie niszczyć motywacji (co jest bardzo trudne). Kolejne wymaganie to zatrudnienie odpowiednich – zmotywowanych ludzi (tutaj też uwaga, bo de-motywacja jest  dużo bardziej zaraźliwa niż motywacja).

Powyższy post został zainspirowany rozmową z Bobem Marshallem oraz artykułem: „Bugs are a signal„, który wszystkim polecam!

1 komentarz więcej...

Procedury i narzędzia

opublikowany przez 05, Wrz, 2011, w kategoriach Agile, Praca

„Ludzie i interakcje ponad procedury i narzędzia” – łatwo powiedzieć – trudniej zrobić.

Pierwsza myśl, która pojawia się, gdy zostajemy managerami w firmie IT, w której panuje chaos:
– „Trzeba ten chaos posprzątać”
– no dobrze, ale jak?
– „Wprowadźmy procedury, które uporządkują chaotyczne procesy…”
To nie działa! – wiem, bo sprawdziłem. Procedury są fajne, ale…

Po wprowadzeniu procedury mającej usystematyzować proces wdrażania aplikacji na serwery produkcyjne, bardzo szybko okazuje się, że rzeczy tak oczywiste jak wydawanie tylko ze stabilnego brancha, czy w ogóle posiadanie czegoś takiego jak stabilny branch nie dla wszystkich są oczywiste, a skoro nie ma tego szczegółowo opisanego w procedurze to kto by się tym przejmował. Ponadto dosłownie od razu pojawia się spychologia typu: „MY zakodowaliśmy już swoje teraz ONI niech się martwią jak to wydać”.

Aby poradzić sobie z codzienną „bieżączką” wynikającą z nadmiaru zadań krytycznych do zrobienia „na już” wprowadzamy proste kryteria oceny krytyczności i nadawania priorytetu zgłoszonym ticketom. Po chwili okazuje się, że zapis w stylu: „Jeśli błąd powoduje znaczące straty finansowe to można nadać mu priorytet krytyczny” jest podstawą do wielu nadużyć i 80% zgłaszanych ticketów ma priorytet krytyczny, a autorzy powołują się na „znaczące” wg nich straty finansowe, chociaż nie są w stanie, czy też nie mogą podać żadnych kwot.

Narzędzia, które wprowadzamy w dobrej wierze, po to by uporządkować pewne elementy procesu bardzo szybko obracają się przeciwko nam. Wprowadzane procesy powodują zanik i rozproszenie odpowiedzialności za wykonywane zadania. Niby posiadanie procedury daje większy komfort pracownikom bo pozwala w każdym momencie się na tą procedurę powołać ale z drugiej strony okazuje się, że jej nadinterpretacja szybko zwalnia co niektórych z myślenia.

A gdyby tak spróbować usiąść razem z innymi i po prostu robić te wydania w sposób, który pozwoli na opanowanie chaosu, robić je wspólnie aż do momentu, gdy wszyscy nauczą się robić to dobrze, zrozumieją po co robić to dobrze, zrozumieją, że sami mogą mieć wpływ na to by robić to jeszcze lepiej…

A gdyby tak spróbować uświadomić zgłaszających tickety, po co te priorytety wprowadzamy i że jeśli sami nie dojdą do tego jak sortować zadania według priorytetu to wiele ważnych rzeczy po prostu umknie… A gdyby tak w ogóle zlikwidować priorytety i robić zadania według uznania…

Czasami wdrażając Agile zapominamy o podstawowych zasadach właśnie takich jak ta z manifestu mówiąca o ludziach i interakcjach. Czasami zdarza się, że tak bardzo jesteśmy zapracowani tworzeniem nowych procedur, pisaniem dokumentacji i samym wdrożeniem, że nie zauważamy, iż ludzie nie są gotowi na wymyślane przez nas procedury. Czasami, a nawet często bywa tak, że procedury są tylko łatą nalepioną na problemie, gdy źródło problemu jest zupełnie gdzie indziej – gdzieś głębiej, a zgodnie z Lean problemy należy rozwiązywać a nie szukać drogi na około, rozwiązywać poprzez eliminowanie przyczyny powstania problemu.

3 komentarze więcej...

Poszukiwany/Poszukiwana!

opublikowany przez 06, Lip, 2011, w kategoriach Praca, Testowanie

Coraz częściej zauważam wzrost aktywności wielu firm IT na rynku pracy. Zauważam także więcej ogłoszeń dla testerów i QAów. Pojawia się też coraz więcej firm zajmujących się rekrutacją pracowników dla IT. Powodów może być wiele – czasem jest to spowodowane dynamicznym rozwojem firmy, a czasem jak to zwykle w przypadku testerów bywa próbą ratowania zbugowanego systemu.

Oglądałem kiedyś ciekawą prezentację Ken’a Schwabera wprowadzającą do Scrum. Oprócz samej tematyki Scrum poruszony został tam jeden bardzo ciekawy problem – Ken przedstawił przykładowy (sprawdzający się w większości przypadków) cykl życia start-up’ów. Wygląda to mniej więcej tak:

Kilku pomysłowych gości wpada na świetną, rewolucyjną idee i rozpoczyna pracę w swoim garażu/pokoju w akademiku/wynajętym mieszkaniu etc. Po jakimś czasie pojawia się pierwsza wersja live oferowanego systemu/aplikacji która powoli zaczyna zarabiać – na początku walczymy o to by zwróciły się koszty. Po jakimś czasie, przeważnie w wyniku niesamowitego zbiegu okoliczności start-up staje się bardzo popularny i zaczyna nagle zarabiać coraz więcej pieniędzy, co powoduje że firma się rozwija i zatrudnia więcej pracowników, którzy jak najszybciej produkują coraz to nowsze ficzery by jeszcze bardziej powiększyć zyski. Przeważnie wszyscy będąc na tej fali ciągłego powiększania przychodów nie przejmują się jakością. Po pewnym czasie projekt dociera do punktu w którym dodanie nowego ficzera staje się droższe niż zyski z niego płynące, niemniej jednak są one cały czas dodawane z różnych powodów – często czysto marketingowych nieprzekładających się na wymierne korzyści materialne. Mija jeszcze trochę czasu, po którym ktoś nagle stwierdza, że przepisanie całej aplikacji od nowa zajmie mniej czasu niż dodanie nowego ficzera. W międzyczasie zarząd/właściciele firmy zaczynają się zastanawiać nad tym jak rozwiązać problem zbyt drogich ficzerów. Jednym z rozwiązań jest pozbycie się problemu poprzez sprzedanie go innym – na rynku jest wiele firm typu venture capital, które masowo skupują start-up’y, po to by niektóre z nich przekształcić w prężnie działające przedsiębiorstwa. Zdarza się też tak, że zarząd postanawia wreszcie przenieść nacisk z wyłącznie zarabiania na polepszanie jakości (czasem też na przepisanie systemu od zera). W obydwu tych przypadkach (nieważne czy firmę kupi ktoś nowy, kto będzie chciał polepszyć jakość, czy zarząd sam zdecyduje się to zrobić) potrzebne jest zapewnienie specjalistów. Właśnie wtedy firmy decydują się na zatrudnienie zespołu QAów, którzy ogarną cały ten bałagan i zaproponują rozwiązania problemów. Czasem jest już za późno, niemniej jednak, jeśli tylko nakład na jakość jest wystarczająco duży często udaje się to osiągnąć.

W życiu każdego testera przychodzi czas na zmiany… Czasem bywa tak, że jest to zmiana pracy… Jeśli taki czas nadszedł właśnie dla Ciebie to mam dla Ciebie świetną propozycję! Szukamy testerów/inżynierów testów/QAów do naszego zespołu we Wrocławiu.

Jeśli jesteś zainteresowany/zainteresowana możliwościami dalszego rozwoju w dziedzinie automatyzacji testów, testowania, szeroko rozumianego QA etc. to zapraszam do kontaktu (jeśli napiszecie, że dowiedzieliście się o ofercie pracy z mojego bloga macie +10 do charyzmy ;-)) . Więcej informacji możecie znaleźć tutaj.

Szukamy też programistów PHP i Python.

8 komentarzy więcej...

QA vs Tester

opublikowany przez 17, Lut, 2011, w kategoriach Praca, Testowanie, Zarządzanie

Przeglądając ostatnio oferty pracy zauważyłem, że większość firm szuka QAów a nie testerów. Co jest grane? Czyżby nagle wszyscy zaczęli zapewniać jakość zamiast testować oprogramowanie? Było by cudownie… Niestety, jak przyglądam się bliżej tym ogłoszeniom, to jasne staje się, że owe firmy nie szukają Quality Asurance Engineer’ów tylko zwykłych testerów, w najlepszym wypadku inżynierów testów. Nadużywanie tytułu Quality Assurance Engineer albo Specialist prawdopodobnie wynika, z tego iż mało kto tak naprawdę wie co się pod tą nazwą kryje, jednocześnie wszyscy chcą być trendy i przyciągnąć większą uwagę potencjalnych kandydatów. Wcale się nie dziwię – samemu mi było trudno znaleźć wartościowe informacje na temat QA. Często te informacje są sprzeczne lub niekompletne.

Problematyczne może być także przetłumaczenie tego terminu z języka angielskiego na polski – próby typu „Inżynier Jakości”, „Inżynier Zapewniania Jakości” nie brzmią zbyt dobrze, dlatego osobiście wolę pozostać przy QA.

W takim razie czym jest Quality Assurance? Na pewno Quality Assurance nie jest tożsame z testowaniem oprogramowania. W najlepszym wypadku proces testowy może być zaliczany jako część procesu Quality Assurance. Głównym celem QA jest zapobieganie powstawaniu błędów, w przeciwieństwie do testowania oprogramowania, którego głównym zadaniem jest detekcja błędów – weryfikowanie jakości. QA wykorzystuje wiele narzędzi w celach prewencyjnych, między innymi zajmuje się organizacją i kontrolą procesu wytwarzania oprogramowania, buduje środowiska oraz narzędzia wspierające testowanie i kontrole jakości, poszukuje i wprowadza „dobre praktyki” by zwiększać efektywność i poprawiać jakość i dopiero jako jeden z wielu elementów pojawia się weryfikacja jakości produktu, która może zostać przeprowadzona poprzez testowanie oprogramowania.

Z pojęciem Quality Assurance związanych jest bardzo wiele innych niezmiernie istotnych terminów takich jak CMMI czy normy ISO. To właśnie zapewnienie osiągnięcia wspomnianych norm jest dosyć często głównym celem procesu QA.  Quality Assurance to także praca z ludźmi, zarządzanie wiedzą, organizacja pracy, doskonalenie umiejętności pracowników etc.

Powyżej starałem się wyjaśnić podstawowe różnice pomiędzy QA a testerami – jest to tylko moja własna interpretacja tego co znajduje się w encyklopediach, poradnikach, normach itp. niemniej jednak czytając różne artykuły, blogi etc. powyższa interpretacja coraz bardziej się weryfikuje i klaruje także postanowiłem się nią podzielić.

Jeśli ktoś ma inne zdanie na temat QA to zapraszam do dyskusji.

8 komentarzy więcej...

Shu-Ha-Ri

opublikowany przez 07, Lut, 2011, w kategoriach Agile, Kanban, książki, Praca, Scrum, Zarządzanie

Tajemniczy tytuł Shu-Ha-Ri to zaczerpnięte z kultury japońskiej trzy poziomy doświadczenia, często używane w kontekście sztuk walki takich jak aikido. Piszę o tym, gdyż nauka sztuk walki ma zaskakująco wiele wspólnego z wdrażaniem metodologi w organizacji. Trzy poziomy doświadczenia, trzy poziomy wtajemniczenia wymuszają na uczniu stopniową, systematyczną naukę dzięki czemu eliminuje się większość błędów.

Shu – przyswojenie, zachowanie, pielęgnacja
Jest to pierwszy etap nauki, w której uczeń skupia się na opanowaniu podstawowych technik i zachowań. Termin ten oznacza także lojalność wobec jednego nauczyciela. Podczas tego etapu najważniejsze jest przyswajanie wszystkiego z największa dokładnością bez możliwości wprowadzania jakichkolwiek zmian. W tej fazie nieistotne są powody stosowania technik, najważniejsze jest opanowanie do perfekcji podstaw. (Przypomina mi się scena z „Karate Kid” w której dzieciak uczy się podstawowych ruchów myjąc samochody 😛 ). Nie wszyscy zdają sobie sprawę z tego jak ważne jest zbudowanie podstaw, by móc z powodzeniem dalej rozwijać swoje umiejętności. Na poziomie Shu okazuje się, że do osiągnięcia celu jakim jest efektywne wykorzystanie umiejętności wystarczająca jest jedna droga, stąd też wymóg lojalności do nauczyciela i posłuszeństwo. Ta stara zasada jasno pokazuje, że mieszanie różnych technik a w naszym przypadku metodologi wprowadza chaos i doprowadza do sytuacji, w której mamy dużo różnych umiejętności ale nie reprezentują one żadnej wartości praktycznej ani technicznej jako całość. Według tradycji to nauczyciel decyduje o tym kiedy uczeń może zakończyć ten etap i przejść na poziom Ha.

Ha – odłączenie, zerwanie z tradycją
Drugi etap nauki polega na uwolnieniu się do pewnego stopnia od klasycznych metod. W tej fazie ważne jest by odnaleźć i zrozumieć powody technik nauczonych na poprzednim etapie. Tutaj zaczyna się sztuka, odłączenie od codziennie powtarzanych czynności i stopniowe rozwijanie technik. Na tym etapie uczeń rozpoczyna własne eksperymenty, powinien być gotowy na to by samodzielnie analizować i myśleć nad powodami wykorzystywania niektórych technik po to by w przyszłości samodzielnie je rozwijać i dołączać nowe. Cała dostępna wiedza została zdobyta, teraz uczeń musi nabyć doświadczenia.

Ri – uwolnienie
Ostatni etap, w którym uczeń staje się mistrzem, uwalnia się od tradycji, przechodzi poza granice. Uczeń posiadający duże doświadczenie i wiedzę może je wykorzystywać w życiu codziennym. Na tym etapie uczeń już nie uczy się sztuki walki od innych tylko tworzy swój własny niepowtarzalny styl. Dopiero tutaj możliwe jest całkowite uwolnienie od standardów i podstaw. Tutaj uczeń/mistrz może pozwolić sobie na niekonwencjonalność, która dzięki zdobytej wcześniej wiedzy i doświadczeniu ma bardzo duże szanse na sukces.

Jak to wszystko ma się do wdrażania metodologii? Miałem nie do końca przyjemną okazję kilkukrotnego obserwowania prób wdrożenia metodologi/narzędzi (Scrum, Kanban) w różnych organizacjach, które zakończyło się porażką. Porażka ta według moich obserwacji wynikała między innymi z tego, że wdrażający zakładali, iż członkowie zespołu i oni sami są co najmniej na poziomie Ha, z tym że wielokrotnie brakowało im wiele do osiągnięcia Shu – nie znali, bądź nie potrafili stosować podstaw. Ponadto wdrożenia typu „weźmy planowanie ze Scrum, tablicę z Kanban ale nie stosujmy na niej limitów, do tego eliminujmy waste za pomocą narzędzi Lean i nazwijmy to wszystko Agile to może nam coś tego wyjdzie” ciężko jest nazwać wdrożeniem. Jak już pisałem w notce o automatycznym chaosie jeśli wdrażamy coś w organizacji to przede wszystkim musimy wiedzieć co wdrażamy i mieć jakiś, co najmniej ogólny plan wdrożenia. Pisałem też już kiedyś o teorii i jej zestawieniu z praktyką, moje doświadczenia jasno pokazują, że teorie sprawdzają się w przygniatającej większości przypadków jeśli tylko spełni się jeden zasadniczy warunek – postępuje się według jednej teorii od początku do końca.
Miałem okazję jakiś czas temu wspierać jeden mały zespół podczas wdrażania Scrum, postanowiłem zastosować zasadę Shu-Ha-Ri. Na początku pokazałem im wszystkie artefakty, pokazałem jak powinno wyglądać planowanie, jak rozbijać zadania, jak rozmawiać podczas spotkań typu stand-up oraz wyjaśniłem klientowi w jaki sposób opisywać wymagania. Po dwóch sprintach, podczas których na prawdę sumiennie starali się przestrzegać wszystkich zasad, praktycznie nie musiałem już tłumaczyć po co to wszystko było – sami dobrze wiedzieli co zyskali porównując sytuację obecną z poprzednimi projektami i z łatwością potrafili wskazać przyczyny stosowania takich a nie innych technik. Obecnie po trzech miesiącach zespół skutecznie wprowadza własne usprawnienia do stosowanej metodologi – starają się używać TDD, programują w parach, robią regularne przeglądy kodu. Wielce pomocne okazały się retrospekcje, które dosyć szybko definiowały problemy, a metoda systematycznego wprowadzania poprawek do procesu owocuje polepszeniem jakości pracy a także lepszą atmosferą i motywacją wynikającą każdorazowo z sukcesu jakim jest eliminacja błędów z procesu.

Po raz pierwszy o Shu-Ha-Ri przeczytałem w książce Alistera Cockburn’a „Agile Software Development – Gra Zespołowa”, którą polecam. Lektura zachęciła mnie do dalszego drążenia tematu, którego efektem jest ta notka

1 komentarz więcej...

O motywacji słów kilka.

opublikowany przez 04, Lut, 2011, w kategoriach Praca, Zarządzanie

Zastanawiałem się ostatnio nad czynnikami, które wpływają na to, że jedne projekty kończą się sukcesem, a inne niestety porażką. Po analizie kilku przypadków doszedłem do wniosku, że jednym z ważnych czynników sukcesu jest odpowiednie motywowanie pracowników. Oczywiście nie jest to jedyny warunek, który trzeba spełnić, niemniej jednak warto zastanowić się co nas motywuje do pracy? Pierwsza odpowiedź jaka się nasuwa zdecydowanej większości pytanych to „pieniądze”. Ale czy na pewno? Z doświadczenia wiem, że pieniądze owszem motywują na początku kariery, zwłaszcza wtedy, gdy się tych pieniędzy nie miało, a tu nagle co miesiąc na konto spływają regularne całkiem pokaźne sumy. O takiej motywacji możemy mówić jedynie w kontekście pracowników niedoświadczonych, przeważnie młodych, zaczynających swe kariery. Co innego, gdy mamy do czynienia z pracownikami doświadczonymi, wysokiej klasy specjalistami czy też ekspertami. Specjalistów rzadko motywują pieniądze, a jeśli już to jest to motywacja krótkotrwała. Nie wiem jak w innych dziedzinach ale jeśli o IT chodzi to obecnie w Polsce specjaliści są bardzo poszukiwani i wiele firm jest w stanie zapłacić na prawdę duże pieniądze za ich usługi, tym samym dla pracodawców zwiększa się ryzyko tego, że ktoś podbierze (podkupi) ich najlepszych pracowników oferując wyższą pensję.

Co zatem zrobić? Jak inaczej niż za pomocą pieniędzy motywować pracowników?

Okazuje się, że wspomniani ‚specjaliści’ pracują głównie po to by osiągać satysfakcję z wykonanej pracy. Jeśli pracownik jest dumny z wykonywanej pracy samoistnie przekłada się to na jego wysoką motywację, co skutkuje wysoką produktywnością. Zastanawiając się nad tym co sprawia, że jesteśmy dumni z wykonywanej pracy możemy dojść do trzech wniosków.

Możemy być dumni z produktu naszej pracy. Jeśli oprogramowanie, które wytwarzamy jest dobre, dobrze napisane, spełnia wszystkie wymogi jakościowe to możemy być dumni ze swojego dzieła. Jako anty-przykład podam system, który ogólnie rzecz biorąc działa, marketingowcy z powodzeniem sprzedają go klientom dzięki czemu firma zarabia, niemniej jednak jakość kodu i sposób jego wytwarzania są na tak niskim poziomie, że żaden programista nie chciałby tego systemu pokazywać w swoim portfolio wiedząc, że potencjalny pracodawca mógłby ten kod przejrzeć. W takiej sytuacji pracownik może powiedzieć: „OK, cieszę się że system działa, ale po powrocie do domu nie czuje satysfakcji z wykonywanej pracy – system jest ok, ale tak na prawdę to jeden wielki śmietnik owinięty ładnym papierkiem”.

Kolejny rodzaj dumy to duma z osiągnięć. Pracownicy odczuwają satysfakcje, gdy ich praca przyczynia się do osiągnięcia sukcesu – sukcesu firmy, sukcesu projektu, czy nawet samego wybicia się zespołu ponad szeregi innych pracowników. Żeby motywować pracowników za pomocą tej metody wystarczy definiowanie odpowiednio małych celów, których osiągnięcie w krótkim czasie oznacza sukces, który następnie powinien być celebrowany w odpowiedni sposób. Dobrym przykładem zastosowania takiego rodzaju motywacji może być nagradzanie i ciągłe powtarzanie zespołowi, który pracuje nad wytwarzaniem nowych funkcjonalności frontendowych, które są potem sprzedawane klientom, że to oni generują większość zysku w firmie, która zatrudnia także programistów backendowych nie mających bezpośredniego wpływu na zyski firmy.

Oprócz powyższych jest jeszcze jeden ważny aspekt motywowania pracowników. Pracownicy są dumni z uczestnictwa w czymś dużym. Człowiek jest istotą stadną, dlatego łączymy się w grupy, społeczeństwa etc. Podobnie jest w przypadku wykonywania pracy im bardziej pracownik czuje się częścią małej społeczności w zakładzie pracy tym bardziej wpływa to na jego motywację. Ponadto znaczący wpływ na motywacje ma świadomość skali tego co jest produkowane. Zupełnie inne podejście w tej kwestii ma pracownik firmy takiej jak Google, Microsoft czy Apple, który ma świadomość tego, że z produktów jego pracy korzystają codziennie miliony użytkowników, a zupełnie inaczej swój udział w przedsięwzięciu ocenia pracownik małej firmy tworzącej sklepy internetowe, które może w najlepszym wypadku dojdą do kilku tysięcy wejść dziennie. Sam udział w przełomowych projektach dużej skali bywa często wystarczająco motywujący by pracownicy wykonywali swoją pracę najlepiej jak to tylko możliwe.

Powyżej opisałem trzy podstawowe czynniki mające wpływ na motywację pracowników. Oczywiście takich zależności jest znacznie więcej, chociażby sama atmosfera pracy, szef, wygodne krzesło, troska firmy o pracownika, rzetelne kierownictwo, które dotrzymuje słowa, społeczne aspekty wykonywanej pracy itd.

7 komentarzy więcej...