Starší komentáře ke článku: Neokrádejte své klienty aneb jak také dělat (nejen) web
Zpět na článek | Úvodní stránka Interval.cz
Datum vložení: 2.12.2002 7:48:22
Sice to s článkem příliš nesouvisí, ale zaujala mě formulace, že Alice z dilbertovských stripů "nevyléčitelně umírá." Už jste někdy někdo viděl někoho, kdo by umíral vyléčitelně? :) Možná byla nevyléčitelně nemocná, jiná formulace je trošku zavádějicí.
S článkem to ale opravdu nesouvisí, jen mě to to zrovna aktuálně pobavilo. Jinak hodnotím článek jako výborný a těším se na jeho pokračování. Díky.
Datum vložení: 2.12.2002 9:18:05
Pěkné dopoledne,
ano, občas někde zbude zajímavý obrat :o) Teď nevím, zda to opravit nebo nechat, neboť jsem rád, že Vás to pobavilo. I když - takových obratů je už tak jinde dost, tedy s dovolením opravím :) A samozřejmě se omlouvám za nedopatření.
Datum vložení: 2.12.2002 11:46:20
Dekuji Markovi za promptni opravu, uznavam, ze to vypadalo ponekud divne.
Ale na druhou stranu zrovna neboha Alice je prikladem cloveka, ktery umiral vylecitelne, aspon soude podle toho, ze se v Dilbertovi objevuje i nadale.
Ovsem na stranu treti tato skutecnost jen podtrhuje nevhodnost, ba i vecnou nespravnost puvodni formulace :-)
Datum vložení: 2.12.2002 12:12:03
On Alici totiz vylecil ten popelar v dilu, ktery se mi z originalu nepodarilo prelozit a cloveku, ktery to preklada pro MF DNES, asi taky ne... Protoze mu vysel nesmysl :)
Datum vložení: 2.12.2002 17:34:53
Mno, ja jsem to asi pochopil... Alice umira na <B>nelecitelnou otravu</B>. Nikoliv <B>nevylecitelne umira</B>. Umira kvuli otrave, na kterou neexistuje lek (je nevylecitelna). Coz vsak neni samozrejme, protoze lze i velice snadno umrit i na chorobu, ktera lecitelna je (ale neleci se)...
Datum vložení: 2.12.2002 13:00:54
Docela hezky clanek, ktery bude urcite pro zacinajici podnikavce v oboru IT prinosem.
V podstate lze souhlasit se vsim co je v clanku napsano, coz svedci o bohate praxi autora...
ad Fluktuace pracovniku...
osobne se na me podepisuje. Nastesti nebylo treba prevzi po nekom rozdelany projekt, nicmene udrzovani hotoveho projektu, obsasne minoritni a predevsim zasadnejsi zmeny jsou casto velkym oriskem, zvlaste pak, kdyz puvodni autor projektu nepouzival komentaru ve zdrojovych kodech a jeho coding style byl naprosto odlisny od meho... Zmeny proto casto vyzdaduji daleko vice casu nez ktery by vzaly v pripade upravy vlastniho kodu... Bohuzel na tuto realitu vetsinou doplaci klient, ktery programatorsky cas zaplati....
Stejne tak se projevuji i zasadnejsi zmeny v prubehu tvorby projektu. Prikladem muze byt navrh databaze, ktery odpovida analyze. Kdyz ale dojde k rozsireni projektu, je casto treba zasahnout i do teto databaze a mnohdy to znamena razantnejsi zmeny v jeji konstrukci. Tato zmena se pak muze projevit i v jiz hotove casti aplikace a je ji treba upravit, ne-li celou prepsat... I kdyz tyto zmeny klient zaplati, tak se na lidech realizujicich projekt projevuji a muze do nich vlozit odpor k projektu, coz pak znamena mensi efektivnost...
Datum vložení: 2.12.2002 15:32:39
Dobrý den,
docela mně zaujala Vaše zmínka o tom, že případné "nedopatřenosti" při vývoji zaplatí klient. Jelikož nemám žádné zkušenosti s řízením programatorských projektů, docela by mně zajímala běžná praxe soft. firem.
Měl jsem za to, že praxe typu: "na této úpravě budu dělat asi tak 10hodin, ale je možné že během dělání přijdu na nějaké mouchy, které to nafouknou na 20hodin. Každopádně to všechno zaplatíš ty."
Domníval bych se, uznávám že možná chybně, že tyto nedostatky ze strany programátora by měly být součástí podnikatelského rizika. Neměla by se domlouvat dle zadání spíše paušální cena než zaplatit výsledné člověko-hodiny?
Moc dík za Vaše odhalení kalkulací IT projektů :)
Petr
Datum vložení: 2.12.2002 16:00:58
Co se tyce oprav chyb, tak je samozrejme ze se na ne vaze zaruka. Hovoril jsem o tom, ze v pripade, kdyz budu upravovat cizi kod, bude mi to trvat misto napriklad 5 hodin (co by trvala uprava vlastniho kodu), hodin napriklad 8, protoze se nejdrive musim zorientovat ve stavajicim kodu...
Datum vložení: 2.12.2002 16:03:29
Jeste dodatek...
kdyz si samozrejme klient v prubehu prace vymysli, ze to bude cely jinak, tak se snad nejedna o nedopatreni pri vyvoji a je samozrejme ze zmeny si bude muset klient zaplatit.
Datum vložení: 2.12.2002 16:28:24
Ale předpokládám, že nyní hovoříte o případu, kdy Vás klient požádal o úpravu stávajícího kódu, který nepocházel z Vaší dílny.
Ale nehovoříte o případu, kdy jeden z Vašich zaměstnanců vytvořil projekt a v další fázi projektu již nebyl přítomen ve společnosti - a tedy zorientování se v kódu novým zaměstnancem je dle mého názoru věcí výhradně Vaší společnosti?
<I>jedná se pouze o příklad a nikoli žádnou praktickou zkušenost.</I>
Datum vložení: 2.12.2002 16:46:05
V tomhle pripade resime rozpor - pochopitelne naklady na implementaci zmeny zadani by mel uhradit klient, na druhou stranu zde muze dodavatel hresit na to, ze klient do nakladu az tak nevidi.
Dodavatel samozrejme muze na rovinu rict <I>"Heledte, toho programatora pokousal na dovolene vztekly velbloud, takze to musi delat nahradnik. Naklady na nej mame stejne, ale on do toho az tak nevidi, a proto to bude stat vic penez"</I>. Pak uz je na vztazich mezi obema subjekty, jestli si dodavatel nevymysli, a jestli to zakaznik akceptuje. V temer idealnim pripade je dodavatel spolehlivy a ma klientovu duveru, takze klient akorat resi otazku, zda dodavateli prozene perka, a nebo si <B>vyjimecne</B> priplati, protoze vi, ze problem existuje a jeho financni podceneni se promitne do kvality.
A v pripade uplne idealnim je riziko komplikaci zpusobene vzteklymi velbloudy eliminovano na minimum (napr. pomoci technik extremniho programovani) a tudiz problem prakticky neexistuje :-) Ono je i v zajmu dodavatele, kdyz nemusi pokouset trpelivost sveho velevazeneho klienta.
Datum vložení: 2.12.2002 16:52:29
V obou pripadech je to stejne... cas straveny nad praci je treba nejak zaplatit. Toto je vsak v rezii obchodniku a muj nazor muze byt jakykoli... Vzdy uvadim celkovy cas straveny nad praci, do ktere se samozrejme zapocitava i konzultace mezi mnou a klientem ci project managerem...
Treba velice dobra taktika firem je veskere (v mem pripade se jedna o serverside reseni v PHP) programove kody predavat v podobe, ve ktere s nimi neni schopen zadavatel nic dalsiho udelat. V PHP lze pouzit napriklad Zend Encoderu, ktery vyprodukuje kryptovane skripty, ve kterych jiz nelze provest zmenu.
Ma to dve vyhody. Prvni je, ze v pripade zasahu do zdrojovych kodu MUSI jit za Vami aby jste zmeny provedl, coz samozrejme prinasi firme dalsi praci a potazmo penize. Druhou vyhodou je fakt, ze z hotove prace nemuze klient vycist Vase know-how, coz je mnohdy daleko cennejsi nez samotny projekt.
Samozrejme je treba ve smlouve specifikovat zda bude mit klient ke kodum pristup ci nikoli, pro pripad, kdyby se kodu domahal za kazdou cenu, tak staci predlozit smlouvu a ukazat prstem na tuto dolozku...
Datum vložení: 2.12.2002 17:16:57
Na druhou stranu je třeba řešit i rizika klienta. Klient musí být chráněn proti riziku, že dodavatel přestane existovat nebo se na něj vykašle. Solidní dodavatel by na to měl ve smlouvě pamatovat i v případě, že klienta to nenapadne (a pokud do toho nevidí, pak ho to opravdu nenapadne). Konkrétně specifikací nějakých podmínek, za kterých klient dostane zdrojové texty pro potřeby dalšího vývoje, pokud dodavatel dále produkt vyvíjet nemůže (přestane existovat) nebo nechce (změní zaměření a není to pro něj efektivní).
Datum vložení: 2.12.2002 17:26:30
Zalezi na tom co si klient kupuje.
Pokud si zadavatel kupuje licenci na uzivani aplikace, kterou dostal, tak neni duvod mu v takovemto pripade zdrojove kody poskytnout. Ze strany dodavatele je prece smlouva dodrzena - klient dostal to co chtel a je to funkcni.
Je to v podstate to same, jako kdyz si koupite napr. Windows - mate funkcni (no nekdo ne zcela funkcni ;-)) OS. Dostal jste to co jste zadal. Pokud by MS zkrachoval a neuvolnil zdrojove kody (coz by v tomto pripade nemusel), tak s tim take nic neudelate.
Datum vložení: 2.12.2002 17:46:19
To sice ano, ale můj pohled je ovlivněn tím, že neprodukuji krabicový software, ale projekty na míru. Pokud se jedná o informační systém, na kterém je organizace závislá, pak potřebuje mít jistotu, že když mne přejede auto (nebo mne přestane bavit se s nimi pořád hádat a nechám se někde zaměstnat), nebudou si muset nechat systém napsat celý znova. Samozřejmě bych to mohl hodit za hlavu (pak už mi to může být jedno), ale považuji upozornění klienta na tuto eventualitu za projev slušnosti.
Datum vložení: 2.12.2002 16:32:17
Samozrejme vzdy zalezi na tom, co se podari domluvit. Obecne vzato vzdy si dodavatel na sebe nejake riziko bere, a cim vetsi, tim snaz se mu podari projekt ziskat. Na druhou stranu racionalne uvazujici klient by mel zvazit, ze podezrele vyhodna a pro nej bezrizikova nabidka nemuze byt proste iracionalni vyplod prilis agilniho obchodnika slibujici necekane potize.
U trochu vetsich projektu je casta praxe takova, ze se projekt rozdeli do minimalne dvou fazi - prvni (analyticka) ma pomerne jasny rozpocet a harmonogram, faze implementacni je pak odhadnuta velmi hrube a jeji doladeni je pak soucasti analyzy. Pricemz ukaze-li se, ze vlastni realizace by byla pro klienta neprijatelna, ma klient pravo se na implementaci vykaslat, pripadne pouzit analyzu pro implementaci vlastnimi silami ci s jinym dodavatelem. Presne nastaveni techto podminek ale zavisi projekt od projektu na spouste faktoru a urcite na to nejde dat univerzalni recept.
V clanku jsem ale nemel na mysli rizika zpusobene <B>chybami vyvojaru</B>, ale spise necekane <B>zmeny zadani</B> ze strany klienta v prubehu projektu. A takovato rizika by urcite dodavatel nest v zasadni mire nemel. (A pokracovani bude prave o jednom ze zpusobu, jak i toto riziko zvladat k oboustranne spokojenosti. :-)
Jeste pisete:
<I>"Neměla by se domlouvat dle zadání spíše paušální cena než zaplatit výsledné člověko-hodiny?"</I>
To opravdu zalezi na slozitosti projektu. Pokud je napriklad mou zakazkou prevod hotoveho grafickeho navrhu do (x)HTML prezentace o peti strankach, urcite nabidnu pevnou cenu a v pripade potreby drobnych uprav nebudu svolavat schuzi projektove komise o zmenovem rizeni :-)
Na druhou stranu pokud se narocnost projektu pohybuje v clovekomesicich, je treba navrhovat rozsahlejsi databazi, resit integraci se stavajicimi systemy a kdo vi co jeste, rozumny obchodnik si nelajsne slibit zakaznikovi pevnou cenu za pevny rozsah a nadto nijak smluvne neosetrit reseni problemu - bud by tim strasne riskoval prodelecny projekt s pozdeji se vynorivsimi nejtvrdsimi projevy v clanku zmineho "boje o rizika" , nebo naopak by musel rizika schovat do notne nadsazene az nekonkurenceschopne ceny.
Opet, hranice mezi "malym" a "velkym" projektem zavisi na spouste veci jako charakter projektu, zkusenosti dodavatele, na spolupraci zakaznika...
Kdyz si to tak po sobe ctu, mohl bych cely tento dlouhatansky prispevek shrnout do jedne vety "ono je to slozite" :-)
Datum vložení: 2.12.2002 17:19:11
Z vlastni zkusenosti:
Jedna li se o novy projekt, vytvari se celkova - pausalni kalkulace, ktera si vsak nechava urcitou rezervu v podobe cenoveho rozsahu - napriklad:
navrh a realizace databazoveho reseni 50 - 60 tisic Kc...
Mnohdy v nich byvaji i volitelne moznosti, ze kterych si klient vybira... pro tyto jednotlive "pluginy" je stanovena samostatna kalkulace. Napriklad:
emailing s moznosti administrace 8.000Kc
tyto ceny se samozrejme scitaji... Tyto ceny vsak vychazeji z casoveho odhadu clovekohodin, ktere se vynasobi hodinovou sazbou. Samozrejme se bere ohled na vazenost klienta a celkovy objem praci.
Obecne lze take rici, ze cim narocnejsi projekt je, tim vetsi byva cenovy rozptyl (a samozrejem i samotna minimalni cena).
Mezi dalsi faktory ceny by se urcite radi vazenost dodavatele. Cim vetsi jmeno v oboru firma ma, tim vice si muze vuci svym klientum dovolit. Zni to sice tvrde, ale v pripade kdy se chce firma chlubit tim ze ji web delal ten a ten, tak je to dost dulezite... jednoduseji receno zadavatel plati i za znacku.
Cenu take bude ovlivnovat account servis. Pokud bude dodavatelem firmicka o jedinem clovickovi, tak klient asi nedostane kvalitni account servis, protoze to bude programatora odvadet od prace, kdyz bude klientovi dve hodiny vysvetlovat, ze zazipovanou prilohu emailu kterou odesila vytvarena aplikace, otevre tak ci onak, a ze zip musi rozbalit v tom ci onom programu a na rozbaleny soubor se musi podivat v nejakem programu... nebo ze pro hotovou aplikaci potrebuje klient jeste webhosting a ze ten uz neni v cene vyvoje zahrnut...
obdobnych prikladu by se naslo daleko vice.
Pokud vytvorime graficky navrh na web, zprogramujeme ho a klient si usmysli, ze bude chtit nove vytvoreny web propagovat tistenymi materialy ci treba na billboardech, a dodavatel je mu schopny toto zaridit, tak si opet muzete dovolit vyssi cenu - odvadite pro klienta fullservice - ten se nemusi starat o prevedeni weboveho navrhu do formatu vhodneho pro billoard, nemusi se starat kde si necha vytvorit obsah reklamniho CD, nasledny potisk samotneho CD, stejne tak jako bookletu a inlayu. To klientovi samozrejme setri cas...
Datum vložení: 3.12.2002 8:34:29
Zdravim Vas,
toto je moj pohlad na vec :) :
Kazdy projekt, ci uz v oblasti IT alebo akejkolvek inej (napr. stavba dialnice) sa vyznacuje casovou a nakladovou nestabilitou.
Projekty z pohladu dodavatela mozme este rozdelit na "bezne" a tzv. "ambiciozne". U beznych projektov dodavatel ma iste skusenosti - riesil podobne projekty, ambiciozny projekt je pre dodavatela uplnou neznamou (napr. stavebna firma dostala zakazku na dialnicu, aj ked ju este nikdy nestavala).
Tieto specifika vytvaraju neprijemne prostredie pre projektove organizacie, ktore nedokazu s urcitostou odhadnut svoje naklady. Kedze sa tu az na par vynimiek ozyvaju hlavne "dodavatelia" rad by som podotkol, ze aj v tejto oblasti platia zakony trhu, a ten kto dava pracu a peniaze je zakaznik a je len na nom, nakolko bude tolerovat vykyvy casoveho/financneho planu.
Ulohou dodavatela by malo byt urcit odhady na potrebny cas a financie co najpresnejsie. Nizke hodnoty mozu priniest problemy s naplnanim planu, prilis vysoke hodnoty su konkurencnou nevyhodou. Projektova organizacia by si mala viest podrobne udaje o plneni predoslych projektov, analyzovat ich a vyhodnocovat. V pripade beznych projektov je mozne dosahovat celkom uspokojive odhady. Najlepsie firmy v tejto oblasti dosahuju aj 80% uspesnost ukoncenia projektov v limite - aka je vasa uspesnost? Niekedy je viac vyhodou - ak si urcite po dokladnej analyze financie a terminy vyssie ako konkurencia, ale viete deklarovat, ze predosle projekty plnite 70% v limite, ostatne ste prekrocili v 90% maximalne o 20% zakaznik vie ze ten odhad je (pravdepodobne) realny/podlozeny dobrou analyzou.
Z podstaty projektovych organizacii vyplyva, ze odhady nakladov a casu su podstatnou sucastou ich cinnosti. V odhadoch sa musi ratat aj s tym s cim sa vobec nerata :) nieto este s niecim tak samozrejmym a beznym ako je zmena poziadaviek zakaznika pocas behu projektu. Samozrejme, moze to byt osetrene zmluvne, ako a co sa bude korigovat/reanalyzovat po novom zadani a kto nesie riziko, to uz je dohoda medzi oboma stranami. S nejakymi zmenami zo strany zakaznika by sa vsak malo ratat uz v zaciatkoch, v akom rozsahu sa najlesie dozvieme z predoslych projektov/skusenosti.
V pripadoch, ked kvoli trhovym tlakom musime dojednat casy a naklady mimo odhadovanych, mame predstavu ake riziko nesie organizacia a ci ho sme schopny/ochotny vykryt.
V zasade na tieto otazky neexistuju presne odpovede, len odporucane postupy pre organizacie a vsetko zavisi od schopnosti projektovych manazerov. V zasade vsak denne riesime svoje kazdodenne osobne projekty cize kazdy z nas je mensim ci vacsim projektovym manzerom, no ti ktory sa tym zivia by nemali nechavat nic na nahodu a prestudovat si aspon zaklady projektoveho manazmentu.
Zdravi/Pcolka
Datum vložení: 3.12.2002 13:19:18
Nelze nez naprosto souhlasit, zejmena s poslednim odstavcem.
Datum vložení: 2.12.2002 15:39:43
Chci pochvalit autora za výborný článek, me zkušenosti jsou téměř shodné.
Datum vložení: 12.6.2003 20:04:07
Ano, velmi prinosne, zejmena pro ty, co nikdy neslyseli o rizeni projektu nebo softwarovem inzenyrstvi.
Nicmene pokud chcete, aby vase produkty byly opravdu kvalitni, berte tenhle clanek jako bibli. Pak se vam povede, ze to, co vytvorite, bude stejne dobre, jako stranky <a href='http://www.templation.cz/' target='_blank'>http://www.templation.cz/</a> pod IE (6)!
Datum vložení: 12.6.2003 20:47:44
heheh... pekne stranecky... este ze mam mozillku :-))