Požadavek zněl jednoduše: přidejte do formuláře nové pole

Některé požadavky vypadají tak jednoduše, že je lákavé rovnou je předat vývojáři. Přidejte nové pole. Omezte počet znaků. Zobrazte adresu ještě na jedné obrazovce.

Pole ve formuláři ale obvykle není izolovaný obdélník s popiskem. Hodnota může vznikat v jednom systému, upravovat se v druhém, zobrazovat se na několika místech a nakonec pokračovat do dalšího procesu. Změna, která je na obrazovce téměř neviditelná, proto může otevřít otázky formátu, validace, oprávnění, historických záznamů i chování navazujících systémů.

Požadavek, který vypadal na několik minut

Při testování jedné z úprav jsme narazili na problém v poli pro telefonní číslo. Formulář umožňoval zadat více než devět číslic. Po uložení sice systém správně zobrazil chybu, z pohledu uživatele ale přicházela zbytečně pozdě.

Do pole pro telefon dovolte zadat maximálně devět číslic. Omezení má fungovat už při psaní, ne až po odeslání formuláře.

Na první pohled jde o drobnou změnu. Pole už existuje, validace částečně funguje a stačí doplnit maximální délku vstupu. Kdyby ale zadání skončilo touto větou, zůstala by řada věcí nejasná.

Počítají se do limitu mezery? Co předvolba? Může uživatel vložit číslo ze schránky v jiném formátu? Co se má uložit do navazujícího systému? A co s hodnotami, které už jsou v databázi uložené s mezerami nebo zahraniční předvolbou?

Najednou už neřešíme jen délku jednoho pole. Řešíme rozdíl mezi tím, co uživatel může napsat, co formulář přijme, co se uloží, v jakém formátu se hodnota předá dál a jak se následně zobrazí.

Jedna hodnota může mít několik různých podob

Telefonní číslo může člověk vnímat jako jednu hodnotu, zatímco formulář, databáze a navazující systém pracují se třemi odlišnými řetězci. Proto je před realizací potřeba oddělit minimálně tři pravidla.

Pokud tyto vrstvy v zadání neoddělíme, mohou všechny strany mluvit o „správném formátu“, ale každá tím myslet něco jiného.

Omezení při psaní není totéž co validace

Původní formulář chybu rozpoznal. Uživatel mohl zadat příliš dlouhou hodnotu, odeslat formulář a teprve potom zjistit, že číslo nevyhovuje pravidlům. Technicky tedy validace existovala. Uživatelsky přicházela pozdě.

Pokud systém přesně ví, že delší hodnota nikdy nebude přípustná, dává smysl zabránit jejímu zadání už během psaní. Ani prosté omezení počtu znaků ale nemusí být správným řešením.

Správná otázka nezní jen „kolik znaků smí pole obsahovat“, ale „kolik číslic má zůstat po odstranění povolených formátovacích znaků“.

Malá změna, několik rozhodnutí pod povrchem

Nemusíme z každého pole vyrábět několikastránkovou analýzu. Potřebujeme ale zviditelnit rozhodnutí, která ovlivní realizaci:

1. Jsou povolena pouze česká čísla?
2. Zadává předvolbu uživatel, nebo systém?
3. Jaké oddělovače může pole přijmout?
4. Jaký formát očekává další systém?
5. Co se stane s historickými hodnotami?
6. Jak se má pole chovat na mobilu?

Pole neexistuje jen tam, kde ho právě vidíme

Ve stejném testování se objevila i jiná situace. Nově doplněná adresa se správně zobrazovala při výběru záznamu a v předvyplněné části formuláře. V pravém panelu se ale načítala odlišná hodnota.

Fakt, že dvě obrazovky ukazovaly správnou adresu a třetí chybnou, naznačoval, že problém nemusí být v samotném uložení dat. Jednotlivé části mohly čerpat z jiných zdrojů, používat novou a starší hodnotu nebo zaměňovat adresu kontaktu s adresou pracoviště.

Jedna správná obrazovka nepotvrzuje, že změna funguje všude. Stejně tak jedna chybná obrazovka automaticky neznamená chybu v databázi. Je potřeba projít celou cestu: zadání hodnoty, uložení, načtení, zobrazení v jednotlivých kontextech a další úpravu.

Životní cyklus hodnoty je delší než formulář

Požadavek obvykle vznikne na konkrétní obrazovce, a proto se diskuse soustředí právě na ni. Hodnota ale může pokračovat do exportu, dokumentu, komunikace nebo jiné aplikace. Čím více kroků a systémů prochází, tím méně vypovídající je samotný screenshot pole.

Zadání proto nemá popisovat jen to, co má uživatel vidět. Mělo by vysvětlit také, odkud hodnota přichází, kdo je jejím vlastníkem, které místo je zdrojem pravdy, kde ji lze upravovat a kde se pouze zobrazuje.

Jak z podobného požadavku připravuji zadání

U drobných změn nechci vytvářet zbytečně rozsáhlou dokumentaci. Zároveň nechci vývojáři předat pouze screenshot a jednu větu. Pomáhá mi pět krátkých kroků.

1. 01

   Popíšu pozorované chování

   Začínám tím, co lze zopakovat a vidět: „Do pole lze zadat více než devět číslic. Chyba se zobrazí až po odeslání.“ Pokud nemám potvrzenou příčinu, nevydávám odhad za technický fakt.

2. 02

   Oddělím současný a očekávaný stav

   Zadavatel i dodavatel musí sdílet stejnou představu o tom, co se děje dnes a co se má dít po úpravě.

3. 03

   Určím rozsah změny

   Ověřím formuláře, administraci, mobil, existující záznamy, importy, API i místa, kde se stejná hodnota zobrazuje.

4. 04

   Pojmenuji nejasnosti jako otázky

   Ne každou odpověď musím znát. Nejasnost ale musí zůstat viditelná, místo aby ji nahradil tichý předpoklad.

5. 05

   Přidám příklady vstupu

   Konkrétní platné a neplatné hodnoty odhalí rozpory rychleji než dlouhý obecný popis.

Příklady odhalí rozpor ještě před vývojem

Pokud zadání označí jako platné číslo s předvolbou, ale současně požaduje pevný limit devíti znaků, je zřejmé, že pravidla je potřeba upravit ještě před realizací.

Ze zadání musí vzniknout testovatelný výsledek

Zadání nepovažuji za dostatečně konkrétní, pokud podle něj neumím připravit jednoduchý test. Věta „upravte validaci telefonu“ nemá jasné měřítko dokončení. Přesně popsaný vstup, výstup a chybové chování už lze převést do scénářů.

Test nekončí u samotného pole

Po kontrole vstupu ještě ověřuji, co se skutečně uložilo, jak se hodnota zobrazí po opětovném otevření formuláře, co se předalo do navazujícího systému, zda se správně propíše do přehledu a detailu a jestli změna neovlivnila jiný formulář.

Testovací scénáře nekontrolují jen práci vývojáře. Prověřují také kvalitu zadání. Když nedokážeme říct, jak se má systém zachovat v konkrétní situaci, možná ještě chybí produktové nebo provozní rozhodnutí.

Ne každá nejasnost má být vyřešena vývojářem

Vývojář může navrhnout technické řešení. Bez potřebného kontextu by ale neměl rozhodovat, zda systém podporuje zahraniční čísla, která ze dvou adres je správná nebo jaký formát musí přijmout navazující aplikace.

Úlohou zadavatele není znát odpověď na každou technickou otázku. Důležité je poznat, která odpověď chybí, kdo ji může dodat a jak ji promítnout do společného zadání.

Screenshot je důkaz problému, ne celé zadání

Screenshot rychle ukáže místo a podobu chyby. Zachytí ale jen jednu obrazovku, okamžik, roli a stav formuláře. Neřekne, co se stalo předtím, odkud hodnota přišla ani jak se systém zachová jinde.

Proto k němu přidávám kroky pro zopakování, současný a očekávaný výsledek, konkrétní hodnoty, roli nebo prostředí a související místa k ověření.

Praktický checklist pro podobnou změnu

Ne každá úprava potřebuje odpověď na všechny následující body. Checklist ale rychle ukáže, zda se za jednoduchým polem neskrývá rozhodnutí, které zatím nikdo neudělal.

Dobré zadání nemusí být dlouhé

Rozsah dokumentace by měl odpovídat riziku, počtu návazností a ceně nedorozumění. Ne velikosti prvku na obrazovce. Někdy stačí několik přesných vět, jindy jednoduchý diagram nebo tabulka scénářů.

Drobné úpravy často nejlépe odhalí dlouhodobé problémy systému: několik formátů stejných dat, více zdrojů pravdy, nekonzistentní validaci, skryté závislosti nebo rozhodnutí ponechaná na odhadu dodavatele.

Požadavek nekončí na obrazovce

Z věty „omezit telefon na devět číslic“ se stala otázka vstupu, formátování, validace, uložení a předání do dalšího systému. Z věty „opravit adresu v pravé části“ se stala otázka, odkud jednotlivé části formuláře data načítají a která hodnota je v daném kontextu správná.

Ani jeden problém nebyl složitý jen kvůli programování. Složitost vznikala hlavně v souvislostech. Dobré zadání nemusí předepisovat každý technický detail. Mělo by ale odstranit situace, ve kterých musí vývojář sám hádat provozní pravidlo nebo význam dat.