Kapacita a kompetence

Pustili jste se s dodavatelem do projektu, na jehož konci má vzniknout interní aplikace, webový portál, prezentace nebo mobilní appka. Pečlivě vybíráte partnera, aby splňoval požadavky - mj. by měl na projekt dostatek dostupné lidské síly, která se navíc bude v dodávce spolehlivě orientovat. To je logické, takže zatím vše v pořádku ✅

Ale není to jednosměrné. Kompetence a kapacita nejsou jen o dodavateli. Většina projektů potřebuje hromadu součinnosti od vás. Často víc, než byste čekali. Budete nahánět své klienty na rozhovory, předávat specifické informace o procesech, vyjadřovat se k návrhům, schvalovat scénáře, topit se v iteracích obsahu, řešit změnové požadavky stakeholderů... prosím, nenuťte mě vymýšlet další příklady.

Budete potřebovat spoustu času, pořád, průběžně. A nejen vašeho, ale taky kolegů — protože typicky se stává, že jediná Radka ví, jak na na API funguje konkrétní proces. Aha, Radka včera odjela na tři týdny do Patagonie. Tak asi budeme muset počkat.

My jako dodavatelé se snažíme na takový bottleneck včas upozorňovat. Občas se i tak nevyhneme otázce: “Nemůžete si tohle zjistit sami?” Můžeme, ale často na to nejsou peníze nebo čas.

Jednoduše shrnuto — technologické projekty vás zatíží spíš víc než míň. A pokud víte, že kapacitu nebo kompetence na projekt dát nemůžete, dohodněte se s dodavatelem co nejdřív, jak se k daným informacím zvládne dostat sám a co to bude obnášet. Projekt tím jenom získá, a vy taky.

Analytika a KPIs

Sedmnáct verzí vizuálního designu, čtyřikrát vyměněný obsah včetně dvou iterací fotek managementu a stakeholderů. Zcela neadekvátní pozornost a priorita.

A když přijde na nastavení vhodných KPI (klíčových ukazatelů výkonnosti), získávání relevantních dat o užívání a jejich budoucí vyhodnocování, často fokus limituje k nule ❄

“Hodíme tam Analytics,” je klasická rychlá záplata. Jasně, to je základ, to se udělá — ale co pak? Kdo a jak často bude ta data posuzovat? Vůči jakým očekáváním? Kdo bude na základě těch dat tvořit hypotézy k testování nebo implementaci?

Přitom u většiny webových a mobilních aplikací se dá měřit alespoň něco. A přemýšlet o tom se musí už v analytické a UX fázi projektu, ne až týden před launchem, kdy se tam pak prostě plácne ta výše zmíněná záplata.

Čísla a kvantifikovatelné ukazatele jsou navíc univerzálně srozumitelné, na rozdíl od subjektivních faktorů, jako je třeba vzhled. Pokud nedojde k misinterpretaci takových výstupů, každý dostane stejné sdělení.

Je proto důležité přemýšlet nad tím, co vám ta konkrétní věc (webová aplikace, portál, mobilní appka) přináší v reálném světě. A jak můžete (a budete!) sami nebo prostřednictvím dodavatele měřit a hodnotit, zda ten přínos odpovídá očekávání.

A hlavně pak máte v rukou perfektního hashtag#nobullshit průvodce, kam se projekt může vyvíjet a posouvat dál. 🚀

Potkat realitu co nejdřív

Je těžké si to přiznat a většinou to přijde až po sérii špatných zkušeností - ale dodavatel neví všechno nejlíp. A zadavatel rozhodně nemá patent na správnou odpověď.

Ten, kdo má většinou pravdu, i když se nám to často nelíbí, je uživatel. Persona (nebo více person), pro kterou se daná aplikace vytváří 🙋‍.

Dodavatel vychází při své práci ze zkušeností. A pokud je proces nastaven správně, testuje své výstupy různými metodami (právě na reprezentantech koncových uživatelů). Ale i tak se stává, že se uživatelé v reálném provozu chovají - v důležitých i méně důležitých faktorech - jinak, než se očekávalo.

Mířím tím k jediné věci - nečekejte na to, až bude produkt dokonalý v každém detailu. Dostaňte ho tzv. “na trh”, i když třeba s omezenými funkcionalitami nebo bez nekonečných designových iterací.

Protože je možné, že “market” ukáže, že jsou potřeba zásadní změny. A vy je díky tomu zjistíte možná o měsíce dříve. Můžete tak investovat čas a peníze do toho, co je opravdu důležité, místo do méně podstatných věcí nebo kosmetických úprav.

Market je hashtag#nobullshit realita.

Drobení požadavků je drahé

Vnímání projektů se často mění, jakmile se přejde z původně stanoveného rozsahu prací do fáze víceprací a dalšího rozvoje.

Najednou se může zdát, že i malé úpravy stojí nečekaně hodně peněz, a to i u relativně menších projektů.

Není to tím, že se dodavatel rozhodl začít vás brát na hůl (alespoň by nemělo).

Za prvé, při každém novém tasku je už třeba brát v potaz zbytek dané aplikace, která může být navíc v ostrém provozu. Aby se nic nerozbilo, je nutná větší opatrnost a důkladnější kontrola.

Důležitější však je, že každá změna představuje celý proces. Zahrnuje zadání, specifikaci, řešení dotazů. Vývoj, kolečko code reviews (které vyžaduje čas dalšího člověka). Nasazení na testovací prostředí, interní a externí testování, a komunikaci. Nasazení na produkční prostředí, další kolo testování a opět komunikace.

Ten proces lze samozřejmě optimalizovat, pokud se řeší více úkolů najednou. Ale pokud se každý požadavek řeší samostatně, celý proces se musí opakovat pro každý úkol zvlášť, neoptimálně.

Připomíná to chození pro rohlíky po jednom. Nejdete si koupit jeden rohlík, protože ho právě teď chcete sníst. Zamyslíte se a koupíte jich víc. Další sníte později, nebo koupíte rohlíky taky pro někoho jiného.

Pokud se požadavky řídí tak, aby se zpracovávaly ve smysluplných celcích, lze výrazně ušetřit čas i peníze. Komplexní proces se tak nemusí neustále opakovat a práce se provádí efektivněji. A dosáhnout toho je to úkol jak pro dodavatele, tak pro klienta.