Hogyan zajlik egy egyedi szoftverfejlesztés?

Négy lépés következik, és mindegyik végén van valami, amit kézbe lehet venni: nem státuszriport, hanem eredmény.

1. 01

   Beszélgetés

   Egy óra arról a folyamatról, ami ma a legtöbb időt viszi el: ki mit csinál benne kézzel, hol áll meg, mikor derül ki róla, hogy hibás. Ebből az is kiderül, van-e egyáltalán rendszer-feladat mögötte. Elég gyakran nincs, és akkor ezt mondjuk meg, nem ajánlatot küldünk. Ezért a lépésért nem kérünk pénzt, és nem jár vele kötelezettség.

   a végén: egy mondat arról, mit érdemes megépíteni, vagy hogy nem érdemes

2. 02

   Közös átnézés a te anyagodon

   Két óra, percre bontott menetrenddel: negyed óra a mai folyamatról, háromnegyed óra tíz-tizenöt valódi levél közös átolvasása, fél óra a tipikus buktatókról, húsz perc időmérés és becslés, tíz perc döntés. Díjmentes, kötelezettség nélkül és nem bemutató: a becslés a te saját számaidból áll össze, nem a mieinkből. Ez a forma az e-mailben érkező megrendelések feldolgozására van kidolgozva, mert ott van mit átnézni; más feladatnál a második lépés részletei mások lehetnek, és ezt nem általánosítjuk.

   a végén: időmérés és megtakarítási becslés a saját számaiddal, és egy igen vagy nem arról, legyen-e pilot

3. 03

   Felmérés és írott specifikáció

   A meglévő rendszer és a folyamat feltérképezése. Itt derülnek ki azok a dolgok, amiktől egy becslés a kétszeresére nő: a nem dokumentált integráció, a folyamat közepén kézzel vezetett táblázat, a rendszer, amihez már nincs jelszó.

   a végén: írott specifikáció, fázisokra bontva, fázisonkénti árral

4. 04

   Kivitelezés fázisonként

   Nem egy nagy szállítás a végén, hanem működő darabok egymás után, mindegyik éles rendszerben.

   a végén: fázisonként egy működő rész, ami a napi munkában használható

Az első lépésért azért nem kérünk semmit, mert a kimenete lehet nemleges is. Van néhány visszatérő helyzet, amiben eleve nem minket érdemes választani. Azokat külön leírtuk.

Öt helyzet, amiben nem minket érdemes választani →

Működő részfunkciót, fázisonként: nem státuszriportot és nem bemutató környezetet.

Minden fázis végén van valami, ami éles rendszerben fut, és amit a napi munkában használni lehet. Ennek két következménye van. Az egyik, hogy a visszajelzés valódi használatból jön, nem elképzeltből: az derül ki, mi hiányzik abból, amit már fognak, nem az, hogy mi tetszik egy képernyőképen. A másik, hogy a projekt bármelyik fázishatárnál megállítható úgy, hogy az addigi eredmény működik.

Két külön dologról van szó, és ezeket nem mossuk össze: a kód ellenőrzése gépi, az eredmény átvétele emberi.

A munka párhuzamos szálakon fut, szálanként külön munkakönyvtárban és külön ágon, felső korláttal. Egyetlen szál eredménye sem kerül be automatikusan: előbb végig kell mennie egy ellenőrzés-soron. Fordul-e, lefutnak-e a tesztek, a megbeszélt hatókörön belül maradt-e a változás, van-e hozzá teszt, egyezik-e azzal, ami le van írva; webes munkánál végponti tesztek és a megjelenés képernyőképes összevetése is.

Ezek nagyobb része determinisztikus: egy futtatás kilépési kódja dönt, nem egy vélemény. Kettő közülük (a kódátnézés és a leírással való egyezés) modellel értékelt, és ezt kimondjuk, mert nem ugyanolyan erős bizonyíték. Bukásnál nem ember kezd nyomozni: gépi hibaleírás keletkezik, és a munka azzal indul újra, korlátozott újrapróbálkozási kerettel.

Szándékosan egyesével fésüljük össze a változásokat. Minden változás elé friss főág kerül, arra fut az integrációs ellenőrzés, és csak utána megy be. Ennek ára van a sebességben, haszna pedig az, hogy elkapja azt az esetet, amit külön-külön semmi nem fog el: két önmagában hibátlan szál együtt is tud törni. Egy változás pedig addig nincs kész, amíg a leírás is nem frissül vele: így lesz a következő kör bemenete a mostani munka eredménye.

Ami ezen túljutott, azt ember veszi át. Nem a kódsorokat olvassa el, hanem az eredményt próbálja ki: meg van-e oldva a feladat.

Ez az oldal is így készül. Minden módosításnál négy gépi ellenőrzés fut rá: hogy minden útvonalnak van-e helye az oldaltérképben, hogy nem maradt-e sehonnan nem hivatkozott komponens, hogy az ábrák színei olvashatók-e a háttéren, és hogy ugyanaz az állítás nem szerepel-e túl sok helyen. A kontrasztellenőrzés első futása két olyan értéket cáfolt meg, amit a saját tudásbázisunk hordozott. Azóta a mérés a leírásainkra is lefut, nem csak a kódra. Ez a munkarend a saját fejlesztési keretrendszerünkből származik, és ugyanaz a keretrendszer hajtja az ügyfélprojekteket is; hogy egy adott projekten pontosan melyik ellenőrzés futott le, projektenként ma nincs kimutatva.

Ugyanez a módszer egy lapon: szoftverfejlesztés specifikációból, AI agentekkel

Az élesítés nem végpont. A rendszer napi ritmusban változik tovább, és ami elkészül, arról az alkalmazáson belül van kiadási jegyzet, hogy aki használja, ne szóbeszédből tudja meg, mi változott. Az egyik leszállított rendszerünknél 2026. június 14. és augusztus 3. között mérve nem volt olyan hét, amikor kiesett volna az üzem.

A mérés is élesben folyik, nem demóban: a pontosságot valódi forgalom visszajátszásával mérjük, ahhoz viszonyítva, amit a megrendelő munkatársa ténylegesen jóváhagyott. A mért szám mellé mindig odaírjuk, mi a mérés alapja és mikor készült.

Egy órával. Arról beszélünk, ami ma kézzel megy, és a végén megmondjuk, van-e mögötte rendszer-feladat. Ha az derül ki, hogy nem éri meg, azt mondjuk meg. Az is válasz, és olcsóbb most, mint egy specifikáció után.

Beszéljünk róla →