Minden alkalommal, amikor új ügyféllel kezdünk együttműködni, web- és mobilalkalmazás-fejlesztő cégünk két átfogó dokumentumot készít, amelyekből kiderül az ügyfél projektjének költségeivel kapcsolatos minden legfinomabb részlet.

Talán már olvasta, miért és hogyan készítünk durva becslést (ha nem, akkor ezt mindenképpen meg kell tennie). És most itt az ideje, hogy felfedje mindazt, amit mindig is tudni akart a részletes becslésekről a MindK-ban.

Mi az a részletes becslés?

A részletes becslés egy húsba vágó dokumentum, amely átfogó bontást ad a projekt költségeiről.

A teljes munkaterületet elemi részekre – jellemzőkre – bontja.

Minden egyes funkciót külön-külön becsülnek meg keresztfunkcionális csapataink.

Az egyes funkciók befejezéséhez szükséges idő összeadódik, és így kialakul az alkalmazás részletes költségvetése.

Detektív becslés vs. durva becslés

Ha azt szeretné, hogy árcédulát ragasszunk a velünk megosztott alapötletre, szívesen küldünk Önnek egy durva becslést. Ez csak általános képet adhat Önnek a projekt költségeiről.

A részletes becslés egy sokkal árnyaltabb és terjedelmesebb dokumentum.

A durva becslésben az alkalmazást hatalmas funkcionalitási blokkokra, úgynevezett epikákra osztjuk.

A részletes becslésekben egy lépéssel továbbmegyünk, és minden egyes eposzt funkciókra bontunk.

A részletes becslés megírása előtt össze kell gyűjtenünk és dokumentálnunk kell az összes követelményt, tisztáznunk kell az összes nyitott kérdést, és meg kell írnunk a specifikációt (abban az esetben, ha a projekthez fix áras megbízási modellt alkalmazunk).

Így előzetesen minden szükséges részletet megtudhatunk, és ennek eredményeként a legpontosabb becslést adhatjuk meg.

Ebben a szakaszban nem lehetnek feltételezések, csak állítások.

Detektív becslés vs. pontos becslés

Íme, miért.

Az igazán pontos becslések csak a Felfedezési fázis befejezése, a megoldás prototípusának elkészítése, a specifikáció megírása és a részletes munkaterület jóváhagyása után lehetségesek.

A fix áras projektek esetében csak a Felfedezési fázis befejezése után készítünk részletes becslést. Ezt a fázist általában külön projektként számlázzuk ki.

Az Agilis/Scrum projektek esetében más megközelítést alkalmazunk.

Ez a módszertan szerint a termékfejlesztés dinamikus és rendkívül rugalmas folyamat. Fő célja, hogy 2-4 hetente kész megoldást készítsen, és alkalmazkodjon a felhasználók visszajelzéseihez.

A teljes projektre vonatkozó végleges becslés készítése nem igazán illik ehhez a megközelítéshez.

A legtöbb esetben nem igazán lehet megjósolni, hogy az alkalmazás milyen formát fog ölteni hónapok és évek múlva. Ezért az agilis projekteknél inkább az úgynevezett Guesstimate-et használjuk.

Ez lehetővé teszi, hogy hozzávetőleges, de rendkívül részletes becsléseket készítsünk anélkül, hogy rengeteg időt pazarolnánk a Discovery fázisra.

Miből áll egy részletes becslés?

A részletes becslés a MindK-ban általában három részből áll: maga a becslés, a szoftverrel kapcsolatos költségek és a kockázatelemzés.

A becslés

Ez a rész tartalmazza a projekt költségeit funkcióról funkcióra lebontva.

A fix áras projekteknél csak az egyes funkciók pontos költségeit írjuk le, de az agilis projekteknél csak becslést tudunk adni.

Ez a rész csak azokat a funkciókat tartalmazza, amelyeket az ügyfeleink 100%-ban megerősítettek. Ha valamikor úgy döntenek, hogy hozzáadnak egy funkciót, akkor azt külön becsüljük meg, és frissítjük a dokumentumot.

Ha egy projekt összetett (pl. szükség van egy webes alkalmazásra, egy iOS /Android alkalmazásra, egy chatbotra stb. is), akkor minden egyes komponens külön-külön kerül becslésre.

Minden funkciót egy felhasználói történet formájában írunk le. Ez egy leegyszerűsített módja a funkcionalitás egy darabjának a felhasználó szemszögéből történő megjelenítésének.

Jellemzően így hangzik: Mint <szereplő>, <funkciót> akarok, hogy <előny> (pl. blogtulajdonosként szeretnék egy feliratkozási űrlapot, hogy feliratkozókat kaphassak az új blogbejegyzésekről szóló frissítésekhez.).

A felhasználói történetek rövidek, tömörek és rugalmasak. De ami a legfontosabb, hogy rendkívül könnyen érthetőek, még akkor is, ha teljesen kezdő vagy a szoftverfejlesztés világában.

A részletes becslés tartalmazza a költségek bontását minden munkatípusra:

• Üzleti elemzés;
• Tervezés;
• Markup (HTML);
• Elfejlesztés;
• Minőségbiztosítás;
• Projektirányítás (PM).

A PM költségei általában az eredmény 25%-át teszik ki. A pontos százalékos arány számos tényezőtől függ:

• Minél összetettebb egy projekt, annál több kommunikációt és irányítást igényel.
• Minél nagyobb a csapat, annál nagyobb kihívást jelent az irányítása, ami további PM-órákat eredményez.
• A harmadik féltől származó integrációk száma szintén befolyásolhatja az irányítási költségeket. Amellett, hogy ez egy újabb megvalósítandó (és kezelendő) funkció, a harmadik féltől származó API-k gyakran megkövetelik, hogy PM-jeink felvegyék a kapcsolatot a szolgáltatókkal.

A nagyvállalatokkal (nagy bankok, nagyvállalatok stb.) mint API-szolgáltatókkal való kommunikáció például igazi nyűg lehet. A magas szintű bürokrácia és a merev hierarchikus struktúrák egy ilyen egyszerű feladatot gyötrelmes munkává változtathatnak.

Egy külön alfejezetben felsoroljuk az összes szabványos funkciót.

A mobil- és webfejlesztéssel kapcsolatos tapasztalataink azt mutatják, hogy bizonyos funkciók és feladatok minden alkalmazásban jelen vannak. Ezek közé tartozhat például a szerverek és a fejlesztőkörnyezet beállítása, a projektmenedzsment, a Google Play kiadás (Android-alkalmazások esetében) és így tovább.

A harmadik féltől származó megoldások költségei

A szoftverfejlesztés során a kerék újbóli feltalálása költséges és gyakran értelmetlen vállalkozás. Szerencsére az informatika világában minden szabványos feladatra vagy gyakori problémára van legalább egy kész megoldás. Néha ezek ingyenesek, de a legtöbb esetben fizetni kell értük.

Ha egy projekt befejezéséhez valamilyen harmadik féltől származó szoftvert, szolgáltatást vagy könyvtárat kell vásárolnunk, akkor ezek költségét megbecsüljük, és a dokumentumban feltüntetjük az összeget.

Ha a projekt például támogatja az SMS-üzenetküldést, akkor fizetnünk kell egy SMS-átjáróért.

Ha a weboldal tervezése egy adott kész sablonon alapul, amelyet használni szeretne, akkor annak költségét is hozzáadjuk a becsléshez.

Vagy ha ügyfeleink azt szeretnék, hogy segítsünk nekik a tárhely biztosításában, akkor javasoljuk nekik a legjobb lehetőségeket (például Amazon Web Services, DigitalOcean vagy más bevált szolgáltatások). Így a tárhelyhez és a szerver karbantartásához kapcsolódó költségek ebben a részben jelennek meg.

Kockázatelemzés

Minden projekt magában hordoz bizonyos kockázatokat. A projektmenedzser feladata ezek azonosítása és a kezelésükhöz szükséges stratégiák kidolgozása.

A meghatározott összeget csak akkor kell kifizetnie, ha egy adott kockázat valós problémává válik. Ellenkező esetben a pénzt megtartja.

Ezek a becslések aztán biztosítékként szolgálnak számunkra a projekt fejlesztését fenyegető sokféle veszély ellen.

Itt vannak példák a termékfejlesztés során előforduló kockázati kategóriákra:

• minőség/technikai/teljesítmény (i. m.pl. új vagy kivételesen összetett technológia alkalmazása, technológia módosítása, lehetetlen teljesítménycélok);
• Projektmenedzsment (pl. a pénzeszközök és az idő hibás elosztása, elégtelen projekttervezés);
• Organizációs (pl. a költség-, idő- és terjedelmi célok közötti összhang hiánya, rossz rangsorolás, szabálytalan háttér);
• külső (pl. jogszabályi változások, problémák a beszállítókkal és alvállalkozókkal, klíma).

A kockázatok azonosítása után a PM rangsorolja azokat, és kockázatelemzést végez.

A célja, hogy kiderítse az egyes kockázatok valószínűségét (azaz megvalósulásának esélyét) és hatását (megvalósulásának következményeit).

Egy példa?

Amint már említettem, az API-szolgáltatók lassan tudnak reagálni. Elhalogathatják a szükséges dokumentáció elküldését, vagy alulmúlható támogatást nyújthatnak. Ez egy valós kockázat, amire előre figyelmeztetni kell. Ezért elhelyezzük a kockázatok fejezetben, és egyúttal hatékony kockázatkezelési stratégiát dolgozunk ki a fenyegetés valószínűségének és hatásának minimalizálására.”

Befejezés

Most már tudja, mire számíthat a részletes becsléstől a MindK-ban. A dokumentum kimerítő választ ad a projekt árára vonatkozó kérdésre, és segít a költségvetés elkészítésében is. Végül pedig világos képet fog nyújtani arról, hogy mennyiért fog fizetni.

Van még valami, amit elmondhatok Önnek a MindK-ban található részletes becslésekről? Csak írjon egy sort, és részletes választ adok!