Spec Driven Development üzleti szemmel
Hogy az AI ne találgasson, és az üzleti kontextus ne vesszen el
Az AI ma már gyorsan tud szöveget írni, ötleteket rendszerezni, képernyőterveket javasolni és fejlesztői munkát támogatni. A sebesség önmagában azonban nem garancia arra, hogy a jó dolog készül el.
A Spec Driven Development, magyarul specifikációra épülő fejlesztés, egyszerű üzleti elvre épül:
Mielőtt az AI vagy a fejlesztőcsapat megoldást készít, rögzítjük, milyen üzleti célt kell szolgálnia.
Így nem egy homályos kérésből indul a munka, hanem közös, ellenőrizhető szándékból.
Miért üzleti kérdés?
Egy vállalkozásban a legtöbb digitális fejlesztés nem technológiai öncél. Valamilyen döntést gyorsít, ügyfélélményt javít, belső folyamatot egyszerűsít, hibát csökkent vagy új bevételi lehetőséget nyit.
Ha a feladat nincs pontosan megfogalmazva, az AI és a fejlesztőcsapat is feltételezésekből dolgozik. Lehet, hogy a végeredmény látványos. Lehet, hogy működik is. Ettől még nem biztos, hogy az üzleti problémát oldja meg.
A specifikáció itt nem vastag dokumentációt jelent, hanem döntési keretet. Mi a cél? Kinek segít? Milyen folyamatba illeszkedik? Mi számít sikernek? Mit nem szabad elrontani? Ezek nélkül az AI gyorsan épít, de könnyen rossz irányba.
A specifikáció üzleti memória
A kész rendszerből sok minden kiolvasható, de a legfontosabb kérdés gyakran rejtve marad: miért pont így döntöttünk? Egy árképzési kivétel, egy jóváhagyási lépés vagy egy ügyfélnek tett ígéret kívülről nézve könnyen tűnhet felesleges bonyolításnak.
Ha a döntések háttere csak beszélgetésekben, e-mailekben vagy valakinek a fejében él, akkor minden új változtatásnál újra magyarázni kell. Ha ez a kontextus eltűnik, a következő csapat könnyen "egyszerűsít" egy olyan szabályt, amely valójában üzleti kockázatot kezelt.
Egy jó specifikáció ezért üzleti memóriaként működik. Rögzíti:
- milyen üzleti problémát oldunk meg
- kinek a munkáját, döntését vagy ügyfélélményét javítja
- milyen meglévő folyamatokhoz kell igazodni
- milyen kivételek, korlátok és nem célok vannak
- mi alapján mondjuk ki, hogy a munka kész
Ettől dolgozik pontosabban az AI
Az AI nem ismeri magától a cég múltját, ügyfélígéreteit, árazását, belső kivételeit vagy azt, hogy egy régi döntés milyen üzleti kompromisszum miatt született. Ha ezek nincsenek leírva, mintákból és valószínűségekből próbál következtetni.
Ha viszont megkapja a célt, a korlátokat és a döntési hátteret, sokkal kevesebbet kell találgatnia. Jobban tud kérdezni, pontosabb javaslatot ad, és könnyebb ellenőrizni, hogy a megoldás valóban azt szolgálja-e, amire az üzletnek szüksége van.
Ez a gyakorlatban nem azt jelenti, hogy az üzletembernek technikai dokumentumokat kell írnia. A jó kiindulópont üzleti nyelvű: helyzet, cél, érintettek, korlátok, elfogadási feltételek. A technikai részleteket ezután már a fejlesztőcsapat bontja le.
Átadáskor ez számít igazán
Egy fejlesztés átadása sokszor nem azért nehéz, mert a fájlok hiányoznak. A gond az, hogy a döntések háttere nem megy át. Az új csapat látja, mi készült el, de nem mindig látja, miért pont így.
Specifikációval az átadás nem nulláról indul. Az új csapat megkapja a rendszer üzleti térképét: milyen ígéreteket kell megőrizni, hol vannak érzékeny pontok, melyik szabály védi az ügyfélélményt, és melyik döntés kapcsolódik bevételhez, megfelelőséghez vagy működési kockázathoz.
Ez különösen fontos, ha több beszállító, belső csapat vagy későbbi fejlesztő dolgozik ugyanazon a terméken. A munka nemcsak befejezhetőbb, hanem folytathatóbb lesz. Nem a kódból kell visszafejteni az üzleti logikát, mert a kontextus külön is megmarad.
Nem kell túlbonyolítani
A specifikációra épülő fejlesztés nem újabb bürokrácia. Nem attól lesz jó, hogy hosszú, hanem attól, hogy a megfelelő döntéseket rögzíti.
Egy kisebb változtatáshoz elég lehet néhány bekezdés: mi változik, miért fontos, milyen esetekre kell figyelni, és honnan tudjuk, hogy kész. Egy nagyobb fejlesztésnél több részlet kellhet, de ott is az a cél, hogy mindenki ugyanazt értse a munka alatt.
A vezetői szempont: ne azt kérdezzük, mennyi dokumentáció készült. Azt kérdezzük, hogy a döntések, korlátok és elvárások elég világosak-e ahhoz, hogy egy másik csapat is biztonságosan folytassa a munkát.
Mikor éri meg?
Nem minden munkához kell formális specifikáció. Egy gyors belső próbához vagy egyszer használatos segédeszközhöz elég lehet egy jó beszélgetés és egy világos feladatleírás.
Akkor térül meg igazán, amikor a rendszer hosszabb ideig él, több ember dolgozik rajta, ügyfelek támaszkodnak rá, vagy az üzleti szabályok nem maguktól értetődők. Ilyenkor a legdrágább hiba nem feltétlenül a rossz kód, hanem az elveszett kontextus.
A specifikáció ilyenkor csökkenti az átadás kockázatát, gyorsítja az új csapat betanulását, és segít abban, hogy az AI ne csak gyorsan, hanem a cég valós üzleti logikájához igazodva dolgozzon.
A lényeg
Az AI akkor hasznos üzleti eszköz, ha pontos irányt kap. Ha homályos a cél, gyorsabban készülhet el a rossz megoldás. Ha világos a cél, a korlát és a siker feltétele, akkor az AI és a fejlesztőcsapat is jobb döntéseket hoz.
A Spec Driven Development ezért nem fejlesztői divat. Üzleti kontrollmechanizmus: segít kimondani, mit akarunk elérni, miért fontos, és mit kell megőrizni akkor is, ha később másik csapat veszi át a munkát.
A kód megmutatja, hogyan működik a rendszer. A specifikáció megőrzi, miért így működik. Átadáskor ez a különbség dönti el, hogy a következő csapat folytatni tudja-e a munkát, vagy újra fel kell találnia a döntéseket.