blog.testowka.pl

Archiwum wiadomości z Wrzesień, 2013

Źle się dzieje w państwie naszym…

opublikowany przez 23, Wrz, 2013, w kategoriach Agile, Zarządzanie

zielona-wyspa

Tak sobie przeglądam dosyć regularnie różne blogi i artykułu na temat współczesnego zarządzania, Agile, Scrum, Lean i innych metod. W zasadzie tylko pod tymi tworzonymi przez polskich autorów po polsku znajduję komentarze, w których czytelnicy w ogóle poddają w wątpliwość to czy Agile w ogóle działa. Nie – nie pisze tutaj o ostatnich dyskusjach pod poprzednimi wpisami, a przynajmniej nie tylko o tym. Ta tendencja jest znacznie szersza.

Niekończące się kłótnie o to, czy Agile jest lepszy od Waterfall i na odwrót zaczynają być domeną wielu rodzimych konferencji (na przykład zeszłoroczny TestWarez) – głównie tych po polsku. Tam gdzie przemawiają obcojęzyczni prelegenci mało kto wdaje się w polemikę. Nie wiem – może wstydzą się, że nie znają języka. A skoro nie znają języka to pewnie nie czytają tego co się na świecie pisze. W sumie gdyby czytali to pewnie by nie polemizowali z rzeczywistością.

Na całym świecie Agile powoli przestaje kogokolwiek zaskakiwać. Ba! Niektórzy twierdzą, że powoli Agile przechodzi do lamusa, że są już lepsze metody, nurty w zarządzaniu. A u nas? U nas o Agile albo nie słyszeli, albo mówią, że Agile to Yeti – ktoś to podobno widział. U nas (nie tylko u nas, ale tu też) używają słów takich jak Agile albo Scrum do opisania rzeczy, które z tymi pojęciami mają niewiele wspólnego. Cóż to trochę boli – ale nie ma co narzekać – pracujemy nad zmianą tego stanu rzeczy. Na szczęście są wśród nas ludzie, którzy się spotykają po to, by zdobyć wiedzę, wymienić się nią a nie bezsensownie kłócić.

Agile nie jest jak Yeti (jak niektórzy próbują przekonywać). Agile działa! Oczywiście, zawsze znajdą się przykłady, gdzie Waterfall działa. Bo Waterfall działa!

Ja nie rozumiem tylko jednego – skoro Waterfall tak dobrze działa, to czemu wiele różnych badań (jak chociażby wspomniany ostatnio Chaos Report) pokazuje, że Agile działa lepiej.

STOP! Takie dyskusje, o tym czy Agile, czy Waterfall jest lepszy nie mają sensu!

Drodzy czytelnicy, jeśli macie problemy z tym, że piszę o Agile jako o czymś co działa i jest powszechnie stosowane to… hmm… to czytajcie uważnie to co piszę, zadawajcie pytania, dyskutujcie – na przykład na facebooku albo twitterze, albo w komentarzach.  Z chęcią na nie odpowiem, po polsku i za darmo! Przy okazji może sam się czegoś od Was nauczę!  Może dzięki temu dyskusje o tym „czy Agile działa?” przerodzą się w dyskusje o tym „jak sprawić by osiągnąć jeszcze więcej – nie ważne czy za pomocą Agile czy Waterfall czy jeszcze czegoś innego?”.

Może takie negatywne i zacofane postrzeganie naszej szarej rzeczywistości wynika z tego jak ogólnie wygląda IT w naszym kraju. Przeważająca większość firm IT w Polsce to firmy zagraniczne, które tutaj znalazły sobie „tańszą” i często lepszą siłę roboczą. Wśród pozostałych znajdziemy w większości albo firmy robiące software dla sektora publicznego, albo polskie firmy outsourcujące developerów „na zachód”. Trochę to układ niewolniczo-feudalny, jak by się nad tym głębiej zastanowić. I fakt w wielu przypadkach pod szyldem „Agile” albo „Scrum” panowie tychże niewolników próbują przemycić kolejne metody wyzysku białych murzynów. Nie dajcie się bez walki! Wiedza o tym czym naprawdę jest Agile jest Waszą bronią :-).

5 komentarzy więcej...

Kolejny post o metrykach – w odpowiedzi na pytania

opublikowany przez 20, Wrz, 2013, w kategoriach Agile, Testowanie, Zarządzanie

4324373384_a4c0d68189_z

We wczorajszej notce nawiązałem do wpisu na testerzy.pl dotyczącego mierzenia jakości pracy testera.

Dla mnie jedyną z pozoru sensowną metryką spośród wspomnianych w artykule z odnośnika wydaje się być mierzenie stosunku ilości błędów, które wyszły na produkcję do tych, które zostały wykryte – niemniej jednak w ten sposób nie mierzymy efektywności testerów tylko raczej ich nieefektywność.

O metrykach wszelkiego rodzaju wspomniałem już w książce „Mity i problemy w Agile”. Nie zrozumcie mnie źle, nie uważam, że wszystkie metryki są bezwartościowe. Uważam, że niektóre z nich są bez sensu, a inne powodują większe szkody niż dostarczają wartości.

Zawsze, gdy ktoś atakuje mnie metryką zadaje proste pytanie po co chce daną rzecz mierzyć? O ile pytanie jest proste z odpowiedzią na nie bywa już różnie. Przeważnie okazuje się, że albo zamierzony cel jest bez sensu, albo można go osiągnąć w inny, mniej bolesny i kosztowny sposób.

Tak, mniej kosztowny! Metryki są kosztowne! „Ludzie zawsze robią to co jest w nich wzmacniane” – to podstawy psychologii i socjologii. Metryki są wzmocnieniem. Jeśli wzmacniamy w testerach potrzebę raportowania jak największej ilości błędów to wkrótce utoniemy pod sterami raportów, dla których będziemy musieli opracować nowe metody zarządzania defektami. Gdy, zaczniemy mierzyć ilość błędów na produkcji, to strach przed wydaniem stanie się na tyle paraliżujący, że na pytanie o jakość produktu testerzy zawsze będą odpowiadać, że jest niewystarczająca. Takie informacje są bezwartościowe dla każdego managera – nawet Test Managera.

W odpowiedzi na poprzedni wpis na blogu Radek z testerzy.pl napisał.

Dzięki za wspomnienie naszej publikacji.
Warto dodać, że sam wspomniałeś, że środowisko Agile i małe projekty to środowisko „normalne”. Nie odpowiadasz na podstawowe pytanie.
Co ma zrobić tester / kierownik testów, kiedy pracuje w „nienormalnym” (w twojej opinii) środowisku, a jego wpływ na metody wytwarzania oprogramowania, technologie, wielkość produktu jest żaden? Ma zmienić pracę i pójść do organizacji z wdrożonym Agile?
Czy instytucja bankowa, która kupuje całościowy system wsparcia działania ma uruchamiać drobne funkcjonalności? Jakby w takimi wypadku wyglądał i ile by trwał start AliorBanku?
Jak wyobrażasz sobie, że osoba z 40 letnim doświadczeniem biznesowym, Pani Halina z księgowości (bez świadomości modeli wytwarzania oprogramowania) usiądzie z programistą w jednym zespole i razem coś zbudują? A co jeśli takich osób trzeba zaangażować 40?

Zadane przez Radka pytania są bardzo trafne, dlatego zdecydowałem, że zasłużyły sobie na osobny wpis na blogu.

Moje odpowiedzi poniżej:

Warto dodać, że sam wspomniałeś, że środowisko Agile i małe projekty to środowisko „normalne”. Nie odpowiadasz na podstawowe pytanie.
Co ma zrobić tester / kierownik testów, kiedy pracuje w „nienormalnym” (w twojej opinii) środowisku, a jego wpływ na metody wytwarzania oprogramowania, technologie, wielkość produktu jest żaden? Ma zmienić pracę i pójść do organizacji z wdrożonym Agile?

W sumie zastanawiam, się czy normalne to dobre słowo? W końcu normalne to nie odbiegające od normy. Jeśli za normę przyjmiemy większość tego co dzieje się na świecie to… nie – projekty Agile nie są normalne! Natomiast jeśli weźmiemy pod uwagę zdrowy rozsądek…

Jak napisałem wczoraj Waterfall działa świetnie dla „dużych projektów”. I to wcale nie był sarkazm. Waterfall działa tam naprawdę dobrze. To znaczy tak dobrze jak jest to w takim środowisku możliwe. Nie widzę żadnego sensu w jakichkolwiek porównaniach Waterfall do Agile.

Oczywiście za chwilę pojawi się pytanie czy w takim razie można w ogóle przekształcić Waterfallową organizację w organizację Agile? Tak, można – jest to trudne i wymaga wielu zmian, na wielu poziomach. Dotyczy to również zmian w tworzonych produktach i w sposobie tworzenia tych produktów.  Często zmiana sposobu ich tworzenia sama sprawia, że produkty ewoluują we właściwym kierunku samoczynnie – jednak chyba lepiej to robić świadomie.

Co ma zrobić taki tester/kierownik testów w opisanej sytuacji? Ludzie są różni – niektórym (myślę, że wielu z nas) odpowiada stabilna praca w miarę niezmiennym środowisku, gdzie jesteśmy odpowiedzialni tylko za swoją działkę. W takim środowisku można dalej się uczyć, rozwijać swoje umiejętności, zwiększać jakość swojej pracy etc. Jednak czasem można (tak jak ja kilka lat temu) dojść do miejsca, w którym dostrzegamy nowe, większe możliwości. Jakość oprogramowania nie zależy od testerów – nie tylko od testerów. Więc albo możemy się oszukiwać i udawać, że stoimy jako testerzy na straży jakości nie mając tak naprawdę na nią zasadniczego wpływu, albo pogodzić się z tą rzeczywistością i dzięki starannej kontroli jakości dostarczać jak najbardziej obiektywne informacje o jakości do osób decyzyjnych. W ten sposób również możemy stać się mistrzami w swoim fachu.

Możemy też iść całkowicie inną drogą i faktycznie zmienić pracę na taką w której będziemy mieli na jakość wpływ. Często będzie wymagało to od nas zdobycia wiedzy znaczenie szerszej niż ta z obszaru testowania oprogramowania. To wszystko jest kwestią indywidualną.

Czy instytucja bankowa, która kupuje całościowy system wsparcia działania ma uruchamiać drobne funkcjonalności? Jakby w takimi wypadku wyglądał i ile by trwał start AliorBanku?

Jeśli taka instytucja chce mieć oprogramowanie, które na prawdę będzie odpowiadało ich wymaganiom to tak, powinna pracować inkrementalnie. Ba, znam kilka przykładów instytucji bankowych czy nawet międzybankowych które dokładnie tak pracują. Kilkadziesiąt (w porywach do 100) osób pracujących nad systemem do transakcji międzybankowych i ani jednego testera. Pełna automatyzacja testów, BDD, TDD i jeśli wyjdzie jakiś błąd na produkcje to koszty idą w miliony – jeszcze raz – nie ma tam testerów!

Jak wyobrażasz sobie, że osoba z 40 letnim doświadczeniem biznesowym, Pani Halina z księgowości (bez świadomości modeli wytwarzania oprogramowania) usiądzie z programistą w jednym zespole i razem coś zbudują? A co jeśli takich osób trzeba zaangażować 40?

Zdarzyło mi się pracować kilka razy z takim właśnie „Paniami Halinami” i teraz jestem już przekonany, że właśnie jak najczęstsze pokazywanie im działającego produktu jest jedynym sposobem na zrealizowanie prawdziwych wymagań co do tego produktu. Pani Halina nie rozumie pojęć typu formularz, nie wie co to jest checkbox ani radiobutton, nie ma pojęcia o AJAXie, etc.

Gdy pokażę Pani Halinie produkt z formularzem to dowiem się, że dla niej jest to formatka, a pokazując listę rozwijalną dowiem się, że chodziło o checkboxy, bo można wybrać kilka opcji a nie jedną. Tego dokumentacja nie przewidziała, bo dokumentacja jest kolejną abstrakcją, która nie dość, że jest niezrozumiała dla programistów to jeszcze nie jest zrozumiała dla Pani Haliny.

Na szczęście jako ludzie, od dziecka kształcimy nasze zdolności komunikacji – potrafimy nawet porozumieć się z ludźmi nie mówiącymi w naszym języku, głównie poprzez pokazywanie przykładów i wizualizacje. Właśnie dlatego każdy programista czy tester, nawet ten najbardziej introwertyczny lepiej dogada się z Panią Haliną niż zrozumie dokumentację.

Świadomość istnienia modeli wytwarzania oprogramowania jest tutaj zbyteczna zarówno u Pani Haliny jak i nawet u programistów i testerów. Opieramy się na podstawowym założeniu, że interakcje pomiędzy ludźmi (ludźmi o zróżnicowanej wiedzy) są lepsze niż jakiekolwiek procesy i narzędzia.

A co jeśli trzeba zaangażować 40 takich osób jak Pani Halina? A trzeba? Czy na pewno? Nawet jeśli to czemu nie – zdarzało mi się robić Sprint Review na którym było około 25 gości z poza IT. Bardzo ciekawe i produktywne dyskusje się tam odbywały. Oczywiście na końcu był jeden Product Owner, który decydował o tym, co jest najważniejszy w danym momencie niemniej jednak wkład od wszystkich gości i innych stakeholderów był znaczący w ciągły rozwój produktu.

Wracając do metryk – według drugiej strony Manifestu Agile jedyną miarą postępu pracy jest działające oprogramowanie. Ja dodam od siebie, że tą miarą jest działające oprogramowanie, które ma sens. Pamiętajcie o zasadzie Pareto – 80% wartości jest generowana przez 20% funkcjonalności.

„Duże projekty” to problem, co ładnie obrazuje podsumowanie CHAOS Report (strona 13 – dla tych co się im nie chce czytać całości). To są twarde dane – oczywiście zawsze znajdą się wyjątki, ale jednak…

W sumie może powinienem napisać o tym jak w takim razie zmienić „duży projekt” w wiele małych?

6 komentarzy więcej...

Agile dla „dużych projektów” nie działa

opublikowany przez 19, Wrz, 2013, w kategoriach Agile, Kanban, Scrum, Testowanie, XP, Zarządzanie

5665717830_dfe3ea51c2_o

Po raz kolejny ktoś próbował mi udowodnić, że Agile dla „dużych projektów” się nie sprawdzi. I… Generalnie zgadzam się z tym stwierdzeniem. Zgadzam się, tak! Agile dla „dużych projektów” nie działa!

Agile z pewnością nie zadziała jeśli za miarę wielkości „dużego projektu” przyjmiemy ilość ludzi nad tym projektem pracujących. Jeśli duże projekty dla Was to takie nad którymi pracuje 200 lub więcej osób to macie znacznie większe problemy niż, to czy Agile zadziała, czy nie.

„Duże projekty” to dysfunkcja sama w sobie.

Programowanie jest rozwiązywaniem problemów – nie potrafię sobie wyobrazić problemu, który potrzebował by więcej niż kilkadziesiąt osób do jego rozwiązania. Owszem, niektóre problemy są bardziej złożone od innych – w takim przypadku jedyne rozsądne rozwiązanie to rozbicie ich na mniejsze – być może mniej złożone problemy i stworzenie mniejszych zespołów rozwiązujących je.

Waterfall powstał właśnie po to, by radzić sobie z „dużymi projektami”. Waterfall jest cool. Waterfall działa… dopóki nie zaczniesz się nad tym zastanawiać…

Cała pseudonauka o tym w jaki sposób powinniśmy testować (oczywiście manualnie) skomplikowane projekty, zarządzać milionami przypadków testowych, poprawnie zgłaszać miliony bugów, następnie zarządzać tymi zgłoszeniami, mierzyć ilość tych zgłoszeń i co gorsza tworzyć z tego metryki mające na celu określenie jakości pracy testerów [BLAH!], to wszystko powstało w odpowiedzi na realne problemy. Problemy, które sami sobie stworzyliśmy budując niewłaściwe oprogramowanie w niewłaściwy sposób.

Skalowanie Agile to kolejny urojony problem.

Coraz więcej na około słyszy się o nowych, pięknych i kompleksowych metodach skalowania Agile. Niektóre z nich nawet zapewne działają. Ba, nawet widziałem je w działaniu. Niestety nadal są to narzędzia służące do rozwiązywania problemów, które ktoś, gdzieś sam sobie stworzył.

Agile nie trzeba skalować, jeśli jesteśmy w stanie przeskalować nasz produkt. Tak jak na przykład zrobili to w Spotify. Kluczem do sukcesu nie jest stworzenie squad’ów, tribe’ów, chapter’ów czy guild’ów… To wszystko powstało tylko po to by wokół wielu, względnie niezależnych komponentów produktu, rozwijanych przez interdyscyplinarne i kros-funkcjonalne zespoły stworzyć platformę służącą do synchronizacji pracy i wymiany wiedzy. Agile jest gdzieś indziej – w każdym zespole z osobna. Nie ma tutaj żadnego skalowania.

Więc tak, Agile nie działa w „dużych projektach”! Duże projekty są problemem samym w sobie. Nie chcę tutaj rozwodzić się nad potencjalnymi i faktycznymi przyczynami tego dlaczego nadal mamy do czynienia z tak wieloma „dużymi projektami”. To nie jest czas na to – niech ten post będzie dla Was przestrogą, by Wasze małe jeszcze projekty nigdy nie stały się „dużymi projektami”.

8 komentarzy więcej...

(Nie do końca) darmowe szkolenie Scrum

opublikowany przez 17, Wrz, 2013, w kategoriach Agile, Scrum

FREE BEER

Serdecznie zapraszam wszystkich na darmowe szkolenie zatytułowane: „Mity i problemy w Agile – mity o Scrum”, które będę prowadził.

Szkolenie odbędzie się w Krakowie 04.10.2013 – więcej szczegółów oraz rejestracja na stronie www.agileszkolenia.pl.

Za udział w szkoleniu nie musicie nic płacić – jest jednak pewien haczyk.

Szkolenie to organizujemy z Code Sprinters dla społeczności. Poświęcam swój czas na przygotowanie, przeprowadzenie oraz promocję warsztatów. Code Sprinters sponsoruje wszystkie opłaty związane z organizacją szkolenia.

Jedyne czego oczekujemy od Was to, to że w zamian za 8 godzin udziału w szkoleniu poświęcicie 8 godzin swojego czasu dla społeczności.

Przy rozpoczęciu szkolenia podpiszemy umowę w której będzie napisane, że w zamian za udział w szkoleniu zobowiązujecie się poświęcić 8 godzin swojego czasu na rzecz społeczności Agile/Scrum lub innej podobnej, działającej w Waszej okolicy. Umowa będzie sporządzona w jednym egzemplarzu – dla Was. Podpiszemy się na niej – zarówno Ty jak i ja.

Jak to wywiążecie się z umowy – to już zależy od Was. Może na przykład zorganizujecie kolejne spotkanie BYOP? Może sami poprowadzicie jakiś warsztat w tej formie?

Pamiętajcie, że gdy już poświęcicie swoje 8 godzin to możecie w zamian oczekiwać od tych, którzy z tego czasu skorzystali dokładnie tego samego. W ten sposób wkrótce razem zbudujemy coś naprawdę wielkiego!

W ten sposób chcemy sprawić, by więcej osób nie tylko uczestniczyło w wydarzeniach organizowanych przez społeczności takiej jak na przykład BYOP, Agile Warsaw czy ALE Kraków, ale także by pojawili kolejni aktywni członkowie tych społeczności, którzy dadzą coś od siebie.

Cały pomysł zapożyczyłem od Jaume Jornet (@JaumeJornet)- który z powodzeniem aktywizuje społeczność Agile w Barcelonie.

20 komentarzy więcej...

O tym jakie to „ciekawe” i „unikatowe” oferty pracy mamy na rynku…

opublikowany przez 12, Wrz, 2013, w kategoriach Inne, Praca

worksucks

Wszelkiej maści rekruterzy i head hunterzy coraz częściej zapełniają folder ze spamem w mojej skrzynce pocztowej. Na portalach społecznościowych typu Golden Line i LinkedIn korespondencja tego typu stanowi przeważającą większość wiadomości, które otrzymuję.

Dlaczego z reguły na nie nie odpowiadam? Ponieważ nie chce pracować dla firmy, która traktuje ludzi jak zasoby – jeśli nie zadają sobie trudu by samemu dotrzeć do potencjalnych pracowników, to raczej nie będzie im później na nich zależało. Pomijam już kwestie tego, że jakość takich usług zazwyczaj (pewnie nie zawsze) pozostawia wiele do życzenia. Jak ktoś, kto nie zna mojej firmy może znaleźć mi odpowiednich pracowników, których ja sam bym zatrudnił.

Niestety tego typu handel żywym towarem staje się coraz bardziej popularny na całym świecie. Jest na szczęście też coraz więcej inicjatyw które stanowczo walczą z tego typu bezsensownym marnotrawieniem ludzkiego potencjału.

Piszę tutaj nie tylko jako teoretyk ale też praktyk, który miał (nie) przyjemność korzystać z takich usług zarówno jako rekrutowany jak i ten, który postanowił spróbować skorzystać z usług firmy zajmującej się rekrutacją do wyszukania i pozyskania odpowiednich pracowników – w ramach eksperymentu (który kosztował nas bardzo dużo niestety).

Poniżej prezentuje jedną z wiadomości jakie otrzymałem na Golden Line oraz moje komentarze:

Witam Panie Wiktorze,

W imieniu dyrektora personalnego, globalnego lidera rozwiązań informatycznych, poszukuję do nowoczesnego centrum w Krakowie, osób na stanowisko: Tester Oprogramowania.

Ofertę wyróżnia:

-Bardzo ciekawa praca oparta o najnowsze technologie
-Możliwość udziału w innowacyjnych projektach
-Rozwój wiedzy i kompetencji poprzez zaprojektowaną ścieżkę kariery
-Rozbudowany pakiet szkoleń wprowadzających, obejmujący szkolenia techniczne, technologiczne oraz z umiejętności miękkich
-Przyjazna atmosfera w pracy
-Dostęp do prywatnej opieki medycznej
-Karta Benefit MultiSport
-Bardzo dobre warunki finansowe, w granicach 5 – 8 tys zł brutto

Wymagania:

-Wykształcenie wyższe techniczne
-Podstawowa znajomość relacyjnych baz danych i SQL
-Znajomość zagadnień z zakresu testowania aplikacji i zapewniania jakości
-Znajomość zagadnień z zakresu metod analizy strukturalnej i obiektowej
-Znajomość języka angielskiego
-Zdolność uczenia się i wykorzystywania doświadczeń
-Komunikatywność

Czytając tego maila miałem ochotę zanegować wszystko co było w nim napisane, a więc po kolei:

W imieniu dyrektora personalnego, globalnego lidera rozwiązań informatycznych, poszukuję do nowoczesnego centrum w Krakowie, osób na stanowisko: Tester Oprogramowania.

Co to za lider, który wstydzi się podać swoją nazwę? To tani chwyt, który pozwala rekruterowi nawiązać pierwszy kontakt. Pamiętajcie, ze rekruterzy to sprzedawcy, a sprzedawcy są od tego żeby wcisnąć nam coś czego nie potrzebujemy. Jak czegoś na prawdę potrzebujemy to sami potrafimy to znaleźć i zdobyć. Nie jesteśmy przecież upośledzeni – przecież pracujemy w IT, no nie?

Ciekawe ponadto dlaczego pan rekruter myśli, że mógłbym z moim doświadczeniem być zainteresowany pracą jako Tester Oprogramowania. Ciekawe czy w ogóle zapoznał się z moim profilem.

Ofertę wyróżnia:

O nie wątpię, że wyróżnia… A właściwie… to wątpię… Mniej więcej to samo jest w każdej ofercie…

-Bardzo ciekawa praca oparta o najnowsze technologie

Ciekawe jakie to technologie? Java, C#, Ruby on Rails? To wszystko to nie jest nic nowego? Jak już ktoś pisze o najnowszych technologiach to lepiej by było, gdyby podał o jakie technologie chodzi. Przy okazji (zakładając, że faktycznie są to najnowsze technologie) wzrosły by sznase na znalezienie kogoś, kto daną technologią się interesuje.

-Możliwość udziału w innowacyjnych projektach

Ciekawe co ogłoszeniodawca rozumie przez innowacje? To temat rzeka.

-Rozwój wiedzy i kompetencji poprzez zaprojektowaną ścieżkę kariery

Fajnie, że ktoś wie lepiej ode mnie co jest dla mnie dobre i z góry zaprojektował moją ścieżkę kariery. Poza tym nie rozumiem jak zaprojektowana ścieżka kariery ma się do rozwoju wiedzy i kompetencji?

-Rozbudowany pakiet szkoleń wprowadzających, obejmujący szkolenia techniczne, technologiczne oraz z umiejętności miękkich

Czytam to i myślę sobie: czyli macie tak poplątane procesy i badziewny produkt, że potrzebne są szkolenia wprowadzające by móc cokolwiek z nim zrobić? Dodatkowo uważacie, że problem leży w umiejętnościach miękkich jak na przykład radzenie sobie ze stresem, rozwiązywanie konfliktów – zwłaszcza z managerami, o i może motywacja! 

A może się mylę i chodzi o to, że i tak nie liczą na to, że zatrudnią kogoś kto wie cokolwiek i z góry zakładają, że trzeba będzie kogoś takiego od zera wszystkiego nauczyć.

-Przyjazna atmosfera w pracy

Czy szanowny rekruter był w tej firmie, pracował tam i wie, że taka właśnie atmosfera tam panuje?

-Dostęp do prywatnej opieki medycznej
-Karta Benefit MultiSport

O super, ale to akurat dzisiaj już chyba nie wyróżnia ofert pracy. Może się mylę…

-Bardzo dobre warunki finansowe, w granicach 5 – 8 tys zł brutto

O! Pierwszy pozytyw, wreszcie w ofertach podają widełki finansowe! Po przeliczeniu 3500-5500 na rękę. Chyba całkiem nieźle jak na stanowisko Tester Oprogramowania.

Dobrze – przejdźmy do wymagań:

-Wykształcenie wyższe techniczne

Ups, niestety nie spełniam tego wymagania, więc odpadam. Jest na pierwszym miejscu, więc pewnie jest to najważniejsze. Niestety mam 8 lat doświadczenia w branży i ledwo skończyłem 26 lat. Nie było czasu na studia, które poza papierkiem w obecnej rzeczywistości nic by mi nie dały. Jakie szczęście, że są firmy które bardziej cenią doświadczenie niż papier.

-Podstawowa znajomość relacyjnych baz danych i SQL

Co to znaczy „podstawowa”? Znam SQL, potrafię kilka zapytań stworzyć jeśli będzie trzeba.

-Znajomość zagadnień z zakresu testowania aplikacji i zapewniania jakości

Skoro przyszli do mnie z ofertą pracy jako tester oprogramowania to chyba wybrali właśnie mnie na podstawie tego, że wedle ich oceny mam jakieś umiejętności z tego zakresu.

-Znajomość zagadnień z zakresu metod analizy strukturalnej i obiektowej

„Analiza strukturalna” – za cholerę nie wiem o co chodzi – pytam więc Google. Wyniki, to fizyka, chemia, geodezja – czy oni na pewno szukają testera? Może chodziło o programowanie strukturalne i obiektowe?

-Znajomość języka angielskiego

Heloł mai nejm iz aj perfekt spik englisz. 

-Zdolność uczenia się i wykorzystywania doświadczeń

Wydawało mi się, że każdy człowiek (i ie tylko jest do tego zdolny) – widocznie się myliłem.

-Komunikatywność

Tą zdolność, też chyba każdy z nas posiada.

Ciekawa oferta – wysłał bym CV. Szkoda tylko, że go nie posiadam – wszystkie informacje na mój temat potrzebne do rekrutacji są na moim profilu na LinkedIn.

Generalnie ogłoszenie nudne jak flaki z olejem. Jak przerażająca większość ogłoszeń. Nie to żebym sam nigdy takich nie tworzył, ale teraz już wiem, że to nuda.

Także drodzy pracodawcy jeśli szukacie ciekawych i wartościowych ludzi to musicie oferować ciekawą i wartościową pracę – taka praca musi być też odpowiednio opisana by zainteresować właściwe osoby.

Jeśli szukacie ludzi, którym będzie zależeć na waszej firmie i waszych produktach to wam też musi zależeć na tych ludziach i ich odpowiednim wyborze. Dlatego nie zlecajcie tak ważnej dla całej organizacji sprawy komuś z zewnątrz.

13 komentarzy więcej...

Czy potrzebujesz Agile Coacha?

opublikowany przez 10, Wrz, 2013, w kategoriach Agile, Coaching, Kanban, Praca, Scrum, XP, Zarządzanie

2536358399_88e6544fa9_o
Po raz kolejny utwierdziłem się w przekonaniu, że ludzie nie czytają, nie tylko moich książek, czy mojego bloga… Ludzie nie czytają w ogóle, albo czytają bardzo mało rzeczy związanych z ich pracą. Utwierdziłem się w sposób najprostszy – pytając około 35 osób czy czytają… Ludzie nie czytają i nie jeżdżą na konferencje bo najzwyczajniej nie mają na to czasu przez pracę. Często przez to, że ich praca jest nieefektywna muszą pracować więcej, by osiągnąć oczekiwane rezultaty. Pracując więcej nie mają czasu na to, by poczytać o tym jak pracować efektywniej…

I w sumie bardzo dobrze… Bo ja czytam… Bo ja piszę książki… Bo ja jeżdżę na konferencje i czasem tam coś opowiadam… Publikuję czasem coś na blogu ale przede wszystkim czytam blogi innych… Poświęcam dużo czasu na naukę nowych rzeczy, ale też na przemyślenia związane z praktycznym zastosowaniem tego co już umiem… Eksperymentuje z nabytą wiedzą stosując ją w praktyce… Ciągle nabywam coraz więcej doświadczenia związanego z tymi tematami… Bardzo różnorodnego doświadczenia dzięki pracy dla bardzo różnych klientów… Klientów w różnym kontekście, w różnym środowisku, w różnych technologiach i w różnych branżach… Rozmawiam z ludźmi, dzielę się swoim doświadczeniem ale też korzystam z doświadczeń innych…

Właśnie to wszytko, właśnie to, że ja MAM na to czas i że swój czas na to właśnie poświęcam jest głównym powodem tego, że bardziej opłaca Ci się zatrudnić mnie jako Agile Coacha, jako Mentora, jako Trenera, jako Doradce, niż samemu poświęcać nieskończoną ilość godzin na wyszukiwanie i zdobywanie tej wiedzy i doświadczenia. Jest to również bardziej opłacalne niż samodzielne popełnianie błędów – zwłaszcza tych kosztownych i tych, które ja już wcześniej miałem okazję popełnić, lub zaobserwować gdzieś indziej.

Poza tym ja lubię to robić. Robię to z pasją. Nie traktuję tego nawet jak pracę – jest to bardziej moje hobby…

Dość tej autopromocji! Generalnie chodzi o to, że zdobywanie wiedzy to również ciężka praca wymagające wielu poświęceń, a już na pewno dużej ilości poświęconego czasu. Czasem można jednak zdać się na kogoś, kto już tą wiedzę posiada, albo ma czas na to, by zdobyciu tej konkretnej wiedzy się poświęcić…

8 komentarzy więcej...