Názory k článku Senzory Martina Malého: Průmysl 4.0 nevzejde z brainstormingu na teambuildingu

Přesně tak. Každá další verze programu situaci komplikuje, místo aby situaci zjednodušovala. Mám pocit, že programátoři píší SW tak, aby se jim dobře programoval, nikoliv tak, aby byl funkční pro uživatele. Máme dodavatele, který kdysi (před více než 25 lety) vyvinul základ SW a během let jej přizpůsoboval, piloval a ladil novým operačním systémům. Určitá uživatelská operace měla logicky uspořádané obrazovky a se dala udělat doslova za 5 vteřin. Pak se rozhodli, že je potřeba udělat SW znova, protože již původní návrh se přežil (ano, bylo potřeba), ale vše udělali tak, že ta samá uživatelská operace, je práce doslova na půl hodiny a obsahy jednotlivých obrazovek jsou naprosto nelogické. Když jsme se ptali, proč překopali původní funkční uspořádání obrazovek, nedostali jsme smysluplnou odpověď. Ale při pohledu do struktury databáze bylo jasno. Změnili strukturu dat (proč by ne, když je to potřeba), ale aby se jim to snáze programovalo, přizpůsobili zobrazená data (obrazovky) změněné struktuře dat a tím pádem program ztratil jakoukoliv logiku zobrazených dat pro uživatele. Takže páni programátoři jděte do ... pracovního procesu. Neuškodilo by vám trochu reálné praxe.

Problém je v terminologii: programátor má skutečně programovat podle zadání. Od toho aby zadání reflektovalo požadavek dělníka (či později zmíněného účetního) je tam projekťák. Bohužel v ČR spousta lidí stále nepochopila že projekťák není obchoďák, a že projekťák je od toho aby dával smysluplné zadání.

Důsledek je, že český "jakoprojekťák" dá zadání "naprogramuj účetní systém", a od programátora se očekává že si sedne, nastuduje legislativu, a pak to na jejím základě začne dávat dohromady. Výsledek toho je samozřejmě katastrofa: buď se programátor časem zblázní protože se bude očekávat že to bude reflektovat všemožné změny legislativy které má "samozřejmě nastudovat on", nebo se zblázní firma v okamžiku kdy programátor odejde, protože projekt který je postavený podobným způsobem je nepředatelný.

Prumysl 4.0 je stejny buzzword jako Informacni dalnice v 90. letech.

Tohle ale neni v zadnem pripade problem programatoru. Programatori plni zadani analytiku a designeru. Problem je vynechani uzivatelskeho testovani navrhu a obecne setreni nakladu. Daleko vice jsou tohle problemy zpusobene spatnym managementem.

Dříve v každém bytovém družstvu a v každé fabrice seděl programátor a dělal programy, které lidem usnadňovaly práci. Chtěli jste program - programátor přišel do kanceláře, podíval se, co děláte a vyptal se na vazby a závislosti. Pak napsal program, vy jste ho zkusili a řekli jste "tohle je špatně, a ještě bych potřeboval to a to..." Programátor program opravil a po pár iteracích to bylo krásné.
Dnes potřebujete program, tak dáte požadavek šéfovi, ten napíše objednávku (v horším případě výběrové řízení), objednávku dostane analytik, ten uspořádá schůzku s účastí středního managementu, lidé debatují kolem stolu a usrkávají kávu, analytik program popíše a předá to kodérům a odborníkům na user interface. Výsledkem je sofistikovaný systém, bohužel odtržený od reality.
Dnes samozřejmě nejde pracovat starým způsobem - proces či program by nebyl transparentní, bezpečný, dokumentovaný a integrovaný. Ale je to škoda.

Z brainstormingu na teambuildingu vždy vzejde hovadina a občas těhotná sekretářka.
Průmysl 10.0 tedy rozhodně ne.

Zářným příkladem je mbank, kde původně jednoduché tabulky internetbankingu se změnily v jakési omalovánky. A když chcete udělat nějakou ne zcela každodenní operaci, musíte se na infolince (placené)
zeptat, kde že je to ukryté. Zde tedy někdo programoval určitě ne pro uživatele. F

To je otázka míry. One-man show kde jeden programátor je analytik, designér, programátor i odborník na problematiku - může fungovat ve startupu. V okamžiku kdy firma trochu přestane stačit že to má "ten jeden v hlavě", protože je potřeba aby na tom dělalo víc lidí, a to už takto nejde.

Zvlášť pokud to prostředí na které je to zaměřené není úplně "stabilní" - právě zmiňované účetnictví může být značný problém, protože lze těžko předpokládat že programátor bude přes den programovat a po nocích makat jako daňař, aby dokázal držet krok v obou směrech - a zvládal vyrábět sw který to vše reflektuje (a navíc samozřejmě dokáže i konzistentně pracovat dle aktuálních zákonů dle toho, co zrovna zpracováváte).

Když je obchoďák placený podle objemu uzavřených kontraktů a ne podílem na zisku, tak je uzavíraní smluv ze kterých není jasný předmět díla naprosto běžné. Zvláště pak u dlouhodobých projektů, kdy může s velkou pravděpodobností předpokládat, že až se konečně zjistí jakou šílenost zákazníkovi nasliboval, on sám už bude mimo dosah a bude uzavírat ohromný objem kontraktů v jiné firmě.

Ne. Programátor má mít buďto jasně zadáno, co má dělat (modul X, implementace rozhraní Y, metoda Z bude mít kontrakt takový a takový,...), nebo musí mít doménovou znalost toho, co dělá. Expert na účetní programy musí rozumět účetnictví, programátor komunikačního stacku musí znát protokoly,... Jinak z něho vypadne jenom to hnědý mazlavý a šéf ho tím vždycky nahodí.

Vždycky jsme si říkal: Nepřizpůsobujte aplikaci datovému modelu, ale uživateli.

"Dříve nebyly tak univerzální grafické frameworky, GUI se muselo dělat, ale člověk to dělal hodně od nuly."

Já jsem před 30 lety (stejně jako mí spoustudenti na technické univerzitě) dělal s univerzálními grafickými frameworky, které nebyly moc odlišné od dnešních ve smyslu abstrakce a univerzálnosti.

Třeba Smalltalk :-)))

Ono je to vidět i na literatuře. "Softwareové inženýrství" v minulém tisíciletí znalo role jako analytik nebo ideový programátor. Waterfall metoda řízení projektů zahrnovala fáze jako mapování procesů, analýza požadavků. Dokumentace byla plná "mockup screen" obrázků a obsahovala i datový model s komentáři zadavatele. Připravit implementační studii byla práce i na půl roku.

Literatura dnes? Jak začít s Angular, jaký zvolit ORM atd. Zakázky se běžně podepisují ještě před vypracováním analýzy a zadání. Sbírání požadavků zákazníka se realizuje dotazníkem, kde náhodně vybraný nešťastník dostane 500 otázek. Veškerou analýzu a návrh si pak udělá dodavatel na základě dotazníku. Doplňující otázky se nepřipouští, to by vypadali jako blbci, co nerozumí všemu. A prototyp se dostane k zákazníkovi buď bez jakéhokoliv komentáře ("hmm, hezký, hmm, na co to vlastně koukám?") nebo s velkou parádou týden před akceptačními testy ("jak jako že nejde mít na objednávce jednu položku na kusy a jinou na Kg? Že to nebylo v zadání? Protože se na to dotazník neptal!")

Prostě jsou teď v módě "hard skills". Na to, že je potřeba nejprve ze zákazníka vylámat zadání (a na to je potřeba ku*evsky dobrý "soft skill") se zapomíná. Stejně tak se místo "soft skills" jako je prezentace, komunikace a vedení týmů klade důraz na strojové provedení nějaké "agilní metody". Jako by nás 15 minut denně ve stoje ve firmě u tabule mělo jak posunou k pochopení potřeb zákazníka. Navíc tyhle "týmové" metody vedou k moru, který znají projekťáci z minulého tisíciletí: ztráta zodpovědnosti, pocit, že mohu občas vypustit a někdo to vezme za mne, a hlavně ono populární "ve chvíli, kdy to může udělat každý, to neudělá nikdo". Přidejte novinky jako "nikdo nechce být celému týmu pro smích a tak se raději neptá na blbé otázky" a "no já si myslel, že to bude důležité, ale nezbyl čas se zeptat".

Přesně tak. I propaganda má své meze, proto i vývojáře musí zajímat syrová realita a nemohou spoléhat na to, že pomocí propagandy protlačí cokoliv.

To je ženský prvek v mužském světě, u krejčího poskládat oděv z prvků, které se líbily na jiných oděvech konkurentek :-))) Vidění světa na základě líbit se a ne na základě hledání hlubší pravdy a toho jak funguje. Oba přístupy mohou být funkční.

Dnes si nepamatujete zda jste pozamykal dveře. Můžete to vyřešit čidly - a pak budete řešit v kterých čidlech jste už vyměnil aku a kde ne. Nebo které aku v ruce jsou ty staré a které nové ;)

No, je tam zmineno i vyberove rizeni. A to pak muze byt totalni konec - je podepsany akceptacni protokol? No tak si nas znovu najmete a za vsechny zmeny pekne platte. (Anebo mate smulu, trhnete si nohou.)
A v kolika firmach funguje, ze se akceptace provadi skutecne poradne.
Externi firme se nelze divit, ze svou cinnost optimalizuje na cil "podpis akceptacniho protokolu".

Třeba ten Smalltalk.

Ale stejně tak byla propracovaná grafická rozhraní třeba i pro C, a další jazyky.

Ve své podstatě z celého IT programování za posledních 20 let prošlo nejmenšími změnami, a revoluce v programovacích jazycích či nějaká podstatná změna se nekonala. Programování i programovací jazyky stagnují, pokud se stvoří nový programovací jazyk, je to na jedno brdo kopie X jiných už dávno existujících.

Řešilo se to úplně stejně. Navíc odpor uživatelů byl mnohem intenzivnější.

Ano, pro C třeba známé Vermont Views. No k těm změnám v programování se snad vymyká jen Rust a možná renesance funkcionálního programování a teorie kategorií a AI, ale i to už tu před 30 lety bylo, co nebylo, byl dostatečně výkonný hardware na kterém by to šlo rozchodit.

Základy byly položeny v 70. letech a od té doby toho moc nového nepřibylo.

S prumyslem 4.0 se seznamuju jako specialista na automatizaci vyroby a projektant uz pomalu dva roky. Rezepisovat tu detaily nema smysl, ale skepse je opravdu namiste. Hlavni problem je pozadavek nacpat do CRM veci, ktere tam jeste nejsou a nikdo neresi, jestli to ma vubec nejaky prinos. Proste jeste tam nemame data odtud, dejte je tam, at to stoji co to stoji. Dalsi problem je chtit za kazdou cenu naroubovat nove technologie tam, kde to nema smysl. Mam namysli takovy ten tuning trabanta. Typicky pocit managementu, ze pokud na starou linku, ktera nejen mechanicky patri davno do srotu, dam nove senzory a novy SW, ze budu mit super stroj 4.0 . Vetsinou je resenim problemu nejen novy stroj, ale i jina technologie, modernejsi infrastruktura a vetsinou i nutnost postavit novou fabriku ;-) Muj zaver je predevsim v tom, ze prumysl 4.0 ma smysl predevsim u projektovani novych technologickych celku. Tam nove mysleni muze prinest nove vyhody a chytra reseni. Roubovani na stare technologie vetsinou prinasi jen vyssi naklady.

Ne vždy házejme vinu na programátory. Programátor má být na řetězu a má dostat jasné zadání, co má naprogramovat, jak se to má chovat.
To zadání si ale nemá dělat sám, jak se mu zlíbí nebo jak by se mu to dobře udělalo. Jestli je chyba v uživatelském komfortu, má nastoupit designér na UX, který se s tím vymazlí, navrhne, otestuje to, nahodí to designerovi, který tomu dodá vzhled a to se pak má dodat programátorovi, který to zprovozní.

Programátor by opravdu neměl navrhovat věci, ještě se mi nestalo, aby to, co navrhl programátor bylo hezké, nebo nedejbože i funkčně použitelné!

Nojo, ale kdo má furt vyvíjet a stavět ta IOT automatizovaná výčepní zařízení?!?

Spíš bych řekl, že IoT se snaží nacpat chytrý ledničky do domácnosti, P4.0 chytrý šroubováky do firmy. Obojí je to stejná kravina - kde je totiž konektivita cenově dostupná a přínos (z pohledu individuálního měřítka zákazníka) vyváží náklady, tak už to tam dávno je.

Na ostatní místa, kde to moc nedává smysl, se to snaží výrobci nacpat za každou cenu (třeba vytvořením módního trendu a označením těch, co to nemají, za outsidery).

Z vlastní zkušenosti vím, že programátoři kolikrát vidí, že je něco špatně. Ale stydí se na to zeptat (aby neztratili punc experta). A ta arogance a odmítání je pak zcela normální obranný mechanismus. Oni ví, že je to špatně, ale prostě to nesmí přiznat. Jejich zaměstnavatel přece dodal špičkovou kvalitu za prémiovou cenu, tak teď nemůže někdo přiznat, že tam něco nebylo na 100%, ne?

Ale co, můžeme si za to sami. V dnešní době každý od každého čeká bezchybnost a neomylnost. Ale člověk je tvor chybující, takže z toho vyleze leda chybovost a neochota chybu přiznat. Upřímnost se dnes trestá a chyba není vnímána jako příležitost k nápravě, ale jako šance vysoudit penále.

A na základě čeho se dělají odhady ceny a termínů? "Bude upřesněno později" ve smlouvě je bianco šek a zákazník si na něho napíše, co jako dodavatel snesete. A někdy i víc a ještě si napočítá penále.

Moje osobní zkušenost asi 25 let stará. Dělali jsem pro firmu automatizaci řízení výroby, tenkrát na "zastaralých a neintuitivních" znakových terminálech. Firma ale chtěla být moderní, tak pořídila místo terminálů PCčka s Win 3.11. No, a zaměstnanci se pak na těch "uživatelsky přívětivých, intutivních a jednoduchých" woknách učili týden spustit si myší emulátor terminálu, aby se pak se tu naši "ošklivou a neintutivní znakovou" aplikaci naučili ovládat za den.

Ale jo, lišilo se to. Najděte si nějaké návody na Turbo Vision, Java AWT atd. Typicky tehdejší problém byl "jak ty komponenty uspořádat na obrazovce tak, jak potřebuji".

Dnes se v návodech dočtete o tom, jak vytvoříte Model, Controler a pak jak vám z toho "systém" sám vygeneruje View. Že je to view úplně naprd, protože je udělané podle modelu a ne podle logiky vyplňování, se obchází leda tak tím, že má uživatel možnost si sloupečky popřetahovat. Dnešní frameworky zkrátka za programátora samy udělají práci, kterou dříve dělal programátor s designérem. A neudělají ji zdaleka tak dobře.

Pijavicův zákon: "Když něco uděláš blbě, nech si zaplatit za projekt, který to částečně opraví"

pan autor a vy jste taky pracovali na poště?

Ono je to obvykle z prostředka - od lidí, co ještě mají potřebu, ale už mají i prostředky. Ti dole mají potřebu ale ne prostředky. A ti nahoře mají sice prostředky, ale ne potřebu. Jen občas se stane, že to přijde od těch nahoře - když jim to dodavatel dobře vychválí (ušetří to peníze, pokosí konkurenci apod.) a vzbudí tak potřebu.

Pravidlo obchodníků s ERP systémy: cílit na výrobní ředitele, vedoucí skladu, vedoucího účetního oddělení atd.

Staré, ale furt platné:
www.loupak.fun/video/srandicky/19281-expert-ve-firme
V tom odkazu je to označené jako "srandičky". Ale mnohdy je to tvrdá realita:-(
Proč by se soudruzi magoři ...eee manageři měli radit s obyčejnými programátory a techniky? Vždyť oni z titulu svých funkcí vědí všechno nejlíp, Akorát ti programátoři a technici jim a jejich geniálním nápadům házejí klacky pod nohy.

Moje první grafické GUI bylo v podstatě vektorový obrázek vygenerovaný Javou, citlivý na polohu kliknutí myši. Všechno se tam dělalo "ručně" (rozhodnutí, ve kterém grafickém prvku je kliknutí). Byla to "práce pro vraha", nicméně např. odkliknutí na novou obrazovku (nebo skončení zadávání) a ukončení programu nebyly těsně vedle sebe (jak je v současnosti běžné), ale v protilehlých rozích. Měl jsem ošetřen i návrat k předchozímu stavu pro případ "ukliknutí se".

Všechna ostatní GUI, která jsem kdy viděl, byť byla dělána ze standardních ovládacích prvků (nebo právě proto) jsou shity, s nimiž se pracuje mnohem hůř a je u nich dost vysoké riziko zničení delší práce kliknutím kousek vedle.

Stal jsem se programátorem, protože dodaný software byl sice funkční ale pro trvalou práci nepoužitelný. Jakékoliv připomínky byly jen házením hrachu na zeď a arogance programátorů maximální. Takže nouze naučila Dalibora housti. Vyrobil jsem už toho dost, ale nikdy jsem se nepouštěl do věcí, kterým bych nerozuměl. I dobrá procesní analýza nestačí. Při programování se přijde na hodně dobrých věcí, které v zadání nemusí být. Kdyby programátorským výtvorům rozuměl i jejich pes, hned by byl život pro uživatele snazší. A to je hlavní pointa článku.

Ale lze - viz Odoo

Ovšem, ale ten návrh by měl být taky proveditelný za rozumného úsilí. Některé nápady mohou znamenat překopání celé aplikace.

Tak efektivnější bude paměťový implantát. Ale takhle se bude uvažovat za 10 let.

Problém je v tom, že před 20ti lety bylo vše jednodušší - a podobný sw se dal udělat jako one man show - právě proto že to bylo jednoduché, prakticky neexistovalo GUI atd. Neřešilo se UX, neřešily se mobily, neřešilo se sto dalších věcí. Dnes to takhle dělat nejde.

to píšeš jen protože jsi v té době neprogramoval :). Podle odpovědi směřuješ k vývoji webu/mobilních aplikací, ať se tam poslední dobou vše přesouvá, pořád je SW vývoj daleko širší téma.

Dříve nebyly tak univerzální grafické frameworky, GUI se muselo dělat, ale člověk to dělal hodně od nuly. Návrhům UI se věnovalo daleko více prostoru (z osobní zkušenosti), one man show to mohla být kvůli tomu, že programátor neměl na dokončení dva měsíce, ale dva roky.

Ano, i tato mentalita je součástí problému. Jestliže je ve vývojářském týmu někdo, kdo má pocit že nedělá analýzu a design, že jen plní zadání, bylo by asi lepší nahradit ho co nejdříve automatem.