Od potrzeby biznesowej do działającej funkcji. Co ginie po drodze?

„Potrzebujemy dodatkowego raportu.”

Zgłoszenie wydaje się jasne. Trzeba przygotować widok pokazujący określone dane, dodać filtry, możliwość eksportu i udostępnić funkcję wskazanym użytkownikom.

Raport powstaje zgodnie z ustaleniami.

Po uruchomieniu okazuje się jednak, że problem pozostał.

Użytkownik nadal nie potrafi szybko ustalić, które sprawy wymagają reakcji. Część danych pochodzi z jednego systemu, część z drugiego, a status widoczny w raporcie nie zawsze odpowiada rzeczywistemu etapowi procesu.

Technicznie funkcja została wykonana poprawnie. Biznesowo nie rozwiązała problemu.

Takie sytuacje nie muszą wynikać ze źle napisanego kodu ani niedokładnej specyfikacji. Często ich źródłem jest coś mniej widocznego: pomiędzy potrzebą użytkownika a decyzją techniczną zginął kontekst, który wyjaśniał, po co dana zmiana ma powstać.

Dlatego dobra współpraca przy rozwoju systemu nie polega wyłącznie na sprawnym przekazywaniu zgłoszeń. Potrzebna jest również możliwość szybkiego sprawdzenia, czy biznes i zespół techniczny nadal rozwiązują ten sam problem.

Zgłoszenie funkcji nie jest jeszcze opisem potrzeby

Użytkownik systemu rzadko zgłasza problem w formie kompletnej analizy biznesowej. Najczęściej wskazuje rozwiązanie, które w danym momencie wydaje mu się najbardziej oczywiste.

„Potrzebuję dodatkowego pola.”

„Dodajmy nowy status.”

„Przydałby się jeszcze jeden raport.”

„Chcemy osobny ekran dla tego procesu.”

Każda z tych propozycji może być uzasadniona. Może też opisywać tylko jeden z możliwych sposobów rozwiązania problemu.

Potrzeba biznesowa opisuje rezultat, który użytkownik chce osiągnąć. Zgłoszenie konkretnej funkcji opisuje natomiast jeden ze sposobów, w jaki system miałby mu w tym pomóc.

Jeżeli rozmowa zaczyna się i kończy na oczekiwanej funkcji, zespół techniczny otrzymuje informację o tym, co zbudować, ale może nie wiedzieć, dlaczego ma to zbudować.

Wróćmy do raportu.

Użytkownik chce raportu zaległych zamówień. Dopiero kolejne pytania pokazują, że jego rzeczywistym problemem nie jest brak zestawienia. Chce wiedzieć, które zamówienia wymagają interwencji. Obecny status nie zawsze odzwierciedla informacje z drugiego systemu, a część wyjątków trzeba sprawdzać ręcznie.

Prośba o nową funkcję często opisuje objaw problemu, a nie jego przyczynę.

W tym przypadku brak raportu jest objawem. Przyczyną może być niepełny status procesu albo niespójny przepływ danych.

Raport nadal może okazać się potrzebny. Może się jednak okazać, że skuteczniejsze będzie poprawienie sposobu wyznaczania statusu, uzupełnienie wymiany danych albo zmiana istniejącego widoku.

Bez poznania celu użytkownika trudno to właściwie ocenić.

Co ginie po drodze od biznesu do osoby technicznej

Informacja o potrzebie rzadko trafia bezpośrednio od użytkownika do osoby, która projektuje zmianę.

W projekcie mogą uczestniczyć właściciel procesu, przełożony użytkownika, wewnętrzny dział IT, konsultant, analityk, project manager, support i zespół programistyczny. Każda z tych ról może być potrzebna.

Ryzyko powstaje wtedy, gdy informacja jest wielokrotnie streszczana i przekazywana dalej, a osoba podejmująca decyzję techniczną nie ma możliwości szybkiego sprawdzenia jej znaczenia u źródła.

Na początku komunikat może brzmieć:

„Potrzebujemy wiedzieć, które zamówienia stoją i wymagają reakcji, bo obecny status nie zawsze odpowiada sytuacji w magazynie.”

Po pierwszym przekazaniu:

„Potrzebny jest raport zaległych zamówień.”

Po kolejnym:

„Dodać raport zamówień ze statusem X.”

Do zespołu technicznego może ostatecznie dotrzeć zadanie:

„Nowy raport z filtrem statusu X.”

Każde kolejne zdanie jest bardziej konkretne technicznie. Jednocześnie zawiera mniej informacji o pierwotnym problemie.

Po drodze mogą zniknąć cel biznesowy, sposób pracy użytkownika, wyjątki, zależności od innych systemów, przyczyna problemu i informacja o tym, po czym poznamy oczekiwany efekt.

W rezultacie można bardzo dobrze wykonać zadanie, które nie powinno było zostać zdefiniowane właśnie w taki sposób.

Im dalej decyzja techniczna znajduje się od źródła potrzeby, tym ważniejsza staje się możliwość szybkiego odtworzenia jej kontekstu.

Krótka pętla informacji chroni kontekst

Wyspecjalizowane role w projekcie są potrzebne. Analityk może uporządkować wymagania, konsultant pomóc zrozumieć proces, project manager pilnować zakresu, a pierwsza linia wsparcia przejąć sprawy, które nie wymagają angażowania zespołu technicznego.

Problem pojawia się dopiero wtedy, gdy kolejne etapy komunikacji utrudniają powrót do źródła informacji.

Problemem nie jest liczba osób uczestniczących w projekcie. Problem pojawia się wtedy, gdy wraz z każdym przekazaniem informacji trudniej wrócić do jej źródła i sprawdzić pierwotny cel.

Dlatego kluczowa jest możliwość szybkiej weryfikacji.

Jeżeli programista lub architekt widzi, że wymaganie może mieć inne konsekwencje niż zakładano, powinien móc zweryfikować je z osobą znającą proces. Jeżeli użytkownik widzi makietę albo pierwszą wersję rozwiązania i stwierdza, że nie odpowiada ona jego sposobowi pracy, informacja powinna szybko wrócić do zespołu.

Krótka pętla informacji nie zastępuje analizy ani procesu projektowego. Chroni przed sytuacją, w której kolejne decyzje są poprawne formalnie, ale coraz dalej od pierwotnej potrzeby.

Czasem najlepszym rozwiązaniem nie jest nowa funkcja

Dojrzały rozwój systemu nie powinien polegać na zamienianiu każdej potrzeby w kolejną pozycję na liście funkcji.

Jeżeli użytkownik prosi o raport, rozwiązaniem może być poprawienie informacji widocznej już w istniejącym ekranie.

Jeżeli potrzebuje dodatkowego pola, być może właściwe dane istnieją, ale pozostają w innym systemie.

Jeżeli oczekuje osobnej ścieżki dla konkretnego przypadku, czasem lepiej zmienić konfigurację lub regułę procesu niż budować kolejny wyjątek.

Odpowiedzialny partner technologiczny nie powinien jedynie pytać, jak zrealizować zgłoszoną funkcję. Powinien najpierw sprawdzić, czy właśnie ta funkcja jest najlepszą odpowiedzią na problem.

Nie oznacza to kwestionowania każdej decyzji klienta. Oznacza wykorzystanie wiedzy technicznej do oceny możliwych rozwiązań i ich konsekwencji przed rozpoczęciem implementacji.

Ma to szczególne znaczenie w systemach rozwijanych przez wiele lat. Nowa funkcja staje się częścią rozwiązania, które trzeba później testować, utrzymywać i dalej rozwijać.

Jeżeli ten sam efekt można osiągnąć prościej, warto wiedzieć o tym przed napisaniem kolejnej warstwy kodu.

Zanim zdecydujemy, co zbudować, warto odpowiedzieć na sześć pytań

Nie każda zmiana wymaga rozbudowanej analizy. Często wystarczy krótka rozmowa, która pozwala sprawdzić, czy obie strony rozumieją problem tak samo.

Po co potrzebna jest zmiana?

Jaki konkretny problem ma zniknąć albo jaka czynność ma stać się łatwiejsza?

Kto będzie korzystał z rozwiązania?

Ten sam mechanizm może mieć inne znaczenie dla pracownika operacyjnego, kierownika i osoby analizującej dane.

W którym momencie procesu pojawia się problem?

Znaczenie informacji zależy od tego, co wydarzyło się wcześniej i co ma wydarzyć się później.

Na jakich danych opiera się decyzja?

Trzeba wiedzieć nie tylko, jakie informacje są potrzebne, ale również skąd pochodzą i które źródło jest rozstrzygające.

Co jest sytuacją wyjątkową?

Brak danych, korekta dokumentu, nietypowy status czy opóźnienie w innym systemie mogą zmienić sposób, w jaki proces powinien być obsłużony.

Po czym poznamy, że zmiana przyniosła oczekiwany efekt?

Kryterium sukcesu powinno odnosić się do rezultatu biznesowego, a nie tylko do obecności nowego pola, przycisku czy raportu.

Odpowiedzi na te pytania nie przesądzają jeszcze, że potrzebna jest nowa funkcja. Pozwalają natomiast zdecydować, co rzeczywiście warto zmienić.

Pomocne mogą być również makieta, prosty prototyp albo realizacja ograniczonego zakresu. Ich wartość nie polega wyłącznie na pokazaniu wyglądu rozwiązania. Pozwalają sprawdzić, czy biznes i zespół techniczny tak samo rozumieją sposób jego działania.

Krótka droga do wiedzy technicznej nie może oznaczać zależności od jednej osoby

Bezpośredni kontakt z osobą techniczną daje wartość tylko wtedy, gdy nie prowadzi do sytuacji, w której cały kontekst klienta istnieje w pamięci jednego człowieka.

Wiedza o systemie powinna być zachowywana w dokumentacji, historii zmian, repozytorium decyzji oraz w zespole.

Rolę krótkiej drogi do wiedzy technicznej może wspierać model stałego opiekuna-programisty, który zna środowisko klienta i potrafi szybko przejść od zgłoszonego problemu do oceny jego konsekwencji technicznych.

Nie oznacza to jednak, że tylko jedna osoba powinna rozumieć rozwiązanie.

Stały opiekun ma ułatwiać dostęp do kontekstu, a nie tworzyć jego jedyny magazyn.

Historia systemu ma znaczenie również dlatego, że pozornie prosta zmiana może wynikać z decyzji podjętych kilka lat wcześniej.

Dlaczego określony status działa właśnie w taki sposób? Dlaczego dane pochodzą z jednego systemu, a nie z drugiego? Dlaczego dla konkretnego procesu istnieje wyjątek?

Bez wiedzy o wcześniejszych decyzjach łatwo zmienić jeden element bez świadomości konsekwencji dla pozostałych.

Ciągłość wiedzy jest więc częścią jakości rozwoju systemu, a nie wyłącznie kwestią organizacji zespołu.

Jak sprawdzić, czy sposób współpracy chroni kontekst

Jakość współpracy warto oceniać nie tylko przez szybkość realizacji zgłoszeń. Równie ważne jest to, czy sposób pracy pozwala zachować znaczenie potrzeby od momentu jej zgłoszenia do podjęcia decyzji technicznej.

Pomocnych może być pięć pytań:

1. Czy osoba techniczna może w razie potrzeby porozmawiać bezpośrednio z właścicielem procesu?

2. Czy przed rozpoczęciem prac ustalane są cel, użytkownik i sytuacje wyjątkowe, czy wyłącznie oczekiwana funkcja?

3. Czy z góry wiadomo, po czym będzie można ocenić, że zmiana przyniosła oczekiwany efekt?

4. Czy model współpracy pozwala zaproponować rozwiązanie inne niż pierwotny pomysł i wspólnie ocenić jego konsekwencje?

5. Czy decyzje i ich uzasadnienie są dokumentowane oraz dostępne dla zespołu, a nie tylko dla jednej osoby?

Nie chodzi o to, aby każda niewielka zmiana przechodziła pełny proces analityczny.

Chodzi o możliwość sprawdzenia, czy rozwiązanie, które ma powstać, rzeczywiście odpowiada problemowi, który organizacja chce rozwiązać.

Działająca funkcja nie zawsze oznacza rozwiązany problem

Stosunkowo łatwo sprawdzić, czy funkcja została wykonana zgodnie z ustaleniami.

Trudniejsze jest pytanie, czy ustalenia prowadziły do właściwego rozwiązania.

Długi łańcuch komunikacji nie musi być problemem, jeśli zachowuje kontekst i pozwala go szybko zweryfikować. Krótka ścieżka również nie gwarantuje dobrego rozwiązania, jeśli decyzje nie są dokumentowane i nie można odtworzyć powodów ich podjęcia.

Najważniejsza jest jedna zasada:

osoba podejmująca decyzję techniczną powinna wiedzieć nie tylko, co ma powstać, ale również dlaczego ma powstać.

Dopiero wtedy można świadomie zdecydować, czy potrzebny jest nowy raport, dodatkowe pole, zmiana konfiguracji, integracja - czy może zmiana samego procesu.

Zanim powstanie lista funkcji, warto porozmawiać o problemie

Jeżeli planujesz zmianę w systemie i masz już listę oczekiwanych funkcji, warto przed wyceną sprawdzić, jaki problem biznesowy stoi za najważniejszymi z nich.

Czasem rozmowa potwierdzi pierwotny kierunek.

Czasem pozwoli uprościć zakres.

A czasem pokaże, że rozwiązania należy szukać w innym miejscu niż początkowo zakładano.

Chcesz sprawdzić, czy lista funkcji rzeczywiście odpowiada problemowi biznesowemu?

Porozmawiajmy o procesie, który wymaga zmiany, zanim powstanie ostateczna lista funkcji do wyceny.

Porozmawiajmy o procesie i możliwym rozwiązaniu.

FAQ

Czym różni się potrzeba biznesowa od zgłoszenia konkretnej funkcji?

Potrzeba biznesowa opisuje rezultat, który użytkownik lub organizacja chce osiągnąć, np. szybsze rozpoznanie zamówień wymagających interwencji. Zgłoszenie funkcji wskazuje jeden z możliwych sposobów osiągnięcia tego rezultatu, np. stworzenie dodatkowego raportu. Dlatego przed rozpoczęciem prac warto sprawdzić, czy zaproponowana funkcja rzeczywiście odpowiada na źródło problemu.

Dlaczego funkcja zgodna ze specyfikacją może nie rozwiązać problemu biznesowego?

Specyfikacja może poprawnie opisywać oczekiwaną funkcję, ale nie uwzględniać pełnego kontekstu potrzeby. Jeżeli po drodze znikną informacje o celu, wyjątkach, danych lub sposobie pracy użytkownika, zespół techniczny może prawidłowo wykonać zadanie, które nie usuwa rzeczywistej przyczyny problemu. Zgodność ze specyfikacją nie jest więc jeszcze równoznaczna z osiągnięciem oczekiwanego efektu biznesowego.

Kiedy warto zakwestionować pierwotny pomysł na funkcję?

Warto to zrobić wtedy, gdy analiza pokazuje, że problem można rozwiązać prościej albo znajduje się on w innym miejscu niż początkowo zakładano. Zamiast nowej funkcji właściwym rozwiązaniem może być zmiana konfiguracji, poprawa przepływu danych, wykorzystanie istniejącego mechanizmu lub modyfikacja procesu. Chodzi nie o podważanie pomysłu użytkownika, lecz o wybór rozwiązania najlepiej odpowiadającego jego potrzebie.

Jak ograniczyć utratę kontekstu między biznesem a zespołem technicznym?

Najważniejsza jest możliwość szybkiej weryfikacji założeń między osobą znającą proces a osobą podejmującą decyzję techniczną. Pomagają w tym krótka pętla informacji zwrotnej, jasno opisany cel zmiany, uwzględnienie sytuacji wyjątkowych oraz dokumentowanie decyzji i ich uzasadnienia. Wiedza o potrzebie powinna być dostępna dla zespołu, a nie pozostawać wyłącznie w pamięci jednej osoby.