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.

🙂

Taktika pri vyjednavani koupe nemovitosti v USA

Vyjednavni o koupi nemovitosti je z velke casti taktika a psychologie. Trzni cena neni uplne dokonala. Je to vzdy o vyjednavani. A jedna strana vzdy chce vice koupit nebo vice prodat. A pri tom vyjednavani se to pak zacina ukazovat.

Zakladni pravidlo je, ze to jestli na nemovitostech vydelate se nejvice rozhoduje pri koupi! Zasada je co nejlepe koupit.

Finalni cena neni temer nikdy finalni
Kdyz se uz chvili vyjednava tak jedna strana, v tomto pripade prodavajici rekl, ze to je FINAL PRICE (Take it or leave it). Proste, ze uz vice v zadnem pripade neslevni. Tomuhle se vzdycky smeju (pro sebe po tajmu) kdyz to nekdo rekne, protoze jsem snad jeste nezazil, ze by to platilo. Americani jsou dobri na kompromis. A kdyz je kupni cena treba 1.3 milionu dolaru (final price) a nabidnu o 50 tisic mene, tak je hodne pravdepodobne, ze akceptuji. U vetsich castek to plati jeste vice. Kdyz je koupe za pet milionu tak uchylka od final price dalsich par set tisic dolaru nikdy ten deal nerozbije. Par set tisici se vydela jen tim, ze ma clovek trosku drzost a i kdyz ho druha strana presvedcuje at v zadnem pripade uz dalsi nabidku neposila, ze nebudou reagovat tak to presto posle. Takze cinnost co zabere par minut vydela penez ktere byste na ulici nenasli.

Prodavajici fixovany na magicke cislo
Jak jsem popisoval to finalni ceny tak jsou v tom i vyjimky. Nekdy se prodavajici fixuji na nejaka magicka cisla. Jeden pan co sel do duchodu a prodaval mi kancelare tak rekl, ze musi dostat 460 tisic a ani o dolar mene. Nebo tri sourozenci zdedili dum a prodavajiho ho. Ale vi, ze kazdy chce milion takze se to musi prodat za tri miiony a nejede pres to vlak. Pak se doopravdy to vyjedavani zasekne na ten finalni cene. V praxi jsem zjistil, ze tito prodavajici uvazuji nad tim dealem jinak.

Pak vymyslim jine strategie. Vymyslim zpusob jak ukazat, ze dostavaji to svoje magicke cislo, ale pritom je to pro me porad dobry deal. Podarilo se mi to uz vicekrat pres tzv. owner financing. Misto zaplaceni cele hotovosti, tak zaplatim jen cast (klidne az 50%, aby prodavajici mel jistotu a maly risk) a zbytek je pujcka od prodavajiciho. Proto se tomu rika owner financing. Pak ukazu prodavajicimu, ze na urokach vydela treba dalsich xxx tisic navic, tak mi o tu castku muze snizit kupni cenu. Dostane sice penize postupne, ale zaroven v tom ma i danovou vyhodu (u tech investicnich nemovitosti nemusi danit v jednom roce a rozlozi ten zisk na vice let).

V praxi to vypada takto. Nabidnu nizsi cenu. Prodavajici chce vice. Ja reknu, ze vice penez nemuzu nabidnout, ale kdyz mi da owner financing tak mu nabidnu xx downpayment a xx vydela na urokach behem xx let (podle toho jak vycitim, ze chce penize rychle nebo pomalu tak nabidnu ten termin). Pro me je to vyhoda, ze nemusim pouzit svoje penize. Nemusim platit bance za odhad nebo jine papirovani (u komercnich nemovitosti treba jeste Enviromental report). Je to vyhra na obe strany.

Schopnost odejit z vyjednavani
Nejhorsi je, kdyz se jako kupujici zamilujete do nemovitosti a musite ji mit. To je temer zaruka na zaplaceni vice nez musite. Ja se do posledni minuty na nic nefixuji. Kdyz na me prodavajici vyrukuje s tim, ze ma jeste dalsiho zajemce co taky napsal nabidku (coz se v USA stava dost casto, ze na jednu nemovitost je najednou nekolik nabidek a zacina bidovani jak v aukci), tak pro me je to signal odejit.

Napr. agent prodavajiciho sdeluje po obdrzeni me nabidky:
“Mame tady dalsiho vazneho zajemce. Uz se byl trikrat podivat a chystaji taky napsat nabidku”. 

Doslova to tem prodavajicim rikam, ze jestli je to “multiple offer situation”, takze nemam zajem a odstoupim. To pusobi jak ledova sprcha. Protoze kazdy prodavajici miluje, kdyz muze cenu vysponovat mezi nekolika zajemci. Nekdy i trosku lzou a prave tam se nejvice vyplaci z vyjednavani odejit a treba za mesic se znovu ozvat.

Schopnost odejit i po zainvestovani penez
Due dilligence (cinnosti kdy si zjistujete jestli je nemovitost vhodna, delate inspekce a pruzkumy) stoji cas a penize. Kdyz nainvestujete treba par tisic dolaru do pravnika nebo nejakych pruzkumu (treba “survey” – coz je zamereni kde skutecne vede pozemek a jestli treba na nem nemaji sousedi neco postaveneho), tak prodavajici dostane casto pocit, ze uz z toho obchodu neuhnete. A nejednou se vyjednava hure. Ono casto se v te due dilligence prijde na ruzne negativni veci a znovu se vyjednava o cene. Ja jako prodavajici to taky nemam rad a nechce se me zlevnovat cenu. Ale jako kupujici chci samozrejme vyjednat vse nejlepe. A ted zalezi kdo me lepsi znalost trhu a lepe odhadne situaci. V poslednim dealu jsme takto na posledni chvili rusili a po nekolika mesicich pristoupili na o dost lepsi cenu!

I po odmitnuti se nebat nabidnout nizsi cenu
Tohle je dalsi vec co me fascinuje. V USA se mi uz nekolikrat stalo, ze jsem dal nabidku. Nedohodli jsme se. Pak jsem po case dal horsi nabidku. Znovu jsme se nedohodli. A zase po case jsem dal jeste horsi nabidku! Kdybych byl v tom stejnem pripade prodavajici tak by me takovy kupujici strasne stval. Ale americani jsou fakt dobri na delani kompromisu a vyreseni situace podle konkretni situace nebo podminek. Ono ty zivotni situace se meni. Lidi treba najednou potrebuji ty penize vice. A obchod se pak uskutecni. Me tuto strategii vubec nevadi pouzivat kdyz neco kupuji, ale nemam ji rad kdyz mi to nekdo udela zrovna kdyz prodavam:-). Na to je pak nejlepsi nereagovat a trosku ziskat zpet kontrolu nad situaci. Protoze kdyz by clovek zacal vyjednavat s tou hodne spatnou nabidkou tak je to cista znamka zoufalstvi, ze chce za kazdou cenu prodat.

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