Vlákno názorů k článku Senzory Martina Malého: O smutném vývojáři, který celý den kontroluje, jestli bliká LEDka od thr - A vážně bude to kvalitní spolehlivé automatizované testovací...

Korporace jsou dobré na to, aby perspektivní nápady převzaly od menších firem a dotáhly je do konce, právě s ohledem na náklady a zajistili jejich optimální reprodukci.

No tak zrovna hlídání blikající LEDky za odpoledne hotové bude. Jinak ale neschopnost realistického ohodnocení časové náročnosti je poměrně běžná na obou stranách - u techniků i u managementu.

Před časem jsem měl zajímavý případ: bylo potřeba cosi naprogramovat do jedné aplikace. Ta část byla zralá na nějaký menší refactoring řekněme zvíci dvou dnů. Po něm by doprogramování trvalo plus minus tři dny. Nebo se dal refactoring odsunout a dalo se to naprogramovat za pět až sedm dnů.
Dohlížející manager tomu nerozuměl, nenechal si to vysvětlit a trval na tom, že se musí dělat právě a jen na té nové funkci, protože takové měl zadání shora. Dopadlo to tak, že vývojáři se na něj vykašlali a za těch celkových pět dnů to udělali i s refactoringem. Zdánlivě happy end, jenže na druhé straně ignorování managementu v projektech, které nejsou one-man-show, taky asi není to pravé ořechové.

Na jedno odpoledne není nikdy nic. Ale zase, kdyby si člověk myslel, že to nebude na jedno odpoledne, tak by do toho nešel.

Ono taky jde o to, jestli ušetřit práci sobě nebo někomu jinému :-D

Tak pravdou bývá, že všechno vypadá jednoduše, než se to začne dělat. Teprve při jakémsi rozpracování se projeví skutečná hloubka problému. Osobně mám odpozorován násobící koeficient 5.

V siemensu jsem to hodil stazistovi/bri­gadnikovi. Muj plat byl nekde jinde a firma resenim, ktere nelze reusnout pro jine reseni neziska nic. Uz jen ze by to nekdo musel vzit a nastudovat je slozitejsi nez to dat nekomu kdo stoji daleko min nez cas ktery bych na tom tenkrat stravil ja.
Ono je to pekne kdyz si doma clovek bastli a zkousi, ale pokud mu za krkem dycha manazer ktery drzi v jedne ruce kolejnici a v druhe pantograf, tak to neni zrovna "atmosfera na hrani".

A pak zapli v menirne napajeni trakce...;)

Za odpoledne bych to mel ve sve firme. Ale ted nepodnikam, jsem v korporatu za slusne penize. A tam to neni o arduinu a fotodiodou. To se musi zdokumentovat podle ISO, testovat to musi nekdo jiny, program musi byt verzovan a musi byt zdokumentovat, atd. V korporatu i trivialita zabere tyden. Vse anglicky a tak aby to pochopil i Cinan v nasi pobocce v Cine nebo Argentinec. Na vsechno mame milion papiru a formularu. Agilne vyvijime :-)

Za ten den bude schéma přípravku, seznam součástek a schválení přímýho nadřízenýho. Když dobře, tak odeslaný požadavek na logistiku. Druhý den, když dobře, to logistika objedná, třetí den dojde balíček od Farnella, ale baba na logistice má dovolenou, takže za dva týdny je fotoodpor na stole a může se začít bastlit...

Tady ale řešíme, kolik čistého času na tom zaměstnanec umlátí, ne za jak dlouho to bude k použití.

Zákazník má dostat prototyp za týden. Test je o tom sledovat 12 hodin LEDku (nejde urychlit, stejný by byl i s přípravkem). Vyrobit přípravek v čistým čase by trvalo 12 hodin.
- Je rozumný si s tím 12 hodin hrát, aby se to pak 12 hodin testovalo samo a člověk mohl dělat něco rozumnějšího?
- Pokud jo, bude mít zákazník pochopení pro to, že se testovat začne až dva dny po termínu předání (protože schvalování a logistika)?
- Pokud by se i tak termín stihl, jak vysvětlit šéfovi, že týden sedí a čeká?
- Pokud to během čekání otestuje, jak okecá výrobu něčeho, co už není potřeba?

(Osobně jsem to řešil jako "ladění a prototypování produkčního testeru" s tím, že se něco ve fabrice opravdu použilo)

Jo? Dělal jsem v korporaci šest let. Fajn bylo třeba když veškerá dokumentace k projektu byla formou poznámek ve zdrojáku a ještě ve francouzštině a návod k použití...

Občas se setkáte i s dokumentací ve formě lidové slovesnosti, která se ve firmě předává už málem mezi generacemi. Zásadně nemá psanou formu. Je třeba si rozprávět s kolegy napříč kontinenty tak jako naši předkové si vyprávěli s potulnými tovaryši při draní peří.
Takový dýchánek je ovšem třeba uspořádat přesně dle interních směrnic a bezpečnostních zásad.

Ano, to jsem zažil. V oné firmě se znalosti nezapisovaly, tam se tradovaly.

Také jsem to zažil. I jsem jich pak část zapsal, ale následně raději zatajil. Protože jedna věc je "slyšel jsem, že" a druhá věc je "v dokumentu, co jsem napsal, tvrdím že". Ono se totiž tradovalo plno blbostí :-( A pár si jich člověk přimyslel, když něco špatně pochopil (tichá pošta?) Má kouzelná fráze byla "My observation is ..."

Docela chápu, že u téhle lidové slovesnosti nebývá odvaha to zpětně sepsat. A také vím, že do svých poznámek si to lidé píšou. Ale o tom nikomu neříkejte! :-)

Proto prosazují standartni / standardizaci terminologii a ostré se vyhrazuji pro krcmarove a kakademicke lobby na rootu za české paskvily. Protože vím jak to dopadá ve více jazycích vcetne čínštiny a japonstiny. Právě tak jak popisujes. V případě nestandartni terminologie v docce mít glossary.jako co je to sezení, jižní můstek, předběžne konání instrukcí nebo "kdyz"... znáte z hloupých vs skript...

Tak tak. V technice, pokud se něco dokumentuje, tak slova mají jasně daný význam. Když se člověk podívá do třeba do popisu komunikačního standardu, tak tam má popsány i významy may, must, should... Na začátku projektu se dokonce sepisuje doménový slovník, aby člověk použil korektní výraz místo "kulatý tentononc" a předešlo se nedorozuměním. A ten pak bývá někde na začátku produktové specifikace. Protože sestavit takový slovník a používat korektní výrazy je
1) levnější, než řešit nedorozumění
2) člověk si na termíny ze slovníku zvykne a nemusí přemýšlet, co tím ten druhý myslel
3) takto sepsanou dokumentací se dá zabít právník zákazníka, když má blbý kecy, že to mělo být jinak.

K prvnímu odstavci: jde o spolehlivost. Zlepšovákům se meze nekladou, ale když se stane průser, tak je to zlé. Například se zjistí, že už to pár týdnů nepočítá a nikdo to neumí opravit. Případně že to blbne a ukazuje to čísla o chlup jiná, než by mělo - co s tím, akceptovat chybu? Opravit? Vyhodit...

K druhému odstavci: chybějící dokumentace je věc běžná. Korporace ji chtějí, ale to se jim buď vysvětlí, že na to teď není čas, nebo se jim tvrdí, že dokumentace je. Pak ji nový člověk potřebuje a zjistí, že buď není vůbec, nebo sice je, ale přes tisíce stránek obsahu v ní nic není. Častější je to u malých týmů a prakticky sázkou na jistotu je to u agilních týmů. Agilní metody totiž umožňují to, aby se z toho člověk nezbláznil a udržel si v tom přehled. Jenže dokud v tom má daný člověk přehled, tak je nulový tlak na pořizování dokumentace. To pak narazíte na nedokumentovanou vlastnost, polovina lidí z doby, kdy se to implementovalo, tam už není, a ta druhá polovina si po těch letech nevzpomene proč to tak je (respektive si každý vzpomene, ale každý nějak jinak a neshodnou se). To se vážně někomu nestalo, že by si na standup meetingu chtěl dělat poznámky a dostal za to akorát vynadáno, ať nezdržuje? A to jsem potkal i pár jedinců, kteří nedokumentovali už z principu - chtěli mít know how, kvůli kterému by byli pro firmu nepostradatelní.

Tak tak, korporace dokumentaci chce. Ale lidi jsou líní ji sepsat a manažerům se zdá, že to zdržuje projekt.

Měl jsem jeden čas projekťáka, co záměrně podstřeloval čas projektů a dokumentaci, která byla vyžadovaná, pak řešil tak, že se do systému nahrály za dopoledne prázdný šablony a udělala se fajfka do checklistu, že tam ten dokument je. Pak chtěl člověk za rok použít testovací přípravek, ze kterýho trčelo pět drátů a tři hodiny otravoval ostatní - zjistit autora, zjistit od autora zapojení a jaký napětí použít pro napájení,... V lepším případě, v horším reverse engineering, protože autor odešel/zemřel/byl přeložen jinam.

Empiricky mám zjištěno, že hodina psaní dokumentace ušetřila asi 5h práce v budoucnu.

Hezký povídání na toto téma: https://www.zdrojak.cz/clanky/technicky-dluh/

Kdysi po mně šéf chtěl vědět, jak se dokumentuje a archivuje výroba jistých komponent pro jaderné elektrárny. Ta výroba už běžela nějakou dobu, ti co to zařizovali už dávno ve firmě nebyli a žádný předpis co by se toho týkal jsem nenašel a to se firma honosila a snad dosud honosí vlastnictvím certifikátu ISO 9000.
http://www.mmspektrum.com/clanek/normy-rady-iso-9000-prinos-nebo-hrozba.html
Tak jsem vzal tužku, notes, prošel jsem výrobou, vyptal a zapsal jsem, co a jak sledují, kam to všude píší a kde se to pak silážuje, dal jsem tomu štábní kulturu a šéfovi jsem to předložil. Pak se už nic nedělo.
Když šéf zahnul kramle a my jsme po něm rovnali kancelář, našel jsem emajl jak komusi psal, jestli by nezdokumentoval tu výrobu, že já jsem to udělal moc pečlivě.

Šéf měl rozum, kdyby se něco stalo, tak by vás u soudu podle té vaší dokumentace upekli za živa, protože by se jistě našlo něco, co by jí neodpovídalo.

Někdy dokumentace nechybí, ale je zastaralá. Žádná firma nedokáže zajistit, aby dokumentace odpovídala aktuálnímu stavu.

Možná se tomu blíží metoda TDD, kdy samotný test je automaticky i dokumentací správného použití.

Se strašně divím, že ani autora, ani nikoho jiného nenapadlo připojit drátek k patici té LEDky a nemuselo by se vůlbec fušovat s fotorezistorem.

Treba to neni mozne. Napriklad pokud slo o test stability proti EMC ruseni.

Ještě jednodušší by bylo, pověsit logovani na tu funkci, která přímo obsluhuje blikani ledkou. I když bez znalosti konkrétního případu je to možná příliš idealisticky představa.