Chce != potrzebuje

Ciężki chleb powszedni związany z wymaganiami to… nie uleganie koncertowi życzeń. Użytkownicy dużo chcą, czasem biznes chce nawet za to zapłacić ale… No właśnie, czy jest tu ale? Może IT powinno się cieszyć, że ma robotę?

Kogo słuchać?

To może zacznijmy od tego, od kogo zbierać wymagania? Użytkownik końcowy, użytkownik kluczowy a może właściciel biznesowy? Nie ma idealnej odpowiedzi i na pewno trzeba wysłuchać wszystkich, którzy w temacie są zainteresowani (czyli pozostałych interesariuszy, których nie wymieniłam także ;)). Zwłaszcza w agile kładzie się nacisk na słuchanie użytkownika, ale… No właśnie jest ale. Nie mówię, tu że użytkownik końcowy powinien zostać pominięty, aczkolwiek należy pamiętać że w większości wypadków systemy informacyjne to zespół naczyń połączonych i trzeba widzieć szerzej niż tylko swój kawałek aplikacji. Użytkownik kluczowy powinien w tym względzie być bardziej „uświadomiony” i przesiać wymagania z koncertu życzeń pod względem merytorycznym. Choć istnieje jeszcze przypadek, gdy użytkownik ani końcowy ani kluczowy nie ma nic do powiedzenia i system jest zdominowany przez właściciela biznesowego (święte jego prawo, płaci to wymaga). Jeśli za tym kryje się wizja i przy okazji dana osoba doskonale zna potrzeby użytkowników, to może tragedia się nie wydarzy. Aczkolwiek jak to jest trochę balansowanie na krawędzi przepaści (nie polecam, nawet dla osób lubiących sporty ekstremalne).

Może poprzestańmy na tym, że wysłuchać trzeba wszystkie strony. 

Co wybrać?

Kategoryzacja i wybór tego co jest do zrobienia to inna kwestia. Ciężkim kawałkiem jest wybranie tych elementów które faktycznie przybliżają biznes do osiągnięcia celu biznesowego. Jeszcze ciężej przekonać biznes, że ich wymarzona funkcjonalność nie jest potrzebna… Zaraz, zaraz – wróćmy do początku. Czy nie powinniśmy być szczęśliwi że mamy co robić, a nie odsiewać pomysły?! Odpowiedź brzmi NIE. Jak jesteśmy działem IT wewnętrznym – to zależy nam przecież aby firma nie marnotrawiła pieniędzy. Jak jesteśmy zewnętrzną firmą IT – to zależy nam na tym, aby klient był zadowolony. A nie będzie zadowolony jak dostanie funkcjonalności z których nie korzysta a do tego obraz rozpaczy dopełni  odpowiednio wysoka faktura…

Po co?

Analityk omnibusem nie jest, więc warto aby zadawał magiczne pytanie: „po co” (dlaczego to wiemy, aplikacja ma pomagać albo zarabiać, albo ciąć koszty*, wyjątek stanowią aplikacje urzędów których celem istnienia jest irytowanie petentów </joke>). Jak wiemy po co, to możemy zamodelować odpowiednie rozwiązanie. Plus doradzić co generuje koszty, a nie przybliża nas do osiągnięcia celu biznesowego (tak, tak – po to aby to wyrzucić do kosza, albo chociaż przesunąć na koniec kolejki do zrobienia i liczyć po ciuchu że z czasem upór na wykonanie danej funkcjonalności mnie). 

Podsumowanie w dwóch słowach: „po co?”. 

* ułatwienie pracy wlicza się w to. Pracownik który sprawniej wykonuje zadania (szybciej, robi mniej błędów itp.) ma większą wydajność i większe moce przerobowe. Jeśli to jest pracownik który był „wąskim gardłem” to według teorii łańcucha krytycznego, odciążenie go spowoduje szybsze wykonanie pracy. Nie wgłębiając się w teorie bardziej: wszystko sprowadza się do pieniędzy :)