Category Archives: Guest posts

Prispevky od pratelu Podnikani v USA… Rozsirujeme ruznorodost nazoru, zkusenosti, pripadovek od dalsich zajimavych lidi.

Mrzení při rozjíždění online podnikání v postsovětských státech

Již několik let provozuji web Skrblík.cz. Po počátečních potížích, jako v téměř každém podnikaní, jsme s kolegy přišli na to, jak takový web dělat a být zároveň ve „zdravém“ zisku.

Asi před dvěma roky mě napadlo, že bych mohl vzít úspěšné fragmenty ze Skrblíka jako různé výhodné nabídky, slevy, slevové kupóny, rozsáhlé přehledy akcí typu Black Friday, … a zkusit expandovat mezinárodně, ze začátku do zemí bývalého Sovětského svazu. Proč do těchto zemí? Žije tam poměrně hodně obyvatel, online prostředí není tak vyspělé jako na západě, není tam zdaleka taková konkurence jako v západní Evropě a v USA.

Zčásti mě k mezinárodní expanzi inspiroval můj dlouhodobý pobyt v ukrajinském Užhorodu. Užhorod je totiž historicky velmi multikulturní město, kde se vždy potkávalo a společně žilo mnoho národů – Rusíni, Ukrajinci, Maďaři, Rusové, Slováci, Češi, Gruzíni, Arméni, Cikáni, Poláci, Rumuni a v posledních několika letech přibylo několik tisíc vysokoškolských studentů z Indie, Sýrie a afrických zemí. Je to vidět třeba i na místní kuchyni, kde se všechny vlivy zajímavě mísí. Zajímavé je, že i přes značný konzervatismus místních obyvatel všichni žijí víceméně v klidu a míru bez nějakých konfliktů. Naopak například ve Lvově, který je také na západní Ukrajině, ještě nedávno reagovali lidé velmi rozporuplně na rusky hovořící lidi a to i včetně cizinců s akcentem, u kterých je zřejmé, že jsou ze střední nebo západní Evropy.

Protože Skrblík a i nové plánované podnikání je založeno především na obsahu, potřeboval jsem sehnat větší množství externích spolupracovníků, kteří ovládají především ukrajinský a ruský jazyk. A právě Užhorod mi v tomto přišel kvůli výše uvedeným důvodům jako ideální místo pro nábor talentu. Samozřejmě roli hrály i významně nižší mzdy na Ukrajině, ve srovnání s ČR poloviční až třetinové a to se při samofinancování nového projektu hodí!

Zaregistrovali jsme doménu, připravili design, web a já začal hledat v Užhorodu spolupracovníky pro tvorbu obsahu. Především mezi známými, nabídnul jsem na místní poměry solidní mzdu (tehdy ekvivalent asi 70 czk za hodinu), nabídnul práci z domu nebo z kanceláře v Užhorodu. Našel jsem a domluvil se asi s 8 lidmi, většina byla studenti – vysokoškoláci, většinou z chudých poměrů, takže jsem očekával vysokou motivaci díky možnému solidnímu výdělku. Velmi brzy se ukázalo, že i ukrajinský pracovní trh má istá kulturná špecifiká. V podstatě všichni postupně shořeli jak papír. Prakticky nikdo neudělal domluvenou práci, někdo dodal část, někdo nic. Netušil jsem vůbec proč. Později jsem zjistil některé důvody. Jedním z nich byla například pro Ukrajinu nevhodná frekvence vyplácení peněz. Zatímco v ČR standardně vyplácíme spolupracovníky měsíčně, na Ukrajině je zvykem týdenní vyplácení peněz (a v některých případech dokonce denní!). To jsem nevěděl, nabízel jsem standardně měsíční, překvapivé ale bylo, že mi nikdo ze spolupracovníků nedal feedback a nepožádal o týdenní vyplácení. Celkově jsem byl velmi překvapen, že úroveň spolupracovníků byla velmi nízká v porovnání s kolegy například ze Skrblíka. Doteď si nedokážu úplně vysvětlit proč.

Po této zkušenosti jsme zkoušeli hledat lidi na různých freelance severech. Měli jsme už část obsahu hotového, nicméně v nekompletní a nespustitelné podobě, tak jsme chtěli aspoň něco dokončit. Ukrajinci nebo Rusové na freelance webech už ztrácejí ekonomickou výhodu, nebojí si říct „evropské“ peníze, někdy jsou dražší než pracovní síla v ČR a na Slovensku.

Nyní jsme v situaci, že si úplně nevíme rady, jak najít šikovné rusko a ukrajinsko hovořící spolupracovníky, zkoušíme různé cesty, výsledky jsou zatím nejisté. Pokud máte s touto problematikou zkušenosti, budu rád za vaše tipy!

Pááááán Fandor

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

Predstavani projektu Auditist.com

Ahoj,

v prvni rade musim podekovat Johnovi, ze mi dovolil timto zpusobem promluvit ke svym vernym ctenarum. A hlavne za to, ze pise svuj blog a motivuje nas tim k vyssim vykonum 🙂

Muj pribeh

Tak dlouho jsem si pral odcestovat do USA, az jsem jednoho dne, pred 5ti lety, dostal nabidku pracovat na fulltime projektu v Rusku. Rekl jsem si: “zapad nebo vychod, to je fuk”, a vyzvu jsem bez vahani prijal. Jednim z hlavnich pracovnich ukolu bylo provadet bezpecnostni audity na skladech a obchodech od Moskvy az po Sibir. O tom, ze jsem na zacatku vubec neumel rusky a nevedel vubec nic o bezpecnosti treba priste 🙂

Problem

Bezpecnostni audit byl vlastne checklist asi 95ti otazek vytistenych na ctyrech papirech A4. Vedle kazde otazky oznacite vysledek, napisete komentar a pripadne poridite fotografii. Audit samotny zabral 4-5 hodin. Vetsinou jsem pak prisel na hotel a rovnou prepsal vysledky auditu do excelu. Nasledne jsem sve nalezy zaslal managementu. A potom? Potom se zpravidla nic moc nestalo. Travil jsem cas cestovanim, pripravou na audit, auditem samotnym, prepisovanim vysledku do excelu, reportovanim. Vse stalo hodne casu a velke penize. Efektivita prace a hodnota pro firmu mohla byt vyssi.

Reseni

Rikal jsem si, ze musi existovat lepsi pristup a v hlave se mi zrodila myslenka na software. Zacal jsem po necem patrat, ale nenasel jsem v te dobe nic rychleho, prehledneho, neco co by fungovalo dobre na telefonu/tabletu a offline. O nekolik mesicu pozdeji jsem mel tu cest pri sve praci jeste makat na jednom projektu s Johnem a to mne tak nabilo, ze jsem si rekl, ze takovy software sam vyrobim. Dal jsem dohromady programatory a prvni verze je jiz na svete.

Auditist.com

– Auditist umoznuje vytvorit si checklist pro jakykoli druh auditu nebo inspekce

– Jedna se o webovou aplikaci, ktera je plne responsovni a umoznuje vam provadet audity na jakemkoli zarizeni, a to i v offline

– Muzete pohodlne oznacovat odpovedi, psat komentare a prikladat fotografie

– Planujete audity pro sebe nebo pro svuj tym

– Vysledek auditu nebo souhrnny report se zobrazi na jedno kliknuti

– Nalezy z auditu primo priradte k reseni odpovedne osobe a sledujte jejich realne vyreseni

– Tady Auditist nekonci, appku stale rozvijim a zlepsuji

V Auditistu muzete kontrolovat vse od provozu malych obchodu, kavaren, skladu, ucetnictvi, bezpecnosti prace, hygieny, pozarni prevence, bezpecnostni prevence, prevence ztrat, udrzby budov az po ruzne ISO audity, 5S audity atd. Dnes jiz mnoho firem nejaka softwarova reseni pouziva, ale casto jsou uzivatelsky neprijatelna nebo nefunguji na mobilnich zarizenich.

Pokud kohokoli z Vas appka zaujala nebo byste se na ni chteli jen podivat, piste, rad Vam zpristupnim testovaci verzi.

Budu vdecny za jakekoli komentare.

Frank
Frank@auditist.com
https://auditist.com

Z emailu: Dostupné kvalitní zájmové kroužky

V nějakém městě/ obci nejsou kroužky vůbec, jinde třeba málo kvalitní lektor a pod. A rodič nemá vždy možnost trávit s dítětem 2hod. denně, 3x v týdnu kvůli tréninku.

Proto plán:

  • dovoz dětí busem/ minibusem do kroužku mimo obec, kde bydlí
  • převzetí odpovědnosti hned při nástupu do busu
  • možnost spolujízdy s dítětem – např babička, rodič
  • v buse by byl člověk, který by děti (+ jejich případný doprovod) evidoval, že jedou (tužka nebo systém)
  • hodnota pro dítě – dovoz až ke kroužku+kvalitní vedení, pro rodiče – časová úspora, pro mě- profit z členských příspěvků, z jízdenky nebo z obojího

Otázky:

  1. Je vůbec reálný takový projekt vzhledem k proměnným jako jsou různá města (okruh např. 20-30km), různé kroužky a různé časy jejich začátků? Ano?…pak…
  2. Dokáže takový projekt být profitabilní z % z členských příspěvků a/nebo z dopravy?
  3. Jak dopravu řešit?
  4. Jaké další otázky bych si měl položit?
  5. Je to celé hovadina? – děkuji za přečtení až sem:)

Aleš

Ako sme spustili medializuj a prečo IT projekty meškajú

Začiatkom mája sme spustili registráciu odborníkov na portáloch medializuj.sk a medializuj.cz.

Medializuj je platforma, ktorá spája novinárov s odborníkmi. Novinári často prácne hľadajú špecialistov, ktorí by sa vyjadrili na témy, ku ktorým pripravujú článok. Odborníci sa vďaka vyjadreniu v médiách zviditeľnia a posilnia svoje meno, či firemnú značku. A práve to spája náš projekt.

Prvá verzia bola veľmi oklieštená a nevyladená. Náš pôvodný plán bol spustiť plnú verziu do 15. mája 2019, čo sme však nestihli. Spustili sme ju presne o mesiac neskôr a stále ju zdokonaľujeme.

Prečo IT projekty meškajú?
Pozrime sa bližšie na čísla.

  • 75% IT manažérov očakáva, že ich SW projekt skonči neúspechom
  • menej ako tretina IT projektov je úspešne dokončených v rámci časového plánu a rozpočtu

S meškaním IT projektov v korporáciách sa už ráta ako so samozrejmosťou. Prečo však meškal aj náš projekt, ktorý som programoval sám? Stále som sa nepoučil po desiatkach IT projektov?

Dôvody meškania medializuj:

    1. Zlý časový odhad pre definovaný rozsah prác
      Podnikatelia sú väčšinou optimisti. Keby boli pesimisti/realisti, nepúšťali by sa do nového podnikania. Ako všetky projekty, aj tento som podhodnotil. Veci, ktoré mali trvať 2 dni, trvali 3 dni.

 

    1. Rozsah prác neobsahoval všetky potrebne veci
      Portál Medializuj je rozsiahlejší ako sme pôvodne rátali. Niektoré featury prišli ako feedback od klientov a niektoré mali byt zadefinovane v pôvodnom rozsahu prác. Jednoducho sa však na nich zabudlo.

 

    1. Veľa neznámych
      Medializuj je postavený na najmodernejších technológiách. Tie sa ešte veľmi rýchlo vyvíjajú a menia (React.JS, GraphQL, node.js…).
      Mnoho balíkov, ktoré sme používali obsahovali chyby, ktoré som musel riešiť. React.js taktiež kompletne zmenil API, a tak sa cely front-end musel výrazne prepísať. Sú to dopredu neznáme veci, ktoré sa veľmi ťažko plánujú.

 

Aj napriek meškaniu je projekt medializuj úspešný. Denne sa nám registruje množstvo odborníkov aj novinárov. Tato služba je a aj bude navždy bezplatná.

Som si istý, že Johnove publikum je plné odborníkov, tak prečo sa neregistrovať?

Odkaz pre registráciu odborníkov v CR: https://medializuj.cz/jsem-odbornik/
Odkaz pre registráciu odborníkov v SR: https://medializuj.sk/som-odbornik/

Zsolt Szabo