"Stavební dozor" nad programátorem

Tyhle veci je lepsi resit pred zacatkem projektu, ne na jeho konci. Zakladem je vybrat overeneho, duveryhodneho programatora, u ktereho mate jistotu, ze vas nebude odirat. Dobre je taky v prubehu (opet ne na konci) kontrolovat co, jak a za kolik se dela. Overovat vykazy programatora po vykonu prace je dost problematicke, casove narocne a konec koncu dost subjektivni.

[1] Bohužel, nebylo to v mé moci hned od počátku. Sám bych to asi řešil nějak jinak. Dobré je, že k vývoji aplikace zatím moc připomínek nebylo a vše chodí jak má. Teď se začaly řešit trochu jiné věci - import dat, sestavy apod. Takže zatím není ještě nic hotového a vstoupit se do toho dá.

Osobně se mi osvědčilo mít vše dobře popsané ve smlouvě (do detailů). Pokud to ve smlouvě není, pak máte problém, protože prokazatelnost bude špatná.

jinak k otázkám:
ad a) pokud nemáte zkušenosti v programování, pak bych si vzal konzultanta, který zvolené platformě rozumí - to by Vám mělo dát minimálně nástřel, nakolik jsou jím uváděné práce reálné

ad b) na začátku mít vše dobře popsané ve smlouvě, pak by bod b vůbec nemusel být

ad c) pokud budete měnit programátora, pak zkuste hledat někoho, kdo dané platformě rozumí a má prokazatelné zkušenosti

Odpovidat na toto stylem ze takhle se to nemelo od zacatku delat je zcestne. Ze skusenosti znam ze takto to proste na spouste mistech a firmach chodi. Vzdy kdyz zadava praci nekdo kdo tomu dostatecne nerozumi. Sam uz jsem se k par takovejm nedodelkum dostal a vim ze clovek se muze zlobit sec chce ale neni mu to nic platny a je treba vymyslet co stim nez resit proc to predtim tak nebylo (to je dobry pak jen jako upozorneni pro priste).

Ad a) zde bych rozhodne souhlasil s predchozimi komentari, pokud dane problematice uplne nerozumite, sezente si nekoho kdo tomu rozumi. Jinak tim stravite spousty casu a vysledek nebude zadny. Tady taky asi zalezi jak moc to clovek zpetne chce zkoumat a jestli se casove a financni naklady vyplati.

Ad b) zde dost zalezi jak to bylo domluveno. Pokud existuje nejaka smlouva tak bych se prvne ridil podle ni. Pokud ne, a tak to dost casto v techto pripadech byva, bych se jednoduse zameril na to co od aplikace chci. Pokud dotycny neni schopen pozadavky splnit, jednoduse bych uzavrel spolupraci a pozadal o veskerou dokumentaci a zdroje. Zde je to samozrejme cele o dohode kdyz neni smlouva, takze rozhodne ne silo, ale diplomaticky.

Ad c) zamyslet se co nyni aplikace umi a co ve vysledku potrebuji, podle toho presne specifikovat co chci aby delala a jak to ma vypadat. Na dalsi praci uz si obstarat dalsiho cloveka ale se smlouvou, kde bude presne receno za co a jak se bude platit.

Jinak nedelam si iluze ze takto to ve spouste firem chodi. To je realita, holky z kanclu neco potrebujou tak reknou klukovi od kamaradky co jim to zbastli. Na druhou stranu stejne to je kdyz je ve spolecnosti ajtak, tam se zase skoro nic neoutsorcuje a vsechno bastli ten clovek i kdyz o tom nema moc paru. Takze tak.

Náročnost vytvoření jedné sestavy, včetně otestování a zapracování změn? 6 hodin. Při ceně 500 Kč za hodinu vám to vyjde na 3000 Kč. I u ustálené sestavy budou chtít uživatelé změny, vždy se najde něco, co by chtěli dělat dnes jinak a lépe, po zkušenostech jaké mají. Takže jim dodáte původní sestavu a budou chtít user-friendly změny. Takže ze 3 hodin surové sestavy, nakonec s tím ztratíte 9 hodin jen to hvízdne (změna, změna zpět, původní bylo lepší, další změna). Takže, jestliže je těch sestav 20, tak 60 000.- Kč a to se vám nevyplatí.

Ze zkušenosti - člověk má tendenci být v odhadech optimistický. Pokud je na počátku jasné zadání (což se téměř nikdy nestane), je na psaní SW obvykle 2x víc práce, než to na počátku zdá. Zadání se obvykle v průběhu vývoje více či méně změní. Ve výsledku pak celý projekt zabere 3x - 5x více času, než to vypadalo na začátku.

Vytvoření nějakého uživatelského rozhraní stojí průměrně tak 40-60% celkové práce. Vytvoření opravdu dobrého intuitivního, snadno použitelného rozhraní trvá násobně déle - dělá se několik verzí, které se průběžně zkouší, mění a od základu přepisují.

Tedy pokud uživatelské rozhraní je nic moc a zdá se vám to asi tak dvojnásobně předražené, dost pravděpodobně vám dal ten programátor slušnou cenu. Zapracování opravdu dobrého UI a drobných změn bude stát minimálně ještě jednou tolik.

Osobně nejsem příznivcem složitých smluv a podrobných zadání. Protože to sice vyhovuje byrokracii, ale lidem většinou ne. Ti chtějí produkt. Co se týče toho, jak jste to udělali, asi bych spolkl, že to byla chyba. A poučil se pro příště. Tím poučil myslím vysloveně agilní metodiky.

Já jako programátor to dělám tak, že si sednu s klientem, a domluvíme se na nějakém rozsahu práce, který chce na projektu udělat. Domluvíme se finanční a časový strop. Když je to hotovo, a faktura zaplacená, tak si sedneme znova, a znova si domluvíme další kolečko.
Výhody to má následující:
- Klient může kdykoliv změnit zadání, priority. V granulitě toho sprintu.
- Já jako programátor nemusím vysvětlovat, zda je cena adekvátní. Pokud mu to přijde hodně, řekne mi to, pokud nebudu ochoten slevit, najde si jiného. A já se mu samozřejmě budu snažit vysvětlit, že je má nereálné představi. Faktem je, že zatím jsem to obhajovat nemusel (asi jsem levnej).
- Odevzdávám vždy funkční aplikaci s dokumentací a zdrojáky dle smlouvy, která vlastně pouze definuje licency.

Tedy moje doporučení je, nechat minulost být, zaplatit mu, co udělal, ale příšẗě to udělat tak nějako podobně jako já.

[4] Pokud si ale zadavatel neumi ohlidat smlouvu, tezko si pak muze stezovat na fakturovane hodiny. Jednoduse mu stejne nezbyva nez zapaltit, nic jineho s tim neudela. Nema absolutne zadny smysl vynakladat dalsi penize na analyzu a audit ... vysledkem mozna bude zjisteni, ze by se to dalo napsat za 1/3 casu, ale to nic nezmeni na tom, ze pokud to neni osetreno smluvne, musi to zaplatit.

Takze nejlepsi rada = vzit klacek, a jit s nim pretahnout toho, kdo si ten vytvor objednal, pripadne mu strhnout premie/... necht se projevi osobni odpovednost.

Zcela bezne se totiz pise do smlouvy co ma aplikace delat (cim podrobneji, tim lepe) a kolik to bude stat (celkem), s tim, ze je mozne (napriklad) zduvodnene navyseni o max 10% (typu, vy ste ale nechteli export do XYZ, to bude za dalsi 3 hodiny). A cokoli dalsiho dodatkem ke smlouve.

Jakekoli zjistovani expost je ztrata casu i penez.

Nějak uzavřít ve stavu který je použitelný, zaplatit za něj a zaměřit se na budoucnost, další etapy. Zpětné analýzy použít nejvýš jako poučení do budoucnosti: ne o tom kolik stojí přidání knoflíku na sestavu, ale jak to řídit.

Tyhlety podrobné výkazy kolik minut trvala implementace které funkce jsou nesmysl. Dělají se, vykazuje se podle nich, handrkuje se kolem nich... ale ke kvalitě ani ceně výsledku nepřidají nic.

Souhlasím se [7][8]. U podobných projektů nejprve podrobně analyzovat (klidně analýzu zaplatit zvlášť) a odahdnout na základě analýzy náročnost implementace, rozdělit ji na etapy. Pak se dohodnout na celkové ceně a době dodání, včetně pravidel pro možné změny obojího. Případě rozdělit na etapy dodávané a palcené zvlášť.

PS: Mimochodem, věta "zbývá dokončit pár drobností včetně importu" mi srdečně rozesmála. A je signifikatní kolik prostoru věnujete popisu technických detailů a jak málo uzavřené smlouvě, domluvenému způsobu komunikace a pravidlům předávání produktu.

Me prije zcestny zpusob fakturace na zaklade hodin - mnohem lepsi je dle meho dohodnout se jasne na pozadovane praci VCETNE toho co urcuje, zda je dana prace hotova a za tento celek uzavrit smlouvu s pevne danou castkou. To za jak dlouho to stihne udelat je jeho vec a pokud to neumi odhadnout, opet je to jeho vec.

jinak za zvlaste uzitecny povazuji prispevek [7] od "taco"

:-) existuje... Jmenuje se to Statement of Work, Work Break Down Structure, Detailed Project Schedule, Project Manager ale zejména Fix Price Contract - klidně i interní.

Michal

[10] ano, s tymto suhlasim. Je lepsie si prejst zakladne poziadavky, prejst si aj uzivatelske prostredie, a dohodnut si termin a cenu. U kazdeho sa striedaju dni, ked "fici" a urobi takmer cely program, s dnami, kde je to hlavne o analyze a dobrom navrhu, a vtedy okrem pokreslenych papierov s navrhmi neurobi ani riadok programu.

"programátor tvrdí, že daný problém nelze vyřešit" - nakopat do zadnej casti a vyhodit z okna. Neexistuje nic, co by sa nedalo. Vsetko sa da, len obcas je cesta komplikovana. Nie je ten programator z klikacov? nahadzat komponenty na formular, prepojit s databazou a program je hotovy.

> alespoň nějak zjistit, zda vykázaný čas strávený nad prací je "korektní"?

Podla mna nie:
-programator casto odhadne, ze to prida napriklad za 5 minut, ale vyskytnu sa necakane problemy s nejakou nenapadnou komponentou a robi to pol dna. Ked si nauctuje pol dna, tak s tym asi tazko nieco spravis
-co jeden programator realne zvladne za hodinu, to robi iny 2 hodiny => odhad od inych firiem nemusi byt spolahlivy (ak teda myslis korektnostou to, ci na tom naozaj tolko pracoval)

> jednoduše "odpálkovat" programátora s tím, že my máme požadavky a on je plní?

Ano - to sa povie lahko - "ja platim, ja rozkazujem".

> Pokud jeho koncept aplikace není technicky zvládnutelný zvolenými nástroji (podotýkám, že technická část byla navržena jím), co dělat dál?

Ked je to uz po zaciatku projektu a podpisani zmluvy, tak je to tazke - idealne je sa s nim nejak dohovorit...

> c) jak případně převést nedodělaný projekt na někoho jiného?

Nepocitaj s tym, ze by sa to podarilo - zvacsa to bude potrebovat ovela viac penazi, ako tvorba od zaciatku.

> na co upozornit případného dalšího programátora?

Idealne je mu poskytnut, co presne od neho budete chciet - a ak je to mozne, tak chciet od neho ako prve (nefunkcne) GUI. Tam sa aspon ujasnia pojmy a predstavy - potom naprogramovanie veci za tym uz nema ako to "pokazit".

Toto je klasická ukázka amatérismu. V celku se vždy jedná o ucelené dílo. Je to obdobné jako jiná díla: malé nebo velké stavby, umělecká díla, podnik, cokoliv, jsou tam účastníci (zadavatel, dodavatel, uživatel), ekonomická kritéria (zjednodušeně náklady/výnosy/pro­vozní náklady aj.) a řada jiných vlivů. Stavbu si dovedeme představit všichni - nezačínáme nákupem materiálu, sehnáním dělníků atd. Kdysi, tuším že v PVT, byly vytvořeny směrnice pro tvorbu ASŘ - primárně pro ekonomické úlohy ale s přihlédnutím k automatizaci procesů - a ač nerad, jsem se s nimi musel postupně seznámit. Na svoji dobu to byl velice precizní materiál a neuplatnil se proto, že ti amatéři, co vytvářeli ASŘ, jim nerozuměli. Začínalo to zadáním, pak studie, úvodní projekt, oponentura úvodního projektu, rozčleněním na etapy, možnosti pokračování atd. A možná jste si všimli, že se vůbec nemluví o programování nebo programátorech. Programátor je vlastně zedník a je věcí realizátora aby si zajistil šikovné dělníky. A aby je řídil.
To není velikášství, i kdyby to vše dělal jeden člověk - a u větších věcí to ani není možné ani zdravé - tak v určitém rozsahu se musí vlastně všechno provést.
Zmiňované téma je tedy klasickou ukázkou chybného postupu od samotného začátku řešení této úlohy. Téma to je na knihu.
Takže možná vyhodit programátora, ale určitě hledat solidního dodavatele. Takže v počátku jde rozhodně o neschopného zadavatele - asi amatéra. A kdo ho zaměstnává? Atd.

a) zozente si par ludi co sa vyznaju, strcte im to do ruky a vypadne vam par podhodnotenych cisel :). Ale to je cinnost ciste pre dobry pocit, nema zmysel sa tym velmi zapodievat.

b) to je vec povahy a suhry, ocividne si nerozumiete a treba nieco zmenit. Moja oblubena formulacia je "to by bolo drahe", myslim tym to iste, ale je to spolocensky akceptovatelnejsie :).

c) asi bude stacit dostatocne jasne popisat sucasne problemy. Ak to bude schopny clovek, bude mu to stacit. Je vyrazne lahsie pokracovat v niecom, ako zacat na zelenej luke.

btw. mozno ste mali pomenovat platformu, ziskali by ste adresnejsie reakcie :)

Ja osobne sa snazim problemom tohto typu predchadzat co najmensou granularitou. Primarne je to, ale o ludoch. t.j. hladam najmensie kvantum prace, ktore overi ci clovek/dodavatel je schopny a naslednem bud kvantum zvacsim (v pripade spokojnosti) alebo sa snazim poucit (v pripade nepokojnosti).

zdravim,

asi potvrdim, co par zdejsich prispevovatelu.

Zaplatit, pokud aplikace dela, co ma.

A priste delat analyzy a zadani. Ono je vcelku dost pozde setrit na praci, kdyz jste vlastne usetrili na zadani a analyze soude podle toho, ze jsem moc nevidel tyto slova v zapisku blogu.

Nikde jsem take moc nevidel slova neco jako cenovy strop nebo presne urcena cena za vyhotoveni.

Pokud dodavatel dodava veci, tak jak ma v cenovem ramci, tak bych jej nechal dilo dodelat a zaroven predat dokumentaci. A klidne s nim i dale spolupracovat.

Pokud zjistite, ze Vam tvrdi, ze "uz je to skoro hotovo" a Vy si projdete prehled funkcionality a zjistite, ze chybi poslednich 20% = 80% prace, tak bych uvazoval o tom to cele nejak ukoncit. Urcite je treba ale stanovit nejmene nejake meritko, jak je hotovo podle nejakych elementarnich prvku z funkcionality.

gf

Tak zmluva je zaklad.
Zadanie je zaklad. Pokial ste mu daly zadanie a mate v zmluve ze toto a toto si mal spravit. A on pocas projektu povie ze sorry ale uz sa to neda lebo to technologia nezvlada nie je Vas problem ale jeho. Za kazde nedodrzanie pokuty natvrdo. Tak to funguje v priemysle a nikto sa nehra...

[19] a skusali ste to dakedy? :)

Ono je to jednoduche:
- nikto sudny Vam nepodpise nejake monstrozne pokuty, okrem pripadov ktore su jasne mimo hru
- takisto Vam nepodpise, ze spravi hocico co si pocas projektu vymyslite a k tomu zadarmo
- a ked Vam to uz niekto podpise, tak si to da mastne zaplatit.

Druha vec je, ze este som nevidel analyzu, kde by nebola kopa moznosti, ako spravit nieco zle.

Cerstvy priklad z tohto mesiaca: uplne trivialna zmena, trivialne zadanie, robota odhadnuta na 2MD, ... stav po par dnoch prace: "platforma nepodporuje jednu trivialitu bez ktorej to cele nepojde"... dodavatel uz par dni hlada nejaky hack :).

[20] pokuty samo nikdo nepodepise, ale definovat cenu, za kterou neco udela ... specielne kdyz to neco mam a reknu mu "chci aby to delalo presne to samy, co ten excel" ... pak je samo jeho problem, kdyz si rekne "to sfouknu za dva dny" ... a bude na tom delat mesic. Riziko podnikani. Stejne tak mu po 14ti dnech muzu rict, ze proste na smlouve je tejden, a at si to tedy strci za klobouk a nezaplatim ani korunu.

Mimochodem, zcela osobni zkusenost - prijde nosic drivi do lesa (obchodak) a vyklada, jak je upgrade ERP jen takove vetsi patch na odpoledne ... => pozadavek, nech si to dodavatel tedy patche, ale necht podepise, ze za kazdy den navic bude platit 1/2M ... mno nechtelo se jim to podepsat ... i proto (coz sem samo vedel z jinych zdroju) ze se jim to ani u jedinyho zakaznika nepovedlo patchnot bez pruseru (= minimalne tydeni uplny vypadek + az mesic vsemoznych potizi).

Takze jakmile nekdo neco tvrdi, tak po nem chci, at se k tomu zavaze pod nejakou penalizaci. Hned se ukaze, jak moc se to tvrzeni zaklada na pravde.

Stručně - podle popisu je externí programátor "špatný". Výmluvy, že to platforma nepodporuje, atd... jsou znakem amaterismu.
Co se týče samotného posouzení odvedené práce vs fakturace, tak jednoznačně doporučuji nějakého správce kódu. Např. GIT. Dají se z něj dělat všeliké sjetiny, takže pokud příště narazíte na položku "zápis dat", dá se k tomu poměrně rychle vyjet historie. Každopádně doporučuji provést okamžitě stop, dát podnět k setkání a jasně dát dodavateli najevo svou nespokojenost. Ideálně když je smlouva a jsou tam zřetelné porušení.

pohled z druhé strany /ne konkretně k tomuto případu ale obecně/
- špatná specifikace požadavků zákazníkem
- zákazník na začátku moc neví co by chtěl, ono časem se ukáže
- každá druhá sekretářka je odborníkem na programování a hlavně dokáže posoudit obtížnost a náročnost
- a nejraději mám požadavky, které začínají: Tady bych chtěla jenom přidat ...

Jejda, to je zase problém.
1) smlouva má být postavena tak, že zákazník dostane program s požadovanou funkčností za sjednanou cenu. Kolik hodin na tom kdo stráví je jeho věc. Při převzetí se zkontroluje, zda funkce odpovídá požadavkům. Hotovo. Jakýkoli další rozvoj, úpravy, opravy atd. je placeno. Zde už klidně hodinově, ale podle mého názoru je lepší pevná cena za konkrétní funkci.
2) problém u předdefinovaných sestav je ten, že nikdo není schopen zjistit, zda sestava dává správné výsledky - tj. zda bere a zpracovává primární data tak, jak chtěl uživatel. Proto může být v určitých případech lepší vyplivnout z programu surová data, nechť si je uživatel zpracuje. To je běžné.
3) čas strávený nad tvorbou programu se zjistit nedá. Zaplaťte a hotovo.
4) příště až budou dámy chtít udělat něco, čemu nerozumí, nechť se interně obrátí na někoho, kdo ví o čem je řeč (IT oddělení) a dotyčný se postará o to, aby projekt proběhl v pořádku.

SW na zakazku bez projektu, ktery by se svou podrobnosti blizil napr. stavebnim nebo strojirenskym projektum je vzdy problem. Jedina moznost je prubezne proplaceni a odevzdavani hotovych casti s tim ze zdrojove kody vlastni zadavatel a obe strany muzou kdykoliv odstoupit.

V první řadě bych se soustředil na to, zda má vůbec smysl řešit nějaké "kontrolování". Pokud firma nespecifikovala přesně co chce, jak to chce atd., stejně na dotyčného nemáte páku takže výsledek bude, že se z okna vyhodí to co se zaplatí programátorovi + váš čas + čas někoho, kdo bude analyzovat.

V řadě druhé, "stavební dozor" se používá na stavbě domu kde proběhne nejdřív nějaká diskuze klienta s architektem, návrh, kontrola, odsouhlasení, pak předání stavební firmě. Pokud vývoj software probíhá tak, že se programátorovi řekne "no tohle jako bude dům, tak nám to udělejte", a v průběhu se specifikuje "udělejte tam nějak dveře a okna, na to jsme nějak zapomněli", "víc červené prosím", "okno trochu víc doleva", zabere to nepochybně tuny času. Tohle je v zásadě kámen úrazu podobných projektů, protože jsou v zásadě dvě cesty (a pak cokoli mezi).
a) klient s programátorem se domluví co přesně v této etapě chtějí, programátor udělá, vše se zkontroluje, dělá se nová etapa
b) klient s programátorem se snaží nějak "průběžně" stále měnit zadání tak, aby klient dostával to co chce

Problém je, že u a) klient dostává něco co ve výsledku nechce, ale programátor může alespoň analyzovat a pracovat. U b) pak sice klient jednou dostane to co chtěl (a na začátku to nevěděl), ale znamená to nutnost spolupráce, takže to žere oběma stranám spoustu času, a ve výsledku neexistuje nic jako "zadání je hotové" protože neexistuje ani zadání. Tohle by teoreticky mohl řešit projektový manažer, ale u podobných "bezedných děr" to v zásadě jen zdvojnásobuje strávený čas protože ve výsledku programátor stejně pořád předělává.

Jinak chtít "dodatečně" vědět, co programátor dělal mi přijde jako trochu problém. Pokud verzuje pak samozřejmě "nějaké" informace dostanete, otázka je zda to nebude něco jako
3h "výstup č. 1"
2h "úprava výstupu č. 1 dle nových požadavků"
1,5h "úprava výstupu č. 1 dle nových požadavků"
2h "úprava výstupu č. 1 dle nových požadavků"
4h "rework výstupu č. 1 dle nových požadavků"
2h "úprava výstupu č. 1 dle nových požadavků"

3h tvorba seznamu co jsem dělal

Je to prosté. Buď zaplatíte hodně za dobrou analýzu a zadání. Nebo zaplatíte hodně za implementaci :-)

[21]
"Takze jakmile nekdo neco tvrdi, tak po nem chci, at se k tomu zavaze pod nejakou penalizaci. Hned se ukaze, jak moc se to tvrzeni zaklada na pravde."

Ked zaplatite, dostatocnu cenu za danu klauzulu penalizacie, preco nie.
Ak vyzadujete istotu chodu s pokutou 1/2M den, je logicke, ze cena sa zdvihne o 1/2M*bulharska konstanta, pretoze vzdy sa moze nieco pokazit.
Zaplatite? Podla mojich skusenosti vacsina odberatelov chce istoty, ale zadarmo.

[28] Chtel sem po onom dodavateli, necht si urci cenu, odpovidajici nasim pozadavkum ... nebyli toho schopni. Nebyli dokonce ani schopni patchnou vlastni system. Nakonec sme byli jedinou firmou, ktera patchla bez problemu ... protoze sem si to udelal sam ...

Jejich predstava totiz byla "no a tady vemem tenhle stos papiru a podle nej budem menit jednotlivy nastaveni", nacoz sem jim rek, ze jim asi jeblo, ze chci script, protoze nebudu resit ze se nekde neco zapomelo.

Ten sem si nakonec napsal ... vlastnorucne ...

Programator nema mit co resit user-friendnost aplikace, ten ma dostat jasne zadani, jak ma popripade plaikace vypadat, co ma co delat jak funkce a to prosim podrobne rozepsano. Od toho je tady nad programatorem architekt, ktery funguje i jako spojka se zakaznikem. Architekt by mel podle slozitosti zadani od zakaznika urcit, kolik bude zapracovani te one funcnosti stat clovekohodin. Ma byt jasne dana sazba, kterou zakaznik zaplati za jednu clvoekohodinu. Architekt (nebo konzultant), odhadne pocet hodin, kolik by asi zapracovani mohlo trvat a ten samozrejme trochu navysi. Pote se se zakaznikem dohaduje, zda na to pristoupi ci nikoliv. Programator za to nemuze, ten akorat musi oduvodnit, proc pretahl pocet hodin, ktery mel na danou praci vymezen. Pri zpracovani vetsiho projektu je dobre projekt rozsekat na dilci casti a ty klidne i na dalsi podcasti, aby se predeslo dohadovani se se zakaznikem, pokud chce zapracovat neco dodatecne, ze to nebylo soucasti puvodniho zadani a bude tedy oceneno zvlast.

[30] predvcerom som cital "specializacia je pre hmyz a nie pre ludi" :)

Prakticky pri takychto drobnostiach je velmi zriedkave, ze existuje x-specialistov,
z ktorych nad tym kazdy stravi epsilon casu.
Realistickejsi plan je najst niekoho kto vie vsetky pozadovane veci v dostatocnej miere. Nebude to dokonale, ale cenovo vyrazne pritulnejsie.

Dohladu sa zadavatel aj tak nevyhne. Scenar "obratim sa na velkeho renomovaneho dodavatela ktory vsetko sa velke prachy zabezpeci" je cisty alibizmus pre manazerov.

Na rozumnou radu "co teď s tím" je zde příliš málo informací. Tak jen pár rad pro příště:
1. Do smlouvy vymezit co je součástí díla. Pro tento případ je dost zajímavé, zda výběr technologie byl na dodavateli, nebo na vás.
2. Vymezit minimální funkcionalitu, která je v každém případě "v ceně". Tady je dobré třebas právě vyjmenovat tiskové sestavy, které jsou součástí zadání. Pokud některé věci nejsou zřejmé předem (bude teprve vytvářena specifikace), tak uvést kdy bude specifikace hotova, že v ní bude uveden výčet funkcí a odhad ceny a že bude podléhat schvalování. V takovém případě je běžné uvést na začátku cenu za vytvoření specifikace tak, aby dodavatel měl jistotu, že mu ji zaplatíte i když do toho pak nepůjdete. A pro vás to pak znamená další okamžik, kdy můžete říci "ok, tohle se mi nelíbí, do toho nepůjdem". Občas se stane, že vezmete specifikaci, dodavateli za ni zaplatíte a pak s ní oslovíte konkurenci, kde vám dají lepší cenu.
3. Dohodnout předávací podmínky. U levnějších věcí je běžné, že se platí za hodinu/den práce (viz bod 2 - tam je uveden odhad, kolik to zabere hodin). U dražších věcí se zase dohodne celková cena a co to bude umět. Pokud to umí to, co bylo hodnodnuto, pak zaplatím. Pokud ne, tak se ještě rozhodnu, zda přijmu alespoň část za nějaké menší peníze.
4. Dohodnout se na ceně víceprací. To je právě to dodělávání věcí za běhu. Je dobré zde uvést orientační náročnost typických víceprací, ale u menších projektů nemá smysl smlouvu zbytečně natahovat a tak se jen uvede, že "veškeré vícepráce musí dodavatel dopředu oznámit včetně závazného odhadu pracnosti a objednatel se pak rozhoduje, zda danou úpravu v tomto rozsahu chce nebo ne".
5. A v neposlední řadě se dohodnout na autorských právech. Už jsem zažil pár případů, kdy objednatel dostal instalačku na CD nebo flashce a tím veškerý smluvní vztah skončil.

Pro jednodušší věci se to dá vměstnat na dvě strany fontem 12.

No a ta pracnost, ono to skutečně takhle pracné může být. Pokud je to technologie, kterou dodavatel nezná, a navíc je to kluk, který se "na vás učí", tak to je ta pracnost odpovídající. Proto je tak důležité nechat vybrat dobrou technologii a zvolit někoho, kdo s tím má zkušenosti a může ukázat reference včetně typických odhadů pracnosti. A pokud taková firma není, tak se volí spíše metoda "bude to umět to a to, dodáno to bude nejpozději v srpnu 2013 a bude to stát tolik a tolik bez ohledu na to, zda to firma zfoukne za odpoledne nebo to bude dělat měsíce".

Dohled pak začíná tím, že se stanoví milníky a seznam funkcí. Pravidelně se kontroluje dostupnost funkcí a plnění milníků. Stejně tak se eviduje seznam víceprací. Vícepráce se dopředu musí nacenit a schválit. Také se musí ověřovat, zda byly dodány a v jakém termínu a kvalitě. A opět se preferuje metoda "zabere to cca 5 hodin, takže to bude stát 5000 Kč bez ohledu na to, kolik to ve skutečnosti bude trvat". Pokud to dodavatel zvládne rychleji, jsou v plusu. Pokud ne, tak je to jejich problém. Pokud budou placeni od hodiny, tak to málokdy dodají včas a budou mít tendenci nechat si proplatit i čas, který nad tím nestrávili (ten pičičmunda u toho sice seděl 3 dny, ale z toho 12 hodin prosurfoval na youtube).

Důležitým krokem je dohodnout rozsah díla. A být připraven v případě katastrofy prostě smlouvu vypovědět a nic neplatit, nebo i vymáhat zpět zaplacené peníze. Tady je důležité mít všechno dopředu schválené včetně odhadu pracnosti. Tak to funguje třebas i v autoservisu - když vám řeknou, že ta oprava bude stát cca 8000 Kč, tak vám nemůžou pak jen tak naúčtovat 30 tisíc. A tu cenu zapisovat ke každé dílčí úpravě. Takový vedlejší efekt toho je, že tak evidujete, kdo u vás kterou úpravu chtěl a schválil. To bývá pak zajímavé sledovat, kdo si nechal udělat nejdražší "doladění" :-)

a) je potřeba zdrojáky dát do nějakého verzovacího systému a potom je vidět, co se udělalo. Rozhodně je poznat kompletní přepsání - ale je potřeba mít dobrou vůli na obou stranách. Ten, co zdrojáky dohlíží, by měl poznat pouhé přeformátování kódu od skutečných pozitivních změn. Občas jednořádková korekce trvá několik hodin.

b) každý programátor má limit toho, co ještě zvládne udělat - je možné, že na to už nestačí. Pomohlo by aspoň naznačit použitou platformu a "neřešitelný" problém. Je možné že to opravdu nejde nebo se najde někdo, kdo smysluplně poradí a potom to zvládne.

c) to je jednoduché - je potřeba vzít zdrojáky a ukázat je komplet tomu dalšímu programátorovi a popsat ten "neřešitělný" problém. Buď řekne - to zvládnu, nebo to vůbec nezvládnu, nebo to budu muset celé přepsat a to bude trvat X.
Nejhorší případ je, že řekne, že to zvládne a taky se v tom utopí.

ad a) - rychla odpoved: takmer bez sance;
- dlha odpoved: ide to ale je otazka ci nad tym napokon nestravis viac
casu ako nad celym projektom. pri projekte s rozsahom par tisic riadkov
kodu (kam asi vas projekt spada) to mozu byt hodiny prace navyse, musi to
robit niekto kto ma DOBRE skusenosti a to nielen s programovanim ale
aj so zvolenou platformou;

ad b) - rychla odpoved: to nerob, vzdy je lepsie sa dohodnut (win-win);
- dlha odpoved: vies co tym dosiahnes? dve veci: nasraneho programatora
(co vlastne ten zakaznik chce?!) a nasraneho uzivatela (co vlastne ti
programatori chcu, su dobre plateni tak nech makaju!!). osobne by som
zvolil taktiku zastavenia projektu, spisania poziadaviek na papier,
poziadavky rozdelit na malicke ulohy a plnit, odskrtavat. tu by sa mozno
hodila pomoc ineho programatora ktory by bol najaty len na verifikaciu
odvedenej prvej cca tretiny prace. je velmi dobre ak sa aktualny
a kontrolny programator nekamaratia ale aktualny programator
o kontrolnom vie (tip: zobrat ho na prve dve-tri schodzky pri spisovani
na ten papier);

ad c) - kratka odpoved: radsej to zadajte ako uplne novu pracu a poriadne
spiste poziadavky;
- dlha odpoved: to je takmer urcite zlozitejsie ako napisat to odznova.
novy programator by sa najskor musel zoznamit s poziadavkami, zrovnat si
to v hlave, premysliet ako to urobit. a predstava, ze by teraz mal zacat
citat kod a premyslat preco toto robil taktok a hentok robil inak... to
by vam vykazoval "analyza aktualneho riesenia", po dvoch tyzdnoch zistite
ze ste zaplatili uz ako za stareho a on stale analyzuje aktualne riesenie;

dalsie poznamky pod ciarou:

-kontrola postupu prace kontrolou zmien cez svn/git funguje len na zaciatku ked kod pribuda rychlo ale cca od hotovej prvej tretiny sa neprogramator nema ako v tom vyznat. staci obcas zmenit strukturu a ak bude kontrolovat neodbornik je to s kontrolou v prdeli;

-overeny, doveryhodny programator ktory vas nebude odierat neexistuje; ak teda za odieranie povazujete "tu mi to trvalo 40 minut ale nafakturujem im hodinu, tu 20 minut ale vykazem pol hodinu". z takychto "tu desat, tu dvadsat minut" sa za den nascitaju 2-3 hodiny.

-pokial ti skuseny, overeny programator s 10 rocnou praxou povie, ze to bude trvat tyzden, bude to trvat tyzdne tri. je to realita a za dvadsat rokov sa mi to potvrdilo na kazdom projekte - je jedno ci to boli velke bankove aplikacie alebo male projektiky za 20tisic. ako it manazer by si to mohol vediet, ak nie uz to vies.

-na male projekty rob male zmluvy. vyries tam licenciu, na ostatne sa vykasli. predstava, ze v zmluve bude par stran definicii za co bude aka pokuta - podpise ti to len zufalec, programator nie. alebo si myslis, ze budes pomocou svn analyzovat commitovany kod a zistovat ci vcerajsiim commitom naplnil bod 4.1.3.22, pismeno a) zmluvy? na to by si potreboval dalsieho cloveka a si v prdeli. pozri sa na jobs.cz na vyhladanie vyrazu "programator" - kto by s tebou podpisoval taku zmluvu? student alebo cerstvy absolvent ktory nevie do coho ide takze navyse ani nebudes mat pripadnu pokutu z coho zobrat. alebo si myslis, ze na projekt s rozsahom dva tyzdne programatorskych prac v cene 40 tisic najmes pravnika na spracovanie 30 stranovej zmluvy za dalsich 40 tisic?

-nemusi kecat ked hovori, ze nieco platforma nepodporuje. nie raz som sa stretol s tym, ze sa velky projekt zasekol na tom, ze pouzivana platforma nepodporovala nejaku prkotinu ktora vsade inde bola beznou sucastou frameworku. zvlast "chutny" v tomto smere bol SAP ale stretol som sa s tym aj pri "beznych" frameworkoch.

doporuceny postup:
1. spravit tvz. wireframe - to kludne moze spravit trosku znaly manazer (ty) s buducim uzivatelom aplikacie;
2. definovat vstupne data, moze urobit znaly manazer (ty);
3. definovat vystup, moze urobit znaly manazer (ty);
4. naprogramovat (programator)
5. otestovat (uzivatel, ty)

a este jedna poznamka: je dobre najat programatorov dvoch, vo firme im dat stol, k stolu dve stolicky, jednu klavesnicu, monitor... ale o extremnom programovani sa da docitat aj inde. ma to jednu nespornu vyhodu: ked jedneho programatora zrazi elektricka druhy pokracuje akoby sa nic nestalo.

drzim palec.

„Protože se však jedná o práci externí firmy, není úplně jednoduché pochopit, nakolik se vykázané programátorské hodiny blíží realitě. existuje něco, jako stavební dozor při stavbě, ale na programátorské práce?“

Pokud někoho v první řadě zajímá, zda jsou odprogramované hodiny skutečně odprogramované, tak toho možná s velkým úsilím dosáhne. Čeho ale nedosáhne je ten funkční program.

„Doslovný komentář je něco ve stylu : "Však víš, programátoři..."“

Jako familiérní komentář u piva chápu. Pokud to má být vážně míněnou pracovní komunikací člověka, který má něco řešit s programátory, tak bych toho člověka vyhodil.

„Z textu výše vidíte, co míním pojmem stavební dozor. To je člověk na stavbě, který hlídá, že je vše pod kontrolou, v souladu s plánem a že si nikdo nevymýšlí. Jak to nakonec řešíte vy v oblasti programování ať už jedné (zadavatel) či z druhé strany (programátor)?“

V první řadě nebudu objednávat externí firmu, která toto nedokáže zajistit. To už je jednodušší hlídat jednotlivce než hlídat špatného a drahého hlídače.

Je zaujímavé ako tu snáď polovica ľudí radí spraviť komplexnú zmluvu, dávať zdrojáky do SNV-ka alebo GIT-u a podobné veci.

K smiechu.

Podľa mňa užitočné komentáre sú 6, 7, 26, 27 a 34. Zvyšok ilustruje neskúsenosť z relevantného množstva projektov ideálne na roznych pozíciách v týme.

[36] „Podľa mňa užitočné komentáre sú 6, 7, 26, 27 a 34. Zvyšok ilustruje neskúsenosť z relevantného množstva projektov ideálne na roznych pozíciách v týme.“

Ještěže jsi neuvedl 36.

klasicky problem nezvladnuteho agilneho vyvoja, chybalo sledovanie pocas tvorby. resp. poziadavky boli agilne ale vyvoj vodopadovy.

ako tu niekto pisal:
1) zastavit vyvoj
2) spisat sucasny stav
3) zistit co chyba alebo treba prerobit
4) napisat co sa ma este spravit + zakladny popis
5) spravit odhady na nove veci - pesimisticke, tj. to co povie programator krat konstanta - toto je najtazsie, mozno tu prizvat dakeho odbornika
6) rozdelit si vyvoj na napr. na tyzdnove useky (staci na taky maly projekt) - ak je uloha dlhsia ako tyzden, rozdelit na mensie, ktore sa daju skontrolovat
7) spustit vyvoj
8) pred zaciatkom kazdeho tyzdna (napr. piatok) sa stretnut, ukazat stav splnenych uloh + vybrat zo zoznamu uloh, ulohy, ktore sa budu riesit dalsi tyzden + dopisat podrobny popis (pozor musi spadat do rozsahu, ktory sa predtym urcil)
9) komunikovat
10) komunikovat
11) komunikovat

a este raz komunikovat, ak programator urobi nieco inak a nepovie to dopredu, tak je to jeho problem.

plnu sumu platit za splnene ulohy. za z vacsej casti splnene alebo s malou chybou tak 2/3 sumy, atd... a nech si fakturuje ulohy + riadenie projektu okolo (komunikacia, maily, ...)

Když to zjednoduším a nadsadím, tak jste si dříve pytlíkovali něco v Excelu, pak jste se rozhodli, že už to je pro vás nákladné a tak byste to chtěli udělat líp, tedy že vám na to někdo napíše jednoduchý prográmek, ale ten zase nesmí stát moc peněz, takže by to chtělo najít někoho levného, ale šikovného. Franta, synovec zetě naší účetní dělá taky do těch počítačů, prej i nějaký programy a není drahej, bydlí u rodičů a má malé náklady, takže si účtuje stovku na hodinu. A on přijel, mrknul na to, pobavil se s kolegyněmi a řekl "jasně, to je pro mě práce tak na dva týdny". Jenže těch hodin přibývá a on ten Franta asi nebude tak šikovnej, protože to furt nefunguje, jak my jsme chtěli. No a teď jsme se rozhodli, že mu budeme koukat na ruce, protože si myslíme, že si těch hodin vykazuje moc. Za mě tedy:

a) Nikomu není nic do toho, jak dlouho tu práci kdo dělá. Jiná věc je, jestli je daná práce za nějakou cenu drahá nebo laciná, ale to je dáno smlouvou a trhem. Vykašlal bych se na počítání hodin zpětně (pokud to nemá být poučení pro příště), ale snažil bych se rozumně a realisticky domluvit do budoucna, ať už s tím samým člověkem nebo s někým novým. Uděláš tohle a tohle a dostaneš tolik a tolik a bude to tehdy a tehdy. Když to uděláš za 10 minut, tvoje plus a když to budeš dělat 12 hodin denně 7 dní v týdnu, tvoje minus.

b) Rozumně "odpálkovat" programátora nelze zřejmě ze dvou důvodů: 1. Nerozumíte tomu a 2. I v uvozovkách to vypadá na problém v komunikaci. Navštívit nějaký kurs komunikace nebo vyhodit ichtyla, se kterým není možná domluva a najmout někoho jiného.

Jestli platforma něco umí nebo neumí se takto na dálku nedá říci, ale předpokládám, že jde buďto o neschopnost programátora nebo o to, že to sice jde, ale stálo by to víc, než budete ochotni zaplatit. Najměte si někoho, kdo tomu rozumí a s programátorem to probere. Jednak tím vašeho programátora proklepnete, jestli to není úplný packal a jednak získáte pohled zvenčí na daný konkrétní problém.

c) Hlavně realisticky zhodnoťte náklady a výnosy jednotlivých rozhodnutí DO BUDOUCNA. Je úplně fuk, kolik peněz jste v projektu utopili, pokud mezivýsledek není životaschopný, zahoďte ho a začněte znovu. Případného dalšího dodavatele hlavně vyberte rozumně (snadno se to řekne) a on si ty problémy zhodnotí sám. Na co ho chcete upozorňovat, když té práci nerozumíte?

Klasika - uzivatel nevie co chce, ale bude s tym otravovat az kym to nedostane. A potom sa divi, aku dostane fakturu :-)

Nečetl jsem celou diskusi, ale musím vyjádřit nesouhlas s příspěvky, které propagují stanovení ceny na začátku a potom trvání na ní s tím, že odhad je "problém programátora". Nevím, kolik diskutujících takto pracovalo za fixní cenu, ale podle mé zkušenosti to člověk ze začátku dost podstřelí, zvlášť když mu zákazník nakecá, jak je to jednoduché. K takové práci pak chybí motivace a výsledek je v lepším případě odfláknutý. Ti zkušenější už potom buď za fixní cenu nepracují, nebo odhad raději nadsadí, takže zákazník si raději vybere někoho jiného. Za klíčové při výběru programátora bych považoval reference, nejlépe někoho, s kým už má zákazník zkušenosti, potom se dá klidně jet na hodiny.

Aktuálně to na mě působí tak, že vám programátor dodal to na čem jste se domluvili na začátku a plus mínus to funguje. To že tam nejsou sestavy nemusí být chyba programátora, ale zadání.

Je tu jedna důležitá otázka, zaplatili jste danému programátorovi už hotové věci?

Pokud ne, tak na místě toho programátora bych se choval stejně a zařadil bych vás do kategorie "problémový zákazník" a další upravy bych pro vás už nedělal. A zvláště, pokud zaplacení zakázky podmiňujete naprogramováním funkčnosti, která v původním zadání nebyla. Z blogu to na mě působí tak, že vám přišla faktura, vám přijde moc vysoká a snažíte se cenu snížit.

[38] V podstatě jsi popsal agilní vývoj :) Oproti klasickému vodopádu (což je tenhle případ) má vyšší pravděpodobnost úspěšně dokončeného projektu. Překvapuje mě, že pan Vít, IT Manager, o tom ví tak málo, že se ptá na Rootu...

Domnivam se, ze na tu situaci se hodi Agile Scrum a tydenni sprint.
Za vyhodu povazuju, ze programator je zrejme jen jeden, ze se nejedna o slozity team.

Jeste neni pozde.

Vy jako Product owner (rikejte si jak chcete) dejte dohromady seznam 5-10 nejdulezitejsich pozadavku. Tedy chybejici features a podobne oblasti.

Sednete si pak s tim programatorem a at je seradi za sebou podle obtiznosti. Staci orientacne.
Pokud oba rozumite relativnimu odhadu napriklad ve scrum pointech (fibbonaciho rada, nebo jine metody), tak to pouzijte.
Pokud nevite, rozdelte ty tasky alespon na tri hromadky, jednoduche, stredne slozite, a nejslozitejsi.

Jasne mu take reknete ktere itemy jste ochotni zaplatit a ktere uz povazujete za proplacene.

Pak vezmete dva ty dulezite jednoduche a zeptejte se jestli je schopen je za tyden udelat.
Pokud ne, zvladne alespon jeden?
Asi vite kolik stoji tyden jeho prace a budete tak vedet kolik stoji ta jednoducha featura.

Za tyden at to odprezentuje a pokud je to ok, vy mu to zaplatite.
Tyden neni extremni risk ani pro jednoho z vas.

Idealne to parkrat zopakujte.
Snazite se znovu vzajemne vybudovat ztracenou duveru.
To mu reknete, a jasne mu reknete, ze dal budete rozhodovat podle rychlosti a kvality jeho prace po tydnech.

Nejlepe po kazde prezentaci se znovu sejdete a znovu se podivate na narocnost tech zbyvajicich ukolu.
Pokud mate pripominky, prihodite je na hromadku dulezitych itemu.

Idealne ty zbyvajici itemy spolu rozdelite na 1 tydenni, 2 tydenni a mesicni.
Mesicni a vetsi se snazte rozdelit na mensi, pripadne vyzobnout opravdu dulezitou funkcnost. Ja vim, to muze byt tezke.

Zhruba po trech opakovanich (to znamena za tri tydny) uz budete mit slusny obraz kolik casu ty dulezite veci jeste zaberou a kolik vas to bude u tohoto programatora jeste stat.
Zaroven po diskuzich s programatorem budete mit o zbyvajicich ukolech vetsi prehled.
To je chvile pro zasadni rozhodnuti, jestli najmout nekoho jineho, nebo pokracovat takto.

Nema cenu programatorskou praci rozepisovat po hodinach.

Uz v tehle fazi by bylo idealni pozvat dalsiho pripadneho programatora, projdete s nim ty same itemy a uvidite jak je ohodnoti on.
Jestli budete delat odhady s kazdym z nich otevrene, nebo tajne a oddelene, je na vas.

Smlouva na takovy druh tydenni spoluprace muze byt problem, ale verim ze resitelny.

Překvapuje mě že se v odpovědích jen jednou objevil termín "Project manager". To je přece ten stavební dozor který stojí mezi zákazníkem který ví prd o programování a programátorem který jen matně tuší co přesně zákazník chce. A hlavně má ten Project manager na starosti dodržování termínů a rozpočtu. Jenže jeho čas stojí peníze které jsou hned vidět a spousta zákazníků "ušetří" tím že tenhle článek vynechá. Sice je to nakonec vyjde dráž, ale tak jako v tomhle případě se budou snažit neúspěch svalit na toho programátora a nepřiznají si že ve skutečnosti si ten projekt blbě naplánovali a ohlídali.

[45] Project manager je obdoba stavbyvedoucího - čili zcela odlišná role, než má stavební dozor.
Zdá se, že tento projekt nemá ani stavbyvedoucího, ani stavební pozor, takže by mu pomohlo to i to.

A role PM se tu nepřímo celkem diskutovala. Hlavně se řešilo to, že najmout si freelance projekt managera znamená riziko, že tu příště bude příspěvek ve stylu:
"Projekt manager vykazuje spoustu hodin, ale projekt se moc nehýbe dopředu, poraďte, jak prověřit jeho práci."

Tiez si myslim ze funkcie/moduly programu mali byt popisane na zaciatku a teraz je trochu neskoro... Tiez mala byt dopredu dohodnuta cena a nie platba programatora na hodiny... Pripada mi to ako ked si beriete taxik a platite za kilometer oproti dohodnutiu sa dopredu na cene.
Teraz sa vam nepaci ak taxikar isiel dlhsou cestou lebo na kratsej je podla neho "zapcha" (zacpa) - ale dokazovat kto ma pravdu je trocha problem...

Zakladem (a bibli) jsou CODING RULES. Ty musi programator dodrzovat pod hrozbou pracovniho tabora :-)

Nu a pak musi existovat blokove a procesni schema aplikace, zivotni cyklus aplikace a zivotni cyklus zdrojoveho kodu. Pochopitelne tez musi existovat zadani funkcnosti dane aplikace a to vcetne "spojeni" s okolnim svetem.

Z zivotniho cyklu pak zadavatel sestavi jednotlive cykly (etapy) a z etap pak denni vykazy.
Netreba zduraznovat, ze "administrativa" pak zabere neco mezi 10-30 % nakladu na vyvoj a udrzbu aplikace, nicmene jedna se o "nutne zlo".

Vcelku rychle se blizi doba, kdy vyse uvedene veci budou soucasti nejake te "best practice" a pak je bude vyzadovat vetsina odberatelu a zadavatelu.

Tak za prvý. "databáze v excelu" je zlo. Jen za to, že se Vám s tim někdo bude patlat by měl dostat nějaký zvláštní příplatky. Za druhý u podobnejch věcí zabere udělat tu věc podle prvního zadání méně než třicet procent času, kterej se nad tím ve výsledku stráví. Další třetina je, že člověk přidělává "drobnosti" se kterejma přijdou lidi po tý co uvidí co dostali a zjistí, že si představovali něco jinýho. Ten čas je třeba násobit koeficientem dva a půl, protože zadavatelé obvykle nejsou schopní srozumitelně říct, co chtějí a nejsou ochotní se zamyslet nad tím, co jim člověk řiká. Chtěj "udělátko", magickej chlíveček a podobný kraviny. Komický je, že to obvykle nejsou ty, který s tim potom budou dělat, ale naprosto zbytečná mezivrstva, která musí nějak ospravedlnit svoji zbytečnou existenci. Poslední třetina času je to, že se to musí nakonec samozřejmě celý překopat, protože poslední z "drobnejch úprav" je v naprostym rozporu s myšlenkou, jak to bylo původně namyšlený.

[37] Závidíš že tam nejsi taky uvedenej?

K věci: žádnej zkušenej programátor nepůjde na pevnou cenu za zakázku, bude chtít hodinovou sazbu. Pokud někdo na tuto podmínku přistoupí není to zkušenej programátor. Ověřeno 20-ti letou praxí programátora a později projektového manažera na projektech pro velké firmy jako Česká pojišťovna, DHL, KB, EON ale i malé firmy s cca 5-ti zaměstnanci. Na vlastní kůži jsem viděl problémy které "pevná sazba za dílo" dělala. Když chcete pevnou sazbu kupte si krabicové řešení.

Howg.

Landel: nesuhlasim; ked je to zaplatene dobre, tak preco nie fixnu cenu? Mne sa tak podarilo dostat aj 10k Kc za cca 2 hodiny prace (ini to robili ovela narocnejsie a mali by co robit 2 tyzdne). Spokojne boli nakoniec obidve strany.
Samozrejme je to riziko, ale inak je to podla mna najlepsia moznost, ako programovat pre obidve strany.

[50] Ale půjde. Zkušení programátoři samozřejmě chodí do zakázek za pevnou cenu. Musí být ovšem splněny tyto podmínky:
-Projekt je jasně definovaný, ze smlouvy je jsou jasné podmínky podle kterých to bude zákazník přebírat.
-Je jasně definována nutná součinnost ze strany zákazníka (aby se nestalo, že požádáte o dump databáze a budete týden čekat na odpověď, že oni vám ho podle procesu nesmí dát).
-Jedná se o projekt, kde se dá odhadnout, kolik času to zabere.
-Zákazník chápe, že cena dodávky na klíč vždy obsahuje značnou rezervu pro případ, že se ukáží nečekané problémy. (Tak nečekané problémy jsou vždy, ale ne vždy musí zdvojnásobit časovou náročnost projektu).
-Podmínky odstoupení od smlouvy jsou pro dodavatele nepříjemné, ale rozhodně ne likvidační.
-Je definováno jak se budou řešit vícepráce za dodatečné požadavky.

A pochopitelně - pokud má nějaký programátor/firma rámcovou smlouvu se zákazníkem, tak už je velmi časté, že se jednotlivé zakázky domlouvají za fixní cenu.

[51[, [52] Jak dlouho se živíte programováním zakázek na klíč? Ano, za fixní cenu se dají udělat jednorázovky "přidejte mi sloupeček do tabulky" nebo "chci novej report s osmi sloupečky kde data jsou z pěti tabulek joinované". Ale ne "udělejte mi komplexní aplikaci.

Btw: [52] - to co popisuješ je vztah firma - firma, ne firma - programátor (jedna fyzická osoba). Chtěl bych vidět jak takovou smlouvu táhne z rukávu programátor na jednání s firmou. Táhnul by. Velice rychle.

Živím se tím jako projekťák.

Ok, upravím své tvrzení: Jestli chcete pevnou cenu a není to rychlovka dle stručného popisu výše kupte si krabicové řešení.

Na fixnu sumu by som nikdy nesiel. Teda okrem pripadu, ze by bola 100-nasobkom mojho odhadu :-) Pri fixnej cene, si klienti velmi radi vymyslaju, podla ich nazoru malickosti, ktore ked odmietnete, tak to beru ako neochotu (za tie prachy, nam to nechce urobit). Viem ze by sa to dalo riesit zmluvami, hlbkovymi analyzami a hardcore popismi, ale to ma absolutne nebavi, nie som uradnik ani pravnik. A nepotrebujem to, nikoho nenutim. Klientovi dam odhad, ale potom sa uz ide na realne hodiny, s tym ze si moze priebezne sledovat stav cez web v track systeme. Nemam dovod davat si tam zbytocne hodiny, prace je dost. Okrem toho neviem kto vsetko vidi konecne vykazy prac a nerad by som bol za idiota. Meno si clovek pokazi velmi rychlo a tazko sa to naprava. To mi za par tisic ojri nestoji.

[53] V současnosti dělám pro zákazníky z oboru průmyslové automatizace. Pokud jsem daný typ projektu už dělal, tak běžně nabízím fixní cenu za kompletní aplikaci (někdy i s dodávkou HW). Zákazníci to tak požadují, protože i oni svým zákazníkům většinou dodávají za fixní cenu.
Kompletní aplikace dělám většinou menším firmám. Pokud pracuji pro nějakou velkou firmu, tak obvykle nedodávám aplikaci, ale pracuji jako najatý živnostník a potom je sazba za hodinu.

Když jsem pracoval jako zaměstnanec pro SW firmu a měli jsme zákazníky z jiného segmentu, tak některé kšefty byly per hodina, jiné fixní.

To s tím, že by se smlouvou letěl, to bohužel nechápu, jak myslíte. Je jasné, že když proti velké firmě vytáhnu svou smlouvu, tak mě řeknou, bohužel - podepisuje se ta naše a hotovo. Ale proti malé firmě se často dá na smlouvě dohodnout. S velkou firmou jsem smlouvu o hotové aplikaci za fixní cenu ještě nepodepisoval.

A poslední větu nechápu už vůbec. Krabicové řešení a vlastní vývoj jsou jiné světy. Pokud pro daný problém existuje krabicové řešení, tak ho zvolí všichni, protože vývoj vlastní aplikace by je přišel o několik řádů dráže. Fakt neznám nikoho, kdo by vyvíjel na zákazku něco, co existuje jako krabicový produkt (nepočítám různé podfuky ve státní správě, kdy jde o jiné cíle).
Já a zřejmě všichni ostatní tady děláme právě věci, které nemají krabicovou alternativu, tak mi ta vaše věta fakt nedává pražádný smysl.

Ja mel vzdycky za to, ze "stavebni dozor" je prace it reditele v danem podniku. Precejenom, jak by mohl it reditel ridit, kdyz nezna svuj obor ;-)