"Na trhu dlouhodobě chybí vývojáři nebo datoví analytici, takže vznikají nástroje odstraňující programátorskou vrstvu."
Tohle ovšem neřeší problém s chybějícími vývojáři a už vůbec ne s datovými analytiky (i když nepochybuju, že se to tak SAP jako obvykle snaží tupější části managerů prodat), ale nahrazuje to tu nejlevnější část kodérů tam, kde se jejich práce překrývá se správou obsahu a integrační vrstvu. Ani jedno z toho ale opravdu není žádná novinka.
Tohle bude katastrofa. Na papíře to vypadá hezky, ale v praxi to nebude dlouhodobě fungovat. Problém totiž není primárně v tom, že aplikace nemá kdo vyvíjet, ale v tom, že je nemá kdo udržovat.
Také jsme takhle "na koleni" vyvíjeli různé aplikace pro podporu naší výroby. Důvod byl právě v tom, že vývojáři měli plné ruce jiné práce, nechtěli řešit jednoduché věci, které by nám naopak nejvíce pomohly, a na všechno lepili šílené cenovky za vývoj v tisích dolarů, takže by návratnost byla v řádu roků. Management na to docela slyšel, protože nám tyhle naše malé utilitky v součtu šetřily docela dost času a práce. A v neposlední řadě se jimi předcházelo lidským chybám - úkon, který není třeba udělat, se nedá pokazit.
Proč to ale brzo začalo drhnout a na čem se to nakonec zastavilo? Drhnout to začalo ve chvíli, kdy autoři přecházeli na jiné pozice nebo dokonce odcházeli z firmy. Dokumentace obvykle žádná (klidně dvacet stran zbytečné omáčky a zásadní informace žádná), kvalita kódu kolísavá (ne že by byl špatně, ale zkuste lidem vnutit nějaké standardy) a deployment obvykle stylem "to pan Spilka nainstaloval na počítač na příjmu a na počítači mistra ve skladu, ale my nevíme jak". No a zastavilo se to jednou o víkendu (nebo to byl svátek?), kdy se kolem deváté ráno odporoučel náš home made program na tisk štítků a v celé fabrice se nenašel nikdo, kdo uměl s tím originálním, který dva roky nepoužili. Po několika hodinách, kdy výroba stála, to neustál pan generální ředitel, zavolal na support IT (v USA) a domáhal se opravy programu. Marně.
Hned další den přišel zákaz vývoje a používání takových aplikací. Stálo docela dost úsilí to přeci jen nějak protlačit, museli se pravidelně přezkušovat lidé z používání původních aplikací, vše projít auditem, školit lidi na psaní dokumentace atd. V důsledku to skoro všechny původní autory znechutilo a už nikdo nic nového nepsal.
Tahle aktualita mi právě tohle připomněla. Nejdříve bude "hurá, můžeme si sami", ale pak dojde na lámání chleba s podporou těch aplikací. Může si je napsat každý? Každý sám pro sebe a zas a znova? Nebo je bude používat více lidí? A kdo je bude školit? Udržovat aplikaci? Dělat podporu? Co když bude autor na dovolené nebo odejde z firmy? Jak to skončí? Buď nástroj umře, nebo ho budou používat ti samí lidé, co danou práci dělají doteď. Odhaduji, že zde nastane ta druhá varianta: navzdory marketingovým řečem "už nemusíte čekat na čas vývojáře" to nakonec bude právě ten vývojář, kdo to použije. Není to špatně navržené a docela bych se nedivil, kdyby to zvýšilo produktivitu práce vývojářů. Ale z ruky to dát nesmí, protože co neprojde přez ně, to se nedá supportovat.
To zní hezky a určitě na to uslyší hodně manažerů, kteří to přinesou do svých firem. Drag and drop a mám integraci...
To ale bude fungovat jenom pro integrace systémů, kterým SAP služba rozumí. Je to vlastně ideální případ, který kdyby dělal programátor ručně, tak to může být také jen provolání jiného systému pomocí jediného řádku kódu a rozhodně to neudělá pomaleji než drag and dropem.
Ten problém je ten, že takhle ta realita není. Systémy jsou různé, s různými hlavičkami, autentizacemi, autorizacemi, reakcemi na chyby, atd... A asi na tohle je v článku pamatováno ve větě: "Vývojáři a IT odborníci se místo toho budou moci soustředit na klíčové projekty."
Takže ve výsledku se firma rozpoltí na 2 vývojové proudy, ručně a graficky a vznikne navíc závislost na cizým (nyní zdarma, později za peníze) produktu, který může do budoucna překážet.