sobota, 31 maja 2008

Wieloprojektowość

Wyobraźcie sobie szpital, w którym operuje się chorych. Teraz kierownictwo tego szpitala, jako że chce skutecznie i szybko leczyć swoich pacjentów nakazuje aby natychmiast jak tylko pojawi się pacjent kierować go na potrzebną mu operację. Pomyślcie co się zaczyna dziać na salach operacyjnych. Jak jest jeden czy dwóch pacjentów to jest jeszcze dobrze, potem zaczyna być ich coraz więcej (kierowani są na operacje od razu jak tylko się pojawią). W końcu jest ich więcej niż zespołów lekarzy chirurgów i sal operacyjnych. Co w tym momencie robi kierownictwo szpitala? Nakazuje, żeby jeden zespół lekarzy wykorzystujący jedną salę operacyjną jednocześnie robił kilka operacji. Przecież Ci lekarze to świetni specjaliści, na pewno jakoś dadzą radę. Tak więc zaczyna się dzielenie czasu. Nad jednym pacjentem godzina, potem godzina dla drugiego. W miarę jak rośnie ich liczba zaczyna się problem z dostępnością sal operacyjnych. Anestezjologów zresztą też brakuje. W związku z tym tworzymy listy dostępności sali wraz ze ścisłym harmonogramem, który chirurg kiedy operuje którego pacjenta a który anestezjolog gdzie asystuje. Sale są dokładnie na godziny, więc nie można się spóźniać. Problem w tym co chirurdzy mają robić w czasie, gdy nie mogą operować swojego pacjenta, bo sala jest zajęta. Najchętniej by poczekali, ale szefostwo szpitala nie chce marnować drogocennego czasu chirurgów. Przecież to są świetni specjaliści i nie mogą w pracy spędzać "nieproduktywnych" godzin. W związku z tym szefostwo nakazuje chirurgom robić obchody w czasie jak ich (już "rozpoczęty") pacjent czeka na wolną salę. Skutek jest taki, że przestają zdążać na swój czas w harmonogramie dostępności sali, bo nie mogą się oderwać od obchodów. A jak już przyjdą i zaczną operować to jak tylko się dobrze "wdrożą" w danego pacjenta okazuje się, ze muszą go zostawić, bo w harmonogramie skończył się czas dostępności dla nich sali operacyjnej. Anestezjolodzy mają podobny problem.

Jesteście oburzeni takim podejściem? Kto by się chciał tam leczyć?

Teraz proszę podstawicie sobie w powyższym przykładzie zamiast "pacjent" to "projekt", zamiast "chirurg" to "programista" a zamiast "sala operacyjna" to "serwerownia" (czy dowolny inny zasób, który jest wystarczający rzadki w Waszym środowisku). Brzmi znajomo? Nikt nie zadaje pytania "kto by kupił projekt od takiej organizacji"?

Ciekawe jest, że branża medyczna, jakkolwiek niedoskonała, już od dawna potrafi sobie radzić z taką sytuacją. W prosty sposób: dedykowane zespoły, priorytetyzacja wykorzystania kluczowych zasobów (najpierw ten co ma życie zagrożone a potem ten co operacja plastyczna), kolejkowanie pacjentów zamiast współbieżności. Śmiem twierdzić, że nawet w Polsce statystyki sukcesów są dużo lepsze dla operacji medycznych niż dla projektów, w tym zwłaszcza projektów innowacyjnych. Znaczy, że takie rozwiązania działają. Teraz wypadałoby podpatrzyć czy u nas nei da się tak samo. I tutaj niespodzianka. Zarządzanie zwinne bardzo podobnie podchodzi do portfolio projektów jak szpital do operacji. To znaczy: zespół jest dedykowany do jednego projektu (nie wolno pożyczać ludzi), projekty robi się jeden po drugim a nie współbieżnie, a priorytety zapewnia właściciel produktu. Czyli podobnie. Ciekawe, dlaczego skoro w branży medycznej te zasady uznajemy za taką oczywistość w projektach już nie.

niedziela, 25 maja 2008

Sztuka odmawiania

Innovation is not about saying yes to everytnig. It's about saying NO to all but crucial features.

Innowacja nie polega na akceptowaniu wszystkiego. Polega na odrzucaniu wszystkich oprócz absolutnie niezbędnych funkcjonalności

Kto to powiedział? Steve Jobs. Kto jak kto, ale on akurat wie co to innowacyjność. Przeczytałem to zdanie w doskonałej zresztą książce "Getting Real". I mnie olśniło. To jest aż tak proste a jednocześnie aż tak skomplikowane do zastosowania. Innowacja jest czymś, co w absolutnie nowy sposób rozwiązuje istniejący, konkretny problem świata rzeczywistego. Dlatego nie jest sztuką wymyślać tysiące nowych funkcjonalności naszego produktu, które kiedyś, być może zostaną użyte przez pół promila użytkowników. Sztuką jest tak wymyślić kilka podstawowych rzeczy tak, aby wnosiły one istotne zmiany w życie naszych klientów. Parafrazując to, co kiedyś pisał na swoim blogu Alex Barszczewski chodzi o to, aby za pomocą 4% rzeczy osiągnąć 64% rezultatów (podwójna zasada Pareto). Teraz prawdziwa trudność polega na tym, że nie tylko trzeba potrafić wytworzyć te 4% co spowoduje 64% oczekiwanej wartości dodanej, ale także, a w zasadzie przede wszystkim, należy te właśnie 4% wprowadzić do produktu jako pierwsze. Jeszcze więcej: w zasadzie powinno się wprowadzić tylko te 4% i nie martwić się o resztę. Pomyślcie, jeżeli 4% naszej funkcjonalności generuje 64% wartości dodanej dla klienta ostatecznego to jak bardzo uzasadnione ekonomicznie jest tworzenie pozostałych 96%???

Jeżeli takie podejście jest słuszne (brzmi logicznie), to oznaczałoby, że posiadanie skutecznego sposobu ustalania co jest a co nie jest ważne z punktu widzenia klienta ostatecznego naszego produktu jest dla firmy kluczem do tego, czy jest ona innowacyjna czy nie. Innymi słowy nawet ponadprzeciętna zdolność do wytarzania produktów będzie mało przydatna i/lub nieefektywna ekonomicznie, jeżeli nie będziemy wiedzieli co wytworzyć oraz gdzie zatrzymać się w naszym tworzeniu. Znów są to pytania warte miliony. Krótka analiza i przeszperanie pamięci wykazało, że metody zwinne mają mechanizm wyboru funkcjonalności zaimplementowany same w sobie. Opisywałem go tutaj. Czy jest wystarczający? Kiedyś myślałem, że tak. Teraz jak już jasno widać jak bardzo kluczowy jest to proces zaczynam mieć wątpliwości, czy nie mógłby on być zastąpiony czymś skuteczniejszym. Mimo wszystko, sam fakt że istnieje on, choćby w szczątkowej formie, oznacza , metody zwinne wspierają innowacyjność. W odróżnieniu od metod, które na wartość biznesową uwagi nie zwracają żadnej.

Zadanie domowe do przemyślenia: jaki jest w Twojej organizacji system (tak, system – to jest zbyt ważne, aby opierać się tylko na przeczuciu jednej czy drugiej osoby) określania tego, co wnosi jak dużą wartość dla Waszych klientów?

sobota, 17 maja 2008

Zwinne zarządzanie zmianą w organizacji

Parę tygodni temu obyłem inspirującą rozmowę z pewnym ciekawym człowiekiem. Rozmawialiśmy na temat projektu wprowadzenia zmian organizacyjnych w bardzo dużej firmie. Zmiany miały być na wielką skalę. Na tyle wielką, że projekt musiał być realizowany w etapach. Na sam koniec rozmowy poprzez tematykę etapów zeszło na metody skutecznego zarządzania takim projektem. Jedną z rozważanych hipotez stało się użycie metod zwinnych do zarządzania tymże projektem.

Na pierwszy rzut oka pomysł wydaje się być totalnie pozbawiony sensu. Podstawowym założeniem wszystkich metod zwinnych (wszystkiego co nazywa się agile) jest iteracyjne dostarczanie działającego produktu. Działającego produktu. A my mówimy o projekcie wprowadzenia zmian organizacyjnych. Więc nie spełniamy podstawowego założenia. Drugim założeniem bardzo ważnym dla metod zwinnych jest koncentracja na przepływie wartości dodanej dla klienta, której emanacją są definicje funkcjonalności. Dlatego w projektach zwinnych nie definiuje się struktury podziału pracy tylko strukturę podziału funkcjonalności produktu końcowego. Bo to ukończona funkcjonalność niesie wartość dodaną a nie praca wykonana. Znowu więc na pierwszy rzut oka nijak ma się to do wprowadzania zmian organizacyjnych w firmach. A na drugi rzut oka?

Załóżmy przez chwilę, że organizację jako całość traktujemy jako produkt. Klientem na ten produkt jest właściciel organizacji lub jego przedstawiciel (zarząd). Tenże produkt przynosi właścicielowi korzyści biznesowe (zwykle wyrażone dość konkretnie w pieniądzach). Aby te korzyści przynosić tenże produkt posiada zestaw funkcjonalności, pewnych działań realizowanych przez organizację, które to działania, każde z nich, ma pewną wartość dla klienta. Jeżeli by tej wartości nie miało to klient (właściciel) już dawno wyrzuciłby to działanie ze swojego produktu (organizacji).

Przy takim spojrzeniu nie ma przeszkód, aby zarządzać projektem zmian organizacyjnych przy użyciu metod zwinnych. Klient (właściciel) definiuje jakie nowe funkcjonalności powinien mieć produkt (organizacja). Na przykład organizacja powinna mieć dedykowany dział wsparcia klienta albo organizacja powinna zarządzać projektami według metod zwinnych. To jest funkcjonalność, której brakuje a która z punktu widzenia właściciela przyniosłaby realny wzrost wartości całej organizacji. Teraz taką funkcjonalność można potraktować tak jak w projektach zwinnych: rozbić na mniejsze, nadać priorytety i wspólnie z klientem zastanowić się co wdrażamy najpierw. A następnie powołany zespół projektowy ds. zmian organizacyjnych zacząłby takie zmiany wdrażać. Produktem dostawy po każdej iteracji byłaby cała organizacja, która wykazywałaby działające kolejne elementy zdefiniowanej funkcjonalności.

Takie podejście do tematu zmian organizacyjnych po krótkim zastanowieniu wydaje się być obiecujące. Nie dość, że wydaje się być możliwe do wdrożenia to ma jeszcze dwie ważne cechy. Po pierwsze traktując organizację jako produkt z określonymi funkcjonalnościami spowodujemy, że definiując co trzeba zmienić będziemy się patrzeć na funkcjonalności właśnie a nie działania, które mamy przeprowadzić. Podobnie jak w przypadku zwinnych projektów przestajemy rozmawiać o działaniach a zaczynamy się skupiać na efektach, które te działania mają przynieść. Dzieje się tak, gdyż właściciel podobnie jak klient chce efektów a nie działań. Druga ważna sprawa wynika wprost z poprzedniej. Skupienie się na efektach oznacza, że będziemy musieli rozważać wartość biznesową każdego z nich. (każdej nowej funkcjonalności, którą będzie miała mieć organizacja). A analiza wartości biznesowej wprowadzanych zmian jest czymś, co w przypadku tradycyjnie zarządzanych projektów zmian organizacyjnych rzadko się zdarza. Potencjalnie uzyskujemy bardzo dużo.

Powyższe to czysta spekulacja, ale czy to zadziała? Zgodnie z duchem zasad projektów zwinnych teoretyczna negacja jest zabroniona. Trzeba by przeprowadzić eksperyment. Szukam chętnych. Adres email w informacji o mnie po prawej stronie.

niedziela, 11 maja 2008

Kontrakty na projekty zwinne

Ostatnie kilka tygodni spędziłem bardzo pracowicie spotykając się z wieloma bardzo interesującymi ludźmi. Stąd dłuższy brak postów na blogu. Z drugiej strony spotkania te były niezwykle interesujące i dostarczyły bardzo ciekawych spostrzeżeń.

Przykład, który mnie najbardziej zadziwił to omawiany już tu kiedyś (tutaj) „problem” kontraktów na projekty zwinne. Generalnie podczas każdej prezentacji, szkolenia czy nawet rozmowy na temat zwinnych metod zarządzania projektami prędzej czy później któryś z obecnych kierowników projektów podnosi „problem” kontraktów. Najczęściej przybiera to formę pytania „a co ja mam powiedzieć mojemu klientowi jak on zapyta ile będzie kosztował cały system”. Zwykle w takich przypadkach tłumaczę, że kontrakty na projekty realizowane zwinnie powinny być płacone inkrementalnie za wykonaną pracę, tak jak jest dostarczana funkcjonalność. Odpowiedź kierowników jest zwykle jedna: „moi klienci się na to nigdy nie zgodzą, oni chcą wiedzieć ile będzie kosztowała całość”. Dyskusja trwa długo.

Otóż tak się składa, że rozmawiałem ostatnio z kilkoma osobami, na co dzień kupującymi oprogramowanie, w tym oprogramowanie tworzone na zamówienie. Jako, że metody zwinne moim konikiem są, prędzej czy później schodziło na tą tematykę. Z wielkim zdziwieniem stwierdzałem, że idea zwinnego rozwoju oprogramowania, w tym płacenia inkrementalnego... bardzo im się (wszystkim) podobała. Jako, że byli to ludzie odpowiedzialni za pieniądze natychmiast (wszyscy) reagowali tak samo: to jest idealny sposób ograniczania ryzyka. Jeden z nich wprost od razu zapytał gdzie może znaleźć firmę, która zgodzi się na rozwój oprogramowania w taki właśnie sposób: płacenia za krótkie, ściśle zdefiniowane iteracje. Czy przeszkadza im to, że nie wiedzą ile będzie kosztowała całość? W zasadzie nie. Ewentualne kontrowersje natychmiast znikały gdy dowiadywali się, że będą mogli zmieniać definicję „całości” w dowolnym momencie, ze skutkiem z końcem kolejnej iteracji. To jest racjonalne, bo przecież zwykle oprogramowanie kupuje się nie po to, aby było „całością”, tylko po to, aby realizowało potrzeby biznesowe. Co ciekawe ludzie, którzy zlecają tworzenie oprogramowania rewelacyjnie to rozumieją. Dla nich rachunek jest prosty: kwota jaką zapłaciłem za oprogramowanie musi być (zdecydowanie) mniejsza niż korzyść wyrażona finansowo, którą ono (szybko) wygeneruje. Dlatego możliwość dynamicznego dostosowywania się do zmieniających się potrzeb i w ten sposób możliwość szybszego generowania większej korzyści jest bardzo, ale to bardzo dużą realną wartością. Więc ja się pytam o jakim „problemie” kontraktów na projekty zwinne mówią kierownicy projektów? Zadanie domowe dla nich: przy następnej rozmowie z klientem zapytajcie się czy nie zgodziliby się na kontrakt oparty o metody zwinne zarządzania projektami.

Na koniec jedna uwaga: klienci z którymi rozmawiałem są osobami wydającymi pieniądze, że które ponoszą pełną odpowiedzialność (w części są to ich własne pieniądze). Podkreślam to, bo w korporacjach, gdzie wydaje się pieniądze „budżetowe” sprawa może wyglądać zdecydowanie inaczej.

niedziela, 4 maja 2008

Dlaczego nie u nas?

Witam po miesięcznej przerwie. Co było powodem może wyjaśnię kiedy indziej. Dzisiaj coś na temat innowacyjności. Zobaczyłem i od paru dni nie mogę wyjść ze zdziwienia. Chodzi o ten filmik zaprezentowany w ramach TED Talks:
http://www.ted.com/index.php/talks/view/id/245

Dla tych którym nie chce się oglądać streszczenie: Johnny Lee pokazuje jak za pomocą bezprzewodowego kontrolera Wii (USD 40) oraz diod podczerwonych (USD 10) skonstruował interaktywny whiteboard oraz technikę trójwymiarowej prezentacji obrazu. Zwłaszcza to drugie robi niesamowite wrażenie (więcej i dokładniej tutaj).

A teraz coś co nie daje mi spokoju od kilku dni. Jaka jest przyczyna tego, że takie innowacje powstały w USA na Carnegie Mellon University a nie gdziekolwiek w Polsce? Zwykle w takich wypadkach mówi się o pieniądzach i niedoinwestowaniu nauki. Niestety, w tym wypadku ta wymówka odpada: cały sprzęt kosztował USD 50, reszta to zwykły PC & czas na napisanie software. Odpada argument finansowy, bo nie wierzę, że naszej nauki nie stać na wydatki rzędu 200 PLN. Chyba brakuje nam więc czego innego. Pamiętam jak dzisiaj, że ładnych kilka lat temu jak chciałem robić doktorat usłyszałem na mojej uczelni "ale wie Pan, doktorat to nie jest od tego, żeby rozwiązywać jakieś problemy techniczne, tylko od tego aby poszerzać dziedzinę nauki". Cóż, Johnny Lee nic nie poszerzył za to od momentu powstania prototypu w jego laboratorium do momentu komercyjnego wdrożenia minęło... 5 miesięcy (o czym niżej). Mam dziwne wrażenie, że u nas trzeba zmienić system, bo jeżeli nie potrafimy poradzić sobie z innowacją za 200 PLN to na pewno nie będziemy potrafili poradzić sobie z innowacją za 200 000 000 PLN. Czuję się wściekły i bezsilny. Jeszcze raz: jaka jest przyczyna, że to nie powstało u nas?

Ciekawe jest też w jaki sposób rzeczony Johnny Lee poinformował świat o swojej innowacji i doprowadził do jej komercjalizacji. Otóż film z doświadczenia opublikował na... Youtube (tutaj konkretnie). Koszt: USD 0 (zero). Film obejrzał człowiek z Electronic Arts. Muszę tłumaczyć do było dalej??? 5 miesięcy.

Co sprawia, że u nas tak nie można?

Odpowiedź jest warta miliardy i przyszłość naszego kraju.