Dzielenie funkcjonalności raz jeszcze

Prawie dokładnie dwa lata temu napisałem post nt. wielkości funkcjonalności. Post był krótki i treściwy, ale po dwóch latach w sposób równie krótki i równie treściwy muszę dokonać pewnej modyfikacji tego, co w nim napisałem.

Otóż jak najbardziej prawdą jest, że w ramach iteracji powinniśmy realizować funkcjonalności, których wielkość jest nie większa niż jedna iteracja. Doświadczenie dwóch lat nauczyło mnie jednak, że nie jest optymalne mówienie, iż każda z tych funkcjonalności musi dostarczać wartość dodaną dla klienta. Powinno się mówić o tym, że każda z funkcjonalności (w tym takie po podziale) powinny dostarczać wartość dodaną dla właściciela produktu (Product Managera). Czy to robi różnicę? Subtelną, ale jednak robi. Różnica ta polega na tym, że właściciel produktu nie koniecznie jest klientem (aczkolwiek może nim być). Zdarzyło mi się w mojej praktyce spotkać się z przypadkami, kiedy klient końcowy jako wartość dodaną dla siebie widział tylko i wyłącznie coś, co jest efektem końcowym całego projektu. Po prostu z punktu widzenia klienta końcowego żaden z elementów pośrednich, będących efektami poszczególnych iteracji nie powoduje, że biznes klienta zacznie lepiej działać i przynosić lepsze efekty. Dlatego czasami trudno tu jest mówić o wartości dodanej poszczególnych iteracji. Z punktu widzenia klienta takowych po prostu nie ma.

Natomiast wartość dodana z punktu widzenia właściciela produktu może być trochę inną wartością dodaną niż z punktu widzenia klienta. Na przykład posiadanie części rozwiązania może być dla właściciela produktu wartością, bo wie, że jest bliżej całości rozwiązania. Natomiast z punktu widzenia klienta to nie ma żadnego znaczenia, bo jemu wartość przynosi tylko i wyłącznie rozwiązanie w całości.

Nauka z tego taka, że w planowaniu zwinnym jeżeli istnieje ktoś taki jak właściciel produktu to planowanie odbywa się z oparciu o jego definicję wartości i on odpowiada za definiowanie funkcjonalności. I to właściciel produktu odpowiedzialny jest za to, aby koniec końców produkt dostarczał wartość dla klienta ostatecznego.

Uwaga!!! Klient i właściciel produktu w niektórych przypadkach to może być jedna i ta sama osoba, wtedy oczywiście cały ten post i tłumaczenie ma mały sens.

I na koniec jeszcze jedno spostrzeżenie. Gdyby nie praktyczna próba zastosowania agile nigdy nie spotkałbym się z taką sytuacją i nigdy nie przypuszczałbym, że wartość dodana dla klienta może w pewnych wypadkach być tak trudna do zastosowania. Ale od czego jesteśmy zwinni (agile). W sposób agilowy dostosowaliśmy się do panujących warunków. Zastanawiam się tylko jak by się w takiej sytuacji zachowali reprezentanci nurtu "agile ortodoksyjny"?

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?

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.

Co to jest to Agile Project Management?

Jak w największym skrócie wytłumaczyć czym jest zwinne zarządzanie projektami (Agile Project Management)? Odpowiedź w szczegółach będzie inna w zależności od tego do kogo ma być skierowana. W jednym zdaniu powiedziałbym tak:

Dla organizacji, działających w warunkach, w których istnieje niepewność dotycząca technologii bądź wymagań klienta, Agile Project Management jest klasą metod zarządzania projektami pozwalającą,w odróżnieniu od innych, na natychmiastowe rozpoczęcie, uporządkowane poprowadzenie i zakończenie z sukcesem projektów kierując sie cały czas przepływem wartości dodanej dla odbiorcy produktów projektu.*

Miejscem, gdzie metody zwinne znajdują najlepsze zastosowanie są te środowiska, w których występuje niepewność. Na przykład wszelkiego typu projekty innowacyjne lub projekty dla bardzo szybko zmieniających się rynków (internet, „nowe media”). W takich wypadkach nie ma możliwości dokładnego zaplanowania całości projektu w sensownym czasie. Mamy więc klasyczny dylemat: albo planujemy dokładnie (bo tak jest bezpiecznej) i odkładamy start projektu w nieskończoność albo zaczynamy działać szybko (bo tak wymaga rynek) w oparciu o niepełne plany. Metody zwinne rozwiązują ten potencjalny konflikt dając zestaw narzędzi pozwalający na rozpoczęcie projektów w nie będąc pewnym całego planu osiągnięcia celów projektu. Co więcej dają możliwość usystematyzowania prac nad takim projektem w sposób, który gwarantuje, że zespół mimo braku posiadania pełnego planu pozostanie na właściwej drodze i będzie wykonywał właściwe zadania.

Metody zwinnego zarządzania projektami są tak skonstruowane, że mimo braku pewności co do dróg osiągnięcia celów projektu jeden parametr jest cały czas w punkcie skupienia zarówno kierownictwa projektu jak i każdego członka zespołu. Tym parametrem jest przepływ dodanej wartości biznesowej dla odbiorcy produktów projektu (klienta). Ta jedna cecha stanowi, że w połączeniu z elastycznością tego rozwiązania projekty realizowane metodami zwinnymi mają zdecydowanie większe szanse zakończyć się sukcesem. Klient jest zaangażowany w cały proces decyzyjny w projekcie zwinnym. Zespół projektowy realizując projekt ściśle odpowiada na potrzeby klienta dostarczając mu dokładnie te elementy, które stanowią realną wartość dodaną dla klienta. Takie podejście powoduje, że z jednej strony zespół projektowy uczy się co ma a co nie ma wartości w danym projekcie, z drugiej odbiorca produktu (klient) doskonale wie, że będzie dostawał dokładnie to, co dla niego jest wartościowe a nie to co wartościowe jest dla zespołu projektowego.

Na koniec rzecz wcale nie najmniej ważna, którą zawsze lubię podkreślać. Zarządzanie zwinne projektami, poprawnie zaimplementowane, oprócz opisanych wcześniej realnych zalet biznesowych ma jedną niepowtarzalną zaletę ludzką: zespoły projektowe po prostu lubią pracować tą metodą. Jakie są tego powody tłumaczyłem tutaj. A możliwe implikacje biznesowe przedstawiałem nie swoimi słowami tutaj.

*Dodatkowy warunek konieczny: produkty projektu można dostarczać w postaci inkrementacyjnej. To oznacza, że funkcjonalność, którą spodziewamy się dostać w ramach całego projektu powinna być możliwa do podzielenia na tak małe części, aby każdą z nich dało się wykonać w ramach jednej, dość krótkiej (2-6 tygodni), iteracji.

Metody zwinne w organizacji "stabilnej" cz. 4

Dzisiaj po raz ostatni napiszę o tym dlaczego stabilne organizacje przechodzą na zwinne zarządzanie projektami. Powód, który zostawiłem na koniec jest dość kontrowersyjny, choć jednocześnie jest dość często wymieniany przez managerów z firm, które wdrożyły zarządzanie zwinne projektami.

Powodem, dla którego przechodzi się na zarządzanie zwinne jest często chęć przestawienia organizacji z nastawienia czysto technicznego na nastawienie biznesowe. Tradycyjny paradygmat zarządzania przyłożony do organizacji produkujących bardzo zaawansowane technicznie produkty takie jak na przykład oprogramowanie powoduje bowiem, że wewnątrz organizacja zaczyna skupiać się na technice podczas gdy na zewnątrz powinna skupiać się na zaspokajaniu biznesowych potrzeb klienta. Inżynierowie pracujący w organizacjach zarządzanych tradycyjnie przez większość swojego czasu zastanawiają się jak rozwiązać problem techniczny a nie problem biznesowy klienta. Wbrew pozorom to nie to samo. W niektórych firmach powstają wręcz specjalne działy analityków, których jedynym zajęciem jest przekładanie wymagań biznesowych na wymagania techniczne. Założenia za tym stojące są takie, że inżynierowie nie mogą zrozumieć wymagań biznesowych a z drugiej strony, że klient nie jest w stanie pojąć techniki. O ile to drugie być może jest prawdziwe to zarządzanie zwinne projektami całkowicie odrzuca założenie pierwsze.

Całe proces zarządzania zwinnego został tak stworzony by na każdym etapie dbać o klienta. Inżynier pracujący nad projektem głównie rozwiązuje problemy klienta i spełnia jego wymagania. Każde działanie zespołu projektowego jest podporządkowane wypełnieniu wymagania funkcjonalnego klienta. Wymagania funkcjonalne zaś są reprezentacją wartości dodanej dla klienta, czyli tego, za co firma realizująca projekt dostaje pieniądze. Takie podejście pomaga inżynierom skupić się na rozwiązywaniu realnych problemów klientów a nie problemów technicznych, które często są ciekawe i interesujące ale w żadnym razie nie przyczyniają się do znacznej poprawy funkcjonalności produktu.

Kolejną cechą pomagającą zespołowi projektowemu nastawić się na rozwiązywanie potrzeb klienta jest sposób zapisywania wymagań i idący za tym stały kontakt z klientem. W projektach zwinnych zakłada się, że wymagania pierwotnie spisywane są na dość dużym poziomie ogólności. Następnie są one uszczegółowiane podczas bieżących kontaktów z przedstawicielami klienta. Jak już kiedyś wspominałem rozwiązuje to problem kodowania i dekodowania informacji – osoby implementujące wymagania na bieżąco i bezpośrednio od klienta dostają informację o tym jak będzie wykorzystywana zlecona funkcjonalność. Otrzymywanie tych informacji bezpośrednio od klienta z pominięciem zespołu analityków oznacza lepszy kontakt z rzeczywistym światem klienta i zdecydowanie lepszą komunikację. Doświadczenie projektów prowadzonych metodami zwinnymi wskazuje, że ilość niepoprawnie (z punktu widzenia klienta) działających funkcji produktu jest nieistotnie mała. Oczywiście wszystko to pod warunkiem, że klient zgodzi się poświęcić swój czas na intensywną komunikację z zespołem projektowym – zwykle nie ma z tym jednak problemu, gdyż w zamian uzyskuje zdecydowaną korzyść w postaci lepiej przemyślanego produktu.

Dużą rolę w skupieniu na kliencie odgrywają przeprowadzane po każdej iteracji prezentacje działającego produktu. Podczas tych prezentacji klient może i powinien sam używać produktu wytworzonego do tej pory w projekcie. Najłatwiej jest to zrobić w przypadku oprogramowania komputerowego, gdzie po prostu klient dostaje do ręki klawiaturę i myszkę. Może w pełni korzystać ze wszystkich funkcji, które miały być wyprodukowane we właśnie zakończonej iteracji. NA tym samym spotkaniu obecni są także członkowie zespołu projektowego, którzy na żywo widzą, w jaki sposób klient używa ich produktu. Takie spotkania bardo pomagają ustawić właściwą perspektywę biznesową wśród zespołu. Szczególnie, że odbywają się relatywnie często. Zdarzało się wielokrotnie, że zespół widząc jak ich klient używa produktu proponował rewolucyjne zmiany w produkcie wielokrotnie upraszczające sposób użycia i w efekcie pozwalające klientowi pracować dużo bardziej efektywnie.

Na koniec mała uwaga: w żaden sposób nie chcę tutaj dowieść, że tradycyjnie zarządzane projekty nie są nastawione pro-kliencko. Twierdzę jedynie, że metody zwinne wydatnie pomagają skupić się na rozwiązywaniu faktycznych problemów klienta, komunikacji z klientem oraz na sposobie, w jaki faktycznie będzie wykorzystywany produkt końcowy.

Skąd się biorą wymagania?

Pytanie nieskomplikowane, odpowiedź zwłaszcza w świetle tego, o czym pisałem wcześniej powinna być oczywista: od klienta. Niestety. Odpowiedzi oczywiste nie zawsze są prawdziwe.

Najpierw trzeba się dobrze zastanowić, kto to jest klient. Klient jest osobą, która zamawia i płaci za nasz produkt. Jeżeli działamy w ramach projektów wewnętrznych zamiast klienta jest tzw. właściciel produktu, czyli osoba, która odpowiada za stworzenie nowego produktu. Płacą zaś za niego tak naprawdę klienci docelowi, którym właściciel produkt sprzedaje. Umówmy się, że niezależnie od tych sytuacji wszystkie te osoby będę nazywał klientami.

Pytanie jest następujące: czy klient ma dobrą wiedzę o tym potrzebnych funkcjonalnościach produktu? Zdarza się, że tak. Ale w ogólnym przypadku klient nie zawsze jest tym, który produktu używa. Na przykład w dużych korporacjach software jest zwykle kupowany przez dział IT a potem wdrażany w całej firmie. Czy dział IT (klient) naprawdę wie jakie funkcjonalności powinien mieć program? Nie. O funkcjonalnościach najwięcej wie użytkownik końcowy, czyli ten, który oprogramowanie będzie używał w swojej codziennej pracy.

Co więcej często dość naturalne jest, że istnieje pewnego rodzaju różnica zdań pomiędzy spojrzeniem na wymagania od strony klienta a od strony użytkownika końcowego. Załóżmy, że tworzone jest nowe oprogramowania do zarządzania projektami w dużej firmie. Używać go będą oczywiście kierownicy projektów oraz wszyscy zaangażowani w projekty w firmie. Zamawia go (klientem jest) jednak albo centralny dział IT albo szef działu zarządzania projektami. Z ich punktu widzenia priorytet będą miały takie wymagania jak: bezpieczeństwo danych, łatwość instalacji, łatwość zdalnego zarządzania, przeglądanie sytuacji wielu projektów, raporty z pracy poszczególnych kierowników projektów, kontrolowanie zasobów firmy w kontekście wielu projektów itp. To są funkcjonalności, które oni potrzebują. Czy te wymagania stanowią jakąkolwiek wartość dodaną dla zarządzania projektami w firmie? Wątpliwą. Użytkownicy końcowi potrzebują: łatwości planowania projektów, pomocy w harmonogramowaniu, łatwości przydzielania zasobów, automatyzacji przydzielania zadań, łatwości śledzenia postępu prac (dla kierowników), prostej i szybkiej metody raportowania postępu prac (dla wykonawców), ostrzeżeń o nieprawidłowościach w projekcie. Jeszcze raz: czy system spełniający wymagania klienta ale nie implementujący wymagań użytkownika końcowego będzie miał rzeczywistą wartość dodaną dla organizacji?

Czy w związku z tym wszystkie napisane we wcześniejszych wpisach słowa o kreowaniu wartości dla klienta nie są prawdziwe? Czy nie powinno chodzić o wartość użytkownika? Nie, bo mówimy o dwóch różnych rzeczach. Nie można porównywać jabłek z gruszkami. Klient płaci za produkt, więc to on domaga się za płacone pieniądze dostarczenia wartości dodanej dla siebie. Tylko za tą wartość zapłaci. Wartość ta tworzona jest poprzez implementację funkcjonalności potrzebnej użytkownikom końcowym produktu (wartość dla użytkownika końcowego powinna przekładać się na wartość dla organizacji). Jednak to klient ma ostateczny głos za co chce płacić a za co nie. On też decyduje o tym, które elementy z jego punktu widzenia są najbardziej potrzebne a które mniej. Jeżeli klient zadecyduje, że jego wymagania mają większą wartość niż wymagania użytkowników i trzeba je zaimplementować to jest jego suwerenna decyzja. Etyka zawodowa nakazywałaby jednak poinformować go o potencjalnym konflikcie takim jak opisany wcześniej.

Tak więc jak w projektach zwinnych powinno wyglądać ustalanie co tak naprawdę produkujemy? Wymagania zbieramy od użytkowników końcowych. Priorytety ustalamy z klientem. Proste.

Planowanie a wartość dla klienta

Pamiętam jak dziś, że kiedy mój znajomy objawił mi prawdę o tym kto płaci mi pensję dość długo nie mogłem wyjść z szoku. W każdej komercyjnej firmie jest bowiem tak, że koniec końców pensję płaci pracownikowi płaci nie firma, w której jest on zatrudniony, ale klient tej firmy. Żadna firma na świecie (oprócz mennicy państwowej) nie ma maszynki do produkcji pieniędzy, każda z nich pieniądze bierze od swoich klientów. Dlatego niezależnie od zajmowanego w firmie stanowiska każdy pracownik powinien dążyć do tego, aby jego firma produkowała wartość dodaną dla klientów. Jeżeli bowiem tej wartości nie będzie to wkrótce nie będzie też ani klientów ani pracy.

Ta zdroworozsądkowa zasada została wbudowana w podejście zwinne do zarządzania projektami. Jedną z wartości zwinnego zarządzania jest "działający produkt ponad kompleksową dokumentację". Po prostu nie ma na świecie klienta, który zapłaciłby realne pieniądze za dokumentację rewelacyjnego systemu, który ma tylko tą jedną wadę, że nie istnieje. Dużo więcej klientów jest w stanie zapłacić za działający system, nawet jeżeli nie byłby tak rewelacyjny a jedynie w dobry sposób spełniał podstawową potrzebę. Pojęcie wartości dla klienta przewija się przez procesy zwinnego zarządzania w wielu miejscach: wybór funkcjonalności do iteracji, prezentacja wykonanej funkcjonalności, określanie wizji, spekulacja na temat osiągnięcia wizji - wszystkie te czynności są oparte o ideę dostarczania klientowi wartości dodanej.

Jednym ze szczególnych elementów związanych z zarządzaniem projektem jest planowanie podziału dużego projektu na mniejsze, ściśle określone części, które zespół projektowy będzie wykonywał a zarządzający projektem będą nadzorować śledząc tym samym postęp prac. W tradycyjnych metodach zarządzania projektami stosuje się do tego tzw. WBS, czyli strukturę podziału pracy (Work Breakdown Structure). W zarządzaniu zwinnym do tego samego służy FBS, czyli struktura podziału funkcjonalności (Feature Breakdown Structure). Jaka jest różnica? Otóż taka, że elementem końcowym w WBS jest zwykle pewna czynność do zrobienia. W FBS jest to pewna testowalna funkcjonalność. Już widzicie różnicę? W tym drugim przypadku ponieważ mowa o pewnej funkcjonalności zawsze jednocześnie można powiedzieć o pewnej zwiększonej wartości dodanej dla klienta. W procesach zwinnych dzieli się i śledzi postępy w dostarczaniu wartości dodanej dla klienta. W procesach tradycyjnych śledzi się postęp w wykonaniu prac. Niby mała różnica a jednak.

Przekonałem się o tym parę dni temu, kiedy oglądałem plan pewnego potężnego projektu. Zrobiony w miarę poprawnie WBS obejmował lekko ponad 2000 (dwa tysiące) zadań atomowych. Przejrzałem je wszystkie. Pominąwszy oczywiste i pozostawione bez odpowiedzi pytanie jak zarządzać 2000 zadań atomowych rzuciło mi się w oczy jeszcze jedno. Otóż zadania te były tak skonstruowane, że w ogóle nie wynikało w którym momencie powstawała jakakolwiek wartość dodana dla klienta. Próbowałem znaleźć w tym WBSie zadania, po skończeniu których mógłbym powiedzieć że w tym momencie wartość systemu dla klienta wzrosła. Niestety takich zadań nie było. Jedynym miejscem był kamień milowy "produkt działa u klienta" - to w miarę oczywiste. Niesamowite jest dla mnie to jak można zarządzać dostarczaniem systemu podzielonego na 2000 zadań, razem ponad 20000 godzin pracy inżynierów różnych specjalności i podczas całego tego czasu wiedzieć tylko ile pracy zostało wykonanej. A nie wiedzieć jaka wartość została dostarczona dla klienta. Oczywiście próbowano to robić przy użyciu analizy EVA, ale moim zdaniem to nie wystarczało. W jaki sposób wiedza ile trwało i czy skończyło się zadanie "analiza technologii X"przekłada się na wiedzę ile wartości dostarczyliśmy dla klienta? W przypadku posługiwania się FBS taka wiedza byłaby dostępna natychmiast. O samym FBS napiszę więcej następnym razem - dzisiaj już się za długo rozpisałem.

Weźcie kiedyś jakiś dostępny dla Was plan projektu i prześledźcie go. Zobaczcie czy z poszczególnych elementów planu wynika że projekt dostarcza wartość dodaną dla klienta. Czy możecie kontrolować proces dostarczania tej wartości? Czy możecie mierzyć postępy dostarczania wartości dla klienta? Analizując ten plan ani na moment nie zapominajcie kto tak naprawdę płaci Wam pensję.