Az „I know" halála

Avagy: feedback az élet. Olyan nincs, hogy én tudom — tényleg nincs. Minden a programozásban visszajelzéseken alapszik. Maga az ügyfél véleménye is visszajelzés. Éppen ezért mindenről visszajelzés kell. Olyan nincs, hogy „én tudom...". A unit test egy feedback. A compiler is egy feedback.

„A technológiai dogmák ott kezdődnek, amikor a megoldás hamarabb megvan, mint a probléma megértése."

Ha azt gondoljuk valamiről, hogy tudjuk, és rögtön azt is tudjuk, hogyan kell megoldani, akkor legyen bennünk egy gyanú: tényleg tudom? Attól, hogy ismerek egy módszert, és az alkalmas az adott dolog megoldására, nem biztos, hogy az a legjobb módszer is. Természetesen itt is igaz a Pareto-elv: ha a jelenleg ismert vagy alkalmazott technológia megoldja a problémák 80%-át, akkor nem érdemes annak leváltásán dolgozni. Tényleg sokszor azt gondoljuk, hogy mindent tudunk, pedig szinte mindent kétségbe kell vonni. Ha feltesszük magunknak a kérdést, hogy jó ez, amit csinálunk, és igennel tudunk válaszolni, akkor biztosak lehetünk benne, hogy jó úton járunk.

Éppen ezért, mivel „nem tudunk semmit", mérni kell. A mérés eredménye is egy feedback. Monitorozni kell mindent: a rendszer sebességét, a felhasználók viselkedését, azt, hogy mely funkció milyen gyakran van használva. Az időket is mérni kell — azaz mi az, amire gyorsan lehet kattintani és gyorsan lehet vele végezni, és mi az, ami gondot okoz a felhasználónak. Mikor nyom cancelt! Azaz mikor csalódik. Ez felesleges munka, elveszett idő. Milyen hibaüzeneteket kap a rendszertől, mik a leggyakoribb hibaüzenetek. Hol nem egyértelmű a program. Mikre keres és mikre szűr a leggyakrabban. Milyen nézetnek kéne lenni alapból. Milyen mezőt keres? Megnyílik a detail dialóg, nem kattint, vagy tabot vált, de ott sem kattint, megy a következőre, és ott ír át valamit. Ez azt jelenti, hogy keresett egy mezőt, de nem találta meg elsőre — nem jó helyen van? Vagy nem logikus csoportban?

Amikor megtervezzük a rendszert, azt gondoljuk, tudjuk, mit csinálunk, de valójában csak egy idealizált elképzelés mentén megyünk, és ezt valósítjuk meg. Ezeknek a dolgoknak találkozni kell a realitással. A rendszer egy előfizetéses rendszer, nincs kényszerítő erő arra, hogy ne álljon tovább a felhasználó. A rendszernek egyértelműnek és világosnak kell lennie — egy dialóg, ami megjelenik, nem kelthet félelmet a felhasználóban: „Jó helyen járok?", „Ez az, amit akarok?". Ez egy picit kapcsolódik az előző témához: kell, hogy a felhasználó magabiztos legyen, neki a rendszer a munkaeszköze, ahogy nekünk a kód az. Természetesen a Pareto-elv itt is igaz: a felhasználók problémáiból az igazán kellemetlen gondokat a megoldások 20%-a okozza. Ezekre kell koncentrálni, és nem rögtön minden problémát megoldani. Ezeket is mérni kell. :) Ne gondoljuk, hogy tudjuk, mik a felhasználók gondjai — egyszerűen nem igaz, hogy „I know..."

A Continuous Delivery könyv 2002-es kutatása szerint a szoftverek funkcióinak 50%-a vagy soha nincs használva, vagy csak nagyon ritkán, vagy nulla, vagy nagyon kis valódi értéket tesz hozzá a termékhez és az ügyfél-elégedettséghez. 50% az annyira sok — ha ezt előre tudjuk, akkor havi két szabadságra mehettünk, és ugyanazt az értéket közvetítjük a vevő felé. A probléma a következő: az ügyfelek csak a megoldásért fizetnek, nekik az kell. De az ügyfelek NEM TUDJÁK, hogy mit akarnak. Fenntartással kell kezelni minden ügyfél igényt. A megoldást nekünk kell kitalálni, megalkotni és létrehozni — ettől kreatív a szakma, és ettől innovatív. Steve Jobs mondta az innovációról: „nem kérdezheted meg a vevőket, hogy mit akarnak, majd utána megpróbálod nekik odaadni azt, mert az alatt az idő alatt, amíg megépíted, a vevők közben valami újat akarnak". Előre kell gondolkodni. Henry Ford mondta egyszer, hogy ha megkérdezné a vevőket, mit akarnak, akkor ők valószínűleg azt mondanák: „gyorsabb lovakat" — tehát az ügyfelek nem tudják, hogy mit akarnak. És ezek közül a legveszélyesebbek azok, akik azt hiszik, hogy tudják. „I know..." — itt sem igaz.

Eric Ries, aki a Lean Startup könyvet írta, mondta, hogy a legdrágább módszer az ügyfél igények felmérésére, ha megcsinálod a programot. Eric csinált egyszer szoftvert, amiben 3D avatarok voltak, és összesen 11 üzenetküldő programhoz integrálta azt. Nagyon de nagyon odafigyelt a minőségre, és hat hónapot ölt a cége a projektbe. Majd amikor végre kiadták a szoftvert, nagyon izgult, hogy stabil lesz-e, hogy az integrációk jól fognak-e működni, stb. De kiderült, hogy egyáltalán nem kellett volna izgulnia, mert a szoftvert összesen egyetlen ember töltötte le. Egyáltalán nem számított, milyen a minősége. Ugyanis senki nem használta.

Feedback az élet.

Az „I don't know" ereje

Avagy a profizmus kulcsa. Profinak lenni azt jelenti: alázatosnak lenni. Vagyok annyira profi, hogy már tudom — semmit sem tudok biztosra. Ha valaki ki meri mondani, hogy „nem tudom", és nem a bullshitet nyomja vagy találgat, akkor már eljutott egy magasabb szintre. Merjük azt mondani, hogy nem tudom. Ha féligazságot vagy nem biztos dolgot osztunk meg a másikkal, akkor azzal félrevezetjük, és kárt okozunk a programnak. A kár gány, a gány a fertő, a fertő a halál...

Nem tudni valamit nem szégyen. Nem ismerni egy technológiát, nem égő. Nem vágni fejből egy git parancsot, nem blama. Egy fejlesztő mindig tanul — ha mindent tudna, nem lenne mit tanulnia. Újabb dolgok megismerése, újabb dolgok befogadása az egyetlen útja a fejlődésnek. Sok olyan idős programozó van, aki begyepesedett, és nem akar, és most már nem is tud technológiát váltani. Bizonyos tekintetben én is ilyen vagyok. Ezek a programozók nem akartak tanulni, mert azt hitték, hogy már megtanulták, amit lehet, és a szakma csúcsán vannak. Ezek az emberek sosem mondják, hogy „nem tudom". Ne légy ilyen.

Ha ki mered mondani, hogy „nem tudom", akkor biztos lehetsz abban, hogy korrekt és értelmes választ kapsz, és azt fogod megtudni, amit akartál — nem homályos ismeretek alapján fogsz dönteni. A megalapozott döntések viszik előre a tudásodat, a karrieredet, és végső soron a szervezetet is. Ez az „I don't know" ereje.