Cenový odhad projektu – kolik byste si účtovali?

Tady jde nacenit to stažení a zpracování XMLka a to ještě zhruba, když ani nevíme o jaké XML se jedná (struktura, velikost ..) . Nikdo neví, jak přesně to bude data zpracovávat a co z nich bude poté potřeba získávat. Dokážu si pod zadáním představit jednoduchou aplikaci která zabere 30 hodin vývoje a druhou složitou klidně i na 200 hodin.

Napsal Martin Kejzlar;1279679

Tady jde nacenit to stažení a zpracování XMLka a to ještě zhruba, když ani nevíme o jaké XML se jedná (struktura, velikost ..) . Nikdo neví, jak přesně to bude data zpracovávat a co z nich bude poté potřeba získávat. Dokážu si pod zadáním představit jednoduchou aplikaci která zabere 30 hodin vývoje a druhou složitou klidně i na 200 hodin.

Kazde XML je v rozsahu cca 500 polozek:id, titulek, obrazek, url, kratky popis, datumAktualizace je denne.

ani důkladné sepisování a vysvětlování mi moc nikdy nefungovalo. S netechnickými klienty jsem zažíval hlavní problém v tom, že nejsou schopni dopředu si produkt ani s pomocí dobře promyslet a požadují změny v průběhu nebo až na konci a očekávají, že to je pořád v rámci původního budgetu. Někdy se jedná o hodně razantní změny na celém projektu.Další velká komplikace je v komunikaci, veškeré časové odhady, které jsme dávaly byly časové náklady na naší práci, nikoliv termíny, kdy to bude a nevztahovaly se na prodlení na straně klienta. Stala se mi úsměvná situace, kdy klient i přes urgence nedodal nutné podklady, ale následně vyhrožoval soudem, že jsme mu projekt včas nedodali, součástí podkladů byla samozřejmě i podepsaná smlouva...Nemyslím si, že úvodní žádost o nacenění byla vhodně položená, většina podobných dotazů tady je od lidí, kteří chtějí za daný projekt co nejméně, chtějí to od jednotlivých programátorů a ne od firem a na nějaké řízení kvality nebo procesů si vůbec nepotrpí a nevidí v tom výhodu. Zpravidla prozuji WP, prestashop nebo mají geniální revoluční nápad na projekt, který ale nemohu říct ani programátorovi. Proto i všechny ostatní odhady byly tak nízké a v řádu hodin. U poptávky je často vhodné začít přibližným rozpočtem - tísíce, desítky tisíc ... miliony nebo aspoň by to měla být první otázka.Z pohledu klienta je pro mě těžko akceptovatelné navyšování rozpočtu, to naprosto chápu, nikdy nechce si objednat ledničku a při převzetí za ní ještě 50 % doplatit aniž by mu to někdo dopředu řekl. Tahle skupina lidí bere vývoj na zakázku jako zboží a přesně tak jim ho chce prodávat. Z pohledu dodavatel si zase neumím představit, že nacením něco, co ještě nevím jak bude vypadat, protože nezkušený malý klient má tendence do toho v průběhu zasahovat a měnit nebo naopak chce vývoj něčeho nového (rozpoznávání obrazu z bezpečnostní kamer např.) a u výzkumu se odhady dělají složitě.Právě jak jsem zmiňoval, osvědčil se mi agilní přístup. Na začátku se dohodneme co je cílem, jaké jsou očekávání, jaký rozpočet a jaké má klient představy. Co je pro něj důležité a co naopak ne. Udělá se určitý rámec, sestaví tým a určií se časová alokace (tj. klient zaplatí měsíc práce a má jistotu, že dostane funkční věc), sepíší se user storky. Klient musí pravidelně docházet, ideální je, když je sám součástí týmu a může ovlivňovat vše v počátku a být u diskuzí. Většinou k nám klient chodí na půl dne alespoň jednou týdně a řada věcí se supluje konferenčními hovory. Jsou ale i takoví, kteří nám nechají naprosto volnou ruku, on pak ve výsledku v tom není velký rozdíl, produkty mají tak nebo tak určitou úroveň a klient k tomu může přistupovat jak sám chce.

Napsal TomášX;1279687

ani důkladné sepisování a vysvětlování mi moc nikdy nefungovalo. S netechnickými klienty jsem zažíval hlavní problém v tom, že nejsou schopni dopředu si produkt ani s pomocí dobře promyslet a požadují změny v průběhu nebo až na konci a očekávají, že to je pořád v rámci původního budgetu. Někdy se jedná o hodně razantní změny na celém projektu.

Další velká komplikace je v komunikaci, veškeré časové odhady, které jsme dávaly byly časové náklady na naší práci, nikoliv termíny, kdy to bude a nevztahovaly se na prodlení na straně klienta. Stala se mi úsměvná situace, kdy klient i přes urgence nedodal nutné podklady, ale následně vyhrožoval soudem, že jsme mu projekt včas nedodali, součástí podkladů byla samozřejmě i podepsaná smlouva...

Nemyslím si, že úvodní žádost o nacenění byla vhodně položená, většina podobných dotazů tady je od lidí, kteří chtějí za daný projekt co nejméně, chtějí to od jednotlivých programátorů a ne od firem a na nějaké řízení kvality nebo procesů si vůbec nepotrpí a nevidí v tom výhodu. Zpravidla prozuji WP, prestashop nebo mají geniální revoluční nápad na projekt, který ale nemohu říct ani programátorovi. Proto i všechny ostatní odhady byly tak nízké a v řádu hodin. U poptávky je často vhodné začít přibližným rozpočtem - tísíce, desítky tisíc ... miliony nebo aspoň by to měla být první otázka.

Z pohledu klienta je pro mě těžko akceptovatelné navyšování rozpočtu, to naprosto chápu, nikdy nechce si objednat ledničku a při převzetí za ní ještě 50 % doplatit aniž by mu to někdo dopředu řekl. Tahle skupina lidí bere vývoj na zakázku jako zboží a přesně tak jim ho chce prodávat. Z pohledu dodavatel si zase neumím představit, že nacením něco, co ještě nevím jak bude vypadat, protože nezkušený malý klient má tendence do toho v průběhu zasahovat a měnit nebo naopak chce vývoj něčeho nového (rozpoznávání obrazu z bezpečnostní kamer např.) a u výzkumu se odhady dělají složitě.

Právě jak jsem zmiňoval, osvědčil se mi agilní přístup. Na začátku se dohodneme co je cílem, jaké jsou očekávání, jaký rozpočet a jaké má klient představy. Co je pro něj důležité a co naopak ne. Udělá se určitý rámec, sestaví tým a určií se časová alokace (tj. klient zaplatí měsíc práce a má jistotu, že dostane funkční věc), sepíší se user storky. Klient musí pravidelně docházet, ideální je, když je sám součástí týmu a může ovlivňovat vše v počátku a být u diskuzí. Většinou k nám klient chodí na půl dne alespoň jednou týdně a řada věcí se supluje konferenčními hovory. Jsou ale i takoví, kteří nám nechají naprosto volnou ruku, on pak ve výsledku v tom není velký rozdíl, produkty mají tak nebo tak určitou úroveň a klient k tomu může přistupovat jak sám chce.

Tomuto naprosto rozumim, a mnoha firmam se osvedcuje agilni zpusob, dokazete vsak rict ze agilnimu vyvoji klienti rozumi ? Ze jej chapou spravne, ve vasem pripade jste zminil nekolikrat nastavite plan, v mnoha pripadech klient doda zadani a odmita jakoukoliv analyzu, "vse doda" vse je jasne. I napric tomu ze se upovedomi ze se mohou objevit necekane veci, casti ktere budou navic. Tehdy se stava ze klient po nejasnym a obecne popsanym modulem a casti, obraci list a rika vzdyt to je z toho jasne, nebo odmita skutecnost ze by dana polozka mela byt vice pracemi.Komunikace muze pomoct, no jak vime ve vyvoji je mnoho uskali ktere mohou prekvapit zavyslostmi ktere je nutne pridat a vytvareji novy rozsah, ktery klient odmita akceptovat protoze to povazuje za samozrejmost.Nejvice postihovane zakazky jsou v malem a strednim rozsahu, u velkych je toto vyjmecnost ze se neco podobneho udeje.

Napsal TomášX;1279687

ani důkladné sepisování a vysvětlování mi moc nikdy nefungovalo. S netechnickými klienty jsem zažíval hlavní problém v tom, že nejsou schopni dopředu si produkt ani s pomocí dobře promyslet a požadují změny v průběhu nebo až na konci a očekávají, že to je pořád v rámci původního budgetu. Někdy se jedná o hodně razantní změny na celém projektu

........

Jsou ale i takoví, kteří nám nechají naprosto volnou ruku, on pak ve výsledku v tom není velký rozdíl, produkty mají tak nebo tak určitou úroveň a klient k tomu může přistupovat jak sám chce.

Toto je jeden z nejlepších příspěvků, který jsem za 9 let na Webtrhu četl! Rep+

Ne, nerozumí mu, proto ho nezmiňujeme, pouze říkáme, že pokud nemá jasnou představu, může průběh ovlivňovat, ale potom je nutné osekat funkčnost na minimum, to se stihnout musí a zbytek podle přání a náročnosti. Pochopení náročnosti hodně pomáhá to, že vidí přímo programátory, kteří ten čas odhadují a pracují na tom, řešení diskutují. Povětšinou máme v týmu 4 - 5 programátorů, takže vývoj pokračuje hodně rychle.Ano, to klienti dělají, k tomu je podstatná část zadání rozprava o tom, jaké barvy kde použít a jaká kde bude textace. Proto se s ním musí sednout, ukázat mu podobné projekty, vysvětlit mu jak k tomu přistupuje zákazník, poptat se ho, pro koho to vůbec bude a proč si myslí, že to chce takhle. Ty nekvalitní zadání jsou jen výsledkem toho, že nutíme klienty ty zadání psát, pak vypadají jak vypadají.Úvodní diskuze zaberou i několik dní čistého času, je nutné pro nás správně rozkličkovat rozsah a typ projektu, rozložit na základní části a stanovit technologie, způsoby řešení, aspoň přibližně. Plánem jsem myslel zejména interní plán, vždy se musí jakákoliv práce rozkouskovat a rozplánovat, alespoň do nějakého gantova diagramu, bez toho není možné správně řídit zdroje, grafik prostě nemůže několik dní sedět a čekat až se na něj dostane řada. Tohle je ale na zodpovědni projekt managera, který dělá rozpis práce, stanovuje postup, komunikuje s klientem, vysvětluje mu problematiku a tlumočí "nesmysly" od programátorů.Člověk tady nadává na malé klienty, ale ti velcí jsou ještě horší, člověk komunikuje s někým, kdo to má na starosti, ale nerozumí tomu. Smlouvy nepodepisuje, na vše se musí zdlouhavě ptát ostatních oddělení a celkově práce hodně vázne, tam je agilní přístup hodně těžko uchopitelný.

Napsal TomášX;1279701

Ne, nerozumí mu, proto ho nezmiňujeme, pouze říkáme, že pokud nemá jasnou představu, může průběh ovlivňovat, ale potom je nutné osekat funkčnost na minimum, to se stihnout musí a zbytek podle přání a náročnosti. Pochopení náročnosti hodně pomáhá to, že vidí přímo programátory, kteří ten čas odhadují a pracují na tom, řešení diskutují. Povětšinou máme v týmu 4 - 5 programátorů, takže vývoj pokračuje hodně rychle.

Ano, to klienti dělají, k tomu je podstatná část zadání rozprava o tom, jaké barvy kde použít a jaká kde bude textace. Proto se s ním musí sednout, ukázat mu podobné projekty, vysvětlit mu jak k tomu přistupuje zákazník, poptat se ho, pro koho to vůbec bude a proč si myslí, že to chce takhle. Ty nekvalitní zadání jsou jen výsledkem toho, že nutíme klienty ty zadání psát, pak vypadají jak vypadají.

Úvodní diskuze zaberou i několik dní čistého času, je nutné pro nás správně rozkličkovat rozsah a typ projektu, rozložit na základní části a stanovit technologie, způsoby řešení, aspoň přibližně. Plánem jsem myslel zejména interní plán, vždy se musí jakákoliv práce rozkouskovat a rozplánovat, alespoň do nějakého gantova diagramu, bez toho není možné správně řídit zdroje, grafik prostě nemůže několik dní sedět a čekat až se na něj dostane řada. Tohle je ale na zodpovědni projekt managera, který dělá rozpis práce, stanovuje postup, komunikuje s klientem, vysvětluje mu problematiku a tlumočí "nesmysly" od programátorů.

Člověk tady nadává na malé klienty, ale ti velcí jsou ještě horší, člověk komunikuje s někým, kdo to má na starosti, ale nerozumí tomu. Smlouvy nepodepisuje, na vše se musí zdlouhavě ptát ostatních oddělení a celkově práce hodně vázne, tam je agilní přístup hodně těžko uchopitelný.

To naprosto chapu a je to spravny, postup presto mnohdy narazite na klienty ktere jsem zminil predtim, domluvite se na agilnim vyvoji a na nevyjasnene budoucnosti ktera se vyjasni pocas vyvoje. nastavite orientacni, termin a plan + cenu a podepisuje se smlouva. V prubehu objevujete veci ktere tlumocite klientovi dle dohody, pro naplneni jednotlivych sprintu, u 3 sprintu klienta ormzi, nebo znervozni z navysovani sumy a zacne se ucukavat a vetsinou vznika spor, tuto situaci jsme jiz jednou zazili a jak se bavim se znamymi neni to nic neobvykleho.Samozrejme u velkych klientu se dela analyza aby se predeslo agilnimu vyvoji a stanovila se fixni cena za fixni projekt, coz je v mnoha pripadech nejlepsi a take zde zalezi od druhu klienta s nekterymi se pracuje uzastne s nekterymi ne. ( nemluvil jsem o klientech mimo jine ale o rozsahlosti projektu ).Proto verim, ze takovy clanek, ktery by popisoval co lze kdy ocekavat je velice vhodny pro uvod klienta do sveta IT a ocekavani od dodavatele, stejne tak pro nezkuseneho dodavatele ktery pristoupi na cenu aniz by si overil zdali to je mozne viz, 2 prispevek s extremne nizkou cenu.

článek může být zajímavý :).Ano, vždy jsou nějaké problémy. Unavenost klienta jsme vyřešili zvětšením týmu na až 5 programátorů, to pak jsme schopni většinu projektů dodat do měsíce. Na měsíc programování stanovíme pevný rozpočet a většinou toho stihneme více než si klient představuje, takže je spokojený. Je to celé ale už taková věda.

Napsal TomášX;1279709

článek může být zajímavý :).

Ano, vždy jsou nějaké problémy. Unavenost klienta jsme vyřešili zvětšením týmu na až 5 programátorů, to pak jsme schopni většinu projektů dodat do měsíce. Na měsíc programování stanovíme pevný rozpočet a většinou toho stihneme více než si klient představuje, takže je spokojený. Je to celé ale už taková věda.

Zde je obava, 5 programatoru znamena 5x vetsi cena za mesic. Coz znamena rychly vyvoj ale daleko vyssi cena, coz byva z vetsiny nejvetsi kamen urazu klienta.

to je na projekt managerovi, jestli usoudí, že více lidí zvýší rychlost nebo se budou akorát motat. Ano, náklady za měsíc jsou vyšší, ale klient pak nečeká na nějaký modul týden, ale klidně den a půl. Samozřejmě musí více lidí dávat smysl a nesmí mít prostoje.Máme ve firmě přes sto programátorů a to nám umožňuje relativně dobře vyvažovat zdroje a zapojení, k tomu máme svoje produkty, na kterých je pořád co dělat...

Pojdme se teda zamerit na ten cenovy odhad prosim a pripadne dalsi pripady ktere se Vam udeli, bez techto informaci zadny clanek kterybude mit smysl a realne podklady nebude. :) Dekuji.