Analiza biznesowa jest ą, ę

Notebook and coffee with copy space on a wooden background. selective focus

Słuchałem jakiś czas wywiadu z prof. Bralczykiem na temat języka polskiego. Z wywiadu tego, utkwił mi w głowie fragment dotyczący ewolucji języka, która między innymi skutkuje znacznym zubożeniem słownictwa będącego w powszechnym użyciu. Mnogość określeń bazujących na subtelnościach i niuansach jest zastępowana zwrotami typu wporzo, mega, czy zapożyczeniami w stylu ołmajgod. Tak, wiem, makaronizmy od wieków uzupełniały nasz język, aczkolwiek, jak mi się wydaje, nie w takim stopniu.

Nałożyłem tę sytuację na inne języki – języki wyrazu myśli analitycznej. Od dziesiątek lat rozwijane z myślą o radzeniu sobie w sytuacjach, w których język naturalny jest niewystarczający, gdy zwykły zapis myśli w formie zdań utrudnia pracę, a czasami czyni ją niewykonalną w zadanym czasie i w oczekiwanej jakości. W obszarze tym także widać było pewną ewolucję – strukturalne metodyki wytwarzania oprogramowania zostały płynnie zastąpione paradygmatem obiektowym, poszerzający się zakres technologiczny odnajdywał wsparcie w nowych środkach wyrazu – nowych językach. Kolejne obszary analizy biznesowej, architektury biznesowej, architektury korporacyjnej zostały objęte dedykowanymi językami. Środki wyrazu, jakimi aktualnie dysponuje (a precyzyjniej, powinien dysponować) kompetentny analityk są ogromne. Nic tylko uczyć się, uczyć, uczyć, nabierać doświadczenia i świadomie, płynnie i adekwatnie do sytuacji stosować.

I nagle okazało się, że to wszystko jest niepotrzebne. Że JAKO analityk CHCĘ stosować bardzo proste techniki ABY szybko wdrażać rozwiązania. I niewiele więcej jest potrzebne. I skomplikowane stało się proste. Jak budowa cepa.

OMG! Ja jednak wolę ą, ę. Rili.

 


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

Analityk biznesowy jako lider

Lider. Często określenie to niesie za sobą skojarzenia z charyzmatycznym prezesem firmy, która osiągnęła spektakularny sukces. Bądź z rozpoznawalnym przywódcą partii politycznej. Z drużyną sportową i jej najlepszym zawodnikiem.

W analizie biznesowej, szczególnie w trudnych organizacyjnie projektach, w ramach których podejmowane są niełatwe decyzje analityk biznesowy musi stać się takim liderem. Liderem zmiany. Twarzą tej zmiany. Kompetencje przywódcze będą wymagane w różnych sytuacjach – w trakcie rozmów ze specjalistami dziedzinowymi o aktualnym stanie organizacji, o występujących problemach, w trakcie wypracowywania docelowych rozwiązań, prezentacji rozwiązań innym interesariuszom projektów. Uzyskanie właściwego poziomu dialogu będzie możliwe w sytuacji, gdy specjaliści dziedzinowi oraz osoby oceniające i podejmujące kierunkowe decyzje odnośnie wdrożenia rozwiązania uznają nas za wiarygodnego partnera. Na wiarygodność wpływa wiele kryteriów: wiedza dziedzinowa, kompetencje inżynierskie (analityczne), umiejętność komunikowania się, negocjowania. W ogromnym stopniu wiarygodność buduje postawa lidera, postawa osoby która całym sobą potwierdza zasadność uczestniczenia w pracach.

Analityk biznesowy uczestniczący w nietrywialnym przedsięwzięciu przez cały czas będzie się zmagał z koniecznością motywowania członków zespołu do zaangażowania się w prace, stawić będzie musiał czoła oporowi, który może się pojawić w sytuacjach, gdy uczestnicy zauważą zagrożenie dla swojego aktualnego miejsca w organizacji, będzie negocjował fragmenty rozwiązania z opiekunami obszarów biznesowych, na które zmiana wpłynie. W tego typu sytuacjach ogromną rolę będą odgrywały kompetencje przywódcze, kompetencje które przekonają inne strony do pójścia we wskazanym kierunku.

Liderem nie można zostać w efekcie dekretacji. Lidera wybiera i akceptuje grupa, z którą pracuje. Lider musi do siebie grupę przekonać. Lider musi pokazać, że warto z nim udać się w długą i niełatwą drogę. Lider musi o swoją pozycję dbać (nie mylić, z walką).

Liderem albo się jest z natury, albo trzeba się nauczyć nim być. Pozycja lidera nie jest dana raz na zawsze – o utrzymanie tej pozycji należy stale dbać. Aby dbać o nią skutecznie, trzeba wyrobić w sobie umiejętności zauważania sytuacji, w której wymagana będzie świadoma interwencja mająca na celu podtrzymanie pozycji. Skutecznego interweniowania także należy się nauczyć.

Proces dydaktyczny w tak subtelnej kompetencji, jaką jest przywództwo nie jest łatwy. W szczególności, niełatwo jest ocenić, czy prezentowana postawa jest przekonująca, czy da szanse zbudować wokół siebie zespół. Pomoc w tym zakresie przyszła do nas z zupełnie nieoczekiwanego kierunku. Wiele lat temu, w szeroko pojętym światku hipicznym, pojawił się nurt naturalnych metod pracy z końmi. Zaowocował on zakrojonymi na szerszą niż dotąd skalę pracami w zakresie behawioryzmu tych wrażliwych zwierząt. Potwierdziły one między innymi fakt, iż konie żyją w bardzo hierarchicznym świecie, w którym to od skuteczności lidera zależy dobrobyt, a często i życie grupy. Jest to świat w którym wykluczenie z grupy oznacza śmierć, a proces ustalania miejsca w stadnej hierarchii odbywa się nieustannie. Często sygnały świadczące o próbie zrewidowania miejsca w hierarchii są subtelne – koń „niechcący” delikatnie kogoś przesunął, koń „przypadkowo” nie usłyszał. Koń nie zrobił nic przypadkowo. Koń sprawdza, czy Ten Drugi jest wyżej (i musi go słuchać), czy przypadkiem dzisiaj To Ja jestem wyżej. Koń nie czyta wizytówek. Koń nie wie, kim jest tato, czy ciocia. Koń widzi Tego Drugiego. I sprawdza go.

Na bazie tego typu wiedzy powstały unikalne w swoim charakterze warsztaty budujące kompetencje przyszłych liderów. W trakcie warsztatów trzeba przekonać konie, iż warto nam zaufać. Konie szczerze nam odpowiedzą. A ja szczerze polecam.

Ulotka: Lustro Lidera

Unikalne warsztaty mające na celu budowanie kompetencji przywódczych, w trakcie których ocena uczestników jest dokonywana przez konie.

 

 

Grafika: http://www.freepik.com/free-photos-vectors/background Background image created by Katemangostar – Freepik.com


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.

SCRUM responsibly

W którą stronę bym się nie obrócił, przed oczami widzę zwinność. Nie, żebym miał wizje – tak mnie uszczęśliwia szara rzeczywistość. W zasadzie nie miałbym nic przeciwko temu, gdyby nie fakt, iż w większości przypadków zwinność ta przybiera karykaturalną formę pogoni za nieosiągalnym – a im bardziej nieosiągalne staje się nieosiągalne, tym szybszy i mniej kontrolowany staje się pościg.

Patrząc na ten fenomen z punktu widzenia analityka biznesowego, nie mogę pojąć sposobu, w jaki zwinność, promowana przez praktyki SCRUM, miałaby pomóc realizować przedsięwzięcia prowadzone w nietrywialnym środowisku. Trudność z pojmowaniem rozpoczyna się już na poziomie roli o nazwie Product Owner. Tłumacząc literalnie na język polski, mamy do czynienia z właścicielem produktu. Ale jakiego produktu? Czy produktem jest cała zmiana, która została zainicjowana (na przykład w formie projektu)? Jeżeli tak, to właściciel produktu powinien być nazywany właścicielem zmiany. Jeżeli jednak powinien być jawnie wskazany produkt, to jaki? Załóżmy, że zmiana dotyczy usprawnienia jakiegoś obszaru organizacji – czy w takim razie ten obszar jest produktem? Jeżeli tak, to czy w przypadku szerokiej zmiany, dotykającej na przykład wielu procesów biznesowych, nie wystąpi konflikt choćby pomiędzy właścicielem produktu a właścicielami procesów biznesowych?

Bez względu na to, co jest produktem, zgodnie z zaleceniami SCRUM, właściciel tegoż jest odpowiedzialny za zawartość product backlogu, a zespół deweloperski, za jego przetworzenie w finalny, wartościowy produkt każdego sprintu. Załóżmy, że rozpoczynamy prace w przedsięwzięciu o charakterze opisanym wcześniej. Efektem prac sprintu mogą być wskazane w procesach punkty nieciągłości, wykazana niezgodność pomiędzy celami procesów a modelem biznesowym, oraz wskazane do zrewidowania polityki, reguły biznesowe oraz definicje niektórych pojęć. Pytanie, czy to ma wartość biznesową w kontekście SCRUM (boć nie jest to przecież działający fragment systemu).? Kim są deweloperzy (boć miejsca dla projektantów, programistów i testerów tam nie ma)? Analiza biznesowa na tym poziomie ma to do siebie, iż nie jest zbyt przewidywalna. Mnogość międzyludzkich interakcji, często powiązanych z emocjami wynikającymi z zaburzenia komfortu na najniższych poziomach piramidy potrzeb, powoduje, iż zwroty analitycznych akcji są częste, a z dnia na dzień odkrywane mogą być obszary wymagające osobnego potraktowania. W praktyce, sprinty zaczynają określać częstotliwość raportowania, pozostawiając prace swojemu własnemu rytmowi. Innymi słowy, zaczynamy praktykować sztukę dla sztuki. Po co?

W trakcie kilkunastu rozmów na temat praktyk SCRUM w kontekście analizy, docierał do mnie przekaz, iż SCRUM jest techniką deweloperską, w której deweloper to członek zespołu pracujący nad rozwiązaniem IT. Gdyby przyjąć taki punkt widzenia, to cała praca związana z projektowaniem docelowego kształtu organizacji w ramach szeroko pojętej zmiany odbywać się powinna poza SCRUM. Jeżeli tak, to za właścicielem produktu powinien stać sztab analityków biznesowych i architektów biznesowych, wspierających go w podejmowaniu decyzji dotyczących product backlogu. Ale zaraz – czy nie sankcjonujemy przypadkiem podejścia waterfall (które, dla przypomnienia, jest ZŁEM)? Najpierw analiza a potem „kodowanie”?

Kontynuując podróż w dół procesu wytwórczego, docieramy w końcu do zespołu deweloperskiego, którego zadaniem jest wytwarzanie, w odstępach wyrażanych długością sprintów, upragnionego oprogramowania. Podtrzymując założenie, iż pracujemy na problemach o złożoności nietrywialnej (np. dowolna korporacja), zmiana na poziomie IT będzie wymagała zmian w wielu systemach jednocześnie, które rozwijane są w różnych technologiach, jednostkach organizacyjnych i podmiotach (spółki zależne, dostawcy w pełni zewnętrzni). Zakładając zdroworozsądkowo, iż planowanie logiki rozwiązania (poziom PIM według MDA) dokonywane jest według zasad wspierających systemowe podejście do problemu, analiza poszczególnych funkcjonalności może trwać zauważalnie długo z punktu widzenia długości sprintu. W praktyce może się to przełożyć na funkcjonowanie podzespołów scrumowych dwóch prędkości – zespół analityków, ux-owców, architektów IT pracujących nad przyrostem n, i deweloperów, zajmujących się przyrostem n-1. Oczywiście, nic nie stoi na przeszkodzie aby deweloperzy w jakimś zakresie pracowali nad przyrostem n, aczkolwiek małe jest prawdopodobieństwo, aby ukończyli go w sprincie, w którym ukończą go analitycy. To tez prowadzi do wniosku, iż do pewnego stopnia mamy jawnie do czynienia z podejściem (iteracyjnym i przyrostowym) waterfall.

Poszczególne wątki można rozwijać dalej, aczkolwiek z punktu widzenia celu niniejszego wpisu nie jest to zasadne. Wątpliwości, które opisałem mam od dawna. Dane mi było przeprowadzić wiele rozmów, z wieloma osobami, z wielu organizacji i żadna z tych rozmów wątpliwości nie rozwiała, a większość tylko je potwierdziła. Z drugiej strony, ze środowisk promujących zwinne, oparte o SCRUM podejście, uzyskuję zapewnienia, iż da się to wszystko ogarnąć, tylko trzeba zmienić styl myślenia, podejście, zaufać, i takie tam. Cierpliwie czekam, bom ciekaw. Aczkolwiek coraz bardziej utwierdzam się w przekonaniu, że jedyną rzeczą, jaka nas może uchronić od porażki są wysokie kompetencje osób pełniących poszczególne role w projekcie (architektów korporacyjnych, architektów biznesowych, analityków biznesowych, analityków systemowych, architektów IT, projektantów, programistów, testerów, specjalistów dziedzinowych, scrum masterów, kierowników projektów, i innych), dobrze określony proces wytwórczy (metodyka dostosowana do charakteru przedsięwzięcia), dobrze określony proces zarządczy (dostosowany do specyfiki przedsięwzięcia), postawa skierowana na rozwiązywanie problemów oraz zdrowy rozsądek, nakazujący czerpanie z różnych źródeł (waterfall, agile, TQM, facylitacja, BPM, design thinking, itd.).

Howgh!

 

Grafika: http://www.freepik.com/free-photo/silhouettes-of-a-tree-and-a-man-on-a-book_969890.htm” Designed by Freepik


Licencja Creative Commons
Ten utwór jest dostępny na licencji Creative Commons Uznanie autorstwa – Bez utworów zależnych 4.0 Międzynarodowe.