Witam!
W wolnych chwilach między zajęciami przeglądam ostatnimi czasy artykuły oscylujące w okolicach wytwarzania oprogramowania, jego projektowania etc. Tak się złożyło akurat, że na portalu devBlogi.pl pojawiła się ostatnio informacja o projekcie "97 rzeczy" - serii przetłumaczonych na nasz ojczysty język artykułów znanych i szanowanych autorytetów w światku informatycznym na ważne tematy, takie jak zasady dobrego projektowania. Jedną z takich "rzeczy" jest spojrzenie na nasze oprogramowanie oczami jego użytkownika. W artykule pojawia się takie oto stwierdzenie:
"(...) istnieje przepaść między tym, czego użytkownicy chcą, a tym co w rzeczywistości robią. To niepokojące jako, iż normalnym sposobem zbierania wymagań użytkownika jest wypytywanie. Dlatego właśnie najlepszą metodą wyłapania wymagań jest przyglądanie się użytkownikom. Spędzenie godziny na obserwowaniu użytkowników jest o wiele bardziej pouczające, niż spędzenie dnia na zgadywaniu tego, czego mogliby chcieć."
Przez cały dzień ta myśl prześladowała mnie i nie dawała spokoju, aż uświadomiłem sobie, że w każdym akademickim projekcie jaki wykonywałem stwierdzenie to (o zgrozo!) się sprawdzało. Ponieważ okazało się, że w najnowszym projekcie na uczelni dostaliśmy trochę wydłużony deadline, więc rozważam wprowadzenie na pewnym etapie wprowadzenia prototypu interfejsu oraz szczątkowej funkcjonalności, aby przekonać się jakie jest pokrycie wymagań umieszczonych w specyfikacji projektu w odniesieniu do realnych oczekiwań użytkowników. Aż boję się myśleć, jakie będą wyniki tego sprawdzenia ;) Ktoś ma doświadczenie w tego typu podejściu? Może mógłby podzielić się jakimiś radami/wskazówkami/materiałami? :)
Pozdrawiam i do następnego razu!
Nie no pokazywanie tego co częściowo zrobiłeś to dosyć powszechna praktyka. Natomiast to o czym tutaj piszesz to faza zbierania wymagań - idziesz i patrzysz jak pracuje Twój przyszły użytkownik - patrzysz jakie zadania wykonuje i się zastanawiasz jak Twoja aplikacja ma być zrobiona. Ja osobiście nigdy nie miałem okazji tak robić ale słyszałem, że ktoś tak kiedyś zrobił z moich znajomych - wyniki były dobre.
OdpowiedzUsuńA na ogol sprawy komplikuja sie jeszcze bardziej. Rzadko zdarza sie tworzyc software dla 1, 2, 10 uzytkownikow. Duzo czesciej liczyc by mozna ich w setkach, czy tysiacach, a w przypadku softu webowego - no coz, "world population is the limit". Powstaje wiec kwestia dla kogo tak na prawde robimy soft? Dla statystycznego uzytkownika - no nie, bo kogos takiego nie ma. Kazdy ma swoj specyficzny sposob korzystania z aplikacji, zalezacy od doswiadczenia, wieku, plci, itd., itp... Polecam obejrzeć:
OdpowiedzUsuńhttp://www.ted.com/talks/malcolm_gladwell_on_spaghetti_sauce.html
http://www.infoq.com/presentations/pragmatic-personas
Ja może spaczony jestem bo pisałem kiedyś w J2EE i w tym raczej nie programuje się dla mas a dla konkretnej firmy, która to zamawia a więc tam mają już jakieś wypracowane metody pracy i grupy użytkowników pracują mniej więcej podobnie i realnie jest szansa posiedzenia za kimś popatrzenia mu na ręce.
OdpowiedzUsuńBylbym raczej za hipotezą, że to nie zależy od faktu czy oprogramowanie jest enterprise czy web i w jakiej jest technologii. Istotny jest kontekst i rodzaj softu - tzn. jesli tworzysz aplikacje do jakiegos fast-fooda to tam rzeczywiscie kazdy bedzie uzywal ja w identyczny sposob (chociaz uzytkownikow moga byc dziesiatki tysiecy). Natomiast mozesz tworzyc aplikacje do pracy grupowej dla 50 uzytkownikow i tu sie okaze ze kazdy w roznym stopniu i w rozny sposob bedzie tego uzywal. Chce przez to powiedzieć "to zależy" ;) czasem bedzie trzeba sie z ta kwestia zmagac dla 50 uzytkownikow a czasem i dla 10 000 bedzie spokoj.
OdpowiedzUsuńChoc ufam, ze w Twoim przypadku zastosowaliscie dobre podejscie, nie chcialbym popularyzowac nieprawdziwego pogladu ze jak ktos pisze w EJB'kach albo dla "enterprajsu" to go to co pisalem w poprzednim komentarzu nie dotyczy.
Warto by do kompletu przeczytac Getting Real.
OdpowiedzUsuńOkazało się, że na mojej uczelni są pracownicy, którzy specjalizują się w tego typu badaniach. Dzisiaj rozmawialiśmy z opiekunką projektu i doszliśmy do wniosku, że można tego spróbować przy współpracy z owymi specjalistami dla b. małej liczby badanych. Ma to swoje zalety:
OdpowiedzUsuń1. Nauczymy się czegoś nowego :)
2. Okazuje się, że osoby, dla których aplikacja jest budowana nie za bardzo wiedzą jak z nami rozmawiać i nie są w stanie powiedzieć co ich denerwuje w obecnych systemach, jak się nimi posługują etc. Dzięki takiemu badaniu będziemy mieli lepsze rozpoznanie w temacie.
O wynikach "doświadczenia" nie omieszkam poinformować na łamach bloga :)
@Mateusz - dzięki za książkę. Trochę mam lektury obecnie ale za jakiś czas na pewno po nią sięgnę :)