CF 12/2018 Mimořádný přezkum - usnesení RP o smlouvě na dodávku SW

[Jan.Hora]

Dovolím si ještě reagovat na následující dva body (k ostatním bodům jsem už dříve svoje názory napsal, takže nebudu plevelit diskusi jejich opakováním, není mým cílem jimi umlátit ostatní do bezvědomí ):

1.7mega není tak vysoká cena za požadovaný objem práce.

Zde tedy mohu dodat, že aplikace Proplácení jak je teď online vznikala asi 7 dní soudě podle datumů dní, které jsou uvedeny v GITu plus dva navíc, než se to tam dostalo. A to se na tom nepracovalo každý den celý den.

Taky je hotový jen prototyp. Abychom to mohli porovnávat, tak nejen že se to musí dotáhnout a nasadit, ale taky doplnit funkčnost, která je ve specifikaci a klikátko ji ještě neumí, ale hlavně se to musí potom 8 let provozovat a podporovat. Cena zakázky zahrnuje i ten provoz a podporu, aktualizace a soulad s legislativou, to bude v budoucnu taky stát mnoho člověkodní, když bychom to dělali vlastními silami (neříkám že je to špatně, jen bychom neměli vyvolávat dojem, že nasazením stávajícího klikátka do produkce práce končí nebo je z většiny hotová).

PS: Nijak nezpochybňuju, že 7 dní je hodně dobrý výsledek vzhledem k rozsahu funkcí a kvalitě stávající verze. Klobouk dolů!

Jo takhle. Asi by to bylo dobré, ale nemyslím že je to teď zásadní otázka s vlivem na hlasování o přezkumu. S tím, že budou vícenáklady za extra vývoj (a že to může docela naskákat, když budeme chtít hodně vývoje) jsme se už bavili - je celkem buřt, jestli to je za grafiku nebo něco jiného.

Rovnou tedy již počítáme s tím, že to bude stát ještě víc, než je nyní schváleno ? Snad se nedostaneme do profesionální ligy veřejných zakázek, kde je navýšení i v řádu desítek procent.

Ještě jsem nezažil projekt, kde by specifikace na začátku projektu obsahovala všechno a nepřišlo se na nic, co by bylo třeba doplnit nebo měnit, přitom to ale neznamenalo, že byly špatně připravené. Některé otázky prostě zazní teprve až ve chvíli, kdy to někdo začne implementovat a integrovat - a bude to tak i s tvým řešením.

Problém navyšování veřejných zakázek je v netransparentnosti, záměrné nevýhodnosti smluv a záměrně nekvalitních zadáních. Tenhle problém nevidím, vícepráce jsou v diskutované smlouvě podchyceny úplně standardně a na specifikaci se poctivě pracuje, aby byla co nejúplnější.

[Martin.Kucera]

Dovolím si ještě reagovat na následující dva body (k ostatním bodům jsem už dříve svoje názory napsal, takže nebudu plevelit diskusi jejich opakováním, není mým cílem jimi umlátit ostatní do bezvědomí ):

Zde tedy mohu dodat, že aplikace Proplácení jak je teď online vznikala asi 7 dní soudě podle datumů dní, které jsou uvedeny v GITu plus dva navíc, než se to tam dostalo. A to se na tom nepracovalo každý den celý den.

Taky je hotový jen prototyp. Abychom to mohli porovnávat, tak nejen že se to musí dotáhnout a nasadit,

Nasazení s funkčností "rozpočty-záměry-proplácení" by měla být, podle toho co vím, otázka jednotek dnů.

ale taky doplnit funkčnost, která je ve specifikaci a klikátko ji ještě neumí,

Zkus nepřebírat shazující označení - ta customizace 2Kúčetnictví přece bude "klikátko" úplně stejně.
Věřím Martinovi (na základě praktických výsledků, které již předvedl), že zbylou funkčnost dokáže doplnit během dalšího měsíce, a to bez negativního dopadu na jinou jeho činnost pro stranu.

ale hlavně se to musí potom 8 let provozovat a podporovat.

Tady nechám odpověď na Martinovi nebo někom jiném IT zdatnějším než já.

Cena zakázky zahrnuje i ten provoz a podporu, aktualizace a soulad s legislativou, to bude v budoucnu taky stát mnoho člověkodní, když bychom to dělali vlastními silami

Prosím, neopakuj už ten mýtus o souladu s legislativou. Dodržení legislativy má zajistit dodavatel účetních služeb (má to i ve smlouvě), to není věcí nadstavbové aplikace pro naše interní procesy.

Ještě jsem nezažil projekt, kde by specifikace na začátku projektu obsahovala všechno a nepřišlo se na nic, co by bylo třeba doplnit nebo měnit, přitom to ale neznamenalo, že byly špatně připravené. Některé otázky prostě zazní teprve až ve chvíli, kdy to někdo začne implementovat a integrovat - a bude to tak i s tvým řešením.

Vtip je ovšem v tom, že když budeme něco potřebovat upravit ve vlastní aplikaci, pravděpodobně to bude trvat srovnatelně dlouho jako psaní specifikace té úpravy pro externího dodavatele. No a ten externí dodavatel na implementaci bude nejspíš taky potřebovat víc času než my (což je dáno rozdílem mezi "vidím do toho, co dělám, protože jsem s příslušnou stranickou problematikou denně v kontaktu" a "jsem externí dodavatel, kterému je nutno přesně vysvětlit, jak se to má chovat"), takže jsme u externisty minimálně na dvojnásobku času od vzniku poptávky po dodání výsledku.
(Aneb klasické "někdy je rychlejší něco udělat sám než jinému vysvětlovat jak to má udělat" - neplatí samozřejmě o činnostech, u nichž se předpokládá budoucí opakování.)

[Martin.Rejman]

Děkuji za slušnou reakci, přidávám své

Dovolím si ještě reagovat na následující dva body (k ostatním bodům jsem už dříve svoje názory napsal, takže nebudu plevelit diskusi jejich opakováním, není mým cílem jimi umlátit ostatní do bezvědomí ):

1.7mega není tak vysoká cena za požadovaný objem práce.

Zde tedy mohu dodat, že aplikace Proplácení jak je teď online vznikala asi 7 dní soudě podle datumů dní, které jsou uvedeny v GITu plus dva navíc, než se to tam dostalo. A to se na tom nepracovalo každý den celý den.

Taky je hotový jen prototyp. Abychom to mohli porovnávat, tak nejen že se to musí dotáhnout a nasadit, ale taky doplnit funkčnost, která je ve specifikaci a klikátko ji ještě neumí, ale hlavně se to musí potom 8 let provozovat a podporovat. Cena zakázky zahrnuje i ten provoz a podporu, aktualizace a soulad s legislativou, to bude v budoucnu taky stát mnoho člověkodní, když bychom to dělali vlastními silami (neříkám že je to špatně, jen bychom neměli vyvolávat dojem, že nasazením stávajícího klikátka do produkce práce končí nebo je z většiny hotová).

PS: Nijak nezpochybňuju, že 7 dní je hodně dobrý výsledek vzhledem k rozsahu funkcí a kvalitě stávající verze. Klobouk dolů!

Prosím, nenazývejme to klikátkem - je to reálná aplikace připravená po vzoru nalodeni.pirati.cz do ostrého provozu na našich serverech. Což se o této closed-source službě nikdy nebude dát říct.

Provoz a podpora jsou tam v tom smyslu, že dodavatel očekává, že nezkrachuje. Reálně finance padnou na vývoj, a my dáme značku Piráti na produkt 2kúčetnictví. Následná podpora bude již boj o to, co ve skutečnosti dostaneme. Vždyť k tomu není ani uživatelská dokumentace - a podle toho, co jsem naklikal, to rozhodně nemusí být vždy intuitivní. Kontrolní otázka z app.2kucetnictvi.cz : jaká je default akce na formuláři pro založení faktury ? Nápověda: není to uložení faktury. A volba pro "neuložení změn" chybí rovněž. Např. pokud si otevřu znovu již vytvořenou fakturu, proč vidím možnost "vybrat zákazníka", když už mám kolonky vyplněné od minule ? Co když uživatel omylem někoho vybere v selectboxu, a pak to uloží ... vyplněné hodnoty budou ztraceny ? Opravdu chceme, aby takto vznikl SW, o kterém se bude říkat, že ho zadali Piráti a ta firma ho tak bude prezenovat ?

Jo takhle. Asi by to bylo dobré, ale nemyslím že je to teď zásadní otázka s vlivem na hlasování o přezkumu. S tím, že budou vícenáklady za extra vývoj (a že to může docela naskákat, když budeme chtít hodně vývoje) jsme se už bavili - je celkem buřt, jestli to je za grafiku nebo něco jiného.

Rovnou tedy již počítáme s tím, že to bude stát ještě víc, než je nyní schváleno ? Snad se nedostaneme do profesionální ligy veřejných zakázek, kde je navýšení i v řádu desítek procent.

Ještě jsem nezažil projekt, kde by specifikace na začátku projektu obsahovala všechno a nepřišlo se na nic, co by bylo třeba doplnit nebo měnit, přitom to ale neznamenalo, že byly špatně připravené. Některé otázky prostě zazní teprve až ve chvíli, kdy to někdo začne implementovat a integrovat - a bude to tak i s tvým řešením.

Problém navyšování veřejných zakázek je v netransparentnosti, záměrné nevýhodnosti smluv a záměrně nekvalitních zadáních. Tenhle problém nevidím, vícepráce jsou v diskutované smlouvě podchyceny úplně standardně a na specifikaci se poctivě pracuje, aby byla co nejúplnější.

Pokud se tedy obecně ví, že potřebné požadavky vyplynou až při implementaci, je třeba jiný projektový management a stávající model (specifikace - smlouva) je nefunkční. Pro tyto případy existují např. agilní metodiky vývoje SW. A ty se opírají o "best-practice":

• postupný rozvoj,
• průběžné psaní testů,
• kvalitní předběžnou analýzu,
• cílenou tvorbu zdrojových kódů tak, aby bylo možné reagovat na změny požadavků

Pokud je Pirátský skin alespoň domluven, dobře. Já jsem ho tam nikde nenašel.

[Jiri.Snizek]

Veřejně vyjadřuji podporu přezkumu a zrušení rozhodnutí republikového předsednictva.

[Jan.Korbel]

Martine muzes prosim jeste shrnout, jake funkce se prekryvaji mezi tim, co uz ted mas (+ tim, co planujes mit nebo bys v rozumne dobe a s rozumnym usilim mohl mit) a tim, co by melo vzniknout komercne? Podle vseho neplanujes implementovat vsechno ze zadani (EET, ...?) - urcite i s vidinou toho, ze vytvaris docasny system.

Co by tedy zbylo na pripadne nove vyberko, pokud by se jako finalni reseni zacalo pouzivat to cos vyrobil? A co by (na rozdil od kompletni externi dodavky) zustalo "doma"? Dekuji.

[Jan.Hora]

Nasazení s funkčností "rozpočty-záměry-proplácení" by měla být, podle toho co vím, otázka jednotek dnů.
...
Věřím Martinovi (na základě praktických výsledků, které již předvedl), že zbylou funkčnost dokáže doplnit během dalšího měsíce, a to bez negativního dopadu na jinou jeho činnost pro stranu.
...

ale hlavně se to musí potom 8 let provozovat a podporovat.

Tady nechám odpověď na Martinovi nebo někom jiném IT zdatnějším než já.

Shrnu to: Tohle vše je třeba připočíst k těm sedmi dnům. Už ty sám jsi tam popsal dalších 30 dnů jen na vývoj a do provozu jsi se ani nepouštěl.
Neříkám že to Martin nezvládne, ani že je pomalý (naopak postupuje nadprůměrně rychle). Říkám jen že není moc relevantní, co se stihlo za sedm dnů, protože to není s čím porovnat. Srovnávat jde pracnost a náklady toho, co je obsahem smlouvy (což nemůžeme, protože nemáme dvě kompletní a porovnatelné nabídky řešení). Nyní můžeme pouze říct, že Martin vyrobil velmi rychle kvalitní prototyp a uměl by si s celým zadáním poradit nadprůměrně rychle. Neposouvejme to nikam jinam, měli bychom porovnávat výsledný stav, jeho pracnost a náklady, to byla podstata mé výhrady k tomu argumentu.

Prosím, neopakuj už ten mýtus o souladu s legislativou. Dodržení legislativy má zajistit dodavatel účetních služeb (má to i ve smlouvě), to není věcí nadstavbové aplikace pro naše interní procesy.

To ano. Má to ve smlouvě i dodavatel nadstavby, protože tam je to potřeba taky. Když si nadstavbu budeme dělat sami, tak si i ten soulad nadstavby zajišťujeme s právem sami. Pokud tvrdíš, že na nadstavbě se změny legislativy vůbec neprojeví, tak se pleteš - je to na 8 let, za tak dlouhou dobu nějaké změny v tom účtu budou a otázka pouze zní, jak budou složité a kolik jich bude nutné nějak promítnout do nadstavby. Nepochybuju, že zrovna Martin je v budoucnu zvládne přinejmenším stejně dobře, jako externí firma, ale netvrď že všechno řeší smlouva na účto, to prostě není pravda, takhle to v reálu nezafunguje.

Vtip je ovšem v tom, že když budeme něco potřebovat upravit ve vlastní aplikaci, pravděpodobně to bude trvat srovnatelně dlouho jako psaní specifikace té úpravy pro externího dodavatele. No a ten externí dodavatel na implementaci bude nejspíš taky potřebovat víc času než my (což je dáno rozdílem mezi "vidím do toho, co dělám, protože jsem s příslušnou stranickou problematikou denně v kontaktu" a "jsem externí dodavatel, kterému je nutno přesně vysvětlit, jak se to má chovat"), takže jsme u externisty minimálně na dvojnásobku času od vzniku poptávky po dodání výsledku.
(Aneb klasické "někdy je rychlejší něco udělat sám než jinému vysvětlovat jak to má udělat" - neplatí samozřejmě o činnostech, u nichž se předpokládá budoucí opakování.)

A nebo taky naopak, protože se může projevit efekt "když za to neplatím, dám si na čas" případně "paralýza analýzou". A nebo se to vzájemně vyruší a vyjde to na stejno. Tady se bavíme "co by - kdyby", protože záleží na tom, jak je řízen projekt na straně dodavatele (externího nebo interního) i odběratele. Fakt to není relevantní téma pro rozhodování v téhle věci.

Prosím, nenazývejme to klikátkem - je to reálná aplikace připravená po vzoru nalodeni.pirati.cz do ostrého provozu na našich serverech. Což se o této closed-source službě nikdy nebude dát říct.

Nemyslel jsem to nijak pejorativně. Jak se to teda oficálně jmenuje? Url mi jako název nepřijde zrovna přehledné, což takhle PiroPlácení?

Provoz a podpora jsou tam v tom smyslu, že dodavatel očekává, že nezkrachuje. Reálně finance padnou na vývoj, a my dáme značku Piráti na produkt 2kúčetnictví. Následná podpora bude již boj o to, co ve skutečnosti dostaneme. Vždyť k tomu není ani uživatelská dokumentace - a podle toho, co jsem naklikal, to rozhodně nemusí být vždy intuitivní. Kontrolní otázka z app.2kucetnictvi.cz : jaká je default akce na formuláři pro založení faktury ? Nápověda: není to uložení faktury. A volba pro "neuložení změn" chybí rovněž. Např. pokud si otevřu znovu již vytvořenou fakturu, proč vidím možnost "vybrat zákazníka", když už mám kolonky vyplněné od minule ? Co když uživatel omylem někoho vybere v selectboxu, a pak to uloží ... vyplněné hodnoty budou ztraceny ? Opravdu chceme, aby takto vznikl SW, o kterém se bude říkat, že ho zadali Piráti a ta firma ho tak bude prezenovat ?

Reálně IMHO většina peněz padne na provoz a na vícepráce. Upřímně - ať ten SW vyrobíme jakkoliv, tak tam po cestě nějaké nedostatky budou a budou pak opraveny. Proto dneska jede iterativní agilní vývoj - máš to tam vždycky a tohle je nejlepší způsob, jak to řešit, liší se to jen rozsahem a strukturou iterací (podle toho, jestli to děláš inhouse nebo externě).

Navíc ideální pirátský software (doma vyvinutý, open-source,atd.) má jednu vadu pro tu propagaci - že takhle nikdy ve státní správě nemůže vzniknout, protože státní správa na to nemá lidi. Ta vypíše výběrko, přihlásí se externí firmy a ona si nějakou vybere. A může se (a bude) stávat, že i když budou chtít opensource, tak ho nikdo nenabídne, na tom není nic špatného. To, čím jdeme příkladem, je hlavně výsledné řešení a proces jeho výběru a psaní specky (nikoliv její dokonalost, byť bych to taky uvítal). A tady máme jedinou chybu, že jsme si zbytečně na začátku omezili soutěžící tím sloučením služeb (ale upřímně, mě by to taky v tu chvíli taky nenapadlo). A tahle chyba prostě za rušení toho rozhodnutí IMHO nestojí.

Pokud se tedy obecně ví, že potřebné požadavky vyplynou až při implementaci, je třeba jiný projektový management a stávající model (specifikace - smlouva) je nefunkční. Pro tyto případy existují např. agilní metodiky vývoje SW. A ty se opírají o "best-practice":

• postupný rozvoj,
• průběžné psaní testů,
• kvalitní předběžnou analýzu,
• cílenou tvorbu zdrojových kódů tak, aby bylo možné reagovat na změny požadavků

Tahle metodika (resp metodika postavená na těchto zásadách) je moje oblíbená - je přehlednější a ideální pro inhouse vývoj, v případě externího dodavatele ale zvedá nabídkovou cenu (a docela dost - iterativní vývoj tímhle způsobem výrazně zlepšuje kvalitu výsledného produktu, ale taky logický zvedá pracnost). Tady se můžu jen dohadovat, ale myslím že externí dodavatel tohle nenabídl hlavně kvůli obavě, že by pak měl nekonkurenční cenovou nabídku. Ale pro inhouse vývoj je tohle ta nejlepší cesta, kterou znám, to se shodneme.

[Martin.Kucera]

Co by tedy zbylo na pripadne nove vyberko, pokud by se jako finalni reseni zacalo pouzivat to cos vyrobil? A co by (na rozdil od kompletni externi dodavky) zustalo "doma"? Dekuji.

Když srovnám specifikaci s tím, co Martinova aplikace umí a co (podle toho, jaké informace si ode mě vyžádal) má umět, tak oproti té specifikaci bude chybět nanejvýš
9. Vystavování faktur a seznamy faktur
10. Vystavování pokladních dokladů vč. EET a seznamy pokladních dokladů
což jako strana stejně pokud vím neděláme.

Shrnu to: Tohle vše je třeba připočíst k těm sedmi dnům. Už ty sám jsi tam popsal dalších 30 dnů jen na vývoj a do provozu jsi se ani nepouštěl.

Zatímco ta firma má jen na vývoj dnů 90 (poznámce o nepouštění se do provozu nerozumím).

Což mi připomnělo další rozdíl - Martinovo Piroplácení je možné připomínkovat a testovat (a to lidmi, kteří ho budou reálně používat) průběžně při vývoji, tohle nám asi ten externí dodavatel nezajistí, což? (Aspoň ve specifikaci ani harmonogramu nic takového není, je tam 3. 10. zahájení testovacího provozu a 14. 10. zahájení rutinního provozu.)

[Jan.Hora]

Když srovnám specifikaci s tím, co Martinova aplikace umí a co (podle toho, jaké informace si ode mě vyžádal) má umět, tak oproti té specifikaci bude chybět nanejvýš
9. Vystavování faktur a seznamy faktur
10. Vystavování pokladních dokladů vč. EET a seznamy pokladních dokladů
což jako strana stejně pokud vím neděláme.

Tak tady to je těžká debata - jestli to potřebujeme, tak tyhle dvě funkcionality jsou zrovna masakr. Ale to co má umět PiroPlácení není totéž, co má umět nadstavba nad 2k, ta je mnohem širší - proto to nechci porovnávat, jsou to dvě věci, co mají průnik, ale nejsou rozsahem stejné.

Zatímco ta firma má jen na vývoj dnů 90 (poznámce o nepouštění se do provozu nerozumím).

Což mi připomnělo další rozdíl - Martinovo Piroplácení je možné připomínkovat a testovat (a to lidmi, kteří ho budou reálně používat) průběžně při vývoji, tohle nám asi ten externí dodavatel nezajistí, což? (Aspoň ve specifikaci ani harmonogramu nic takového není, je tam 3. 10. zahájení testovacího provozu a 14. 10. zahájení rutinního provozu.)

Právě že testování a opravy jsou časožravé. Pokud Martin vyvine aplikaci do 30 dnů, ještě nějakou dobu se bude ladit a testovat, než to bude fakt plně v provozu. Když to dodává externista, tak je formálně aplikace nepřevzatá, tj. se tam nechává dostatečný buffer, aby stihl nechat nás to otestovat, opravit vady a dostat to do stavu, kdy podepíšeme akceptaci. 90 dnů mi přijde celkem v pohodě (30 dní vývoj, 30 dní testy a opravy, 30 dní buffer na průšvihy).
Tím se dostáváme k tomu testování - průběžné testování nemá smysl, když si na to najímáš externí firmu. Necháš si formou kontrolních dní ukazovat progress (abys viděl, jestli vývoj běží normální rychlostí - když víš o čem je IT projekt, tak z toho poznáš, jestli jedou podle plánu nebo se rýsuje problém) a na konci uděláš takzvané akceptační testy (UAT). Ty jsou dopředu popsané, protože na jejich základě se provede (nebo neprovede) převzetí do provozu. Občas se dělá průběžná akceptace, což má u nás podobu specky pro první fázi a specky kompletního řešení a odpovídající formulace ve smlouvě. Tj. i akceptace se bude muset udělat dvakrát (přeci jen už to je dost velký projekt, aby stál za dvě kola akceptačních testů a související práce kolem toho). Tím se otvírá onen prostor k připomínkování a soupisu požadavků do budoucna, pokud se přijde na to, že jsme něco zásadního zapomněli napsat do specky nebo se něco z původních požadavků změnilo od doby podpisu smlouvy do akceptace.

A tou poznámkou o provozu jsem myslel to, že provoz a údržba je podstatnou částí ceny. Je to na osm let a celou tu dobu někdo bude muset dělat helpdesk, řešit aktualizace, musí se platit a obnovovat hardware. To je pro dodavatele spousta nákladů, které do té ceny promítl.

[Vit.Fux]

Vážení přátelé,

do kauzy jsem se nezapojoval, dovolím si proto přidat komentář z pohledu pozorovatele. Shrnutí "zajímavostí" pro naplnění demokratického minima:

1) výběrové řízení
* výběrové řízení na dodavatele účetních služeb nebylo standardně vyhlášeno v sekci veřejných výběrových řízení, ale bylo vyhlášeno v oznámeních a nebylo zmíněno v newsletteru
* zadání výběrového řízení bylo nereálné a zadání bylo zpětně upraveno podle podmínek které si nadiktovali účastníci výběrového řízení
* výběrové řízení nikdo nevyhrál, výsledkem bylo to, že se zakázka rozdělila na dvě samostatné služby a smlouvy, mezi dvě různé firmy:
-- P&N Holding s.r.o. - která poskytuje účetní služby a zajišťuje, že veškeré účetnictví budeme mít v pořádku, viz. smlouva
-- SPIEW s.r.o. - která vyvine a bude provozovat nástavbu nad účetním softwarem pro zjednodušení potřeb Pirátské strany, dle našich předpisů (rozpočty, záměry, proplácení, atp.)
* Smlouva na účetní služby platí, a tento mimořádný přezkum se jí nijak netýká. Předmětem tohoto mimořádného přezkumu je druhá smlouva na nástavbu nad účetním softwarem.
* Protože na nástavbu nebylo vyhlášeno samostatné výběrové řízení, nemohly se ho účastnit dodavatelé SW řešení, kteří zároveň neprovozují účetní služby (které pro nástavbu nejsou potřeba). A bez řádné soutěže nevíme, jestli zakázka například není nebo je předražená (jako člověk z oboru si myslím, že je hodně předražená ).
* Výběrové řízení bylo uděláno tak špatně, že ho musela řešit KK, a chce/chtěla ho zrušit.

2) smlouva na softwarovou nástavbu
* Jde o smlouvu na pronájem SW, který ale pronajímatel nemá. My máme zaplatit jeho vývoj, přičemž ho nebudeme vlastnit (autorská práva, zdrojové kódy).
* Je to model vývoje a provozu SW obvyklý snad jen ve státní správě (koupím si něco, co mi ve výsledku nepatří), který jako Piráti kritizujeme a snažíme se změnit. Jde také proti našemu standardu pro nové aplikace používané Pirátskou stranou (na kterém se mimochodem Jakub Michálek podílel).
* Smlouva by vytvořila závazek na 8 let dopředu, což je u software poskytovaného jako služba velmi nestandardní. Obvyklé je platit měsíčně, maximálně na rok dopředu (kvůli nějaké slevě). (Vyjímečně na delší dobu, ale v situacích, kdy jde o řádově vyšší částky.)

3) schválení smlouvy
* ke smlouvě měly mnoho výtek členové RV, TO, právnící, a další
* Vzhledem k výše uvedenému RV záměr 19.3. neschválil. Ale hned za 2 dny, aniž by se cokoliv zásadně změnilo, proběhlo opakované hlasování RV, kde byl záměr schválen (to jsme si z parlamentu teda přinesli pěkné praktiky ).
* RK vydala předběžné opatření proti podpisu smlouvy a řešila, zda-li na základě podnětu KK zruší celé výběrové řízení.
* nekteré výtky byly do smlouvy zapracovány, ale většina ne
* 18.6. RP smlouvu schválilo. Prakticky v době, kdy platilo předběžné opatření RK. V té době se jednalo o smíru, ale ten byl RK oznámen až 21.6..
* jednání KK a RK jestě neskončilo, objevují se nové závažné skutečnosti

4) mimořádný přezkum
* 20.6. byl podán členský podnět pro mimořádný přezkum rozhodnutí RP o podpisu smouvy na nástavbu
* někdo hodně nechtěl, aby to CF projednalo, diskuse byla například plná lživých a závádějicích informací, že zrušením smlouvy na nástavbu přijdeme také o účetnictví, které ho se to ale vůbec netýká
* probíhal lobbing pro nepodpoření členského podnětu WTF?! Zavedeme si registr lobbystických kontaktů pro politikaření ve straně?!

A pravděpodobně jsem si spousty dalších věcí nevšiml.

-------------------------------------------------------------------------------------

Když to shrnu, celé to hrozně smrdí. Podpisem nevýhodné smlouvy na nástavbu účetnictví rezignujeme na Pirátské ideály a naše vlastní stanovy a další předpisy. Rezignujeme na princip toho, že sami děláme věci, které jako Piráti prosazujeme. Stala se toho kauza plná vnitřního politikaření a lobbingu. Termíny a tlaky na urychlené schválení jsou velmi podezřelé. Dochází k porušování a ohýbání předpisů. A za jakou cenu? Jak se podařilo ten paskvil protlačit přes RV, RP, KK a RK? Vydírá nás někdo nebo co?! Nechápu to...

Jaké je východisko? Martin Rejman už ukázal, že si tu nástavbu dokážeme udělat sami, mnohem rychleji a levněji. A jsme Piráti, není na to sám, já a další lidi přiložíme ruku k dílu. Když to budeme chtít rychle, tak zhruba za pětinu až desetinu ceny toho smluvního řešení si to můžeme nechat celé naprogramovat. S tím že zdrojové kódy a vlastnictví SW bude naše, můžeme to poskytnout jako OpenSource, můžeme si sami dělat potřebné úpravy. Případně můžeme udělat nové výběrové řízení podle předpisů, s dobrým zadáním, jako skutečnou soutěž, kde budeme vybírat z různých řešení. Možností je sposuta, a jsou lepší než výše zmíněná smlouva.

Já osobně nemám chuť rezignovat na Pirátské ideály a tento členský podnět, zrušení té smlouvy na SW nástavbu účetnictví, pro klidné svědomí podpořím.

[Martin.Kucera]

Právě že testování a opravy jsou časožravé. Pokud Martin vyvine aplikaci do 30 dnů, ještě nějakou dobu se bude ladit a testovat, než to bude fakt plně v provozu. Když to dodává externista, tak je formálně aplikace nepřevzatá, tj. se tam nechává dostatečný buffer, aby stihl nechat nás to otestovat, opravit vady a dostat to do stavu, kdy podepíšeme akceptaci. 90 dnů mi přijde celkem v pohodě (30 dní vývoj, 30 dní testy a opravy, 30 dní buffer na průšvihy).

Jenže v harmonogramu to je poněkud jinak:
Fáze 1 - Zkušební provoz - 3.10.2018
Fáze 1 - Rutinní provoz - 14.10.2018
Fáze 1 - Předání - 17.10.2018

Nikde tam nevidím, že by bylo možné testovat dřív než po těch 90 dnech.