Existuje něco jako předloha či plán pro tvorbu digitálních produktů? Podle analytika Gartneru Jasona Wonga, který v minulém týdnu na toto téma přednášel na semináři v pražském hotelu Imperial, existuje (dostaneme se k němu za okamžik). V praxi nicméně podle Wonga většina organizací vytvářejících vlastní systémy, ty tvořící software nevyjímaje, ve skutečnosti vyprodukuje cosi, co připomíná kopii jejich vlastní komunikační struktury. Poprvé si tohoto fenoménu všiml v roce 1967 Melwin Conway a přeformuloval jej do definice známé dnes jako Conwayův zákon (či chcete-li, Conwayova poučka). O dvacet let později (1988) si téhož všiml Nigel Bevan v případě webových portálů, když konstatoval: „Podniky často vytvářejí weby s obsahem a strukturou, která odráží jejich interní myšlení, spíše než potřeby uživatele – návštěvníka webu.“
V praxi to znamená, že má-li nějaký podnik či jeho IT organizace vytvářet a dodávat (respektive provozovat) digitální produkty či služby, musí se zásadně proměnit. Podle Wonga jsou přitom důležitá tři „digitální“ pravidla: není možné začínat znovu (nahrazovat znovu a znovu celé systémy je příliš nákladné, riskantní a časově náročné, navíc to má velký dopad na byznys). Není možné vyčkávat (až bude vše „dotransformováno“) a konečně není možné do důsledku předvídat (kam se trh a naše produkty či služby vyvinou). To vše znamená, že průběžný model dodávání digitálních produktů (služeb) – označovaný často jako produktový model, produktové řízení či produktový způsob dodávky – mění především fungování na úrovni týmů, jejich znalostí, dovedností a interakcí (jsme zpět u Conwayova zákona).
Namísto definovaných, oddělených a časově omezených projektů nastupují „tekuté“, leč trvalé multidisciplinární týmy s produktovými řadami, jež disponují především byznys znalostmi a novými typy znalostí technických (často méně hlubokých než v minulosti – což je dáno mimo jiné využíváním low-code či no-code nástrojů). Práce tedy probíhá v krátkých iteracích „nekonečného“ cyklu DesignOps a DevoOps s velkým významem a důrazem kladeným na zapojení „civilních“ vývojářů (citizen developers) a IT (spolu)řízeného do značné míry byznysem. V technologické oblasti pak jde o prvky jako MASA (Mesh App and Service Architecture – přinejmenším duchovní nástupce SOA), multiexperience (přístup z různých typů zařízení a rozhraní) či hybridní aplikační platformu. Klíčovým kritériem pro hodnocení výstupů přitom není seznam vytvořených funkcí, ale hodnocení zákazníka (CX) a obchodní výsledky. Odlišnosti se pochopitelně týkají také financování a dalších oblastí, jak o tom hovořil v krátkém rozhovoru, který jsme vám nabídli minule, viceprezident a analytik Gartneru Matthew Hotle.
Pokračování z INSIDE Observer
Co se zmíněného plánu či nákresu týče, ten zjednodušeně řečeno kombinuje výše uvedené a nabízí přehled klíčových funkcí, které bude třeba v rámci produktového modelu obsadit (produktový manažer typicky na straně byznysu, produktový vlastník na straně IT, UX lead, DevOps Leader a další), týmů, jež velké organizace nejspíš budou muset vytvořit (produktové, platformní), rozhraní, které je obvykle třeba podporovat (psaní, dotyk, chat, gesta, hlas), a dovedností či technologií i domén, jež bude třeba zvládnout či zapojit. Konkrétní výběr a tvorba individuálního plánu a nákresu se pochopitelně budou lišit podle dané společnosti a trhu, který obsluhuje – a může být výtečným tématem pro diskuzi s Gartner analytikem.
Napsat komentář