A hálózati oldalak nyitása megszüntette a szűk üzleti keresztmetszetet a nagy szolgáltatások és a kis szolgáltatásfejlesztő cégek között egy jól érthető és használható szabályrendszer segítségével, ami automatizált megállapodási keretet hozott létre. Az API kultúra legnagyobb értéke nem csak az, hogy fejleszteni lehet más rendszerekre és azokban felgyűlt adatokra, hanem az, hogy egy olyan beépített bizalmi rendszert hoz létre, amely automatikusan elrendezi a kérdéseket üzleti entitások között, amiket korábban tucatnyi menedzsernek kellett megrágnia.
A nagy szolgáltatások nem a fejlesztési inkopetencia, hanem szervezeti tehetetlenség miatt szoktak belassulni. A szervezeti tehetetlenség pedig szervezeti kérdések és emberi tényezők együttállása és még csak nem is a menedzserek hibája, hanem bizonyos modellekben, például egy szolgáltatás, vagy szolgáltatáscsoport fejlesztése során fellépő üzleti skálázási probléma. Egy webes szolgáltatás fejlesztése során egyszerűen annyi üzleti kérdés kerül elő, hogy a szervezet képtelen megfelelően reagálni, miközben a szervezet hatékony működéséhez egyébként szükséges tekintély megakadályozza az átalakulást.
Vannak olyan kicsinek ható dolgok amik óriási különbségeket tudnak hozni abban, ahogy alkalmazásokat használunk. Egy apró trükk, ami első pillantásra nem is feltünő egy szolgáltatást fényévekkel használhatóbbá tud tenni, és ezeknek az elemeknek a megtalálása a legfontosabb feladat minden szolgáltatás fejlesztési folyamatban.
Itt van első példának a Google Maps. Mielőtt megjelent a hazai piacon, több térképes szolgáltatás is hozzáférhető volt, némelyek csúnyácskábbak, némelyek szebbek, de kivétel nélkül mindegyik szenvedett ugyanattól a problémától, rendkívül megnehezítette a címek bevitelét. Ezek a keresők többnyire egy adatbázisból dolgoznak, ahol minden utca bizonyos szabályok mentén van felvezetve, ha nem az általuk tökéletesnek vélt formában teszed fel a kérdésedet, kicsi az esélye, hogy jó találatot kapj.
Múlt héten a Microsoft egyik magas beosztású emberével szervezett kerekasztalt Bátorfi Zsolt – Microsoft developer evangelist -. Néhány napra a találkozótól összehoztunk egy rövid interjút, amiben főleg a Microsoft webes stratégiájával kapcsolatban kérdeztem.
Vajon miért van az, hogy minden hazai szolgáltatás specifikáció tömve van információs architektúrára, rendszer felépítésre vonatkozó elemekkel, ugyanakkor a felhasználó szempontjából legalapvetőbb felhasználási esetek nem kerülnek rögzítésre.
Meg van határozva, hogy hol és min kell futnia a rendszernek, hogy a felhasználónak milyen böngészőn kell elérnie az alkalmazást, de hogy konkrétan hogyan fog kapcsolatba lépni a rendszerrel, az valahogy nem tűnik dokumentálandónak.
Egy rendszernek működnie kell, ez manapság elég nyilvánvaló, amitől valami más lesz az az, hogy a felhasználó és a rendszer hogyan kerül kapcsolatba egymással. Ezt érdemes egyszerűen, strukturáltan és teljes egészében dokumentálni.
A mostani specifikációk olyanok, mintha a dokumentáció egy kocsi tervezésekor arról szólna, hogy az autónak gurulnia kell, vagy tudni kell bele tankolni, esetleg benzint fogyasszon, legyen benne kormány, ember is férjen bele. Ez a fontos, vagy az, hogy milyen egyedi elemek érkeznek az új dizájnba és ezeket miként fogják a felhasználók használni?
Ki gondolná, hogy az egyszerűsítés is okozhat értelmezési problémát a felhasználóknál, ha túl nagy innovációt hoz.
Google 1998. Ott a termék, amire mélyen mindig is vártunk, egy zavarástól mentes felület, ahol csak be kell ütni, mit szeretnénk megtalálni és minőségi találatokat kaptunk vissza.
Amikor 2000 környékén az első felhasználói tesztek keretében a telezsúfolt nyitólapokhoz szokott embereket leültették az Google felülete elé, hogy keressenek, volt aki csak ült egész sokáig és nézte a képernyőt. A Google csapat azt gondolta, hogy biztos a keresésen gondolkodik. A teszt után rákérdeztek, hogy miért nem írt be semmit, mi tartott ennyi ideig, válaszként annyit mondott, hogy várta, mikor töltődik be az oldal. Ez után tették be a lezáró láblécet.
Zseniális példa nem? A felhasználó egyszerűen nem ezt a viselkedést várja el az oldaltól, és az első reakciója mindig az, hogy biztos “valami közbejött”, vagy “én vagyok a hülye”.
Az innováció még akkor is nehéz, ha jó irányba haladunk.