A GDD létrejötte után, azaz mikor már minden előre látható és várható tennivaló a felszínre került, jöhet a kalkuláció.

A “work estimate“, vagy “munkaidő táblázat” gyakorlatilag a fejlesztéssel kapcsolatos összes teendőt nagyobb “milestone”-okra (mérföldkövekre), azokat pedig kisebb “task”-okra (feladatokra bont), és ez utóbbiakhoz egy számot rendel:
A feladat elvégzésére szánt várható munkaórák számát.

Ezek a számok már annyira pontosak, hogy összeadva őket, +/- 5%-ra meg lehet jósolni a leírtak költségét. Ilyenkor már csak a megrendelőn a sor, hogy eldöntse: belevág a projektbe, vagy sem.

Plusz kiadások

Bár a munkaidő táblázat már szinte mindent magába foglal, vannak érdekes jelenségek, amelyekről érdemes tudni.

Feature creep

Erről itt olvashatsz bővebben.

Igények természetes növekedése

Az igények ésszerű módon is növekedhetnek, nem csak idétlen formában lépnek fel, mint a feature creep esetében. Nyilván a cél egy minőségi termék, és miért ne lehetne minőségibb, ha a büdzsé engedi.

Nem számítható dolgok

Ahogy sakkban, úgy egy játék tervezésénél is minden egyes előre gondolt lépés hatványozva növeli a lehetőségek számát, aminek következtében nem lehetséges abszolút mindenre számítani.

Ugyan a taskok esetében sok meglepetés nem szokott lenni, de az előfordul, hogy a lefejlesztett játékverzió ébreszt rá egy ésszerűbb megoldásra. Vagy például fejlesztés közben egy jobb, élvezetesebb játékmechanikára bukkanunk.
Mivel a lehetőségek szó szerint végtelenek, mindenre – abszolút mindenre – senki sem képes előre számítani.

Vizuális minőségi ugrás

A kalkuláció a kezdetben felvázolt igények alapján készül el. Tehát egy mondjuk úgy, hogy pl egy bizonyos szintű látványt, hatást foglalna magába.

Bár az a jellemző, hogy a kapott látvány, vagy minőség magasabb az ügyfél által vártnál, a rendelkezésre álló lehetőségek miatt megnőhet a minőségi igény a tervezetthez képest, és gazdagabb vizuális, audiális világra lesz szükség. Legalábbis a megrendelő ezt érzi.
Ez általában már a projekt vége felé jelentkezik, ugyanis a “csiszolási” (“angolul: polishing”) folyamatok a legvégső feladatok (ha valamiért nem kellett előre venni a játékfejlesztés menete alatt).

A csiszolási munkálatokat pedig lehet egy feneketlen gödörnek tekinteni, ugyanis bármeddig el lehet menni vele.
Itt is nagyon fontos, hogy megtaláljuk a középmezsgyét, használjuk a 20/80-as szabályt, vagy valamilyen irányvonalat, hogy a költségeket igazolni tudja az elért eredmény.

Az itt felsorolt plusz kiadásoktól egyébként nem kell félni, teljes mértékben az ügyfél kezében a döntés, hogy mennyit szán a projektre.
Ha szigorúan tartjuk magunkat a kezdeti elképzeléshez, akkor a projekt költsége szinte pontosan annyi lesz, mint amennyit a táblázat mutat.

Élő követés

A táblázat ezt követően egy élő dokumentummá változik. Ide kerül minden, ami elvégzésre került, és az ügyfél “élőben” – legalábbis max egy nap késéssel – követheti a projekt haladását.
Minden nap végén beírom a végzett munkaórákat, ami a ténylegesen gép előtt, aktív programozással, vagy szerkesztéssel töltött időt jelenti. Ezt nem stopperel mérem, hanem egy szoftver fut a gépemen, amit másodpercre pontosan számolja az aktív időt, így nekem nem kell ezzel foglalkozni.

Az így kapott számok összege kerül majd kiszámlázásra a milestone végén, mikor az ügyfél kezébe kapja, kipróbálja a terméket jelen verziójában és elégedett vele.

A telefonos beszélgetések, email-váltások, az ágyban fekve gondolatban programozott algoritmusok, a hibajavítások, és a keretrendszer-fejlesztések nem kerülnek kiszámlázásra.
Hogy miért? Azért, mert korrektnek tartom a munkaóra áraimat a magam részére is, úgy gondolom jobbára fedezi fent említett nehezen beazonosítható, de ugyanúgy a projektre szánt órákat.

Összegzés

A munkaóra táblázat tehát meghatározza a rendelkezésre álló infók szerinti idő és így pénzbeli kiterjedését az adott projektnek.
Kizárja a nagyobb meglepetéseket, és megnyugvást biztosít mind a megbízónak, mind pedig a játékfejlesztőnek.