Rád vzpomínám na svou roli solution architekta v projektu Chytré auto (zdravím kolegy do T-Mobile), ve kterém prototypování bylo velmi důležitou součástí dodávky. Princip služby je takový, že do ODB konektoru v autě dáte malou krabičku, ve které je SIM karta. Tato krabička vám pak kromě jiného na telefon posílá notifikace o tom, že auto nastartovalo, že ho někdo odtahuje nebo že byly zaznamenány otřesy. Jestliže pak nejste původcem zmíněné činnosti, tak to značí, že byste se k autu měli dostavit dříve, než bude pozdě.
Prototypování spočívalo v tom, že jsme dostali testovací krabičku a s tou jezdili. Cílem bylo jednak zjistit životaschopnost takové služby a jednak nastavit parametry krabičky tak, aby notifikace chodily jen v oprávněném případě.
Během testů jsem večer přijel domů a zaparkoval auto na jednom z posledních míst. Než jsem šel spát, nic se nedělo. Na noc telefon vypínám, takže jsem spal spokojeně jako vždy. Ovšem o to horší situace nastala po ranním zapnutí telefonu: dostal jsem notně přes sto notifikací o otřesech auta. Vyskočil jsem zděšeně z postele, abych ho z okna zkontroloval. To však stálo spokojeně na místě, kde jsem ho večer opustil. Co se tedy stalo? Zjistil jsem to, až když jsem k němu přišel. Zaparkoval jsem totiž pod jírovcem a ten mi na auto celou noc pouštěl jeden kaštan za druhým. Co kaštan, to notifikace. Výsledkem tedy bylo, že bylo potřeba snížit citlivost čidla v krabičce.
A přesně tohle byla situace, na kterou byste v kanceláři při hledání vhodného nastavení přišli jen při hodně velké fantazii. A teď si představte, že byste prototypování neprovedli a produkt dali rovnou zákazníkům. Jak by asi byli spokojení?
Uvedený příklad ukazuje, že prototypování opravdu má své nezastupitelné místo při dodávce změn. Zkušený business analytik by měl rozpoznat situace, kdy je dobré prototypování provést a poté jej realizovat.
O prototypování, ale i mnohém dalším se můžete dozvědět na mých školeních business analýzy.