Jak analityk biznesowy powinien we właściwy sposób pracować ze zmianami

20 kwietnia 2023

  • Autor: Ulia Dniprova

  • Złożoność: normalna

  • Czas: 13 min

Akceptacja zmian w istniejącym produkcie prawie zawsze wiąże się z dużym ryzykiem. O to, co powinien zrobić analityk biznesowy po otrzymaniu wniosku o zmianę, dlaczego warto zaangażować zespół w proces i jak negocjować z klientem zapytaliśmy lidera zespołu analityków biznesowych Michaiła Bachracha.

Witam, nazywam się Michaił Bachrach, w tym artykule zamierzam podzielić się moim praktycznym doświadczeniem zdobytym przez ostatnie 8 lat w analizie biznesowej. Główne typy projektów, w których brałem udział to Greenfield, Business transformation oraz Re-engineering types, trwające od 6 do 18 miesięcy. Obecnie pracuję jako kierownik zespołu analityków biznesowych w firmie EPAM.

Ważna uwaga: będę mówił o zmianach w kontekście już wdrożonego przyrostu produktu. Innymi słowami, będę mówił o procesie change request, kiedy zmiana pojawia się na bazie czegoś, co zostało już oprogramowane.

Opowiem o tym, jakie zmiany mogą pojawić się na tym etapie, czego mogą dotyczyć oraz jak prawidłowo oceniać wnioski o zmianę i zarządzać zmianami.

Kryteria oceny i rodzaje zmian

Jak analityk biznesowy powinien we właściwy sposób pracować ze zmianami

Jednym z głównych czynników, które należy wziąć pod uwagę podczas oceny, jest typ projektu i rodzaj zobowiązania umownego. Popularne formaty projektów to Waterfall i Agile. Jeśli chodzi o ustalenia umowne, najczęściej spotykane są Fixed Price lub Time and Materials.

Oprócz typu projektu, ważne jest, aby wziąć pod uwagę fazę prac, finanse, komunikację, architekturę i politykę firmy klienta w celu oceny zmiany.

Waterfall to podejście do metodologii delivery, gdzie ostateczna decyzja i terminy są określone z góry, a zespół ma za zadanie wdrożyć wszystko w jak najbardziej szczegółowy sposób.

Jest to metodyka programowania etapowego w długim okresie czasu. Najpierw przeprowadzana jest analiza produktu, następnie design, programowanie i testowanie. Odpowiednio, im późniejsza faza, tym projekt będzie droższy.

Wydaje się, że podejście Waterfall bardzo utrudnia wprowadzanie zmian w trakcie. Trzeba jednak wziąć pod uwagę „politykę” usługodawcy – jak ważny jest dla firmy klient poza kontekstem „zarabiania pieniędzy” i jakie budżety są przeznaczone na projekt.

Waterfall ogólnie zakłada istotne ryzyko, ograniczenia i restrykcje, więc często budżetuje się w nim całkiem spore pieniądze. Czasem więc klient może „za darmo” potwierdzić oprogramowanie dodatkowej zmiany.

Agile nie jest podejściem, ale raczej sposobem myślenia z różnymi frameworkami, które są używane jako metodologię do delivery oprogramowania produktu. W Agile, programowanie odbywa się w cyklach iteracji: co 2-4 tygodnie zespół wytwarza działający przyrost produktu.

Jeśli wynik się nie podoba, zespół go naprawia; jeśli się podoba, idziemy dalej. Oczywiście, wiele zależy od rodzaju relacji kontraktowej, ale więcej na ten temat dalej.

W Fixed Price nie chodzi o metodologię, ale o podejście do zobowiązań kontraktowych klienta. W Fixed Price chodzi o ograniczenia budżetowe, a w większości przypadków także o czas i zasoby.

Na przykład, klient pyta:

– Ile będzie kosztować wasze rozwiązanie?

– 500,000.

– OK – mówi klient – daję ci tę kwotę, a ty musisz wymyślić rozwiązanie.

Klient chce zobaczyć rezultat, ale jednocześnie jest tylko 500 tysięcy. Jeśli klient ma ograniczony budżet, to będzie też ograniczenie czasowe i trzeba to wziąć pod uwagę przy ocenie, dyskusji i podejmowaniu decyzji o zmianie. Ważne jest, aby przekazać klientowi, że oprócz przerwania linii czasu, nowa zmiana będzie wymagała dodatkowych pieniędzy.

Time and Materials – przeciwieństwo Fixed Price, bardziej podobne do Agile.

Tutaj klient może powiedzieć:

– Musimy to rozwinąć, ale nie jestem jeszcze pewien, co chcę zobaczyć w finale. Dawajcie na razie 10 developerów, ile kosztują miesięcznie?

– 100 tys. dolarów.

– Zapłacę 100 tysięcy miesięcznie – mówi klient – i będę patrzył na wynik.

Zmiany w Time and Materials mogą być łatwo potwierdzone przez klienta, ponieważ płaci on za ludzi, a nie za ilość pracy. Są jednak niuanse: nawet gdy klient ma duży budżet i możliwość zwiększenia zasobów, to i tak będzie miał oczekiwania co do zakończenia danej fazy lub całego projektu. To właśnie tutaj ważne jest śledzenie zmian, ponieważ mogą one znacząco przesunąć termin zakończenia projektu.

W tym artykule podzieliłem rodzaje zmian ze względu na hierarchiczną segmentację zmian w stosunku do rozwiązania. Zmiany dzielimy na 4 grupy: punktowe, poziom funkcji całościowych, poziom komponent systemu oraz poziom cross-komponent lub ekosystemy.

Zmiany punktowe

Przykładem zmiany punktowej na frontendzie może być nazwa przycisku, nawigacja itp. Dla backendu byłyby to: wymaganie api, obliczenia, reguły techniczne i biznesowe, itp.

Jak wygląda zmiana punktowa w rzeczywistym doświadczeniu:

System wyświetla listę obiektów, np. kampanii marketingowych, a w nich listę elementów. Gdy użytkownik chciał przenieść element z jednego folderu do drugiego, klikał „wybierz folder/element/plik”, a system wyświetlał popup z płaską, nieotwartą listą elementów (plików i folderów).

Przychodzi prośba od klienta: „Przeróbmy popup, aby widzieć od razu całą strukturę drzewa do wyboru plików”.

Z punktu widzenia interfejsu użytkownika zmiana wydaje się prosta, ale przed podjęciem decyzji należy przyjrzeć się, na jakie kryteria oceny wpływa dana sytuacja:

  • Komunikacja – czy wszyscy naprawdę zgodzili się na zmianę. Najpierw komunikowałem się z klientem, potem poszedłem do developerów i QA. Zespół powiedział, że zmiana nie jest taka prosta, ponieważ musimy wyciągnąć listę plików i folderów z zewnętrznego systemu za pomocą api. Co więcej, ciągniemy tylko pierwszy poziom, a poziomów może być 5 lub 10, co oznacza, że wykonanie wizualizacji w UI będzie przeciążone.
  • Elementy architektury. Prośba wyglądała na tak punktową i prostą, że można było powiedzieć programistom: „Koledzy, zmieńcie wizualizację z listy jednopoziomowej na drzewiastą”. Ale kiedy zaczęli rozgryzać szczegóły, okazało się, że na poziomie backendu zmiana wpłynie na architekturę.
  • Faza prac. Do tego czasu zaimplementowaliśmy już api, które wyciągało pierwszy poziom plików i folderów. Aby zmienić listę jednopoziomową na listę przypominającą drzewo (pokazującą 2-4 poziomy jednocześnie), musielibyśmy zmienić api i poprosić dostawcę – system zewnętrzny – o wsparcie wielopoziomowego zwrotu zapytania dla tego api. W związku z tym, jako BA, zdałem sobie sprawę, że w fazie, w której api jest już wdrożone i istnieją umowy z klientem, zmiana widoku listy nie jest realistyczna.

W końcu klient odrzucił strukturę plików przypominającą drzewo, gdy wyjaśniono mu, że trzeba będzie przerobić api i dogadać się z dostawcą zewnętrznym, aby zmienić strukturę swoich usług związanych z listą danych.

Poziom funkcji całościowej (cecha/funkcja)

Jeśli podczas procesu rozwoju klient zażądałby nowej funkcji lub chciałby zmienić reguły biznesowe, byłby to przykład zmiany na poziomie funkcji.

Będę kontynuował na przykładzie listy obiektów:

Klient był zadowolony z plików i folderów w systemie, ale chciał też dodać możliwość kopiowania np. z folderu głównego do folderu drugiego poziomu. 

Przyjęliśmy wniosek pod warunkiem spełnienia dwóch kryteriów oceny:

  • Finanse: Ponieważ funkcja kopiowania nie została omówiona i zatwierdzona w umowie na rozwiązanie, chcieliśmy poprosić o dodatkową zapłatę za nią w ramach projektu Fixed Price.
  • Polityka: Oczywiście, nowa funkcjonalność wymagałaby dodatkowej zapłaty. I tu właśnie pojawia się czynnik polityki: można by było zasugerować klientowi, że funkcja będzie kosztować mniej pieniędzy lub uwzględnić płatność w kolejnej umowie.

Szukaliśmy lepszego rozwiązania biznesowego, więc zaakceptowaliśmy zmianę i wystawiliśmy fakturę, a od tego momentu decyzja należała do klienta.

Poziom komponentów

W średnich i dużych projektach występują komponenty, które są podzielone pomiędzy zespoły według releasów, kamieni milowych itp. Przykłady: zmiana globalna, gdzie zaangażowanych jest kilka komponentów, np. katalog, baza danych klientów, realizacja zamówień w ramach tego samego systemu.

Konkretnym przykładem, z którym się zetknąłem, była zmiana interfejsu na stronie z voucherami prezentowymi.

Stworzyliśmy interfejs frontendowy do sprzedaży voucherów, zimplimitowaliśmy go i szliśmy dalej. W pewnym momencie, na marginesie, klienci i interesariusze przedyskutowali następujące wymaganie: „Chcemy, aby użytkownik widział dwa różne interfejsy użytkownika na etapie wyboru certyfikatu i na etapie po zakupie”.

Projekt był Agile i Time and Material, czyli klient płacił stałą kwotę za miesiąc. Niuansem było to, że mieliśmy już zaplanowany i opracowany interfejs dla obu typów akcji użytkownika: gdy osoba kupiła voucher i gdy go dopiero wybiera.

Dlatego kluczowym kryterium oceny była faza projektu. W początkowej fazie po prostu zmienilibyśmy projekt i opracowali to, co chciał klient. Ale my byliśmy w fazie prawie gotowego UI.

Aktywnie komunikowaliśmy się z klientem, wyjaśniając:

  • jakie są sposoby na wprowadzenie zmiany;
  • ile pracy trzeba by wykonać;
  • jak wpłynie to na harmonogram.

Ostatecznie zmiana została potwierdzona, a przesunięcie terminu uzgodnione z klientem. 

Cross-komponent/poziom ekosystemowy

Ekosystem – słowo dość popularne w dziedzinie IT – to coś logicznego, ergonomicznego, „płynnie” włączonego w nasze życie. O ekosystemie mówimy wtedy, gdy powstaje działający produkt, który w pełni odpowiada potrzebom biznesu. Przykładem może być duży projekt przedsiębiorstwa, w którym zespoły 30-40 osób wykonują różne komponenty, a całość jest ekosystemem. W takim projekcie zmiana logiki pracy funkcji będzie miała wpływ na kilka komponentów lub cały system.

Przykład z praktyki: Metoda obliczania i pobierania pieniędzy za usługę

Klient sprzedawał towary, a co miesiąc pobierał od klienta opłatę za pewną usługę. System liczenia był wadliwy, więc cały czas trzeba było coś poprawiać ręcznie.

W proces płatności zaangażowanych było kilka oddzielnych podkomponentów systemu: obliczanie kwoty, wystawianie faktur i określanie, który dokładnie produkt należy użyć dla każdego klienta.

Klient chciał wprowadzić zmiany do istniejącego produktu, a w tym przypadku podkreśliliśmy politykę firmy, ponieważ trzeba było wprowadzić poważną zmianę w projekcie Waterfall, w którym wszystko zostało wcześniej uzgodnione.

Zmiana dotyczyła wielu elementów systemu, więc musieliśmy wcześniej omówić z klientem najmniejsze szczegóły.

Te rzeczywiste przykłady pokazują, że nawet zmiana punktowa, która na pierwszy rzut oka wygląda na nieistotną, może mieć wpływ współmierny do poziomu cross-komponentów.

Jeśli chodzi o segmentację na poziomie solution, to zmiana punktu wygląda jak drobiazg w porównaniu z komponentem poziomu. A jeśli analityk biznesowy na to nie wpadnie, to może dostać taką prośbę od klienta i pomyśleć: „Co tam, tylko przycisk do zmiany, to szybko”. BA napisze dodatkowe wymagania dotyczące zmiany, potwierdzi i obieca, że to zrobi.

Ale powiedzmy, że analityk biznesowy nie wziął pod uwagę, że mała zmiana wpływa na architekturę aplikacji innej firmy, dla której klient nie ma umowy na wprowadzenie zmian.Następnie okazuje się, że zmiana punktowa może kosztować 500K, ale komponent poziomu może kosztować tylko 250K.

Więc nawet coś, co wygląda na małe i niepoważne, lepiej potraktować przez analityka biznesowego o takim samym poziomie odpowiedzialności jak coś, co wygląda bardzo poważnie.

Następnie opowiem, jakie 4 zasady zawsze pomagają mi utrzymać zmiany pod kontrolą.

Zarządzanie zmianami

Jak analityk biznesowy powinien we właściwy sposób pracować ze zmianami

Chodzi tu nie tyle o kolejnych krokach zarządzania, co raczej o kluczowe zasady, o których pamiętam podczas pracy z każdą zmianą. Zrozumienie i przestrzeganie tych zasad zawsze przynosi wartość dla klienta, niezależnie od tego, czy zmiana zostanie przyjęta czy odrzucona.

  1. Dowiedz się, jaki jest powód zmiany, dlaczego istnieje konkretne wymaganie. Zmiana może wynikać z chęci klienta do poprawienia czegoś (potrzeba biznesowa) lub rozwiązania jakiegoś problemu, który nie został wykryty na czas.
  2. Utrzymywanie przejrzystości procesu. Oznacza to, że nigdy nie staram się szybko rozwiązać problemu rozmawiając tylko z 1-2 osobami lub tworząc ticket bez żadnego wyjaśnienia. Ważna jest komunikacja i włączenie do procesu klienta, zespołu i zainteresowanych osób po stronie klienta, aby każdy rozumiał, co się dzieje.
  3. Współpraca z klientem. Znaczenie tej zasady to pozytywna, proaktywna i kooperacyjna interakcja z klientem na poziomie formalnym i nieformalnym.
  4. Zarządzanie czasem. W zarządzaniu zmianą wszystko musi być ASAP, bo zarządzanie zmianą jest najwyższym priorytetem.

Pokażę na przykładzie jak działają te cztery zasady:

Wniosek o zmianę powstał na etapie UAT (user acceptance testing). UAT to końcowa faza wydania produktu, która występuje w każdej metodologii. Oprogramowany produkt jest przekazywany do testowania klientowi końcowemu lub użytkownikowi. Na przykład w przypadku systemu sprzedaży usług turystycznych, produkt może być testowany przez biuro podróży: jak wszystko działa.

Jeśli użytkownik znajdzie problem, przekazuje go wyżej do swojej organizacji.

Opracowaliśmy system sprzedaży produktów TPK dla konsumentów, a użytkownikami końcowymi byli pracownicy samej firmy.

I tak w procesie akceptacji jeden z tych użytkowników przychodzi do swojego kierownika, szefa sprzedaży, i mówi:

– Widzę, że w profilu zamówienia dla klienta brakuje wymaganego pola „adres 2”, a my nie możemy korzystać z systemu bez tego pola.

Kierownik sprzedaży skontaktował się z właścicielem produktu po stronie klienta – i powiedział, że dzisiaj problem z polem adresu jest najbardziej krytyczny i trzeba się nim zająć jak najszybciej.

Właściciel produktu przyszedł do mnie i wtedy zaczęła obowiązywać trzecia zasada: współpraca. Podczas pracy nad projektem, w relacjach z klientem stale tworzyłem podejście oparte na współpracy i przynosiło to obopólne korzyści. Klient nie miał więc pretensji, nie przekazał problemu moim managerom, ale powiedział: „Przedyskutujmy, co możemy zrobić z tym problemem”.

Tu włączyłem pierwszy punkt: ustalenie przyczyny – i zacząłem pytać: „Co jest nie tak z tym adresem?”. Przygotowywaliśmy produkt przez około rok, dopracowywaliśmy szczegóły, sam stałem w punktach sprzedaży, obserwowałem, jak klientom sprzedaje się produkty, jak są one przetwarzane. I tego pola z adresem nie było w wymaganiach.

Powiedziałem do właściciela produktu: „Nie grzebmy w szczegółach tylko z tobą, lecz omówmy wszyscy razem. Czy możesz zorganizować zlot z szefem sprzedaży i użytkownikiem, który zrozumiał problem?”.

Tu zadziałała zasada transparentności procesu: nie powiedziałem, że mamy change request management, więc przygotujmy ticket, omówmy go z wami, potem ja omówię go z kierownikami itd. Byłem całkowicie transparentny: nie rozumiem problemu i jestem gotów go omówić.

Product owner zorganizował zlot, zebraliśmy się i zaczęliśmy ustalać w czym tkwi problem. Użytkownik odpowiedział, że nie ma pola „adres 2”, które wpisywał przez ostatnie dziesięć lat.

Dialog potoczył się tak:

– Do czego to prowadzi? Co to za problem, jeśli nie ma się adresu?

– Cóż, zawsze go wpisuję.

– Dlaczego miałbyś to robić?

– Właściwie to mam tylko instrukcję, żeby zawsze go wpisywać.

Spojrzał na swojego kierownika sprzedaży i zapytał:

– Dlaczego my go wpisujemy?

A kierownik powiedział:

– Myślałem, że mi odpowiesz.

Następnie poprosili o czas do namysłu i ostatecznie poinformowali, że pole nie jest ważne. Problem został rozwiązany bez angażowania wyższego kierownictwa, dodatkowych pieniędzy, przesuwania terminów itp.

Te cztery czynniki: przyczyna, przejrzystość, współpraca i czas, pomagają w prawidłowym postępowaniu z wymaganiami klienta. Dalej wyjaśnię, dlaczego ważne jest zachowanie porządku w ocenie każdej zmiany.

Jak dowiedzieć się, czy zmiana jest konieczna

Jak analityk biznesowy powinien we właściwy sposób pracować ze zmianami

W mojej pracy oceniam potrzebę zmiany krok po kroku. W pierwszym kroku patrzę, jaka jest wartość proponowanej zmiany i dla kogo jest ona ważna. Kolejnym krokiem jest analiza i dyskusja z interesariuszami. I dopiero w ostatnim kroku przechodzę do etapu formalnego – udokumentowania ewentualnej zmiany, porządkowania ścieżek analizy, oceny i rozwiązywania problemów.

Ważne jest, aby postępować w takiej kolejności: Personal – Informal – Formal, bo w przeciwnym razie można zepsuć relację z klientem i wielokrotnie przerabiać to samo.

Powiedzmy, że analitykowi biznesowemu powiedziano na spotkaniu, że trzeba wprowadzić zmianę: dodać nowy przycisk.

Analityk, pomijając 2 pierwsze punkty, przeszedł od razu do części oficjalnej i zaraz na powiedział: „OK, oto umowa, stworzę zadanie, wyślę je do kierownika i on się tym zajmie”.

Jeśli na spotkaniu był przedstawiciel klienta, to przekaże informację swojemu kierownikowi, który skontaktuje się z Twoim PM-em i będzie oburzony: „Dlaczego, u licha, dajesz nam change request na przycisk? Nawet nie rozmawialiśmy o tym, jak to będzie działać, który przycisk wybrać, jak to wdrożyć, ile to będzie kosztować, a wy już wystawiliście change request”.

Złamana jest tu nie tylko procedura oceny zmian, ale także czynnik przejrzystości procesu: klient może odnieść wrażenie, że żądanie zmiany będzie bardzo kosztowne i to spowoduje konflikt.

Kiedy więc pojawia się prośba od klientów lub managerów: „Chcę coś zmienić”, jest jeszcze jedna opcja. Analityk biznesowy zawsze może powiedzieć: „Mam wszystko zapisane, jutro dam Panu odpowiedź”. Jest to normalne, ponieważ każdy klient oczekuje dwóch odpowiedzi na swoje zapytanie: kto to zrobi i kiedy. Jeśli BA udzielił tych dwóch odpowiedzi, to w większości przypadków można poświęcić czas na przemyślenia i kontynuować rozmowę później.

Jak działa ocena krok po kroku, spójrzmy na abstrakcyjny przykład: trzech interesariuszy chce trzech przycisków w różnych kolorach: zielonym, czerwonym i niebieskim.

Mówię: „OK, dziś zastanowię się nad najlepszym rozwiązaniem, a jutro odpowiem”. Następnie oceniam zmianę w trzech krokach.

  1. Personal – kto i dlaczego tego potrzebuje.

Jako jedną z opcji, umówiłbym się na 15-minutowe spotkanie z każdym z trzech klientów, aby wyjaśnić, dlaczego zielony, a nie czerwony przycisk jest dla nich tak ważny, jakie są korzyści.

Weź też pod uwagę kontekst roli każdego z interesariuszy, bo niektórzy klienci mogą być wiceprezesem i ulegać wpływom jego asystenty, sekretarzy.

Z jednej strony nie możesz takiemu klientowi powiedzieć formalnie przy innych: „Nie podoba mi się twój czerwony przycisk”, bo to by go zdyskredytowało. Jednocześnie trzeba przeanalizować, czy on naprawdę tego potrzebuje, czy chce tylko pokazać swoją ważność przed innymi.

  1. Informal – rozmowa z zainteresowanymi osobami

Kiedy już przeanalizujesz dla siebie, jakie są niuanse, złożoności, problemy, opcje rozwiązania zmiany i zrozumiesz je – możesz kontynuować ocenę poprzez nieformalny proces komunikacji z zaangażowanymi osobami. Twój zespół może powiedzieć, że czerwony przycisk nie jest odpowiedni dla nie funkcjonalnych wymagań interakcji użytkownika z UI, na przykład kolor czerwony może być zbyt drażniący dla osób o osobliwej percepcji.

Po dyskusji możesz zebrać tych samych trzech klientów i powiedzieć: „Czerwony przycisk nie jest odpowiedni dla osób z wadami wzroku. Zielony przycisk przechodzi, ale nasi analitycy zrobili analizę rynku i stwierdzili, że zielone przyciski są bardzo rzadko używane”.

Na wszystkie te informacje można nałożyć poziom wpływu interesariuszy, czyli jeśli wiesz, która z trzech osób jest najważniejsza, możesz przedstawić wszystko tak, aby wybrać jego przycisk, i jest prawdopodobne, że on sam będzie potem negocjował z pozostałymi.

  1. Formal – etap formalny

Klienci mogą powiedzieć: „OK, przekonał nas Pan do tego przycisku, ale zostały jeszcze dwa inne. Nadal chcielibyśmy zrozumieć, jak wybrać między nimi”. Dopiero na tym etapie można sformalizować zadanie lub dokument i powiedzieć: „Oto podjęliśmy te decyzje, pozostaje ostatnie pytanie”. Klienci wiedzą, że BA wszystko z nimi omówił, wszystko zrozumieli, dostali wszystkie za i przeciw. Później klienci wrócą do zadania formalnego i wybiorą jeden przycisk.

Korzyści z takiego podejścia krok po kroku są dwie: będzie decyzja o zmianie, z którą wszyscy się zgadzają i nie ma negatywnego nastawienia do dostawcy (BA lub jakiegokolwiek uczestnika projektu).

Zaangażowanie zespołu

Jak analityk biznesowy powinien we właściwy sposób pracować ze zmianami

Mówiąc o zespole, mam na myśli wszystkich zaangażowanych: PM, delivery lub techniczny manager, główny analityk, tester, DevOps. Jeśli ludzie na dowolnym poziomie w twoim zespole nie rozumieją potrzeby zmiany, będzie to miało wpływ na aplikację, obsługę wniosków i kontekst jako całość.

Aby zwiększyć zaangażowanie zespołu, doświadczony BA buduje procesy biznesowe przy użyciu różnych narzędzi. Oczywiście w projekcie jest PM, który może powiedzieć: „Mamy change request management, proces zmiany jest opisany, tu jest strona w Wiki, Confluence, dowolne zasoby. Przeczytajcie to i jak przyjdzie zmiana, to pracujcie nad nią”.

Jednak moim zdaniem analityk biznesowy powinien działać jako łącznik między biznesem a częścią techniczną, jako przewodnik między klientem a projektem. I w przeważającej części staram się przyjąć taką rolę łącznika, niezależnie od tego, co robią wszyscy inni.

To, na czym się skupiam, to angażowanie zespołu w zmianę:

Proces

W jakim stopniu ludzie rozumieją, jak przetwarzamy zmiany w projekcie?

Zadaniem BA jest upewnienie się, że wszyscy rozumieją proces na poziomie przetwarzania i wdrażania rozwiązania.

Istnieją scenariusze, w których BA zrobił wszystko jak należy: przeszedł przez fazę osobistej oceny zmiany, przeanalizował zmianę, przeszedł do fazy formalnej i stworzył zadanie.

A potem Dev Lead, który codziennie rano kontroluje backlog, zobaczył ticket, zdecydował, że change request ma priorytet – i niezwłocznie przekazał go do developmentu.

Jeśli Dev Lead nie zna procesu przetwarzania zmian, nie wie, że czekamy na komentarz od klienta lub BA powinien był napisać: „Wszystko zostało omówione, zmiana statusu na tak i tak”.

Gdy po prostu powiedzą: „Przetwarzajmy zmianę”, każdy usłyszy coś innego. Ludzie rozumieją to samo zadanie na różne sposoby. Nawet w codziennym życiu, jeśli poprosisz o zrobienie kanapki z kiełbasą i serem, ktoś zrobi dwa kawałki sera i jeden kawałek kiełbasy, a ktoś zrobi 6 kawałków kiełbasy i 1 ser.

Dlatego proces można opisać w Wiki, ale lepiej zorganizować jedną rozmowę i upewnić się, że wszyscy tak samo rozumieją.

Znaczenie zmiany

Ważne jest, aby zespół rozumiał nie tylko proces – „Jak” przetwarzamy zmianę, ale także „Dlaczego”, co ona robi dla użytkowników, klientów czy całego biznesu. To do analityka biznesowego należy przekazanie zespołowi znaczenia i wszystkich horyzontów zmiany.

Co to zrobi dla biznesu: na przykład, co te trzy przyciski zrobią dla klientów? Powiedzmy, że czerwony przycisk – przyspieszy reakcję użytkownika na wydanie jakiejś części w fabryce, a wydajność wzrośnie o 40 procent.

Zrozumienie znaczenia wpływa na proces. Z mojego doświadczenia wynika, że dla zespołu, który będzie pracował nad zmianą: pisząc jakąś banalną linijkę kodu, w formacie „zmień klasę, dodaj funkcję” itp. osobiście ważne jest zrozumienie wartości implementacji, co daję tą zmianą?

Na przykład, jeśli zmieni się interfejs obsługi zakupionego vouchera, użytkownikowi staje się wygodniej pracować, widzi przydatne funkcje i może poprawnie obsłużyć voucher itp.

Terminologia

Zmianami zajmują się najczęściej Analitycy Biznesowi, Project Managerowie lub Architekci. Jednak wielokrotnie w trakcie mojej pracy kontrolowałem i zdążałem na czas, gdy osoby w zespole, które nie są zaangażowane w przetwarzanie zmian na etapie ich powstawania, takie jak Dev Lead czy QA, brały odpowiedzialność za change request.

Zdarzają się sytuacje, gdy na zlocie klient mówi: „Zastanawiam się, który przycisk zrobić: zielony, czerwony czy niebieski” – a Dev Lead natychmiast odpowiada: „OK, przygotujemy to change request i opracujemy go”.

Zdanie to brzmi normalnie, ale w kontekście terminologii istnieje ważny przedrostek do tego zdania. Jest nim słowo „możliwe”.

Omawiając coś z klientem, nigdy nie obiecuję: „Omówię, przygotuję lub przeanalizuję ten wniosek o zmianę”. Zawsze mówię: „To jest potencjalna lub możliwa zmiana i ja się nią zajmę”.

Kiedy obiecujesz: „Przeanalizuję wniosek i udzielę odpowiedzi”, dla niektórych klientów brzmi to jak naruszenie przejrzystości procesu. Klient może pomyśleć, że wydajesz już change request bez wcześniejszej dyskusji.

Jak analityk biznesowy powinien we właściwy sposób pracować ze zmianami

Odpowiedzialność analityka biznesowego

Praca ze zmianą jest działaniem wysokiego ryzyka na każdym etapie,

gdzie nie ma miejsca na „nie wiem/zapomniałem” lub „sam to zrobiłem/pomyślałem, że tak będzie lepiej”.

Niezależnie od wstępnej wielkości wizualnej, zmiana może spowodować krytyczne konsekwencje, więc nawet wniosek na punktowego poziomu nigdy nie może być oceniany jako coś prostego.

Odpowiedzialnością analityka biznesowego jest ocena zmiany, a następnie, prawidłowo zbudować pracę z klientem i zespołem. Chodzi o to, aby być odpowiedzialnym na swoim poziomie, aby zrozumieć, kto podejmuje decyzje i gdzie. Dotyczy to zarządzania interesariuszami, i to nie tylko w odniesieniu do klientów zewnętrznych: możesz mieć ekspertów domenowych, jednego lub więcej architektów w swoim zespole – oni również muszą być włączeni w proces decyzyjny.

Tworzenie i przyjmowanie zmian w istniejącym produkcie, zwłaszcza w produkcie w trakcie programowania, jest prawie zawsze związane z wysokim ryzykiem: kiedy pojawia się wniosek o zmianę, BA nie może i nie powinna powiedzieć: „Wiem, że to zajmie 5 sekund albo że to zajmie 100 dni”. Aby uniknąć krytycznych konsekwencji, trzeba z takim samym poziomem odpowiedzialności traktować to, co wygląda bardzo poważnie i małe, pozornie punktowe zmiany.

Ulia Dniprova

Ulia jest copywriterką IAMPM. Zawsze gotowa udzielać porad młodym autorom i po prostu uwielbia rozmawiać o marketingu, tekstach i znaczeniach.