[JiRo]

I když eOP mám taky a používám, občanku jsem si k volbám také vzal. A to jsem o problémech nevěděl. Snad je to takový léty zažitý reflex, automatizmus. K volbách vždy s občankou. Takže jsem si s sebou vzal vybraný a zakroužovaný volební lístek, občanku, telefon, klíče a vyrazil jsem.

Sám mám zkušenosti se různými IT systémy (řízení v energetice) a vím tedy, jak je důležité ještě ve fázi úvodní analýzy, parametrů při výběru dodavatele, basic designu, designu, výroby, instalace i testování, podchytit všechna možná rizika, mimořádné situace, kdy takový systém pracuje v netypickém/nenormálovém stavu, a které mohou mít na jeho funkci zásadní vliv. Proto mě v odkazovaném článku zaujalo vyjádření ředitele DIA Martina Mesršmíta, kde je podle mne všechno špatně:

Došlo k nesprávnému odhadu a testování na tuto zátěž. Zájem o eDoklady byl velký, což nás velmi potěšilo a velmi nás mrzí to, že se nepodařilo zájem pokrýt kapacitou systému.

• žádný odhad v jakékoliv fázi řešení nemá místo. Musí jít o výsledek komplexní úvodní analýzy, jejího auditu i škálování možných požadavků na funkce systému po celou dobu jeho používání. Při spuštění systému, při jeho zálohování, instalaci nové verze, ve dne v noci, v pracovních dnech, sobotu i neděli, o svátcích, na začátku pracovního týdne, na jeho konci, na začátku prázdnin, na jejich konci, při volbách, Olympiádě, vysokých teplotách i těch nízkých, za sucha, při povodních, ... Záměrně to přeháním, ale takhle komplexní to musí, případ od případu a systém od systému, pokud jsou ty jednotlivé situace pro něj nějak signifikantní, být.
  
• řešit tohle až při testování, je pozdě. Ano, při testování se ty očekávané mimořádnosti musí ověřit (nejlépe nasimulovat), ale musí se tak dít na základě nějakého seznamu, které mimořádnosti a definice toho jak budou vypadat, který byl zpracovány už v úvodních analýzách, tedy ještě dávno před tím, než se systém začal poptávat. A na tyhle mimořádnosti musí být systém, resp. jeho parametry a požadavky na něj, už od úvodních fází celého projektu, navržen. Testování pak už jen ověří, jestli bylo vše provedeno správně.
  

To, že ředitel DIA nakonec rezignoval je asi správné, ale i to nemusí být jednoznačné. Je samozřejmě otázka, kdo tu úvodní analýzu a podklady pro výběrové řízení připravoval. Pokud on ten požadavek na funkci systému při mimořádných situacích do zadání a požadavcích na parametry systému neuvedl, je to jeho chyba. Je pak otázkou, zda to dodavatel mohl či chtěl ovlivnit. Velmi často je to tak, že když na to například účastník výběrového upozorní, tedy že je to zadání slabé, je z výběru vyřazen. Když to ale v dobré míře zohlední, cena naroste a neuspěje taky.

Já jsem se ve své profesní praxi účastnil snad všech zmíněných procesů, napřed jako uživatel a zadavatel, pak jako vývojář, realizátor, product manager, project manager a nakonec i jako obchodník, který systémy nabízel. A ze všech těch procesů jsem si odnesl dost zkušeností, ale jedna z nich mi, s ohledme na diskutované téma, připadá jako klíčová:

Úroveň a kvalita nabídky je přímo úměrná úrovni a kvalitě poptávky.

A tohle je něco, co se zejména ve státní správě, kde ta úroveň poptávky bývá někdy skutečně tristní, potvrzuje. A patrně se to teď propsalo i do případu eDokladu. Jednoduše řečeno, zapomněli na to, že přijde den, tedy den voleb, kdy tu eObčanku použije několikanásobně víc lidí, než kdy jindy.