Osm tipů pro správu „občanských“ low-code vývojářů

Podle společnosti Gartner vytváří nebo přizpůsobuje svá vlastní řešení 41 % zaměstnanců mimo IT – a do roku 2023 budou tito „občanští vývojáři“ ve velkých podnicích čtyřnásobně převyšovat profesionální vývojáře, předpovídá výzkumná firma. Většina organizací již používá alespoň jeden nízkokódový nástroj, přijatý odděleními nebo jednotlivými uživateli, kteří mají k řešení nějaký problém. Jednoho dne, možná brzy, se vývoj aplikací bez psaní kódu stane stejně běžnou obchodní dovedností jako e-mail a tabulky, předpovídá Forrester.

Ale s výhodou rychlejšího vývoje přicházejí větší rizika. Řízení nad zvýšenou autonomií, kterou přináší samoobsluha a nízký kód, se podle Gartneru stalo klíčovým faktorem, který musí IT zvažovat.

Zatímco formální struktury řízení ještě nejsou běžné, IT lídři začínají řešit problém správy nízkého kódu. „Vědí, že chtějí umožnit mnoha a mnoha lidem dělat technologickou práci, a chtějí to dělat polo-organizovaným způsobem,“ řekl John Bratincevic, senior analytik společnosti Forrester, pro web CIO.com.

Platformy s nízkým kódem přinášejí vyšší produktivitu, úspory nákladů a často i změnu kultury, která zlepšuje vztahy mezi podnikem a IT. Správně provedený nízký kód může organizacím pomoci dosáhnout neustálého zlepšování, které obchodní transformace vždy slibovala, s kulturou řešení digitálních problémů.

Zde je návod, jak mohou CIO pomoci občanským vývojářům být úspěšní pragmatickým způsobem, který zmírňuje rizika, aniž by odrazoval od experimentování a samoobsluhy.

1. Vystupte ze stínu

Aby byl nízký kód úspěšný, IT lídři jej nemohou považovat za stínové IT a CIO by na něj neměli pohlížet jako na potenciální zátěž, říká významný analytik a viceprezident společnosti Gartner Jason Wong.

„Účelem občanského vývoje je říci, že máme dohodu mezi IT a byznysem, účast a vstup těchto občanských vývojářů do toho, co chtějí vybudovat, a pochopení toho, jaké nástroje jsou pro ně nejlepší,“ říká.

Platformy s nízkým a žádným kódem navíc neposkytují pouze způsob, jak vytvářet aplikace vizuálně: centralizují také přístup a zdroje a sledují, jak jsou používány. Díky tomu může IT vytvářet zásady o tom, kdo bude mít přístup k jakým zdrojům dat a jak smí sdílet aplikace a automatizační toky, které tato data zahrnují.

Granulární řízení přístupu založené na rolích umožňuje IT řídit přístup ke konkrétním koncovým bodům a datovým tabulkám až po úroveň pole a záznamů, čímž poskytuje odpovídající přístup k různým oddělením v různých vývojových prostředích. Měli byste být také schopni spravovat, jaké konektory jsou k dispozici a jaké akce mohou být prováděny na koncovém bodě. Můžete například chtít, aby zákaznická podpora mohla vytvářet aplikace, které mohou číst tweety, ale neuveřejňovat je, nebo se můžete rozhodnout globálně umožnit uživatelům s nízkým kódem aktualizovat záznamy, ale nikdy nic nemazat.

2. Vyvažujte kontrolu a autonomii

Získání správné rovnováhy kontroly a autonomie pro občanské vývojáře je zásadní. Nechcete špatné zabezpečení, ale pokud jsou procesy správy a přístupu příliš náročné, lidé se prostě vrátí k neřízenému stínovému IT.

To bude vyžadovat plánování, poznamenává Bratincevic. „Není to extrémně složité, ale musíte si to všechno dobře promyslet a je to specifické pro vaše prostředí,“ říká a dodává, že než budete moci nastavit správu, jsou klíčová data. „Základem toho je: Jaká data máme a která jsou citlivá a která ne.“

Ujistěte se, že používáte ochranu před únikem dat na všechna data sdílená externě, a mějte zásady, které varují občanské vývojáře, pokud vytvářejí automatizaci nebo pracovní postup, který by mohl porušovat dodržování předpisů – například kopírování e-mailů nebo PII.

Občanští vývojáři by také měli mít autonomii při výběru platformy. Je chybou nutit firmu ke standardizaci na jediné platformě s nízkým kódem, varuje Wong. Pokud firemní uživatelé nemají pravomoc vybrat si nástroje, které jim fungují, nemáte k dispozici občanský vývoj.

Místo toho se spolehněte na svůj rámec řízení a ujasněte si, jakou podporu mohou tito uživatelé očekávat, pokud si vyberou jiný nástroj, říká Wong. „Zde je rozsah toho, co můžeme udělat; tady je bezpečná zóna. Pokud chcete spoluvytvářet, zde jsou věci, které můžeme spoluvytvářet a podporovat,“ dodává jako příklad, „ale neočekávejte, že IT vycvičí zdroje, aby porozumělo tomuto specifickému nástroji pro vytváření komponent a widgetů v této platformě; na to prostě nemáme dostatečný záběr.“

3. Zvolte správný strategický přístup

Klíčové je také vytvoření správného strategického modelu pro záležitost občanského vývoje ve vaší organizaci.

Forrester identifikuje tři běžné přístupy, z nichž první je malý, autonomní tým složený z lidí se zkušenostmi se zlepšováním procesů, schválený IT oddělením, ale začleněný do obchodní jednotky a podřízený obchodnímu manažerovi. Tento strategický přístup je velmi agilní, ale nebude škálovatelný, říká Bratincevic: „Je to přirozené, když veškerou práci dělá malý tým.“

Druhý přístup je samoobslužný, ve kterém může kdokoli vyvíjet nástroje s nízkým kódem založené na politikách a vedení v rámci platforem. „Ovládáte ‚co‘, místo toho ‚kdo‘,“ říká Bratincevic. „‚Kdo‘ je kdokoli, ale to ‚co‘ je omezeno povahou platformy a přístupem k datům, který jim poskytujete.“

Třetí, nejvyspělejší přístup kombinuje agilní týmy a širokou demokratizaci do federovaného modelu s centrem excelence, které spravuje platformy s nízkým kódem, zavádí ochranné vedení a podporuje týmy nebo jednotlivé nadšence v odděleních a obchodních jednotkách, stejně jako samoobslužné vývojáře nízkého kódu.

V tomto modelu závisí způsob vývoje konkrétní aplikace na jejím případu použití, použitých datech a zkušenostech zúčastněného vývojáře, vysvětluje Bratincevic. „Můžete mít více či méně kroků v životním cyklu vývoje zabezpečení; můžete mít více či méně požadavků na náhledy; možná budete muset s někým spolupracovat, než použijete určitý zdroj dat.“

Tento vyspělý model je složitější „ale je to také ten, který pokrývá většinu oblastí: ovládáte data, řídíte vývojový proces, ale jednáte pragmaticky,“ říká.

4. Poskytněte odpovídající IT podporu

Kromě řízení a politik musí CIO poskytovat zdroje a podporu. „Postoj IT k občanským vývojářům je neuvěřitelně důležitý pro jejich produktivitu a jejich úspěšné výsledky,“ říká Wong ze společnosti Gartner.

Za tímto účelem Gartner navrhuje formalizovat občanský rozvoj pomocí rámce řízení, který pokrývá „zelené“ bezpečné zóny, kde mohou občanští vývojáři vytvářet pracovní postupy a automatizaci; „žluté“ zóny podpory, kde občanští vývojáři spolupracují s profesionálními vývojáři na vytváření výkonnějších aplikací; a „červené“ nebezpečné zóny, které vyžadují dohled a schválení IT, přičemž některé aplikace jsou považovány za tak složité a kritické, že zůstávají pod kontrolou IT.

Středisko excelence (COE) může například vytvářet rozhraní API a vlastní komponenty nebo umožnit vznik fúzních týmů s profesionálními vývojáři, kteří pracují v prostředí s nízkým kódem i v tradičních vývojových prostředích. COE může také poskytovat výukové zdroje a odbornou pomoc pro občanské vývojáře pro složitější nebo kritičtější práci, jako je psaní dotazových výrazů, možná s otevřenou pracovní dobou.

Tento druh spolupráce a podpory je to, co odlišuje nízký kód od stínového IT.

„V rámci stínového IT máte jednotlivce, kteří jednají na vlastní pěst, dělají věci, které jsou ve stínu, mimo dohled,“ říká Wong. „Občanský vývoj říká: Pojďme to otevřít, aby se uživatelé nebáli výtky za používání těchto nástrojů. Máme pro ně cestu, jak se učit, tak jak potřebují: Chtějí jít zkrátka dostatečně do hloubky, aby vybudovali to, co potřebují, a učili se za pochodu, se schopností požádat o pomoc komunitu, ostatní pokročilé uživatele, ale také potenciálně i IT oddělení.“

5. Získejte správná rozhraní API a konektory

Aby bylo možné uspět, musí být IT oddělení proaktivní při zpřístupňování konektorů a vytváření robustních rozhraní API pro přístup k interním datům.

„Ujistěte se, že jsou vaše rozhraní API dobře definovaná, mají vrstvu správy nebo katalog a že je lze snadno připojit pomocí těchto řešení s nízkým nebo žádným kódem,“ říká Kin Lane, hlavní evangelista v platformě API Postman.

Musíte také sledovat, kde se rozhraní API používají ve výrobě, abyste měli přehled o nákladech na externí rozhraní API a abyste se ujistili, že systémy, které dodávají interní rozhraní API, mají odpovídající zdroje. Ne vše, co funguje jako API, je vytvářeno robustním backendem. „Jakkoliv bychom rádi věřili, že dobře navržené RESTful API je to, co tvoří API; to prostě není pravda,“ poznamenává Lane. „FTP lokace s CSV je považována za API, a tabulky jsou král.“

A nezapomeňte na robotickou automatizaci procesů (RPA), stále populárnější způsob, jak dostat informace ze starších systémů do aplikací s nízkým kódem a automatizačních pracovních postupů. Zavedením pracovního postupu RPA, který například automatizuje extrakci dat z naskenovaných PDF, může IT dále umožnit vývojářům občanů vytvářet přínosné obchodní aplikace.

6. Nezapomeňte na recenze a metriky

Jednotliví firemní uživatelé, kteří řeší svůj vlastní problém, pravděpodobně nebudou myslet na vysokou dostupnost, obchodní metriky nebo jakékoli formální recenze. Jen málo platforem s nízkým kódem k tomu obsahuje nástroje, ale užitečné mohou být metriky, jako je čas potřebný k dokončení procesu, stejně jako zavedení pravidelných kontrol pro sledování výkonu a analýzu příležitostí pro další vývoj.

Metriky a recenze také poskytují příležitosti ke zkoumání podnikových procesů, protože automatizace špatného procesu vám rychleji přinese špatné výsledky. Pomocí nástrojů pro dolování procesů [process mining tools] odhalte neefektivitu nebo práci navíc, kterou mohou některé týmy vykonávat, a dejte zaměstnancům, kteří na procesu skutečně pracují, příležitosti k jeho zefektivnění, místo aby jen vytvářeli aplikace, které problém „zalepí leukoplastí“.

7. Vyvíjejte operace podle potřeby

Analytické a monitorovací nástroje na platformách s nízkým kódem mohou nejen sledovat využití API, ale také vás upozornit na aplikace, které se staly tak populárními nebo kritickými pro podnikání, že je možná budete chtít přesunout do žlutých nebo červených zón podpory vyšší úrovně, jak je načrtla společnost Gartner.

Průkopnické nápady, které se promění v aplikace, jež jsou tak populární, že potřebují větší podporu IT, jsou známkou podnikové inovace, říká Wong. Úkolem IT je, aby to bylo udržitelné.

V praxi může tento postup vytvářet napětí; původní vývojář nízkého kódu může mít obavy z převzetí nástroje IT oddělením a tým IT může mít obavy z podpory aplikace, kterou nevytvořil nebo nespecifikoval. Kultura spolupráce mezi podnikem a IT by měla pomoci vyhnout se podezření na obou stranách.

8. Podporujte kulturu inovací

I když se můžete obávat, že experimentování s nízkým kódem vytvoří příliš mnoho aplikací, s nimiž si váš IT tým neporadí, častějším problémem je, že nenabírá dostatek hybnosti, aby strategie fungovala. Mnoho podnikových uživatelů s problémy, které by jim mohl pomoci vyřešit nízký kód, se přirozeně nebude považovat za „vývojáře,“ zdůrazňuje Bratincevic.

„Existuje spousta technicky smýšlejících lidí z podniku, kteří dělají technickou práci nebo stínové IT,“ říká, ale „dokonce ani lidé, kteří tuto práci dělají, nebudou nutně chtít kupovat formální program s platformou řízení.“

Mnoho organizací zjistí, že interní hackathony – s časem na školení, mentoring a podporu – mohou nastartovat zájem a vytvořit jádro počátečních aplikací. Případně vyhledejte řešitele problémů, kteří by mohli vzkvétat jako první uživatelé. Lidé, kteří již stínové IT používají jako součást role, jež zahrnuje neustálé zlepšování nebo speciální projekty, jsou hlavními kandidáty na to, aby se stali podporovateli [nízkého kódu], zvláště pokud si vyžádali aplikaci, na které IT oddělení nemělo čas začít pracovat.

Nízký kód může umožnit významný kariérní postup, kdy podnikoví a přední pracovníci získávají odborné znalosti pro techničtější role. Berte to jako způsob růstu vaší budoucí digitální pracovní síly – a buďte připraveni podporovat a odměňovat zaměstnance, abyste toho dosáhli. Jedním z důvodů, proč se programy s nízkým kódem nedaří škálovat, je očekávání, že zaměstnanci na nich budou pracovat vedle své každodenní práce, spíše než aby šlo o její součást, zvláště pokud podniková kultura neoceňuje neustálé zlepšování.

Musíte se také vypořádat s lidským aspektem řízení změn. Co když původní občanský vývojář přejde na jinou práci a jeho kolegové nebo náhradníci nemají o aplikaci zájem? Nebo, pokud mají zájem, byly účel a pozadí aplikace dostatečně zdokumentovány pro předání?

Na druhou stranu ne každá aplikace s nízkým kódem zůstane užitečná navždy, říká Wong. „Pokud nikdo nepřistoupí k tomu, aby převzal její vlastnictví, pak musí být předpoklad takovýto: Nebylo to příliš užitečné; nech to zemřít." To je jen minimální problém, když jsou náklady na implementaci tak nízké.

Myslete na nízký kód jako na příležitost, ale také si uvědomte, že je nevyhnutelný, navrhuje Bratincevic.

„Nebude to dokonalé; vyskytnou se problémy, uděláte nějaké chyby, ale toto je vaše příležitost zorganizovat všechny lidi vyvíjející aplikace v celé organizaci způsobem, který je propojený, automatizovaný a rozumný; vytvořit ten správný základ spíše než nechat vše na náhodě.“