Vlákno názorů k článku Budoucností vývoje velkých e-shopů jsou agilní kontrakty od Anonymous - pri agilnim vyvoji platit vzdy za hodiny. a...
-
Anonymous (neregistrovaný)
pri agilnim vyvoji platit vzdy za hodiny. a pokud je omezeny rozpocet, tak se pri agilnim vyvoji nemusi dostat na vsechny pozadavky (a proto by mely byt na zacatku zprioritizovane). kolegyne mela hezky obrazek, kde ukazovala rozdil mezi waterfallem s jeho dimenzemi/"trojimperativem" (cena-kvalita-cas) a agilnim pristupem (pri stanovenem rozpoctu se pracuje, dokud se nevycerpa, teda pokud se nahodou nestihne vsechno udelat)
nicmene dovedu si predstavit, ze kontrakt s dodavatelem kapacit na IT vyvoj bude znit "za 3 miliony kapacity analytika a za 3 miliony kapacity vyvojare" a kdyz bude chtit pak pokracovat, tak si priobjedna. ale to je zase platba "za hodiny". -
Lukáš Heinz (neregistrovaný)
Uvedu to hned ze začátku - dělám v ShopSys.
Souhlasím, že pro dodavatele je lepší dodat SW. Problém je, že u velkých projektů od zadání k předání uplyne několik měsíců a my sice dodáme SW podle zadání a analýzy, ale zákazník už to takto nechce a nepotřebuje, protože se změnila situace na trhu, je nový trend nebo se změnil obchodní ředitel a mají novou strategii (vše jsou reálné případy). Pro nás by bylo nejlepší jim to předat s tím, že vše je podle domluvy hotovo. Ale klient bude naštvaný. A to není situace, kterou chceme.
Proto se teď orientujeme na agilní kontrakty, protože zde může klient v půlce, kdy dostane část funkcí, říci, že toto už takto nechce a pak se řeší, jaké věci se odsunou. Také průběžně vidí, co je uděláno a průběžně si funkce přebírá... Je to pak více o komunikaci a domluvě a je mnohem větší pravděpodobnost, že na konci budeme jak my, tak klient spokojeni.
-
Dobrý den,
v našem případě analyzujeme, specifikujeme, naceňujeme a kontraktujeme výsledný software. Relizujeme jej ale po sprintech (minimální životaschopný produkt + sprinty). Do jednotlivých sprintů se vybírají úpravy (či jejich části) ze specifikace. A postupně při dokončování sprintů vznikají nové požadavky. Podle jejich priority přeskakují původní zakontraktované úpravy, nebo z nich vzniká fronta "nice-to-have" funkcí, z kterých se pak vybírá po dokončení projektu. Záleží tedy případ od případu.
Petr Svoboda / ShopSys
-
Dobrý den,
v našem případě:
analyzujeme, specifikujeme, naceňujeme a kontraktujeme hotový software. Relizujeme jej ale po sprintech (minimální životaschopný produkt + sprinty)
Do jednotlivých sprintů se vybírají úpravy (či jejich části) ze specifikace. Při předávání sprintů se však například začíná ukazovat, že:
- funkce je dle zadání a wireframu, ale aby byla užitečnější je potřeba ji ještě lehce rozšířit či modifikovat (což si jedna či druhá strana uvědomila až při živém použití)
- některé funkce není tak důležitá jako nápad na novou funkcí (který vznikl při zkoušení jiných živých funkcí)
- data pro definované parametrické filtry není možní v termínu zákazníkem dodat, tuto funkci je možné odložit a raději realizovat něco z "nice-to-have" nově vymyšlených funkcí
- při ukázání životaschopné verze dalším kolegům ve firmě zákazníka, přišly nové nápady na úpravy, ke kterým se na úrovni analýzy/wireframů neuměli vyjádřit (nedokázali si to představit)Nové požadavky se tedy zařadí mezi seznam věcí k realizaci, specifikují, nacení a klient jim přidělí prioritu. Bude-li priorita vysoká, odsune to realizaci méně prioritní funkcí (přestože byly specifikovány a zakontraktovány).
Může samozřejmě nastat situace - a klient si jí je vždy při změnách priorit vědom - že některé funkce nebudou v aplikaci nakonec vůbec realizovány. Pokud je zastropovaný rozpočet, přidávaly se nové funkce a neodebraly žádné jiné, na funkce s nejnižší prioritou se už totiž nemusí vyjít zdroje (využily se na nové prioritnější požadavky).
Petr Svoboda / ShopSys
-
polygon (neregistrovaný)
Jen se zeptám, je to fix price, nebo cost-plus? Má zkušenost je že se všichni co mají něco společného (byť jen slovně) s agile snaží minimalizovat vývojové rozpočty a fixed priced kontrakty a produkt se dodělá, opraví se všechny chyby a doimplementují či přepracují všechny potřebné funkce až během SLA. Stane se pak ale přibližně toto.
Zadavatel nemá zvláštní potřebu moc přemýšlet o zadání. Objednává stylem: chci nové erp, nebo třeba eshop. Má vyčleneněn rozpočet a čas a ví, že produkt doopravdy dostane až po nějaké době běhu servisní smlouvy kdy bude podávat "reklamace". Dodavatel nemá zvláštní potřebu dojednat přesné zadání a ani vlastně jednat o ceně, protože předání je vlastně jen formální, cenu lze snadno uhlídat alokováním těch nejlevnějších lidí a že to bude mít chyby nikoho netrápí.
Během SLA pak nastává, že má zákazník motivaci čerpat co nejvíce hodin (opravy, konzultační hodiny, apod.), zatímco dodavatel ty hodiny již prodal a je motivován jich dodat co nejméně.Na druhou stranu je to status quo akceptovaný již od začátku, takže to takto funguje. Je to ale výhodné, lepší?
Zadavatel zaplatí totéž a dostane tutéž funkčnost jako kdyby produkt objednal za fix a proběhla řádná analýza. Drobné plus je, že rozhodování můžu odložit, je to ale taky prvek nejistoty. Kupuju, ale nevím co. Mínus je, že produkt dostanu v nedeterministickém čase (zřejmě později).
Dodavatel má plus, že nemusí nic plánovat, nemusí nic rozhodovat, nemusí mít kvalitní zaměstnance, nemusí řešit termíny, kvalitu. Vlastně jediné co musí řešit je dohodnout ten kšeft a pak už je to bez rizika. Mínus je, že bez rizika není zisk.____
Mluvím stále teoreticky, o vaší firmě nic nevím. -
polygon (neregistrovaný)
Asi je nejlepší hned na začátku si rozmyslet za co chcete aby se platilo. Z pozice zákazníka i dodavatele. Jestli za dílo, nebo za hodiny.
Z pozice zákazníka pokud je obvykle vaší motivací obdržet hotový software, ale může být výhodné "uvázat" si pracovní sílu dodavatele pro adhoc úpravy když vlasně pořádně nevím co chci.
Z pozice dodavatele je obvykle výhodné dodat software a svou marži ovlivňovat interně řízením odpracovaných hodin (kvalitou pracovní síly), ale pokud nejsem schopen řídit firmu a motivovat lidi, může být výhodné "uvázat" svou pracovní sílu odběrateli a zajistit si pevný příjem.Nechci soudit, ShopSys ani nejí zákazníky neznám, ale nemůže mít popisovaný neúspěch příčinu v souběhu těchto zmr.ehm jevů, tedy jakési neochoty podnikat v podnikání?
ČLÁNKY DO MAILU