Přechod na produktově orientované IT (příklady z praxe)

U IT projektů se opakuje stále stejný problém. Jak týmy přecházejí z jednoho na další, „je to, jako by začínal každý program od nuly, namísto snahy o navázání na to, co se již podařilo“, říká Sreelakshmi Kolli, viceprezidentka pro IT ve společnosti Align Technology, která vyrábí lékařské přístroje. „Ztrácí se kontinuita v myšlení.“

Kolli však pracuje na změně uvažování v celé globální firmě, a to zavedením řízení IT orientovaného na produkt s využitím agilních metodik a produktových týmů sestavených ze zástupců obchodu, marketingu a IT, které udržují v chodu neustálý cyklus inovací. „Začali jsme loni jednou produktově orientovanou iniciativou a letos plánujeme tři další,“ říká Kolli.

Více než polovina (55 %) dotázaných v průzkumu společnosti Gartner tvrdí, že přechází z projektového na produktový přístup jako způsob, jak v podniku průběžně vytvářet a zavádět nové funkce a schopnosti. Tyto společnosti realizují změnu mimo jiné zaváděním nových architektur a nástrojů (39 %) investicemi do vývojových metodik DevOps (35 %) a náborem pracovníků s potřebnými novými dovednostmi (32 %).

Cesta od projektově orientovaného k produktově orientovanému řízení IT má však svá úskalí. Předpoklady úspěchu jsou podrobná analýza aktuálně poskytovaných výstupů, získání nových dovedností školením nebo náborem pracovníků a změna uvažování všech dotče­ných.

Andy Rowsell-Jones, viceprezident a ředitel výzkumu ve společnosti Gartner, tvrdí, že většina podniků na cestě k produktovému řízení narazí na tři překážky: neustálé problémy s financováním, složité sestavování produktového týmu se správnou kombinací dovedností a potíže s hledáním manažerů pro různorodé produkty.

„Dobrá zpráva je, že většina podniků tento přechod podstupuje,“ říká Rowsell-Jones, jenž spolu s CIO, kteří mají změnu úspěšně za sebou, nabízí rady a praktické zkušenosti se zaváděním produktově orientovaného IT.

Vymýšlejte, tvořte, zavádějte, propagujte

Rozsah změn se sice u každého subjektu liší, ale většina produktově orientovaných přístupů má řadu společných znaků.
„Každý produktově orientovaný přístup zahrnuje metodiku DevOps,“ říká Rowsell-Jones. „Podaří-li se vám ji uvést do praxe tak, aby fungovala spolehlivě a opakovatelně, máte dobrý základ.“

Vývoj produktů má čtyři fáze, dodává. Týmy se musejí nejprve rozhodnout, jaké funkce bude nový produkt mít, a následně jej vytvořit, zavést a aktivně propagovat – „to je něco, na co technicky zaměřené týmy obvykle nemyslí“, vysvětluje Rowsell-Jones. Úspěch v tomto novém uspořádání světa vyžaduje, aby produktoví manažeři a CIO hovořili se zákaznickými skupinami, analyzovali, co zákazníci říkají na sociálních sítích, zkoumali míru loajality klientů, porovnávali své výsledky s konkurencí – to vše s cílem zjistit, jaké úpravy nebo nové funkce je nutné přidat do procesu průběžného vývoje produktů.

Avšak první překážkou, na kterou většina podniků naráží, je podle Rowsell-Jonese financování. U typického projektu utratí IT oddělení většinu nákladů na počátku a následně výdaje klesají. Produktový model je oproti tomu typicky „zpočátku levnější“, ale výdaje budou pokračovat „dlouhodoběji po menších částkách“, říká Rowsell-Jones.

Dalším úskalím je nalezení schopných produktových manažerů. „Produktoví manažeři musejí rozumět technické stránce a zároveň trhu, na kterém se pohybují,“ vysvětluje Rowsell-Jones. Kvůli tomu se produktoví manažeři obvykle rekrutují z obchodní sféry. „Musejí rozhodovat, které funkce přidat nebo ubrat, a jsou odpovědní za propagování produktu, získávání zpětné vazby a její zohledňování při dalším rozhodování. Proto je tak těžké kvalitní produktové manažery nalézt.“

Ani udržet vysoké pracovní nasazení produktového týmu není snadné. „Má-li DevOps tým neustále pracovat v rychlém tempu, po čase to začne být skutečně náročné,“ upozorňuje Rowsell-Jones.

Nový pohled na rozpočet

Pradip Sitaram, CIO společnosti Enterprise Community Investment, narazil na všechny tři uvedené překážky, když se před třemi roky snažil o přechod na produktově orientované řízení jako způsob, jak vytvořit smysl pro vlastnictví nad řešeními, na nichž jeho tým pracoval. „Klíčem nejsou technologie,“ říká. „Klíčem k úspěchu je vztah s byznysem – angažovaný byznysový partner.“

Nejprve Sitaram zpochybnil praxi projektových rozpočtů na kalendářní rok. „Obvykle jsou takové rozpočty nerealistické. Ale takto to nikdy nefunguje,“ říká. Sitaram namísto toho navrhl, aby byznysoví manažeři předložili rámcovou představu, co potřebují, kolik peněz na to mají a kdy to potřebují mít hotové. Společný tým by následně vymyslel nejlepší produkt, jaký je možné s danými prostředky a v daném čase vyvinout.

Zpočátku se setkával s určitým odporem. Jeden obchodní manažer mu namítl: „Když vám povím, kolik mám peněz, utratíte je všechny.“ Ale jak Sitaram zdůrazňuje: „Vše, co děláme, musí být založené na důvěře. Pracujeme přece všichni pro jeden podnik.“ V současné době v jeho investiční společnosti pracuje na produktech zhruba desítka DevOps týmů, každý sestavený z technických a obchodních expertů, vedený produktovým manažerem z obchodní sféry.

„Nezačínáme bez byznysového vlastníka produktu, který je oprávněný hovořit a jednat za celou firmu, stanovuje priority a rozhoduje,“ říká Sitaram. „Někdy je těžké přesvědčit vedení, aby na takovou práci uvolnilo manažera, ale pokud vaše obchodní jednotka investuje do nového produktu, je ve vašem zájmu nalézt vlastníka produktu a alokovat jeho čas.“

Hledá se znalec

U globální automobilové společnosti Holman Enterprises spočívá přístup orien­tovaný na produkt menší měrou v zavádění nových technických nástrojů a větší měrou v nalézání správných lidí, říká výkonný viceprezident a generální ředitel Steve Haindl.

„Máte-li k dispozici lidi, kteří skutečně rozumějí byznysu, nástrojům a všemu, co je potřeba k dosažení požadovaného výsledku, potom máte správnou úroveň odborných znalostí, abyste věděli, na čem pracovat a na čem nepracovat,“ říká Haindl.

Každá ze tří obchodních linií společnosti Holman má tým pro produktové řízení sestavený ze zástupců IT, obchodu a marketingu. Každý tým má také „miniCIO“, který rozumí obchodní činnosti podniku. „Zavést takovou strukturu trvalo pět nebo šest let,“ říká Haindl.

„Většina členů produktových týmů se v poslední době vrátila do školy získat magisterský titul nebo MBA,“ říká Haindl. „Vyučený mechanik, který ve firmě pracoval 20 let, získal nové dovednosti a naučil se, jak stavět analytické platformy,“ dodává.

Dnes podle Haindla díky produktově orientovanému řízení pracují správné týmy na správných projektech a iterativní, agilnější přístup funguje dobře. „Přechod z projektového na produktové řízení jednoznačně dává smysl,“ říká Haindl. „Ne každý produkt jej nutně vyžaduje – ale na úrovni klíčových projektů se rozhodně tato forma interní spolupráce a kombinace dovedností vyplatí.“

Technologie na prvním místě

Ve společnosti Align Technology procházely projekty tradičním procesem vývoje s pilotní fází a limitovaným uvedením na trh. „V každé fázi jsme používali technologie, jaké se právě hodily,“ říká Kolli.

„Nyní je každý členem hlavního týmu. Všichni chápeme, v čem problém spočívá a s čím má kdo přijít. Jak nejrychleji sestavit něco, co můžeme otestovat na trhu? Jak to můžeme dále rozvíjet, jakmile zjistíme, co se zákazníkům líbí a nelíbí?“ Jedno vydání průběžně přechází do dalšího.
Produktově orientovaný přístup firmy je možný částečně díky technickým rozhodnutím v průběhu několika let. „Snažili jsme se o větší modularitu a téměř vše máme v cloudu,“ říká Kolli. „Budujeme více mikroslužeb a nasazujeme je v kontejnerech. Díky tomu můžeme mít menší týmy, které jsou akceschopnější a dopodrobna znají svůj kód. Dříve, když jsme měli velké monolitické architektury, nebylo reálné, aby měl malý tým lidí přehled o celém kódu.“

Jedním z nejtvrdších oříšků u produktově orientovaného řízení IT je zajistit, aby nezůstaly opomenuty základní prvky. „Než se pustíte do změn, musíte zajistit, že máte k dispozici veškeré potřebné prostředky – logování, monitoring, zabezpečení, ochranu soukromí nebo napojení dat na širší repozitáře,“ říká Kolli.

Výhled do budoucna

Gartner podnikům radí, aby před přechodem na produktové řízení zjistily, jaké se u nich vyskytují technické překážky, a kolektivně hledaly řešení.
„Pokud například není produkt založený na API, je skutečně těžké aplikovat DevOps. Nebo pokud tvoříte složitý systém záznamů, musíte jej nechat na příslušných úrovních schválit,“ upozorňuje Rowsell-Jones.

Je také důležité věnovat pozornost lidskému faktoru a řešit jak změnu kultury, tak kvalifikační předpoklady. Nejdůležitějším předpokladem úspěchu je budování vztahů s obchodními složkami a dalšími zainteresovanými stranami v podniku a vysvětlování přínosu IT pro digitální byznys.