Minden funkcióhoz írott spec – mert az elképzelés fejlesztés közben is változik

Milyen hibát előz meg ez

A forgatókönyv mindig ugyanaz. Egy hívásban megbeszélünk egy funkciót, mindenki bólogat, elindul a fejlesztés – aztán félúton kiderül, hogy az ügyfél egészen mást képzelt, mint mi, vagy közben ő maga is továbbgondolta az egészet. Ez senkinek nem a hibája: az alapítók akkor ismerik meg igazán a saját terméküket, amikor látják formát ölteni, és ez a felismerés valóban sokat ér. Csakhogy ha félkész kóddal találkozik, annak ára van: újra kell dolgozni, mindenki frusztrált, és mindkét oldalon ott marad a rossz érzés, hogy a másik „nem azt csinálja, amiben megegyeztünk”.

Megtanultuk, hogy ezt folyamatproblémaként kezeljük, és folyamattal is oldjuk meg – nem fegyelmi kérdésként, amiért valakit hibáztatni kellene. Ez lett az Invoice Guru-projekt egyik legfontosabb tanulsága, és ma már minden projektünkön így dolgozunk.

Hogyan néz ki nálunk egy spec

A „specifikáció” szóról a legtöbbeknek egy negyvenoldalas dokumentum jut eszébe, amit senki nem olvas el. A mieink szándékosan pont fordítva működnek: általában elférnek egy oldalon, és olyan hétköznapi nyelven íródnak, hogy az ügyfél tényleg meg tudja ítélni, jó-e, amit leírtunk:

• —Mit csinál a funkció – úgy leírva, ahogy a felhasználó tapasztalja, nem az implementáció felől
• —Mi az, ami kifejezetten nem része – a scope-ot ugyanis a határai jelölik ki
• —Mely állapotokra kell válasz: üres, betöltés alatt, hiba, offline, hiányzó engedély
• —A nyitott kérdések – még azelőtt feltéve, hogy egyetlen sor kód megszületne, nem utólag felfedezve
• —Az ügyfél jóváhagyása – egy mondatnyi egyetértés, nem ünnepélyes aláírás

Miért véd ez mindkét felet

Amikor egy elképzelés fejlesztés közben megváltozik – és meg fog –, a spec egészen más mederbe tereli a beszélgetést. Nem azon vitatkozunk, ki emlékszik jól a hívásra, hanem mindkét fél ugyanazt a dokumentumot nézi, és ahhoz képest beszéljük meg a módosítást: mibe kerül, mit tol el, most éri-e meg, vagy inkább a következő iterációban? Magát a változást szívesen fogadjuk – a spec csak azt teszi láthatóvá, hogy mi az ára, még mielőtt kifizetnénk.

Óradíjas együttműködésben ez egyben a méltányosság eszköze is. Az ügyfél látja, miben állapodtunk meg, mi készült el, és mi változott menet közben. Pontosan ez az az átláthatóság, amitől a time-and-materials elszámolás biztonságosnak érződik, nem pedig parttalannak.

Az AI-korszakban a spec csak még értékesebb lett

Van itt egy fordulat, amire nem számítottunk: az AI-alapú fejlesztés felértékelte az írott specet. Egy pontos spec szinte szó szerint felhasználható kiváló minőségű utasításként az AI-eszközök felé – minél tisztább a specifikáció, annál nagyobb részét lehet biztonságosan felgyorsítani az implementációnak. Azok a csapatok, amelyek megtanulták fegyelmezetten leírni, mit építenek, pontosan azok, akik a legjobb helyzetből adhatják át az építés egy részét az AI-nak.

Az egyoldalas spec tehát sosem volt bürokrácia. A legolcsóbb dokumentum az egész szoftverfejlesztésben: az, amelyik még akkor elkapja a félreértéseket, amikor azok csak szavak.