Miért tudunk fix áron TYPO3-frissítéseket kínálni

Aligha van olyan téma, amely az ügynökségekkel folytatott első beszélgetésekben gyakrabban kerülne szóba, mint a projekt árazása.

Szinte mindenki tapasztalt már olyan projekteket, amelyek eredetileg áttekinthetőnek tűntek, a megvalósítás során azonban a vártnál jóval összetettebbé váltak. A régi extensionök másként viselkednek, mint ahogy a dokumentáció állítja, az egyedi módosítások mélyen belenyúlnak a TYPO3 magjába, vagy a frissítés közben derül ki, hogy egy meghatározó üzleti folyamat kizárólag egy alig dokumentált bővítményben valósult meg.

Minél több ilyen tapasztalatot gyűjt össze az ember, annál érthetőbbnek tűnik a következtetés:

„Egy nagyobb TYPO3-frissítést valójában nem lehet komolyan fix áron kínálni."

Jól megértjük ezt a nézőpontot. Néhány évvel ezelőtt valószínűleg mi is hasonlóan érveltünk volna. Ma már némileg árnyaltabban látjuk az összefüggést.

Nem azért, mert a frissítési projektek egyszerűbbé váltak volna, hanem mert ma jobban értjük, hogy egyáltalán miből fakad a bizonytalanság az ilyen projektekben.

A legnagyobb kockázati tényező ritkán maga a TYPO3

Amikor egy projektköltségvetés kicsúszik a kézből, gyakran azt feltételezik, hogy a frissítés nehezebb volt a vártnál. A mi tapasztalatunk más.

A meglepetések többsége már a projekt kezdete előtt is létezett. Csupán a fejlesztés során váltak láthatóvá. Ez döntő különbség.

Egy karbantartás nélkül maradt extension nem azért válik hirtelen problémássá, mert elkezdődött a frissítés. Egy örökölt architektúra nem a migráció során keletkezik. És egy tizenöt éves, PI-alapú extension sem válik egyik napról a másikra bonyolulttá.

Mindezek a dolgok már korábban is jelen voltak. A különbség pusztán abban áll, hogy mikor ismerik fel őket.

Ezért az elemzési fázist nem szervezési előkészületnek tekintjük. Az már a tulajdonképpeni engineering-folyamat lényegi része.

A jó becslések nem pusztán a tapasztalatból fakadnak

A tapasztalat természetesen segít. Több mint 150 TYPO3-frissítés után számos technikai mintázatot jóval gyorsabban felismerünk, mint néhány évvel ezelőtt. Tudjuk, mely extension-kombinációk okoznak rendszeresen problémákat, ismerjük a régebbi vállalati projektek tipikus architektúráit, és jó érzékünk van ahhoz, hogy egy rendszer mely területei érdemelnek különös figyelmet.

Mindezek ellenére szerintünk veszélyes lenne a jó becsléseket kizárólag a tapasztalatra építeni. A tapasztalat értékes, ám szubjektív marad.

Ezért igyekszünk minél több felismerést egy reprodukálható elemzési folyamatba átültetni:

• Mely extensionök vannak használatban?
• Ezek közül melyeket karbantartják aktívan?
• Mekkora az egyedi kód mennyisége?
• Milyen integrációk léteznek?
• Hogyan fejlődött a platform az elmúlt években?
• Mely területek hordozzák tapasztalatunk szerint a legnagyobb technikai kockázatot?

Minél több ilyen kérdésre lehet már a projekt kezdete előtt választ adni, annál kisebb lesz a tényleges bizonytalanság aránya.

Nem az a célunk, hogy minden kockázatot kizárjunk

Olykor az a benyomás alakul ki, hogy a fix ár automatikusan azt jelenti: a projekt teljes mértékben kiszámítható. Ez sem nem reális, sem nem őszinte volna.

Egy gondos elemzés után is maradnak nyitott kérdések. Talán létezik egy egyedi bővítmény, amelynek tényleges funkcionalitása csak a migráció során válik teljesen láthatóvá. Talán kiderül, hogy egy harmadik féltől származó extension az aktuális verziójában már nem rendelkezik fontos funkciókkal. Vagy egy eddig ismeretlen különleges eset bukkan fel a minőségbiztosítás során.

Az ilyen helyzeteket nem lehet teljesen elkerülni. Ezért nem az a célunk, hogy megszüntessük a bizonytalanságot. A célunk az, hogy a lehető legjobban láthatóvá tegyük.

Minél kisebb az ismeretlen terület, annál megbízhatóbbá válik minden árkalkuláció.

Miért gazdaságosabbak a folyamatok a hőstetteknél

Különösen az összetett projekteknél könnyen kialakul az az elképzelés, hogy a sikeres fejlesztők mindenekelőtt rendkívül jól oldják meg a problémákat. Ez igaz. Legalább ennyire fontos azonban az a képesség, hogy ne kelljen ugyanazokat a problémákat minden projektben újra megoldani.

Számunkra itt kezdődik az engineering:

• a belső frissítési ellenőrzőlistánk,
• a Legacy Updater,
• saját Rector-szabályaink,
• automatizált regressziós tesztek,
• deployment-szkriptek,
• a tudásbázisunk.

Ezen befektetések egyikét sem egyetlen projekthez fejlesztettük ki. Azért születtek meg, mert ugyanazokat a mintázatokat figyeltük meg újra és újra.

Minden új eszköz csökkenti a bizonytalanság egy kis részét. Önmagában ez a hatás gyakran látványtalannak tűnik. Sok projekten átívelve azonban átalakítja a teljes árkalkuláció alapját.

Miért függ össze a minőség és a gazdaságosság

Egy érdekes megfigyelés foglalkoztatott minket különösen az elmúlt években: sok vállalat a minőséget többletráfordításnak tekinti.

• több teszt,
• több dokumentáció,
• több review,
• több folyamat.

Rövid távon ez igaz. Hosszú távon azonban megváltozik az egész projekt gazdaságossága.

Ha a vizuális regressziós tesztek már a fejlesztés során automatikusan felismerik az eltéréseket, később jelentősen csökken a kézi tesztelési ráfordítás. Ha létezik egy reprodukálható deployment-folyamat, az élesítéskor jóval kevesebb meglepetés adódik. Ha a gyakori migrációkat automatizáljuk, nemcsak a fejlesztési ráfordítás csökken, hanem a hibák valószínűsége is.

Más szóval: a jó engineering nemcsak fejlesztési időt takarít meg, hanem egyúttal csökkenti a minőségbiztosítás költségeit is. Éppen ezt az összefüggést becsülik szerintünk gyakran alá.

Vannak projektek, amelyeket tudatosan nem kínálunk fix áron

Ez a szakasz talán meglepő. Mindezek ellenére nem minden frissítést kínálunk fix áron. Vannak helyzetek, amikor egészen tudatosan lebeszélünk róla:

• ha a platform lényegi részei hiányoznak,
• ha a telepítés nem futtatható,
• ha a forráskód vagy az adatbázis hiányos,
• vagy ha a tulajdonképpeni projekt terjedelmét még egyáltalán nem határozták meg.

Ilyen esetekben a fix ár nem erősség volna. Hanem spekuláció.

Nem hisszük, hogy egy jó ajánlat abból születik, hogy a lehető legtöbb kockázatot vállaljuk. Egy jó ajánlat akkor jön létre, amikor mindkét fél érti, mely kockázatok léteznek valóban, és melyeket értékeltek már tisztán.

Miért különösen érdekes ez az ügynökségek számára

Projektjeink közül sok ügynökségekkel együttműködve jön létre. Éppen itt figyeljük meg gyakran ugyanazt az érdekellentétet.

Egyfelől a végfelhasználók tervezési biztonságot szeretnének. A költségvetéseket korán jóvá kell hagyni. Másfelől az ügynökség nem akar olyan gazdasági kockázatot vállalni, amelyet nem tud felmérni.

Egy reprodukálható engineering-folyamat mindkét félnek segít. Nem helyettesíti a tapasztalatot, de csökkenti azoknak az ismeretlen tényezőknek a számát, amelyek megnehezítik a megalapozott árkalkulációt.

Éppen ezért nem értékesítési eszköznek tekintjük a fix árat. Számunkra sokkal inkább egy olyan engineering-folyamat eredménye, amely módszeresen csökkenti a bizonytalanságot.

Mit tanultunk ebből

Amikor ma visszatekintünk az első nagyobb frissítési projektjeinkre, feltűnik, mennyire megváltozott a projekttervezésről alkotott felfogásunk. Korábban azt hittük, hogy a jó becslés mindenekelőtt a tapasztalatból fakad.

Ma azt mondanánk: a jó becslés abból ered, hogy a lehető legkevesebbet kelljen becsülni. Minél több tudás áll rendelkezésre már a projekt kezdete előtt, annál megbízhatóbbá válik minden árkalkuláció.

Talán éppen ez a gondolat írja le az engineering és a gazdaságosság valódi összefüggését. Az engineering nem teszi egyszerűbbé a projekteket. Az engineering kiszámíthatóbbá teszi a projekteket.

És pontosan ezért tudunk ma számos TYPO3-frissítésre fix árat kínálni – nem azért, mert figyelmen kívül hagyjuk a kockázatokat, hanem mert megtanultuk őket jóval korábban láthatóvá tenni.