Jak získat potřebnou IT infrastrukturu

Již dost dávno (přelom tisíciletí, resp. začátek 90. let) jsme dospěli k názoru, že individuální řešení jsou mírně řečeno problematická. Na dané téma uvádím příklad KHK Software, jejichž partnerem jsme byli při mém působení ve Vídni na konci 80. let. Nejdříve propagovali a podporovali vytváření "customizací" pro zákazníky, kterým se nelíbila standardní funkčnost. Dost často vznikaly naprosté nesmysly. Po zhruba 2 letech zoufalé a marné snahy zajistit, aby to, co partneři vyvíjející nadstavby vytvoří, neničilo základ funkčnosti a navíc fungovalo i v nových verzích, veškeré úpravy zakázali. Sice jim to už nepomohlo, ale ponaučení je jasné.

Individuální řešení je opuštěný ostrov (s aktivní sopkou).

Pokud nic jiného nezbývá

Dejme tomu: Jsme natolik specifická organizace (např. finanční instituce, provozovatel energetických sítí, operátor nebo některá z organizací provozujících veřejnou infrastrukturu... nebo rovnou MMR), že pro konkrétní potřebu žádné standardní řešení neexistuje. Stojíme před otázkami.

• Jak získat potřebné IT řešení?
• Jak vytvořit dostatečně přesné zadání (pokud je to vůbec reálné)?
• Jak by takové zadání mělo vypadat? Jak aplikovat princip MVP?
• Umíme dostatečně přesně popsat (zjistit & vyjasnit) naše faktické potřeby?
  Věcný obsah a souvislosti toho, co děláme, nikoli technické aspekty vytvářeného řešení - předpokládá se, že vývoj bude probíhat plně v souladu se všemi známými architektonickými, technologickými, bezpečnostními a dalšími standardy (takže není potřeba předstírat, že je známe a chápeme, co to znamená) - např. spoléháme, že ergonomii IT systémů bude zhotovitel rozumět lépe než zadavatel (a víme, že na stavbě je užitečný stavební dozor). Jde o schopnost převést nepochybnou znalost domény do zadání plně srozumitelného / jednoznačného zhotoviteli.

Popř. jestli nemá být ta definice potřeb a z nich odvozených požadavků součástí plnění, nikoli zadání.

Realita

Nezabývejme se tím, kdo má dělat co. Vyjasněme si, co je z technického hlediska nezbytně nutné, popř. žádoucí. Co jsou nesporná omezení.

Východiska/omezení

• Organizace, která potřebuje pro svoji činnost novou nestandardní IT funkčnost/infrastrukturu, nemá obvykle vlastní kapacity pro její vývoj.
  • Přestože lze předpokládat trvalý vývoj / rozvoj individuálních řešení, není účelné držet interní kapacity na veškerou práci, kterou je potřeba jednorázově odvést (vzácnost takových lidí na trhu práce, náklady na udržování kvalifikace, míra závislosti, stimulovatelnost atd.).
  • Pokud by se dala efektivně využívat "práce ve mzdě" (vývoj elementární funkčnosti dle potřeby zadávat exernistům), možná by dávalo smysl mít interně "core" tým, který by řešil fakticky jenom architekturu řešení a veškerou realizační práci nakupoval. Sporné je, jak by to fungovalo u testování, tvorby dokumentace, při integrací se stávajícími systémy apod. Plus téma interních standardů (není obvyklé, že externí vývojáři budou ochotni dodržovat pravidla, která se jim z jakéhokoli důvodu nelíbí).
    Plus platí, že pokud chci něco hodně sofistikovaného a nejistého jednoznačně zadat, dost často může být efektivnější to rovnou udělat. Což bude u nových systémů většina práce.
  • Nároky na způsobilost jak vývojářů, tak jejich vedoucích jsou enormní. S rozvojem technologií rostou. Obecný nedostatek takových lidí - jejich cena a náklady na jejich řízení (koordinaci práce).
  • Stabilní tým by měl dosahovat výrazně vyšší produktivity a drasticky nižší chybovosti. To směřuje k jinému přístupu.
• Je rozumné respektovat princip MVP.
  Tak jako tak není reálné pro komplexnější systém udělat "dostatečné" zadání pro "cílovou" podobu funkčnosti, protože jak známo, už samo nasazení nového systému představuje zásadní změnu, která zcela jistě povede ke změně požadavků (neměla by ovlivnit potřeby, ty zůstávají stejné, dokud se nezmění externí prostředí). Takže vytváříme minimalistickou verzi s vědomím, že se další funkčnost bude postupně doplňovat. To má řadu výhod.
  • Nižší nároky na komplexnost analýzy = rychlost všeho.
  • Snižuje se riziko nesprávného pojetí (zadání, zmařené investice).
  • Uživatelé budou mít dřív k dispozici to, co potřebují. Postupná funkčnost vždy musí znamenat snížení nároků na uživatele (usnadnění).

Pochyb o smysluplnosti vlastní vývojářské divize je zkrátka příliš mnoho. Některým typům organizací se to může vyplatit, zejména když dokáží efektivně nastavit interně vztahy (na komerčním principu - fakticky to ovšem musí dopadnout tak, že se vývoj software osamostatní, nebo se z něj stane zhoubný nádor). Takové vztahy, aby se vývoj choval racionálně - měl zájem na dodání optimální funkčnosti co nejrychleji + zájem na otevřenosti, udržovatelnosti a rozšiřitelnosti řešení. Což je klíčová výzva pro interní i externí realizaci. Samo od sebe k tomu nedojde.

Jak postupovat

• Provést důkladnou (iniciální) analýzu potřeb. Systematicky v ní pokračovat jak v průběhu vývoje, tak v době rutinního provozu (sběr nedostatků, podnětů, využívání příležitostí spojených se změnami technologií, podmínek, dovedností lidí atd.).
  • Je otázka, zda / nakolik je organizace provést takovouto analýzu vlastními silami, popř. jak to zjistit/ověřit. Hodně jednoduše se nabízí validace vytvářených materiálů nezávislým expertem, který sice najde jen některé věcné nepřesnosti reálných potřeb (nemá dostatek konkrétních zkušeností / interních podkladů, ale pokud je skutečně kvalifikovaný, měl by zpochybnit nedostatečně doložené požadavky / představy), měl by ovšem být schopen najít všechny problémy směrem ke specifikaci pro vývoj (vyhodnotit, nakolik dobře jsou postavena akceptační kritéria, aby vývojový tým věděl, co má dělat).
  • Pokud by tuto práci měl dělat někdo zvenčí, fakticky po něm chceme, aby velmi komplexně poznal naše podmínky / situaci. Plně pochopil potřeby včetně všech technických, organizačních a legislativních specifik. Něco takového se může vyplatit jen ve velmi speciálních situacích (aneb je potřeba to zvládnout interně - pokud to neumíme, je nutno se to naučit - viz dále).
• Výsledky analýzy převést do specifikací. K tomu už potřebujeme konkrétního vývojáře, který zná možnosti využívaných komponent, technologií a prostředí.
• Vytvořit minimalistickou (pokud to dává smysl, tak dílčí) verzi funkčnosti. Tu v rámci vývoje důkladně (na dodaných / společně vytvořených či odvozených) testovacích datech otestovat. Definice testů (fakticky součást akceptačních procedur) musí být velmi důkladně a srozumitelně popsána v zadání.
  Snažíme se ověřit, nakolik dodavatel chápe zadání a jak dokážeme spolupracovat. Musí to být skutečně minimalistický rozsah a musí to být velmi rychle (od sjednání té minimalistické funkčnosti v řádu dnů nebo týdnů - a pokud dodavatel tvrdí, že to nejde, tak pravděpodobně počítá s tím, že se na té naší zakázce teprve bude učit vyvíjet software... nebo se úmyslně brání tomu minimu, na kterém se má ukázat, "co umí").

Kritickým prvkem je objektivizace analýzy potřeb. Je velmi pravděpodobné, že v naprosté většině organizací chybí k tomuto účelu kvalifikovaná kapacita. Optimální řešení by mělo být získat ji cestou rozvoje dovedností (nejlépe na principu learning by doing) vlastních pracovníků - naučit se to. Ale i tak bude potřeba pro audit jejich práce využit externího experta (je pravda, že najít dostatečně účelná a účinná kritéria hodnocení jeho práce může být obtížné - u seriózních partnerů lze sjednat předem rámec a pravidla určující, podle čeho se stanoví výše odměny a kdy a za jakých okolností bude přiznána).

Pokud hodláme provést analýzu potřeb s využitím externích kapacit, je potřeba si uvědomit, že po lidech, kteří to mají dělat, chceme, aby pochopili to, co děláme, lépe než my sami (nemluvě o překážkách, které jim přitom hodláme stavět do cesty). Což je pro ně extrémně náročné a pro obě strany výrazně neefektivní. Alternativou je smíšený tým, ve kterém je hlavní náplní vysvětlování principů a moderace součinnosti. Obvykle je pochopení potřeb bez intenzívní účasti interních lidí nemožné. Intenzívní účast je podmíněna alespoň částečným rozvojem dovedností.

V případě akce typu "digitalizace stavebního řízení" to je nejspíše jinak - u externistů může být pracnost nižší a úroveň pochopení potřeb vyšší než u interních pracovníků zadavatele (jelikož záměr je natolik obecný a nezávislý na současných reáliích, že vyšší kvalifikace externistů převáží nad zkušenostmi interních pracovníků).

Zájmy dodavatele

Pokud (teoreticky) dostává jednorázové zadání, které dostatečně definuje výsledek.

• Vyfakturovat co nejvíc a udělat co nejméně. Čas je dán.
• Účinnost zapracování uživatelů nikdo nehodnotí.
• Případné koncepční chyby - pokud je to jednorázová akce - nevadí.
• Nejsou pravděpodobné korektní zátěžové testy, takže se ani nemusí objevit neefektivnosti.

Jestliže tvůrce systému chápe, že se o něj bude muset starat, mohl by se chovat jinak.

• Hlavní část ceny vytvořeného / provozovaného řešení získává jeho provozem. Takže se snaží jej zprovoznit co nejdříve v minimálním rozsahu a optimální kvalitě (MVP). 
• Ví, že zapracování je klíčem a proto bude usilovat o to, aby uživatelé zvládli nový systém co nejlépe.
• Mohl by vytvářet systém tak, aby se mu průběžně snadno rozšiřoval (protože se největší část funkčnosti bude doplňovat průběžně a trvale). Je to sice aktuálně náročnější než nejjednodušší možné konstrukce, ale z dlouhodobého hlediska to může být naprosto zásadní (pokud systém s rozvojem nepočítá, může být nutno jej pro doplnění funkcí vytvářet znovu).
• Má zájem na minimalizaci spotřeby kapacit na podporu a odstraňování chyb, proto bude dbát na optimální kvalitu řešení (protože cena podpory je konstantní nebo se snižuje s růstem počtu zásahů).

Chce to najít partnera, který by pochopil výhodnost této podoby spolupráce. Přiznat si, že není reálné ani žádoucí udělat úplné zadání. Naopak bychom se měli snažit dostat zadání co "nejvýš" - nikoli atomické technické požadavky, ale přimět dodavatele vnímat naše potřeby včetně jejich budoucího vývoje a zajistit jeho zájem na tom, aby vytvářené řešení bylo co nejefektivnější.

Myslitelný scénář

Připusťme, že nedokážeme (sami ani s nezávislým externím poradcem) formulovat zadání tak, aby bylo zcela nesporné, co má vyvíjený systém dělat (sestavit jasná akceptační kritéria; pokud to dokážeme, můžeme takovéto zadání zkusit soutěžit, není jisté, zda najdeme dodavatele). I kdybychom to dokázali, tak se zůstává problém s udržováním a rozvojem systému (viz výše zájmy dodavatele). 

• Najít spolehlivého partnera. Nikoli nejlevnějšího, ale nejspolehlivějšího.
• Společně nastavit pravidla spolupráce tak, aby obě strany měly zájem na co nejefektivnějším průběhu vývoje. Vybudovat - s účastí alternativního dodavatele - prostředí tak, aby bylo garantováno dodržování standardů a metodik - aby bylo možno řešení předat nebo migrovat data. Pokud na to partner nepřistoupí nebo to bude sabotovat, tak zjevně není dostatečně spolehlivý.
• Současně tím na něj převést zájem o to, aby řešení bylo i z dlouhodobého hlediska co nejefektivnější. Ideálně to nastavit tak, že rozvoj systému je hrazen z paušálu podpory. Paušál závisí na produktivitě uživatelů nebo obdobné hodnotě vyjadřující užitečnost řešení.

Směřuje to fakticky k "pronájmu" individuálního řešení. Aby dané řešení zůstalo jeho tvůrci, resp. poskytovateli. Aby měl zájem ho rozvíjet. Aby měl zájem, abychom s ním byli spokojení. Když se s ním budeme muset rozejít, vytvořené řešení si "koupí" jeho nástupce (nebo už má vyvinuté lepší). 

Proč by to mělo fungovat

Funguje to u outsourcingu auta. Nemusí nám patřit, přesto v něm můžeme jezdit. Stačí najít správné podmínky. Nevymlouvat se, že to nejde. Pochopit, že není výhodou vlastnit něco, čemu nerozumíme, neumíme to ani rozvíjet, ani opravit pokud se to rozbije. Chytré je najít způsob, jak nastavit vztah s poskytovatelem - aby to, když nebudeme se systémem spokojení a budeme to chtít vyměnit, byl problém pro stávajícího poskytovatele, nikoli pro nás.

Neříkejme, že to nejde, když jsme pro to nic neudělali.

• Rozhodnutí musí udělat majitel: "Chci, abychom si další/tento systém pronajímali. Dohodněte se, co to má umět a sjednejte nájem včetně podpory a dalších služeb, který na X roků nebude vyšší než pořizovací náklady a podpora. Chci vidět kompletní dokumentaci jednání s minimálně dvěma / třemi / xxx potenciálními dodavateli. Prostě se to naučte - zajistěte si, co k tomu potřebujete, máte na to Y% rozpočtu nového řešení."
  Nebo něco takového...
  Je to pořád to stejné (jako u pořízení jiných produktů, které nedokážeme nesporně zadat). Musíme využít kvalifikace poskytovatelů a domluvit se s nimi na tom, co zadat dokážeme.
• Vyžádá si analýzu situace & audit & návrh smluv / podmínek.
• Pokud analýza tvrdí, že není reálně si na míru vytvořené řešení pronajmout, musí hodně srozumitelně vysvětlit proč. Např. vůbec nikdo z potenciálních dodavatelů není ochoten přistoupit na outsourcing. 
  Což je zjevně jen otázka ceny a souvisejících podmínek. Nedává smysl chtít "přechytračit" partnera, který by poskytoval životně důležité služby, Je ovšem možné, že se široko daleko nenajde nikdo, kdo by byl ochoten nesnažit se přechytračit nás...
• Autorská práva jsou beztak nezcizitelná.
• Poskytovatel nás tak jako tak drží pod krkem. Nebude škodit, když se budeme držet navzájem.
• Hledat, jak to jde a ne jak to nejde.

Je pravděpodobné, že pokud se najde někdo, kdo přistoupí na rozumnou podobu vztahu - férové rozdělení nákladů, rizik a užitku, tak řešení bude výrazně kvalitnější a levnější. Bude to hodně efektivní pro obě strany.

Na případě stavebního řízení je dobře vidět, jak je to celé neskutečně komplikované. Navíc platí, že je skutečným utrpením slyšet politiky, když o tom mluví. Bezpochyby nelze předpokládat, že by veřejnost rozuměla kvalifikované analýze a bylo by velice obtížné a nepopulární převést odborný názor do polohy, kterou bude spolehlivě chápat i člověk bez IT-kvalifikace. Takže nejspíš nebudeme mít šanci si udělat vlastní názor na to, kdo v čem selhal a jaké ponaučení si lze odnést. Zjednodušeně platí, že veřejný zadavatel pravděpodobně zákonitě není schopen pořídit téměř žádné sofistikovanější řešení (diskuse možná u příspěvku na LinkedIn).