VOY: IMHO zajistit, aby byl merge request dostatecne dobre definovanej, rozsekanej na atomicky reviewovatelny patche a s dostatecnou dokumentaci / commit messagema / atd. je zodpovednost autora. Pokud jako reviewer dostanu na stul blbe rozsekanej blob, kde neni jasny co je cilem nebo nejakej patch dela vic, nez by mel, tak holt bounce. A to je zase zodpovednost reviewera, aby to bouncnul. Od toho mame interaktivni rebase, aby slo praci prezentovat srozumitelne.

Tahle disciplina pak dost pomaha pri blamovani, kdy je mozny se doblamovat ke commitu s rozumnou commit message, kde je napsany, proc jsou veci tak, jak jsou. Coz dale emancipuje juniory, protoze si spoustu otazek dokazou zodpovedet sami a nejsou zavisli na buddym nebo seniorovi.

VOY: No tady časová dotace na code review nebyla a oni to dělali fakt důkladně a snaží se, aby jedno PR řešilo jednu věc a dalo se v tom vyznat. Takže dokud si nejsou jistý, že to tak chtějí nepouští to dál. Případně se zjistí, že je třeba něco spravit, tak to tam visí delší dobu, než se dokončí jiný PR, který opravuje chybu.

Ono taky záleží jaká je tvoje role dodavatele. Např. daňový poradci mají povinně pojištění profesní odpovědnosti za škody. Oni mi sice řeknou, ať si to pročtu jestli tam někde není chyba, jenže já tomu vůbec nerozumím a proto si je přece platím.

Ale u téhle korporace jsem jako pomocná síla. Tzn. jejich zaměstnanci by měli znát produkt lépe anebo přinejmenším stejně jako já. A když je něco nejasné, tak se o tom samozřejmě pobavíme. Pokud by si mě najali na něco, co oni sami neumí a nerozumí tomu, tak přiznávám, že to je alibistický.

No a pokud tam tu chybu stejně pustím, tak budu první, kdo se bude hlásit o opravu :-)

JARDABEREZA: To mi přijde jako v pohodě ošetření problému...

VOY: A jak za to má potom ručit autor kódu? Jako když podnikáš, tak neseš nějaké riziko a je na tobě, abys zajistil procesy, aby se práce kontrolovala. Něco jiného je, když na to zaměstnanec sere a chybu či dokonce škodu udělá schválně nebo mimo pravidla. Ale zaměstnanec nemá co nést riziko např. proto, že mu práci nikdo nekontroluje, nebo že třeba někde kód ani netestují a po půl roce se diví, že se jim koleje v týmu nešešly. Alibismus je to házet na zaměstnance. Má existovat moment, kdy je hotovo, odklepnuto, zkontrolováno.
Dodatečné úpravy či opravy, může stát, jsou pak nový úkol.

Když se mě jako OSVČ v roli kontraktora u jedné korporace ptali na pojištění škody, tak jsem řekl, že všechna moje práce půjde přes pull requesty, kde jejich zaměstnanci budou dělat code review a od toho okamžiku je to jejich problém. Co se ostatních věcí týče, tak dělám remote a nemám moc šanci jim fyzicky něco poškodit :-D. Stačilo jim to.

QWWERTY: jj, často je průšvih způsobeny neobvyklou kombinací věci, které jsou samy o sobě OK, i jsou OK jejich běžné kombinace..

E2E4: " software je vždycky plný chyb" ... a musel by byt zazrak, aby jsi za vsechny ty chyby byl zodpovedny jenom ty
coz te vraci zpatky k AMBIENTIUM: "nade vší pochybnost musí být prokázáno, že jediná odpovědná osoba za škodu jsi Ty a firma nebo kdokoliv další nemůže za nic"

DWICH: tak tady se bavíme spíš o odpovědnosti Švarc systém zaměstnance..

a to prokazování zavinění škody je u software těžký, software je vždycky plný chyb, nevím jak velká už je odpovědnost zakládající nedbalost..

Ještě bych doplnil, že v případě chyby nebo problému jsou dvě možnosti, jaké klient může chtít uplatnit: smluvní pokuta nebo vzniklá škoda.

Smluvní pokuta je past. Škoda může být tisícovka nebo klidně nulová, smluvní pokuta může být nastavena na 10 tis. Na smluvní pokutu nepřistupovat. Těch důvodů je víc.

Vzniklou škodu je potřeba definovat jako reálně vzniklou a prokázanou škodu. Tzn. když ji klient chce uplatnit, musí ji opravdu prokázat nějakým věrohodným způsobem. Což je právě ta výhoda oproti pokutě. Leckdy právě ta potřeba reálného vyčíslení klienta může odradit to řešit, podobně jako dodavatel leckdky promíjí klientovi jeho pozdní dodání podkladů a jiný "prohřešky" vůči podepsaný smlouvě.

Třetí věc je - nepřistupovat na pokutu a vzniklou škodu zároveň. Vysvětlit, že budete ručit za reálně vzniklou škodu, což by jakýkoliv pracovník měl, ať v IT nebo zedník. Na profesi nesejde. Všichni bychom měli odpovídat za svoje chyby. A opravdu se na to pojistit. Ty výše pojistek jsou dneska zanedbatelný vzhledem k výši příjmů.

No a poslední bod - limitace škody. I když je to právně složitější, je dobrý klienta připravit na to a mít to smluvně ošetřené, že ručíte do výše škody XY podle vašeho pojištění. Nedostanete se tak do situace, že děláte můstek mezi dvěma bankama, kde výpadek na hodinu může být škoda za miliardu, kdežto za tu práci dostanete 20 tisíc. I když ta škoda může být astronomická, vy můžete ručit do např. 10 % z ceny díla. Jinak by se nevyplatilo dělat takhle rizikovou věc za 20 tisíc a pak rovnou odevzdat celou odměnu při výpadku na jednu minutu.

Jestli klient chce astronomické záruky, měla by tomu odpovídat i cena za zhotovení a případně i pojištění. Kde může být argument - naše standardní pojištění je do výše 20 miliónů. Pro tento projekt se můžeme pojistit až na dvě miliardy, ale ty náklady z principu promítneme do ceny. Nebo se můžete pojistit jako klient vy. Je to věcí jednání.