Definicja potrzeby

10 lipca, 2021 przez Stary Zgred

Rozwiązania informatyczne

czyli Usługi IT powinny adresować określone potrzeby użytkowników.

Definicja potrzeby jednoznacznie zdefiniowana i rozumiana przez wszystkich zwiększa prawdopodobieństwo sukcesu 😀.

Stwierdzenie wydaje się oczywiste, ale jak to z oczywistościami bywa,
ich zdefiniowane, a tym bardzie zapisanie bywa trudne 😮.

Jeżeli dodatkowo zadamy pytanie jaką to przyniesie wartość dodaną dla naszego biznesu?
Co nam to da??? – inna wersja pytania,
to jeżeli nie zostaniemy nazwani hamulcowymi to będziemy mieć szczęście 😐.

Z drugiej strony podstawą decyzji czy coś robić, albo który wariant wybrać powinien być Business Case (w polskojęzycznej wikipedii), w największym skrócie ocena kosztów vs. korzyści.

Nie znając potrzeby, którą chcemy zaadresować trudno będzie określić jakie korzyści przyniesie nam wdrożenie określonego rozwiązania 😳.
A wyrażenie ich w PLN to czysta abstrakcja 😛.

Bardzo częstym błędem w zdefiniowaniu potrzeby jest używanie w definicji potrzeby listy funkcjonalności, które chcemy aby były realizowane.
To tak samo jak pomylenie celu podroży ze środkami transportu, które wykorzystujemy, aby znaleźć się u celu 😈.

Użyłem liczby pojedynczej w tytule, ponieważ uważam, że realizowanie projektów adresujących wiele potrzeb to prosty przepis na klęskę projektu.

Nie istniej panaceum na wszystkie choroby ….
Tak samo nie istniej projekt adresujący wszystkie potrzeby …

Adresując wiele problemów jednocześnie, bardzo szybko trafimy na przypadek, że będziemy usieli wybrać
Który cel jest ważniejszy 😳.
Jak implementować poszczególne funkcjonalności,
które realizujemy, … 🙂 a z których rezygnujemy, … 🙁
Będą one sprzeczne 😐
albo szukamy bardziej skomplikowanego rozwiązania,
ale wówczas będzie to kosztowne 😕.

Priorytety

Jeżeli już chcemy zaadresować kilka potrzeb, to nie pozostaje nic innego jak określić ich priorytety.

Prosta klasyfikacja musi być vs. miło by było (must be vs. nice to have) może nie wystarczyć 😳.

Aby zawsze mieć jasną odpowiedź co jest ważniejsze musimy umieścić je na liście od najważniejszego do najmniej ważnego 😮.
Życzę powodzenia w tworzeniu takiej listy 🙂, trochę złośliwy komentarz, ale doświadczenie robi swoje .

Propozycja działania

Osoba z cohones kładzie na stół propozycję według swojej najlepszej wiedzy. a gracze niech grupowo to znaczy przy akceptacji wszystkich dokonają zmiany 🙂.
Twardziel może stać i czekać na finalną wersję, jedyna rzecz do przypilnowania terminy, bo dyskusje mogą długo trwać.
Z drugiej strony do czasu zmiany obowiązuje ta ogłoszona 😈.

Ciąg dalszy

Rozwiązania informatyczne są używane przez dłuży czas, to oczywistym jest, że potrzeba/potrzeby mogą ulec zmianie 😳.

Wówczas należy je adresować stosując dokładnie taką samą logikę jak przedstawiona powyżej.
Możemy w tym przypadku mieć dwa różne przypadki.

Pierwszy przypadek, to potrzeba zmian funkcjonalnych zgłaszana przez biznes, np.: obsługa nowego typu dokumentu lub zdarzenia albo rozszerzenie naszego biznesu (nowe obszary) 😀.

Drugi przypadek jest trudniejszy do zdefiniowania, ale zazwyczaj objawia się problemami operacyjnymi zaobserwowanymi przez biznes jako problemy w funkcjonowaniu rozwiązania.
Przyczyny mogą być różne, ale najczęściej to:

• obciążenie większe niż przewidziano w trakcie tworzenia rozwiązania
• znaczący wzrost znaczenia funkcji, która na etapie projektowania było mało istotna 😛
• użycie rozwiązania niezgodnie z jego pierwotnym przeznaczeniem 😳

Powyższe powoduje, że mamy braki zasobów, określane jako niedobór mocy obliczeniowej – choć nie zawsze dosypanie CPU pomaga 👿, gdyż niedoszacowana funkcja była nieoptymalnie zaimplementowana 😐.

Niezależnie od tego z którym przypadkiem mamy się mierzyć, zawsze kluczem do rozwiązania będzie definicja potrzeby, czyli jednoznaczne określenie priorytetów potrzeb lub problemów.

Na co zwracać uwagę czyli jak radzić sobie z tym węzłem gordyjskim w kolejnych wpisach 🙂.

ZAPRASZAM

Komentarze |0|