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

[Jan.Hora]

A je dost videt, jak jsme po volbach ztratili smysl pro hodnotu penez - kdyz tady Honza nepovazuje moznou ztratu napr. 1M Kc za prilis velke riziko.

Ten zbytek tvého postu je celkem trefné shrnutí kritiky, takže ho ponechám bez komentáře (ať se každý rozhodne, jestli souhlasí nebo nikoliv), ale na to poslední zareagovat musím - považuju celý projekt za rozumný z hlediska nákladů a přínosů (IMHO na tom základu dodavatel nic moc nevydělá ani když to vyvine na první dobrou a bez obvyklých reworků na své náklady, které se obvykle na takovém projektu před releasem objeví a ukousnou dodavateli ze zisku), přičemž riziko, že ztratíme celou částku (nebo takovou část, že budeme v mínusu) hodnotím jako dobře řízené.

Jinými slovy, pokud by ten projekt nejdbože fakt selhal, tak nad tou částkou nemávnu rukou, ale půjdu tvrdě po příčinách - a bude-li jejich původcem chyba na naší straně nedbalostní povahy, tak viníka roznesu na kopytech za to, že promarnil drahocenné prostředky.

Že nehodnotím riziko jako vysoká (samozřejmě beru že nesouhlasíš) neznamená, že bych si nebyl vědom hodnoty těch peněz, které za to zaplatíme.

PS: pot commited slyším prvně mimo pokerovou oblast, jdu si to radši nastudovat, než se rozhodnu, jestli tomu začnu oponovat

Když budu mít zdrojáky a vyměním dodavatele účetních služeb, stačí úprava (ano, samozřejmě za ni může být příslušný programátor zaplacen), aby aplikace komunikovala s API účetního SW používaného dodavatelem.
Když nebudu mít zdrojáky, jsem vydán na milost správci aplikace, jestli bude ochoten takovou úpravu vůbec provést (a pokud ano, na kolik si ji nacení).

Teoreticky ano, ale prakticky se tahle páka málokdy vyplatí využít. Spíš pokud máš problém tohoto typu, tak měníš nakonec celého dodavatele (a z důvodů již uvedených obvykle i řešení, protože průšvihový projekt bude málokdy někdo ochotný převzít - jednou jsem byl v pozici "přebírajícího dodavatele" a už bych do toho nikdy znova nešel)

[Martin.Kucera]

Když budu mít zdrojáky a vyměním dodavatele účetních služeb, stačí úprava (ano, samozřejmě za ni může být příslušný programátor zaplacen), aby aplikace komunikovala s API účetního SW používaného dodavatelem.
Když nebudu mít zdrojáky, jsem vydán na milost správci aplikace, jestli bude ochoten takovou úpravu vůbec provést (a pokud ano, na kolik si ji nacení).

Teoreticky ano, ale prakticky se tahle páka málokdy vyplatí využít. Spíš pokud máš problém tohoto typu, tak měníš nakonec celého dodavatele (a z důvodů již uvedených obvykle i řešení, protože průšvihový projekt bude málokdy někdo ochotný převzít - jednou jsem byl v pozici "přebírajícího dodavatele" a už bych do toho nikdy znova nešel)

Jenže tady je řeč o tom, že průšvihová by nebyla aplikace, nýbrž dodavatel účetních služeb (toho bychom chtěli vyměnit). Tj. žádný průšvihový projekt by v takovém případě nikdo nepřebíral, bylo by potřeba do neprůšvihového projektu dodělat komunikaci s API účetního SW nového dodavatele (pokud by používal jiný SW než ten předchozí dodavatel).

[Vit.Fux]

Nicméně já si myslím, že tu smlouvu stejně nebudeme moc uzavřít i když ji vypilujeme k dokonalosti, protože by to znamenalo útratu 1.700.000 Kč bez výběrového řízení. Původní výběrko je příliš daleko od toho k čemu jsme se už dostali, že se nedá počítat.

[Jan.Hora]

Jo takhle - v tom případě ale problém není, měníš dodavatele účetních služeb, takže doděláváš (nebo v rámci nové zakázky necháváš zajistit) API z jeho systému, které může konzumovat už používaná nadstavba (samozřejmě očekávám, že i když nový dodavatel pojede na FlexiBee, tak tam nějaký ten dovývoj bude).

Samozřejmě nezpochybňuju fakt, že je lepší a pohodlnější mít zdrojáky k dispozici a ne jen v úschově u notáře (třeba bych si uměl představit jednou za rok nechat udělat TO namátkové code review, abychom si kontrolovali, že dodavatel drží kvalitu kódu na žádoucí úrovni). Jen se mi zdá nepravděpodobné, že by nás to reálně mělo v budoucnosti kousnout, a že je kvůli tomu potřeba přezkoumávat rozhodnutí.

[Martin.Kucera]

Jo takhle - v tom případě ale problém není, měníš dodavatele účetních služeb, takže doděláváš (nebo v rámci nové zakázky necháváš zajistit) API z jeho systému, které může konzumovat už používaná nadstavba (samozřejmě očekávám, že i když nový dodavatel pojede na FlexiBee, tak tam nějaký ten dovývoj bude).

A když dodavatel aplikace odmítne (což bohužel asi může) to nové napojení dodělat?

[Jan.Hora]

Tak ho ugriluješ na smlouvě na bodě 5.9. - poskytovatel je povinen poskytovat služby nezbytné pro bezchybný provoz, což jednoznačně je i funkční API na jeho straně aplikace.

[Ivo.Vasicek]

A to by nám uškodilo v čem přesně, když projekt má být stejně dodán až po volbách? Pak už měsíc navíc hraje zanedbatelnou roli.

Měsíc to fakt nebude Měsíc zabere jen příprava nového výběrka, doladění specky, pak ho vyhlásit, provést, vyhodnotit, připravit projekt, ověřit prototyp vůči specce a začít. Je to 3-6 měsíců, podle toho, jak rychle bude trvat ten začátek. To mě osobně přijde jako hodně vysoká cena.

Lze to stihnout do měsíce v pohodě. Zadávací dokumentace může být klidně i do čtrnácti dnů, výběrko může taky trvat 14 dnů - stačí krom veřejné výzvy aktivně obeslat cca 5 firem. Navíc RP nemusí čekat na toto jednání, může zadat nové výběrko (zpracování) hned. Tvá ničím nepodložená spekulace 3-6 měsíců je mimo realitu.

[Jan.Hora]

Má tvrzení jsou podložená zkušenostmi, dokonce s projekty obdobné velikosti. Žádný z nich netrval od začátku přípravy výběrka do podepsání smlouvy 14 dní a to ani v případě, že šlo o situaci, kdy jsme měli hotové řešení a firma nás sama oslovila, že ho chce, vypíše výběrko ať se přihlásíme. Lidi spolu musí komunikovat a jelikož mají i jiné povinnosti, tak to chvíli trvá, než se všechno připraví, provede, dotáhne a podepíše.

Ostatně ukaž mi pirátské výběrko, které od chvíle, kdy se řeklo "uděláme výběrko" do podpisu smlouvy nebo objednávky (nebo ekvivalentního rozhodnutí při dodání vlastními zdroji) trvalo 14 dnů. To budou tak maximálně kampaňovací stánky nebo kancelářské potřeby. Napsal jsem dlouhý elaborát, ale pak jsem ho zase smazal, je to jen opakování prvního odstavce.

Mimochodem pokud by výběrko trvalo 14 dní, tak to není moc času na přípravu kvalitní nabídky - omezil by sis tím účastníky, protože se ti nepřihlásí firmy, co nerady šijí nabídky horkou jehlou. A podmínky vedoucí k omezení počtu účastníků je jedna z věcí, která je na současném výběrku mohutně kritizována.

[Rostislav.Reha]

S Martinovym resenim nas nic az tak nehoni - stejne bude driv nez to zvladne tahle firma podle kritizovaneho navrhu smlouvy.

[Vaclav.Fortik]

Rád bych rovněž přidal pár komentářů a reakcí na tvrzení uvedená v jednání. Jelikož mnohé již bylo uvedeno, začnu poněkud šířeji.

Osobně vnímám Pirátskou stranu jako tu, která má aktivně přicházet s řešeními, která jsou přínosná pro širší společnost. Téma svobodného software žádná jiná strana neakcentuje. Měli bychom to být především my, kdo se bude snažit ukázat, že lze vyvíjet kvalitní a dostupný software, a že existuje i jiná cesta. Jak velice pěkně shrnul Jan Lipavský zde (viewtopic.php?f=637&p=569240#p569240), je podpora open-source aplikací v našem programu, ale i členské základně, významně zakotvena.

Chceme být vzorem v IT, nikoliv referencí toho, jak se to v ČR nyní musí dělat (potřebné argumenty pro obhajobu validity řešení shrnul výborně Honza Hora zde: viewtopic.php?f=477&t=42346&start=20#p568989), protože k tomu nejsou odborné kapacity a prostředky. Sami poukazujeme ve státní správě na netransparentní smlouvy, různé úpravy zadávacích dokumentací. Právě netransparentnost a přílišná náročnost odrazuje podnikatele od účasti na státních zakázách.

Máme best-practice (https://wiki.pirati.cz/to/standart_pro_aplikace), pomocí které chceme dosáhnout kvality SW. Např. již pouhá přítomnost aplikačních testů zajistí, že:

• nové vlastnosti programu se mohou přidávat pružně, je totiž možné ověřit, že to nenarušilo zbytek systému,
• pokračovat ve vývoji může kdokoliv - pokud někdo něco upraví, a přestanou fungovat testy, ví se, co se má kde opravit,
• součástí testů bývá i popis testovaných funkcí - dokumentace k aplikace tak vzniká organicky, již během kvalitní realizace.

Propagujme tedy standardy tvorby SW, jejich vzájemnou datovou výměnu formou API nebo ve státní správě tzv. OpenData rozhraní. Můžeme ukázat, že to lze realizovat.

Jelikož termín realizace a dodání prvních úprav je až v říjnu, je třeba zajistit lepší proplácení již nyní, což lze díky prototypu dostupnému zde (https://piroplaceni.kouzelnakrabicka.cz/) a jehož spuštění by se mělo podařit v nejbližší době. Díky tomu nejsme v časové tísni na podpis smlouvy, AFAIK minimálně co se procesu proplácení (a případně párování darů a aktualizací rozpočtů s tím souvisejících) týká. Prototyp by měl být dopracován do následujícího stavu:

• možnost zadávat střediska a organizační složky schvalující záměry a položky rozpočtů,
• zadávání rozpočtů, jejich kapitol, podkapitol a položek včetně sledování jejich vyčerpání,
• schvalování položek a záměrů, zadávání a schvalování žádostí o proplacení,
• napojení na bankovní účty a přenášení příchozích plateb do schvalovatelné podoby (např. některé dary je možno odmítnout),
• po schválení příchozí platby navazuje převod financí do rozpočtu a případné navýšení položek / záměrů.
• evidence nepeněžních darů a jejich finančního ekvivalentu - následné generování sestavy pro dohledový úřad - UDHPSH - ve formě https://zpravy.udhpsh.cz/zprava/ps2017/pirati

Pokud se aplikace osvědčí, nabízí se další integrace, které povedou k automatizaci byrokracie, např. generování faktur pro dodavatele Pirátů - faktura se vygeneruje v aplikaci, následně se rovnou zařadí do žádostí o proplacení.


Dále uvádím odpovědi na otázky z diskuse:

Otázka na Martina Rejmana: Ty si tedy myslíš, že tvá aplikace může eventuálně umět všechno, co čekáme od té dojednávané? A že to TO nesebere kapacitu řešit jiné zanedbané potřeby strany (a že jich je spousta...)? Můžu jako člen RV udělat něco, co by pomohlo rychlému nasazení tvojí aplikace, nebo i tomu, aby byl její rozvoj brán jako vážná alternativa?

Vytvořená aplikace Piroplácení zajistí agendu, která spotřebovává čas všem. Od dodaného řešení je jistě očekáváno více, např. EET implementovat není cílem.

Ohledně pracovních kapacit TO - aplikace https://piroplaceni.kouzelnakrabicka.cz/ tvoří technologický celek (Python - Django - Bootstrap Vue.js - REST API - SSO Keycloak), který bude opakovaně využit i pro další aplikace. Rozvojem této aplikace tak zároveň získáváme lepší možnosti pro:

• nalodeni.pirati.cz - které již běží v pilotním provozu. Např. tabulková komponenta z Proplácení bude rovněž přenesena tam, takže umožní plynulé vyhledávání v seznamu dobrovolníků a dalších lidí, kteří se nám přihlásí. Dle mého názoru je tato komponenta klíčová i pro dobrou prezentaci "transparentního účetnictví" Pirátů veřejnosti - je dobré mít pěkné hledání ve fulltextu záznamů, které se zobrazují.
• people.pirati.cz - nová evidence členů - díky REST API bude mít oddělenou datovou základnu od Nalodění, potřebná data si bude vyměňovat dle potřeby.
• aplikace pro řízení chodu schůzí poslanecké sněmovny - v součané době je to řešeno pomocí Google tabulek, které jsou zcela nedostatečné z pohledu řízení procesu a oprávnění k editaci dat v nich obsažených
• libovolné další, které budeme chtít - jednotné technologie, a zároveň jejich možná variabilita, umožní zapojení dobrovolníků, kteří nám chtějí s IT aktivně pomáhat.

Reálný stav je nyní ten, že Proplácení je jediná varianta pro následující tři měsíce - máme již připraven plán na přechod, měl by být prodiskutován na setkání vedoucích odborů. Musíme totiž vyřešit i návazné otázky, které např. zde v diskusi ještě nepadly: jaká data se mají kam importovat, data o záměrech v současné době v DB podobě ani moc asi neexistují. Ale pozitivní je, že asi dokážeme data za rok 2018 do Proplácení dostat.

Jako vážnou alternativu si aplikaci ozkoušelo v současné době asi 24 lidí (https://piroplaceni.kouzelnakrabicka.cz/rest/users/), kteří se tam přihlásili. Pouze přihlášení uživatelé mají možnost zobrazit si formulář s přidáním záměru, žádosti o proplacení nebo nové rozpočtové položky. Pro další rozvoj dle plánu výše bude třeba zpětné reakce klíčových uživatelů.

Konečně věřím, že předkládaná varianta představuje jediné schůdné řešení, které povede v rozumné době k požadovaným výsledkům. Jak vůči členské základně, tak vůči voličům máme povinnost představit co nejdříve funkční a stabilní systém.

Pro následující 3 měsíce je Proplácení jedinou variantou, nic jiného se nestihne realizovat. Vůči voličům máme pak povinnost dodržovat prezentovaný volební program, což by spíše znamenalo, že ukážem, jak podporujeme opensource. To, že umíme být transparentní, již voliči vidí např. na smlouvy.pirati.cz .

Pokud bychom se od navrhovaného řešení chtěli odchýlit, museli bychom vypsat nové výběrové řízení, protože Martin Rejman je najatý jako L2 podpora, nikoli jako programátor rozpočtového systému navázaného na účetní systém, a vzhledem k rozsahu projektu není reálné očekávat, že by byl schopný celý systém postavit sám ve svém volném čase. Nic to nemění na tom, že Martinem navržené zjednodušení zadávání žádostí jako vedoucí FO rád podpořím k implementaci, protože sice neušetří mnoho práce samotnému FO, ale slibuje významnou časovou úsporu při zadávání žádostí o proplacení, což je problém, který členskou základnu nyní trápí ze všech nejvíc.

Jak uvedeno výše, součástí řešení Proplácení je i softwarová platforma, která umožní další udržitelný rozvoj pirátských aplikací. Je to tedy spíše naopak - řešením jedné aplikace získáváme know-how pro naše další aplikace.

Volný čas ... to je ten, kdy se spí ?

Proč si to strana neudělá sama/od člena/od známého?
Politická strana není softwarová firma. Má důležitější věci na práci, např. měnit státní správu k lepšímu.
Jeden člověk nemůže dodat servis jako firma. Není tam žádná redundance. Rizika jsou značná - udržitelnost, kvalita, včasná podpora.
PS: chtít někomu něco přihrávat (třeba že členovi) je pokrytecké, vyčítají-li kritici především že výběrové řízení neproběhlo dle jejich představ.

Piráti jsou speciální v tom, že mají software jako svůj program (podporav opensource). Jak chceme měnit a elektronizovat stát, pokud rezihnujeme na provádění téhož na vlastním píšečku ?

Redundanci a další kvality se zajišťují pomocí požadavků na kvalitu software výše. To totiž znamená dokumentaci, testování , řízené nasazení na test a následna na produkci, zálohování, ...

Kritický systém je, pokud se nepletu, právě flexibee v pozadí, tato nadstavba nám pouze ty naše procesy zjednodušuje, ne? A pokud by je nezjednodušovala dostatečně, můžeme přijít s jinou, která nám je zase o něco více zjednoduší.

Nejedná se o zjednodušení procesů ve FlexiBee, ale o vytvoření procesů, které potřebují Piráti.

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.

Opensource není magické řešení všech problémů IT světa. Dává možnosti navíc, ale není samospásné. Když budeš chtít odejít od dodavatele s takovou aplikací, jako je ta naše, tak tu appku odepíšeš i když bude opensource. Prostě nestojí za to to opravovat a předělávat. A u open-source řešení jsem tohle už taky zažil (konkrétně 2x), v obou případech to bylo tím, že tým prostě nedržel standardy a best practices. To ti opensource nezachrání a pokud nemáš dostatek interních kapacit, tak je ti prd platné, že to teoreticky můžeš provozovat sám, neudržíš to stabilní (od dodavatele odcházíš kvůli nespokojenosti, takže ta aplikace asi není hvězdná - jinak bys zůstal) a je lepší to zahodit a udělat znova pořádně. Důvod proč chceme opensource pro mě byl vždy spíš v tom, že se pak o naše hvězdná řešení můžeme rozdělit se státní správou a se světem vůbec.

A právě nedodržování SW standardů vede k tomu, že je nakonec nutno vynaložit celou cenu za SW na reimplementaci. Možná se změní požadavky, ale možná také ne ...

Stejně tak ta grafika - to je na další diskusi, jestli tohle má nebo nemá být v budoucnu objednáno, ale nevidím souvislost s objednávkou té aplikace jako takové, grafika není pro fungování FO vůbec důležitá, ani by mě nenapadlo to dávat do specifikace jako základní požadavek.

Jelikož výše opakovaně padlo, že to děláme i pro voliče, tak by to mělo vypadat Pirátsky.

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.

K tomu open-source: Pokud to bude nadstavba nad FlexiBee, které je proprietární (stejně jako každý jiný účetní program), jaký má open-source smysl? Jediný, kdo by z toho profitoval, je vydavatel FlexiBee. V okamžiku, kdy vlastní účetní program je proprietární, tak nemá smysl se zabývat tím, zda jeho nadstavby mají být open-source (resp. ať se tím zabývá vydavatel toho SW - v tomto případě ABRA, ale ne politická strana, pro kterou je SW jenom prostředkem, aby mohla fungovat, ne cílem činnosti). Pokud by ta nadstavba byla nezávislá na účetním programu a komunikovala by skrz vlastní API s čímkoli, tak je to jiná, ale to ve specifikaci není.

Řešení formou (garantované účetnictví, closed) - (procesní nadstavba, opensource) dává naprostý smysl. API rozhraní si může někdo "přepojit" jinam, nebo zařít využívat jiný účetní SW. Pokud bude ten opensource dobrý, tak naopak vznikne situace, kdy výrobcí účetních SW budou podporovat napojení na jejich produkt.