Friday, December 28, 2018

Dwie zasady skutecznego rozwiązywania problemów w prezencie noworocznym

Bez zbędnych wstępów.

Zasada 1.

Niemal każdy dylemat ma co najmniej dwa rozwiązania: dobre i praktyczne. Najczęściej są one od siebie różne.

Przykład: Znajdujesz się na skrzyżowaniu równorzędnym, który samochód ma pierwszeństwo? Jeśli odpowiedziałeś, że ten z prawiej, to masz rację. To dobra odpowiedź. Odpowiedź praktyczna jest taka, że pierwszeństwo ma ten większy...Samo życie.

Jeśli zatem przychodzą do Ciebie manager i Scrum Master z dylematem typu "czy dorzucanie zadań do sprintu jest adżajlowe, czy nieadżajlowe", to nie bierz udział w tej dyskusji. Zamiast tego pomóż im rozwiązać najbardziej palący aktualnie problem. Dobrze słyszałeś - zadanie kilku efemerycznych pytań o wartości Scruma nie wystarczy. Trzeba będzie doradzić, pokazać, albo część zrobić samemu.

Żeby przeanalizować czy coś jest dobre czy niedobre, potrzeba spokojnej głowy i refleksyjnego nastroju. Gwarantuję, że gdy zejdzie ciśnienie, związane z bieżączką, kwestię adżajlowości swojej pracy rzeczeni manager i SM rozwiążą sobie sami.

Zasada 2.

Albo inaczej nieskromnie - Wielkie Twierdzenie Bartyzela: "Każdy problem da się tak steoretyzować, że nie będzie istniało jego rozwiązanie, możliwe do znalezienia za pomocą aktualnie znanych metod badawczych".

Nie daj się wciągnąć w dywagacje "a jeśli mamy dużą liczbę transakcji na sekundę, która będzie przyrastać dość szybko, to XYZ, będzie lepsze niż ŃŚĄ". Niemal zawsze polegniesz.

Zamiast tego proś o konkretne kejsy i rozwalaj przypadek po przypadku. Pamiętaj, że hipotetyczne problemy mają hipotetyczne rozwiązania. Konkretne problemy mają rozwiązania konkretne.

Managerowie zagadują mnie często: "Czy manager może być Scrum Masterem?". Kilka razy zdarzyło mi się odpowiedzieć: "Nie, ale ty możesz". Case-by-case.

Wednesday, October 31, 2018

Odpowiedź: 42

Świat IT jest pełen odpowiedzi...
  • Jak pisać czytelniej? Dzielić algorytmy i metody na mniejsze kawałki. Pisali o tym McConnell, Beck, Martin.
  • Jak radzić sobie implementacją złożonego procesu? Można wydzielić współpracujące ze sobą obiekty. Pisał o tym Meyer.
  • Jak okiełznać złożoność domenową? Można zastosować wyróżnić bounded contexts itd. Pisali o tym Evans, Vernon, Dahan, Young i inni.
  • Jak dokładniej testować? Pisać mniejsze testy skupione na konkretnym zachowaniu. To, akurat mówią wszyscy...
  • Jak poprawić trafność oszacowania? Można dekomponować na podzadania. Pisał o tym McConnell.
  • Jak ogarnąć mega złożone interfejsy UI? Podzielić ma mniejsze lepiej zarządzalne kawałki i skomunikować między sobą. Zrobili np. w robotlegs framework.
  • Jak skalować agility? Zacząć od skalowania produktu i podzielenia go na mniejsze podprodukty. Mówili o tym Poppendieckowie.
  • Jak poprawić swoją efektywność. Skupić się na mniejszej ilości spraw. To tłuką na konferencjach bez litości.
  • Jak uniknąć kosztownego refaktoringu i mądrzej ogarnąć architekturę? Wydzielić odpowiednio małe microserives. Mówił o tym Young.
  • itd.
Wymienione odpowiedzi są pożyteczne, ale chyba gdzieś umknęło pytanie. Otóż podstawowym pytaniem, z którym boryka się uniwersum IT jest pytanie o granulację. Ile to jest mało, ile dużo, a ile odpowiednio?
Jaki serwis będzie OK, a jaki za duży? I w jakim stopniu zależy to od kontekstu?

Kłopot w tym, że żadne z wymienionych odpowiedzi, ani chyba też żadne, które znamy, nie adresuje tego podstawowego pytania.

Wednesday, October 24, 2018

Dzięki za 4Developers w Łodzi!

Nie ma co ukrywać ścieżka Soft Skills & Business Relations wyszła świetna. Przez większość slotów sala była nabita ponad wymiar.

Dziękuję prelegentom za przygotowanie prezentacji. Szczególnie dziękuję za sumienne potraktowanie naszej prośby o przemyślenie take aways z prezentacji.

Z mojej strony "utrzymać":
  • formułę krótkich prezentacji; planowaliśmy 12 min. wyszło ~15; wiem od prelegentów, że to trudne zmieścić ogrom swojego doświadczenia w tak krótkim czasie; robiłem sobie jednak losowe exit poll śród uczestników - ta forma bardzo im odpowiada; zarekomenduję Proidei utrzymanie takiej formy ścieżki
I "do zmiany":
  • musimy poprawić timing; przerywanie prelegentowi nie jest miłe ani dla jednej ani dla drugiej strony; uwierzcie mi jednak, że uczestnicy tego oczekują i zgłaszali nam takie prośby w trakcie konferencji;
  • Od wielu prelegentów dostałem prośbę o feedback nt. ich wystapień; mam taki pomysł, aby na najbliższym 4Developers każdy z prelegentów mógł go otrzymać o ile wcześniej wyrazi taki życzenie; będę uczestniczył we wskazanych wystąpieniach jako obserwator, robił notatki i przekażę prelegentowi/prelegentce swoje obserwacje: start-stop-continue
  • kolejny pomysł polega na tym, aby prelegent, który otrzyma najlepsze noty od uczestników został poproszony na kolejnym wydaniu konferencji o rozwinięcie swojego tematu w dłuższym slocie np. 30-45 min. Skoro uczestnicy deklarują, że chcą go/jej słuchać, to idźmy za tym
  • na końcowych talkach ubywało osób głównie z tego powodu, że niektórzy wyjeżdżali; nie wiem co z tym zrobić

Friday, October 12, 2018

Zwinność kulturowo rozmiękczona

Tu, nad Wisłą, ze zwinnością (agility) wydarzyło się coś niedobrego. Zapraszam to krótkiej rozkminki.

Weźmy taki cytat ze Scrum Guide (dotyczy on roli Product Ownera): "The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable."

I z polskiego tłumaczenia: "Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać je Zespołowi Deweloperskiemu, jednak to Właściciel Produktu pozostaje za nie odpowiedzialny"

Dostrzegasz coś intrygującego?

responsible vs. accountable

Responsible oznacza odpowiedzialność w takim sensie, że ktoś ma coś w swoich obowiązkach, bo na przykład zostały mu te obowiązki przydzielone.

Accountable oznacza mocniejszy rodzaj odpowiedzialności np. prawnej, czyli odpowiedzialności za konsekwencje.

Zatem tłumaczenie oddające sens angielskiego zdania powinno brzmieć: "Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać je Zespołowi Deweloperskiemu, jednak to Właściciel Produktu zostanie z nich rozliczony". Jedno słowo wiele zmienia, co?

Podobnie rzecz się ma Zespołem Deweloperskim: „Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.”

Zatem Zespół Deweloperski zostanie rozliczony za brak przyrostu (increment) produktu na koniec sprintu.

Niuans kulturowy

Moim zdaniem mamy tu do czynienia z różnicą kulturową. Anglosaska - jak mniemam - prosta i konkretna zasada rozliczenia została w polskim tłumaczeniu rozmyta i rozmiękczona w ogólną odpowiedzialność.

Zgaduję powód. Sęk w tym, że rozliczyć ma w języku polskim mocno pejoratywne konotacje. "Rozliczę cię" oznacza mniej więcej tyle: "Słuchaj gościu, jak coś pójdzie nie tak, to ty za to bekniesz. Poniał?"

Głębiej o accountability

Powiem więcej. "accountability" oznacza taki rodzaj (silnej) odpowiedzialności (za konsekwencje), który został przyjęty dobrowolnie. Na przykład CEO jest accountable za organizację i zostanie rozliczony za ew. sukcesy i nieprawidłowości. Ważne jest to, że on o tym wiedział od samego początku i zgodził się na to "rozliczanie" w momencie przyjęcia nominacji.

W tak rozumianym rozliczaniu nie ma nic negatywnego. Ktoś otrzymuje pełnię władzy: przywileje oraz konsekwencje. Prosty deal.

Czego chce Scrum?

Posługując się już przedefiniowanymi wyżej pojęciami, można powiedzieć, że Scrum chce od swojego praktyka pewnej dojrzałości.

Chce, aby PO, DevTeam czy SM, zanim podejmą decyzję, że używają Scruma, zatrzymali się na moment. Niech się zatrzymają, popatrzą na możliwe przywileje, na potencjalne konsekwencje i świadomie powiedziedzą: "Tak, chcę być rozliczony za swoją pracę."...albo nie.

Rzecz jasna możliwość rozliczania implikuje ze strony organizacji konieczność przydzielenia autonomii, decyzyjności i tak ogólnie nie wpieprzania się w paradę.

Kolorowy coach

Tu kudos dla Bartka za insight.

Weźmy jeszcze jeden cytat na temat tego, co tam Scrum Master powinien: "Coaching the Development Team in self-organization and cross-functionality"

I po polskiemu: "Coachując Zespół Deweloperski w zakresie wykorzystania zasad samoorganizacji i międzyfunkcyjności".

No więc rzucili się ludzie na kursy kołczigu i adżajkołczują. No, ale looknijmy sobie na OxfordDict czymże jest ten coaching?

O, żesz w mordę, madafaka! Co ja paczę???

  • "Train or instruct (a team or player)"
  • "Teach (a subject or sport) as a coach"
  • "Give (someone) instructions as to what to do or say in a particular situation"
  • "Give (someone) professional advice on how to attain their goals"

Zatem jeśli Scrum Master coach Zespół Deweloperski, to oznacza, że ten Scrum Master jest naumiany Scruma i generalnie ogarnia temat. Następnie jego zadanie polega na tym, aby nauczyć Scruma zespół. No i może ludzi poza zespołem, przynajmniej na takim poziomie, żeby kumali o co chodzi.

Nie oznacza to, że statutową metodą pracy Scrum Mastera jest "metoda coachingowa", czyli zadawanie pytań tak, aby delikwentom samo wyjajiło się, co im dolega. Może to robić, jak będzie ku temu powód. Moje doświadczenie podpowiada mi jednak, że takich chwil jest naprawdę niewiele.

Nawiasem mówiąc "metoda coachingowa" zakłada, że klient ma pełnię kompetencji do rozwiązania swoich problemów. No więc życzę powodzenia w pracy tą metodą, gdy zespół nie zna i nie umie Scruma.

Ej, a wiecie jak deweloperzy mówią na takich adżajlkołczów, co to w każdym próbują znaleźć wewnętrzne dziecko i proszeni czy nie proszeni serwują sesje coachingowe tuzinami? "Kolorowe pisaki"...sam słyszałem.

Także, ten...wyluzuj. Po prostu wyluzuj.

Continuous attention to technical excellence...

No więc jak taki #kolorowyCoach w pośpiechu przygotowuje się do certyfikatu, to czytając po łebkach adżajlmanifesto, skupia się tylko na wartościach, zapominając, że jest tam też parę bardziej szczegółowych wytycznych.

Między innymi taka: "Continuous attention to technical excellence and good design enhances agility". O co chodzi?

Coraz częściej dochodzę do wniosku, że pierwszym blokerem do uzwinnienia się jest architektura. Co z tego, że nasz supersystem powstał w sprintach i nawet miał wizję i rołdmapę, skoro to monolit liczący 2MLOC?

Gdzieś popełniliśmy błąd. W którymś momencie zwinność odkleiła się od technologii i stała się wyłącznie: kulturą, mindsetem i procesem.
Tak się nie da.

Biznes dzieje się szybko. Żeby szybko produkować dla tego biznesu potrzeba metod, architektur, technologii i skilla, które umożliwią osiągnięcie tej szybkości. Bez tego zostają tylko kolorowe pisaki...

A na deser międzyfunkcjonalność

W oryginale: "Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment"

I w rodzimym dialekcie: "Zespoły Deweloperskie są międzyfunkcjonalne, w swoim składzie posiadają wszystkie umiejętności niezbędne do wytworzenia Przyrostu produktu."

Nie wiem czy tylko ja wymiękam z tą "międzyfunkcjonalnością"?

Neologizm - jak przypuszczam - "międzyfunkcjonalność" należałoby rozumieć przez analogię do np. "międzywydziałowości", czyli jako coś co się dzieje "pomiędzy granicami wyznaczonymi przez funkcjonalności". Czy ja wiem?

Jeśli już kuć nowe słowa, to ideę oddawałoby "pełnokompetentny": "Zespoły Deweloperskie są pełnokompetentne, w swoim składzie posiadają wszystkie umiejętności niezbędne do wytworzenia Przyrostu produktu." Ewentualnie "pełnoumne" :)

Thursday, September 6, 2018

Jestem Scrum Masterem, co mam robić?

Śmieją się developerzy ze ScrumMasterów, że ci nic nie robią. Niby żartem, niby po przyjacielsku, ale boli. Gdy ScrumMaster zostaje ScrumMaster jedne z pierwszych pytań, które sobie zadaje to:
  • No i co ja mam teraz robić?
  • A co jeśli zapomnę jak się programuje?
  • A co jeśli znudzi mi się programowanie
Jedna z dróg, którą może wybrać SM na wdrożenie Scruma wiedzie przez cztery następujące etapy:
  1. Framework by Guide
  2. Jakość techniczna
  3. Wartości i wyjście poza zespół
  4. Nieustanny tuning DoD
W tym modelu, SM może zająć się doprowadzeniem do zaistnienia następujących rzeczy:
  1. Framework by Guide
    • Zaimplementowanie w pracy zespołu ról: SM, PO z biznesu, SM, DevTeam
    • Zaimplementowanie w pracy zespołu: sprintów stałej długości, DoD, Planningu, Review, Daily, Retro, regularnego refinementu PBL, Product Backloga, Spring Backloga
    • Biznesowe cele sprintów
    • Zaimplementowanie w pracy zespołu: biznesowego inkrementu produktu na koniec sprintu, współpracy między zespołem a PO, która nie wymaga sztywnego DoR
    • samoorganizacja Zespołu deweloperskiego
    • Doprowadzenie do tego, aby testerzy byli pełnoprawnymi członkami Zespołu scrumowego, a nie podzespołem w zespole
  2. Jakość techniczna
    • Wdrożenie 1-3 metryk kodu oraz systematyczna praca nad ich poprawianiem; propozycja na początek CC oraz LOC na poziomie metod i klas
    • Zmierzenie długu technicznego, przygotowanie planu jego spłaty i wynegocjowanie tego z PO
    • Wdrożenie Continuous Integration -> Continuous Deployment -> Continuous Delivery
    • Wprowadzenie regularnego Code Review w zespole wraz z narzędziem, który je wspiera
    • Wdrożenie Test/Behaviour Driven Development
    • Wdrożenie automatycznych testów funkcjonalnych wraz z narzędziem, które je wspiera; nauczenie PO i/lub interesariuszy formułowania wymagań w formie scenariuszy
    • Wdrożenie Domain-Driven Design, nawiązanie współpracy z ekspertami domenowymi, wdrożenie Modelling Whirpool
    • Regularne Architectural Kata
    • Regularne Refactoring Kata
  3. Wartości i wyjście poza zespół
    • Doprowadzenie do sytuacji, w której prace zespołu są niezależne od innych jednostek organizacji
    • Pomoc managerowi zespołu w na nowo zdefiniowaniu swojej roli w stosunku do zespołu scrumowego
    • Doprowadzenie do określenia zasad współpracy pomiędzy jego/jej zespołem a innymi zespołami i/lub jednostkami organizacyjnymi
    • Stymulowanie wewnętrznych inicjatyw typu "craftsmanship": wewnętrzne konferencje, warsztaty, szkolenia, mini-społeczności skupione w okół danych technologii albo ról (np. gildie)
    • Eksponowanie osiągnięć zespołu na zewnątrz organizacji: konferencje branżowe, artykuły w prasie i na portalach branżowych
    • Wdrażanie i promowanie empirycznego podejścia do pracy tj. wprowadzanie przejrzystych metryk przy jednoczesnym uczeniu organizacji jak z nich sensownie korzystać
  4. Nieustanny tuning DoD
    • Doprowadzenie do sytuacji, w której "Done" oznacza "dostępne dla klientów"
    • Praca na skróceniem time to markiet, time to feedback
    • Dążenie do sytuacji, w której ani zespół ani organizacja nie potrzebują Scrum Mastera, gdyż jego obowiązki zostały osmotycznie przejęte przez członków zespołu i innych pracowników organizacji, którzy bezpośrednio dostarczają wartość dla jej klientów

Tuesday, August 28, 2018

SegFault



Cieszę się, że to właśnie ONI zrobili nową konferencję.
Z każdym z chłopaków miałem okazję wielokrotnie współpracować i myślę, że łączą ich trzy rzeczy:
  • absolutnie niedogmatyczne podejście do programistycznych mód
  • alergia na bullshit
  • olewczy stosunek dla autortetów

Nie wiem jak dla Was, ale dla mnie to pachnie totalną konferencyjną innowacją. Do zobaczenia we Wrocławiu!

Sunday, July 22, 2018

Zarządzanie "flow"

Miałem ostatnimi czasy nieprzyjemność gościć w hotelu Royal Park Elenite w Bułgarii. Miejsce to do złudzenia przypomniało mi czasy przedszkolne w epoce słusznie minionej, gdy z całych sił starałem się "swoją nauką przynosić chlubę moim rodzicom oraz mojej ojczyźnie Polsce Ludowej"...

Jednak to, co bawiło mnie trzydzieści kilka lat temu, teraz mnie po prostu wnerwiało. Zarządzając tak dużym obiektem można schrzanić wiele rzeczy. Odniosłem wrażenie, że w Royal Park dokumentnie schrzanili je wszystkie.

Żeby tam jakoś wytrzymać postanowiłem zająć się czymś interesującym. Zacząłem przyglądać się stołówce, czy też sali bankietowej - jak nazywano stołówkę.

Byłem naprawdę pod wrażeniem kreatywności designerów tej sali, która już przy niewielkiej liczbie gości rezonowała nieprawdopodobnym chaosem.

Poniżej wklejam poglądową mapę tejże sali.


Straty, straty, straty

Zacznijmy od wylistowania zaobserwowanych przeze mnie start, czyli rzeczy, których w stołówce nie chcielibyśmy obserwować.

  • długie i uciążliwe kolejki - na mapie zaznaczone czerwonymi trójkątami
  • częste kolizje obsługą albo z innymi gośćmi
  • goście pozostawiają dużo niezjedzonych potraw
  • długi czas kompletowania posiłku
  • masło i cukier zmieniają miejsce między obiadem a kolacją
  • gdy zostawisz skompletowany talerz na stoliku bez opieki, to może on zostać sprzątnięty jako "zużyty"

Straty wydają się ze sobą niepowiązane. Przyjrzyjmy się im jednak z perspektywy stoiska z Wypiekami. Na tym stoisku:

  1. Pracuje jedna osoba
  2. Nie nadąża z wypiekami za popytem na nie
  3. W skutek czego powstaje kolejka
  4. Gdy nastąpi dostaw wypieków, to czekający w kolejce nakładają sobie duże ilości
  5. Zatem wypieki znów szybko znikają
  6. I znów powstaje kolejka z powodu niezaspokojenia popytu na wypieki

Przyjrzałem się ilości nakładanych potraw przez gości, a następnie sam sobie tyle nałożyłem. Mimo, że jestem zdrowym, silnym 96kg facetem, zmiękłem.

Nie dałem rady pochłonąć tego wszystkiego bez przeżarcia się. Nie mówiąc już o zakończeniu posiłku porcją słodyczy i miską lodów.

Wnioski #1

Na podstawie ww. obserwacji stawiam następującą hipotezę: nieefektywność procesu produkcji prowadzi do kolejek, oraz zwiększonego popytu i szybkiego wysycania produktów, także do gromadzenia nadmiernych zapasów "na wszelki wypadek", co z kolei ponownie skutkuje niedostępnością produktów, a tym samym kolejkami.

Gdy zobaczymy to na diagramie przyczyn i skutków, od razu odkryjemy pętlę.

Wnioski #2

Zarząd hotelu próbuje radzić sobie z kolejkami w ten sposób, że dzieli gości na dwie grupy. Pierwsza grupa przychodzi na śniadanie o godzinie 7, druga o 8.30. Zamieszczony diagram wskazuje, że jest to błędne podejście. Dzielenie na grupy zniweluje okresowo objawy problemów. Przyczyny pozostaną nietknięte ponieważ dzielenie na grupy nie likwiduje pętli.

Wnioski #3

Zastanawiałem się, gdzie się "wlewa" do tej pętli, co ją startuje. Po krótkiej obserwacji odkryłem winowajcę.

Dla przykładu stoisko z wypiekami obsługuje tylko jedna osoba, której zadaniem jest: ułożenie na blachę, włożenie do pieca, wyjęcie z pieca, a następnie ułożenie do wypieków w koszykach. Wypieków w trakcie śniadania są 3-4 rodzaje. Osoba obsługująca po prostu nie ma tylu rąk.

Druga obserwacja jest taka, że choć personel niezwykle się stara, to oni zwyczajnie nie wiedzą jak konkretnie powinni pracować. Ich praca nie została zaprojektowana. Jest spontaniczna. Sęk w tym, że spontaniczność bardzo słabo się skaluje.

Wnioski #4

Przypuszczam, że to iż tylko jedna osoba obsługuje Wypieki, wynika z oszczędności kosztów. Moim zdaniem jest to podejście błędne. Na podstawie diagramu przyczyn i skutków, uważam, że dołożenie dodatkowej osoby, zaprojektowanie ich współpracy oraz przeszkolenie skutkowałoby:

  • Zmniejszeniem kolejek
  • Mniejszą ilością wyrzucanego jedzenia
  • Poprawą ogólnej satysfakcji gości

Zatem co do pieniędzy - zwiększenie kosztów na dodatkowy etat zostanie zrekompensowane oszczędnościami na ilości wyrzucanego jedzenia.

Paradoksalnie może się okazać, że większą ilością osób będziemy przygotowywać mniejszą ilość jedzenia, gdyż poprawa płynności procesu dostarczania jedzenia zniechęci gości do gromadzenia nadmiernych zapasów na talerzach.

Skoro o procesie mowa...

Dimityr idzie na śniadanie

Popatrzmy na wycieczkę po restauracji jak na proces, w którym na kolejnych etapach, wędrujący przezeń gość otrzymuje jakąś wartość - potrawę, sztućce, itp.

Weźmy pod uwagę hipotetycznego gościa hotelowego - nazwijmy go Dimityr - który przyszedł z dzieckiem, aby zjeść śniadanie: ciepły posiłek, płatki dla dziecka, herbatę, trochę zieleniny, a na deser słodką bułkę ze stoiska z wypiekami

Poniższy rysunek pokazuje trasę Dimityra, którą przebędzie w stołówce, aby zjeść śniadanie.

Jak można przypuszczać, przy przeciętnej setce gości na sali, prawdopodobieństwo kolizji z innymi głodnymi, kimś z obsługi, albo poślizgnięcia się na jakimś mokrym obrzydlistwie jest bardzo wysokie. Sam się kilkukrotnie niemal wyłożyłem niosąc dziecko na rękach.

Najbardziej niebezpieczny sposób rozwiązywania problemów w tym procesie można zobrazować przez to, co się dzieje z mlekiem do płatków śniadaniowych...Jeśli przyjrzysz się ponownie mapie, zauważysz, że tuż przy płatach stoi naczynie z zimnym mlekiem. Natomiast mleko ciepłe znajduje się w przeciwległym końcu sali, w okolicy ekspresów do kawy.

Odkryłem, że jest tak dlatego, iż w okolicy płatków brakuje gniazdka do podłączenia pojemnika, który podtrzymywał by jego temperaturę. Na tym polega właśnie dramat tego rozwiązania - na naginaniu procesu biznesowego pod ograniczenia techniczne. Do zapamiętania: nie wolno tego robić. To niemal zawsze prowadzi do chaosu.

Jeśli ograniczenia techniczne nie pozwalają na poprawne wsparcie procesu, już lepiej go okroić - czyli zrezygnować z wystawiania płatków. Albo wystawić tylko zimne mleko przy płatkach, a obok ze dwie mikrofale.

Mityczna wartość biznesowa

Zdefiniujmy, czym jest owa wartoś biznesowa. Dla mnie, jako uczestnika chaotycznej gonitwy po stołówce wartość biznesowa, czyli to czego przede wszystkim oczekuję od restauracji, do której przychodzę na śniadanie jest:

  • odwrotnie proporcjonalna do łącznej drogi, którą muszę przebyć, aby skompletować śniadania i rozpocząć jedzenie
  • odwrotnie proporcjonalna do ilość kolizji z innymi uczestnikami procesu
  • odwrotnie proporcjonalna do sumarycznego czasu potrzebnego na skompletowanie śniadania (włączając w to oczekiwanie w kolejkach)

Chociaż czas można w prostym przypadku wyprowadzić z drogi, to dla gościa restauracji czym innym jest dreptanie pomiędzy stoiskami, a czym innymi przedłużające się czekanie.

Uściślijmy zatem:

gdzie: Vb - wartość biznesowa, L - łączna droga, t - łączny czas, n - liczba kolizji, k - współczynnik proporcjonalności. Przyjmijmy roboczo, że n = 1 jest po prostu wartością minimalną i nie oznacza kolizji.

Warto się przy okazji zastanowić, jaką interpretację fizyczną ma współczynnik proporcjonalności - k. Prawdą jest, że:

Można więc przyjąć, że k jest jednostkową - minimalną - wartością oczekiwaną przez klienta, przy której wypadkowa czynników wpływających na wartość biznesową osiąga wartość minimalną równą 1.

Wnioski #5

Należałby by dążyć do tego, aby gość uzyskał wspomnianą podstawową wartość biznesową za jednym razem, z jednej lokacji na zasadzie "grab and go". Na przykład: mleko plus płatki, plus mikrofala albo gotowe hot-dogi.

Wnioski #6

Zatrzymajmy się jeszcze na chwilę przy kolejce do dań ciepłych. Jej przyczyna nie wynika z niedostatecznych dostaw, jak w przypadku stoiska Wypieki. Tu chodzi po pomieszanie przetwarzania szeregowego z równoległym.

Zestawy dań powtarzają się trzykrotnie w rzędzie. Goście zaś ustawiają się w jednej kolejce do wszystkich dań. Większość gości nakładało sobie jedną bądź dwie potrawy. Zatem jeśli akurat brakowało tylko jednej potrawy, na którą czekała tylko jedna osoba, to blokowało to całą kolejkę. W ten sposób większość gości z kolejki oczekiwała na dostarczenie potrawy, której akurat nie chcieli sobie nałożyć.

Widząc bezsens tej sytuacji uparcie pomijałem kolejkę, co spotykało się z powszechnym niezrozumieniem.

Problem ten można by teoretycznie rozwiązać, jeśli powtarzające się zestawy dań rozmieści się równolegle zamiast szeregowo - na zasadzie wysp. Ułatwi to spontaniczne powstawanie wielu kolejek do jednej wyspy.

Podsumowanie

Po opisanym przemyśleniu sprawy mam następujące rekomendacje:

  • zredukować ilość serwowanych potraw; mniejsze urozmaicenie na rzecz płynniejszego procesu
  • zwiększyć liczbę osób przygotowujących potrawy na bieżąco, aby zapewnić większą ilość regularnych dostaw
  • tam, gdzie występują ograniczenia techniczne nie kombinować, tylko odciąć tę gałąź procesu np. zlikwidować płatki
  • wprowadzić miejsca potraw "grab and go, które nie wymagają kompletowania np. gotowe hot-dogi
  • preferować równoległe ustawienia potraw zamiast szeregowych
  • dążyć do takiego organizowania przestrzeni, aby preferować więcej małych kolejek niż mniej dużych
  • mierzyć ilość wyrzucanego jedzenia
  • mierzyć długość i częstość występowania kolejek przy stanowiskach z potrawami
  • przeszkolić personel i zapoznać go z oczekiwanym flow na stołówce

Sprawy, którym należy się jeszcze przyjrzeć, to:

  • ustawienie stolików w stosunku do potraw
  • trasy, po których porusza się personel z dostawami oraz ze zużytymi naczyniami
  • utrzymywanie czystej podłogi

Monday, February 5, 2018

Ścieżka Soft Skills @ 4Developers




W tym roku proponujemy Wam nowy format ścieżki Soft Skills
  • talk trwa 12 minut
  • warsztat trwa 60 minut

Może na początek wyjaśnię skąd ta zmiana. Jestem częstym bywalcem różnego rodzaju konferencji zarówno jako uczestnik jak i prelegent. Jeśli popatrzymy na ścieżkę konferencyjną jak na ciąg zdarzeń dostarczających wartości uczestnikom, to ja widzę następujące straty:

  • zbyt długi czas opowiadania o sobie - sorry, ludzie nie po to zapłacili za bilet po to, żeby posłuchać o biografii prelegenta, ile ma certyfikatów,
    w ilu meetupach się udziela itd; przyszli po to, aby: dowiedzieć się czegoś, posłuchać o czyichś doświadczeniach, skonfrontować swoje przemyślenia, ponetworkować

  • take aways zakomitej większości prezentacji, które widziałem można zmieścić w kilkanaście minut jeśli nie mniej, reszta to wypełniacze i luźno powiązane z tematem historie,

  • OK, że Twoja firma szuka developerów, ale zapraszamy do zostania partnerem konferencji

  • tak, istnieje rodzaj prezentacji, w której celem jest wciągnięcie uczestnika w ciekawą historię i dostarczenie mu rozrywki - jako mentor ścieżki Soft Skills mam na nią inny pomysł; ma ona dostarczać wartość, rzeczy które będziesz mógł wykorzystać w swojej pracy; rozrywkę zapewni Ci before/after party

Poniżej zamieszczam kilka wskazówek, jak przygotować talk/warsztat w nowej formule

Daj się zgooglować

Zminimalizuj część związaną z przedstawianiem się. W ciągu 12 minut naprawdę nie ma na to czasu. Jeśli z Twojej prezentacji uczestnicy dowiedzą się wyłącznie kim jest prelegent i czym się zajmuje, będzie to dla nich zerowa wartość. No, chyba, że jesteś sławnym piłkarzem czy kimś tego pokroju. Aczkolwiek, o ile się orientuję, nie mamy budżetu na takowych.

Daj się więc zgooglować. Zadbaj o swoje profile: LinkedIn, Twitter, GitHub, FB i pozwól uczestnikom samodzielnie podjąć decyzję, czy chcą się dowiedzieć o tobie czegoś więcej

Single Responsibility Principle

Skup się na JEDNEJ rzeczy. Jeśli potrzebujesz głębszej inspiracji w tym temacie - przeczytaj TĘ KSIĄŻKĘ.

Lepiej dla uczestnika jeśli z Twojej prezentacji dowie się "wszystkiego o czymś" niż "coś o wszystkim".

Sformułuj take away

Jeśli przedstawiasz jakąś ideę, to uczestnik wychodzący z Twojej prezentacji musi mieć bardzo konkretną odpowiedź na pytanie: "I co ja mam teraz zacząć robić?". To jest "take away" z prezentacji. W związku z tym dokładnie przemyśl: czego uczestnik ma się nauczyć albo na jakie pytanie ma znaleźć odpowiedź w trakcie słuchania Twojej prelekcji.

Rób to, co mówisz

Gdy prowadzisz warsztat na temat autoprezentacji, to prezentuj się zgodnie z tym, co prezentujesz...Trudno o gorszy fail niż mówienie jednego, a robienie czegoś innego. To tak jakbyś krzyczał do kogoś: "Nie krzycz na mnie!".

Pamiętaj, że słowa uczą a przykłady pociągają. Na warsztacie oprócz tego, co powiesz, ważne jest również czy stosujesz względem uczestników to, o czym opowiadasz. Ludzie więcej uczą się przez obserwację niż poprzez przyswajanie treści. Zatem rób to, co mówisz.

Tak, to jest trudne

Przygotowanie i poprowadzenie wartościowej prezentacji 12 min. jest trudniejsze niż talk 1h. W trakcie godzinnej prezentacji możesz "zarzucić" słuchaczy dużą ilością informacji na różnym poziomie szczegółowości. A jeśli dodatkowo przepleciesz je dobrymi historiami albo żartami, uczestnicy będą mieli wrażenie, że "było dużo i było fajnie". Niestety jest to tylko wrażenie.

W ciągu 12 min. tak się nie da. Albo przekażesz konkret albo od razu widać, że "król jest nagi".

Przetestuję na sobie

Jako pomysłodawca tego eksperymentu, przetestuję go na sobie pierwszej kolejności. Poprowadzę pierwszą prezentację na ścieżce, więc jeśli coś ma pójść źle, to zbiorę feedback jako pierwszy i będziesz miał chociaż chwilę na wprowadzenie poprawek do swojej prezentacji :)

Jeśli nie będziemy mieli wystarczającej ilość zgłoszeń, aby zapełnić agendę, poprowadzę również 60 min. warsztat.

Wizja ścieżki na 2019

Od dłuższego czasu marzy mi się poprowadzenie takiej prezentacji, aby uczestnicy mogli dawać mi feedback w czasie rzeczywistym. Wyobrażam to sobie tak:

  • prowadzę prezentację, a na ścianie wyświetla się wykres z poziomem zainteresowania uczestników słuchających wystąpienia
  • każdy z uczestników może na bieżąco np. poprzez apkę mobilną oznaczać swój poziom zainteresowania tym, co mówię np.: czerwony, żółty, zielony
  • moim zadaniem jest takie modyfikowanie sposobu prowadzenia on-the-fly, aby maksymalizować satysfakcję uczestników
  • mam nadzieję, że ten pomysł uda się zrealizować na przyszłym roku
  • proponuję następujące MVP: tylko moje wystąpienie poprowadzone w ten sposób albo tylko dla chętnych