piątek, 30 maja 2014

Zarządzanie projektami na podstawie ryzyka w wytwarzaniu sekwencyjnym oraz w iteracyjnym

Zarządzanie projektami na podstawie ryzyka w wytwarzaniu sekwencyjnym oraz w iteracyjnym - Kraków 10 czerwca, 18:00

Zapraszam w Krakowie 11 czerwca

BrightTalk, ul. Lubicz 23 A, "Testowanie wg modelu", 18:00, 11 czerwca

Stara baśń o trzech braciach i zarządzaniu procesami - METODYKA TRES HERMANOS! Nowość! Zwinnie!

(tak, niektórzy już tę moją bajkę czytali gdzie indziej)
  • Tak, podobny temat poruszałem rok temu na Forum Jakości 2013 ("Testowanie na podstawie ryzyka - ostateczne rozwiązanie tajemnicy")
  • W tym roku chcę z tematyką trzech braci (jakbym był wojującym agileowcem, pisłabym o tematyce tres hermanos!) wrócić na kolejnym Forum Jakości ("Ekonomika jakości") - w nowej odsłonie :)
TRES HERMANOS
Stary ojciec, umierając, podzielił majątek równo między swoich trzech synów: Adama, Jana i Konstantego. A że nie miał do dyspozycji kota w butach, więc, choć niechętnie, bo to niezgodne z logiką bajek, podzielił wszystko na trzy równiutkie części.

Stary ojciec musiał być egalitarystą jeszcze wcześniej, zanim zmogła go ostatnia niemoc, bo Adam, Jan i Konstanty mieli dokładnie takie samo wykształcenie i byli równie mądrzy, i sprytni. Żeby nie wchodzić sobie jednak w życiu w drogę, postanowili rozejść się we świata trzy strony, w ramach Schengen oczywiście. Tam, gdzie osiedli, każdy zaczął zarabiać na życie, zakładając fabrykę granitowych kamieni młyńskich. I choć sami rzeczywiście w drogę sobie nie wchodzili, ich produkty – kamienie młyńskie – na rynku zaczęły ze sobą konkurować.

Powiedzieliśmy już, jak bardzo równo wszystko było między braćmi podzielone, więc choć każdy z nich bardzo się starał, w końcu jedynym, w czym jeden od drugiego mógł być lepszy, okazało się to, który z nich sprawniej i skuteczniej będzie te kamienie projektował, wytwarzał, produkował i sprzedawał.

Na początku był chaos

W fabrykach Adama, Jana i Konstantego wszyscy wszystkim wchodzili w drogę, niczego nie dawało się szybko znaleźć, wciąż były jakieś kryzysy, to samo robiło się po kilka razy bez potrzeby, a za każdym razem inaczej. Było dużo krzyku, dużo mądrzenia się, pełno zamieszania, i choć miało się wrażenie wielkiej pracowitości, gotowych do sprzedaży klientom granitowych kamieni wychodziło z tego tyle, co kot w butach napłakał – bardzo mało.

Przypadkiem przejeżdżała tamtędy (w trzech miejscach naraz – tak w bajkach bywa) kareta wioząca Kopciuszka na bal. Siedząca obok swej podopiecznej Dobra Wróżka widząc bałagan, zatrzymała karocę i każdemu ze zdumionych braci wręczyła magiczną różdżkę z halogenowym napisem ZARZĄDZANIE PROCESEM.

- Nie wierzę w te głupoty! – oznajmił twardo Adam i po staremu z miną groźną, jakby uciekł wprost z okładki czasopisma „Manager”, w ciemnych okularach, wrzeszczał w trzy komórki na raz, wywalał jednych pracowników, zatrudniał drugich, organizował grupy kryzysowe. Jego ludzie pracowali w nadgodzinach, powstał lokalny etos twardego, dynamicznego, młodego pracownika na kompulsywnej adrenalinie.

Nocami słychać było tam wycia młodych wilków, produkcja granitowych kamieni chwilami rosła gwałtownie, tyle że połowę z nich przez pomyłkę wyprodukowano w wersji ozdobnej, z aksamitną powierzchnią ścierną. Czas jakiś trwała ta zadyma, aż w końcu z kurzawy wyszedł obdarty brat Adam i z węzełkiem na kiju powędrował w świat.

Opłaca się praca dobrze zorganizowana

Zostawmy na chwilę konwencję bajki: opłaca się praca dobrze zorganizowana. Po prostu sprawdzoną wielokrotnie prawdą dotyczącą tak produkcji, jak i usług jest, że nakłady na stworzenie, utrzymanie i przestrzeganie stosownych procedur zwracają się zwykle bardzo szybko. Zorganizowany, jednolity, dający się wielokrotnie powtarzać sposób pracy to właśnie PROCES. Niektórym wydaje się irytujące, że PROCES każe młotek zawsze odkładać na to samo miejsce, ale dobry rzemieślnik wie,
jak to ogromnie upraszcza i przyspiesza pracę.

Proces jako zasada odkładania młotka w określone miejsce – to mało odkrywcze. Proces jako zasada, że każdą rozmowę telefoniczną zapisuje się w określony sposób, że istnieje zorganizowany system obsługi klientów, procedury dokonywania zakupów, kontroli jakości, opieki nad kompetencjami i potrzebami pracowników, ba – nawet proces zarządzania całą firmą, to już trudniejsze, prawda? Wszystkie te procesy powinny być ze sobą zgrane, zsynchronizowane – to jeszcze trudniejsze. Tym właśnie zajmuje się dziedzina ZARZĄDZANIA PROCESAMI.

Drugi brat

Drugi z braci, Jan, wziął sobie do serca radę dobrej wróżki. Wkrótce już praca w jego fabryce – tak przy samej produkcji, jak i we wszystkich pozostałych obszarach, zaczęła stosować się do ściśle określonych reguł. Firma chodziła jak dobrze naoliwiony zegarek, każdy znał swoje miejsce, skrybowie pracowicie skrzypieli gęsimi piórami tworząc stosowne zestawiania. Do wszystkiego była odpowiednia procedura. Kiedy patrzyło się na przykład na przenoszenie zamówień klientów od sprzedawców, ubranych w zielone stroje z pawimi piórami, do grupy planującej produkcję, ubranej
jak jeden mąż w szamerowane złotem żółto-liliowe huzarskie mundury, wyglądało to wprost ślicznie, jak zawiły, delikatny, skomplikowany menuet! Jan dumny był, że tak starannie wypełnił zalecenie wróżki i czekał ze strony rynku stosownej nagrody.

Niestety! Okazało się, że skomplikowane menuety równie skutecznie, choć inaczej, niż chaos w fabryce pierwszego brata, niekoniecznie przekładają się na kamiennomłyński sukces! Procedury zbyt zawiłe, zbyt sztywne, zbyt dworskie pochłaniały wszystkim tyle czasu, tak utrudniały skuteczną i sprawną pracę, że… wkrótce i Jan poszedł w ślady swego marnotrawnego brata Adama i obaj, biedacy, znaleźli pracę jako woźnice w karocach, którymi Dobra Wróżka rozwoziła Kopciuszki na dworskie bale we wszystkich epokach i częściach świata.

Trzeci brat, Konstanty, najdzielniej sobie poczynał. W jego firmie ani nie widziało się nerwowej bieganiny jak u Adama, ani skomplikowanych figur dworskiego tańca jak u Jana, ludzi było tam się niewielu, ale jakoś tak wszystko sprawnie szło, jakby za sprawą czarów jakowych!
- Jak ten Konstanty to robi? – dziwili się ludzie, patrząc z zazdrością, jak kamienie młyńskie z dużym, dumnym „K” na środku, skrzypiące, w pary wołów zaprzężone wozy po całym świecie rozwoziły.
- On zna potężne czary! – szeptali.
– Gadają, że te czary to DOBRE, PROSTE, ELASTYCZNE PROCESY – dodawali, spluwając
zabobonnie przez lewe ramię, coby się do nich jakie licho od tych słów nie przyczepiło.

Zarządzanie procesem bizensowym

A dobra wróżka, zniechęcona do pracy zawodowej „uszczęśliwiaczki” zbyt wysokim odsetkiem rozwodów wśród Kopciuszków i ich książąt, widząc sukces Konstantego, postanowiła zająć się uczeniem zasad ZARZĄDZANIA PROCESAMI, w czym najwyraźniej była dobra. Mówią, że nawet wyuczyła kilku zawodowych pogromców smoków, jak zarządzać procesem projektowym, co jest najtrudniejsze, bo jak wiadomo, jeden smok do drugiego niepodobny, a poza tym bestie takie, wielogłowe, wciąż się czegoś nowego uczą i odradzają, więc biada smokobójcy, który by nieustannego doskonalenia się w swym zacnym rzemiośle zaniechał!

środa, 21 maja 2014

Trzy warunki sukcesu projektu informatycznego

Aby porozumieć się z ludźmi i zrealizować cele projektu, w terminie i bez przekraczania kosztów, trzeba:
  1. porozumienia ze sobą interesariuszy i uczestników projektu,
  2. trafnego określenia celów projektu (potrzeb Klienta),
  3. monitorowania, czy idzie się w dobrym kierunku i nadzorowania przebiegu projektu.
Tymi trzema obszarami naraz zajmuje się pozyskiwanie wymagań, gałąź inżynierii wymagań. Jest to dziedzina interdyscyplinarna, łącząca w funkcjonalną całość psychologię, informatykę, zarządzanie, umiejętności biznesowe, socjologię, prawo.

Spotkać się dziś czasem można z naiwnym poglądem, że inżynieria wymagań jest staroświecka, niemal archaiczna; że jest zbędna w metodach agile, przy ciągłej integracji, czy w sytuacji, kiedy prowadzi się testowanie eksploracyjne. Nic bardziej mylnego: właśnie w metodach agile umiejętność współpracy z klientami i użytkownikami jest szczególnie ważna; ciągła integracja potrzebuje znakomitego zarządzania zmianami i związkami wymagań; testowanie eksploracyjne polega głównie na tym, że testerzy sami znajdują i określają - właśnie wymagania.

Jakkolwiek te czynności nazywamy, opisuje je dyscyplina, nazywająca się pozyskiwaniem wymagań (także definiowaniem celów, określaniem potrzeb i priorytetów klientów, specyfikacją).

Umiejętność pozyskiwania wymagań jest równie ważna dla dostawcy (firmy informatycznej, działu IT), co dla zamawiającego. Tylko dobre wymagania pozwalają na negocjowanie warunków umowy wdrożeniowej.

28-29 maja odbędą się w Warszawie, pierwsze w Polsce, warsztaty pozyskiwania wymagań.


Dla kogo są te warsztaty? Dla uczestników projektów agile, dla kadry zarządzającej i właścicieli małych firm, dla projektantów i programistów, dla testerów, dla prawników, dla kierowników projektów, dla specjalistów zamówień publicznych.

Dla kogo jest pozyskiwanie i negocjowanie wymagań?

Ogromna różnorodność grup docelowych INŻYNIERII WYMAGAŃ jest tym, co różni inżynierię wymagań od innych dziedzin inżynierii oprogramowania. Wymagania, to swego rodzaju spoiwo, łączące w projekcie IT w jednorodną całość działania osób, należących do różnych grup zawodowych [więcej].

[wpis na temat warsztatów 28-29 maja]

Poniżej opisujemy szczegółowo, jakie konkretne korzyści przyniesie osobom, należącym do różnych grup docelowych, wiedza na temat pozyskiwania i negocjowania wymagań.

Ponieważ inżynieria wymagań służy tak wielu różnym grupom zawodowym, podstawowa wiedza, potrzebna wszystkim, określona jest przez system certyfikacji IREB CPRE (Certified Professional in Requirements Engineering). Ten certyfikat uzyskało już ponad 15.000 osób na świecie.

Projekt IT to przedsięwzięcie, mające na celu osiągnięcie, zrealizowanie jakiejś potrzeby biznesowej, celu, marzenia, przy pomocy nowego, lub zmodyfikowanego, systemu informatycznego.

Podstawą całego projektu jest więc poprawne, dokładne, ale zarazem elastyczne zdefiniowanie jego celu i założeń: inżynieria wymagań = stworzenie dobrej specyfikacji wymagań. Ten proces, kluczowy dla powodzenia projektów IT, jest jednak często niedoceniany i przez to źle realizowany, skutkiem czego cierpią inne, lepiej znane i rozpoznawalne obszary, celebryci projektów IT: zarządzanie, projektowanie, programowanie (zwłaszcza metodyki agile), wdrożenie, sprzedaż, i testowanie.

DLA LUDZI AGILE

Zapraszamy zwolenników metod zwinnych (agile), bowiem - wbrew pozorom - podejście agile nie oznacza rezygnacji z wymagań oraz inżynierii wymagań, lecz wręcz przeciwnie - polega na niezwykle intensywnym, interaktywnym zdobywaniu (pozyskiwaniu) wymagań w bliskiej współpracy z klientem.

W szczególności, możliwość zastosowania z powodzeniem metod zwinnych nie tylko w małych, ale również w dużych projektach, zależy od dobrych praktyk inżynierii wymagań (czyli, mówiąc językiem Agile Scrum, od dobrego rejestru wymagań produktu - product backlog - i skutecznego zarządzania podziałem go na rejestry przebiegów - sprint backlog). 

Korzyści dla uczestników Scrum Team, Scrum Master'ów, Product Owner'ów:
Głównym zadaniem Product Owner'a jest tworzenie, zarządzanie i priorytetyzacja wymagań wchodzących w skład rejestru wymagań produktu (product backlog), oraz - wspólnie ze Scrum Master'em - jego podział na wymagania dla przebiegów (sprint backlog). To są w 100% zadania z zakresu inżynierii wymagań; dzięki uczestniczeniu w warsztatach Product Owner będzie je wykonywał lepiej i sprawniej.

Uczestnicząc w warsztatach, Scrum Masterzy oraz uczestnicy zespołów Scrum zdobędą lepszą wiedzę - do praktycznego zastosowania natychmiast - jak szacować pracochłonność realizacji wymagań, jakie są inne sposoby, oprócz user stories, specyfikacji wymagań, jak sobie radzić z wymaganiami niefunkcjonalnymi.
Wszyscy uczestnicy projektów prowadzonych metodą Agile Scrum dostaną cenne informacje, jak pogodzić tę metodykę z realiami zarządzania w dużych firmach i projektach (więcej na ten temat tutaj).

DLA ANALITYKÓW - INŻYNIERÓW WYMAGAŃ

Zapraszamy specjalistów inżynierii wymagań, czyli osoby często noszące tytuły analityków, analityków biznesowych, analityków systemowych, lub specjalistów modelowania biznesowego.

Pamiętajmy, że popularna nazwa "analiza biznesowa" stosowana jest głównie w przemyśle IT, podczas gdy określenie "inżynieria wymagań" jest bardziej rozpowszechnione i rozpoznawalne w świecie akademickim.

Korzyści dla analityków / inżynierów wymagań:

Inżynieria wymagań jest w istocie kluczowa dla powodzenia projektów IT, ale jest wciąż dramatycznie niedoceniana. Z reguły, realizuje się ją ad hoc, niefachowo, albo wrzuca do jednego worka z zarządzaniem projektami, albo wreszcie ogranicza do obszaru wymagań wysokopoziomowych, czego symptomem jest przewaga popularności nazwy "analiza biznesowa" nad nazwą "inżynieria wymagań".

Przy okazji: zapraszam do Stowarzyszenia Inżynierii Wymagań:

DLA WŁAŚCICIELI I DYREKTORÓW FIRM

Zapraszamy właścicieli firm, dyrektorów i specjalistów sprzedaży. Tak naprawdę, choć prawda ta bardzo powoli toruje sobie drogę do naszej świadomości, inżynieria wymagań ma także zaskakująco wiele punktów stycznych ze sprzedażą i z marketingiem: wszystkie trzy mają za zadanie wykrycie, analizę i zdefiniowanie potrzeb klientów. Uwaga: zaproszenie dotyczy właścicieli firm i dyrektorów naczelnych zarówno po stronie dostawców, jak i firm zamawiających oprogramowanie: banków, sklepów internetowych, fabryk robiących buty, samochody i telefony, biur podróży...



Próba określenia, w jaki sposób to właśnie system IT, a nie inne działania (może kampania reklamowa? może zastosowanie nowych technik sprzedaży? może wdrożenie franczyzy?) ma ulepszyć biznes, wymaga starannego doprecyzowania celów biznesowych przedsięwzięcia, czemu służy inżynieria wymagań.

Inżynieria wymagań, mimo swej technicznie brzmiącej nazwy, to prawa ręka biznesu.

Korzyści dla właścicieli i dyrektorów zarządzających:

Przemysł IT, oraz wszystkie branże, które wykorzystują IT, czyli dzisiaj cała gospodarka, od lat cierpi na trudności z porozumieniem się między IT a biznesem. Te trudności są najpoważniejszą przyczyną niepowodzeń, opóźnień oraz realizacji systemów IT, które nie przynoszą oczekiwanych, biznesowych korzyści.

Mimo fantastycznego rozwoju technologii informatycznych, umiejętność porozumienia się tkwi w tym samym punkcie, gdzie tkwiła 60 lat temu.

DLA ARCHITEKTÓW

Zapraszamy projektantów i specjalistów architektury oprogramowania, osoby uprawiające BDD (Behavior-driven development), a więc także i TDD (Test-driven development), bowiem, aby Wasze wysiłki nie poszły na marne, konieczne jest ich zsynchronizowanie w płynnie działającą całość.

W terminologii inżynierii wymagań interesariusze (udziałowcy) projektów, to osoby w różny sposób zainteresowane wynikami projektu. Ich interesy nie zawsze są zbieżne, niekiedy są wręcz przeciwstawne, co powoduje problemy.

Inżynieria wymagań zna metody (zwane negocjowaniem albo konsolidacją wymagań), zapewniające spójność sprzecznych często potrzeb biznesu, użytkowników końcowych oraz administratorów systemów; dzięki nim metody zwinne, w tym BDD oraz TDD, mają pełne szanse na sukces.

Korzyści dla architektów:

Dobra architektura jest warunkiem łatwości utrzymania. Od niej przede wszystkim zależy całkowity koszt produktu informatycznego. Aby zaprojektować dobrą architekturę, trzeba przede wszystkim znać cele biznesowe oraz funkcje tworzonego oprogramowania. Ta wiedza, niezbędna architektom, jest produktem inżynierii wymagań.

DLA PROGRAMISTÓW

Zapraszamy programistów, zwłaszcza stosujących języki obiektowe. Często - zbyt często - zdarza się przecież, że Wasze najlepsze wysiłki idą częściowo na marne, bowiem okazuje się, że klient chciał coś zupełnie innego, niż wywnioskowaliście z niepełnej i niejednoznacznej specyfikacji. Równie często zdarza się, że musicie wykłócać się z testerami, czy dane działanie programu jest poprawne, czy nie, co marnuje czas i nerwy. Wreszcie, jakże często w miesiąc po wdrożeniu wychodzi na jaw, że niedostateczna jest na przykład wydajność oprogramowania, o której nikt w ogóle nie wspominał wcześniej, albo pojawia się nagła konieczność przeniesienia systemu na nową platformę, i z głowy macie plany urlopowe. Czy to wyłącznie Wasza wina? Nie, to skutek niedostatecznej inżynierii wymagań.


Korzyści dla programistów:

Jak wioślarz musi znać nie tylko budowę swojej łodzi, ale także cechy akwenu, po którym pływa, tak programista musi znać nie tylko składnię swojego języka programowania, ale również warunki panujące w projektach IT.

To, co najbardziej przeszkadza programistom w tworzeniu dobrego, budzącego zadowolenie użytkowników kodu, to niejasne i zmieniające się wymagania.

Programiści - uczestnicy warsztatów - dowiedzą się, że inżynieria wymagań to nie tylko biznesowe ogólniki, lecz także - a nawet przede wszystkim - narzędzia, umożliwiające tworzenie dobrego kodu, z którego użytkownicy będą zadowoleni, oraz unikanie wiecznych poprawek i przeróbek.

DLA TESTERÓW

Szczególnie gorąco zapraszamy testerów, analityków testowych i kierowników testów! Kto, jeśli nie Wy, cierpi szczególnie dotkliwie, kiedy wymagania są niejasne, niepełne, nieaktualne, błędne i zmienne! Kto, jak nie Wy, w rzeczywistości wykonuje 90% pracy inżynierii wymagań, domyślając się, jak system ma działać (w szczególności, modne jest nazywać tę czynność testowaniem eksploracyjnym), doprecyzowując założenia, a wreszcie zawzięcie ścigając zwinną, wciąż umykającą chimerę ostatecznej, aktualnej wersji?

W praktyce, niemal każdy w Waszych problemów i prawie każde ze stojących przed Wami wyzwań wynika z braków inżynierii wymagań. Parafrazując słowa wiersza "Ach, kiedyż wykujem, strudzeni oracze, lemiesze z pałaszy skrwawionych" - kiedy wreszcie testerzy będą mogli testować, a nie zajmować się gaszeniem pożarów wybuchających w przeddzień wdrożenia wszędzie tam, gdzie ostrożności nie zachowali inni?

Autentyczny cytat z ogłoszenia o pracę (czerwiec 2013): "[Expected to] work with internal and external stakeholders to clarify requirements".
Korzyści dla testerów:

Testowanie, podobnie jak inżynieria wymagań będące przez dziesięciolecia Kopciuszkiem informatyki, wybiło się w ciągu ostatnich 10 lat na dziedzinę docenianą i znaczącą. Tyle, że stało się to kosztem wzięcia siebie obowiązków, które z testowaniem mają mało wspólnego: przede wszystkim poszukiwania, opisywania, a wręcz domyślania się wymagań!

Dla testerów, korzyści z udziału w są ogromne: będą mogli poznać zasady, jak zadbać o to, aby wymagania dawały się przetestować, jak je wykorzystywać do projektowania testów, i jak sobie radzić, kiedy wymagania są niedostateczne, czy wręcz brakuje ich zupełnie.

DLA PRAWNIKÓW I SPECJALISTÓW PRAWA ZAMÓWIEŃ PUBLICZNYCH

Zakończenie - oby szczęśliwe - projektu, to testy akceptacyjne, zadowoleni użytkownicy, podpisany protokół odbioru, wystawiona faktura, a po zapłacie - obustronna nadzieja na dalszą, skuteczną i wzajemnie korzystną współpracę. Jeśli tak się nie dzieje - co czasem zdarza się, prawda? - to u źródeł tego problemu tkwią, oczywiście, niedostatki inżynierii wymagań.

Dobrze, profesjonalnie zbudowania specyfikacja wymagań powinna być koniecznym uzupełnieniem, załącznikiem do kontraktu, ale... prawie nigdy tak nie jest. Mówiąc skrótowo, prawnicy nie słyszeli nigdy o inżynierii wymagań, a informatycy słabo znają się na prawie cywilnym; stąd nieporozumienia i kontrakty, w których dostawcy jako kryterium sukcesu projektu usiłują wpisać "system będzie w zasadzie działać", a prawnicy ze strony odbiorcy bronią się słowami "wtedy w zasadzie zapłacimy". Więc zapraszamy do nas prawników, specjalizujących się w brany IT.

W szczególności, zwracamy się do wszystkich instytucji, których dotyczy prawo zamówień publicznych, oraz do firm, które realizują dla nich systemy IT. Określone przez to prawo warunki przetargów oznaczają, że SIWZ - Specyfikacja Istotnych Warunków Zamówienia - to w istocie typowa specyfikacja wymagań. Jej formę określają szczegółowe regulacje prawne, z których dla nas najważniejsza jest ta, że po rozstrzygnięciu przetargu SIWZ nie może już ulegać zmianie. Z punktu widzenia zarówno dostawców, jak i ogłaszających przetarg instytucji jest to wielkie wyzwanie, z którym tylko inżynieria wymagań pozwala sobie skutecznie radzić.

Korzyści dla prawników i specjalistów zamówień publicznych:

Prawnicy oraz informatycy posługują się najzupełniej różnymi językami, choć często mówią o tym samym. Przykładowo, kryteria odbioru produktu, które prawnik wpisuje do kontraktu, to w istocie wysokopoziomowa specyfikacja wymagań. Poprawne skonstruowanie łańcucha: warunki kontraktu - wymagania - testy akceptacyjne, pozwoli uniknąć wielu kłopotów i sporów.

Prawnicy i specjaliści zamówień publicznych poznają sposoby, jak mogą unikać wielu chronicznych w ich pracy problemów, nauczywszy się lepiej rozumieć informatyków oraz zasady inżynierii wymagań.

DLA KIEROWNIKÓW PROJEKTÓW

Kto zajmuje się inżynierią wymagań, kiedy jej pozornie "nie ma"? Piszemy "pozornie", bo gdyby jej nie było naprawdę, to żaden, dosłownie żaden projekt na świecie nie skończył by się nawet w przybliżeniu osiągnięciem celu... bo cel byłby nieznany. Oczywiście, robi to po trosze biznes, który zwykle nieźle zna swoje cele, choć niechętnie precyzuje je wobec działów IT; dalej programiści, testerzy, ale przede wszystkim kierownicy projektów, odpowiedzialni wszak za osiągnięcie celu w terminie i za określone pieniądze. Cel określają wymagania (produktowe), termin i pieniądze - także wymagania (projektowe), więc jeśli projekt nie ma wymagań, to znaczy, że tworzą się one i są przechowywane w głowach kierowników projektów. Zresztą, tego właśnie uczą Was, drodzy PM-owie (kierownicy), popularne szkolenia PRINCE2 czy PMI.


Można wręcz powiedzieć, że standard PRINCE2 to standard inżynierii wymagań ("Projekt to organizacja powołana na pewien czas w celu wytworzenia - w przyjętym czasie oraz przy wykorzystaniu uprzednio określonych zasobów - niepowtarzalnych, a wcześniej określonych wyników czy rezultatu"). Z tym, że PRINCE2 koncentruje się na sposobach realizacji wymagań, a nie na samych wymaganiach.

Korzyści dla kierowników projektów:

Tam, gdzie brak analityka / inżyniera wymagań, kierownik projektu automatycznie staje się de facto inżynierem wymagań, odpowiedzialnym za sformułowanie celów przedsięwzięcia.

wtorek, 20 maja 2014

Ekonomika zapewnienia jakości na Forum Jakości Computerworld 13 czerwca 2014

Podczas Forum Jakości Computerworld 13 czerwca 2014, odbędzie się mój wykład na temat ekonomiki zapewnienia jakości (w programie konferencji).

Dokładniejszy opis tematyki jest wcześniej na tym blogu.

Zapraszam.

Zarządzanie projektami na podstawie ryzyka - prezentacja PMI Kraków 10 czerwca 2014

Zarządzanie projektami na podstawie ryzyka w wytwarzaniu sekwencyjnym oraz w iteracyjnym

Seminarium PMI Kraków: http://pmi.org.pl/index.php/aktualnosci-krakow (dzisiaj 20 maja informacji jeszcze nie ma na stronie, pojawi się wkrótce)
A) Wybór metody projektowej na podstawie ryzyka

Decyzja: metodyka sekwencyjna (kaskadową, model V) czy iteracyjna (np. agile, lean, lub inną) nie powinna być kwestią wiary ani ideologii, lecz świadomego wyboru jednej z dwóch strategii radzenia sobie z ryzykiem.
  • Jeśli wiemy, że:
    • wymagania są dobrze znane z góry,
    • dysponujemy czasem na ich staranną analizę i opis,
    • produkt słabo poddaje się podziałowi na stanowiące korzyść biznesową, osobne funkcjonalne kawałki,
    • prawdopodobieństwo zmian w trakcie projektu jest niewielkie,
wtedy lepsza jest metoda sekwencyjna, jako bardziej przewidywalna i prowadząca prostszą drogą do celu.
  • Jeśli natomiast:
    • wymagania są nieprecyzyjne,
    • sytuacja rynkowa nie pozwala na czasochłonne definiowanie i analizowanie,
    • produkt można wdrażać stopniowo, etapami,
    • prawdopodobieństwo zmian jest duże,
wówczas lepsza jest metoda iteracyjna, mniej narażona na to, że stworzy się niewłaściwy system i na to, że będzie się budować wymagania zamiast kodu.

Przedstawię macierz zmiennych, które należy uwzględnić przy podejmowaniu tej decyzji.
B) Realizacja projektu na podstawie ryzyka
Zarówno w PMBOK, jak i w PRINCE 2, zarządzanie ryzykiem jest jedną z czynności podejmowanych w projektach, równoległą do głównych przebiegów, takich jak określenie celów, planowanie, realizacja, wdrożenie (niezależnie od terminologii). Podobnie jest zresztą w rozbudowanych modelach iteracyjnych, np. w RUP. Metody zwinne (lean, agile) realizują zarządzanie ryzykiem głównie poprzez swój iteracyjny i przyrostowy charakter: prawdopodobieństwo ryzyk maleje w kolejnych iteracjach, a wytwarzanie przyrostowe ogranicza konsekwencje błędnych wyborów.
Ciekawe możliwości daje odwrócenie tego tradycyjnego podejścia i taktowanie ryzyka oraz sposobów radzenia sobie z nim jako głównego mechanizmu planowania i realizacji projektu. Jest to możliwe niezależnie od tego, czy wybrano model sekwencyjny, czy iteracyjny, oraz nie wymaga tworzenia nowego procesu, a jedynie wykorzystanie stosowanego dotąd procesu - w inny sposób. Robi się to w modelu sekwencyjnym, przypisując wymaganiom ryzyko, a w modelach iteracyjnych, wykorzystując (odwróconą) miarę korzyści biznesowej jako konsekwencji ryzyka, natomiast miarę wymagań niezawodności jako miarę akceptowanego poziomu prawdopodobieństwa.
Przedstawię diagramy ilustrujące te możliwości w praktyce.

poniedziałek, 19 maja 2014

Zwinny przewodnik po świecie agile :-)

Pojawi się wkrótce (lipiec - sierpień) w: http://fabrykawiedzy.com/

Oto jego spis treści:

Praktyczne korzyści metod zwinnych   
  • Metoda prób i błędów – lekarstwo na niepewność  
  • Co dzisiaj warto wiedzieć o historii metod iteracyjnych i przyrostowych?  
  • Dalszy rozwój metod zwinnych - post-agilism: możliwości i zagrożenia  
  • Meta-metoda: który proces wybrać?  
  • Jak unikać szkodliwych nieporozumień na temat agile?  
  • Jak korzystać z tej książki?  
Jak zwinnie realizować drogę od potrzeby biznesowej do jej zaspokojenia?
  • Etapy życia produktu: projekt, wdrożenie, utrzymanie   
  • Czy klienci potrzebują dobrych produktów?   
  • Kiedy jakość jest za darmo?   
  • Modele cyklu życia oprogramowania: kaskady, V, spirale i żelki   
  • Ciągła integracja i częste dostawy   
Nie bój się zmian! Zwinna inżynieria wymagań
  • Agile na ratunek inżynierii wymagań   
  • Jak i po co określać wymagania?   
  • Czy warto opisywać wymagania?   
  • To nudne zatwierdzanie   
  • Weryfikacja, walidacja, negocjowanie i konsolidacja wymagań w agile   
  • Mężczyzna zmiennym jest – jak zarządzać śliskimi wymaganiami   
Planowanie i nadzorowanie w agile scrum
  • Wady i zalety planowania pracy   
  • Jak dobrze planować nie za dużo i nie za mało, a w sam raz   
  • Przegląd sposobów szacowania pracochłonności   
  • Planowanie agile: pracochłonność, wydajność zespołu, ryzyko   
  • Przegląd metodyk monitorowania i nadzorowania w projektach   
  • Karta przyrostu i jej wykorzystanie   
Testowanie w ramach agile    
  • Testowanie, jako jedna z form zapewnienia jakości   
  • Cele, rodzaje i poziomy testów według kwadrantów testowych agile   
  • Projektowanie testów   
  • Jak agile radzi sobie z tradycyjnymi trudności testowania?   
  • Testy a wymagania w agile   
  • Automatyzacja testów w metodykach przyrostowych i w agile   
  • Testy jednostkowe   
  • Metodyka TDD   
  • Testy akceptacyjne a kryteria ukończenia   
  • ATDD – wyższa szkoła jazdy automatyzacji testów   
Zwinny programista  
  • Role programisty w zespołach agile   
  • Współpraca programisty z innymi uczestnikami zespołu   
  • Korzyści i niebezpieczeństwa bycia zwinnym dla programisty   
Jak być agile i przetrwać? 
  • Zespół samoorganizujący się: wolność i odpowiedzialność   
  • Społeczne i psychologiczne aspekty pracy zwinnej   
  • Role i funkcje – od programisty do coach’a   
  • Znaczenie rytuałów i terminologii agile   
Integracja wielu zespołów agile   
  • Synchronizacja i scalanie produktów kolejnych sprintów   
  • Super-agile: scalanie produktów sprintów równoległych   
  • Sprinty, wersjonowanie, zarządzanie zmianami i synchronizacja dostaw do klienta   
Agile w kaskadowym świecie   
  • Jak zintegrować realizację agile z wymaganiami dużej organizacji?   
  • Projekty agile a zarządzanie portfelem produktów   
  • Umowy wdrożeniowe a agile – aspekty prawne   
  • Agile z punktu widzenia prawa o zamówieniach publicznych   
  • Agile dla systemów wbudowanych i krytycznych dla bezpieczeństwa   
  • Agile poza IT   
Metody treningu – jak stać się zwinnym?   
  • Udoskonalanie procesu agile   
  • Tradycyjne standardy dojrzałości procesów, czy one są zwinne?   
  • Jak z tradycyjnego stać się zwinnym?   
  • Jak rozpocząć karierę od udziału w projekcie zwinnym?   
  • Certyfikacje dla zwinnych   
  • Agile po pięćdziesiątce?   
Agile a kariera    
  • Ścieżki kariery dla uczestników agile   
Źródła   


niedziela, 18 maja 2014

Modne bzdury kontratakują!

Modne bzdury kontratakują!
(http://blog.testowka.pl/2014/02/26/komentarz-do-blad-arystotelesa-w-it/)

[Na marginesie: projekty agile prowadziłem wielokrotnie, szkolenia agile od kilku lat, w tym ponad rok w Szwecji. Wkrótce opublikuję w http://fabrykawiedzy.com/ książkę pt. "Zwinny przewodnik po świecie agile". Ale tym bardziej rażą mnie modne bzdury na temat agile ;-)]

http://blog.testowka.pl/2014/02/26/komentarz-do-blad-arystotelesa-w-it/:
W ostatnim wydaniu Computerworld pojawił się artykuł autorstwa Bogdana Berezy zatytułowany "Błąd Arystotelesa w IT", który wręcz domagał się komentarza. Nie chodzi tyle o jakieś rażące błędy merytoryczne ale raczej o niedomówienia i drobne naginanie faktów, które troszeczkę zaciemniają prawdziwy obraz. Komentarz jednak trochę urósł więc zrobiła się z tego też notka na blogu - poniżej... zapraszam do dyskusji
 
"Rażące błędy merytoryczne" - nie, nie ma ich... ale ich sugerowanie (są nie-rażące?) jest niestety ostrym naginaniem faktów :-(

Wygląda na to, że autor pisząc o testowaniu w Agile jako o czymś co jest w 85% takie samo jak „zwykłe” testowanie chyba nie do końca zdaje sobie sprawę z tego czym faktycznie testowanie w Agile różni się od testowania w procesach „tradycyjnych”.

Autor chyba sobie zdaje sprawę, bo doskonale to zagadnienie zna, z praktyki i z teorii. Autor komentarza nie zadaje sobie natomiast trudu, żeby swoje twierdzenia, że jest inaczej, uzasadnić :-(

Pamiętam jak kilka dobrych lat temu zmieniłem pracę przenosząc się z organizacji pracującej wg tzw. Modelu Kaskadowego opatrzonego normami ISO i certyfikatami CMMI do prawdziwie zwinnego zespołu pracującego w Scrum… Różnica była zasadnicza!


Tak, "zasadnicza różnica" jest także, kiedy zmienia się kraj, branżę, język, firmę oraz proces wg jednego wzorca na inny wzorzec. Ale to nie jest żadna "zasadnicza różnica" w testowaniu, no chyba że ktoś ma tak małe i wąskie doświadczenie, że mu jakakolwiek zmiana wydaje się ogromna, bo brakuje mu ram odniesienia. MIAŁEŚ WRAŻENIE RÓŻNICY, to możliwe, ale jej tak naprawdę nie było. Ot, inna stylistyka.


Oczywiście zgadzam się, że samo testowanie to testowanie i nie różni się niczym w obydwu podejściach… Smutny jest fakt, że wielu „testerów” w tym obszarze ma nadal poważne, podstawowe braki dotyczące technik testowania i projektowania testów, pomimo nawet uczestnictwa w wielu certyfikowanych szkoleniach, które częściej bardziej uczą jak zdać egzamin, niż jak faktycznie coś dobrze przetestować (oczywiście zdarzają się wyjątki)...

No właśnie - NIE RÓŻNI SIĘ :-)

Wracając do różnic pomiędzy Agile a nie-Agile… Już na przykład: rola testera, jego miejsce w zespole i organizacji, wartość i sposoby komunikacji, zasadnicza przewaga bezpośredniej współpracy wewnątrz zespołu wskroś-funkcjonalnego ponad przerzucanie się zgłoszeniami bugów pomiędzy działem testów i działem programowania, częstotliwość testowania, feedback dla programistów, proporcje pomiędzy testami regresyjnymi a testami akceptacyjnymi zupełnie nowych funkcjonalności, rola automatyzacji testów i jej wsparcie w procesie testowym i procesie zapewniania jakości oprogramowania, ciągła integracja i ciągłość testowania to tylko niektóre z różnic, o który autor zdaje się zapominać…
 
Tak, to takie trala-lalala, które osoby propagujące rzekomą nadzwyczajną odmienność agile, chętnie nagłaśniają. Inna duchowość, przyjaźń między ludźmi, bara-bara. Oczywiście, są jakieś systematyczne różnice między testowaniem w agile i nie-agile, ale znacznie mniejsze, niż między złymi i dobrymi projektami, między testowaniem systemów bezpiecznych a takich, gdzie niezawodność jest mniej istotna, itd. WSZYSTKIE te zjawiska, które autor komentarza wymienia jako rzekomo specjalne w agile, występują też często poza agile.

Jest tego trochę więcej niż by mogło się, a przynajmniej na tyle więcej że potrafimy nad tym pracować przez ponad 80% czasu na naszych warsztatach z Testowania w Agile na które serdecznie autora zapraszam.


Na warsztatach - wierzę, w końcu autorom warsztatów ta bardzo opłaca się udawać, że uczą czegoś niezwykłego i wartościowego, aż w końcu sami w to wierzą. W rzeczywistości, nie na "warsztatach"- jest inaczej. Te 80% zresztą po prostu uczycie testowania, udając, że jest to jakieś specjalne "testowanie agile" (bo trochę więcej regresji itp).

Wobec tego - zapraszam na moje warsztaty, tam tę fikcję wyjaśniam dokładniej. I do moich innych artykułów, licznych.

Agile nie jest już żadną nowością – 13 lat praktyki od Manifestu Agile popartych wieloma sukcesami to przy obecnym tempie naszego życia i rozwoju chyba już całkiem sporo. A początków Agile można się doszukiwać w okolicach 1991 roku, a jak twierdzą niektórzy (np. Tom Gilb) jeszcze jakieś 20 lat wcześniej…

Dokładnie - AGILE NIE JEST ŻADNĄ NOWOŚCIĄ. Tom Gilb niczego nie "twierdzi", tylko po prostu metodykę podobną na 90% do agile stosował od 1970 roku. Opublikowałem z nim o tym wywiad ;-)

Co do samej terminologii stosowanej w Agile to… „Jeśli chcesz coś zmienić to musisz coś zmienić” – terminologia i używany język są dobrym punktem startu. Ma to głębokie uzasadnienie zwłaszcza, gdy potrzebujemy zmienić istniejącą organizację.

Żal tego słuchać - zbędne zmienianie nazw świadczy dobitnie o braku zmian istotnych, które trzeba symulować. Taki bolszewizm. Ale tę zmianę nazw można agile akurat wybaczyć, bo służy dobrej sprawie, czyli autentycznie świetnym metodom agile.

Podsumowując – nie rozumiem co autor miał na myśli krytykując realnie działające (przynajmniej na podstawie moich kilkuletnich doświadczeń) metody jakoby były one zupełnie nienaukowymi „modnymi bzdurami”. 


Toś Kolego niewiele z mojego artykułu zrozumiał... Przecież oczywiście NIE krytykuję tam agile, bo uważam (co tam piszę), że autentyczne agile jest świetną metodą. To chyba w artykule jest jasne:
  
Żeby było jasne – jestem gorącym zwolennikiem paradygmatu (zrębu – ang. framework) agile, zwłaszcza agile Scrum. Ten sposób realizowania projektów jako pierwszy i jedyny dotąd na świecie zdołał – przynajmniej częściowo – zlikwidować szereg chronicznych od lat słabości projektów IT [...]

Krytykuję, a raczej ostrzegam przez BEZMYŚLNĄ MODĄ NA AGILE, bez zrozumienia, co naprawdę jest w agile dobre, fascynowanie się jego rzekomymi odmiennościami, zamiast istotnych zalet. Tak, jak w cytowanym tekście "Błąd Arystotelesa" jego autor też nie krytykuje np. języków obiektowych, tylko bezmyślną modę na nazwę "obiektowy", która znaczyła cokolwiek.


Tym bardziej, że metody te również mają podstawy w nauce – może bardziej w psychologii i naukach humanistycznych niż inżynierii ale jednak…


Jak się już do "naukowych nauk humanistycznych" musisz odwoływać, to uprawiasz kult cargo na całego :-) ale agile PO PROSTU jest dobrą metodą, co nie czyni jednak z niej metody zupełnie innej, niesamowitej, humanistycznej - takie tezy to są właśnie modne bzdury.

Przypominam, że „Waterfall” również kiedyś był modną bzdurą, która z siłą wodospadu miała popychać projekty IT do przodu.

No, brawo! O tym właśnie piszę - o tym, że metody różne, dobre w PEWNYM ZAKRESIE, stają się niestety, i dawniej, i dzisiaj, formą kultu, bez zrozumienia, co w nich naprawdę jest dobre, i dlaczego. Ofiarą takiego kultu pada agile - często. Nie zawsze.

Zmieniła się jednak rzeczywistość i mechanizmy współczesnego wytwarzania oprogramowania przez co dawne metody przestały działać.

Zupełna bzdura. Metody sekwencyjne (np. kaskada i wiele innych) i iteracyjne (np. agile i wiele innych) pasuję - niezależnie od epoki - do RÓŻNYCH RODZAJÓW PROJEKTÓW. Bezmyślne stosowanie kaskady tam, gdzie jest nie na miejscu, jest równie niemądre, jak bezsensowne stosowanie agile, tam gdzie ono nie pasuje.

Już widać, że Scrum powoli przestaje być wystarczający na współczesnym rynku, a wydania raz na dwa tygodnie wywołują uśmiech na twarzach praktyków Continuous Delivery pracujących w organizacjach tworzących produkty według zasad Lean Startup

O, to doskonałe przykłady MODNYCH BZDUR. Autor tych powyższych słów nawet, zdaje się nie słyszał o "daily build" (początek lat 90-ych), ani XP (ten sam okres), ani "cleanroom software engineering"), bo mu WIARA w wielkość i nadzwyczajność agile wystarcza? Wydania kilka razy na dzień nie są więc żadną nowością, lecz ("daily build"!) ćwierćwieczną staruszką. Oto do czego prowadzi bezmyślny kut wszelkiej nowości. Jeśli "wydania raz na dwa tygodnie wywołują uśmiech", to jest typowy przykład "agile jako śmieszna moda", bo nie jest zaletą mieć wydania jak najczęściej, tylko tak często, jak trzeba. Amen. Uczcie się ludzie, i nie ulegajcie histerii mody i rzekomych pseudo-nowości.

(gdzie nikt nie wspomina nawet o rzeczach z ich perspektywy tak archaicznych jak inżynieria wymagań

No, to trzeba być niemądrym do kwadratu, żeby nie zdawać sobie sprawy, że inżynieria wymagań po prostu JEST, jak tlen, nawet (zwłaszcza!), gdy jej nie widać. Siłą agile jest właśnie bardzo dobra i zdyscyplinowana inżynieria wymagań, której najlepsze zasady przemyca się pod pseudo-nowoczesną terminologią (żeby nie straszyć młodych gniewnych). Jeśli ktoś uważa, że inżynieria wymagań jest archaiczna czy zbędna, to nawet nie wie, jak sam pracuje, i myśli, że inżynierii wymagań nie uprawia, bo jest "zwinny" i inaczej jej artefakty ponazywał.

Taka moda na niby-nowoczesność jest znana od wieków, archaiczna i przed nią w moim artykule przestrzegam. Jak widać, słusznie :-(

Ciągła inżynieria wymagań

Nowość na moim angielskim blogu: "Continuous Requirements Engineering"

Pop-psychologia 2 (2)



Szkolenia z psychologii biznesu bywają trudne do prowadzenia – wcale nie z powodów merytorycznych. Kłopot polega na tym, że ich uczestnicy często tak naprawdę nie szukają ani wiedzy, ani rzeczywistych umiejętności, lecz wyłącznie szybkich, łatwych, wygodnych i bezbolesnych pseudo-rozwiązań dla skomplikowanych kłopotów. Co gorsza, te rozwiązania zwykle dotyczą spraw, z którymi nauka zwana psychologią nie ma nic wspólnego! Na przykład osoby z organizacji, której rozpaczliwie potrzeba sensownych procedur decyzyjnych, albo sprawnego przepływu dokumentów oraz informacji, albo poprawy zupełnie toksycznych relacji między pracownikami, oczekują pomocy swoich problemów ze strony… psychologii. Takie oczekiwanie jest złudzeniem, ale na próżno tłumaczyć to uczestnikom, którzy z tymi fałszywymi i nierealnymi oczekiwaniami pojawili się na szkoleniu. Zamiast stawić czoła prawdziwym problemom, znacznie łatwiej szukać cudownego leku w niby-psychologicznym hokus-pokus.

Skąd bierze się to złudzenie? Otóż wprawdzie psychologia, jako nauka jest większości ludzi nieznaną, ale jako „psychologię” traktuje się rozmaite popularne, modne i hałaśliwe pseudonauki. Te pseudonauki i niby-psychologiczne metody oferują łatwe, wygodne, atrakcyjnie opakowane i pozornie skuteczne rozwiązania; takie, które zapewniają uczestnikom szkoleń dobre samopoczucie, choć naprawdę mają zerową lub minimalną skuteczność.

Najczęściej, oczekiwania uczestników dotyczą umiejętności manipulowania ludźmi. Przykładowo, z tego właśnie powodu w tak zwanej „psychologii biznesu” dużą estymą cieszą się metody spod znaku NLP. Wprawdzie nie ma żadnego naukowego potwierdzenia ich skuteczności, dodatkowo są one nieetyczne, ale co to szkodzi, skoro wygadani trenerzy NLP gwarantują uczestnikom poczucie, że czegoś się nauczyli, że odtąd będą mogli skłonić swoich współpracowników do posłuszeństwa i spełniania poleceń!

Prawda jest prosta i rozczarowująca w porównaniu z bajkowym światem pseudo-psychologii: prawdziwa psychologia nie dostarcza cudownych lekarstw, nie gwarantuje szczęścia, nie daje żadnych prostych recept na złożone problemy. Tak samo jak, na przykład – geologia - nie jest czarodziejstwem, pozwalającym zatrzymywać trzęsienia ziemi czy wybuchy wulkanów, lecz pozwala tylko (czy może aż?) nieco lepiej je przewidywać, trafniej unikać miejsc, gdzie mogą się zdarzyć. Tak właśnie, jak w swojej książce, „Co możesz zmienić a czego nie możesz. Ucząc się akceptować siebie” opisuje to wybitny amerykański psycholog Martin Seligman – stąd tytuł tego akapitu.

Co ma w tej sytuacji robić dostawca szkoleń z psychologii biznesu? Iść za modą, Udawać, że spełnia nierealne oczekiwania uczestników, czy jednak podawać solidną, prawdziwą, rozczarowująco skomplikowaną i zupełnie pozbawioną magii, wiedzę psychologiczną?

Powiedzmy, że uczestnikiem szkolenia jest kierownik projektu, mający kłopoty z programistami, chronicznie niewykonującymi poleceń i niedotrzymującymi terminów. Naiwnie, spodziewa się, że szkolenie „psychologiczne” dostarczy mu proste, łatwe do zastosowania narzędzia, jak tę sytuację zmienić. Można dla jego radości omówić, na przykład: zasady wykorzystania empatii (wczucia się w prawdziwe potrzeby i dylematy kłopotliwych osób), albo, na odwrót, pokazać manipulacyjne sposoby wywierania wpływu, rodem z NLP. Czy poprzestać na pokazaniu jednej - dwóch takich prościutkich, więc zupełnie niewystarczających w praktyce, metod, dać uczestnikowi poczucie bezpieczeństwa, którego poszukuje, zgarnąć po szkoleniu dobre ankiety i mieć nadzieję, że bez stosowania metod grupy kontrolnej, statystyki i innych zasad naukowego badania, nikt nie wykryje, że pokazane metody są w nieskuteczna, że fałszują rzeczywistość nadmiernym upraszczaniem? Czy też opowiedzieć prawdę, pokazać metody złożone i skuteczne na długą metę, ale niespełniające oczekiwań cudownego psychologicznego hokus-pokus?

Wybieramy tę drugą drogę i zapraszamy na szkolenia rzetelne. Rozmaite metody z czarodziejskiego świata, gdzie można w sobie zbudzić olbrzyma, skutecznie uwodzić panie czy panów, albo zostać charyzmatycznym liderem, można znaleźć gdzie indziej.

Pop-psychologia 1 (2)

Rynek rozmaitych szkoleń, treningów i warsztatów, które obiecują uczestnikom poprawę ich życiowej i zawodowej kondycji metodami „psychologicznymi”, wart jest rocznie w Polsce kilkanaście miliardów złotych – to więcej, niż inwestycje R & D w całym sektorze IT. Na
pewno, są wśród nich nieliczne działania rzetelne, ale zdecydowana większość to – świadome lub nie – fałszerstwa, ponieważ obiecywanych wyników nie są w stanie dostarczyć. W Stanach Zjednoczonych, tej ojczyźnie naiwnej wiary, że każde marzenie można zrealizować, byle
mieć silną wolę i dobrego psychiatrę, te liczby są jeszcze bardziej spektakularne. „The Greatest Hoax on Earth” jest pewnie nie najgorszą nazwą dla tego fenomenu?

To zbiorowe oszukiwanie i samo-oszukiwanie zawdzięcza swe istnienie trzem wielkim złudzeniom.

1. Pierwsze, to nadużywanie słowa „psychologia” – pod tą nazwą, zawierającą przecież rdzeń słowny „logos” (nauka), znajdują schronienie metody, sztuki, pół-religie, szamanizmy i kulty cargo, nie mające żadnego naukowego potwierdzenia. Nie mam nic przeciwko czarom ani innym modnym bzdurom pod warunkiem, że nie będą kłamliwie oferować swoich usług pod płaszczykiem sugestii, że są jakąś formą nauki, choćby „alternatywnej”. Przez analogię: skoro ludzie łakną i są gotowi płacić na przykład za szmatławe tabloidy, facebooki i inne głupawe rozrywki, nie mnie im tego odmawiać, ale budzi mój sprzeciw, aby tę bełkotliwą, plotkarską papkę sprzedawano jako rzetelną informację.

2. Drugie złudzenie, to powszechna wiara, że technikami psychologii można, zmieniając siebie i innych, zmienić sytuację. Jak świetnie wiemy ze złowieszczych doświadczeń Ascha i Zimbardo, tak zwani zwykli ludzie, włożeni w dostatecznie koszmarną sytuację, bardzo szybko także zaczynają zachowywać się koszmarnie. Kierownik działu czy projektu w chorej, toksycznej, hierarchicznej organizacji, mający problemy z podwładnymi, którzy go oszukują, lekceważą czy okradają, nie jest w stanie tej sytuacji zmienić, choćby nawet rzeczywiście udoskonalił swoje zdolności przywódcze, negocjacyjne i nabył lepsze umiejętności wywierania wpływu. Do tej zmiany trzeba przede wszystkim zmienić kulturę organizacji, procedury – psychologia nie dysponuje żadnymi narzędziami, pozwalającymi jej unieważniać ani prawa socjologii, ani fizyki.

3. Trzecie złudzenie, to przecenianie możliwości osiągnięcia indywidualnych zmian poprzez pojedyncze, krótkotrwałe działania, takie jak udział w jakichś warsztatach. Szalbiercze pseudo-psychologie obiecują, że umożliwią nam uzyskanie dużych zmian małym kosztem. Rzetelna psychologia nie jest jednak nauką o tym, jak zmieniać ludzi czy siebie: terapie, nawet te nieliczne, których skuteczność potwierdzono naukowo, to tylko mała część psychologii – ani też o tym, jak wywierać wymarzony wpływ na innych. Osiągania takich niewykonalnych celów domagają się naiwni. Uczciwi psychologowie wiedzą, że jest to niemożliwe, natomiast liczni szarlatani obiecują wszystko, cokolwiek dobrze się sprzedaje.

To, co potocznie nazywane jest psychologią, nie ma wiele wspólnego z psychologią, jako nauką o mechanizmach psychiki ludzkiej. Na co dzień wszelkie działania, począwszy od twierdzenia, że ktoś jest głupi albo uparty, aż po szamańskie tańce, ustawienia Hellingera czy wróżenie z ręki, bywają nazywane „psychologią”.

Psychologia, jako nauka nie zaspokaja w pełni ludzkich potrzeb pociechy, znajdowania sensu, pomocy w radzeniu sobie z zawiłymi sytuacjami. To są jednak ogromnie silne potrzeby, więc nic dziwnego, że pojawiają się niezliczone metody, pociechę i poradę obiecujące. Ich marketing – oprócz podszywania się pod naukę – odwołuje się do prostych i skutecznych, od stuleci znanych zasad wmawiania nieprawdy: zamiast statystycznie istotnych danych, pokazuje się efektowne przypadki indywidualne, choćby zdarzały się jeden raz na sto. Wykorzystuje się też powszechne ludzkie przekonanie, że – porozmawiawszy sobie o problemie – rozwiązaliśmy go. Elokwentny trener, dominujący terapeuta – ludzie wychodzą od nich z poczuciem, że coś osiągnęli, czegoś się nauczyli. Tak działa fałszywka NLP, tak działają popularne szamanizmy Hellingera, tak działa delfinoterapia, tak działa „sześć kapeluszy de Bono” albo metody redukowania stresu muzyką, albo budowanie rzekomego ducha zespołowego meczem paintball’u. Nie działa, ale wierzymy, że działa; każdemu głupio się przyznać przed sobą i przed innymi, że zmarnował dwa dni na bzdury.

Co ma do zaoferowania prawdziwa psychologia? Nieatrakcyjnie brzmiącą, opartą na statystyce, wiedzę. Dopiero poznawszy trochę tej wiedzy, można zacząć próbować coś rozumieć i zmieniać. O ileż jednak przyjemniej po dwóch dniach warsztatu NLP wyjść z poczuciem, że oto posiadło się wyjaśnienie wszelkich zagadek!

Żeby było śmieszniej, czasem ludzie zainfekowani sztuczkami NLP czy innymi bzdurami rzeczywiście na czas jakiś stają się skuteczniejsi. Tak: jeśli szaman wmówi komuś, że po okadzeniu jest nieśmiertelny, też będzie czas jakiś skuteczniejszy w boju. Kulty cargo miewają moc sprawczą… do czasu.

Oto problem, o jakim opowiedział uczestnik podczas prowadzonego przeze mnie szkolenia: jeden z uczestników jego zespołu scrumowego chronicznie nie wypełniał na czas zadań, które na niego przypadały, bo miał zwyczaj realizować, zamiast nich, mnóstwo wrzutek, którymi obsypywało go kierownictwo firmy. Podobno, żadne zastosowane próby wpływu nie działały. OK, sytuacja typowa, nie tylko w agile: bałagan w firmie, nieprzestrzeganie procesu przez kierownictwo, chęć przypodobania się najwyższemu szefowi, jako motywator silniejszy niż lojalność wobec kolegów z projektu, wszystko to dobrze znamy z setek toksycznych, bałaganiarskich organizacji, przeżartych kulturą samców alfa i chorej rywalizacji.

Kłopot? Uczestnik oczekiwał, że podczas warsztatu pod nazwą „psychologia projektu informatycznego”, otrzyma prosty i superskuteczny sposób poradzenia sobie z tą sytuacją! Co gorsza, odnoszące się do sytuacji, omawiane tematy negocjacji, stylów zarządzania, kultury organizacyjnej, różnych sposobów motywowania osób o różnych profilach osobowości, nie interesowały tego uczestnika – on nie chciał zrozumieć, tylko dostać prostą i skuteczną receptę.

Psychologia nie osiągnęła jeszcze poziomu dojrzałości innych nauk, takich jak medycyna, chemia czy fizyka, które nie tylko opisują zjawiska, ale wyjaśniają także ich mechanizmy, co pozwala na wywieranie wpływu. Lekarz, znając mechanizmy choroby, potrafi dzięki temu ją leczyć. Psychologia jest pod tym względem tam, gdzie medycyna była w połowie XIX wieku: wyjaśniła już sporo mechanizmów, ale zbyt mało na razie, aby móc skutecznie pomagać wszędzie tam, gdzie byśmy chcieli.

Kiedy medycyna zaczęła szukać rozwiązań w obserwacji i eksperymencie, zamiast w pismach Arystotelesa, nauce kościołów czy w innych czarach, ruszyła szybko do przodu, zaczęła się dynamicznie rozwijać. Niestety, pod tym względem obecna psychologia tkwi głęboko w
średniowieczu: uczciwi i rzetelni psychologowie są zwalczani przez ciemnogród, szerzą się zabobony. Środki, które można by wykorzystać na naukowe badania, idą na marketing modnych bzdur. Dziś w medycynie też są takie zjawiska, dla przykładu homeopatia czy głośna sekta zwolenników fantastycznej tezy o tym, że szczepienia powodują autyzm, ale to jednak margines. W psychologii natomiast czary-mary takie jak wymieniany już NLP, kapelusze de Bono, porozumienia bez przemocy, cudowne i fantastyczne metody przywództwa, wywierania wpływu, i inne cudeńka zepchnęły prawdziwą psychologię na margines.

Nasze warsztaty psychologiczne nie idą tą drogą – zapraszamy na nie tych, którzy chcą poznawać prawdę, a nie modne bzdury (victo.eu/psychologia.html, http://dobrze.victo.eu/).