W ostatnim tekście o rolach w zespole projektowym koncentrowaliśmy się na funkcji, jaką pełni analityk. Dzisiaj kontynuujemy rozmowę z Michałem Kojtychem, tym razem zadając pytania o podejście bottom-up w analizie IT.
DCG: Jaka jest specyfika podejść do problemu bottom-up?
MK: pytanie, co rozumiesz jako „problem.” Czy chodzi Ci o początkową fazę i zidentyfikowanie problemu/zbieranie wymagań czy o końcową fazę i o wdrażanie zmian, by z problemem się uporać? W obu przypadkach mamy do czynienia z podejsciem od góry do dołu lub od dołu do góry – są to jednak kompletnie dwie różne rzeczy. Przy zbieraniu wymagań to kwestia czy rozmawiasz z interesariuszami, jak to mówimy, „od ogółu do szczegółu” lub odwrotnie, natomiast przy wdrażaniu rozwiązania, bottom-up to podejście opisane/zaprezentowane przez Changa (przyp.red. Jamesa F.) w ramach BPM (Business Process Management) i dotyczy roli managementu oraz roli uczestników procesu we wdrażaniu zmian.
DCG: Chodzi mi o to, że rozmawiając ostatnio o pensjonacie w górach poruszyłeś temat, jak dowiedzieć się, o co chodzi inwestorowi. Jak to robisz?
MK: Rozumiem – zacznijmy od tego, że jak poprzednio, Twoje pytanie o specyfikę podejścia bottom-up wymaga wstępu, by nakreślić kontekst.
A więc jeszcze nic nie mamy i jest to sam początek projektu. Skupmy się więc na tym, a pana Changa i etap wdrażania zostawmy na osobny artykuł.
DCG: OK, od czego zaczniemy?
MK: Przede wszystkim zakładamy, że projekt robimy zgodnie z zasadami sztuki, tzn. wymagania zbieramy rozmawiając z tzw. stakeholderami – a więc interesariuszami – przed wybraniem rozwiązania. Dlaczego to podkreślam? Otóż wybieranie rozwiązania a potem zbieranie pod niego wymagań jest niestety częstą, acz mocno niewłaściwą praktyką (błędnie zakładajacą, że skróci to czas, ograniczy koszty). Wtedy de facto nie musimy się dopytywać o wiele rzeczy, bo jesteśmy bardzo ograniczeni rozwiązaniem i analiza sprowadza się bardziej do "customizacji" rozwiązania. A czy już owo rozwiązanie spełni swoją rolę biznesową, to już życie pokaże. W takiej sytuacji chyba bardziej skierowałbym do tego zadania wdrożeniowca, aniżeli analityka biznesowego...
DCG: Załóżmy jednak, że działamy zgodnie z zasami sztuki.
MK: Jako osoba zorientowana na procesy, odnoszę się do metodyki zgodnej z BPM (Business Process Management), propagowanej przez konsorcjum OMG, które wyznacza pewne standardy w branży. Dotyczy ono wprawdzie rozwoju procesów, ale uważam, że z powodzeniem można je stosować/przekładać w wielu innych przypadkach np.: do rozwoju/budowy oprogramowania. Lub pensjonatu.
Zgdonie z BPM, na poczatku jest faza Discovery, a w niej etap analizy procesów. W przypadku rozwoju oprogramowania też mamy fazę Discovery i analizę sytuacji - gdzie trzeba zrozumieć obecny stan (as is) i to, do czego dążymy (to be). Laury Verner w ramach BPM wyróżnia trzy sposoby zbierania tych informacji:
- scentralizowane vs rozproszone
- ustrukturyzowane vs wolnej postaci
- i wreszcie to, o które pytałaś – odgórne (top-down) vs oddolne (bottom-up)
DCG: Wyjaśnisz, o co chodzi w tych podejściach?
MK: W bardzo dużym uproszczeniu podejście scentralizowane vs rozproszone definiuje, czy rozmawiamy ze wszystkimi interesariuszami razem (np. podczas warsztatów) czy osobno z każdym.
Podejście ustrukturyzowane vs wolnej postaci definiuje, czy mamy jakieś gotowe pytania, czy jest to bardziej free-style – luźna rozmowa, gdzie budujemy powoli obraz.
I wreszcie podejście odgórne – oddolne definiuje, czy sposób prowadzenia tych rozmów rozpoczynamy od bardzo ogólnych zagadnień i powoli schodzimy niżej i niżej, czy skupiamy się na detalach, które budują powoli pełen obraz.
DCG: Po sposobie, w jaki opowiadasz można wnioskować, że najbliższe Ci jest podejście top-down.
MK: Osobiście preferuję podejście top-down, inaczej mówiąc od ogółu do szczegółu.
DCG: Czy zdradzisz więcej szczegółów na temat tego podejścia?
MK: Odpowiadając Ci na początkowe pytanie o specyfikę podejścia bottom-up, chyba najprościej będzie mi odpowiedzieć porównując/charakteryzując oba te podejścia:
PODEJŚCIE ODGÓRNE (TOP-DOWN)
MK: Nawiązując do obecnego, świątecznego okresu, to podejście jest taką choinką, na której najpierw wieszamy łańcuch, potem schodzimy do wieszania poszczególnych bombek, a na koniec okrywamy anielskim włosiem.
DCG: Ciekawa metafora.
MK: Analiza rozpoczyna się od zebrania informacji o niskim poziomie szczegółowości, tak ogólnie. Następnie identyfikuje się poszczególne kwestie, opisuje się je bardziej szczegółowo (jak wspomniałem, patrzę na świat procesowo, ale to tak samo może dotyczyć wymagań).
Takie podejście bardzo ułatwia zachowanie początkowo wybranego kontekstu.
DCG: Czy są jakieś minusy?
MK: Wadą jest, że to, co nie mieści się w naszym początkowym modelu, może nie zostać odkryte. Innymi słowy, gdy coś pominiemy na początku, może się to na nas zemścić później.
PODEJŚCIE ODDOLNE
MK: W podejściu oddolnym natomiast skupiamy się na konkretach, zaczynamy od meritum np. rozmawiamy o konkretnych czynnościach codziennych członków zespołu.
Dzięki temu mamy całą masę szczegółów na sam początek. Jest to zarówno wadą jak i zaletą.
DCG: Dlaczego?
MK: Ponieważ łatwo można zgubić kontekst w gąszczu wymagań. Można też „pójść w las” i skupić się na czymś mało istotnym. Podejście to jednak pozwala zebrać całe spektrum istotnych kwestii, które wymagają dalszej „obróbki.” Analityk musi je odpowiednio zhierarchiwizować i poumieszczać w odpowiednim kontekscie – zilustrować hierarchię i zbadać, czy zebrane informacje na pewno są w zgodzie z celem projektu/w zakresie projektu.
Czy odpowiedziałem na Twoje pytanie?
DCG: Oczywiście. Dzięki za wyjaśnienia.
MK: Na koniec jeszcze dodam, że ogólnie rzecz ujmując, podejścia top-bottom i bottom-up można odnosić też do innych kwestii – np. odpowiedzi na pytania. Ciekawy jestem, czy wolałabyś, abym odpowiedział Ci zgodnie z bottom-up: a więc gdybym najpierw podał definicję, różnice przy minimalnym wprowadzeniu, a potem powoli wyjaśniał?
DCG: Zdecydowanie.
MK: Jeśli uważasz, że byłoby to dla Ciebie łatwiejsze, co byś wolała: szybką odpowiedz, ale ryzyko zgubienia kontekstu podczas jednej z kilku dygresji, czy najpierw teoria a potem odpowiedz?
DCG: Myślę, że opcja mniej ryzykowna. Dziękuję za rozmowę.
ANALIZA IT, TECHNOLOGIA
