VBM dawało orientację na wartość. Podejście zwinne pomogło określić sposób pracy.

W poprzednim artykule doszliśmy do ważnego rozróżnienia.

Nie trzeba przenosić całego możliwego aparatu Value Based Management, aby korzystać z logiki wartości.

Można ograniczyć zakres narzędzi, danych i formalizacji do tego, czego rzeczywiście wymaga konkretny problem właściciela.

Ale na tym problem się nie kończy.

Nawet jeżeli wiemy już, że wartość ma być punktem odniesienia, nadal pozostaje pytanie:

jak właściwie zorganizować pracę?

Można przecież bardzo dobrze wiedzieć, na co patrzeć, a mimo to analizować przedsiębiorstwo miesiącami.

Można mieć trafne kryterium oceny, ale nie mieć jasności, od czego zacząć.

Można wiedzieć, że nie trzeba analizować wszystkiego, ale nadal nie wiedzieć, gdzie postawić granicę.

Można wreszcie zebrać wiele wartościowych informacji, ale nie dojść do rezultatu, który rzeczywiście pomaga właścicielowi w dalszym rozstrzyganiu.

Perspektywa wartości była więc potrzebna.

Ale potrzebny był jeszcze sposób pracy.

Dobre kryterium nie organizuje całego procesu

Value Based Management pomaga spojrzeć na przedsiębiorstwo przez pytanie o wartość.

To bardzo ważna zmiana perspektywy.

Nie patrzymy już tylko na sprzedaż, marżę, ludzi, procesy albo klientów jako osobne obszary.

Pytamy raczej, co te elementy – razem i w określonych zależnościach – robią z wartością przedsiębiorstwa.

To pomaga wybierać to, co istotne.

Nie rozwiązuje jednak automatycznie innego problemu:

jak przeprowadzić pracę analityczną wtedy, gdy czas jest ograniczony, dane są niepełne, a właściciel potrzebuje dojść do użytecznego rezultatu.

To dwa różne pytania.

Pierwsze brzmi:

w jakiej perspektywie powinniśmy patrzeć na przedsiębiorstwo?

Drugie:

jak zorganizować pracę, skoro nie możemy analizować wszystkiego?

Właśnie w tej różnicy zaczyna pojawiać się potrzeba drugiego zasobu wiedzy.

Nie dlatego, że VBM było „za ciężkie”.

Nie dlatego, że właściciel małej firmy potrzebuje prostszej wersji zarządzania.

I nie dlatego, że zarządzanie wartością samo w sobie jest podejściem niewystarczającym.

Problem jest bardziej konkretny.

Orientacja na wartość nie przesądza jeszcze, jak długo pracujemy nad problemem, jaki zakres informacji obejmujemy, kiedy kończymy analizę i w jaki sposób przechodzimy od danych do rezultatu przydatnego właścicielowi.

To właśnie ten problem trzeba było rozwiązać osobno.

Ograniczenia nie znikają, kiedy zaczynamy analizę

W realnym przedsiębiorstwie rzadko pracujemy w warunkach pełnej informacji.

Nie wszystkie dane są dostępne.

Nie wszystkie informacje mają tę samą jakość.

Część wiedzy znajduje się w raportach i systemach.

Część pozostaje w doświadczeniu właściciela i pracowników.

Niektóre kwestie można sprawdzić szybko.

Inne wymagałyby tygodni albo miesięcy dodatkowej pracy.

Jednocześnie decyzja, przed którą stoi właściciel, często nie może czekać na moment, w którym obraz firmy stanie się kompletny.

Ten moment zresztą może nigdy nie nadejść.

Dlatego ograniczony czas nie jest wyłącznie technicznym problemem organizacyjnym.

Staje się jednym z warunków, które trzeba uwzględnić w sposobie pracy.

Ograniczony czas nie jest wartością samą w sobie.

Jeżeli staje się pretekstem do skrótów myślowych, obniża jakość pracy.

Jawne ograniczenie czasu stawia natomiast konkretne wymaganie: trzeba świadomie wybierać, co wymaga uwagi, czego jeszcze nie wiemy i jaki rezultat ma zakończyć aktualny etap pracy.

Właśnie tutaj pojawia się podejście zwinne.

Nie jako synonim szybkości.

Nie jako gotowy framework do przeniesienia do przedsiębiorstwa.

I nie jako obietnica, że wszystko da się zrobić w kilka dni.

Raczej jako źródło rygoru sposobu pracy w ograniczeniach.

Podejście zwinne wniosło inny rodzaj dyscypliny

W VBM Sprint® słowo „sprint” nie oznacza po prostu:

zróbmy to szybciej.

O tym pisałem już wcześniej.

Znacznie ważniejsze jest inne pytanie:

co zmienia się w sposobie pracy, jeżeli z góry uznajemy, że czas i zakres są ograniczone?

Poniższe elementy nie są definicją Agile. To rekonstrukcja tych jego właściwości, które zostały selektywnie wykorzystane w pierwszej integracji.

Po pierwsze, trzeba wybrać problem.

Nie zaczynamy od ambicji opisania całego przedsiębiorstwa.

Z dzisiejszej perspektywy tę funkcję można opisać jako koncentrację na tym, co właściciel próbuje rozstrzygnąć.

Jeżeli rozważa skalowanie, problemem nie jest „pełna diagnoza firmy”.

Problemem jest rozpoznanie tych zależności, które mają znaczenie dla zdolności przedsiębiorstwa do dalszego wzrostu.

Jeżeli rozważa sprzedaż, nie musi od razu wyjaśnić każdego aspektu działania organizacji.

Musi jednak lepiej zrozumieć te elementy, które mogą mieć znaczenie dla wartości, ryzyka i zdolności przedsiębiorstwa do funkcjonowania bez jego osobistego udziału.

Po drugie, trzeba ograniczyć zakres.

Nie w sensie arbitralnego odcięcia „mniej ważnych” obszarów.

Raczej poprzez ciągłe pytanie:

czy ta informacja pomaga nam lepiej zrozumieć problem, nad którym pracujemy?

Jeżeli tak – może być potrzebna.

Jeżeli nie – być może nie musi być częścią aktualnego pola analizy.

Po trzecie, trzeba zaakceptować pracę przy niepełnej informacji.

Nie oznacza to zgody na zgadywanie.

Oznacza uznanie, że nie każdą niewiadomą można i trzeba zamknąć przed dalszym ruchem.

Niektóre braki danych mogą być krytyczne.

Inne mogą pozostać jawnie otwarte.

Jeszcze inne dopiero w trakcie pracy okażą się warte pogłębienia.

Po czwarte, potrzebny jest rezultat.

Nie chodzi o to, aby „zrobić analizę”.

Analiza jest środkiem.

W dzisiejszej rekonstrukcji tej pierwszej integracji widać, że praca nie miała kończyć się samym zebraniem informacji, lecz prowadzić do użytecznego rezultatu.

Na tym etapie nie oznaczało to jeszcze obecnego, w pełni rozwiniętego rozumienia podstawy rozstrzygnięcia właściciela.

To przyszło później.

Ale już sama koncentracja na użytecznym rezultacie odróżniała pracę skończoną od nieskończonego procesu zbierania kolejnych informacji.

Po piąte, zakres pracy nie musi być od początku całkowicie zamknięty.

Jeżeli w toku analizy pojawia się nowa informacja, która zmienia rozumienie problemu, trzeba móc do niej wrócić.

Jeżeli pewien wątek okazuje się mniej istotny, nie ma powodu utrzymywać go tylko dlatego, że był częścią początkowego planu.

To nie jest brak rygoru.

Przeciwnie.

Rygor polega również na tym, aby nie chronić wcześniejszego planu kosztem lepszego rozumienia problemu.

Dwa zasoby odpowiadały na dwa różne problemy

Z dzisiejszej perspektywy funkcjonalny podział ról w tej pierwszej integracji można ująć dość jasno.

Value Based Management wnosiło przede wszystkim orientację na wartość.

Podejście zwinne wnosiło przede wszystkim rygor sposobu pracy w warunkach ograniczonego czasu, zakresu i informacji.

To rozróżnienie jest użyteczne, ale nie powinno być traktowane jako pełna definicja VBM ani Agile.

Oba źródła wiedzy są znacznie szersze.

Interesuje nas tutaj tylko ta część każdego z nich, która wykonywała konkretną pracę w powstającym rozwiązaniu.

VBM pomagało odpowiedzieć:

co jest istotne z perspektywy wartości przedsiębiorstwa?

Podejście zwinne pomagało odpowiedzieć:

jak prowadzić pracę, kiedy nie możemy analizować wszystkiego i nie chcemy czekać na pełną pewność?

Właśnie w tym miejscu zaczyna się autorska integracja.

Nie dlatego, że połączenie tych dwóch podejść było „naturalne”.

Nie dlatego, że jedno było oczywistym uzupełnieniem drugiego.

I nie dlatego, że ich zestawienie automatycznie tworzyło gotową metodykę.

Była to pierwsza odpowiedź na konkretny problem projektowy.

Jak zachować perspektywę wartości, a jednocześnie pracować w sposób ograniczony, skoncentrowany i użyteczny?

To było dopiero otwarcie.

Pierwsza integracja nie była jeszcze dzisiejszym VBM Sprint®

Ten moment łatwo opowiedzieć z dzisiejszej perspektywy zbyt elegancko.

Można byłoby powiedzieć:

mieliśmy VBM, dodaliśmy Agile i powstał VBM Sprint®.

Taka historia byłaby prosta.

I właśnie dlatego byłaby myląca.

Dzisiaj VBM Sprint® obejmuje znacznie dojrzalsze rozumienie problemu i sposobu pracy niż na początku.

Tych późniejszych rozstrzygnięć nie można jednak przypisywać pierwszej integracji.

W pierwszej fazie problem był rozumiany inaczej.

Silniej chodziło o to, jak połączyć logikę zarządzania wartością z krótką, skoncentrowaną formą interwencji i jak przełożyć VBM na realia małego przedsiębiorstwa.

Dopiero późniejsza konfrontacja z praktyką zaczęła zmieniać zarówno sposób diagnozy, jak i sam sposób definiowania problemu.

Dlatego pierwszej integracji nie warto oceniać przez to, czym VBM Sprint® jest dzisiaj.

Trzeba zobaczyć ją jako odpowiedź właściwą dla tamtego etapu rozumienia problemu.

Odpowiedź niepełną.

Ale wystarczająco konkretną, aby można było ją skonfrontować z praktyką.

Dobra koncepcja nie jest jeszcze dobrym rozwiązaniem

Na poziomie konstrukcji połączenie wyglądało logicznie.

Z jednej strony mieliśmy perspektywę wartości.

Z drugiej – rygor ograniczonego czasu, zakresu i koncentracji na rezultacie.

Razem tworzyły pierwszą odpowiedź projektową na rozpoznane ograniczenia pracy.

Ale zgodność logiczna to jeszcze nie to samo co adekwatność praktyczna.

Nie mogliśmy jeszcze wiedzieć, które elementy tej pierwszej odpowiedzi okażą się rzeczywiście potrzebne.

Nie mogliśmy wiedzieć, które będą wymagały zmiany.

Nie mogliśmy też wiedzieć, czy sam sposób definiowania problemu okaże się trafny, kiedy spotka się z realnym przedsiębiorstwem, niepełnymi danymi, różnymi interpretacjami i właścicielem stojącym przed konkretnym rozstrzygnięciem.

W tym sensie pierwsza integracja nie zamykała procesu.

Dopiero go otwierała.

Bo kolejne pytanie nie dotyczyło już tego, czy połączenie VBM i rygoru podejścia zwinnego wygląda sensownie na poziomie koncepcji.

Pytanie brzmiało:

co stało się, gdy ta pierwsza integracja spotkała się z praktyką – i czego autorzy nie mogli jeszcze wtedy o niej wiedzieć?