A szórakoztatóipar félreérti a produktivitást. Így néz ki valójában a valódi fejlesztés

Miért értik még mindig félre olyan sokan a produktivitást?

Animációban, játékfejlesztésben, illusztrációban és UI-designban ugyanaz a kérdés tér vissza újra és újra: „Hogyan dolgozzunk gyorsabban?” „Hogyan legyünk hatékonyabbak?”

És szinte minden alkalommal ugyanazok a válaszok kerülnek elő:

• vezessünk be egy új eszközt
• tanuljunk meg több gyorsbillentyűt
• mozgassuk gyorsabban a kezünket
• egyszerűen szokjunk hozzá jobban

Nem azt mondom, hogy ezek a dolgok teljesen haszontalanok. De ha az egész beszélgetés csak ezek körül forog, akkor nagyon valószínű, hogy teljesen félremegy.

Néha az ilyen ötletek véletlenül működnek. Egy új eszköz segíthet. Egy gyorsbillentyűkre épülő workflow véletlenül jól illeszkedhet. De ha nem tudod megmérni, mi javult és mennyivel, akkor ennek a tevékenységnek a nagy része nem más, mint a produktivitás érzete.

A valódi probléma az, hogy mindenki arra koncentrál, mit kellene hozzáadni, ahelyett hogy azt nézné, miért lassú egyáltalán a workflow.

Miért vall kudarcot a „hamis fejlesztés”?

Amikor a produktivitásjavító próbálkozások kudarcot vallanak, a minta általában ugyanaz: megoldásokat halmoznak egymásra anélkül, hogy előtte felmérnék a jelenlegi állapotot.

Egy Photoshop-workflow esetében ez például azt jelentheti, hogy megnézzük:

• naponta hány perc megy el rétegek keresésére
• hány kattintás veszik el pusztán a blend mode-ok és opacity értékek ellenőrzésére
• mennyi idő telik el, mire a valódi munka elkezdődik azután, hogy megkapod valaki más PSD-jét
• hányszor akad el egy revízió csak azért, mert senki nem látja azonnal, mit kell valójában módosítani

Ha ezeket a dolgokat nem érted, mégis tovább halmozod az olyan ötleteket, mint a „próbáljuk ki ezt a plugint” vagy „osszunk meg több gyorsbillentyűt”, akkor az a legtöbb esetben nem fejlesztés.

Ez csak fejlesztési színház. Még azelőtt kezdesz megoldásokat alkalmazni, hogy a valódi problémát egyáltalán azonosítottad volna.

A fejlesztés nem azt jelenti, hogy találsz egyetlen varázseszközt. A valódi fejlesztés legfontosabb része az, hogy megfigyeld, valójában mi maga a probléma.

1. szabály: szabványok nélkül nincs fejlesztés

Az első dolog, amire egy csapatnak szüksége van, nem több fegyelem vagy motiváció. Hanem szabványok.

Mielőtt azt kérdeznénk: „hogyan tegyük gyorsabbá az embereket?”, előbb olyan dolgokat kell definiálni, mint:

• hogyan legyenek elnevezve a rétegek
• hogyan legyenek felépítve a mappák
• hová kerüljenek az adjustment layer-ek és effektek
• hogyan nézzen ki egy PSD ahhoz, hogy a következő ember azonnal el tudja olvasni

Ha ezek a szabványok nem léteznek, még azt sem lehet tisztán megállapítani, mi számít normálisnak és mi rendellenesnek.

Szabványok nélkül nehéz eldönteni, hogy egy workflow lassú-e, vagy egyszerűen csak kaotikus. Ennek eredményeként az lesz a szabály, aki éppen a fájlt kezeli, és a folyamat emberfüggővé válik.

Ez nem azt jelenti: „a workflow azért működik, mert a tapasztalt emberek erősek”. Azt jelenti: a workflow a tapasztalt emberektől függ, mert nincs szabvány.

Ha részletesebben is meg akarod érteni, hogyan lassítják le a nem szabványosított PSD-k az egész projektet, ez a cikk mélyebbre megy:

Ha a Photoshop PSD-id nincsenek szabványosítva, komoly gyártási problémád van

Ha az elnevezési szabályok és a rétegstruktúra nincsenek szabványosítva, a javítások, handoffok és az irányítás is lassabbá válik.

2. szabály: mielőtt eldöntöd, mit kell tenni, meg kell értened, mi történik valójában

Még ha definiálod is a szabványokat, a fejlesztés akkor sem kezdődött el. A következő szükséges lépés a workflow megfigyelésének képessége.

Ez nem azt jelenti, hogy valamilyen túlzásba vitt, bonyolult analitikai rendszert kell bevezetni. Azt jelenti, hogy nagyon gyakorlati kérdéseket kell közelről figyelni, például:

• hol megy el az emberek ideje keresgélésre
• hol veszítik el az átlátást
• hol jelennek meg az ismétlődő ellenőrzési feladatok
• hol ugrik meg hirtelen a kognitív terhelés

Ezeket a dolgokat saját szemmel kell megvizsgálni. Ha ezeket nem érted, a megfelelő beavatkozást sem tudod kiválasztani.

Sok rétegpanelre épülő workflow-ban a valódi pazarlás nem a puszta inputsebességben rejlik. Hanem abban, hogy hány lépés kell már ahhoz is, hogy egyáltalán megértsd, mi történik.

• a rétegnevek önmagukban nem mutatják meg a valós állapotot
• a rétegekre rá kell kattintani pusztán azért, hogy lásd az opacity-t és a blend mode-ot
• a mély mappastruktúrák megnehezítik a célzott elem elérését
• az irreleváns rétegek folyamatos zajként ott maradnak, még akkor is, amikor csak néhány elemre lenne szükséged

Csak akkor tudod eldönteni, mit érdemes valóban javítani, amikor ezek a problémák láthatóvá válnak. Még ha első pillantásra úgy is tűnik, hogy „az emberek lassúak”, akkor is konkrétan meg kell vizsgálni, miért. Lehet, hogy eszközprobléma. Lehet, hogy képzési probléma. Lehet, hogy szerkezeti probléma.

Egy eszköz bevezetése önmagában még nem fejlesztés. Csak akkor válik azzá, ha összekapcsolódik a megfigyeléssel és a szabványokkal

Ez a pont elég fontos ahhoz, hogy teljesen nyíltan kimondjuk:

Egy új eszköz telepítése nem javítja automatikusan a produktivitást.

Csak akkor válik valódi fejlesztési eszközzé, ha olyan dolgokban segít, mint például:

• a szabványok annyira hasznossá tétele, hogy a követésük láthatóan időt takarít meg
• az aktuális workflow eltéréseinek könnyebb felismerése
• a keresésre, ellenőrzésre és bizonytalanságra elmenő idő láthatóvá tétele

Pontosan ezért olyan nehéz Photoshop-workflow-kat javítani pusztán a standard UI használatával.

Rendbe lehet tenni a rétegneveket, de ebből nem lesz automatikusan nagyobb sebesség. Meg lehet határozni rétegszíneket, de ettől még nem lesz feltétlenül jobb az olvashatóság vagy a kinyerhetőség. Meg lehet szervezni a struktúrát, de amint a PSD nagy lesz, ugyanúgy görgetni és mappákat nyitogatni kell.

Sok csapatban tehát a szabványok fenntartásához szükséges erőfeszítés látható, a nyereség viszont nem.

És pontosan ezért omlanak össze a szabályok nyomás alatt.

A DLLP nem csak egy „gyorsító eszköz”. Inkább olyan eszköz, amely láthatóvá teszi a workflow problémáit

Könnyű a DLLP-t egyszerűen praktikus eszközként leírni. De ez nem a legfontosabb része.

Az igazi értéke nem csak abban van, hogy képes:

• állandóan láthatóvá tenni az opacity-t és a blend mode-okat
• fejlett szűrőkkel pontosan azokat az elemeket kiemelni, amelyekre szükséged van
• dual view-val lehetővé tenni, hogy a PSD különböző részeit egyszerre figyeld

Az igazi értéke abban van, hogy megmutatja, hol veszít időt a workflow.

Ha az elnevezés következetlen, a szűrés ezt azonnal leleplezi. Ha a struktúra olvashatatlan, egy áttekinthetőbb panel ezt azonnal megmutatja. Ha a rétegállapotok kezelése hanyag, a folyamatosan látható tulajdonságok egyetlen mozdulattal leleplezik ezt a káoszt.

Másképp fogalmazva: a DLLP nem csak egy eszköz, amely gyorsabbá teszi az embereket. Hanem egy tükör is, amely megmutatja, mennyi lassulást okoz a jelenlegi munkakörnyezeted.

Ha konkrétabb példákat akarsz látni arra, hogyan lehet ezt a pazarlást megszüntetni, ezek a cikkek részletesebben is belemennek:

Évente 40 órát pazarol a rétegek keresésére? Az első szűrő a Photoshopban, amely nullára csökkenti a 'keresési időt'

Tanuld meg, hogyan lehet megszüntetni a rétegek vizuális görgetéséből eredő pazarlást azzal, hogy csak azt emeled ki, amire valóban szükséged van.

Így láthatod egyszerre az összes réteg opacity-jét és blend mode-ját Photoshopban

Nézd meg, hogyan lehet megszüntetni a kattintásalapú ellenőrzést, és csökkenteni a rétegállapotok megfigyelésének költségét.

A valódi produktivitásjavítás nem „gyorsabb emberek” létrehozásáról szól. Hanem olyan workflow kialakításáról, amely nem lassítja le az embereket

Amire a szórakoztatóiparnak valójában szüksége van, az nem még több ember, aki egyszerűen gyorsabban dolgozik a többieknél.

Hanem:

• olyan PSD-kre, amelyeket bárki el tud olvasni
• olyan környezetre, ahol az aktuális állapot könnyen érthető
• olyan rendszerre, ahol a szabványok megkönnyítik a munkát, nem pedig nehezebbé teszik
• olyan UI-ra, amely csökkenti a felesleges keresést és ellenőrzést

Így néz ki egy nem lelassuló workflow.

A fejlesztés nem arról szól, hogy egyéneket hibáztassunk. Arról szól, hogy nem engedjük, hogy a pazarlás belebetonozódjon a struktúrába.

Ha a csapatod folyamatosan a következők valamelyikét tapasztalja:

• újra és újra rétegeket kell keresni
• a revíziós idő azzal megy el, hogy előbb a fájl szerkezetét kell megérteni
• már mások PSD-jeinek olvasása is kifáraszt
• eszközöket vezettek be, mégsem érezhető soha egyértelmű produktivitásnövekedés

akkor az első kérdésnek nem a személyes erőfeszítésre kell irányulnia. Hanem a hiányzó szabványokra és a workflow alacsony megfigyelhetőségére.

Összegzés: ha produktivitást akarsz, először a workflow-t mérd meg

Gyorsbillentyűket tanulni nem rossz dolog. Eszközöket bevezetni nem rossz dolog. De ez nem a valódi fejlesztés lényege.

A valódi fejlesztés mindig ugyanabban a sorrendben kezdődik:

• határozd meg a szabványokat
• figyeld meg, mi történik valójában
• szüntesd meg a pazarlást strukturális szinten

Ha egy csapat ezt a sorrendet kihagyja, és egyből oda ugrik, hogy „gyorsabbnak kell lennünk”, akkor szinte mindig a hosszabb utat választja.

A valódi produktivitásjavítás nem a puszta akaraterő növeléséről szól. Hanem arról, hogy láthatóvá tesszük a lassulás okait, majd olyan struktúrával helyettesítjük őket, amely nem termeli újra ugyanazt a pazarlást.