Zakładki:
Inne moje "rzeczy"
Inne rzeczy
Innych "rzeczy"
Książki
Możliwości i wzorce projektowe
Po godzinach
Rządzą... Gry
Zobacz mnie na GoldenLine
ThinkLab: moja firma

MOJE KSIĄŻKI - AUTOR

Użyteczność w praktyceM. Kasperski, A. Boguska-Torbicz Projektowanie stron WWW. Użyteczność w praktyce, Helion 2008.

Moja książkaM. Kasperski, Sztuczna Inteligencja, Helion 2003.

REDAKTOR MERYTORYCZNY

UmysłD. Casacuberta, Umysł. Czym jest i jak działa, Świat Książki 2007.

100 sposobów...T. Stafford, M. Webb, 100 sposobów na zgłębienie tajemnic umysłu, Onepress 2006.

Istota inteligencjiJ. Hawkins, S. Blakeslee, Istota inteligencji, Onepress 2005.

RSS
piątek, 17 grudnia 2010

Herezja 1 w swoim czasie wywołała sporą dyskusję. Cieszyłbym się, gdyby w przypadku herezji 2 miało miejsce to samo, gdyż problem jest niebanalny.

Otóż: czy może istnieć UCD bez usability? Tj., czy jest możliwy przypadek prac, w ramach których użytkownik i jego potrzeby są w centrum zainteresowania projektantów, a jednocześnie rozwiązanie końcowe pozostawia wiele do życzenia pod względem używalności? Krótko mówiąc - rozwiązanie spełnia oczekiwania użytkownika, acz sposób korzystania z niego już nie.

Dla wielu być może problem wyda sie sztuczny, bądź zbyt teoretyczny, albo mało interesujący i tu błąd - gdyż ma kolosalne znaczenie z punktu widzenia metodyk rozwijania produktów internetowych, charakteryzujących się m.in. tym, że ich dynamika rozwoju jest zgoła większa od produktów fizycznych, gdzie wprowadzanie zmian i usprawnień nie jest prostym zadaniem (wprowadźcie zmianę do nowego serwisu WWW vs wprowadźcie zmianę do - przykładowo - nowego aparatu telefonu, który wydaje Wasza firma na rynek - to, co w pierwszym przypadku zajmie Wam od kilku minut do kilku tygodni, w drugim będzie wiązało się z czasem liczonym w miesiącach).

Do niniejszego wpisu doprowadziły mnie trzy drogi:

Przy czym:

  • z krytyką o2.pl się nie zgadzam, twierdząc, że jest ona wynikiem nieporozumienia i braku wiedzy merytorycznej twardogłowych krytyków (dinozaurów!), którzy swoją wiedzę osadzają na gruncie ustaleń z lat 90. i początku XXI stulecia, więc i nie przystających do ram współczesnego Internetu. A nawet gdyby przyznać im rację w niektórych aspektach, to jest to racja w stylu marksistowskiej, gdzie materializm jest do obronienia, ale wynika to z zajmowanego stanowiska ideologicznego, a nie z faktów obiektywnych. Stąd trudno spierać się na argumenty idealistom z materialistami. Tu liczą się fakty, a nie sofistyka. A te wyraża się przez elementy mierzalne i... wyrażane słupkami.
  • Zaś artykuł Jana Rychtera uważam za jeden z najbardziej odkrywczych, z jakimi mi się zdarzyło zetknąć w ostatnim czasie (czego mu zresztą pogratulowałem).

Przechodząc jednak do zagadnienia.

1. Rozwój produktu, jakim jest serwis internetowy, boryka się na co dzień z wieloma czynnikami (specjalnie nie nazywam tego 'problemami'): walka o przewagę konkurencyjną - a więc i walka z czasem - walka o użytkowników (wyrażana ilościowo), walka o satysfakcję i użytkowników i partnerów biznesowych (wyrażana jakościowo), etc.

2. Zasoby są głównym determinantem rozwoju. Zasoby przy tym wyrażone są przez takie składniki jak: czas, finanse, ludzie.

2.1. Czas to tyle, co czas na wprowadzenie danej zmiany, biorąc pod uwagę finanse jakimi dysponujemy. Ale też: czas na wprowadzenie zmiany, biorąc pod uwagę jakimi/iloma ludźmi dysponujemy. Czy w końcu: czas na wprowadzenie zmiany w serwisie vs estymacja tego czasu na wprowadzenie danej zmiany przez konkurencję. Jak też: czas na wprowadzenie zmiany w serwisie, satysfakcjonujący naszego partnera biznesowego bądź grupę użytkowników, a przekuwający się docelowo na finanse, co daje nam paliwo na dalsze prace.

3. Zmiany wprowadza się z czterech powodów:

  • zmiana jest wynikiem przyjętej wcześniej strategii, więc jest ona realizacją strategii,
  • zmiana jest wynikiem potrzeby grupy użytkowników,
  • zmiana jest wynikiem potrzeby biznesu - wypływa bądź od managmentu produktu, bądź od partnerów, którzy zgłaszają potrzebę danej zmiany,
  • w końcu zmiana wynika z faktu optymalizacji aktualnego stanu produktu. W tym przypadku zmiana może być powrotem do stanu przed wprowadzeniem wcześniejszej zmiany.

4. Cel przy wprowadzaniu zmian jest jasny: zwycięstwo! Bądź chociaż przetrwanie, dające też czas na przegrupowanie i nową ofensywę.

5. Zmiany są obarczone ryzykiem.

  • Wprowadzona zmiana się nie przyjmie.
  • Grupa docelowa odrzuci zmianę - może to być zarówno grupa użytkowników, jak i grupa partnerów.
  • Zmiana nie przyniosła zamierzonych efektów - jaki jest sens jej utrzymywania / rozwoju? Jaki to koszt?
  • Zmiana pogorszyła inne parametry produktu.
  • etc.

6. Minimalizacja ryzyka. Minimalizacja kosztów. Maksymalizacja współczynnika - proporcja ilości czasu i zaangażowania deweloperów do uzyskania pożądanego efektu, mogą prowadzić (a właściwie prowadzą nieustannie) do wspierania się prowizorycznymi rozwiązaniami. Gdzie zamierzony efekt zostaje osiągnięty - tj. zmiana wprowadzona - ale nim uzyska odpowiednią skalę i się sprawdzi, koszt jego uzyskania jest stosunkowo niewielki. Stąd wprowadzamy i utrzymujemy potem przez jakiś czas dane prowizoryczne rozwiązanie, by w przypadku sukcesu, rozwinąć je / zoptymalizować, bądź w przypadku nie osiągnięcia odpowiednich wartości (skali) - zabić, z mniejszą stratą dla całości (wszak jej wprowadzenie nie kosztowało nas zbyt wiele).

6.1. To, co w artykule Jana Rychtera nazywa się długiem technologicznym, tutaj można przedstawić za pomocą terminu długu projektowego. Mamy to, co mieć chcieliśmy, za dość rozsądną cenę. Chociaż to prowizorka - działa!

7. W ten sposób - konkludując - są możliwe przypadki (a nawet przy wielu projektach wskazane), w których mamy do czynienia z wprowadzaniem zmian, nawet z zachowaniem metodyki User Centered Design, gdzie ostatecznie powstaje coś, co jest odpowiedzią na potrzeby użytkowników i to powstaje przy ich wsparciu, acz pod względem używalności, a więc usability, pozostawia wiele do życzenia.

7.1. Innym przypadkiem gdzie to ma miejsce, są ograniczenia systemowe. Gdzie wprowadzamy rozwiązanie pro-użytkowe, ze względu na użytkowników i przy ich udziale, acz z powodu ograniczenia jakie daje nam zastany system (kod serwisu), nie jesteśmy je wstanie w pełni zoptymalizować... Widzimy błędy interfejsu, acz ich koszt usunięcia jest niewspółmierny do wartości początkowej i obarczonej ryzykiem.

Nie jesteśmy wstanie zoptymalizować przy... ograniczonych zasobach - finansach, ludziach, czasie.

QED.

13:19, marekkasperski
Link Komentarze (4) »