All posts by John

Vsichni kdo investovali poslednich 7 let jsou genialni investori

V podstate kazdy kdo investoval do akcii nebo nemovitosti poslednich 7 let tak ma krasne vysledky.

Je relativne jedno jakou zvolil strategii. Nekdo investoval do bytu. Jiny do garazi. Dalsi do skladu. Nekdo si vybiral akcie s velkou dividendou. Nebo v urcitych odvetvi. Vsichni si peclive promysleli sve strategie. Zvazovali kde a co koupit.

Ted se divaji na plody sve prace a zjistuji, ze jsou genialnimi investory. Vidi krasnou navratnost. Vidi jak stouply ceny. Vsechny ty jejich teorie se ukazaly jako pravdive v praxi. Nejvice se me na tom libi to, ze naproste vetsine to vyslo at uz si zvolili strategii jakoukoliv.

Sam to vidim na sobe. Treba jedno portfolio akcii jsem si naklikal na zachode na mem ipadu behem let 2015-2016. Nejak me v te dobe chytlo, ze bych mohl neco zainvestovat do akcii. A ty nakupy jsem delal jen kdyz jsem sedel rano na zachode. Dnes se divam na vysledky me prace. Cele portfolio je +100%! Strategie vysla!

Rikam to s nadsazkou. Delam si legraci. Ta pointa je, ze to neni zasluha geniality investoru, ale to ze cely trh sel nahoru. A to zakrylo i ruzna chybna rozhodnuti. Ve finale to pak vypada, ze clovek nemuze udelat nic spatne. Krasne se dari. V nemovitostech to fungovalo podobne. Presne tu stejnou situaci jsem zazil pred krizi v roce 2008. Znovu bylo spousta vitezu at uz sazeli na cokoliv.

Tyhle obdobi kdy stoupa trh jsou krasna obdobi optimismu. Vzpominam na minule udalosti. Kdyz takto stoupali akcie v dot com bubline. Nebo nemovitosti pred financni krizi.

Klidne se muze stat, ze vse jeste poroste nejakou dobu. Cim vice se budou snizovat urokove sazby a pujde se i do tech negativnich, tak verim, ze rust bude pokracovat. Ale vecne to trvat nemuze. Proto bych byl velmi opatrny a obezretny. A minuly uspech bych nezamenoval za novou realitu.

Rad nakupuji. Nerad prodavam.

Mam dve nabidky na prodej meho maleho retail centra. Chtel jsem se toho zbavit. Nezapada do me strategie. Investuji hlavne do skladu a retail je proste neco jineho. Chova se to jinak. Jina pravidla.

Tohle beru, ze je naprosto normalni. Kazdy realitni investor k necemu tihne. Nekdo ma rad residential. Nekdo ma rad retail. Nekdo sklady (industrial). Vetsinou to je podle toho s cim ma jak stesti. Pak si na to zvykne. Zna presne jak se delaji smlouvy. Jak co zorganizovat, jak najit najemniky a pak kvuli tomu zustava u toho sveho zamereni.

Moje zamereni jsou sklady a fakt je mam moc rad jako investici. Takze jsem si rikal, ze kdyz se objevi dobra nabidka na prodej tak ten muj retail prodam.

Nabidka se objevila. Delali jsme dneska inspekci a uplne jsem zacal hazet v hlave brzdu. Pocitove jsem mel pocit, ze me ten muj oblibeny najemnik zas tak nevadi. Kdyz me tak videl osobne tak me  trikrat po sobe pozval, ze mi neco chce uvarit k jidlu. Jestli nemam hlad. Byl proste moc hodny a pohostinny. Dokonce si uz zpravil tu klimatizaci na vlastni naklady. Rikal mi Johne, ja se prece o vse postaram! Nemusis mit starosti! Proste paradni najemnik, ze? Taky si rikam, ze jsem mu krivdil. Misto toho abych ho nutil mi platit bankou jsem si mel kazdy mesic chodit pro hotovost a byli by vsichni spokojeni. Tohle chtel a me se nechtelo, protoze nemam cas nekam chodit.

Tak jsem sam zvedavy jak to ted dopadne. Rozumove bych mel retail prodat. Citove se mi nechce uz tolik prodavat. Vynos tam je 6%. Dalsi velka vyhoda s vyznamnymi odpisy (usetrim na danich). Mit penize v bance taky neni moc vyhra (uroky jsou male a jdou zase dolu). Tak to cele zvazuji.

Prvni osobni setkani s negativnimi uroky

Vcera jsem se poprve osobne setkal s negativnimi urokovymi sazbami v praxi. Ne tak, ze bych cetl nejaky clanek v novinach. Ale osobne.

Delam sem tam obchodni transakce v ceskych korunach. A nechci zbytecne prevadet  koruny na dolary a zpet. Mit ucet v CR neni pro me uplne trivialni. Nevim jestli se uz situace zmenila, ale kdyz jsem nemel cesky mobil, tak bylo nemozne provadet ruzne ukony (nebylo kam poslat overovaci SMS a americke telefony to nebralo). Taky nemam rad byrokracii a v USA bohuzel plati pravidlo, ze kazdy zahranicni ucet se musi nahlasovat a kazdy rok posilat formular FBAR. (Ten FBAR pozadavek plati i pro residenty, takze i kdyz jste tady dlouhodobe na viza, tak se to na vas vztahuje.)

Mam dobre vztahy se Citibank tak jsem je pozadal jestli pro me nemuzou ucet v korunach udelat primo v USA. Nemusel bych posilat FBR. Citibank ma i pobocku v CR tak jsem si rikal, ze by snad nejak mohlo jit.

Vcera mi volali, ze by to slo, ale ucet bude mit negativni urokovou sazbu -2%!

Doopravdy me ty negativni urokove miry desi. Kdyz bankeri nevi co delat s penezmi, ze musi uctovat negativni uroky.

Doufam, ze se tento trend nerozsiri jeste vice. Nejenom ze vam z penez v hotovosti ukrajuje zhruba 3% inflace, tak jeste banky budou uctovat urok za to, ze vam ty penize drzi.

Ta politika nizkych uroku pro umele udrzvoani konjukturniho cyklu je nejvetsim duvodem pro rostouci ekonomicke nerovnosti.

Nizke uroky nebo nedejboze negativni budou znamenat, ze aktiva jako nemovitosti, akcie a zlato budou stale stoupat. Proste kam jinam dat penize? Treba dnes vaham koupit komercni nemovitost, ktera vydelava jen 4%. Je to pro me moc maly vynos. Ale kdyby mi banka zacala uctovat 2% za drzeni hotovosti, tak tu nemovitost s 4% vynosnostni okamzite koupim. Podobne bude uvazovat vice lidi a ceny zase pujdou nahoru. Lidi co nemovitosti (nebo jina aktiva) uz ted vlastni budou nejvetsi benefaktori. Lidi, kterym se nikdy nepodarilo nasetrit na downpayment na tu prvni nemovitost uz na ni nikdy nenasetri (kdyz jim banka bude uctovat negativni uroky). Tohle doopravdy nespeje k nicemu dobremu.

Najemnik chce ode mne kupovat nemovitost

Muj nejzabavnejsi najemnik co ma velky problem platit najem vcas (vzdycky tam je nejaky problem za ktery nemuze,  treba ze banka nechce vzit jeho penize) mi posilal SMSky:

Johne, mam zajem koupit celou budovu. Potrebuji s tebou nutne mluvit. Hned mi zavolej jak muzes. Johne, kolik chces za tu budovu? Johne bud ferovy!

Nemel jsem moc chut na to reagovat. Proste neverim, ze nejake penize vubec da dohromady. Treba uz podle toho jak jezdi autem ktere ma kompletne sjete pneumatiky (doopravdy tam nema vubec zadny vzorek). Tak jsem nechtel ztracet nejaky cas diskuzemi co je ferova cena.

Za tyden napsal znovu: “Johne, rozbila se klimatizace. Vyhorel motor.”

Jen pro ctenare, to je klimatizace, kterou nechal bezet asi mesic naplno, v prazdnem prostoru, ze se udelal na strese obrovsky balvan ledu.

Dale psal: “Mam to nechat spravit a rovnou ti poslat ucet? Nebo to zaridis a zaplatis ty?”

Ja odepisuji: “Muzu to nechat spravit mym opravarem nebo to zarid ty. Ale v obou pripadech jsi za tu cenu opravy odpovedny podle nasi smlouvy”. To zustalo uz bez odpovedi.

🙂

Guest post: Kvalitář? Review? Řízení rizik? – k ničemu, softwarové projekty jen zdražují a zdržují. A nebo ne?

Dobrý den Johne, přátelé

rád bych využil možnosti zareagoval na články, kterými u tebe Zsolt Szabo nedávno otevřel téma vývoje softwaru.

Po pravdě, s články nejsem moc spokojený.

Začnu od konce, respektive od Zsoltova prvního článku. Ještě předtím bych ale rád varoval všechny programátory a vývojáře – dál nečtěte. Riskujete zvýšený krevní tlak a možná i pocit ukřivděnosti. 🙂

Zsolt rozebral možnosti vývoje web aplikace a vytvořil krásný rozhodovací strom. Jeho zásadní nevýhodou je však to, že i přes Zsoltovu snahu nebere v potaz realitu většiny podnikatelů, tedy lidí bez jakýchkoli znalostí o vývoji softwaru.

Většina programátorů apriori předpokládá, že všichni podnikatelé tuší, co software je, co všechno (a proč) obsahuje i jak vzniká.

Lidé, na které Zsoltův článek míří, však podle mě nemají žádnou potřebu tomu rozumět. Nepotřebují a nechtějí vědět, co je frontend a backend. Vůbec je nezajímá, jak se objeví(?) funkčnost, kterou vyžadují.

Pro podnikatele jsou důležité jiné věci – aby bylo hotovo co nejdříve a nejlevněji, aby software dělal to, co má, kdy a kde má a aby vypadal podle jejich představ. A to je kámen úrazu.

Další článek zametl s celou problematikou proč je něco vyvinuté pozdě jen tvrzením, že podnikatelé jsou příliš optimističtí a že nebyl správně definovaný rozsah. Škoda, že nezmínil, že existují spousty přístupů a metodik, jak se přesně tomuhle vyhnout.

Abych si přihřál polívčičku, tohle přesně je práce projekťáka u dodavatele a quality managera na straně objednatele. A není to vážně tak triviální. (Tedy, pokud se nesmíříte s pseudo-agile přístupem, kdy prostě platíte programátora, dokud to nevypadá, jak chcete. A on přepisuje tam a zpátky podle toho, jak pískáte. To ale v realitě skončí spokojeností málokdy.)

Vývoj softwaru totiž není hladká cestička a obsahuje spoustu odboček, na které zadavatel nemyslí a jejichž opomenutí se připomene mnohem později a za mnohem více peněz, než kdyby se tyto problémy řešily včas.

V zásadě jste zcela vydáni na milost a nemilost dodavateli, spoléháte na jeho profesionalitu a doufáte, že se nenechá přemluvit k šetření na nesprávných místech. A to je kámen úrazu, protože z principu dodavatel chce jen vydělat a všechny tyhle metodiky a přístupy ukusují z rozpočtu a z jeho zisku. A kdo si na sebe chce dobrovolně ušít bič profesionálního dohledu, že?

Horší je, když má podnikatel pocit, že vývoji softwaru rozumí, protože už jeden projekt v praxi viděl, ve firmě spustili webové stránky vytvořené v ekosystému WordPress, či se dokonce kdysi na škole učil programovat. Takový podnikatel má představu, že už vše viděl a když bude projekt řídit jako svoji firmu, tak vše ohlídá, bude to včas a skoro zadarmo. Z jeho pohledu dodavatelé všechno jen zbytečně komplikují.

Takový projekt obvykle končí totální katastrofou. Obzvlášť když je dodavatelem kodér (úmyslně neříkám programátor nebo developer) bez znalosti projektového řízení (a co hůř, s představou, že to v žádném případě nepotřebuje), nemůže to dopadnout jinak než nespokojeností obou zúčastněných stran.

A tím bych ukončil obecné povídání. John mě požádal, abych se podělil o skutečné příběhy katastrof, jichž jsem byl svědkem za 18 let, co tohle dělám.

Jednotlivé příběhy jsem musel kvůli NDA anonymizovat, ale pokud se v tom poznáte, tak je to čistě shoda náhod. 🙂

Moje práce bohužel není vidět. Když ji dělám pořádně, od začátku projektu, tak vlastně projekt běží hladce a rizika, o kterých mluvím, nikdy nenastanou, takže jsem “zbytečný”.
Problémy, kterým zabráním, z definice nenastanou.

Takže zábavné jsou samozřejmě ty ostatní historky.

Příběh první: Pohřbená multikára aneb “To není potřeba testovat, vždyť to běhá u desítek zákazníků roky”

Kdybych dostal stovku pokaždé, když slyším “to je ověřený kód, to nám běhá v x zařízeních roky”, byl bych na tom jako John. Bohužel, tenhle argument je naprosto neplatný. Jediné, co to znamená je, že se chyba ještě neprojevila.

Chci to ukázat na následujícím případu – software, velmi jednoduchý, v zásadě jen řídil dávkovač písku v lomu.

Dovedete si představit stav, ve kterém dorazil nebohý majitel firmy ráno do práce, když mu ve 3 hodiny ráno zavolali z kamenolomu, že jeho software namísto 1 kubíku nasypal 9 a jen díky tomu, že šel řidič na cigáro a množství zadával z vnějšku kabiny, nemusí řešit smrťák?

Ano, software fungoval skvěle, jen prostě proměnná “kolik” nebyla (tentokrát?) binárně “0001” ale “1010” (tedy 9). Díky intenzivnímu zkoumání jsme nakonec našli problém.

Programátor šetřil pamětí a využil zbytek registru na počítadlo doby od restartu. No a po uplynutí “1111 1111 1111 ” hodin (tedy 4095 hodin decimálně, neboli 170 dní) bez restartu přeteklo počítadlo o paměťovou buňku vedle.

Tato řídicí jednotka běžela minimálně 6 let v provozu, než chyba nastala, a stejných cca 80 jednotek je roztroušeno po Evropě.

Argument “roky nám to funguje” prostě není a nikdy nebude platný. Pravděpodobně si říkáte, že tato chyba měla být nalezena při testování. Bohužel, takový test, který by odhalil všechny možné chyby tohoto druhu, lze napsat snad jen pro družici (psal jsem to), ale pro 80 jednotek do lomu je to totální overkill.

Šlo tomu tedy předejít testováním? Ne.

Šlo tomu předejít jinak? Samozřejmě že ano. Stačilo nastavit správně coding standard (standard pro kódování = jak co psát, jaké konstrukty používat a jaké ne) a udělat jednoduchou revizi kódu druhým programátorem.

Jenže to stojí trochu času a navíc je to “zbytečná práce”.

A moje zbytečná práce je nutit ostatní dělat tyhle zbytečné práce. Nakonec pak většinou ale nepohřbíme náklaďák pod hromadou písku.

Příběh druhý: “Kolik stojí jeden vadný bit”
Když jsme mluvili o testování, vždycky je otázka, kolik do testování chceme investovat a proč. To řeší docela složitý proces řízení rizik. (Opět PM/QM práce.)

Ale není to vlastně zbytečné? Navíc testování je “drahé a neproduktivní”, Ne?

A proč vlastně tohle píšu? Neb příběh, kolik stojí jeden bit.

Představte si sériovou produkci kde výsledkem je ECU včetně softwaru. Na každém kusu, který linka vyrobí, firma vydělá 5 Euro. Měsíčně jich linka vyrobí 200 000.

Bavíme se o jedné z asi 50 řídicích jednotek, které má moderní auto napojené na sběrnice. Tedy vážný vývoj, ne jako v předchozím příběhu, který byl v zásadě o prototypové výrobě.

Software v jednotce měl jít aktualizovat při servisu. Bohužel, programátor, který software psal ho do jednotky nahrával jen přes testovací stanici. Žádný z testů probíhajících v emulovaném prostředí nebyl schopen odhalit, že vlastně přes sběrnici nahrát nejde, a to kvůli jednomu přeplému bitu.

Nechci se bavit o tom jak a zda mohla být tahle chyba odhalena, jen vám chci ukázat jaké důsledky mohou nastat z byznysové stránky a o čem jako kvalitář taky uvažuju.

Jednotka stojí 10 EUR, zisk je na ní 5 EUR. Jediné řešení je ji při servisu prostě nahradit. Za to si servis účtuje cca 100 EUR navíc za práci (a 5 EUR za novou jednotku je náš náklad).

Jednotek s touto vadou bylo vyrobeno 350 000 (linka jela skoro dva měsíce).
Takže jeden vadný bit stál zhruba 36 milionů EUR.

Možná by byl lepší nápad zaplatit víc testerů a kvalitářů, a smířit se s tím že vývoj bude o půlku delší, že?

Příběh třetí: “Ty papíry nepotřebuju, hlavně ať to rychle jezdí”

Znáte ten pocit, když zákazník nemá vždy pravdu? Když chce nesmysl? To se ještě dá překousnout. Problém je, když Vám tvrdí něco jiného, než co má ve smlouvě.

Ve smlouvě na rekonstrukci tramvaje byla schovaná noticka, “a vývoj proběhne dle BOSTRAB”.

Nikdo z obchodu si s ní nedělal starosti, vývojáři se snažili aby tramvaj fungovala jak má, zákazník nás popoháněl.

“Dokumentace? Analýzy? Zkoušky? To já nepotřebuju.” i to je Vám schopen zákazník oficiálně oznámit.

Bohužel, když byl prototyp hotov, tak zákazník prohlásil: “Za 14 dní máte termín, kdy budete řešení obhajovat na drážním úřadě jako změnu na schváleném typu”. Což je právě to, co BOSTRAB řeší.

A tehdy začalo půlroční peklo dopisování dokumentace, zpětné vytváření analýz a, upřímně, i falšování záznamů o věcech, co s funkčním prototypem už nejdou dělat.

Ano, zákazník nic nepotřeboval, ale drážní úřad ano. A firma to celou dobu měla ve smlouvě.

Požadavky na vývoj podle něčeho, případně doložit zkouškou, má obrovské dopady na to, co musíte a jak to musíte udělat.

SW kvalita je tady právě kvůli adekvátní analýze problému a ušetření obdobných krizí.

Příběh ćtvrtý: “Analýzu rizik udělejte až zpětně, je to jen plýtvání časem”
Jednotlivé kroky výrobního procesu mají svůj čas a místo. Když je chcete dodělávat zpětně, stává se z nich jen formalismus, který nic nepřináší. Přinejhorším pak musíte všechno zpětně předělat. A to je drahé.

Typickým případem je analýza rizik na designu (FMEDA).

V metru jsou dveře, které se otevírají na povel z nadřazeného systému. Otevírá je motor, který zná polohu dveří, ale tu si ve skutečnosti jen dopočítává jeho řídicí jednotka na základě povelů do motoru.
Ve dveřích je senzor (kontakt), který detekuje, jestli jsou dveře zavřené a nebo ne.

Pokud děláte analýzu rizik zpětně, můžete se dostat do následující situace.

Nad dveřmi jsou dvě řídicí jednotky připojené na dvě nezávislé sběrnice, které řeší spoustu věcí v segmentu vozu, kromě ovládání dveří. Je potřeba z nich vyvést kabely pro čtení senzoru a pro ovládání motoru.

Projektant (navrhuje kabeláž, úchyty, prostě mechaniku) vám klidně zavede obojí do jedné jednotky. Elektrický návrhář s tím nemá problém. Programátor do ní v pohodě napíše logiku ovládání i logiku detekce zavření.

Nikdo neudělal nic špatně, všichni udělali svou práci jak měli. Vše funguje.

Ale je tu obrovský bezpečnostní problém. Ano, a to je právě obor FMEDA – detekovat problémy a řešit je změnou v návrhu.

Pokud tato jednotka selže, naprosto nevíte, jestli jsou dveře zavřené nebo otevřené. (A pokud selže pořádně, ani nevíte že selhala a myslíte si, že víte v jakém jsou stavu.)

A pak se metro rozjede s otevřenýma dveřma…

Řešení je strašně jednoduché, stačí mít ovládání v jedné a detekci v druhé jednotce (která tam tak jako tak je).

Malá změna v kabelovém svazku a přesun kódu z jedné jednotky do druhé.

Ve fázi vývoje je to práce možna na 2 hodiny s nulovými náklady.

Když ale máte ve výrobě zadané všechny přípravky a všechny kabelové svazky, tak se jedná o změnu za stovky tisíc v nákladech.

A to vážně nechcete.

Jo, není nad to dodělávat ty “papíry” zpětně, hlavně ať nám jede výroba.

Příběh pátý: “Vždyť je to jen beta verze a nikdo ji nenajde”

Bezpečnost informací
– řešíte to vůbec? Co vás možná zajímá jsou zkratky jako GDPR, ISO27000….
Ale vážně chápete příčiny?

Byla jedna firma v hyperkonkurenčním prostředí. Ta si nechávala vyvíjet svůj nový e-shop a jako obvykle, nechala vše na dodavatelích.
Dokonce, protože je to jednodušší, jim poskytla pro vývoj svou ostrou databázi zákazníků a data o smlouvách.
Proč ne, přeci se to bude importovat tak jako tak.
Proč dělat anonymizovaný testovací dataset, to je plýtvání časem a penězi.

Bohužel, jak říkám, prostředí je hyperkonkurenční a jeden konkurent si googlil a hledal. Hledal něco úplně jiného, ale našel beta verzi eshopu. Začal tedy klikat a zkoušet.

Doteď dobrý, mohl si prohlédnout design, možná se inspirovat, ale to by mohl za měsíc při spuštěné ostré verze tak jako tak.

Naneštěstí pro firmu a naštěstí pro něj, si něco chtěl přes ctrl+a zkopírovat. A najednou si při označení všeho všiml bílého linku na bílém pozadí – Admin. (Jo jo, super nápad, takhle schovat nezabezpečený vývojářský přístup, toho si nikdo nevšimne…)

A díky tomu si vytáhl celou databázi zákazníků, uzavřených smluv a cenových nabídek.

Moc dobře pro něj, zisk pár miliónů a desítek přetažených zákazníků.

Jo, byla to jen betaverze na doméně z gabonu…

Příběh poslední : “Dokumentaci i kód máme, tady v té skříni”
Možná jste už slyšeli o Cargo kultu. Napodobování vnějších znaků nějaké činnosti totálně bez pochopení toho, k čemu slouží.

Krásným příkladem je firma, která slyšela, že s vyvinutým SW by měla dostat i zdrojový kód. Mít zdrojový kód je dobrá věc, jde pak změnit dodavatel. Ale když přišlo na věc, bylo vše jinak.
Ono totiž předat někomu 500 vytištěných stran s tím, že tady je zdrojový kód, je dost na nic. Mám dojem, že netaktní vývojář se u zákazníka smál snad deset minut.

A firma zaplakala a vyvíjet se muselo z čisté louky.

Není to osamocený případ a problémem není jen kód. Netušíte kolik věcí exportovaných do PDF jsem viděl. Designy, schémata, pokladačky, ale třeba i grafiku.
K čemu to je, když to zpětně do nástroje nenahrajete?
Povím vám to, je to k ničemu…

Vývojová dokumentace má sloužit k tomu, aby jste byli schopni ze zálohy (archivu) obnovit projekt tak, aby šlo jednoduše a levně opravit malou chyby nebo přidat novou funkci. Ne proto abyste měli “papíry”, protože to chce standard.

A tak je to bohužel se vším. Doufám, že jsem vám na pár případech ukázal proč a jak je lepší se občas zastavit a přemýšlet, že standardy nejsou jen papíry a pro úřady, a že hurá přístup není ani nejlevnější ani nejrychlejší.

Kdybyste si chtěli popovídat, nebo se na něco zeptat, moje stránky jsou www.softsyng.com a můj linkedin je https://www.linkedin.com/profile/view?id=46111140&trk=nav_responsive_tab_prof a mail je petr.svimbersky@softsyng.com

Bohužel vím, že stejně si musíte prožít alespoň jeden podobný příběh, než vás napadne, že je možná dobrý nápad nedělat vše sami a nevynalézat znovu kolo.

Povězte mi v komentářích, jak se strašně mýlím a dramatizuju,
Petr