Mel jsem duvod se pustit do vyzkumu zarucni doby. Presneji receno, doby po odevzdani softveru, kdy se zavazujeme veskere chyby opravit zdarma.
Idealne, samozrejme, delame programy bez chyb a muzeme poskytovat dozivotni zaruku nasim spokojenym klientum. Takhle by se to libilo kazdemu zakaznikovi. U trochu slozitejsich systemu, se musi pripustit, ze chyby jsou soucasti vyvoje, abychom umeli s timto elementem pracovat. Pri narustajici slozitosti neni mozne vsechny stavy vyjmenovat ani 100% otestovat. A chyby jsou nevyhnutelne. Pak muze nastat situace, kdy vetsinu casu budeme opravovat chyby a zivot nasi softverove firmy bude velmi kratky.
Pokud jste vyvojar na volne noze nebo vedete softwarovou firmu, urcite jste tuto otazku resili. Takze jsem vzal telefon do ruky a obvolal par spolecnosti.
Firma---------------- |
Zaruka |
Poznamka |
zavedena znacka 1 |
24 mesicu |
soucasti vyvoje jsou akceptacni testy, kterymi se prokaze funkcnost dle specifikace |
zavedena znacka 2 |
24 mesicu |
rozhodujici je reklamacni rizeni, behem ktereho se posuzuje, zda vubec firma muze za nastalou chybu |
zavedena znacka 3 |
resi se individualne, vetsinou 24 mesicu |
na opravu chyb po zarucni dobe se dava sleva = nizsi hodinova sazba |
mensi firma 1 |
24 mesicu |
chyby nedelame, zaruk se nebojime |
mensi firma 2 |
12 mesicu |
snad 12 mesicu neni proti zakonu, zatim do toho nikdo nestoural, vzdy jsme se se zakaznikem domluvili |
Protoze nekteri mluvili o standardni zaruce 24 mesicu, ktera (mozna) vyplyva ze zakona, nasel jsem
v novele obcanskeho zakona
§620
(1) Při prodeji spotřebního zboží je záruční doba 24 měsíců; jde-li o prodej potravinářského zboží, je záruční doba osm dní, u prodeje krmiv tři týdny a u prodeje zvířat šest týdnů. Je-li na prodávané věci, jejím obalu nebo návodu k ní připojeném vyznačena v souladu se zvláštními právními předpisy 4alhůta k použití věci, skončí záruční doba uplynutím této lhůty.
Mozna jsem se dival spatne, nebo nenasel to co bylo potreba, zatim mi ale vychazi, ze software neni spotrebni zbozi, takze ani neplati povinne 2 roky zaruky.
Navic napriklad
„Záruční doba“: doba, během níž Sun Koncovému uživateli zaručuje bezplatné odstranění Vad Výrobku.
„Základní záruční doba“: trvá 6 (šest) měsíců v případě Hardware, 90 dní v případě Software a 3 měsíce v případě Služeb. V případě, že se vztah mezi Sun, resp. Prodejcem, a Koncovým uživatelem řídí občanským zákoníkem, trvá Základní záruční doba 2 roky. Základní záruční doba podle tohoto záručního a reklamačního řádu počíná plynout od data prodeje Výrobku či instalace Výrobku Koncovému uživateli společností Sun či jejím autorizovaným zástupcem, podle toho, která z těchto událostí nastane později.
Nejaky dalsi postreh nebo zkusenost?
Dobry den,
vas vyzkum je jedna vec, ale realita druha :-). Delal jsem v nekolika velkych firmach, takze vam muzu rict jak to funguje. A to tak, ze chyby se oporavuji zdarma ve fazi testovani. Pokud projde produkt akceptacnimi testy, je zakaznikovi predan a nasledne nasazen. Dalsi opravy chyb se resi v tzv. supportu. Za support se plati ruzne - vetsinou urcitou procentuelni castkou z celkove hodnoty dila (treba 10% rocne).
U velkych projektu, jako je treba internetove bankovnictvi, rozsahle informacni systemy a pod. to snad ani jinak nejde - netere chyby se objevi treba az za rok a jen analyza toho, zda se jedna o chybu sebere urcity cas. Zadna zaruka oprav chyb zdarma po predani a akceptovani dila podle me nikde neexistuje.
Ahoj,
taky jsem to řešil a dospěl jsem k názoru, že je u alespoň trochu složitějších aplikací sebevraždou dávat záruku na software a nikdo to tak nedělá. Řešením je formální akceptace díla. Protože počet chyb nezávisí na kvalitě odvedené práce, ale na důkladnosti testování.
Něco jsem o tom napsal zde: http://www.netmagnet.cz/blog/zaruka-na-software/
Velmi zajímavý článek. Já jsem toho názoru, že by to asi mělo být individuální. Protože každý software může mít prostě jiné "mouchy" Mnohem větší smysl mi dává, aby firma, která má software na svědomí poskytovala uživatelům nějakou formu technické podpory. Něco jako například https://www.memos.cz/ u kterých jsem si objednával vývoj software na zakázku. :-)
Potvrrzuji (1). U nas je to to same . Behem akceptacnich testu (jsou soucasti vyvoje a jeho rozpoctu, typicky 2-3 tydny, naklady na ne jsou zahrnute v rozpoctu a v castce, kterou plati zakaznik za vyvoj. v ramci tohoto jsou opravovany pouze chyby, ktere jsou "jasne" - odlisnost chovani oproti puvodnimu projektu (ktery byl akceptovan a separatne zaplacen zakaznikem).
pokud si v prubehu testu (nebo i vyvoje) zakaznik neco rozmysli, nebo se prijde na neco, na co se pri priprave projektu zapomelo a zakaznik na to pri sve akceptaci neprisel, tak je to soucast zmenoveho rizeni a zakaznik plati hodinovou sazbu, kterou navrhujeme my.
po akceptaci projektu prechazi do supportu, kde uz to byva ruzne - zalezi na obchodnikovi jak projekt zobchodoval . ale typicky priklad je, ze po dobu zaruky (6 - 12 mesicu typicky) ma zakaznik urcity pocet hodin mesicne "zdarma" (napr. 30), po uplynuti zaruky uz se to lisi projekt od projektu (pausalni mesicni castka za urcity pocet hodin, plati vsechno atd tatd)
je to pak krasne videt, jak behem zaruky chodi hromady chyb (casto fura ptakovin), tesne pred uplynutim zaruky prijde treba dvacet chyb naraz a dnem uplynuti zaruky jako kdyz utne a prijde jedna chyba za mesic.casto se zakaznici snazi v ramci chyby protlacit zmenovy pozadavek, ale to je uz jina kapitola... a nikdy nekoncici dohady o tom, kolik zaplati apod...
Ust. § 620 občanského zákoníku upravuje záruku při koupi zboží (kupní smlouva), to nelze na poskytování software vůbec vztáhnout (licenční smlouva). Navíc je nutné rozlišovat odpovědnost za vady podle obchodního a podle občanského zákoníku atd. Na uvedené téma lze napsat přinejměnším diplomovou práci.
Na téma občanský x obchodní zákoník se už toho napsalo mraky, většinou jako součást vysvětlení v internetových diskuzích :-) Jelikož dodávka zakázkového SW se bude v 99% případů řídit obchodním zákoníkem, tak uvedený paragraf nemá žádný smysl. Stejně tak 24 měsíců je lhůta z občanského zákoníku.
dekuji moc za podnetne komentare. Takze jestli jsem dobre pochopil princip supportu, pokud se vyviji software rekneme 1 rok, zakaznik za nej zaplatil 1 mil. pak v nasledujicim obdobi plati v ramci smlouvy o podpore zhruba 8.000,- mesicne za podporu (to je tech 10%). V pripade neustaleho vyvoje za dalsi rok cena podpory muze byt 2 krat vetsi.
Rozumim tomu, ze to je vse otazka smlouvy a obchodniho jednani. Jde mi o to, jestli jsem alespon zhruba pochopil spravne beznou praxi ve vetsich vyvojarskych firmach. Vychazi mi tedy, ze k cene bezprostredniho vyvoje se vzdy pripocte pausalne cena podpory, ktera je ve smlouve. To dava smysl a asi jsem v tom udelal chybu. Problem teoreticky muze nastat pri rozvazani spoluprace, to znamena konec smlouvy o podpore, plati zarucni doba + reklamacni rizeni apod.
je to jednoduché - jestliže to od dané firmy odebírá tvá firma, tak je to podle obchodního zákoníku a pojem "záruka" či "reklamace" neexistuje. Vše musí (může) řešit smlouva. Jestliže se tedy zavážeš dodat nějaký software s nějakými vlastnostmi, tak jej musíš dodat. Jestliže to nemá dané vlastnosti, lze odstoupit od smlouvy. Vše ostatní je pak o té smlouvě, tj. jestli se zavážeš poskytovate záruku, poskytuješ záruku. Můžeš si ve smlouvě nadefinovat libovolné podmínky pro reklamaci atd., můžeš si tam dát podmínku placení nějakého fíčka, jinak přichází o záruku atd. Prostě je to normální dvoustranný vztah, u firem se předpokládá, že mají nějaké IQ nutné k provozování živnosti, nepotřebují tedy zvláštní zákonnou ochranu. Na rozdíl od občanů, u kterých ČR a potažmo EU, předpokládá, že jsou to naprostí idioti a vnucuje pojmy jako dvouletá záruční lhůta a reklamace.
jinak 10 % z milionu je cca. 80 tisíc ne 8 tisíc. Jaká bude cena podpory je opět záležitost čistě smluvní. Praxe je vesměs taková, že dáš za stanovenou cenu projekt, cena v sobě zahrnuje veškeré náklady na vývoj. A k tomu se běžně dává nějaká záruka, což je doba, po kterou zdarma opravuješ to co funguje jinak, než si zákazník představuje. K tomu pak poskytuješ placený support, který zahrnuje v sobě pár hodin práce, která nesouvisí s chybami softu - např. aktualizace softu při změně zákonů či norem, doplňování nové funkčnosti, oprava chyb způsobených uživateli atd. Pakliže ta práce překračuje dohodnutou dobu, je stanovena nějaká hodinová mzda.
[7] tak predevsim 10% z mil je 100 tis., nikoliv 80 :) 100tis deleno 12 mesici je zhruba 8tis. mesicne.
Co se tyce podpory, tak v ni podle mne nejsou jenom ty hodiny prace, ale take dalsi naklady, spojene s udrzbou a podporou, jako napr. nainstalovana kopie toho softu u sebe na lokalnim serveru, zaskoleni novych pracovniku, interni vyvojarska dokumentace k projektu apod. I to, ze je nekdo vubec schopny se projektu venovat, je v obraze a reaguje na pozadavky v rozumne dobe, stoji urcite penize. Mluvime porad o zakazkovem software, nikoliv krabicovem baliku.
Zdravím,
my to máme ještě jinak - v závislosti zda jde o licenční smlouvu nebo smlouvu o dílo.
Níže je citace z LICENČNÍ smlouvy. (V krátkosti jde o doživotní záruku ke všem našim produktům v případě, kdy aplikace běží na našich serverech. Pokud klient provozuje aplikaci na svém serveru či serveru třetí strany, o tuto doživotní záruku přichází - aktuálně v tomto případě uvažujeme o tom, že by se tato naše doživotní záruka nezrušila, ale v plném rozsahu zkrátila na 12 měsíců).
3. Záruka za produkt
3.1. Poskytovatel poskytuje doživotní záruku na řádné fungování produktu. Doživotní zárukou se rozumí po celou dobu existence produktu. Doživotní záruku lze uplatnit pouze tehdy, pokud je produkt provozován na serveru poskytovatele. Poskytovatel se zavazuje odstranit na své náklady vzniklé závady bránicí řádné funkčnosti produktu, a to za podmínky, že nabyvatel nebude do produktu provádět jakékoli zásahy bez předchozí písemné dohody s poskytovatelem. Poskytovatel zajistí opravu závad bránících řádné funkčnosti produktu neprodleně, nejpozději do třiceti dnů od oznámení nabyvatelem. Oznámení bude nabyvatel provádět e-mailem na adresu helpdesk (zavináč) beneta.cz. Kromě toho mohou být, například v urgentních případech, závady informativně oznamovány poskytovateli telefonicky na číslo +420 220 920 930.
3.2. Poskytovatel poskytuje garanci, že v případě žádosti nabyvatele o úpravy či rozšíření aplikace bude tyto úpravy či rozšíření schopen a ochoten uskutečnit minimálně po dobu tří let od podepsání smlouvy. Tyto práce nejsou předmětem této smlouvy a jsou hrazeny samostatně.
=-=
(U SMLOUVY O DÍLO (tj. aplikace na zakázku) může samozřejmě klient kdykoliv reklamovat rozpor funkčnosti dodané aplikace s definicí funkčnosti (analýzou), která je v dané smlouvě o dílo. Prakticky se stává, že nějaký bod (use case) je sporný a dá se vysvětlit několika způsoby, což se pak řeší dohodou s klientem (většinou asi tak, že část podobných sporných bodů klient uhradí a část realizujeme zdarma).
Nadstandardně pak (rádi) řešíme další záruky a kratší reakční doby servisní smlouvou (která nemusí být nikterak vysoká).
No já bych nejdřív narazil na to, co je to vlastně chyba. V rámci vývoje SW se rozličuje chyba a Change request. Je rozdíl v tom, jestli udělá chybu vývojář (nebo už analytik) nebo je problém v tom, že zákazník nějakým způsobem zadal projekt a po jeho převzetí náhle očekává, že produkt bude dělat něco víc (nebo něco jiného) než si sám vymínil.
Pokud jde o klasické chyby pak u běžných vývojářských firem probíhá několika kolové testování. Záleží na naplánování projektu. V naprosto ideálním případě se testuje už analýza a kontroluje se soulad s požadavky zákazníka. Obvykle se ale testuje až v rámci vývoje a to tak, že nejdříve testují samotní vývojáři a následně testeři. To vše je součástí vývoje. Následují akceptační testy. Ty si většinou organizuje sám zákazník. Buď má vlastní testerský tým, nebo najme jinou exterí firmu. Často akceptační testy provádí samotná vývojářská firma (záleží na smlouvě, existuje několik druhů projektů, v rámci kterých si u nás firmy nechávají vyvíjet SW). Co je důležité jsou akceptační kritéria. Ty si vždy zadává zákazník. V nich říká, jaké vlastnosti musí Sw mít a v jakých parametrech fungovat, aby ho převzal. Obvykle jsou ještě sjednány podmínky za kterých je SW převzat z "integračích testů" do testů akceptačních. Tedy zázakník si může říct, že nebude SW testovat dokud v něm bude určité procento nalezených chyb (v závislosti na prioritě). Až do provedení akceptace se stále opravují nalezené chyby.
Opravování následně nalezených chyb (tedy těch,které se neprojevily ani při integračních ani při akceptačních testech) bývá ošetřeno smlouvou. V ní je ale také ošetřeno řešení skrytých Change requestů - tedy případů, kdy zákazník říká, že aplikace obsahuje chybu, ale podle dodavatele je vše funkční dle zadání.
Takže asi tak :-)
Jak symbolicke! Nemohl jsem nejakou dobu zapsat komentar, kvuli chybe v blogovacim systemu. Hlasilo mi to "CHYBA: Chyba databáze - nepovedlo se uložit nový komentář."
Asi pred mesicem jsem zjistil, ze na webovem rozhrani banky nejde zadat prikaz k uhrade dle ulozene sablony. Na hotlinu mi prijemna slecna poradila, ze mam tu sablonu vytvorit znovu. Pry doslo k upgrade systemu.
[12] Predpokladam, stourale, ze se nezivite vyvojem softveru. Pokud ano, opravdu rad bych ten softver videl. Necham se poucit o tom jak se dela trochu slozitejsi softver bez chyb a udelam mu tady reklamu zdarma. ;)
Jinak, se da rict i to, ze pokud bychom nepouzivali pocitace, tak se vubec nemusime zabyvat softverem, hardverem ani jejich chybami ani zarukami.
[11] Obecně souhlas :)
[15] Otázkou je, jestli to takto jsou ochotni chápat i klienti, určitě se nějací, který by se do smlouvy napsalo "Tento sofware je bez záruky (záruka je za dvoujnásobek)" našli, třeba by to mohla být i zajímavá strategie :o)
Nicméně prakticky z pohledu zákazníka (mluvím-li o firmě), to je myslím neakceptovatelné. A pokud na takovou smlouvu klient přistoupí, tak jen proto že (celkem logicky) předpokládá že chyby mu budou opraveny. Kupujete-li si např. dům (opět z pohledu zákazníka), také podepíšete předávací protokol se seznamem chyb, kde třeba podepíšete že střechou neteče, ale když přijde za čas bouřka tak to budete reklamovat. A je jen otázkou dobře napsané smlouvy, aby bylo definováno co to je "nějaký čas", co to je "bouřka", a co to je "teče" :o)
Nicméně myslím, že je právě úkolem dodavatele mít smlouvu rozumně napsanou tak aby chránila obě smluvní strany a připouštěla co nejméně sporných míst.
PS: stavba a údržba domu mi obecně přijde docela dobré přirovnání k sofwaru, je vhodné tam mít architekta (analytik), vytvořit dobrou dokumentaci (analýzu, dokumentaci..) a na základě této dokumentace může v podstatě jakákoli stavební firma postavit ten stejný dům. A i tady platí, že by se pak úpravy domu měly zanést zpětně do dokumentace (a i tady se to často nedělá :o)
Dobry den,
tento je hodne zajimavy...
Pomerne vetsi firma ACOMWARE nam dala na prevodni mustek mezi eshopem a nasem ekonomickym soft. altus vario. zaruku jsme dostali 7 DNI!!!!!!!!!!!!!!!!!!!!!!! byl jsem z toho v soku. Prej se vic nedava.
Navic nam byla predena velmi spatna dokumentace.
Je to vždycky o dohodě a smlouvě kterou sepíšete, slušná firma odstraní zásdní chby zdarma aby zachovala funkčnost a svou dobrou pověst. Pokud potřebujete něco dodělat je to za peníze. Kolikrát pár korun ušetřených na začátků ztratíte v průběhu, když děláte s amatérama a zlatokopama,kterých je poměrně stále dost.
Mam zaruceny zpusob, jak si poridit premium account na rapidshare.
1) udelejte si bezplatně registreci na www.paypal.com
- (sign up), pote si vyberete personal ucet a vyplnite vsechno info co to po vas bude chtit (pro mene zdatne v anglictine... slovo OPTIONAL znamena DOBROVOLNY)(pokud vam staci jen premium ucet na rapidsharu a nebudete si chtit poslat nejake ty dolary na ucet nebo domu nemusite vyplnovat pravdive udaje krome E-MAILU!!!!) - az dojdete k tomu s kreditkou (kreditku nevyplnovat), date cancel a pote si vyzvednete aktivacni email co vam prisel
2) kliknete na odkaz
http://adbux.org/register.php?r=Charlieus
Tady provedete další registraci,vyplníte přihlašovací jméno a heslo. Poté do políček E-mail Address, E-mail Address Again For Verification, PayPal E-mail Address For Payments vyplníte svůj e-mail. Poté ješte vyberete vaší zemi a v kolonce Referrer nechte Charlieus. Pak stačí opsat kontrolní kod a registarce je hotova.
no a princip vlastne spociva v tom ze kliknete na odkaz, pockate tu pulminutu co to vzdy ukaze a jdete dal, za kazdy zobrazeny odkaz dostavate 0,01 dolaru, denne muzete zobrazit +- 10 odkazu ((((nekdy se behem dne pridavaji dalsi a kazdy de jen jednou za 24 hodin))))
ale pozor v zadnem pripade nemejte rozjete dva najednou nebo vam to nic neda, takze staci kliknou na prvni, vyckat az se cas ktery se zobrazi odpocte a objevi se dolar, pote dalsi odkaz atd atd
Až budete chtít peníze vyplatit kliknete na My Stats a zvolíte Cashout. Zde vyberete možnost převodu na PayPal.
A potom si mužete zaplatit rapidshare pomoci sluzby PayPal :) opravduto to funguje ja to tak osobne delam a sem spokojen
No, podle me je zaruka u SW i tak trochu podvod. Pokud to nebezi na HW poskytovatele a pokud to neni dedikovany SW, ktery nepotrebuje OS, je plneni zaruky stejne takrikajic dobrou vuli. Otazek typu a vy mate knihovnu PERL 5.0.0.11.1.1.1.2112 ? tak to se nedivte, vy mate SP3? vy nemate javu 1.6, vy paralelne provozujete Oracle? Tak to nejprve odstrante, nainstalujte zakladni konfiguraci a pak se budeme bavit... etc...
Coz je take dalsi duvod, proc se i placeny SW na zakazku poskytuje jako "tak jak je" a domlouva se nejaka docasna podpora
Zákon č. 40/1964 Sb. Občanský zákoník
Oddíl druhý
Zvláštní ustanovení o zhotovení věci na zakázku
§ 644
Jde-li o zhotovení věci na zakázku, vznikne objednateli právo, aby mu zhotovitel podle jeho objednávky věc zhotovil, a povinnost zaplatit zhotoviteli cenu za zhotovení věci.
§ 645
(1) Zhotovitel odpovídá za vady, které má věc na zakázku zhotovená při převzetí objednatelem, jakož i za vady, které se vyskytnou po převzetí věci v záruční době. Stejně odpovídá za to, že věc má vlastnosti objednatelem při zakázce vymíněné.
(2) Zhotovitel odpovídá za vady provedené zakázky, jejichž příčinou je vadnost materiálu dodaného objednatelem či nevhodnost jeho pokynů, jestliže objednatele na vadnost materiálu či nevhodnost jeho pokynů neupozornil.
§ 646
(1) Záruční doba je šest měsíců
(2) U věcí, které jsou určeny k tomu, aby se jich užívalo po delší dobu, stanoví zvláštní předpisy záruční dobu delší než šest měsíců; záruční doba přesahující šest měsíců se může týkat i jen některé součástky. Zhotovitel je povinen vydat objednateli záruční list s vyznačením záruční doby.
(3) U zhotovení stavby je záruční doba tři roky. Prováděcí předpis může stanovit, že u některých částí staveb může být záruční doba kratší, nejméně však osmnáct měsíců.
Přečteno 86 258×
Přečteno 75 676×
Přečteno 62 236×
Přečteno 51 808×
Přečteno 51 262×