Role
Rubriky: Laici, Persony, Zavedení použitelnosti do firmy, Začátečníci
Typů rolí existuje celá řada. V tomto článku se píše o rolích ve smyslu UCD – User Centric Development.
Většinou, když necháte programátora tvořit, do velké míry předpokládá, že uživatelé jsou jako on. A že se zajímají o jeho software a že mu věnují veškerou pozornost… Samozřejmě, že se tento jev netýká jen programátorů, ale všech lidí, kteří se podílejí na vývoji.
Bylo by dobré, kdyby se všichni mohli setkávat s uživateli, pozorovat je při práci a konzultovat s nimi své nápady. Protože to ale často není možné, simulujeme toto setkání pomocí rolí a person.
Nejdříve vytvoříme role. Administrátor, sekretářka, účetní… všichni, co mohou využívat daný software, a to přímo i nepřímo. Například ředitel asi nebude s vaším softwarem pracovat, ale bude po sekretářce chtít, ať tam zadá nějaká data a pak bude číst výstupy.Role by měly být definovány tak, jako byste psali popis pracovní pozice do inzerátu. Předpokládané vzdělání, zkušenosti, pracovní náplň, popis pracoviště, s kým komunikuje… První role bude těžší vytvořit, asi se vám bude zdát, že je to v každém případu nasazení trochu jiné. Doporučuji vzít konkrétního jednoho zákazníka/uživatele a zamyslet se, jak se liší od ostatních a s drobnými korekturami popsat jeho případ. Pokud se někteří zákazníci nebo uživatelé výrazně liší od jiných, je dobré vytvořit role dvě nebo víc. My třeba máme dvě sady rolí pro jeden produkt: malá fabrika o patnácti lidech a kolos se stovkami zaměstnanců. V malé fabričce dělají zaměstnanci hodně různorodé činnosti, ve velké jsou úzce specializovaní.
Platí, že byste se neměli moc vázat na současné uživatele, důležití jsou uživatelé cíloví. Pokud je některý uživatel jiný, než byste si představovali, nezabývejte se jím. Vlastně rolemi a personami říkáme: takovýmto rolím je určen náš software. Je na obchodnících, aby takovéto lidi sehnali.
V rámci práce na rolích je vhodné také popsat jejich zaměstnavatele nebo pracoviště. Značková prodejna Seatu v Hradci Králové, vede to majitel, pracují tam čtyři obchodníci, je tam servis… Vymyslete si to, ale buďte konkrétní. Role se pak vytvoří přímo pro danou společnost. Pokud máte soukromou klientelu, postupujte obdobně. Jde o to mít nějaké informace o tom, co jednotlivé role spojuje. Pokud produkt používá více společností a komunikují spolu, vytvořte jich víc.
Je velmi důležité role podložit daty. Vše, co se týká použitelnosti, musí být velmi dobře podložené. Jakmile se při nasazování rolí a person ukáže, že neodpovídají realitě, můžete to zabalit. Důvěryhodnost je to nejdůležitější, co budou lidé, kterým to budete představovat, zkoumat. Nepodceňte to.
Jakmile role vytvoříte, ověřte, že jsou v pořádku. Konzultujte to s každým, s kým budete moci. S obchodníky, s analytiky, s kolegy… Každý to trochu upřesní. Asi si někdo vzpomene na další role, které chybí. Ty vytvořte. Konzultace také mají dobrý efekt v tom, že takto nenásilně představíte, že se bude něco nového dít. A kolegy do toho vtáhnete. V této fázi vám nikdo pomoc neodmítne, později to bude něco jiného (to už bude dlouhodobá práce a nějaké změny navíc). Nyní se lidé rádi vytáhnou.
UCD je možno aplikovat i na nový software. Když ještě uživatele nemáte, postupujte stejně, jen budete muset trochu víc zapojit představivost. A o to víc to musíte ověřit. Jestli ověření podceníte, uděláte produkt pro nikoho a navíc tak pošramotíte pověst UCD, že to asi vedení stopne.
Výsledkem bude několik rolí (2-12?). Až jste si jisti, že jsou hotovy a kvalitní, vytvořte ke každé z nich nejméně jednu personu. Většinou jednu, ale někdy se stane, že je lepší jich udělat víc. Například já jsem pro roli školitele udělal role nováčka a zkušeného borce. Každý má jiné problémy a řeší je jinak. Nebo jsem měl roli vedoucího pobočky a tři role podle oboru. Prodejce párků se hodně liší od bankéře.
O personách zase jindy. Více v knize The Persona Lifecycle.
Podle me je jsou 4 role tak maximum co si jsem schopen nejak zapamatovat. I UCD specialista si musi uvedomit stejne jako programatori, ze uzivate UCD nejsou jako on, takze v realu nikdo 12 roli nebo person “resit” nebude na to proste neni cas a mozkova kapacita.
Navic UI (u softwaru krabicoveho typu) nelze delat priliz variabilni pro kazdou roli zvlast – nejen ze na to neni cas (vyvoj testovani dokumentace…), ale prodavac parku nikdy neprizna ze je prodavac parku, navic kdyz bude muset zaskocit za prodavace kvetin, tak bude vyveden z miry ze najednou nevidi to svoje jedine zname tlacitko pridani horcice.
Nadruhou stranu nejsem proti rolim, ale nesmi se to prehanet – kratky 2 vetny popis kazde role musi stacit – ve vysledku je totiz jedno jestli to je prodavac parku nebo kvetin – takove mnozstvi detailu zdrzuje a dela software priliz uzce zamereny a tim neprodejny siroke ruznorode populaci.
Ukazka jednoduchosti Visual Studio – pouze 3 persony: Mort, Elvis, Einstein – jednoducha zapamatovatelna vystizna jmena, jednoduche popisy “feeling lucky” treba tady:
http://www.codinghorror.com/blog/archives/001004.html
[Bobris] Počet rolí odpovídá produktu. Nedá se říct, čtyři role a dost. V jedné firmě máme produkt, který někdo nasazuje, někdo dělá podporu. U zákazníka jeden pro něj dělá grafiku, druhý řeší data, vedoucí řídí projekty a schvaluje je, někdo spravuje aplikaci, jiný servery. Pak jsou tam zákazníci zákazníka, kde marketing tam dává produkty, jiní lidé je kupují a další jim to schvalují.
Minimální počet rolí v článku snižuji. Není to norma. Samozřejmě že u jednoúčelových aplikací je počet rolí malý. Rozhodně by neměla žádná role být redundantní.
Souhlasím s tím, že u krabicového řešení nemá být variabilní UI. Ale jestli tam budou tři velmi různé persony, tak se musíme ujistit, že všem třem se bude se stejným softwarem dobře pracovat. Většinou to lze zařídit. Nebo se můžeme rozhodnout, že náš software bude dělán jen pro jednoho nebo dva z nich. Musí to být vědomé rozhodnutí a musíme vědět, že to těm ostatním nesmíme nabízet.
Popis role rozhodně nemá být jedna nebo dvě věty. S rolemi se nakonec moc nepracuje, jen to podporuje persony. Ale je velmi důležitý proces jejich tvorby. Když chci po zodpovědných lidech detailní popis rolí, zjistí se někdy, že o uživatelích skoro nic neví a že se názory různých lidí velmi liší. Tvorba rolí je proces, kdy se nad tím důkladně zamyslí, protože jim kladu podrobné dotazy. Už se mi i v jedné firmě stalo, že po mém dotazování se na role se zjistilo, že se musí celý produkt přepracovat, protože takoví uživatelé prostě neexistovali.
Až budou role a persony hotové, přijde jejich nasazení – představení. To je jiná fáze a pak se bude redukovat množství informací, které se předají.
Můj příklad s bankéřem jsem zjednodušil až do nesrozumitelna. V tom produktu se použití jednoho softwaru velmi lišilo a bylo třeba myslet na obě varianty. Kdybychom to připravili jen pro jednoho z nich, pro druhého by to bylo skoro nepoužitelné a obráceně. Každému by chybělo několik málo velmi důležitých funkcionalit.
Počet rolí samozřejmě závisí na softwaru. U nás ve WebProofu jsem například z hlavy schopen vysolit aspoň tyto: Administrátor, designer, lead-designer, PR-manažer, podřízený PR-manager, sekretářka. A ne náhodou jsou tyto role i v Tčku, protože lidi, co používají WebProof s vysokou pravděpodobností používají i Tčko.
Nepřipadá mi dobré role nebo persony omezovat. Je to zábavné říkat si, jak by si Josef Skočdopole, designer, poradil s tímto a tímto ovládacím prvkem na této a této stránce. Programátor může popustit uzdu své fantazii a představovat si jeho konkrétní chování a sprostá slova, které mu lítají z úst. Daleko lépe se pak funkcionalita vymýšlí a konzultuje s kolegy: Hej Pepo, víš co by ti na to řekl Pepík Skočdopolovic? Že neví, proč je tady ten panel jednou skrytý a jednou ne. Však víš, jakej je to nervák, raději s tím něco udělej.
Zatím nám nebyly naše persony představeny, ale už teď s pár takovýma v hlavě mluvím a na ty naše se moc těším.
No na to narazim, ne vsichni maji problem se schizofrenii
A v tecku jsou v podstate jen 2 role a to designer (je dostatecne chytry ze dokaze zkopirovat exac a tim je z neho administrator, ale je mene chytry nez programator) a tupy “tiskar” co ma problem se trefit mysi na tlacitko, kdyz se vcera jako kazdy den zkolil… Ale vice mene se tato druha role neresi, takze proste pouze designer. Jen jednoduche role mohou dat vzniknout jednoduchemu, ale pouzitelnemu produktu …
No dobre uplne zjednodusene jde o to proste klesnout jak nejvice to jde a tak se alespon dostat na nejlepsi z uzivatelu, podle me neni nutne si pri tom pomahat vymyslenymi postavami (Kazdy takove dobre zname treba z vlastni rodiny …)
Navic casto ani neni potreba ani tak klesat, je nutne aby aplikace byla pouzitelna alespon pro podobne lidi jako si ty sam, pokud se podari alespon toto tak si vpodstate vyhral zbytek je jen vysperkovani …
[Bobris] Nemyslím si, že máš pravdu, schizofrenie je výborný programátorův pomocník, osobně bych na přijímacích pohovorech vyloučil hned všechny ty úplně psychicky zdravé jedince. =)
Ne, vážně, myslím si, že to opravdu příliš zjednodušuješ. Tčko alespoň v případě Corner bank používá managerka, která v něm kontroluje dopisy a případně v nich opravuje drobné chyby, designer, který nadesignuje vzhled dopisu, a o víc se nestará, úředníci, kteří dodají dopisu potřebná data. To jsou tři role!
Desinger je požitkář, který je každý večer ožralý, tak má ráno problém trefit se na buton, musí mít proto butony velké.
Manažerka je trochu staromódní a nechce se učit složité rozhraní, chce dopis prostě jen zkontrolovat a nahradit nevhodné formulace. Přebývající funkcionalita, kterou nepotřebuje, ji obtěžuje.
Není zas tak těžké na tyto tři role myslet při vývoji a snažit se jim všem vyjít vstříc.
(Jsou to jen příklady, veškerá podobnost se skutečnými postavami je čistě náhodná.)
Hm, přemýšlím, že ne všichni jsou asi uživatelé Tčka. Momentálně teda ano, ale do budoucna chtějí na schvalování a psaní dopisů použít finálně Interactive a WebProof.
[Boris 4] Měl jsem teď dost fofr, tak jsem zatím nereagoval.
Je vidět, že pro vaši aplikaci se tím nikdo seriozně nezabýval, takže neznáš výhody ani techniky. To je v pořádku.
UCD není šílený experiment, je ověřený a funkční, existuje literatura, školy na použitelnost, v US jsou odborníci na použitelnost vedeni jako samostatné pracovní pozice… My to navíc máme prakticky vyzkoušené v naší firmě a máme tedy výsledky přímo před očima.
Mít jen jednu personu, aby se to nepletlo, to je jako bych třeba programátorům radil, ať píší celý kód do jednoho souboru nebo že musejí dokumentovat každý řádek kódu. Asi by to dlouho nefungovalo.
Já znám stovky lidí, pořád se s někým seznamuji. A je to takto běžné. Člověk by neměl mít velký problém se seznámit se s více než se čtyřmi lidmi. Vývoj softwaru je dlouhodobá záležitost, některé persony s vámi stráví několik let, takže investice do seznámení se s nimi se vyplatí.
Dost často v souvislost s personami slyším slovo schizofrenie. Jako kuchař nemám problém jednomu hostovi udělat steak, jinému zeleninové rizoto a třetímu palačinku. Sám si pak klidně dám šneky. Chci tím říct, že do person se člověk nemusí vžívat, jen by si měl umět představit, co by které z nich potěšilo.
[Radek 3] To je typická situace, že když si navzájem nevyjmenujeme, jaké role máme, nezjistíme, že se naše představy liší (skutečně to vidím dost jinak). Táhneme každý za jiný provaz – každý dělá jiný produkt. UCD velmi dobře pomáhá si to ujasnit a spojit síly jedním směrem.
tento článek má jednu zásadní chybu použitelnosti. není zde řečeno, že jde o díl seriálu a není vysvětlen pojem UCD, ani odkázáno na vysvětlení. četl jsem ho jako první a nějakou chvíli jsem se domníval, že se jedná o článek o ověřování uživatelských práv (tam se také hraje s rolemi). umí váš redakční systém seriály? měl by
ale obsah je zajímavý. díky :]
[paranoiq] Pokusil jsem se připomínky napravit odkazy v článku.
co si myslite o optionalite pop-up okenka v PrintNetT? Napadlo mne to v souvislosti nastovani Parametru pro worklflow a ParamInputu. Uzivatel si to nemuze ani pridat jako plugin pouzitim VisualBasicu nebo tak…
[Nizar] Spíš bych tady moc neřešil specifika jednotlivých našich produktů, málokdo je zná. Ani já ne