sobota, 25 maja 2013

Takie podejście byłoby nie do przyjęcia, czyli coś o analizie wymagań

Czytam przedmowę Toma DeMarco do książki "Pełna analiza systemowa" autorstwa Jamesa i Suzanne Robertsonów. Zdania napisane w 1993 roku są w dalszym ciągu aktualne dzisiaj.

"Zmienił się także charakter dialogu między analitykiem, a użytkownikiem. Dawniej (przyp.: w połowie lat 80-tych) mówiliśmy "Oto, co otrzymasz". Teraz pokazujemy model i pytamy "Co myślisz o takim rozwiązaniu?" Gdy razem pochylamy się nad modelem, proces tworzenia systemu ożywa. Użytkownicy kładą rękę na modelu i zaczynają go wyginać i przekształcać. "Prawie, prawie ..." mówią. "... gdyby tylko można było zmienić to na przykład na coś takiego ...". Gdy zaczyna się taki dialog, wiemy, że projekt jest na dobrej drodze.
Gdy po raz pierwszy pokazujemy użytkownikowi model, wiemy z góry, że jest on najwyżej zbliżony do tego, czego użytkownik oczekuje. Pokazujemy model właśnie po to, by sprowokować zmiany."

Dialog z użytkownikiem

Dla mnie dialog z użytkownikiem zawsze był podstawą dobrego zrozumienia wymagań wobec projektowanego rozwiązania. Jak jednak połączyć umiejętność prowadzenia dialogu z inżynierią? Mówi się o inżynierii oprogramowania, inżynierii wymagań, inżynierii systemów. I automatycznie zawęża to obszar kompetencji do ściśle inżynierskich, technicznych.

Też jestem z wykształcenia informatykiem, ale tylko magistrem po uniwersytecie. Nie jestem inżynierem, więc nigdy nie przyszło mi do głowy, żeby dialog z użytkownikiem sprowadzić do określenia "algorytm postępowania". Niestety, takie podejście do użytkownika, jako osoby, która nie rozumie, co się do niej mówi i nie wie, czego chce, spotyka się w pewnych zamkniętych środowiskach.

Z Forum Jakości SI 2013 wyniosłam spostrzeżenia, że coraz więcej mówi się o jakości w kontekście użytkownika, zadowolenia klienta. Wydaje się, że pomocne w takim podejściu są wszelkie metodyki Agile, które zakładają iteracyjne wytwarzanie oprogramowania, przy ścisłej współpracy z użytkownikiem. Wiele prelekcji dotyczyło właśnie tego typu podejścia, chociaż nie jest to panaceum na wszystkie bolączki i nie zawsze można je wdrożyć w organizacji.

Inżynieria wymagań

Zastanawiam się, czy określenie "inżynieria" nie ma konotacji zawężającej je wyłącznie do obszarów wiedzy technicznej. A inżynieria wymagań ma w sobie wiele aspektów "miękkich", począwszy od zbierania wymagań na etapie badania marketingowych, działań sprzedażowych, poprzez wszystkie etapy wytwarzania, ergonomii interfejsu i przekazania klientowi (rozbudowana wersja klasycznego rysunku http://www.projectcartoon.com/cartoon/2).

Warto się będzie nad tym zastanowić, także w kontekście organizowanej w październiku konferencji Dobre Wymagania 2013.

Skłoniła mnie do tej refleksji dyskusja na LinkedIn, a dotycząca inżynierii systemów - pojęcia także funkcjonującego w poprzek wielu branż, natomiast zazwyczaj znanego wyłącznie w perspektywy danej branży, w której funkcjonujemy. Jak się w tym nie pogubić ...? Może przydatny będzie dokument opisujący dwanaście zawodów-roli w ramach inżynierii systemów, przytoczony w tej dyskusji.

Konkluzja

Świat pędzi do przodu, powstają nowe zawody, uczelnie nie nadążają z dostosowywaniem edukacji do potrzeb rynku. Może więc system edukacji musi się jakoś zmienić? Należałoby może odróżnić kształcenie akademickie od kształcenia w kierunku jakiegoś zawodu. Gdzie można zdobyć kwalifikacje do przytoczonych w dokumencie 12 zawodów w ramach inżynierii systemów? Niektóre kompetencje wykraczają zdecydowanie poza stricte techniczne.



2 komentarze:

  1. W dialogu analityk-użytkownik obie strony mogą zadawać sobie regularnie pytania:
    - Czy na pewno rozumiem co ona/on do mnie mówi?
    - Jeśli na pewno rozumiem, to skąd mam tę pewność?
    Pytania te stają się szczególnie istotne, gdy w komunikacji używane są słowa-klucze - takie słowa, których znaczenie jest powszechnie znane, ale konkretne znaczenie w odniesieniu do konkretnego projektu pozostaje niedodefiniowane.

    W odniesieniu do systemów IT, ważniejsze dla mnie (a jestem użytkownikiem) jest zadanie przez analityka pytania "po co?". Nie "co?" i nie "jak?", ale właśnie "po co?". Owo "po co?", nawet kilkukrotnie zadane, odnosi się do istniejących deficytów i oczekiwanych użyteczności. Dopiero gdy deficyty, oczekiwania i priorytety zostaną określone, warto przystąpić do rozmów o konkretnych rozwiązaniach i procesie dochodzenia do nich.

    OdpowiedzUsuń
    Odpowiedzi
    1. Zgadzam się z tym, co napisałeś. To, co na poziomie projektu nazywamy uzasadnieniem biznesowym - "po co?, w jakim celu?, dlaczego?" powinno mieć przełożenie na każde pojedyncze wymaganie, zgadzam się z tym absolutnie. Natomiast w praktyce nie zawsze to się obserwuje, stąd potrzeba edukowania i uświadamiania wszystkich uczestników takich dialogów.

      Usuń

Zapraszam do komentowania