• Różne,  Zarządzanie,  Życie i inne refleksje

    Szczepionka 737MAX

    9 grudnia 2020 / Brak komentarzy

    Jest taki wpływowy artykuł zatytułowany „Software is eating the world”. Chodziło w nim o to, że software jest podstawą działalności właściwie wszystkich odnoszących sukcesy firm. I, że w związku z tym software i budowanie go staje się kluczowe i zarazem powszechne.

    Niestety, wraz z tym powszechne stały się także złe nawyki i praktyki IT, na przykład takie jak wydawanie niegotowych produktów, ukrywanie długu technologicznego czy wręcz testowanie produktów przez użytkowników. To nie było takie groźne, póki chodziło o edytory tekstu, gry czy sieci społecznościowe, ale staje się śmiertelnie niebezpieczne, kiedy przenosi się na inne branże.

    Pierwszym znanym przykładem był Boeing 737MAX wypchnięty „na chybcika”, z wieloma dysfunkcjami organizacyjnymi jakże znajomymi każdemu, kto kiedykolwiek „wypychał za bramę”, na „deadline” kolejną, poprawioną „na szybko” wersję starego systemu. W tym przypadku oznaczało to śmierć około 300 osób i prawie dwuletnie uziemienie samolotów skutkujące poważnymi kłopotami dla Boeinga. A także utratę zaufania do FAA – niegdyś „złotego standardu” wśród regulatorów lotniczych – kiedy okazało się, że FAA właściwie tylko przybijała pieczątki na tym, co Boeing sam „sprawdził”.

    Teraz widzimy podobne podejście – wypchnąć „za bramę”, zrobić testy „na chybcika”, sprawdzić to na milionach użytkowników – na szczepionkach. Z tym, że w przypadku Boeinga 737MAX chodziło o próbę ponownego reużycia starego projektu przez „doklejenie” do niego paru nowych, komputerowych dynksów. Tu zaś mamy wzorzec „nowe eksperymentalne, pospieszne testy na ścieżkach pozytywnych a resztę niech nam ludzie sprawdzą i wykryją błędy”. Coś, co znaliśmy kiedyś z wczesnych wersji Windowsów i co sprawdza się dziś w przypadku Microsoft Flight Simulator 2020 (piękny, nowa jakość w branży ale roi się od błędów), tu się oczywiście nie sprawdzi. W MFSF2020 katastrofy nie są prawdziwe, a sfrustrowani gracze bugi zaraportują po czym co najwyżej poczekają na kolejny „patch” grając w X-Plane. W przypadku szczepionek – zwłaszcza Pfizera i Moderny, opartych na nowej, nigdy wcześniej nie stosowanej technologii – nie będzie tak łatwo, bo żaden „patch” nie przywróci później zrujnowanego zdrowia ani nie wskrzesi tych uczestników eksperymentu, na których wyjdą „bugi”.

    W tej chwili mało kto się tym przejmuje, ale za kilka lat będziemy patrzeć na to, że FDA i inni „regulatorzy” na to pozwolili tak, jak dziś patrzymy na dopuszczenie przez FAA 737MAX do lotów. Z tą różnicą, że – miejmy nadzieję – tym razem odpowiedzialni poniosą jakieś realne konsekwencje.

    Czytaj dalej
  • Praca,  Zarządzanie

    „Feedback”

    1 grudnia 2020 / Jeden komentarz

    Coraz większą popularność uzyskuje słowo „feedback”. Odbywają się całe sesje poświęcone temu jak „dawać feedback” – jak już pisałem urządza się z tego nawet konkursy. Ten „feedback” to widać jakieś bardzo trudne i skomplikowane, a zarazem bardzo ważne zagadnienie, prawda? Dziwna rzecz jakim cudem ludzkość dała sobie radę przez całe wieki, ba!, tysiąclecia, nie roztrząsając tak ważnego zagadnienia.

    Spróbujmy więc „rozpakować” to dziwne słowo i ustalić co się za nim kryje.

    Tak naprawdę chodzi po prostu o to, jak Brajankowi powiedzieć, że coś spieprzył tak, żeby Brajanek nie poszedł z płaczem skoczyć z okna. To jasne, kiedy tylko się chwilę nad tym zastanowimy, bo jakoś nie słyszałem, żeby ktoś miał jakiś problem z chwaleniem (słyszeliście o jakiejś sesji klasy „jak chwalić ludzi, żeby nie urazić ich skromności”? o kursach chwalenia zręcznie?). Problem zawsze jest z krytyką, powiedzeniem komuś, że coś zrobił nie tak, że nie jest wspaniały i cudowny. Innymi słowy „feedback” to eufemizm na krytykę.

    Kłopot polega przy tym nie na samym komunikacie (który najczęściej jest po prostu faktem), tylko na tym, że mamy do czynienia z całymi tabunami niedojrzałych psychicznie ludzi, którzy nie są w stanie go po prostu normalnie przyjąć bez popadania w jakieś okropne stany psychiczne. Innymi słowy, ponieważ mamy do czynienia z ludźmi, którzy fizycznie są dorośli, ale psychicznie są dziećmi, to mamy ich traktować tak, jak pięciolatków. Pięciolatkowi nie można powiedzieć wprost, że jego rysunek samochodu to bohomaz, który nic nie przypomina, bo mogłoby to naruszyć jego delikatną, rozwijającą się psychikę. Dzwudziestopięciolatek powinien jednak być w stanie przeżyć komunikat „twój kod to badziwie, jest nieczytelny, weź się ogarnij i napisz to porządnie jeśli umiesz” bez spazmów i napadu depresji. Powinien, ale niestety coraz częściej nie umie, nie jest w stanie. Brajanka głaskano bowiem i „pozytywnie motywowano” pochwałami za byle co przez całe życie, więc nie jest przyzwyczajony do tego, że jego dzieła mogą budzić inną reakcję niż choćby umiarkowany zachwyt.

    Zresztą, Brajankowi nic nie brakowało całe życie, o nic nie musiał walczyć ani starać się dając z siebie wszystko. Nie wymaga więc wiele od siebie samego. A przy tym Brajanek wie, że jest ogromny popyt na każdego, co umie sklecić jakiś w miarę działający kod, więc nie obawia się utraty pracy – uważa, że znajdzie łatwo następną. I niestety ma rację. W związku z tym nie można Brajanka „naprostować”, oswoić z normalną, prostą komunikacją dorosłych ludzi – trzeba się z nim cackać. Problem w tym, że jednak czasem trzeba Brajankowi przekazać informację, że to co stworzył to badziwie nie używając tego straszliwego słowa. I stąd są wszystkie „kursy feedbacku”, to po prostu kombinowanie jak by ten prosty komunikat olukrować i ozdobić, żeby Brajanek nie doznał straszliwej zapaści psychicznej, a jednocześnie jednak coś poprawił. To kapitulacja wobec smutnej rzeczywitości podobnie jak przypominające przedszkola dla dorosłych biura wiodących firm.

    Popularność kursów i książek „feedbacku” to wszystko objaw problemów społecznych, które toczą naszą schyłkową cywilizację. Wiele jest aspektów tego zjawiska. Na przykład ogólny kult dziecięctwa i młodości, dotyczący nie tylko cielesności (ten wieczny wyścig by wyglądać młodo), ale także umysłowości, który zastąpił typowy dla tradycyjnych społeczeństw szacunek wobec doświadczenia i mądrości nabywanej z wiekiem.

    Ja myślę, że lepiej jednak zamiast komibinować, po prostu mówić wprost i jasno, bez lukrowania o co chodzi. Jeśli ludzie nie zostali przygotowani do bycia dorosłymi przez wychowanie i system edukacyjny, to niestety będą musieli tą lekcję odrobić boleśnie w życiu dorosłym. Traktując pracowników jak dzieci i bawiąc się w „feedback” wcale im nie pomagamy – przeciwnie, utrwalamy niedojrzałość i oderwanie od rzeczywistości hamując w zasadzie ich prawdziwy rozwój.

    Czytaj dalej
  • Agile,  Zarządzanie

    Jak wprowadzić Agile poprzez projekt pilotażowy?

    11 sierpnia 2017 / Jeden komentarz

    Duża popularność metod zwinnych powoduje, że obecnie niemal każda organizacja, która jeszcze w taki sposób nie pracowała, chce przynajmniej spróbować jak sprawdzałby się taki sposób pracy. Typowym pierwszym krokiem wejścia w Agile jest przeprowadzenie pilotażu, a więc możliwie zgodnego z zasadami wdrożenia jednej lub więcej metod zwinnych w pewnym relatywnie niewielkim przedsięwzięciu (obszarze, produkcie, projekcie).

    Zalety takiego podejścia to:

    • ograniczenie ryzyka i skali trudności,
    • zebranie doświadczeń i wytworzenie wewnętrznej wiedzy w organizacji na temat stosowania metod i praktyk Agile w konkretnym środowisku, co przyda się przy ich dalszym wprowadzaniu,
    • uzyskanie pozytywnych efektów, co ułatwi utrzymanie lub nawet dopiero uzyskanie wsparcia kierownictwa organizacji dla Agile.

    [W dalszej części artykułu używam określenia „produkt” tak, jak jest on rozumiany w metodykach zwinnych np. Scrum. W tym rozumieniu „Produkt” to konkretny system lub aplikacja, dostarczająca konkretnych funkcji użytkownikom lub innym systemom, technologicznie i pojęciowo wyodrębniona od innych. W tym artykule słowo „produkt” nie oznacza zatem rezultatu jakiegoś działania, lecz istniejący w czasie byt, który w efekcie działań zespołu podlega zmianom. Słowo „produkt” nie oznacza także warstwy technologicznej albo dokumentu, ale zawsze działające oprogramowanie dostarczające wartościowych funkcji ludzkim użytkownikom lub innym systemom.]

    Wybór przedsięwzięcia

    Obszar dla pilotażu można wybrać na dwa sposoby:

    • najbardziej zmienny obszar – wybranie produktu (systemu, aplikacji), gdzie jest największa zmienność wymagań i co za tym idzie przed wprowadzeniem metod zwinnych największe obciążenie zespołu niestabilnością wynikającą ze sprzecznych żądań i oczekiwań interesariuszów. W takim systemie można pokazać szybko istotną poprawę przewidywalności i przepustowości pracy, często także podniesienie jej jakości.
    • bezpieczny produkt – wybranie relatywnie wydzielonego (zarówno produktowo jak i systemowo) produktu. Dla takiego produktu będzie łatwo wykonać „czyste” wdrożenie podlegających pilotażowi praktyk, a przede wszystkim uzyskać odpowiednie działanie Product Ownera, umożliwiające reakcję na zmienne oczekiwania użytkowników / klientów poprzez ciągłą zmianę i dopasowywanie wymagań kierowanych do realizacji. To powinno umożliwić zademonstrowanie realnych korzyści wynikających z podejścia Agile. Odrębność technologiczna ułatwia doprowadzenie praktyk technicznych i jakości do wymaganego poziomu.

    Wybór jednej z powyższych opcji możno zależy od sytuacji. Wskazana jest dyskusja przed jego dokonaniem, pomocny może tu być konsultant (Agile Coach), który może służąc swoim doświadczeniem doradzić przy wyborze.

    W każdym przypadku jest wskazane, aby produkt (oprogramowanie) był „produkcyjny”, a więc dostępny dla użytkowników. Najlepiej aby był taki od samego początku względnie stał się takim relatywnie szybko podczas trwania pilotażu. Dzięki temu:

    • możliwe jest osiągnięcie realnych korzyści ze zwinności poprzez dostarczanie użytkownikom (klientom) działającego oprogramowania, którego mogą od razu używać oraz możliwość szybkiego reagowania na rzeczywiste potrzeby zgłaszane przez użytkowników (klientów) już w trakcie prac,
    • realne sprawdzenie poziomu technologicznego, w tym zastosowanych rozwiązań i praktyk z zakresu automatyzacji testów i procesu wydań,
    • dyscyplina i zaangażowanie zespołu pilotażowego są większe, gdy mają oni świadomość, że wytwarzają realnie działający produkt, a nie tworzą coś „do szuflady”.

    Przy wyborze obszaru pewne znaczenie ma dostępność oraz osobowość związanych z nim interesariuszy. Zaleca się prowadzenie pilotażu na produktach, których interesariusze są dostępni, otwarci na sposób pracy wymagający częstej interakcji przynajmniej z Product Ownerem, a zarazem borykają się z dużą zmiennością i nieprzewidywalnością, co powoduje trudność w stworzeniu stabilnych wymagań. Interesariusze o omówionych cechach dają największe szanse nie tylko na powodzenie pilota, ale także na osiągnięcie realnych korzyści w wyniku zastosowania metod i praktyk Agile.

    Po wyborze obszaru do pilotażu jest zalecane określenie celów oraz ustalenie metryk, które zostaną użyte do upewnienia się, że owe cele są osiągane. Mowa tu o celach wykraczających poza same metodyki i praktyki Agile. Cele i metryki powinni ustalić zarządzający, którzy podejmują decyzję o pilotażu. Ponownie użyteczne może być wsparcie doświadczonego doradcy (Agile Coacha).

    ​Role i ich przygotowanie

    Poniżej wymieniam role, które wystąpią w pilotażu, krótko je opisując i wskazując kogo optymalnie wybrać do ich pełnienia. Wskazane jest przygotowanie osób mających wziąć udział w pilotażu, stąd podaję także zalecane szkolenia i warsztaty z oferty Code Sprinters.

    Role:

    • Product Owner – osoba decydująca o tym, jakie funkcjonalności będą budowane przez zespół i dostępne w kolejnych wersjach produktu (po kolejnych sprintach). Osoba ta powinna mieć wiedzę biznesową z obszaru produktu (np. przy tworzeniu systemu do sprzedaży internetowej polis ubezpieczenia podróżnego idealnie PO byłby osobą z biznesu, która zajmowała się sprzedażą takich polis względnie ich formułowaniem jako produktów ubezpieczeniowych). Osoba ta powinna mieć odpowiednie umocowanie – nadaną pełnię władzy do decydowania o kształcie produktu.

    Zalecane szkolenia to: Professional Scrum Product Owner, a następnie Product Owner Toolbox.

    • Scrum Master – osoba dbająca o proces, a także o zespół developerski, pilnująca trzymania się zobowiązań i standardów, wspomagająca wszystkich w rozumieniu i stosowaniu Scrum. Wskazane jest, by rolę tą pełniła osoba, która nie ma osobowości dominującej i dyrektywnej (z tego względu może to być rola trudna dla osób mających doświadczenie jako menedżerowie projektów – PM). Nie jest wskazane, by w roli tej występowała osoba, która była – lub co gorsza nadal jest – menedżerem liniowym innych osób biorących udział w pilotażu, zwłaszcza zaś zespołu developerskiego i PO. Wskazane jest zapewnienie nowemu Scrum Masterowi regularnego wsparcia Agile Coacha. W niektórych przypadkach może być wskazane pełnienie tej roli przez kilka pierwszych sprintów przez zewnętrznego Scrum Mastera o większym doświadczeniu.

    Zalecane szkolenia dla osoby mającej być Scrum Masterem: Professional Scum Master, a następnie Scrum Master Toolbox.

    • Zespół Developerski – osoby, które będą wykonywać pracę implementacji wymagań i wydawać regularnie kolejne wersje produktu. Zespół powinien nie przekraczać 10 osób. Powinien być „wskrośfunkcjonalny”, a więc składać się z osób posiadających ogółem, w sumie wszystkie kompetencje niezbędne dla zbudowania co sprint w pełni działającego, używalnego produktu. Jest wskazane, acz niekonieczne, aby zespół skompletować z ochotników. Jest niezbędne aby na czas przedsięwzięcia osoby wchodzące w skład zespołu developerskiego były przypisane do niego w 100%, a więc nie brały udziału w żadnych innych przedsięwzięciach, projektach itp. Jest wysoce wskazane dobranie osób do zespołu z jednej lokalizacji, idealnie umieszczenie członków zespołu w jednym pokoju. Pozwoli to na szybkie zawiązanie więzi różniących zespół od grupy oraz użycie prostych a zarazem najbardziej skutecznych sposobów wizualizacji (tablica, karteczki itp.).

    Zalecane szkolenia: Scrum w Pigułce lub Professional Scrum Foundations, zależnie od posiadanej wiedzy warsztaty Test Driven Development dla odpowiedniej technologii.

    • Menedżerowie liniowi – menedżerowie liniowi to w tym przypadku albo przełożeni osób delegowanych do pilotażu, albo menedżer liniowy formalnie nad całym zespołem pilotażowym. Wskazane jest, by była to osoba otwarta, której doświadczenie i osobowość ułatwią jej wejście w postawę wspierającego lidera (ang. servant leadership).

    Wskazane szkolenia: Scrum w Pigułce, warsztaty Management 3.0.

    • Interesariusze – osoby (najczęściej z tzw. biznesu), które mają możliwość zgłaszania funkcjonalności do produktu. Dobór interesariuszy jest związany z wyborem produktu, dlatego wskazane cechy omówiłem już powyżej.

    Wskazane szkolenia: Scrum w Pigułce, przy większych lub bardziej złożonych produktach może być wskazany udział interesariuszów w prowadzonych przez konsultanta warsztatach Story Mappingu, które pozwolą nie tylko lepiej zdefiniować produkt ale także umożliwią interesariuszom uzyskanie jego szerszej perspektywy, co ułatwia ich współpracę z Product Ownerem.

    W niektórych przypadkach (nowy zespół, małe doświadczenie w organizacji) może być wskazany udział całego zespołu pilotażowego w przygotowanym dla niego „na miarę” programie „Agile Kickstart”. Może on wtedy zastąpić niektóre ze szkoleń polecanych powyżej.

    Powyższy opis zakłada zastosowanie najpopularniejszej metody Agile: Scrum. Dla zastosowania metody Kanban przygotowanie będzie podobne jeśli idzie o Product Ownera, różni się jeśli idzie o pozostałe role (np. rola Scrum Mastera nie występuje, zasady organizacji zespołu są inne itp.).

    Przeprowadzenie pilotażu

    Podczas prowadzenia pilotażu należy dbać o zachowanie zasad metody Scrum, a także przejrzystości (czemu służy m.in. przygotowanie i bezwzględne przestrzeganie Definition of Done, dbanie o dostępność i czytelność Backlogu Produktu itp.). Niezwykle istotne jest wykonywanie nie tylko zakładanych w procesie retrospekcji zespołu, ale także retrospekcji z udziałem interesariuszów i menedżerów – pierwsza taka retrospekcja powinna odbyć się już po trzecim sprincie. Istotne jest również śledzenie założonych uprzednio metryk sukcesu, zwłaszcza biznesowego, oraz dbanie o zachowanie standardów technicznych – dobrej jakości kodu, testowania, niskiej stopy błędów itp.

    Jest wskazane aby podczas pilotażu zespół korzystał z tradycyjnych, papierowych technik wizualizacji sprintu (tablica, karteczki itp.) nawet jeśli docelowo planowane jest wdrożenie elektronicznego narzędzia wspierającego. Takie podejście ma na celu lepsze zrozumienia roli tego rodzaju artefaktów, co może być trudniejsze jeśli od razu zastosowane one zostaną w wersji elektronicznej. Jeśli sytuacja tego wymaga (rozproszeni interesariusze) to wyjątkiem może być sam Backlog Produktu, który może być prowadzony elektronicznie. Najlepiej prowadzić go wówczas w jak najprostszym narzędziu – np. Google Sheets.

    Podczas prowadzenia pilotażu może być przydatne wsparcie zewnętrznego Agile Coacha. Podczas regularnych wizyt będzie on:

    • prowadzić obserwację stanu procesu i zespołu, by następnie przekazać zalecenia i sugestie Scrum Masterowi i zespołowi,
    • poprowadzić niektóre wydarzenia np. wspomnianą wyżej dodatkową retrospekcję,
    • wspierać coachingowo i mentorsko Scrum Mastera i Product Ownera.

    Zespoły mające deficyty umiejętności w zakresie nowoczesnych narzędzi i technik programowania i zapewnienia jakości mogą skorzystać ze wsparcia konsultanta technicznego – doświadczonego praktyka, który pracując z zespołem pomoże mu szybciej takowe techniki opanować, a narzędzia wdrożyć.

    Ocena i dalsze działania

    Po jakimś czasie (może to być ustalony z góry czas lub też moment osiągnięcia założonych wcześniej celów lub stanu produktu), wskazane jest dokonanie podsumowania pilotażu i oceny jego skutków. Pomocne w tym będą ustalone wcześniej metryki sukcesu i prowadzona podczas pilotażu ich systematyczne zbieranie. Wskazane jest dokonanie także badania satysfakcji interesariuszy oraz ew. użytkowników będącego przedmiotem pilotażu produktu. Na tej podstawie kierownictwo podejmuje decyzję co dalej – czy nastąpi szersze zastosowanie metod zwinnych, a jeśli tak to w jakim scenariuszu.

    Jeśli zostanie podjęta decyzja pozytywna, to – zależnie od wybranego produktu – prace nad nim mogą być kontynuowane dalej przez ten sam zespół. Będzie to już jednak „normalna” praca, nie pilotaż. Inne podejście to rozproszenie członków zespołu pilotażowego po nowo utworzonych kolejnych zespołach.

    Czytaj dalej