zbieraniewymagan

Jak odróżnić „Pobożne życzenia” od prawdziwego wymagania biznesowego

Posted by admin

W pracy analityka biznesowego bardzo często spotykam się z przedstawicielami szeroko rozumianego biznesu. Jest to naturalna kolej rzeczy i do tego należy nasze zadanie(Analityków) żebyśmy w dobry sposób przekuli to co chce szeroko rozumiany biznes od szeroko rozumianego IT.

I w przypadku gdy rozmawiamy z przedstawicielami biznesu to bardzo często pojawiają się wymagania które są skomplikowane technicznie do wdrożenia. Przykładowo trzeba zbudować integrację z wieloma systemami tylko po to żeby wyświetlić daną którą na dobrą sprawę wystarczy raz pobrać.

Czasem powstają inne wymagania które powstają na wielu „brainstormach” które są bardzo fajną techniką ale na rozwiązywanie problemów. Moim zdaniem burze mózgów które są robione po to aby zbudować coś nowego są w 90% przerostem formy nad treścią w sztuce wytwarzania oprogramowania.

Więc w jaki sposób pozyskać wymagania które realnie pomogą interesariuszom w ich codziennej pracy bez wdrażania niepotrzebnych wodotrysków często spowalniających działanie aplikacji? Poniżej przedstawiam część swoich sposobów które lubię stosować.

1. Wejścia – wyjścia

Nie wiem czy gdzieś jest dobrze nazwana i opisana ta technika. Ten sposób wypracowałem samemu przy doświadczeniu w pracy z innymi ludźmi. Aby dobrze ją zrozumieć to musimy zrozumieć co robi system informatyczny w najprostszym ujęciu?

System informatyczny przetwarza informację.

Informacje które przetwarzamy muszą być do systemu wprowadzone i ten system te informacje ma za zadanie przetworzyć i dać efekt końcowy. Naszym celem jest poznanie efektu końcowego i wejściowego a następnie staramy się jak najbardziej uprościć trasę informacji pomiędzy wejściem a wyjściem dla osób zainteresowanych.

2. Zamodelowanie procesu

W tej technice najważniejsze jest poznanie jak krok po kroku są wykonywane wszystkie czynności. Następnie wykonujemy model procesu pracy danego użytkownika końcowego i na tej podstawie jesteśmy w stanie szybko stwierdzić co możemy zoptymalizować/ułatwić.

3. Prototypowanie

Jak tworzymy prototyp to między analitykiem a interesariuszem pojawia się automatyczne wyrównanie pojęć oraz wiedzy. W przypadku gdy powstaje prototyp to jesteśmy w stanie przed zaprogramowaniem czegokolwiek stwierdzić co jest potrzebne a co nie.

Te 3 techniki są moimi ulubionymi. Oczywiście nie każda z nich pasuje do wszystkich sytuacji i każdego projektowanego systemu ale bardzo często pozwalają na unikanie mało potrzebnych i kosztownych wymagań biznesowych które zostały niepotrzebnie wykonane( i były pieniędzmi wyrzuconymi w błoto).

SZKOLENIE "Czy zawód Analityk IT jest dla mnie?"

Zapisz się na listę mailową a prześlę za darmo szkolenie Czy zawód Analityk IT jest dla mnie? Co muszę umieć żeby być Analitykiem IT?