Joel a szoftverről szoftvermenedzsment egyszerűen

Joel lapja

Gerilla magyar fordítások

Hivatalos fordítások

A jéghegy titok, leleplezve

Írta: Joel Spolsky (2002. február 13.)
Fordította: Plesz Gábor
Lektorálta: Tóth József
Az eredeti cikk

„Fogalmam sincs, mi a baj a fejlesztőcsapatommal” –, gondolja az elnök-vezérigazgató. – „Olyan jól mentek a dolgok, amikor elindult a projekt. Az első néhány héten a csapat őrülten beindult, és összehoztak egy nagyszerű prototípust. De azóta lelassultak, mint a csigák. Egyszerűen már nem hajtanak olyan keményen”. Kiválasztja Callaway Titanium Driver golfütőjét (Callaway Titanium Driver: A golfütők egy olyan típusa, ami annyira jó, hogy már nem engedélyezett a golfversenyeken), és elküldi az inast egy jéghideg limonádéért. „Talán ha a lógósok közül kirúgnék párat, az ismét feltüzelné a többit.”

Közben, természetesen a fejlesztőcsapatnak eszébe sem jut, hogy bármi is rossz lenne. Ellenkezőleg, semmi gond. Terv szerint haladnak.

Ne engedd, hogy ez veled is megtörténjen! Megosztok veled egy kis titkot a technikai részletekkel nem túlságosan tisztában lévő menedzserekről, ami milliószor könnyebbé teszi az életedet. Igazán egyszerű. Ha tudod a titkot, nem lesz több problémád az ilyen főnökökkel (hacsak nem teszel megjegyzést a golfütőjük hendikepjére).

Az világos, hogy a programozók és az MBA-t végzettek nem ugyanazon a nyelven beszélnek. Sokat gondolkodtam, vajon mi lehet a kommunikációs probléma a szoftvermenedzsmentben, mivel az eléggé világos, hogy a siker és a hatalom azoknak a meglehetősen ritka személyeknek az ölébe hullik, akik tudják, hogyan kell tolmácsolni a programozóul és az mbául beszélők között.

Amikor én megtettem első lépéseimet a szoftveriparban, a legtöbb szoftver, amin dolgoztam, „spekulatív” volt. Ez azt jelenti, hogy nem adott vevők számára készült – abban a reményben készült, hogy sok száz millióan megveszik majd. De sok szoftverfejlesztőnek nem jut ilyen luxus. Talán csak egy ügyfél számára készít szoftvert tanácsadóként, vagy házi programozóként valami bonyolult céges könyvelési akármin dolgozik (megjegyzem, a házi programozók élete számomra fölöttébb titokzatos).

Megfigyelted már az ilyen egyedi megbízások alkalmával, hogy a csúszások, hibák és egyáltalán, a nyomorult légkör egyetlen kizárólagos okozója az, hogy „az a (jó erős jelzőt szúrj be ide) ügyfél nem tudta, hogy mit akar?”

Itt van ugyanannak a problémának három változata:

• „Ez a nyomi ügyfél állandóan meggondolja magát. Először kliens/szerver megoldást akart. Aztán valami repülőúton olvasott valamit a Malév magazinban, és úgy döntött, XML-t akar. Most meg éppen újraírjuk a dolgot, hogy Lego Mindstorm robotok flottáit használja”.
• „De hát pontosan azt készítettük el, amit akartak. A szerződés minden apró részletre kitért. Pontosan azt szállítottuk, amit a szerződés tartalmaz. De amikor leszállítottuk, a világ összeomlott”.
• „A kretén üzletkötőnk fix árért vállalta el a specifikálatlan munkát, és a vevő ügyvédei persze elég okosak voltak hozzá, hogy egy olyan szakaszt is tegyenek a szerződésbe, hogy csak a „vevő általi átvételkor” kell fizetniük. Így aztán rá kellett állítanunk a projektjükre 9 fejlesztőt két évig, és a végén kaptunk 800 dollárt”.

Ha van olyan dolog, amit mindenképpen a kezdő tanácsadók fejébe kell verni, óriási erővel, dobhártyaszaggató energiával, akkor az ez: A vevő nem tudja, hogy mit akar! Ne várd, hogy tudja, hogy mit akar! Ez egyszerűen soha nem fog megtörténni. Gyógyulj ki ebből.

Ellenkezőleg, tételezd fel, hogy neked kell létrehozni a terméket ha törik, ha szakad, és a vevőnek kell, hogy tetsszen, de meg is lepődhet egy kicsit. TE nézel utána a dolgoknak. NEKED kell előállnod valamivel, ami a vevő által elfogadható módon megoldja a problémát.

Egy pillanatra gondold magad a helyükbe. Képzeld el, hogy éppen most adtad el a cégedet a Yahoo!-nak 100.000.000 dollárért, és úgy döntesz, hogy itt az idő felújítani a konyhádat. Felveszel egy profi tervezőt azzal a feladattal, hogy „legyen olyan szuper mint a Horváth Rozi konyhája”. Fogalmad sincs, hogyan kéne ezt elérni. Nem akarod tudni, hogy mi az a Viking tűzhely vagy a Subzero hűtőszekrény – ezek a szavak nincsenek a szótáradban. Azt akarod, hogy a belsőépítész csináljon valami tutit, ezért vetted fel.

Az Extrém Programozást végző emberek azt mondják, hogy a megoldás az, ha a vevőt behozzák a szobába, és bevonják a tervezés minden lépésébe, mint a fejlesztő csapat tagját. Ez, azt gondolom, túl „extrém”. Ez olyan, mintha a belsőépítész mindent megmutatna nekem, hogy hol miért mit tervez a konyhába, és minden apró részletről megkérdezne. Fárasztó, és ha belsőépítész akartam volna lenni, akkor belsőépítésznek mentem volna.

Meg aztán te sem akarod igazán, hogy a vevő a csapatod tagja legyen, nem igaz? Az ügyféljelölt olyan, mintha a leggyengébb alkalmazottat a könyvelésről átküldenék, hogy dolgozzon együtt a programozóval, mivel ő az aki a leglassabban dolgozik, és észre sem veszik a hiányát. Így aztán minden tervezési idődet arra fordítod, hogy a dolgokat egyszerű szavakkal, szótagolva megpróbáld elmondani.

Ne felejtsd el, hogy nem tudja, mit akar. Tervezd meg magad, az alapján, amit a témából megértettél. Semmi gond, ha szükséged van némi tanulásra a témában, vagy el kell beszélgetned egy szakértővel, de a szoftver tervezése a Te feladatod. És ha a témában kiszabott házifeladatodat jól megcsinálod, és jó felhasználói felületet készítesz a programnak, akkor a vevő elégedett lesz.

Most, ahogy megígértem, elmondom a titkot a tolmácsolásról a szoftvered vevőinek (vagy a nem műszaki főnökök) nyelve és a programozók nyelve között.

Tudod, hogy egy jéghegy 90%-a víz alatt van? Nos, a szoftver erre nagyon hasonlít – van egy csinos felhasználói felület, ami a munka kb 10%-a, és aztán a 90% programozói munka alatta. És ha azt is hozzászámoljuk, hogy a munkaidőd felét elviszi a hibák kijavítása, a felhasználói felület elkészítése csak a munka 5%-át jelenti. És ha a felhasználói felület látható részére szorítkozunk, amit PowerPointban is meg tudsz nézni, akkor végülis alig 1%-ról beszélünk.

Ez még nem a titok. A titok az, hogy azok az emberek, akik nem programoznak, azok erről semmit sem sejtenek.

Létezik néhány nagyon-nagyon fontos következménye a Jéghegy Titoknak.

Első fontos következmény. Ha egy 90%-ban rossz képernyőt mutatsz egy nem-programozó embernek, azt fogja gondolni, hogy a program is 90%-ban rossz.

Ezt még tanácsadóként tanultam, amikor egy ügyfél vezetősége számára egy nagy web-alapú projekt demóját készítettem. A kód majdnem 100%-ban elkészült. Már csak a grafikus tervezőre vártunk, hogy kiválassza a betűtípusokat és színeket, és megrajzolja a vagány 3 dimenziós gombokat. Általában mi csak egyszerűen fekete-fehérben az alap betűtípusokkal dolgoztunk, egy csomó kihasználatlan hely volt még a képernyőn, és egyáltalán nem nézett ki valami nagyon jól. De a funkcionalitás 100%-a elkészült és maga a dolog elképesztő dolgokra volt képes.

Mi történt a demó alatt? Az ügyfél a demó teljes idejét a program grafikai megjelenésére pazarolta. Még csak nem is a felhasználói felületről beszéltünk. Csak a grafikai kinézetre. „Hát ez nem valami elegáns”, – állapította meg az ő projektfelelősük. Ez volt minden, amire gondolni tudtak. Egyszerűen nem tudtuk megmutatni magukat a funkciókat. Természetesen a grafikai tervek megvalósítása össz-vissz egy napig ha tartott. Olyan volt, mintha személyünkben festőket szerződtettek volna.

Második fontos következmény. Ha egy nem-programozónak mutatsz egy olyan képernyőt, ahol a felhasználói felület 100%-ban gyönyörű, azt fogja gondolni, hogy a program majdnem kész.

Akik nem programozók, azok csak nézik a képernyőt és pixeleket látnak. És ha a pixelek látszólag egy programmá állnak össze, ami mintha csinálna is valamit, akkor azt gondolják „ó, remek, és mennyi még megcsinálni, hogy valóban is működjék?”

Az ebben rejlő nagy kockázat az, hogy ha először a felhasználói felületet tákolod össze, hogy minél előbb meg tudd mutatni a felhasználónak, akkor mindenki azt fogja gondolni, hogy már minden majdnem kész. És ha a következő évet azzal töltöd, hogy a „burkolat alatt” dolgozol, akkor senki sem fogja igazán látni, mit is csinálsz, ezért mindenki azt fogja gondolni, hogy semmit.

Harmadik fontos következmény. Egy szuper, fényezett kinézetű, de kb négy oldalas dotkom honlap magasabb értékelést fog kapni, mint az a jól használható webhely, ami 3700 év adatait tartalmazza és a háttérszíne szürke.

Ó, egy pillanat. A dotkomok már sehol semmit nem érnek. Mindegy.

Negyedik fontos következmény. Ha a politikai nyomást amit a nem műszaki főnökök vagy vevők gyakorolnak rád, „ki akarod zárni” a projektből, adj nekik néhány grafikai tervet, hadd válogassanak.

Néhány dolognak változtasd meg a helyét, változtasd meg a kinézetet, betűtípust, mozgasd a logót és növeld vagy csökkentsd a méretét. Add meg nekik a fontosság érzetét a nem lényegbevágó rúzs-a-csirkén dolgokkal, ezek színlelésével. Ezzel nem tudják tönkretenni az ütemtervedet. A jó belsőépítész állandóan anyagokat, mintákat, példákat visz magával az ügyfeléhez, hogy válasszon. De soha sem vitatkozik arról, hova kerüljön a mosogatógép. A mosogató mellé kerül, mindegy mit akar az ügyfél. Nincs értelme időt áldozni eldönteni, hogy hova kerüljön a mosogatógép, a mosogató mellé kell kerülnie, akármi legyen is; hagyja hogy az ügyfél örömét lelje az olyan ártalmatlan dolgokban, mint hogy 200-szor megváltoztassa a véleményét, arról, hova kerüljön olasz márvány vagy mexikói csempe vagy norvég fa tőke a lépcsőfokokra.

Ötödik fontos következmény. Ha látvány kell, akkor az egyetlen dolog, ami számít, az a képernyőképek. Csináld meg őket 100%-osan gyönyörűre.

Ne, egy pillanatra se gondold azt, hogy megúszod azzal hogy bárkit megkérsz, hogy képzelje el, milyen szuper lesz. Ne hidd, hogy eszükbe jut a funkcionalitás. Nem. Csak csinos pixeleket akarnak látni.

Steve Jobs jól tudja ezt. De még mennyire jól. A mérnökök az Apple-nél megtanulták azt, hogyan lehet csodálatos képernyőképeket csinálni, mint például az 1024x1024-es ikonok, még akkor is, amikor már mindenük odalett. És a Linux desktop tömeg megőrül a félig átlátszó xterm-ektől, amikből remek képernyőképeket lehet csinálni, de általában idegesítő őket használni. Minden alkalommal, ha a Gnome vagy a KDE egy új változatot jelent be, egyenesen megyek a képernyőképekhez és mondtam „ó, ezek lecserélték a Jupitert a Szaturnuszra. Király.” A többi nem számít.

Emlékszel az elnök-vezérigazgatóra a cikk elején? Boldogtalan volt, mert a csapata nagyszerű PowerPointokat mutatott neki az elején, – maketteket, ráadásul Photoshopban, még csak nem is VB-ben elkészítve. És most, hogy elkészült a felület, nem csinálnak semmit.

Mit tudsz ezzel kezdeni? Ha egyszer megérted a Jéghegy Titkot, egyszerű a továbblépés. Értsd meg, hogy minden demó, amit elsötétített szobában projektorral bemutatsz, kizárólag pixelekről szól. Ha tudod, csináld meg úgy a felhasználói felületet, hogy az el nem készült részek nézzenek úgy ki, mintha még nem lennének befejezve. Használj irka-firkákat ikonoknak az eszköztáron amíg mögéjük nem kerülnek a funkciók. Ha webes szolgáltatást készítesz, érdemes megfontolnod egész eszközök kihagyását a kezdőoldalról, amíg el nem készülnek. Ez lehetővé teszi az embereknek, hogy nyomonkövessék a kezdőoldalt, amíg 3 elérhető parancsról eljut 20 parancsig, ahogyan egyre több dolog elkészül.

Sokkal fontosabb, hogy biztos legyél benne, kézben tartod az emberek elképzeléseit az ütemtervről. Készíts részletes ütemtervet Excel formátumban. Minden héten küldj egy belső gratuláló levelet arról, hogyan sikerült 32%-ról 35%-ra eljutni, és minden a terv szerint halad a december 25-i átadáshoz. Biztosítsd, hogy a valósághű tények meggyőznek mindenkit arról, hogy a projekt a megfelelő sebeséggel megy előre. És ne engedd a főnököd a Titanium ütőt használni. Nem érdekel, mennyire akarod, hogy győzzön, de az USGA kitiltotta őket, és ez egyszerűen nem fair.

**USGA: United States Golf Association – Egyesült Államok Golfszövetsége, ő dönti el, hogy kinek milyen típusú golfütő használata engedélyezett