Modul VII.

B/CZ/Úkol


Modul VII

Jaká kritéria byste zvažovali, pokud byste se rozhodovali, zdali převzít zodpovědnost za funkce produktu, které sice fungují správně (dle zadání), ale používají se hrozně (použitelnost je špatná)? Převzetí zodpovědnosti znamená na vlastní náklady tyto funkce doladit. Sepište tato kritéria a odůvodněte svůj výběr.

Řešení:

Podívám se na tuto problematiku ze silně utilitaristického hlediska, aniž bych přitom ovšem rozporoval výhody opravdu partnerského vztahu se zákazníkem. V zadání je řeč o funkcích, které se používají tak špatně, že se z hlediska celkového produktu dají označit za chybná, důvodem ovšem není nedodržení zadání.

Asi bych se zamyslel nad tím, proč jsou špatně použitelná a kdo za to může. Použitelnost, usability je jeden z aspektů, který spadá pod design a mělo by se na něj brát ohled stejně jako na čistou mechanickou funčnost, apod. Bylo zadání tak detailní, že nebylo možné z hlediska realizačního týmu s tímto aspektem nic dělat? Nebo o něm nebyla ani zmínka a design aspektu byl cele v kompetenci týmu? Tato skutečnost bude hrát v převzetí zodpovědnosti roli. Byla-li tato část produktu na nás, budeme za ní zodpovědnost příjmout muset. Ovšem pokud nebyl dle zadání vůbec prostor pro úpravy, nabízí se v rámci partnerského vztahu, ale vzhledem k našim časovým a hlavně finančním možnostem varianta zodpovědnost přijmout, pokud vykalkulujeme, že se nám to vyplatí.

Tedy, pokud nám skrze finanční a časovou analýzu výjde, že je dolazení schůdné, může se nám vyplatit zodpovědnost přijmout, zejména projeví-li se tato investice v charakteru vzájemných vztahů se zákazníkem. Naše ochota může zafungovat jako znak profesionality a promítnout se například v preferencích. A toto doporučení se dále může šířit skrytě přes networking, přičemž to pro nás pak bude hrát roli jakožto nekvantifikovatelný, těžko zjistitelný, leč velice důležitý marketing a branding.

Úkoly k vašemu projektu z druhého modulu:

  • Vytvořte alespoň dva testovací scénáře ke svému projektu, který jste si v druhém modulu zvolili. Vymyslet si můžete jakýkoliv scénář, fantazii se meze nekladou. Oba scénáře potom hypoteticky vykonejte.

a. První scénář dokončete hypoteticky úspěšně (všechny kroky v testu odpovídají očekávanému výsledku)

b. Druhý scénář zaevidujte jako hypoteticky neúspěšný (v některém kroku narazíte na problém, chybu nebo případně reálný neodpovídá očekávanému výsledku)

Vzorový testovací scénář naleznete v interaktivní osnově, případně zde. Kurzívou jsou v dokumentu věci, které si upravte pro potřeby svých dvou scénářů.

Můžete ale klidně vytvořit scénáře ze nějaké rozumné šablony (na internetu je jich hromada) nebo – pokud si troufnete – si můžete vytvořit šablonu vlastní. Je to na vás.

Řešení:

Oba scénáře přikládám jako samostatné dokumenty.

Pro neúspěšný scénář jsem si vybral testování funkce, kdy si můžeme na stránkách zobrazit HTML kód pro iFrame. Uvažoval jsem o této funkci při vyplňování INSPECTu v Digitální kurátorství, kdy jsem brainstormingoval možné funkce pro digitální objekty v archivu uložené. Nejsem dobrý v HTML, ve kterém mám jen obecný přehled, ale přišlo mi to jako dobrý nápad. Tato funkce je určena pokročilému uživateli, který sám publikuje a chce ve svých příspěvcích využívat objekty z archivu. Proto je hypotetický tester sám developer.

Pro úspěšný scénář, tentokráte z pozice uživatele, jsem si vybral testování funkce zpětnovazebních dotazníků, které mi přijdou fajn. Nemám je sice zatím nikde v projektu ani v předchozích úkolech zakomponované, myslím si ale, že minimálně v nějaké pilotní fázi, nebo v začátcích (pokud už né stabilně na vždy) se jedná o velice užitečnou funkci.

  • Nadefinujte podmínky údržby výstupu svého projektu. Ať už ve formě SLA nebo nějaké interní směrnice nebo interního pravidla – podstatné je, abyste v podmínkách zohlednili faktory, jejichž důležitost plyne z povahy vašeho projektu a jeho výstupu. Musí být jasné, za co kdo ponese jakou zodpovědnost, případně kolik co bude stát. I pokud jde o interní projekt, můžete například definovat zodpovědnost napříč odděleními a stanovit, jaké oddělení ponese jakou finanční zátěž v konkrétních případech a jak rychle musí reagovat.

Řešení:

Tenhle úkol byl pro mne poněkud těžký. Vzhledem k tomu, že se má jednat o dokument ve formě smlouvy (nebo tak jsem alespoň úkol interpretoval), u které existují různé verze znění a podmínky, bylo pro mne těžké si představit, jak reálně má dokument vypadat. Navíc vzhledem k mému projektu, u které mám tým poskládaný z interních zaměstnanců univerzity dělající projekt pro tu samou univerzitu.

Vyřešil jsem to následovně: na internetu jsem si vyhledal šablony k SLA a jednu z nich, která mi přišla relevantní k projektu, jsem vyplnil z pohledu firmy, kterou mám napsanou v projektu jakožto partnera. Dejme tomu, pro kontext a potřeby úkolu, že tato firma bude poskytovat IT služby pro náš projekt, a že tato firma sama řešila problém formou projektu s vlastním projektovým manžerem. Tento dokument tedy přikládám zvlášť a je zpracovaný popsaným způsobem. Využil jsem původního znění a vyplnil projekt v angličtině. Zároveň jsou některé formulace předpřipravné a doplnil jsem pouze konkrétní údaje jako jména subjektů. Snad to bude v pořádku.

V šabloně jsme rozvolnil lhůty pro reakce v případě problémů, jelikož si myslím, že to pro digitální archiv není důležité. Taktéž jsem vzhledem k tomu, co jsme se učili o komunikaci, zaimplementoval pravidlo ohledně chatu, který bude sloužit jako rychlá reakci pokud se bude jednat o malý problém do 500 znaků (nevím jestli to není blbost). Doplnill jsem pravidla ohledně ceny služeb a sankcí pro obě strany v sekci 7.

Myslím, že je tímto ošetřen požadavek rozdělení zodpovědnosti mezi poskytovatelem a zákazníkem s tím, že jsem nešel do detailů ohledně oddělení jednoduše proto, že nemám jasno, jaká oddělení to u mého projektu budou. Finance jsou zohledněny jak v ceně služeb tak sankcí, přičemž jsem použil formulaci standardní denní sazba proto, aby byla cena „nezafixovaná“ relativně. Standardní denní sazbu bych rozuměl průměrný plat v ČR rozpočítaný do hodin. Může se jednat o chybu a možná by bylo lepší se na ceně domluvit fixovaně? Rozsah služeb mi přišel pro externí firmu zajišťující IT v pořádku, vymazal jsem pár drobností, jako vzdálený přístup plochy. Připsal jsem si do podmínek dokumentaci a doporučení pro zlepšení, pokud se bude jednat o kritické aspekty.


Úspěšný testovací scénář

Datum: 2.4.2023

Tester: Libor Zábořecký, odborný asistent

Kontrola funkce zpětné vazby pomocí dotazníků

Postup testování:

  1. Otevřete si stránku digitálního archivu na vašem PC.
  2. Najděte na stránkách funkci zpětné vazby pomocí dotazníků.
  3. Zkuste vyplnit dotazník.
    1. Zobrazuje se dotazník správně?
    2. Je srozumitelný?
    3. Odpovídají odpovědi otázce?
  4. Opakujte stejný postup v mobilním telefonu.

Očekávaný výsledek: 

Uživatel najde funkci zpětné vazby dotazníků.

Dotazník se správně zobrazuje v prohlížeči na PC.

Dotazník se správně zobrazuje v mobilním telefonu.

Reálný výsledek: 

Myslím, že to funguje. Stránka mi naběhla bez problému, vše se zobrazuje jak má. Trochu jsem se musel hledat, kde se vlastně zobrazuje menu, ale neklasifikoval bych to jako problém. Po najetí na dotazníky jsem začal vyplňovat – všech 5 stránek se zobrazovalo dobře, žádné bugy, všechno šlo zakliknout, interaktivní design funguje. Když jsem stejný postup opakoval v mobilním zařízení přišlo mi akorát, že se odpovědi zobrazujou moc malé a občas byl celkem problém se správně strefit. Asi bych si s tímto pohrál. Jinak bych funkci označil za zdárně dokončenou.

Dodatečné poznámky:

Dotazník mi přišel vlice citlivě formulovaný, tzn. otázky byly položeny tak, že mne nenabádaly na určitou odpověď, nemanipulovaly, přišlo mi to celý vyvážený.

Neúspěšný testovací scénář

Datum: 2.4.2023

Tester: Marek Štvrtňa, full-stack developer

Kontrola funkce zobrazení iFrame kódu pro vložení audio na vlastní stránku.

Postup testování:

  1. Otevřete si webovou stránku archivu.
  2. Najděte si libovolný objekt na stránce.
  3. Vyzkoušejte, zda-li vám funguje přehrávání.
  4. Nalezněte na stránce funkci, která vám zobrazí kód pro vložení objektu na vlastní stránku.
    1. Byla funkce lehko k nalezení?
    2. Je popis funkce srozumitelný?
  5. Zobrazte si kód HTML
    1. Zobrazuje se kód správně?
    2. Je kód zkopírovatelný?
  6. Vložte kód na svou vlastní stránku.
    1. Vložte kód do svého HTML kódu na vlastní stránce.
    2. Vložte kód do WordPressu.
  7. Zobrazte vložený digitální objekt na své stránce.
    1. Zobrazuje se přehrávač správně?
    2. Lze audio spustit?
    3. Přehrává se audio správně?

Očekávaný výsledek: 

Uživatel úspěšně najde funkci pro zobrazení HTML kódu.

HTML kód ze zobrazí na stránce.

Vlastní webová stránka zobrazuje funkční audio přehrávač.

Reálný výsledek: 

Bohužel se mi nepovedlo úspěšně dokončit test. Postupoval jsem přesně podle plánu, stránka funguje, objekt svého uvážení jsem našel hudbu. Přehrávání super, bez problému. Funkci jsem našel celkem rychle, ale popis, který se mi u ní zobrazil byl poněkud nesrozumitelný. Určitě by šel formulovat lépe. Což o to, zobrazil jsem si tedy kód, ale způsobem, který prostě není v pořádku. Tagy se nezobrazily vůbec a formátování bylo hrozně nepřehledné. Je třeba to změnit. Když se mi to konečně podařilo zkopírovat a upravit, vložil jsem tedy kód do svého a zkusil ji spustit, ale nefungoval. Generátor špatně generuje atribut src, je třeba se na to důkladněji podívat. Samozřejmě že WordPress to samý.

Dodatečné poznámky:

Upřímně si myslím, že by už ten zobrazený kód mohl vypadat přívětívější a hlavně psaný vhodnějším fontem. To co bylo, comic sans?

Zadruhé mi i umístění a vzhled tý funkce nepřijde nic moc. Nevypadá to prostě dobře. Celá stránka je v pohodě, ale tahle ikonka tam trčí jako kůl v plotě. Asi by stálo za to to celé sladit a překopat design.

Service Level Agreement

Napsat komentář