„Potrzebujemy chatbota”, „musimy wdrożyć CRM”, „dodajmy pole obowiązkowe” — każde z tych zdań może opisywać rozsądny pomysł, ale żadne samo w sobie nie jest potrzebą biznesową. Potrzeba mówi, jaki problem lub cel wymaga reakcji. Rozwiązanie mówi, w jaki sposób zamierzamy na niego odpowiedzieć.
Oddzielenie tych dwóch warstw nie ma blokować pomysłów. Pozwala sprawdzić ich zasadność, porównać koszt i ryzyko oraz uniknąć sytuacji, w której zespół optymalizuje narzędzie, nie wiedząc, jaki wynik ma ono poprawić.
Szybki test: potrzeba czy rozwiązanie?
| Zdanie | Co naprawdę opisuje? | Pytanie otwierające analizę |
|---|---|---|
| Klient ma śledzić przesyłkę w aplikacji | Funkcję | Jakiej informacji klient dziś nie otrzymuje i z jakim skutkiem? |
| 25% klientów dzwoni, bo nie zna terminu dostawy | Problem | Jaki poziom samoobsługi chcemy osiągnąć? |
| Wdrożymy automatyczne przypomnienia | Wariant rozwiązania | Dlaczego zadania są pomijane i kiedy przypomnienie pomoże? |
| Zmniejszyć liczbę spraw po terminie z 14% do 5% | Cel biznesowy | Jakie przyczyny odpowiadają za opóźnienia? |
Prosty test polega na pytaniu: „gdyby ten pomysł był niemożliwy do wdrożenia, czego nadal byśmy potrzebowali?”. Odpowiedź zwykle prowadzi do efektu, użytkownika albo problemu i odkleja rozmowę od jednego narzędzia.
Przypadek: obowiązkowe pole w formularzu
Dział rozliczeń prosi, aby w formularzu zamówienia dodać obowiązkowe pole „centrum kosztów”. Rozwiązanie wydaje się małe. Analiza trzech odrzuconych zamówień pokazuje jednak, że użytkownicy często nie znają centrum w chwili składania wniosku, a właściwa wartość zależy od rodzaju zakupu i projektu.
Potrzeba brzmi: „księgowość musi przypisać każde zaakceptowane zamówienie do prawidłowego centrum kosztów przed eksportem do systemu finansowego; dziś 12% rekordów wraca do ręcznego wyjaśnienia”. Pole obowiązkowe przesuwałoby błąd na wcześniejszy etap, ale nie zapewniałoby poprawności.
Zespół rozważa więc trzy warianty: ręczne pole, automatyczne wyliczenie na podstawie projektu oraz wybór z ograniczonej listy zatwierdzonej przez właściciela budżetu. Ocena rzeczywistej potrzeby zmienia zarówno rozwiązanie, jak i kryteria jego odbioru.
Macierz wariantów zamiast konkursu opinii
| Kryterium | Waga | Pole ręczne | Wyliczenie | Lista zatwierdzona |
|---|---|---|---|---|
| Poprawność przypisania | 5 | Niska | Wysoka przy pełnych danych | Wysoka |
| Wysiłek użytkownika | 3 | Wysoki | Niski | Średni |
| Koszt wdrożenia | 2 | Niski | Wysoki | Średni |
| Obsługa wyjątków | 4 | Słaba | Wymaga reguł | Możliwa przez właściciela |
Macierz nie podejmuje decyzji za właściciela biznesowego. Ujawnia kryteria i kompromisy. Wagi powinny wynikać z celu oraz ograniczeń, a oceny — z danych, prototypu albo konsultacji technicznej, nie z pewności osoby najgłośniej broniącej swojego wariantu.
Kiedy gotowe rozwiązanie może być uzasadnionym ograniczeniem
Czasem organizacja świadomie wybiera platformę korporacyjną, standard architektoniczny albo produkt wymagany przez regulację. Wtedy rozwiązanie nie jest hipotezą, lecz ograniczeniem projektu. Nadal warto zapisać potrzebę, bo pozwala ocenić konfigurację, zakres i późniejszy efekt.
Podobnie w przypadku poprawki błędu: jeśli system oblicza podatek niezgodnie z obowiązującą regułą, przestrzeń wariantów może być mała. Mimo to trzeba nazwać oczekiwane zachowanie, źródło reguły i przypadki testowe. „Zmień algorytm” pozostaje zbyt ogólne.
Rozmowa, która nie odrzuca pomysłu
Zamiast odpowiadać „to rozwiązanie, nie wymaganie”, warto powiedzieć: „zapiszmy ten pomysł jako wariant i doprecyzujmy wynik, który ma zapewnić”. Następnie zapytać o ostatni przypadek problemu, jego częstotliwość, odbiorców, konsekwencje oraz ograniczenia. Takie podejście zachowuje wiedzę pomysłodawcy, ale umożliwia weryfikację.
Wariant „nic nie zmieniać” i koszt alternatywny
Brak wdrożenia również jest decyzją. W macierzy uwzględnij wariant pozostawienia obecnego procesu i policz jego koszt: czas ręcznej pracy, błędy, utracone sprawy, ryzyko regulacyjne oraz wpływ na klientów. Dzięki temu inwestycja jest porównywana z rzeczywistym punktem odniesienia, a nie z abstrakcyjnym zerem.
Trzeba też uwzględnić koszt alternatywny. Zespół realizujący panel nie wykona w tym czasie innej zmiany. Wariant o największej liczbie funkcji może więc przynieść mniejszą wartość niż mała korekta procesu wdrożona szybko. Kryteria porównania powinny obejmować czas do efektu, koszt utrzymania oraz odwracalność.
Pilot zamiast deklaracji
Gdy nie wiadomo, który wariant zadziała, zaprojektuj tani test. Przed budową automatycznego przypisania centrum kosztów można przez tydzień przygotowywać podpowiedź według proponowanej reguły i mierzyć, ile razy właściciel budżetu ją poprawia. Wynik pokaże jakość danych oraz liczbę wyjątków.
Pilot powinien mieć hipotezę, miarę, próg decyzji i ograniczony czas. „Sprawdźmy przez jakiś czas” nie tworzy wiedzy. Zapisz na przykład: jeśli co najmniej 95% podpowiedzi będzie poprawnych, automatyzujemy przypadek podstawowy; pozostałe trafiają do wyboru ręcznego. Jeśli wynik będzie niższy, wracamy do modelu danych.
Checklista przed wyborem rozwiązania
- Problem jest opisany niezależnie od funkcji lub produktu.
- Znana jest wartość bazowa i oczekiwany efekt.
- Potwierdzono przyczyny, na które rozwiązanie ma wpływ.
- Pomysł ma status wariantu albo jawnego ograniczenia.
- Rozważono co najmniej alternatywę procesową i wariant bez zmiany.
- Kryteria porównania wynikają z potrzeby, kosztu i ryzyka.
- Decyzja ma właściciela oraz zapisane uzasadnienie.
- Po wdrożeniu zostanie zmierzony rezultat biznesowy.
Po wyborze wariantu wróć do pierwotnej miary. Kryteria akceptacji potwierdzą, że rozwiązanie wykonano zgodnie z zakresem, lecz dopiero pomiar po wdrożeniu pokaże, czy zniknął problem. Ustal wcześniej moment oceny i osobę, która podejmie decyzję o rozwinięciu, korekcie albo wycofaniu rozwiązania. Porównaj rezultat także z wariantem bazowym i zmianami otoczenia.
Do przygotowania punktu startowego użyj wzoru opisu potrzeby biznesowej. Gdy zespół wybierze wariant, zapisz jego kontekst zgodnie z poradnikiem jak dokumentować decyzje projektowe.
