Joel on Software

Joel on Software   Joel, szoftverekről

 

További "Joel on Software" cikkek magyar nyelven

További "Joel on Software" cikkek angol nyelven

E-mail a szerzőnek (angol nyelven)

 

Keménytökű hibajavítás


Szerző: Joel Spolsky
Fordította: Krisztián Berta
Szerkesztette: Daniel Hegyi
2001. július 31.

A szoftverminőség, vagy éppen annak hiánya olyan dolog, ami miatt mindenki szeret zúgolódni. Most, hogy saját cégem van, eldöntöttem, hogy teszek valamit az ügy érdekében. Az elmúlt két hét folyamán minden mást félretettünk a Fog Creeknél, csak hogy szállítani tudjuk a FogBUGZ új alverzióját, azzal a céllal, hogy az összes ismert buggal leszámoljunk (kb. 30 volt).

Szoftverfejlesztőként hibát javítani jó. Igazam van? Nem igaz?

Nem!

A hibajavítás csak akkor fontos, ha a hibajavítás értéke túlszárnyalja a hibajavítás költségeit.

Ezt felmérni nehéz, de nem lehetetlen. Hadd mondjak egy példát: Tegyük fel, hogy gyárunkban mogyorókrémes-lekváros szendvicseket (Amerikában közkedvelt falat - a ford.) készítünk. Ez a gyár napi 100 000 szendvicset állít elő. Mostanában, néhány új íz bevezetése miatt (foghagymás mogyorókrém, erőspaprikás lekvár) a kereslet a szendvicseink iránt az egekig nőtt. A gyár a napi százezer szendviccsel gyakorlatilag teljesen kihasználja a gyártókapacitást, a kereslet azonban inkább ennek a duplája. De nem tudunk többet gyártani. És minden egyes szendvicsen 15 cent hasznunk van. Tehát napi 15 000 dollár hasznot elbukunk a kapacitáshiány miatt.

Egy új gyár építése túl sokba kerülne. Nincs elég tőkénk, és tartani lehet tőle, hogy a csípős/fokhagymás szendvics csak időszakos hóbort. De a napi 15 000 dollárt továbbra is elvesztjük.

Jó dolog is történt, felvettük Jasont. Jason 14 éves, programozó, aki beleásta magát a gyár számítógéprendszerébe és most kidolgozott egy módszert, amivel a duplájára gyorsítható a gyártósor. A megoldás: túlpörgetés, amiről a slashdoton olvashatott és a próbán működött.

Csak egy valami tart minket vissza attól, hogy élesbe bevessük. Van egy iciri-piciri kis hiba, ami miatt kb. óránként egy szendvics péppé zúzódik. Jason ki akarja javítani a hibát. Úgy gondolja, három nap elég a hiba kijavítására. Hagyjuk kijavítani, vagy helyezzük üzembe a hibás szoftvert?

Ha három nap múlva helyezzük üzembe a hibás szoftvert, az 45 000 dollár elmaradt haszonba kerül nekünk. Viszont megtakarítjuk a nyersanyagárát ...mondjuk... 72 darab szendvicsnek. (három nap alatt Jason mindenképpen kijavítja a hibát.) Nem tudom, más bolygókon mennyibe kerül 1-1 szendvics; a Földön bőven 625 dollár alatt van az ára.

Hol is tartottam? Ja, igen. Szóval néha nem éri meg a hibajavítás. Itt egy másik hiba, amit nem érdemes kijavítani: óriás fájl megnyitásánál összeomlik a rendszer, de csak egyetlen felhasználónál adódik a probléma, aki OS/2-t használ, nagy fájlokat viszont - mint tudjuk - egyáltalán nem. Hát akkor ne javítsuk ki! Több is veszett Mohácsnál. Hasonlóképpen nem aggódom már a 16 színű képernyőt használókért vagy azokért, akik 7 éve polcról telepített Windows 95-öt használnak, javítócsomagok vagy upgrade-ek  nélkül. Az ilyen emberek nem költenek sokat szoftverre, elhihetik nekem.

De általában érdemes kijavítani a hibákat. Még ha ártalmatlan hibák is, rongálják a cég és a termék hírnevét, aminek hosszú távon komoly hatása lesz a bevételeinkre. Nehéz kiköszörülni egy hibás termék miatt a hírnevünkön esett csorbát. A 0.1-es verzió kiadásához itt van néhány ötlet, hogy milyen hibákat javítsunk ki: olyanokat, amelyeknek a kijavítása gazdaságilag megalapozott.

Első lépés: Bizonyosodjunk meg a hibáról!

A FogBUGZ esetében két dolgot tehettünk. Egyrészt elkaptuk az összes hibát az ingyenes demószerverünkön, összeszedtük róluk, amit csak lehetett és az egészet elküldtük e-mailben a fejlesztőcsoportnak. Rengeteg hibát találtunk, hihetetlenül frankó volt. Pl. észrevettük, hogy egy csomó ember nem adott be dátumot a "Mikorra legyen javítva" (Fix For) képernyőn. Ekkor nem hibaüzenet jött, hanem összeomlott a rendszer. (Mivel web-alkalmazásról van szó, mindez egy darab gusztustalan IIS hiba formájában jött elő.) Hoppá!

Amikor a Junonál dolgoztam, még frankóbb rendszerrel gyűjtöttük a bugokat automatikusan. Installáltunk egy kezelőt, ami a TOOLHELP.DLL-t használta, úgyhogy amikor a Juno összedőlt, életben maradt addig, míg a vermet ki bírta pakolni egy logfájlba. A legközelebbi bejelentkezéskor aztán elküldte nekünk. A béták alatt begyűjtöttük ezeket a logokat, összehasonlítottuk az összeomlásokat, aztán bevittük őket a hibakövető adatbázisba. Így szó szerint hibák százait találtuk meg. Ha az embernek egymillió felhasználója van, hihetetlen dolgok összeomlanak, gyakran a kevés memória vagy a szutyok kompúterek miatt. (Packard Bell, dereng?) Ha ilyen is a kódunk:

int foo( object& r )
{
    r.Blah();
    return 1;
}

és csak akkor omolhat össze, ha az r referencia NULL, (ami teljesen lehetetlen, a C++ garantálja, hogy nem lehetnek NULL referenciák) - nem kell elhinni - de ha elég ideig rendesen gyűjtögetjük az milliónyi felhasználó verem-dumpjait, találhatunk összeomlásokat olyan helyeken, hogy az ember nem hisz a szemének. (És nem fogjuk kijavítani. Kozmikus sugárzás, haver. Új gép kell és esetleg most nem kéne telepíteni az összes frankó taskbar-bizgető shareware-t, amihez hozzáférünk. Nnna!)

A másik dolog, hogy minden techsupport-hívást hibaként kezelünk. Amikor fogadjuk a hívást, próbáljuk kitalálni, mit is kellett volna tenni, hogy megelőzzük azt. Például a régi FogBUGZ telepítő azt feltételezte, hogy az anonymousként fog futni. Ez az esetek 95%-ában jól is volt így, de a fennmaradó 5%-nak a terméktámogatási vonalunk felhívása lett a vége. Úgyhogy módosítottuk a telepítőt, hogy rákérdezzen a felhasználói jogosultságra.

Második lépés: Legyen gazdasági visszajelzésünk!

Nem kell, hogy tisztában legyünk mennyit kéne egy-egy bug kijavítására fordítani, de mindenképpen érdemes a techsupport "költségét" ráterhelni az üzleti egységre. A 90-es évek elején a Microsoft pénzügyi átszervezéseket hajtott végre, melyek során minden termelési egység fizette a hozzá irányuló techsupport hívások teljes költségét. A szervezeti egységek kezdtek figyelni a PSS (a Microsoft techsupportja) által kiadott top10-es hibalistára. Ahogy a fejlesztőcsapat odafigyelt ezekre, a terméktámogatási költségek zuhanni kezdtek.

Ez egy kissé ellentmond a legtöbb nagy cégnél bevett új trendnek, miszerint fizesse a techsupport osztály a saját működését. A Junó techsupporttól azt várták, hogy nullszaldós lesz az által, hogy a felhasználókra terhelik a terméktámogatást. Ha a bugok gazdasági terheit a felhasználókra hárítjuk, elvesztjük annak az - amúgy korlátozott - lehetőségét, hogy felmérjük a hibák által okozott kárt. (Ehelyett viszont dühös júzereket kapunk, akik haragszanak, hogy nekik kell fizetni a mi hibáinkért, aztán meg elmondják az ismerőseiknek, mi meg nem is tudjuk, mennyibe kerül ez nekünk. Azért a tisztesség megkívánja a Junóval szemben: a termék ingyenes volt, úgyhogy csak semmi nyüszögés!)

A fenti két probléma megoldásának egyik módja, hogy nem fizettetünk a hívásért, ha az a mi hibánk miatt történt. A Microsoft így tesz, ez nagyon kedves tőlük, én még sosem fizettem nekik. Ehelyett terheljük a 245 dollárt, vagy amennyibe egy ilyen incidens kerül, egyenesen a termék üzleti egységére. Ez teljesen felszívja a termékeladásból származó profitjukat (többszörösen is) és megfelelő gazdasági ösztönzőrendszert teremt. Erről eszembe jut az egyik oka annak, ami miatt a DOS-os játékkészítés szörnyű üzlet volt. Ahhoz, hogy jól nézzenek ki és gyorsan fussanak, általában spéci videovezérlők kellettek és egy szimpla support-hívás annyiba került, mint 20 eladott példány haszna, feltéve, hogy az Egghead és az Ingram árrése (számítástechnikai szaküzletek - a ford.) és az MTV reklámok eleve nem vittek el minden pénzt.

Harmadik lépés: Találjuk ki, mit ér meg nekünk, ha mindegyiket kijavítjuk!

A Fog Creek Software-nél - meglehetősen kis cég vagyunk (kivéve lelki szemeink előtt) - a fejlesztői csapat veszi fel a support-hívásokat. Ez kb. napi egy órát emészt fel, ami a konzultációs árainkkal számolva 75 000 dollár évente. Bíztam benne, hogy le tudjuk ezt szorítani napi negyed órára, ha kijavítjuk az összes ismert hibát.

Ezekkel a felületes értékekkel számolva a megtakarítás nettó jelenértéke nagyjából 150 000 dollár. Ez 62 napi munkára elég: ha meg lehet csinálni 62 napon belül, akkor megéri.

A FogBUGZ hasznos beépített becslőfunkciója segítségével kiszámoltuk, hogy az összes javítás 20 embernap lenne (2 ember 2 hétig), ami 48 000 dollár ráfordítás a százötvenezres megtakarítással szemben, ami nagyon jó megtérülésnek számít. (Figyeljük meg, hogy konzultációs díj helyett programozói fizetéssel is számolhatunk, akkor is a fenti 3:1 arányt kapjuk, mert úgyis kiesik az egyenletből)

És akkor még nem számoltam annak az értékét, hogy jobb lett a termékünk, de nézzük meg azt is. Júliusban 17 felhasználó 55-ször látta összeomlani a régi kódot. El lehet képzelni, hogy közülük legalább egy úgy dönt, nem veszi meg a FogBUGZ-ot, mert hibás volt a demó alatt (jóllehet nincs pontos statisztikám erről.) Bárhogy is, az elveszett üzlet miatt elmaradt haszon jelenértéke valahol 7000 és 100 000 dollár között van. (Ha elég komolyan vesszük a számítást, nem nehéz megkapni a pontos értéket).

Következő kérdés: egy kevésbé hibás programot adhatunk drágábban? Ez mind felértékeli a hibajavítást. Feltételezem, hogy szélsőséges esetekben a hibák mennyisége befolyásolja az árat, de nehezemre esne olyan példát felhoznom a kereskedelmi szoftverek világából, ahol valóban ez történt volna.

Ne verjetek meg!

Elkerülhetetlen, hogy némely emberek ilyesféle tanulmányok olvasgatása közben furcsa következtetésekre jutnak: pl. Joel szerint nem érdemes kijavítani a hibákat. Igazából azt hiszem, hogy a leggyakoribb hibák kijavítása tiszta nyereséget hoz. De előfordulhat, hogy ha a legapróbb hibák javítása helyett valami mást csinálunk, annak komolyabb pénzügyi haszna van. Ha dönthetünk, hogy egy OS/2-es fazon hibáját javítgatjuk, vagy egy új funkciót fejleszthetünk a programunkba, amivel eladhatjuk azt 20 000 példányban a General Electricnek, akkor az OS/2-es fazon bizony így járt. És ha elég ostobák vagyunk és továbbra is hiszünk az OS/2-es hiba kijavításának elsődlegességében, a versenytársaink valószínűleg okosabbak lesznek, mi meg tönkremegyünk.

Mindent összefoglalva: a szívem mélyén optimista vagyok és hiszem, hogy a magas minőségű termékek előállítása további, nehezen elérhető értékeket rejt magában. A dolgozóink büszkébbek lesznek. Egyre kevesebb ügyféltől kapunk majd vissza CD-t, amin látszik, hogy agyonmikrózták, majd baltával apró darabokra vágták. Jómagam túlzásba viszem a minőségi munka iránti igényt (valójában a FogBUGZ összes ismert hibáját kijavítottuk, nem csak a brutálisakat), ezt büszkén vállalom, és biztos vagyok benne, hogy a demószerver minden hibájának megoldása nyerő termékhez vezet.



A fordítás alapjául szolgáló angol cikk címe: Hard Assed Bug Fixin'  

Joel Spolsky a Fog Creek Software alapítója. A Fog Creek egy apró szoftvercég, székhelye New York City. Joel a Yale egyetemen végzett, majd programozóként és menedzserként dolgozott a Microsoftnál, a Viacomnál és a Junonál.


Az itt olvasható oldalak egyetlen személy véleményét tükrözik.
Minden itt megjelenő tartalom ©1999-2005 Joel Spolsky. Minden jog fenntartva.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky