Pay as you go vs. FTFP| Mňamka #216

V ideálním světě by se v daném termínu stihl realizovat dohodnutý rozsah práce za domluvenou cenu.

V praxi datových projektů se ale ideálu dosahuje obtížně. Je tedy třeba se dle konkrétního případu rozhodnout pro vhodný model řízení dodání projektu. Důležité je analyzovat velikost a dopady rizik, charakter projektu, očekávané výstupy a prostředí, ve kterém má projekt probíhat.

Pro začátek si modely dodání můžeme rozlišit na tradiční a agilní přístup. Tradiční přístup (níže zastoupený jako Fixed time Fixed price) vychází z toho, že již na samotném začátku projektu jsou dané všechny vrcholy trojúhelníku Rozsah - Cena - Termín. Agilní přístup pak (velmi zjednodušeně) přichází s tím, že zafixuje dva vrcholy trojúhelníku a třetí nechá ve volnosti k průběžným změnám. Například zafixujeme cenu s termínem a víme, že v termínu X za cenu Y bude hotovo to, co bude na projektu zrovna nejdůležitější. Více o agilnilně řízených projektech psal Patrik zde.

V BizzTreat používáme dva základní modely pro řízení projektů: Pay as you go a Fixed time Fixed price. Pojďme se podívat na jejich výhody a nevýhody:

Fixed time Fixed price

Model Fixed Time Fixed Price (FTFP) zafixuje cenu, termín i rozsah projektu. Obecně se tento model hodí na jednorázové projekty a skýtá několik úskalí, především pro stranu dodavatele.

FTFP bychom použili preferovaně v případech, kdy:

  • Firemní politika, procesy tvorby a schvalování rozpočtů si “nerozumí” s agilnějšími přístupy.
  • Je velmi důležité, aby nebyl překročený připravený rozpočet. V extrémních případech se může stát, že požadavek na nepřekročení rozpočtu má vyšší prioritu než samotné dodání funkčního projektu.
  • Charakter projektu neumožňuje pouze částečné nasazení, je potřebné, aby byl projekt nasazený jako kompletní.
  • Neočekáváme dlouhodobou spolupráci, ale pouze jednorázový ucelený (a časově ohraničený) úkol, např. potřebujeme přenést data ze systému A do systému B.

Model FTFP přináší zvýšené riziko na straně dodavatele v podobě překročení rozpočtu nebo kapacit. Při prvotní analýze často není možné odhalit veškeré podrobnosti datového prostředí objednatele. Dodavatel pravděpodobně riziko zohlední při plánování kapacit přirážkou k ceně ke kompenzaci rizika a pokrytí neočekávaných nákladů nad odhadnutý rámec.

Pro dodavatele je model FTFP naopak výhodný v případě, když se během realizace projektu ukáže, že úvodní odhad byl přestřelený, a projekt je možné realizovat za využití nižších zdrojů. Pro dodavatele to znamená, že dostane zaplaceno i za práci, kterou nakonec nebylo třeba odvést.

Pay as you go

Model Pay as you go bychom zařadili k těm agilnějším a s oblibou ho využíváme u dlouhodobějších projektů. Oběma stranám, dodavateli i objednateli, přináší flexibilitu ve směrování datových aktivit. Smluvně daná je zde obvykle pouze jednotková cena za práci datového detektiva, případně i časový rozsah odvedených prací (při větším odběru hodin a stabilitě odběru v čase se jednotková cena snižuje).

Mezi vhodné situace pro použití modelu Pay as you go patří:

  • Objednávající firma je zvyklá pracovat agilně. Umí průběžně vyhodnocovat datové potřeby jednotlivých zaměstnanců nebo oddělení a na základě toho stanovit priority rozvoje.
  • Na začátku práce není jasně definovaný rozsah práce a počítá se s jeho dalším průběžným upřesněním.
  • Objem rozsahu spolupráce se může v průběhu času měnit (tedy při počátku projektu existuje požadavek ze strany objednatele na průběžnou schopnost přizpůsobení rozsahu projektu, ať už z finančních, rozsahových či jiných důvodů).
  • Dlouhodobě nastavená spolupráce zahrnující datové aktivity ve více paralelně běžících či sériově uspořádaných projektech.

Mezi nevýhody modelu patří fakt, že se časový rozsah projektu může postupně stále více prodlužovat. V praxi je třeba na to průběžně myslet, sledovat rozsah odvedených prací a v případě, že by se situace začala stávat neúnosnou, domluvit se na přechodu na jiný model (např. fixně definovat množství hodin k dokončení tohoto projektu, kdy převis hodin již půjde na vrub dodavatele).

V modelu Pay as you go funguje většina projektů v BizzTreat. Zpravidla jednou týdně s klienty procházíme aktuální stav projektů a priority. Často se stává, že se priority na straně klienta dynamicky mění. Díky svobodnému modelu se těmto požadavkům můžeme přizpůsobit a dělat datové projekty tak, aby nám dávaly smysl.

Který model použít?

Model Fixed time Fixed price je vhodný pro jednorázové, kritické a jasně definované projekty. Agilnější model Pay as you go je vhodný pro dlouhodobou spolupráci v dynamicky se měnícím prostředí požadavků.

Máte k článku nějaké otázky nebo připomínky? Klidně mi napište, rád to s Vámi proberu :-)

Michal Donát
datový detektiv
LinkedIn

Základní pojmy v datovém modelování | Mňamka #457

Základní pojmy v datovém modelování | Mňamka #457

Co je to datový model? Jaký je rozdíl mezi konceptuálním a logickým modelem? A k čemu slouží proces tzv. normalizace? Bez datového modelování se dnes v BI obejdete už jen stěží, Kuba si o něm proto připravil krátkou minisérii, ve které si vše probereme od úplných základů. V prvním díle se seznámíme s nejdůležitějšími pojmy, které byste v této souvislosti měli znát, a na jednoduchém příkladu z oblasti sales si ukážeme, jak takový datový model vlastně vypadá. Tak pojďme na to!

MAQL II. - MAQL Reuse factů & Nesting metrik | Mňamka #454

MAQL II. - MAQL Reuse factů & Nesting metrik | Mňamka #454

Proč se vyplatí recyklovat metriky v MAQL? Máme tady pokračování naší krátké minisérie o dotazovacím jazyku MAQL od Péti. V minulém díle jsme si osvětlili základní rozdíl mezi SQL a MAQL a dnes se zaměříme na výhody metrik vytvořených pomocí MAQL a jejich recyklaci. Funguje to přitom podobně jako v případě klasické recyklace surovin. Pokud ji dělat nebudete, ušetříte si možná půl minutky práce, v budoucnu se vám to ale může velmi nepříjemně vrátit. Tak se na to pojďte podívat!

Šaty dělají kód aneb Proč je někdy lepší kebab než velbloud | Mňamka #441

Šaty dělají kód aneb Proč je někdy lepší kebab než velbloud | Mňamka #441

I špatný standard může být lepší než žádný standard. Bez toho totiž ve vašem kódu velmi snadno zavládne chaos. V praxi se např. často stává, že lidé halabala kombinují různé druhy uvozovek, míchají malá a velká písmena v pojmenování proměnných nebo se pro jistotu vůbec žádných jmenných konvencí nedrží. Ostatně, Tomáš už se o tom mnohokrát přesvědčil na vlastní pěst. Sepsal pro vás proto mňamku, ve které si připomeneme, proč byste přece jen nějaký standard při psaní kódu mít měli!