Az első kérdés a gazda
Mielőtt egy prototípusból éles rendszer lesz, négy kérdést teszek fel. Ki lesz a gazdája két év múlva, ha a mostani készítője már máshol dolgozik? Mi történik a folyamattal, ha holnap reggel leáll, és mennyi idő alatt lehet visszaállni a régi módszerre? Milyen adat megy át rajta, és ki fér hozzá ma, a tervezett hozzáférésen túl? Mennyi a belső órák valós ára három évre vetítve?
Ha az első kérdésre nincs név, a többit nem is nézem. Tapasztalatom szerint ez az egy kérdés a belső appok nagyjából harmadát visszaküldi prototípus állapotba, és ez így van rendjén.
A busz faktor
A szoftverfejlesztésben busz faktornak hívják azt a számot, ahány ember kiesése után egy projekt megáll. Avelino és társai 2016-ban 133 ismert nyílt forráskódú projektet vizsgáltak meg a GitHubon, és 65 százalékuknál ez a szám legfeljebb kettő volt. Ezek a projektek nyilvánosak, sok szem látja őket, mégis egy vagy két emberen múlnak.
Egy belső app busz faktora szinte mindig egy. Pécsett egy magánklinikán az időpontokra emlékeztető üzeneteket küldő appot a recepció vezetője építette, és amikor hosszabb betegszabadságra ment, kiderült, hogy az üzenetek az ő személyes fiókjáról mentek ki. Három hétig senki nem tudta újraindítani, és ezalatt érezhetően több páciens maradt el.
Átadás nélkül
- A kulcsok a készítő gépén vannak
- A logika a fejében él
- A hibákat ő javítja, szóban jelezve
- Ha elmegy, az app vele megy
Átadással
- A kulcsok céges fiókhoz tartoznak
- Egy oldal leírás van róla
- Van egy második ember, aki ismeri
- A gazda és a karbantartó külön meg van nevezve
Mi kell ahhoz, hogy átadható legyen
Négy dolgot kérek minden belső apphoz, amire mások is támaszkodnak. Kell egy megnevezett üzleti gazda, aki a működéséért felel, és aki nem feltétlenül az informatikán dolgozik. Mellé egy technikai karbantartó, aki hozzá tud nyúlni, ha valami elromlik. Minden kapcsolathoz céges fiók és céges kulcs kell, személyes belépés helyett. Végül egy egyoldalas leírás arról, mit csinál, honnan veszi az adatot, hová ír, és mi a teendő, ha leáll.
A második ember nem luxus. Egy kis cégnél sem kell ehhez külön csapat, elég, ha a készítő mellett egy kolléga egyszer végigcsinálja vele a hibaelhárítást, és a leírásból egyedül is boldogul.
A függőségek is öregszenek
Egy AI segítségével épített app ritkán áll önmagában. Nyelvi modellre, adatbázis szolgáltatásra, tárhelyre és néhány külső programkönyvtárra épül, és ezek mind változnak. A modellszolgáltatók nyilvános menetrend szerint vezetik ki a régi modelleket, az Anthropic például legalább hatvan nappal előre jelzi egy modell kivezetését. Az értesítő levél a regisztráló címére megy, és ha az a kolléga már nincs a cégnél, egy hétfő reggel derül ki, hogy az app nem válaszol.
Ezért a gazda feladata az is, hogy tudja, mire épül az app, és egy listán vezesse. Egy AI rendszer nem egyszeri beruházás, hanem üzemeltetett eszköz, aminek karbantartási ciklusa van.
Források és további olvasnivaló
Avelino, G., Passos, L., Hora, A., Valente, M. T., A Novel Approach for Estimating Truck Factors, ICPC 2016. A négy kérdésről ebben a cikkemben, a modellek kivezetéséről és a függőségi leltárról A modell, amire építettél, nyugdíjba megy című írásomban, a belső felelős szerepéről itt írtam.
Workshop
AI Transformation Day
Egésznapos, vezetőknek szóló program. Feltérképezzük, hol tart a szervezet, mi az első reális lépés, és milyen belső feltételek szükségesek a sikerhez. A nap végén konkrét, priorizált cselekvési lista.
Érdekel a program →