Create IT Blog - co se děje v Cleverlance

 

 

Efektivita využití AI v testování softwaruhttps://create-it.cz/Blog/Stranky/AI_testing.aspxEfektivita využití AI v testování softwaru<p>​Doba, kdy bylo softwarové testování plně závislé na manuální práci testerů, kteří museli prověřovat jednotlivé části kódu a ručně hledat chyby, je pravděpodobně minulostí. Tato metoda byla nejen časově náročná, ale především vysoce závislá na lidském faktoru. V současnosti jsme ve světě testování softwaru svědky evolučního procesu; přechodu od zažitých metod automatizace k sofistikovaným technikám založeným na umělé inteligenci.</p><p>Umělá inteligence (AI) umožňuje testerům analyzovat rozsáhlé datové sady, predikovat chování systému a odhalovat potenciální problémy, které by mohly lidskému oku uniknout. AI se ve stále větší míře podílí na zdokonalování přípravné fáze testování. Pomáhá při psaní testovací strategie, testovacího plánu a také s konkrétními testovacími scénáři v programovacím jazyce dle vlastní volby.<br></p><p>K významnému nárůstu kvality testování došlo již s příchodem automatizovaného testování. Automatizované skripty dnes běžně provádějí opakující se úkoly bez potřeby lidské intervence, což vede ke zvýšení efektivity a objemu zvládnuté práce.<br></p><p>Aktuálně je jedním z nejběžnějších pomocníků využívaných při testování ChatGPT. ChatGPT-4 (Generative Pretrained Transformer) byl vyvinut společností OpenAI, organizací honosící se posláním vývoje umělé inteligence pro dobro lidstva. Přičemž jen společnost Microsoft investovala do projektu více než miliardu dolarů, další využití v prohlížeči AI BingChatGPT je již také dostupné na trhu.<br></p><p>Model GPT-4 byl trénován na obrovském množství dat dostupných na internetu. V této chvíli však pracuje model pouze s daty platnými do září roku 2021, stejně jako tomu bylo u jeho předchůdce. Jak již bylo řečeno, dokáže Chat GPT zlepšit kvalitu přípravné a realizační fáze testování. Funguje jako zkušený kolega, který je kdykoliv k dispozici k diskusi nad tématy a rutinními úkoly, se kterými potřebujete pomoci. Ve své práci je pak podstatně rychlejší než člověk. ChatGPT komunikuje primárně v angličtině. Češtině bez problému rozumí, ale jeho odpovědi v tomto jazyce jsou prozatím omezené a nevyužívají plného potenciálu modelu.<br></p><h2>Empirický výzkum potvrdil rychlejší a kvalitnější vyřešení úkolu s pomocí AI<br></h2><p>Z publikované empirické <a href="https://economics.mit.edu/sites/default/files/inline-files/Noy_Zhang_1.pdf" target="_blank">studie​</a> Massachusetts Institute of Technology autorů W. Noye a W. Zhanga je zřejmé, že pozitivní přínos ChatGPT je experimentálně měřitelný a prakticky využitelný. Jak dále uvádí Noy a Zhang, produktivita práce jednoho člověka během jednoho pracovního dne je složena ze složky rychlosti zpracování konkrétního úkolu a složky kvality poskytnutého výstupu. Realizovaného výzkumu se zúčastnilo 444 zaměstnanců, zejména zkušených analytiků dat. Každý z účastníků měl za úkol zpracovat dvě zadání oblasti, na kterou se specializují. Výstupem měl vždy být dokument typu krátký report, analýza nebo budoucí strategie v rámci dané oblasti.</p><p>První ze dvou zadaných úkolů vyřešili účastníci tradičním způsobem, bez pomoci umělé inteligence. Při řešení druhého úkolu byli náhodně rozlosováni do dvou skupin. První polovina zaměstnanců, experimentální skupina, měla tento druhý úkol vyřešit s pomocí ChatGPT. Druhá, kontrolní skupina, si měla vystačit s tradičními metodami bez pomoci AI. Zhruba 30 % účastníků pracující s ChatGPT neměla dříve s AI žádnou zkušenost. Vzniklé dokumenty z druhého experimentu byly hodnoceny expertním týmem specialistů schopných kvalitu výstupů odborně posoudit. Hodnocení se pohybovalo na škále 1–7, kdy 1 byla nejnižší a 7 nejvyšší možná známka. Výstup, tedy vypracovaný dokument, byl vždy hodnocen třemi nezávislými hodnotiteli. Hodnotitelům nebylo sděleno, zda byl výstup vypracován s pomocí umělé inteligence, či nikoli.<br></p><h2>Výsledek výzkumu překvapil, s pomocí AI došlo k nárůstu objemu zvládnuté práce o 60 %<br></h2><p>Fenomén kognitivní psychologie, známý jako kompromis mezi rych­los­tí a přesností, se v tomto výzkumu nepotvrdil. Došlo jak k rychlejší­mu vyřešení úkolů, tak k dosažení lepší kvality dodaných výsledků. V prvním experimentu tvorby dokumentu bez pomoci AI došlo k zhruba shodnému výsledku měřené kvality v obou sledovaných skupinách. Obě skupiny byly kontrolním srovnáním stejně výkonné jak v měřeném čase, tak v dosažené kvalitě výstupů.</p><p>V druhém kole experimentu trvalo zpracování úlohy s pomocí ChatGPT v průměru 17 minut. Kdežto průměr zpracování úkolu bez pomoci umělé inteligence trval 27 minut. V laboratorních podmínkách by tedy jeden pracovník během 8hodinové pracovní doby (480 minut) vytvořil 480/27 = 17,7 ucelených výstupů. Specialista s pomocí ChatGPT by pak vytvořil 480/17 = 28,3 hotových výstupů. To znamená navýšení produktivity práce o téměř 60 %! (28,3–17,7)/17,7 = 0,598. Tento rozdíl odpovídá 0,83 standardní odchylky, což je v experimentech hodnoceno jako rozdíl velký.<br></p><p><img src="/Blog/PublishingImages/Stranky/AI_testing/AI_graf_1.png" data-themekey="#" alt="" style="margin:5px;width:658px;" /><br></p><p>Kvantita jako taková by nás dostatečně neuspokojila, pokud by jí bylo dosaženo na úkor kvality. V tomto případě, a na základě nezávislého hodnocení tří odborníků na dané zpracované téma, tomu tak ale rozhodně není. Rozdané známky hodnotitelů na škále 1–7 dosáhly průměrného hodnocení 4,5 s pomocí AI a 3,8 bez pomoci AI. Jak již bylo zmíněno, hodnotitelé nevěděli, zda byl výstup zpracován s, nebo bez pomoci ChatGPT. Standardní odchylka posunu kvality výstupu nabyla hodnoty 0,45. Tato hodnota je přesně na hranici malé až střední změny ve sledovaných parametrech výzkumu.<br></p><p>Největšího efektu dosáhla umělá inteligence v rychlosti zpracovávaných úkolů. Došlo ale také k mírnému až střednímu posunu v kvalitě dodaných výstupů. Vzhledem k nízké čí žádné předchozí zkušenosti s ChatGPT lze časem díky postupnému nabývání zkušeností s nástroji AI očekávat ještě vyšší rychlost a kvalitu při dosahování plnění zadaných úkolů. Zajímavé by bylo zopakovat celý experiment se vzorkem uchazečů, kteří mají předchozí zkušenost s využitím ChatGPT řekněme 75 %. Postupně se očekává nárůst zkušeností práce s nástroji umělé inteligence. Výsledky experimentální skupiny s vyšší zkušeností využití nástroje by pravděpodobně vedly k ještě výraznějším rozdílům ve výkonu mezi kontrolní a experimentální skupinou.<br></p><h2>Reálný příklad z praxe psaní regresních testů<br></h2><p>Psaní základního regresního scénáře zabere zkušenému testerovi zhruba 30 minut. S pomocí ChatGPT zvládne tester regresní scénář napsat a vyladit za polovinu času. Hlavní přidaná hodnota spočívá v domyšlení všech pozitivních i negativních cest, které mohu po zadání analýzy požadavků nastat. Jednoduše řečeno, tester přenese rutinní úkoly na stroj a uvolní si kreativní část mozku k řešení komplexnějších úkolů a dohledu nad celkovým výstupem přípravy testování. V kombinatorice je ChatGPT dobře vytrénován a jeho výstupy pomohou eliminovat riziko zanesení chyb. Stejně tak pomůže s určením vah důležitosti a priorit jednotlivých scénářů při udržení komplexit a integrity celku. Zejména při velkém počtu testovacích scénářů v řádech tisíců je zachování nezávislého arbitra při výběru kritických cest nutných k otestování zcela klíčové.<br></p><p><img src="/Blog/PublishingImages/Stranky/AI_testing/AI_graf_2.png" data-themekey="#" alt="" style="margin:5px;width:658px;" /><br></p><h2>Detailní analýzy přečte chat GPT za vás a extrahuje ty nejdůležitější myšlenky<br></h2><p>Reálně dokáže ChatGPT efektivně navrhnout také komplexní testovací strategii, konkrétní testovací plán, plán regresních testů či přímo vygenerovat hotové skripty pro automatizaci v Pythonu, Playwrightu či CyPressu. Navržené testovací skripty jsou po doplnění konkrétních přístupových cest a autorizaci plně funkční.</p><p>Obrovská přidaná hodnota umělé inteligence tkví v možnosti navázat na předchozí konverzaci a vhodnými dotazy dosáhnout ideálního řešení. AI dokáže dále nalézt limity a podmínky daného řešení, nalézt chybu v kódu nebo nabídnout různé varianty řešení problémů do přehledné tabulky, včetně poměrného zastoupení daného řešení ve světě.<br></p><h2>Umělá inteligence je dobrý sluha, ale zlý pán<br></h2><p>ChatGPT ukládá veškerá poskytnutá data a kombinací vhodných otázek je může v dobré víře poskytnout dalším uživatelům. Je proto nezbytné citlivé firemní údaje chránit a vůbec je ke zpracování AI neposkytnout. Moderní software využívající ChatGPT API dokáže ta­ko­vá­to škodlivá data ​identifikovat již na vstupu a včas je eliminovat. Posunuje tak hranici bezpečnosti práce s umělou inteligencí na vyšší – akceptovatelnou míru rizika. V ideálním případě je vhodné komuni­ka­ci a poskytnutá data umělé inteligenci ukládat k podrobnější ana­lý­ze. Výstupy z ChatGPT je vhodné ukládat také a sledovat vývoj poskytovaných výstupů v čase na úrovni jednotlivých uživatelů.​<br></p><p><br></p><p><em style="orphans:2;text-align:justify;widows:2;">David Víteček</em></p><p><em style="orphans:2;text-align:justify;widows:2;">Zdroj: SystemOnLine 11/2023​​</em>​<br><br></p>odborné;#
Měřitelnost přínosů implementace metodologie DevOpshttps://create-it.cz/Blog/Stranky/meritelnost-devops.aspxMěřitelnost přínosů implementace metodologie DevOps<p>​​V minulých dílech našeho seriálu o DevOps jsme se věnovali roli <a href="/Blog/Stranky/devops-digi-transformace.aspx" target="_blank">DevOps v digitální transformaci</a>: co si pod tímto pojmem představit, a jaké jsou klíčové body tohoto systému práce. Popsali jsme také <a href="/Blog/Stranky/zavedeni-devops.aspx" target="_blank">jak DevOps úspěšně zavést​</a> uvnitř technologické organizace a neselhat při tom. Nyní, ve třetím a závěrečném dílu, se budeme věnovat neméně důležitému tématu, a to odpovědi na otázku, které bude čelit každý zaměstnanec technologicky zodpovědný za vývoj a doručení aplikace. Ta otázka velmi zjednodušeně zní: „Kolik to bude stát, co z toho budeme mít a kdo to nakonec zaplatí?“ Ke každému hodnocenému aspektu uvedeme pro lepší představu i krátký příklad z praxe.<br></p><h2>1. Čas</h2><p>Nikde jinde, než právě při vývoji a doručování aplikací nehraje tato jednotka tak důležitou roli jako zde. Vývoj softwaru je velmi drahá záležitost, a předpokládané náklady lze poměrně jednoduše přenést na časovou osu. Přímá úměra je velice jednoduchá: Čím více času při vývoji softwaru strávíme, tím více peněz musíme vydat. Částečným řešením může být automatizace, ale pouze pokud je v týmu dostatek zkušených specialistů, kteří ji umí aplikovat.<br></p><p>Naprosto zásadní je mít správně nastavený rozpočet vůči velikosti týmu, který se bude v projektu angažovat. Projektové vedení, analytici, vývojáři a testeři dokážou doslova „konzumovat“ časové jednotky po celých týdnech a žádný rozpočet není bez nezbytného plánování ve skutečnosti tak velký, aby nedokázal nakonec velice rychle dojít.</p><p>K vývoji aplikací se nyní nejčastěji používá některý z agilních přístupů. Cílem DevOps je zajistit dostatečnou podporu agilním vývojovým týmům, přesto však není nezbytně nutné, aby byly jejich součástí. Bezpochyby nejrozšířenější agilní metodikou používanou na vývoj aplikací je Scrum.<br></p><p>V ideálním světě lze vytvořit backlog na konkrétní úkony, a dopředu si rezervovat čas DevOps specialisty. Tedy konkrétně a pouze jen jeho „Dev“ část, kterou lze plánovat. Bohužel v tom reálném musí DevOps, (tentokrát spíše ta „Ops“ část) reagovat ihned a nelze čekat na další sprint s opravou kritické části nasazení. Plánování se tím nutně stane složitějším.<br></p><p>Naší prioritou je eliminovat plýtvání, přinést dostatečnou kvalitu tam, kde je vyžadována a také budovat a zvyšovat celkovou zkušenost týmu. Právě proto je velmi často lépe aplikovatelná Lean Kanban metodologie.​​<br></p><h4>Příklad:​<br></h4><p>Před adopcí DevOps nebylo u našeho zákazníka možné paralelizovat sestavování aplikačního kódu. Sestavení monolitické aplikace trvalo přes 60 minut. Vývojáři nemohli vytvářet nové vývojové větve, a požadavek na vyřízení zabral i týden. Změnové požadavky na aplikaci byly plánovány měsíčně a release probíhal každý kvartál.<br></p><p>V případě operativních zásahů nefunkčnosti nasazení, bylo nutné kontaktovat externí tým, který sice reagoval následující den, ale problém vyřešil většinou až za několik dalších pracovního dní.<br></p><p>Díky metodologii DevOps bylo možné implementovat novou mikroservisní architekturu. Vývojáři si nyní mohou sami vytvářet vývojové větve. Jejich aplikační kód je testován v reálném čase ihned po odevzdání. Změnové požadavky jsou plánovány každé dva týdny a release je možné uskutečnit prakticky kdykoliv. Provozní chyby jsou eliminovány ten samý den, kdy jsou reportovány. Celkově potřebovala nová majoritní verze aplikace na cestě před zákazníka pouze 35 % času v porovnání s tou předchozí.<br></p><h2>2. Kvalita</h2><p>Jakákoliv další jednotka, kterou si stanovíme má víceméně opět dopad na čas, který je potřeba věnovat nápravě chyb, ať aplikačních, nebo UX. Kvalita je ale jedna z nejlépe hodnotitelných metrik, kterou můžeme sledovat. Zároveň se čísla velmi dobře sledují na grafech, které je nutné předložit jako důkaz správně provedené digitální transformace.<br></p><p>Každá společnost by měla udržovat seznam reportovaných chyb aplikace včetně jejich závažnosti s tím, že ty nejzávažnější bude opravovat jako první. Právě počty aktivních vs. vyřízených chyb v tomto seznamu se dají velmi dobře srovnat se stavem před zave­de­ním DevOps. Na reportování chyb lze použít kterýkoliv trackovací nástroj typu Jira, Trac, YouTrack nebo CI/CD platformy Azure Dev­Ops, Github, které také nabízí určité, byť drobně omezené, možnosti.<br></p><p>Kvalita se netýká pouze komplexního řešení hotového produktu, ale i jeho částí. Konkrétně služeb, ze kterých je postavena. Díky statické analýze můžeme měřit kvalitu kódu i bezpečnost. Mezi nejznámější nástroje patří SonarQube, který zvládne hravě obojí. Další služby jsou jFrom, Deepsource, Codacy, Qodana a mnoho dalších. Výstupem jsou grafy, které ukáží, jak dobře na tom daný produkt aktuálně je, včetně trendu, kterým se kvalita ubírá.<br></p><p>Standardně je možné tyto testy kvality a bezpečnosti implementovat jako jeden z podmíněných kroků při sestavování aplikačního kódu. Pokud odevzdávaný kód nesplní definovaná pravidla a limity, je automaticky zamítnut. Jinými slovy, není připuštěn k integraci a dalším testům, dokud ho vývojáři neopraví.<br></p><h4>Příklad:<br></h4><p>Díky DevOps, automatizaci a integraci statické analýzy ve vybrané společnosti vzrostla velmi zásadně kvalita produktu. Na základě nižšího počtu hlášených chyb došlo ke zlepšení kvality o více než 65 %. Většina chyb byla nalezena a včas odstraněna díky automatizovanému testování, definovaným pravidlům na kvalitu kódu i bezpečnostním testům.<br></p><h2>3. Flexibilita</h2><p>Jak lze měřit schopnost umět se přizpůsobit neustále se měnícím podmínkám na trhu a potřebám zákazníků? Zejména v dnešním dynamickém podnikatelském prostředí, kde flexibilita při vývoji softwaru velmi často znamená udržení konkurenceschopnosti, je tato schopnost zásadní? DevOps podporuje agilitu a umožňuje zapracování průběžné zpětné vazby zákazníků. Zrychlení iterace vývojových cyklů a časté nasazování aktualizací softwaru jsou jen některé ukazatele, které lze bez větších potíží zveřejnit.<br></p><h4>Příklad:<br></h4><p>Nové procesy umožnily rychlejší reagování na změnu trhu: změnové požadavky jsou zpracovávány podle reportu společnosti často až 18x rychleji. Toho bylo možné dosáhnout díky automatizaci někte­rých kroků při integraci, opět včetně testování. Odevzdaný kód je po splnění podmínek automatický začleněn do hlavní vývojové větve.<br></p><p>Takto velké zrychlení vývoje by nebylo myslitelné bez podpory paralelního vývoje a infrastrukturních závislostí. Díky dynamicky škálovatelnému prostředí je vždy dostatek výkonu pro vývoj a testy bez velkého dopadu na celkovou cenu. Když výkon není potřeba, jsou prostředky infrastruktury uvolněny na nezbytné minimum.<br></p><p>Flexibilitě napomáhá i moderní technologický stack a orchestrace aplikačních modulů. Pomocí dockerizace je velmi jednoduché izolovat jednotlivé verze aplikace, škálovat i doručovat a to bezvýpadkově. Kontejnerizace umožňuje i snadný „rollback“ (vrácení na předchozí verzi), pokud si to situace žádá. To, co dříve trvalo hodiny a dny, je možné aplikovat do několika málo vteřin.<br></p><h2>4. Náklady</h2><p>Téměř s jistotou nenarazíte na žádného vlastníka produktu, který by podepsal vývojovému týmu tzv. „blank cheque“. Stejně tak nevím ani o úspěšném projektu, kde byl termín dodání definován stylem „Až to bude, tak to bude“.<br></p><p>Náklady musí být známy a vyčísleny a vždy se musí hledat úspora tak, aby byl výsledný produkt ziskový. Jedním z mnoha řešení je automatizace procesů testování a doručení softwaru. Dalším řešením je dynamická infrastruktura typu „Pay as you go“, kdy jdou náklady pouze na infrastrukturu, která je aktivně používaná. Zároveň je vhodné zvolit architekturu, která umožňuje dynamické škálování infrastruktury.</p><p>Optimalizovat lze i ve vývojovém týmu, nebo požadovaných službách. Je vždy nutné mít interní vývojový tým, který (pokud chcete dostatečnou senioritu), je velmi drahý. Některé jeho části lze samozřejmě i outsourcovat.<br></p><h4>Příklad:<br></h4><p>Díky digitální transformaci společnosti a změny architektury bylo možné snížit náklady na infrastrukturu o 67 %! Snížily se také celkové náklady na vývoj a zrychlilo se celkové dodání. Úspory se dotkly také potřebných lidských zdrojů, opět díky automatizaci, není potřebný tak velký lidský výkon.<br></p><h2>Závěrem</h2><p>I když se může zdát, že je vše zalité sluncem na rozkvetlé zahradě plné růží, je nutné si uvědomit i rizika spojená s digitální transformací, o kterých jsme se bavili v předchozích dílech. Pokud je transformace prováděna neodborně, populární metodou „pokus-omyl“, může tento pokus vyjít velmi draho bez valného výsledku, nebo s výraznou ztrátou.<br></p><p>V případě, že je transformace naplánována dobře, je možné ji provést „bezvýpadkově“, kontinuálně a v přesně vymezeném časovém horizontu bez zásahu koncových klientů, a o ty jde dodavatelům softwaru samozřejmě především.</p><p>Díky měřitelnosti jednotlivých aspektů implementace DevOps procesů je jasně prokazatelné, jaký je přínos zavedením metodologie ve společnosti. Zároveň dokážou tyto metriky odhalit slabá místa, na která se lze více zaměřit při dalším rozvoji.​<br></p><p style="orphans:2;widows:2;text-decoration-style:initial;text-decoration-color:initial;"><em>Vojtěch Kijenský</em></p><p style="orphans:2;widows:2;text-decoration-style:initial;text-decoration-color:initial;"><em>Zdroj: SystemOnLine 08/2023​​</em></p>odborné;#
Informační architektura - struktura a organizace informací v digitálním světěhttps://create-it.cz/Blog/Stranky/informacni_architektura.aspxInformační architektura - struktura a organizace informací v digitálním světě<p> <em>​​​​​Trápíte se občas nad tím, že nedokážete na Internetu něco rychle najít? Ať už se jedná o zboží v e-shopu, tlačítko pro připojení přílohy ve Datové schránce nebo nákup lístku na online seminář. Na stránkách, kde hledáte dlouho nebo dokonce nenacházíte potřebné údaje, roste vaše nespokojenost a mění se ve frustraci. Na vině je většinou špatná informační architektura. Co je to informační architektura (IA) a proč je důležité její výstavbu nepodcenit? Jak ji navrhnout, aby uspokojila potřeby cílové skupiny? </em><br></p><p>Informační architektura se zabývá organizací, strukturou a navigací informací, aby byly snadno dostupné, srozumitelné a užitečné pro uživatele. Správné uspořádání informací je základním prvkem úspěšného fungování webových stránek, softwarových aplikací a dalších informačních systémů. </p><p>Jak tedy navrhnout IA, která má předpoklady být dobrým poskytovatelem informací? Při návrhu IA se prolínají tří základní perspektivy. Zohlednění všech dílčích oblastí je klíčem k návrhu kvalitní IA. A naopak, potlačení kterékoliv z nich negativně ovlivní výslednou kvalitu. <br></p><p> <img src="/Blog/PublishingImages/Stranky/informacni-architekura/architektura1.svg" data-themekey="#" alt="" style="width:100%;margin-top:20px;" />  </p><h2>Kontext</h2><p>Každé naše konání se děje s určitým účelem a v nějakém prostředí. Stejně tak i IA , systému, aplikace či ​webových stránek, vzniká v určitém kontextu. Před tvorbou IA tedy musím mít zřejmou odpověď na otázku jaký je účel IA s ohledem na obchodní cíle. Co mi přinese a proč ji potřebuji? Další rovinu kontextu představuje umístění IA v interakci s okolním světem. Jak k ní budou přistupovat uživatelé? Kontext můžeme vnímat zjednodušeně vnímat jako odpověď na otázku „proč a kde“ bude vznikat IA.​<br></p><h2>Uživatel</h2><p>Obchodní cíle jsou realizovány interakcí s okolím – s uživateli. Tato oblast představuje druhou perspektivu. Kdo jsou cíloví uživatelé? Jaké jsou jejich potřeby a hlavní motivace? To jsou základní otázky, jejichž odpovědi musíme umět zformulovat. V této rovině pracujeme se skupinami uživatelů a hlavně jejich mentálními modely.​<br></p><h2>Obsah</h2><p>Poslední perspektivu představuje obsah, tedy všechna data, která pomocí IA organizujeme. Obsah je silně ovlivněn uživatelem. Musíme znát odpovědět na otázku, jaký obsah je pro uživatele relevantní? Kolik informací jsou uživatelé schopni zpracovat najednou? Správná IA má poskytovat přiměřené množství informací, které uspokojí co největší procento cílové skupiny. Myslet si, že čím více informací poskytneme, tím větší skupinu příjemců obsloužíme, není většinou pravda. Zároveň musí být správně navržená IA flexibilní a škálovatelná. Žijeme v dynamické době a je třeba mít na paměti budoucí vývoj a s ním předpokládané změny. </p><h2>Tvorba IA jako proces</h2><p>Mít na paměti všechny tři perspektivy nemusí být vždy jednoduché. Tady je stručná kuchařka, kterou můžete použít, abyste při tvorbě IA na nic nezapomněli.</p><p>1. <strong>Poznejte kontext.</strong> Důvody a cíle IA je potřeba mít pořád na paměti. Porozumění zadání, motivace a celkového kontextu je první důležitý krok. Pokud zadání nemáte jasně definované, shrňte jej stručně sami a nechejte si ho odsouhlasit vlastníky projektu. K popsaným cílům je nutné se v procesu navrhování IA vracet. Jen tak máte jistotu, že se neodchýlíte od požadovaného stavu a splníte zadání. </p><p>2. <strong>Definujte cílové skupiny uživatelů.</strong> Jaké jsou potřeby a motivace? V jakém kontextu uživatelé hledají informace? Existují 4 obecné důvody návštěvy: </p><blockquote style="margin:0px 0px 0px 40px;border:medium;padding:0px;"><p>• Uživatel ví, co hledá. Dokáže popsat cíl svého vyhledávání a má určitou představu, jak jej najít. Cesta k cíli by měla být rychlá a jednoduchá.</p><p>• Uživatel ví přesně, co hledá, ale nemůže si vzpomenout na název, detaily. Dokáže si ovšem vzpomenout, kde zhruba informaci našel.</p><p>• Uživatel má matnou představu, co potřebuje vědět. Někdy to dokáže vyjádřit, jindy ne.</p><p>• Uživatel neví přesně, co hledá. Nehledá nic specifického, má jen obecný cíl.      </p></blockquote><p>Ideální IA dokáže pokrýt všechny důvody. Nezapomeňte ale na to, že všem nikdy nevyhovíte. Přestože jsou určité vzorce chování, i tady platí „sto lidí, sto názorů“. Důležité by mělo být rychle a kvalitně obsloužit skupinu, která nám pomůže dosáhnout obchodních cílů. Ta nemusí být nutně tou nejrozsáhlejší.</p><p>3. <strong>Seznamte se s obsahem.</strong> Počítejte s tím, že tato fáze vám může zabrat hodně času. Ať už je to kvůli rozsahu nebo neznalosti zpracovávaného tématu. V této fázi je žádoucí posuzovat obsah s ohledem na definované cílové skupiny a jejich potřeby. Pokud děláte revizi IA, je dobré se ptát – uspokojí tato informace potřeby primární cílové skupiny? Pokud ne, pryč s ní. Hygiena obsahu je většinou pracná a bolestivá, protože autor zpravidla nerad vyhazuje něco, co vytvořil a dal si s tím práci. Je na vás jej dobrými argumenty dovést k názoru, že tohle je správná cesta. </p><p>4. <strong>Udělejte rešerši. </strong>Je vysoce pravděpodobné, že v digitálním světě existuje stejné nebo velmi obdobné řešení tomu, kterého chcete namodelovat. Zjistit, jak fungují podobná řešení vám pomůže lépe předvídat uživatelské znalosti a zkušenosti dané oblasti, které se budou snažit podvědomě aplikovat při používání vašeho řešení. Hovoříme o poznání tzv. uživatelského mentálního modelu.</p><p>Nejjednodušší srozumitelná definice <a href="https://www.nngroup.com/articles/mental-models" target="_blank">mentálního modelu</a> je podle Nielsen Norman Group „Mentální model je to, co si uživatel myslí o daném systému." Jinými slovy, mentální modely jsou předpoklady založené na dosavadních zkušenostech poznávání reálného světa, které lidé nosí v hlavě před interakcí s webovou stránkou nebo aplikací. Všichni podvědomě tušíme, že kontaktní informace nalezneme v sekci O nás nebo Kontakt a nebudeme očekávat její umístění mezi deskriptivními informacemi produktu nebo uprostřed novinového článku. Tuto myšlenku zformuloval do jednoho ze základních UX zákonů průkopník této oblasti <a href="https://www.nngroup.com/people/jakob-nielsen/" target="_blank">Jakob Nielsen.</a></p>​<hr /> ​ <h2>Jakobův zákon (Jakob’s law)</h2><p> <i> Jakobův zákon o uživatelském zážitku na internetu říká, že uživatelé tráví většinu času na jiných webových stránkách než na vašich. To znamená, že uživatelé dávají přednost tomu, aby váš web fungoval stejně jako všechny ostatní weby, které již znají.</i>​​<br></p>​<br><hr /><br> <div><p>Nepodcenit rešerši a inspirovat se podobnými řešeními je zpravidla lepší než přehnaná kreativita a snaha o originalitu. Lidé nechtějí přemýšlet a rozhodovat se více, než je nutné.</p><p>5. <strong>Roztřiďte obsah.</strong> V tomto kroku musíte vymyslet koncept taxonomie a struktury. Taxonomie je systém kategorizace a klasifikace informací, struktura je o definování vzájemných vztahů mezi jednotlivými částmi systému. Klíčové je mít koncept. Např. webové stránky nabízející robustní softwarové řešení mají několik možností, jaké pojetí pro uspořádání obsahu zvolit. Jako uživatele vás může v první řadě zajímat, jaké má produkt funkce. Nebo hledáte informace o produktu podle odvětví, tedy hledáte identifikaci s cílovou skupinou. Anebo si říkáte, proč zrovna tenhle produkt, jaké má benefity, přednosti atd. Svět je pestrobarevný a komplexní, neexistuje jen jeden správný koncept. Vracejte se k rešerši a inspirujte se jimi.</p><p>Jakmile se rozhodnete pro jednu hlavní myšlenku, můžete definovat primární úrovně hierarchie informací, tj. hlavní kategorie, do kterých budete třídit obsah. Pro tento krok můžete použít metodu Třídění karet (card sorting). Jednotlivá témata rozřazujete do hlavních kategorií nebo jejich podskupin, které vám intuitivně dávají smysl. Nesnažte se vytvářet zbytečně mnoho kategorií a úrovní. Čím méně, tím lépe. Při třídění obsahu využijte aplikací, které vám umožní vytvořit snadno myšlenkovou mapu nebo jinak vizualizujete uspořádání obsahu. Programů pro bezplatné použití je dneska celá řada; Figma, Miro, Lucidspark, MindMaster aj.</p><p>Jakmile máte vytvořenou hierarchii, udělejte si průběžný test. Využít můžete tzv. Stromové testování (tree testing). Je to v podstatě inverzní metoda ke třídění karet. Snažíte se nalézt konkrétní informaci v dané struktuře. Cílem tohoto testování je odpověď na otázku „Najdou uživatelé to, co hledají?“</p><p>V tomto kroku pamatujte také na to, že je nutné držet konzistentní jazyk – tón, jazykový rytmus, jednotné názvosloví a soudržnost informací. To všechno silně ovlivňuje uživatelský prožitek. Pojmenovávejte kategorie jasně, srozumitelně a jednoduše.</p><p>6. <strong>Navrhněte wireframe.</strong> Wireframe je grafické zobrazení upořádání klíčových prvků navigace jako jsou menu, drobečková navigace, odkazy, vyhledávání a další prvky sloužící k procházení obsahu. Tvorba wireframů je o logice fungování systému/stránek. Díky nim získáváte vizualizovaný pohled na rozložení prvků usnadňujících orientaci a hledání informací. Navíc vám jejich vytvoření dovolí simulovat další uživatelské testování; identifikovat potenciální problémy a řešit úpravy dříve, než se bude řešit grafický design nebo bude systém v provozu. V neposlední řadě je potřeba myslet i na to, na jakých zařízeních bude naše řešení realizováno a v případě nutnosti navrhnout wireframe pro všechna požadovaná zařízení (desktop, mobil, tablet). Výsledkem tohoto kroku by měla být jednoduchá, konzistentní a intuitivní navigace napříč všemi kontexty použití.</p><p>7. <strong>Aplikujte design.</strong> Sebelépe navržená IA neobstojí, pokud její obsah není dobře prezentován. Cílem této fáze je vytvořit esteticky příjemné a konzistentní uživatelské rozhraní, které umocní pozitivní uživatelský prožitek. K tomu slouží designový jazyk. Jedná se o soubor pravidel, vzorů a prvků vizuálního designu, ke kterým patří barevná paleta, typografie, ikony, vzory, mřížka atd.  Správné použití designu může uživateli pomoci rychle identifikovat důležité informace, usnadnit orientaci na stránce anebo podpořit sdělení, která jsou ze strategického hlediska vhodné uživateli komunikovat. </p><p>8. <strong>Sestavte prototyp.</strong> Když máte jasno o tom, jak budou informace uspořádány, máte rozmyšlenou navigaci a navrhnutý design, je čas vytvořit prototyp, který simuluje vzhled a chování budoucího produktu. Propojením několika navrhovaných obrazovek vytvoříte maketu řešení, které prezentujete zadavateli a zároveň skvělý nástroj pro otestování budoucího produktu. Rozsah prototypu se odvíjí od očekávání a potřeb zainteresovaných stran. Může sloužit pro potřeby testování IA i jako zadání pro vývojáře. Záleží tedy na okolnostech, jak moc velkou část aplikace budete prototypovat. Pro otestování navigace a jednoduchost pohybu v aplikace zpravidla stačí jen malá část. </p><p>9. <strong>Testujte.</strong> Existuje celá řada technik a postupů, jak testovat informační architekturu. Je potřeba otestovat navigaci, zkontrolovat jednotnost použité taxonomie, konzistentnost designového jazyka, interakci systému, responzivitu řešení atd. Testování použitelnosti (usability testing) je objemná kapitola z oblasti Testování.</p><p>To nejjednodušší testování, které byste ale měli v této fázi sami realizovat, vychází z uživatelských potřeb. Definujte tři základní scénáře použití, které uživatel v aplikaci bude provádět, a ty, které z obchodního hlediska považujete za klíčové. Jak rychle dokážete uspokojit tyto potřeby? Je navigace dostatečně intuitivní? Jsou informace vizuálně dobře rozpoznatelné? Nezapomeňte, že u vás hrozí provozní slepota. Jakožto tvůrci IA víte, kam jste co zařadili. Požádejte kohokoliv blízkého, aby vám věnoval deset minut. Nechejte jej splnit dané úkoly a vy jen přihlížejte. Toto testování nepotřebuje velký rozpočet a výsledky zjištění mohou mít velký dopad na finální řešení.</p><h2>Závěr</h2><p>Níže nakreslené schéma shrnuje základní kroky, které směřují k cíli. V popsaném procesu je cílem funkční prototyp, který splňuje zadání. Někdy proces končí roztříděním obsahu, protože zadáním je dodat jen strukturu IA bez navigace. V tomto případě přeskočíte kroky návrh wireframe, design a prototypování, ale rozhodně nevynechejte fázi testování. </p><div><p> <br> </p><p></p><center><img src="/Blog/PublishingImages/Stranky/informacni-architekura/architektura2.svg" data-themekey="#" alt="" style="width:80%;margin-top:20px;" /></center> <p></p><p> <br> </p><p>Schéma ukazuje, že pokud zapojíte do tvorby IA i fázi testování, budete některé kroky opakovat a ladit. Dokud výsledek neprojde uspokojivě základním testováním, nepředkládejte jej klientovi, ani jej neposouvejte dále v rámci projektu do realizace. Když testování do tvorby IA nezapojíte, na chyby stejně přijdete. Jen to bude o něco později a s většími dopady; vyšší náklady, nespokojenost uživatelů, ztráta reputace atd. A hlavně, než posunete řešení dál, měli byste si být jistí, že znáte odpověď na otázku „Splnil jsem zadání definované na začátku tvorby IA?“</p><p>Závěrem si připomeňme, že ve všech krocích byste měli mít stále na paměti tři základní dimenze: kontext, uživatel, obsah. Využijte osvědčených standardů a buďte kreativní, ale konzistentní, v designovém jazyku.​</p><p>​<br></p><p> <span style="color:#000000;font-family:calibri, sans-serif;font-size:15.3333px;"> <em>Vendula Vytisková</em></span><em></em><br></p><p> ​<br> </p></div></div>odborné;#
Jak úspěšně zavést DevOpshttps://create-it.cz/Blog/Stranky/zavedeni-devops.aspxJak úspěšně zavést DevOps<p>​V předchozím článku <a href="/Blog/Stranky/devops-digi-transformace.aspx" target="_blank">„Role DevOps v digitální trans­for­ma­ci“​</a>, jsme se zabývali podstatou a výhodami přístupu DevOps. Jeho zavedení v organizaci pomáhá s urychlením i zvýšením efektivity procesu nasazení a celkovým vylep­še­ním spolehlivosti nasazení nových softwarových produktů pomocí agilního vývojového procesu. Dnes se podíváme na možná úskalí spojená se zavedením DevOps procesů do struktury organizace a jak těmto problémům čelit. Základním účelem přechodu k metodě DevOps je totiž dlouhodobé nastavení celého procesu tak, aby nevznikaly vícenáklady spojené s plánováním, organizací a realizací.​<br></p><h2>Strategický plán je klíčem</h2><p>Na počátku každé úspěšné změny stojí zejména kvalitní a promyšlený strategický plán. Je tedy potřeba si určit jeho podobu i obsah, stejně jako stanovit realizační tým. Strategický plán je pak úzce provázán s projektovým plánováním. Projektové plánování představuje jeden z klíčových kroků pro úspěšné zavedení DevOps do organizace.<br></p><p>Nejdříve je potřeba si definovat očekávaný výsledek. Pokud například chceme začít s menší mikroservisní aplikací, můžeme na první službě skvěle odladit celý proces od odevzdání kódu, přes automatické testy, nasazení až po monitorování životních funkcí a upozornění na případné chyby.<br></p><p>V okamžiku, kdy je celý proces detailně popsán, je důležité stanovit si časovou náročnost celé aktivity, termín odevzdání finální podoby i postup přidávání dalších aplikací. Takový způsob plánování pomáhá nacházet opakující se vzorce v nasazování i testování a umožňuje tak vytvářet určité šablony. Některé z těchto šablon je pak možné pomocí různých nástrojů použít opakovaně k automatizaci.​<br></p><h2>Kdo je kdo? Bez jasně definovaných rolí v týmu to nepůjde…</h2><p>Důležitou součástí plánu je také popis jednotlivých rolí v týmu. V každé implementaci takových procesů by se měl nacházet alespoň jeden člověk skutečně znalý dané aplikace, tedy zástupce vývojářů. Stejně tak by se měl účastnit jeho protějšek ze strany operativců, kteří udržují aplikaci při životě v produkčním prostředí, popřípadě se starají o její monitorování. V neposlední řadě by měl být součástí týmu i někdo, kdo je zodpovědný za infrastrukturu, aby celý proces probíhal bez problémů a neprodlužoval se čas doručení při čekání na různé technické účty a prostupy. Pro úspěšné fungování všeho výše popsaného je potřeba mít domluvenou i podporu u managementu organizace. Možná se tato poznámka může zdát jako nadbytečná, ale praxe opakovaně ukazuje opak. S postupy a fungováním DevOps týmu totiž musí být velice dobře seznámeno i vedení firmy a musí tomuto týmu poskytovat svou součinnost a podporu.​<br></p><h2>DevOps kultura krok za krokem</h2><p>Jak vlastně vzniká DevOps kultura v organizaci? Je potřeba ji prostě a jednoduše vytvořit na základě několika faktorů. Těmi jsou čas, typ projektu, velikost organizace, velikost týmu a samozřejmě i rozpočet. Zde se opět vracíme k důležitosti a roli managementu organizace a jeho úloze v zavádění kultury DevOps. V samotném úvodu snah o zavedení postupů DevOps je totiž nejdůležitější probrat s managementem, jaký přínos bude mít tato aktivita pro koncové uživatele, vývojové a podpůrné týmy, nebo pro firemní kulturu a v neposlední řadě pro výsledky celého týmu. Uspořádání technických i personálních záležitostí totiž pochopitelně následuje až s podporou managementu, který je přesvědčen, že dělá správnou věc. Zcela nezbytné je probrat také finanční a časové zázemí pro implementaci procesů, aby nově vzniklý DevOps tým měl opravdu prostor v klidu efektivně pracovat.<br></p><p>Před zapojením vzniklého týmu je samozřejmě potřeba zajistit důkladné školení na DevOps metodiku, nebo si najmout specialistu, který s takovou aktivitou může pomoci. Jedná se o komplexní proces a je možné, že na některé chyby při implementaci by se mohlo přijít zbytečně pozdě. Od nově vzniklého týmu se naopak očekává schopnost učit se novým věcem a nevracet se do starých zaběhnutých kolejí.​<br></p><h2>Komunikace jako základ úspěchu</h2><p>Ač se to může zdát jako banalita, je potřeba nepodceňovat kvalitní nástroje pro komunikaci. Nově vzniklý DevOps tým musí mít možnost efektivně komunikovat jak uvnitř, tak i s ostatními články celé organizace. Mezi efektivní nástroje rozhodně nepatří e-mail, který se používá spíše pro formální komunikaci. Naopak výborným nástrojem pro týmovou komunikaci jsou například Slack, MS Teams nebo Discord, které pak dokáže využít DevOps tým pro automatické sdílení chyb a komplikací v procesu s ostatními členy organizace. V poslední době je možné využít i implementované chatboty, které jsou schopny v rámci komunikačního nástroje zjistit stav, kde se jejich nasazení nachází, v jakém stavu jsou například backendy napříč testovacími prostředími a podobně.​<br></p><h2>Automatizace aneb „Samoseto“</h2><p>Matematika využívá symbol nekonečna ve spojení s nekončícími procesy a ani v DevOps není tento symbol náhodou, protože cokoliv se opakuje vícekrát než jednou, je potřeba zautomatizovat a tím dostat i mezi nekončící procesy. Kde všude se dá proces automatizace aplikovat? Začněme třeba od infrastruktury.<br></p><p>Pomocí Terraform šablon jsme schopni říci kolik a kde potřebujeme výpočetního výkonu, které všechny komponenty potřebujeme k chodu a podle jakých pravidel se má naše infrastruktura rozšířit nebo zmenšit. Celý tento proces se dá navíc také automatizovat. Operátor tak už nemusí používat příkazy, ale infrastruktura se po aplikaci změny v dokumentu upraví sama. Pro takové úpravy je možné využít nástroje jako GitLab nebo Azure DevOps. Možností je v současnosti samozřejmě ještě mnohem více.<br></p><p>Stejný postup lze využít na nasazení monitorovacích nástrojů, dokumentace nebo jakékoliv jiné komponenty z DevOps palety. Zní to velice jednoduše, má to ale i svá úskalí na která je potřeba si dát pozor. Veškerá automatizace vyžaduje údržbu, aby byla odolná pro všechny nadcházející aktualizace. Pro odolnou automatizaci je dobré opět využít šablony, a proto čím více podobné jsou si aplikace s programovacím jazykem, který byl použit, tím menší zdroje jsou potřeba na rozšiřování šablon, ale i na nutnou údržbu.​<br></p><h2>Dvakrát měř, jednou řež</h2><p>Bez dobře nastavených metrik jsme v podstatě „slepí“ a na základě domněnek je těžké cokoliv udržovat, sledovat případně vylepšovat. Pro takové aktivity existují komplexní nástroje jako je Datadog, Dynatrace nebo Splunk. Tyto nástroje dokážou s pomocí operátorů v infrastruktuře poměrně jednoduše načíst celou aplikaci, logy i její zázemí. Ovšem pouze pokud jsou do aplikace volně puštěny. V některých organizacích jako jsou třeba banky, to bohužel není možné, v jiných organizacích je to naopak žádané, protože přinášejí dokonalý přehled o všem, co se děje, na jednom místě.</p><p>Pokud neexistuje možnost využít tyto samostatné nástroje a je nutné nástroj více přizpůsobit potřebám organizace, nabízí se pak např. ELK stack i s možností připojení Grafany.​<br></p><h2>SRE</h2><p>Sebelepší nástroj však potřebuje zkušeného specialistu, který ho bude používat. V tomto případě se jedná o pozici zvanou SRE (Site Reliability Engineer). Tato role kombinuje prvky softwarového inženýrství a provozu IT infrastruktury. Člověk v této pozici je zodpovědný za zajištění spolehlivosti, škálovatelnosti a dostupnosti systémů a služeb pro uživatele.<br></p><p>Site Reliability Engineer se zaměřuje na řešení problémů spojených s výkonem, stabilitou a škálovatelností systémů. Jeho hlavním cílem je minimalizovat výpadky a zajistit, aby systémy byly vždy dostupné a efektivní. Součástí role je také řízení incidentů.​<br></p><h2>Závěrem</h2><p>Po přečtení těchto řádků si možná řeknete: „Dobře, tak teď půjdu, naplánuju si zavedení DevOps, domluvím se s vedením, vezmu Frantu z vývoje a Vaška z operations, napíšeme pár skriptů a pipeline, něco zmonitorujeme a máme to - jsme DevOps organizace!“<br></p><p>Bylo by to samozřejmě dobré zjištění, ale DevOps je velice komplexní proces, který přece jen nelze takto jednoduše obsáhnout. Aby bylo zavedení přístupu DevOps do organizace funkční, každá ze součástí nezávisle na velikosti organizace vyžaduje pečlivý a zodpovědný přístup, protože celý procesní řetěz je jen tak silný jako jeho nejslabší článek. Nicméně nezoufejte. Pokud máte vizi a dostatek odhodlání, půjde to!<br></p><p><em>Vojtěch Kijenský</em></p><p><em>Zdroj: SystemOnLine 07/2023​</em></p><p><br></p>odborné;#
Role DevOps v digitální transformacihttps://create-it.cz/Blog/Stranky/devops-digi-transformace.aspxRole DevOps v digitální transformaci<p>​​Tak jako ve většině technologic­kých odvětví se i ve vývoji soft­waru na zakázku stále zvyšuje tlak na jeho rychlost a flexibilitu. V tradičních přístupech, jako je například Waterfall, to však vět­šinou není možné. Technologické společnosti tak objevují nové agilní přístupy, které umožňují zrychlení vývoje a nasazování projektů. Jedním ze základních stavebních kamenů agilního přístupu k vývoji softwaru je využití metody DevOps. Ty umožňují společnostem velmi rychle reagovat na měnící se požadavky klientů v průběhu vývoje i provozu aplikací.<br></p><p>Průzkum z roku 2019 vytvořený společností <a href="https://www.puppet.com/resources/history-of-devops-reports" target="_blank">Puppet</a> ukázal, že použití metody DevOps umožnil technologickým společnostem zrychlení doručování změnových požadavků a vydávání nových verzí softwaru až o 63 %.<br></p><p>Klíčem ke zlepšení výkonnosti, kvality služeb a zároveň i zvýšení zisku je pro IT firmy pochopení a průchod tzv. digitální transformací. Jedině tak je možné udržet krok, přizpůsobovat se novým trendům a zůstat konkurenceschopným. Ne vždy se to však podaří.<br></p><p>I když podle průzkumu společnosti <a href="https://www.statista.com/statistics/870924/worldwide-digital-transformation-market-size/" target="_blank">Statista</a> se očekává, že do roku 2024 bude na digitální transformaci vynaloženo neuvěřitelných 2.4 miliard USD, jen 30 % z těchto implementací je nakonec úspěšných. V čem dělá tolik firem chybu? Velmi často je to podceněním samotné transformace, neznalostí všech důležitých rolí a chybějící kvalifiko­va­né autority, které jsou v této cestě digitální transformace nezbytné.<br></p><p>V tomto článku bychom se rádi věnovali základním aspektům digitální transformace z pohledu metody DevOps, které přímo stojí a jsou zodpovědné za oblasti jako je automatizace, zvyšování kvality a bezpečnosti softwaru a v neposlední řadě snižování nákladů.<br></p><h2>Co je vlastně DevOps?<br></h2><p>DevOps bývá často označením pro pracovní pozici, nebo proces nasazení. Pravdou je, že je to celý soubor pravidel, metod, postupů a technologií určených k urychlení a optimalizaci vývoje softwaru. Často využívá automatizaci, cloudové služby, virtualizaci a kontejnerizaci k dosažení rychlého, spolehlivého a předvídatelného nasazení nových verzí softwarových produktů pomocí agilního vývojového procesu.<br></p><p>Samotný název DevOps vznikl spojením dvou anglických slov „Development“ a „Operations“, tedy vývoj a nasazení softwaru. O ty se v tradičním vývojovém procesu starají různé týmy. V procesu DevOps jsou tyto úkoly spojeny do jednoho celku a vykonává je tak stejný tým. DevOps zavádí a popisuje důležité automatizace, které při tvorbě projektu ve starších přístupech zabíraly příliš mnoho času. Mezi tyto automatizace patří integrace projektu (continuous integration) a nasazení projektu (continuous delivery). To umožňuje po každém vývojovém cyklu automaticky sestavit projekt a otesto­vat tak, zda je práce jednotlivých vývojářů funkční ve společném celku, a to bez zásahu člověka. Nasazování nových verzí projektu je obvykle velmi zdlouhavá činnost. Při použití tohoto přístupu však tato potřeba odpadá a nasazení provádí automaticky počítač.​<br></p><h2>Co je digitální transformace?</h2><p>Digitální transformace je komplexní a rozsáhlý proces, při kterém se buď digitálně upravují stávající podnikové procesy, nebo se dokonce vytvářejí nové, aby efektivně vyhovovaly měnícím se požadavkům podnikání a trhu. Digitální transformace tedy vyžaduje výrazné přepracování procesů tak, aby se staly digitálními, a přepracování zákaznické zkušenosti tak, aby odpovídala digitálnímu prostředí. Jinými slovy, digitální transformace využívá digitální technologie a data k vytváření zisku, efektivizaci podnikání, nahrazení nebo transformaci podnikových procesů, kompetencí, modelů řízení a výroby (nikoliv pouze k jejich digitalizaci) a k vytvoření prostředí pro digitální obchod a spolupráci.<br></p><p>Digitální transformaci v podnikání je třeba chápat jako nikdy nekončící proces. Na této cestě budou podniky vždy muset reagovat na změny v prostředí, přehodnocovat svůj status quo a měnit své transformační aktivity.​<br></p><h2>Jak DevOps zapadá do digitální transformace?</h2><p>Vybudování kultury DevOps ve firmě není jednorázová záležitost. Jedná se o trvalý a nikdy nekončící proces. Nejde jen o sérii technologických kroků, které musí organizace, týmy a samotní programátoři splnit, ale jde o změnu organizace projektu a především o změnu myšlení zaměstnanců a vedení.<br></p><p>V tradičním procesu vydávání softwaru jeden tým (vývojový) píše, testuje a sestavuje kód izolovaně. Poté ho předá druhému (provoznímu) k nasazení a vydání. Tento proces však může vést k pomalejšímu vydávání a tím i ke zhoršení zákaznické zkušenosti. DevOps zásadně omezuje právě problémy spojené s tradičním procesem vydávání softwaru. Technologické firmy tak mohou vydávat produkty v řádu hodin nebo dnů místo týdnů nebo měsíců.<br></p><p>Digitální transformace zlepšuje podnikové procesy prostřednictvím technologických vylepšení. Vytváří také nové a vylepšené procesy, které jsou řízeny technologiemi. DevOps propojuje procesy vývoje softwaru a provozní procesy. Díky této synergii může DevOps pomoci organizaci na její cestě k digitální transformaci. Níže se podíváme na čtyři klíčové body, jak jsou procesy DevOps užitečné při digitální transformaci.​<br></p><h2>1. Automatizace</h2><p>Automatizace je důležitým aspektem digitální transformace, protože pomáhá zrychlit procesy, omezit manuální činnosti, odhalovat chyby a zvýšit efektivitu. Díky DevOps mohou organizace automatizovat různé fáze vývoje a dodávání softwaru, včetně sestavování a nasazování, testování a správy infrastruktury. Automatizace minimalizuje čas potřebný k vývoji, testování a vydání softwaru, což vede k rychlejšímu uvedení na trh a častějšímu vydávání nových verzí. DevOps navíc umožňuje automatizovat monitorování a údržbu aplikací a infrastruktury. To pomáhá organizacím rychle identifikovat a řešit problémy a zajistit vysokou dostupnost aplikací.<br></p><p>DevOps navíc umožňuje automatizovat kontrolu bezpečnostních hrozeb, čímž snižuje riziko narušení bezpečnosti a zajišťuje, že aplikace splňují regulatorní požadavky. To pomáhá organizacím splnit požadavky neustále se měnícího podnikatelského prostředí a udržet si náskok před konkurencí.​<br></p><h2>2. Snížení nákladů</h2><p>Kontrola nákladů je klíčovou součástí každé organizace. V digitální éře je však obzvláště důležitá, protože při práci s novými technologiemi a různorodými týmy je snadné ztratit přehled o výdajích. Pokud se vyskytnou problémy s některou částí systému, budete o nich okamžitě vědět, takže je můžete rychle odstranit a zabránit dalším škodám.<br></p><p>DevOps šetří organizacím náklady omezením manuálních procesů, zvýšením efektivity a optimalizací využívání zdrojů. Zefektivněním procesů vývoje, testování a nasazení snižuje DevOps riziko chyb, přepracování a výpadků.​<br></p><h2>3. Zvyšování kvality softwaru</h2><p>V prostředí DevOps vývojové a provozní týmy úzce spolupracují, což vede k celkově efektivnější komunikaci. Výsledkem je efektivnější proces vývoje softwaru, který snižuje riziko chyb a zajišťuje, že aplikace splňují požadované standardy kvality. V rámci DevOps jsou zavedeny postupy průběžného testování, integrace a dodávání (CI/CD), které zajišťují důkladné otestování a ověření aplikací před jejich vydáním. Je tak možné zachytit a vyřešit problémy v rané fázi vývoje, snižovat riziko chyb a zajistit vysokou kvalitu aplikací.<br></p><p>DevOps také pomáhá zavést mechanismy průběžného monitorování a zpětné vazby, které poskytují přehled o výkonu aplikací a infrastruk­tu­ry v reálném čase. Organizace tak mohou rychle identifikovat a řešit problémy, zlepšovat kvalitu aplikací a zvyšovat uživatelskou zkušenost. DevOps navíc podporuje používání nástrojů pro automatizaci a orchestraci, které vývojářským firmám pomáhají standardizovat a zefektivnit proces nasazení. Výsledkem je méně manuálních chyb a kratší doba nasazení aplikací, což vede i ke zlepšení kontroly kvality.<br></p><h2>4. Využití nových technologií​<br></h2><p>Ještě před několika lety byly mnohé technologické společnosti v oblasti IT a softwaru spíše konzervativní a jakékoliv změna nebo adopce nových technologií byla velmi náročná, v posledních pěti letech dochází k přesnému opaku. Oblast IT zažívá revoluci směrem do cloudových služeb, která těmto společnostem umožňuje využít služby PaaS a SaaS a která byla do této doby mimo jejich finanční a časové možnosti.<br></p><p>Za zmínku stojí přes 250 spravovaných služeb (managed services) v AWS, Azure, nebo GCP dostupných během pár minut na „jedno kliknutí“. Na vzestupu je i strojové učení, kde jsou k dispozici neuronové sítě, speciálně upravené pracovní stanice nebo přizpůsobená datová skladiště.<br></p><p>Většina aplikací nově nekončí na serveru jako proces, ale izolovaně v kontejnerech orchestrovaných v Kubernetes/Openshiftu, a stále častěji, pokud to má aplikační smysl, i serverless (AWS Lambda/Azure Functions/Google Cloud Functions).<br></p><p>Při vytváření nových aplikačních a infrastrukturních návrhů je autor prakticky limitovaný jen znalostí a možností těchto poskytovatelů a vlastní fantazií. (Kterou krotí snad jen hranice definovaného rozpočtu a korporátních pravidel.)<br></p><p>Poměrně nová a čím dál rozšířenější technologie používaná v DevOps je možnost deklarativního přístupu k doručení software, kdy se již nestaráme o to, jak doručit, ale popisujeme pouze, jak to má v pro­stře­dí vypadat. Specializovaný software pak zajistí, že se při jakéko­liv, i nechtěné, změně prostředí samo opraví do funkčního stavu.​<br></p><p>Během doručování softwaru, ale i při jeho běhu v prostředí máme k dispozici pokročilé nástroje diagnostiky a detekce chyb, které jsou také již napojené na strojové učení a umožňují nejen odchytit, ale i predikovat potenciální hrozby. Na základě znalosti běhu aplikací jsou detekovány a reportovány anomálie i nestandardní chování uživatelů, což vede ke zvýšení bezpečnosti. V neposlední řadě lze tyto technologie využít i k automatizovanému vytvoření dokumentace prostředí.</p><h2>Závěr<br></h2><p>Digitální transformace je kompletní přeměna podnikání, která vyžaduje více než jen aktualizaci IT systému nebo vytvoření několika aplikací. V rychlém světě, ve kterém se dnes nacházíme, potřebují organizace prostě rychle a efektivně inovovat. Aby této změny bylo dosahováno, je třeba změnit představu o fungování firmy jako takové. Nejlepším způsobem, jak zahájit digitální transformaci společnosti, je iniciovat kulturu DevOps. Úspěšná digitální transformace zahrnuje změnu systému práce, která následně povede ke zvýšení efektivity a úspoře času i financí.​<br></p><p><em>Vojtěch Kijenský</em></p><p><em>Zdroj: SystemOnLine 06/2023</em></p><p><em><br></em></p>odborné;#
Testing Clever Akademiehttps://create-it.cz/Blog/Stranky/testing-akademie.aspxTesting Clever Akademie<p style="display:none;">​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​Vstup s námi do světa IT a pojď se naučit testovat software!​ Naši průvodci tě provedou cestami a stezkami až na tvou pomyslnou K2 – získáš svou příležitost v jiném oboru, ve kterém zúročíš své analytické a kritické myšlení.<br></p> ​<div class="ms-rtestate-read ms-rte-wpbox"><div class="ms-rtestate-notify ms-rtestate-read 7011e392-79f3-4920-88bc-448b0e5808ac" id="div_7011e392-79f3-4920-88bc-448b0e5808ac" unselectable="on"></div><div id="vid_7011e392-79f3-4920-88bc-448b0e5808ac" unselectable="on" style="display:none;"></div></div><p>​​<br><br></p>vzdělávání;#
Monitorování podnikových procesů pomocí chytrých hodinek?https://create-it.cz/Blog/Stranky/monitorovani-podnikovych-procesu.aspxMonitorování podnikových procesů pomocí chytrých hodinek?<p>​​​​​Podle <em>Minnesota Reformer</em> investovaly dvě velké americké společnosti z oblasti zpracování masa, Tyson Foods a JBS, do aplikace pro chytré hodinky, která jim v reálném čase umožňuje monitorovat průběh procesů ve výrobě. <br></p><p>Tato technologie má za cíl nejen zvýšit produktivitu firmy, ale také bezpečnost zaměstnanců. V masném průmyslu jsou velmi vysoká rizika úrazů. Opakující se, rychlá a namáhavá práce činí z masokombinátů jedny z nejnebezpečnějších pracovišť. Americké ministerstvo práce v posledních letech provádělo opakovaná vyšetřování bezpečnostních incidentů v tomto odvětví. <br></p><p>Aplikace je kompatibilní s hodinkami Samsung Watch 4, které během pracovní směny nepřetržitě sbírají data z výrobního procesu pomocí svých senzorů – konkrétně sílu, rotaci, rychlost a směr pohybu ruky pracovníka. Tato data jsou poté interpretována softwarem s prvky umělé inteligence, která určuje, zda jsou pohyby bezpečné, a upozorní pracovníky, pokud překračují bezpečnostní limity v síle nebo rychlosti. Získaná data převádí na metriky zobrazované na „dashboardu.“ Ten obsahuje nejen bezpečnostní metriky, ale také aktivní skóre produktivity.​<br></p><h2>Jaké výhody z toho pro firmu plynou?</h2><p>Používání chytrých hodinek jako nástroje pro monitorování procesů ve výrobě může přinést firmám množství výhod.</p><p>Klíčovou z nich je <strong>zvýšení produktivity výroby</strong>. Díky sledování pohybu a výkonu prováděných aktivit je možné identifikovat méně produktivní pracovní postupy a navrhnout opatření pro zvýšení výkonu jednotlivých aktivit. </p><p>Další výhodou používání chytrých hodinek je <strong>zvýšení bezpečnosti zaměstnanců</strong>. Senzory chytrých hodinek mohou predikovat potenciální bezpečnostní rizika na pracovišti. Hodinky jsou vybaveny technologií RTLS (real-time location system), takže si v případě potřeby může pracovník snadno přivolat asistenci či pomoc.</p><p>Software také může z dat o aktuálním průběhu jednotlivých aktivit ve výrobním procesu, poskytovat pracovníkům okamžitou zpětnou vazbu, díky které si mohou výrazně usnadnit <strong>práci </strong>nebo <strong>zlepšit</strong> svůj <strong>výkon</strong>.</p><p>Používání chytrých hodinek v průběhu aktivity umožňuje také snadno sbírat anonymní data o pohybu po areálu firmy, která mohou být dále analyzována a použita pro <strong>optimalizaci pracovních postupů a využití zdrojů</strong>. Tyto informace firmám přináší <strong>snížení nákladů a zvýšení ziskovosti</strong>, pracovníkům pak další <strong>usnadnění</strong> jejich <strong>práce</strong>. Optimalizace pracovních postupů z hlediska jejich ergonomie navíc pomáhá <strong>předcházet </strong> <strong>dlouhodobým zdravotním potížím</strong>.</p><p>V neposlední řadě mohou chytré hodinky také pomoci zaměstnavatelům <strong>zlepšit komunikaci se zaměstnanci</strong>. Díky technologii HMI (Human Machine Interface) mohou zaměstnanci lépe interagovat s různými systémy a stroji v reálném čase a snadno se přizpůsobit různým pracovním úkolům. </p><p>Celkově může využití chytrých hodinek pomoci společnostem optimalizovat pracovní postupy, snížit prostoje, a tím zvýšit produktivitu výrobního procesu a bezpečnost pracovníků. Z marketingového hlediska to může být silný prodejní argument pro společnosti, které se snaží zlepšit své hospodářské výsledky a odlišit se na přeplněném trhu. A zpětná vazba ze strany odborů ukázala (přes počáteční obavy), že pracovníci vnímají tuto inovaci jako skutečný přínos pro svou práci.</p><h2>Ochrana soukromí pracovníků</h2><p>Obavy zaměstnanců ohledně soukromí jsou důležitou věcí, která musí být zohledněna při zavedení jakéhokoli nového monitorovacího systému v pracovním prostředí. Realizací podobných řešení využívajících chytré hodinky se v Cleverlance také zabýváme. Zeptali jsme se proto <strong>Mikuláše Müllera</strong>, který vede jednotku <a href="https://www.cleverlance.com/cz/CleverIndustry/">CleverIndustry</a>, dodávající systémy pro digitalizaci průmyslu a logistiky, jak tento problém řešíme v Cleverlance:<br></p><p> <em>„V případě aplikace pro chytré hodinky, která monitoruje aktivity ve výrobním procesu, je důležité zdůraznit, že respektujeme GDPR a zajišťujeme bezpečné zpracování osobních údajů. Všechna data jsou šifrována a uchovávána na zabezpečených serverech, kde jsou přístupné pouze autorizovaným osobám.</em></p><p> <em>Každý zaměstnanec používá pokaždé jiné hodinky. Před každou směnou si je náhodně a anonymně vybere „z police,“ takže nelze přesně určit, jaký konkrétní zaměstnanec se nachází nebo nacházel na kterém místě v určitý okamžik. To by mělo zaměstnancům dodat pocit bezpečí a zaručuje jim to, že jejich soukromí není ohroženo.</em></p><p> <em>Je také důležité vysvětlit zaměstnancům všechny aspekty fungování tohoto systému, a přesvědčit je o tom, že jim chytré hodinky pomohou usnadnit jejich práci a neohrozí jejich práva a soukromí“</em> zdůrazňuje Mikuláš Müller.​</p><p> <em style="text-align:justify;orphans:2;widows:2;text-decoration-style:initial;text-decoration-color:initial;">K​ateryna Sakovska​</em><span style="text-align:justify;">​</span>​<br></p><p>​<br></p>odborné;#
Jak od klienta získat informace, ty správné https://create-it.cz/Blog/Stranky/jak-ziskat-informace.aspxJak od klienta získat informace, ty správné <p>​​​Součástí každého projektu je fáze, kdy je potřebné získat vstupní informace od klienta. Zpravidla analytik obdrží na začátku projektu či změnového požadavku nějaké zadání, které je více, či méně detailní. Zadáním může být pouze vize klienta, nebo také přehledný seznam požadavků. Ať je vstupem to, či ono, je nutné si s klientem zadání projít a doplnit jej, případně zkorigovat nepřesnosti. Proč? Důvodů je více, například od zpracování zadání mohla uplynout delší doba a na straně klienta tak mohlo dojít ke změnám. Analytický pohled na zadání může také odhalit tzv. slepá místa, případně požadavky, které mohou být vzájemně v rozporu. Tím hlavním důvodem ale je, že je <strong>nutné, aby analytik pochopil cíle a motivace klienta.</strong> Musí mu být jasné co a proč chce klient dosáhnout, tj. de facto zjistit jeho reálné potřeby. Ty následně analytik převede do finálních požadavků a zapracuje v návrhu řešení.<br></p><p>Jak ale získat správné informace? <strong>V první řadě je potřeba si uvědomit, že klient je odborníkem na svůj business, ale nemusí být odborníkem na IT oblast.</strong> Při diskusi s ním se tedy vyhněte IT slovníku typu – objekty, API nebo procedura, a to minimálně do doby, než si ověříte, že klient tyto pojmy zná a opravdu jim rozumí. </p><p>Dále je důležité si uvědomit, že <strong>každý člověk má ve své práci jistou dávku rutiny, aktivit, které vykonává zcela automaticky.</strong> Pokud klienta požádáte, ať vám popíše svou činnost, může proto některé kroky vynechat, aniž by si to uvědomil. Abyste získali kompletní informace k procesu, můžete použít tzv. hraní rolí. Vžijete se do role zákazníka, který požaduje danou službu a budete se doptávat na vše, co vás zajímá, tzn. povedete rozhovor, který by reálně vedl k získání nové služby. Čím více a detailních dotazů položíte, tím lépe, neboť klienta dostanete myšlenkově do procesu, kdy Vám bude muset krok za krokem popsat aktivity na straně zákazníka, ale také aktivity, které realizuje on sám. Nezapomeňte si v diskusi vymýšlet různé hraniční situace, protože je také důležité zjistit a popsat nestandardní situace, které mohou nastat. V každém procesu se skrývá více či méně výjimek, které je nutné zmapovat. Následně, dle jejich četnosti, se rozhodne, které z nich bude systémové řešení pokrývat. </p><p><strong>V průběhu diskuse zkoušejte různé varianty práce s klientem.</strong> Někteří z nich jsou čtenáři a potřebují si informace přečíst, někteří jsou vizuálně zaměření a lépe se orientují ve schématech, někteří potřebují vidět obrazovky, aby si představili, co se děje nebo má dít. Pokud si v úvodních schůzkách otipujete klienta, budete vědět, který způsob práce mu vyhovuje. </p><p><strong>Je také nesmírně důležité dotazy správně formulovat.</strong> Pomáhejte klientovi položením komplexnějších dotazů. Například, když budete řešit vytvoření smluvního formuláře, neptejte se pouze stylem „Co se má stát po uložení smlouvy?“, ale uveďte příklady „Má někomu přijít notifikace o jejím založení, chcete, aby se smlouva vytiskla, bude smlouvu někdo schvalovat?“. Vycházejte ze zkušeností z jiných projektů, kde jste řešili něco obdobného. </p><p><strong>Vždy prezentujte, což je obzvlášť důležité v době on-line meetingů.</strong> Není nic horšího, než když se všichni dívají do černé obrazovky s ikonami fotografií účastníků. Z mých zkušeností není až tak důležité si zapnout kameru a vidět se, jako sdílení „řešeného obsahu schůzky“. Pokud máte první meetingy, otevřete si úvodní zadání klienta, nebo klidně malování s připravenými body. Pište, kreslete, modelujte, ale vždy to s klientem sdílejte. Abyste mohli něco sdílet, musíte se samozřejmě na každou schůzku s klientem připravit. <strong>Základ práce analytika je navrhnout harmonogram témat a na každou schůzku jít připravený.</strong> Pokud se budete bavit o oblastech, které neznáte, a nikdy jste neřešili, využijte dostupné veřejné zdroje a nastudujte si je, případně se poraďte s kolegy. Pokud se jedná výjimečně o oblast, ke které nelze nic najít, použijte vlastní fantazii, představte si, jak by to asi mohlo fungovat. Klientovi pak můžete na schůzce s čistým svědomím říct „Tuhle oblast neznám, ale představuji si …“. </p><p>Když už jsme u plánování témat, <strong>nezapomeňte si říct, koho na které schůzce potřebujete</strong>. Nemusí to být konkrétní jméno, stačí role, např. zástupce pro oblast zpracování pohledávek. Je dobré si na začátku analytických prací, i v jejich průběhu, tvořit matici rolí a zodpovědných osob, tzv. stakeholderů. Pro návrh řešení vám nesmí chybět informace od žádného z nich. Pokud byste například navrhovali řešení pro oblast pohledávek, lze předpokládat, že potřebujete toto téma probrat také s odborníkem na legislativu vymáhání, exekuční či insolvenční řízení. Je důležité se správně ptát, ale je také důležité se ptát správných lidí. </p><p><strong>Na konci každé schůzky, nebo už v jejím průběhu, pokud řešíte více témat, zrekapitulujte výstupy</strong>, tj. co jste uzavřeli a jak. Pokud jste společně tvořili proces, v rychlosti jej projděte, pokud jste řešili požadavky, v rychlosti přečtěte alespoň ty, které jsou nosné. Pokud jste některé oblasti nemohli uzavřít z důvodu chybějících informací, zadejte úkoly, ať již klientovi nebo sobě. Na konci každé schůzky řekněte téma pro tu další. Stručně vysvětlete, o co se bude jednat a na co se má klient připravit, například „Pozítří si projdeme oblast evidence vašeho zákazníka, tj. budeme potřebovat zjistit, jaké informace o zákazníkovi potřebujete (osobní údaje, kontaktní údaje), zda jej ověřujete v nějakých registrech (například Insolvenční rejstřík).“ Dejte klientovi čas, aby se na schůzky připravil. Zvýšíte tím jejich efektivitu a samotný postup sběru požadavků nebo analýzy řešení. </p><p><strong>Učte klienta číst vaše výstupy.</strong> Jak jsem psala v úvodu, klient obvykle nebývá odborník na IT, pokud mu tedy nakreslíte proces v BPMN nebo UML, nemusí ho umět číst. Stejně tak nemusí rozumět Use Case modelu, sekvenčnímu diagramu atd. Můžete jej to naučit, což doporučuji. V průběhu schůzek prezentujte své výstupy, procházejte je a krok za krokem popisujte, co na nich je. Jednak si tím s klientem potvrdíte, že váš výstup je správný, zároveň tím klienta postupně naučíte schématům rozumět. </p><p><strong>Vždy pište zápisy ze schůzek.</strong> Je to sice nepopulární, ale nesmírně důležité. Tvorba zápisů by měla být automatickou součástí analytické práce. Každý zápis má v bodech shrnout výstupy schůzky, tedy to, co jste si zrekapitulovali na konci schůzky. Přílohou může být schéma či obrazovka, nad kterou jste diskutovali. Pokud jste v průběhu schůzky, některou „cestu řešení“ zavrhli, uveďte to do zápisu i s důvody, které k tomu vedly. Nezapomeňte zde uvést úkoly i s termíny splnění a zodpovědnou osobou. Zápis by měl vzniknout vždy do 24 hodin od schůzky, nejpozději do 48 hodin. Termín je sice důležitý, ale kvalita zápisu má v tomto případě přednost. Pokud se naučíte dobře psát zápisy, bude to pro vás velice kvalitní vstup do vaší analýzy. Každý zápis musí být klientem schválený, což někdy bývá kamenem úrazu. Proto si s klientem dohodněte pravidlo, že pokud není zápis připomínkován, např. do 2 pracovních dnů, je automaticky považován za schválený. Samozřejmě nezapomínejte na začátku každé schůzky projít stav úkolů. </p><p>Práce sběru těch správných informací od klienta je, jak vidíte, složitější proces. Není to pouze o pokládání těch správných otázek, ale o plánování, přípravě, modelování, prezentování, učení i zápisech. Je to ale také o hraní si, diskusi, brainstormingu, vymýšlení různých situací, kreslení obrazovek. Jedná se o iterativní proces, kdy vy se postupně učíte „business klienta“ a on se učí „jak číst vaše návrhy“. Pokud vše uděláte správně, navrhnete řešení, které klientovi vyřeší jeho reálné potřeby. A to je cílem každé analytické práce.<br></p><p>Zuzana Drotárová<br></p>projekty;#
Digitalizace kontejnerových vozíků pomocí IoT čidel – řešení pro logistické problémy v době nárůstu elektronického obchoduhttps://create-it.cz/Blog/Stranky/digitalizace_voziku.aspxDigitalizace kontejnerových vozíků pomocí IoT čidel – řešení pro logistické problémy v době nárůstu elektronického obchodu<p>​​S růstem objemu elektronického obchodu a změnami v chování spotřebitelů je efektivní doručování zásilek obtížnější než kdykoli předtím. V důsledku neefektivity logistických procesů má mnoho přepravců problémy pokrýt stále rostoucí počet zásilek. Nedostatečný přehled o využití a umístění kontejnerových vozíků způsobuje zbytečné komplikace a neefektivitu v jejich optimálním využití. Intenzita dopravy a náklady kvůli nevyužité kapacitě přepravního prostoru rostou, negativně působí na životní prostředí, a navíc se termíny na doručení zásilky prodlužují. A nespokojení zákazníci se pak hlasitě domáhají svých nedoručených zásilek!<br></p><p>Všechny tyto problém je možné řešit sledováním kontejnerových vozíků pomocí technologie Bluetooth. Dobrým příkladem je nizozemská pošta, která nedávno oznámila digitalizaci 250.000 přepravních rolovacích klecí pomocí čidel od společnosti <a href="https://kontakt.io/" target="_blank">Kontakt.io​</a>. Pošta doručuje přibližně 1,1 milionu balíčků a 8,1 milionu dopisů napříč celým Beneluxem denně! V roce 2020, během koronavirové pandemie doručila rekordní počet 337 milionů zásilek, což bylo téměř o 20 % více než v roce 2019.</p><p>Technologie, kterou nizozemská pošta pro digitalizaci svého logistického procesu a sledování rolovacích klecí naložených zásilkami zvolila, jí přinesla mnoho výhod – které jsou však využitelné i v řadě dalších odvětví.​<br></p><h2>Přehled o využití kontejnerových vozíků</h2><p>Jejich sledování pomocí IoT čidel umožňuje nizozemské poště získat lepší přehled o tom, jak jsou využívány. Čidla poskytují informace o tom, kdo vozíky právě používá, jak často je využívá, a kolik jich je momentálně k dispozici. Díky přesnému monitoringu dokáže pošta identifikovat nevyužité či prázdné vozíky a minimalizovat tak náklady v celém dodavatelském řetězci.​<br></p><h2>Optimalizace </h2><p>Detailním sledováním pomocí bluetooth čidel může pošta rozmístit vozíky tak, aby byly využívány co nejefektivněji. Ukázalo se, že zatímco v některých expedičních depech jsou vozíky z části nevyužívané, jinde dokázali přidáním dalších vozíků výrazně zvýšit efektivitu přepravy.​<br></p><h2>Odhalení úzkých míst a problémů v logistickém řetězci</h2><p>Pokud je nedostatek vozíků na jednom místě, nebo se někde hromadí zásilky, může to znamenat, že pošta nebude zásilky stíhat odbavovat. Díky bluetooth čidlům od společnosti Kontakt.io, sledujícím polohu kontejnerových vozíků, dokáže nizozemská pošta problémy předvídat a zaměstnance nebo vybavení včas přesunout, aby se situace vyřešila. Tento jednoduchý krok řeší problémy dříve, než vzniknou.​<br></p><h2>Lokalizace „zatoulaných“ zásilek</h2><p>Ztráta zásilky nebo celého kontejnerového vozíku znamená pro každou zasilatelskou službu vážný problém. Díky čidlům je lokalizace vozíků mnohem jednodušší a rychlejší, pošta o žádném z nich nikdy neztrácí přehled. Ví, na který kontejnerový vozík s tzv. rolovací klecí byla zásilka naložena a také pozná, ve kterém voze nebo překladišti se vozík nachází. Dokáže proto snadno zjistit, kde přesně se zásilka nachází a v případě potřeby ji přesunout na správné místo.​<br></p><h2>Informace o kapacitě kontejnerových vozících v reálném čase</h2><p>Díky digitalizaci logistiky pomocí sledovacích čidel má nizozemská pošta přehled dokonce i o aktuální kapacitě jednotlivých kontejnerových vozíků – zda je klec plně naložená, nebo zda je v ní volné místo. Detailní přehled, kde se vozíky nacházejí, co obsahují a jak se pohybují, včetně případných zpoždění, umožňuje zvýšit efektivitu procesů a zlepšovat zákaznické služby.​<br></p><h2>Snížení nákladů</h2><p>Sledování rolovacích klecí a toho, co je na nich, umožňuje identifikovat místa, kde je možné snížit náklady v logistickém řetězci. Například posílat plně naložené klece místo poloprázdných, nebo zajistit, aby tyto jednotky jely co nejpřímější cestou na místo určení. ​<br></p><h2>Snižování ekologické stopy</h2><p>Rychlá identifikace míst, kde lze kontejnery nejlépe využít, přináší nejen vyšší nákladovou efektivitu, ale zároveň snižuje negativní dopad na životní prostředí díky menšímu množství nevyužitého prostoru během přepravy.<br></p><p>Technologie sledování kontejnerových vozíků pomocí IoT čidel, které zvolila nizozemská pošta, může být klíčovým řešením, jak zvládnout stále rostoucí objem přepravovaných zásilek. Tato technologie umožňuje získat lepší přehled o využití kontejnerových vozíků a minimalizovat náklady na výměnu zařízení. Díky monitorování lze rozmístit vozíky tak, aby byly využívány co nejefektivněji a předvídat „úzká hrdla“ v logistickém řetězci. Pomáhá řešit problémy dříve, než vzniknou, a minimalizovat negativní dopady na životní prostředí. Společnosti a organizace i v dalších odvětvích mohou tuto technologii využít k optimalizaci svých logistických procesů a minimalizaci nákladů.​<br></p><p><em style="orphans:2;text-align:justify;widows:2;text-decoration-style:initial;text-decoration-color:initial;">K​ateryna Sakovska​</em>​<br></p><p><br></p>odborné;#
V Cleverlance mě to nepřestává bavit ani po 12 letechhttps://create-it.cz/Blog/Stranky/rozhovor-petra-m.aspxV Cleverlance mě to nepřestává bavit ani po 12 letech<p>​​​​​​Dělat rozhovor s mladou a chytrou ženou je vždy radost. Pokud je to vaše kolegyně, se kterou máte možnost se potkávat v Cleverlance již 12 let, je ta radost dvojnásobná. Dnes vám představíme Petru M., které jsme se zeptali, co se za její profesní kariéru změnilo a jaký má na práci v Cleverlance pohled.<br></p><h4>Ahoj Petro, jak​​​​ se máš?​​​</h4><p>Mám se skvěle, děkuji. (smích)</p><h4>Jaká byla „tvoje cesta“ do Cle​ver​lance?</h4><p>Studovala jsem Softwarové inženýrství na ČVUT a už během studia jsem měla možnost vyzkoušet si různé projekty a role. Práce v IT se mi líbila už tenkrát, tak jsem po vysoké škole nastoupila do firmy, která vyvíjela software. Tam jsem byla asi tři roky, ale protože jsem se chtěla více rozvíjet v analýze, začala jsem se poohlížet po dalších možnostech. Ve finále jsem se rozhodovala mezi dvěma společnostmi, které o mě měly zájem. Obě firmy dělaly na podobných projektech, obě měly dobrou pověst, co se odbornosti týče, ale při návštěvě v Cleverlance mě více oslovilo její pracovní prostředí, a kultura, kterou jsem tam vnímala. A letos v květnu je to už 12 let.</p><h4>Takže jsi dala na svůj pocit?</h4><p>Ano, a nelituji toho. Cítila jsem, že v Cleverlance je komunita lidí se stejným cílem. Nejdříve jsem pracovala spíše na projektech u zákazníků a neměla tak možnost se s dalšími kolegy vidět každý den, naštěstí se ale v Cleverlance dělá maximum pro to, aby se měli šanci všichni potkávat. Organizují se různé akce, společné obědy, nebo snídaně s managementem, abychom věděli, co je nového. Já nejvíc oceňuji nabídku různých školení a dalších vzdělávacích „aktivit,“ na kterých mám možnost se potkat s ostatními.</p><h4>Na co ráda vzpomínáš?</h4><p>Zhruba po roce se situace výrazně změnila, kdy jsem z menších projektů u zákazníka, začala pracovat přímo v kancelářích firmy na vývoji softwaru pro nové pilíře penzijního pojištění. Projekt byl velmi náročný, protože musel být dokončen ještě před začátkem platnosti nové legislativy. Práce bylo sice hodně a někdy jsme pracovali i o víkendech, ale v týmu jsem poznala spoustu skvělých lidí, se kterými jsme měli společný cíl, na který jsme se soustředili. Nikdy například nezapomenu na tradici společných obědů, kterou jsme ještě ve starých kancelářích v pražských Holešovicích měli, a rituál vybírání, vyjednávání a smlouvání, na co a do které restaurace vyrazíme. To byl tenkrát asi nejvýraznější rys naší firemní kultury. (smích)</p><h4>Takže jsi tu našla, co jsi hledala?</h4><p>Ano a poznala jsem, že v Cleverlance jsou dva typy lidí: jedni, kteří přijdou s cílem pracovat na konkrétním projektu a po jeho dokončení pokračují dál, a druzí, kteří tu pracují dlouhodobě na různých projektech. Ta druhá skupina je daleko větší i díky tomu, že v Cleverlance je velké množství zajímavých projektů pro široké spektrum zákazníků v různých odvětvích a je tedy z čeho vybírat. S některými z nich pracuji na různých projektech stále, se spoustou dalších lidí se sice běžně nevídám, ale víme o sobě, a potkávám je třeba na školeních, na akcích nebo minimálně na vánočním večírku. A je to vždy velmi příjemné setkání. (smích) </p><p>Pokud se na to podívám z pohledu business analýzy, podařilo se nám společně po několika letech práce spoustu věcí nastavit – postupy, metodiky, standardy. Myslím, že nás hodně spojil i ten pocit spoluvytváření, společných inovací, nebo projekty, kde jeden navazuje na výstupy předchozího.</p><h4>A z odborného hlediska? Co si myslíš o možnostech profesního růstu v Cleverlance?</h4><p>Za prvé je to podle mě o zkušenostech. Děláme na zajímavých zakázkách pro velké zákazníky, takže tu o ně není nouze. Jako B​usiness analytik jsem si například musela zorganizovat spoustu workshopů se zákazníkem, s budoucími uživateli vyvíjeného softwaru. Mnohokrát se mi stalo, že přišla skupinka lidí, kteří mi dokázali úplně zničit agendu a vůbec jsme se nedostali k tomu, co bylo vlastně cílem setkání. To byl hlavně můj problém, nedokázala jsem to správně zkorigovat a zabývat se tématem toho konkrétního workshopu. To mě naučilo, jak důležité je si správně naplánovat agendu a jasně komunikovat cíl a proč jsme se vlastně sešli. Důsledně schůzku vést, držet se cíle a nedat prostor ničemu, co by mohlo workshop „rozbít.“</p><p>Za druhé Cleverlance nabízí spoustu skvělých interních školení, která jsou k dispozici pro každého a skvělé je, že si je vytváříme „sami pro sebe“. Osobně jsem těchto školení využila už jako student, později i jako lektor. V Cleverlance je samozřejmě i možnost absolvovat externích školení. Konkrétně v mém případě, kdy jsem se po několika letech jako Business analytik chtěla posunout do role Product ownera, tak mě Cleverlance v kariérním postupu podpořila a zaplatila mi externí školení i certifikaci.</p><h4>Vážně? A jak se tedy podle tebe změnila business analýza jako obor, za tu dobu, co jsi tady?</h4><p>Když jsem před lety nastoupila do Cleverlance, používala se při řízení projektů jen metodika waterfall, ale protože nastávaly komplikace s řízením projektů, přešli jsme postupně na agilní způsob práce a máme lepší výsledky. Pracovala jsem na mnoha projektech v bankách, které tímto způsobem změnily nejen vývoj IT systémů, ale celou svojí organizaci. Týmy mají v současné době k dispozici Product ownera, který definuje požadavky zákazníka. Tento trend již funguje nějakou dobu a podle mne konečně umožnil porozumění mezi zákazníkem a týmem, který software vyvíjí.</p><h4>Jaký je podle Tebe vlastně rozdíl mezi Business analytikem a Product ownerem?</h4><p>Business analytik se obvykle zaměřuje na analýzu a porozumění potřebám zákazníka. Na to, jak mohou být tyto potřeby naplněny v podobě vyvíjeného softwaru. Business analytik pracuje s vývojovým týmem, aby vypracoval specifikaci a po celou dobu projektu zajišťoval, že jsou naplněny potřeby zákazníka. </p><p>Product owner podle mne více řeší, proč software vlastně vzniká, k čemu bude sloužit. Vytváří „vizi“ výsledného softwarového produktu a snaží se ji předat celému týmu. Na denní bázi řeší priority jednotlivých požadavků, jak jsou důležité pro „business“, do kdy musí být hotové, a plánuje vydávání nových verzí.</p><p>To je důvod, proč je pro mne tahle role současným vyvrcholením mojí profesní cesty. Postupně jsem si vyzkoušela různé role v rámci IT a uvědomila si, že otázkám „co máme dělat“ a „jak to máme udělat“ musí předcházet otázky jako „proč to máme udělat,“ „proč je to důležité“ a „jak je to důležité…“. Myslím, že v Cleverlance si lidé velmi cení možnosti získávat zkušenosti při práci pro různé zákazníky, v různých oborech, na různých projektech. Neumím si představit, že bych strávila celých 12 let stejnou prací na jednom místě, pro jednoho zákazníka.</p><h4>Co tě teď v nejbližších měsíc​ích čeká?</h4><p>Hodně práce. (smích) Začala jsem participovat na novém projektu jako Product owner několika produktů. Zatím se rozkoukávám, sbírám informace a znalosti, rychle bych ale chtěla být pro zaběhnutý tým přínosem. A jelikož dovolenou pro své dobrodružnější cesty do Maroka a Uzbekistánu plánuji až po prázdninách, krásně to do sebe zapadá.</p><p>Tak ať se ti daří, příjemné léto.</p><p>Díky za rozhovor.</p><p> <em>Kateryna Sakovska​</em><br></p><p> <br> </p>​<br>odborné;#vzdělávání;#projekty;#