Co ma wspólnego Evidence Based Management i Predator?

W moim artykule w ostatnim wydaniu Strefy PMI, w oparciu o historię lekarza z wiedeńskiej kliniki Ignáca Semmelweisa, podkreśliłem znaczenie podejmowania decyzji opartych na solidnych faktach i dowodach, a także omówiłem ruch społeczny związany z Evidence Based Management (dalej EBM). Tych, którzy jeszcze nie czytali serdecznie zachęcam do nadrobienia zaległości. W poniższym materiale zagłębię się w szczegóły frameworku EBM opracowanego przez Scrum.org. W moim odczuciu jest on niezwykle ciekawy i przydatny, gdyż znacząco wspiera zarządzanie organizacją i produktem. W jaki sposób? Odpowiedzi jest kilka: promuje ciągłe doskonalenie (continuous improvement), realizuje model biznesowy oparty na zarabianiu jak największej ilości pieniędzy (business outcomes) poprzez zwiększanie wartości biznesowej klientów oraz użytkowników (customer/user outcomes).

Od wiedeńskiej kliniki po scrumowe zespoły. Jak powstawał Evidence Based Management?

Kiedy słyszymy termin Evidence Based Management (dalej EBM), możemy natknąć się na dwa główne znaczenia tego pojęcia. Pierwsze odnosi się do ruchu społecznego, drugie jest bardziej specyficzne i związane z frameworkiem zaproponowanym przez Scrum.org. Evidence Based Management w pierwszym znaczeniu to ruch społeczny, który ma na celu skłonienie ludzi zarządzających do podejmowania decyzji opartych na rzetelnych dowodach. Celem jest unikanie podejmowania decyzji bazujących jedynie na intuicji, przeczuciach czy osobistych przekonaniach, a zamiast tego kierowanie się sprawdzonymi informacjami i danymi.

Siedem znaczeń Kanbana

Podobno kiedyś Konfucjusz powiedział: „Naprawa państwa zaczyna się od naprawy pojęć”. Nikt nie jest pewien, czy naprawdę to powiedział, ale co ważne, chciałbym dzisiaj sprecyzować znaczenie słowa „kanban”. Bardzo często ludzie interpretują to na własny sposób, i kiedy dwie osoby rozmawiają na ten temat, mają na myśli dwie zupełnie różne rzeczy.

Scrum + UX to połączenie doskonałe!

U moich klientów czasami widzę, że UX jest traktowany po macoszemu. Na poziomie deklaracji mówi się, że UX jest ważny, jednak w praktyce główny nacisk kładzie się na prace inżynieryjne i rozwiązania techniczne. Kwestie takie jak design produktu, spełnianie potrzeb przyszłych użytkowników, wizja biznesowa czy w ogóle zasadność produktu są na drugim planie.

Projekt czy Produkt? Oto jest pytanie!

Pracowałem przez ostatnie 11 lat z najróżniejszymi firmami, od malutkich software house’ów, poprzez korporacje, aż po ministerstwa. Niestety w większości przypadków spotykam się z charakterystycznym problemem, nazywam go syndromem myślenia projektowego. Jest to przeciwieństwo do jak najbardziej pożądanego myślenia produktowego.