Gyerekkoromban láttam egy kung-fu filmet amiben a suttyó tanonc megkérdezte tanítójától, hogy mennyi ideig kell gyakorolnia ahhoz, hogy elérjen arra a szintre amin a mester van. Erre a bölcs valami olyat válaszolt, hogy 10 évig. Erre a tanonc visszakérdezett, hogy ha dupla annyit gyakorol mint most akkor mennyi időbe telik mindez? Erre azt a választ kapta, hogy 20 évbe, amit a tanonc nem értett. A bölcs mester elmagyarázta neki:
Ha fél szemmel a célt nézed, akkor csak egy szemmel tudsz a feladatra koncentrálni.
Az a jó ezekben a nagy kínai bölcseletekben – melyek amerikai forgatókönyvírók tollaiból pattannak ki – hogy úgy értelmezi az ember ahogyan akarja, de legalább jól hangzik.
Előfordult már velem, hogy egy projekt során megfeledkeztem a célokról és a produktivitásom mély pontra esett, miközben a ráfordított munka és energiamennyiség csak növekedett. A fókuszvesztésről van szó, amikor az össze-vissza csapkodás az evezőlapátokkal nem viszi előre a hajót csak egy helyben forgatja és nem történik semmi.
Olyan az egész mint a bekötött szemű ember az autó volánja mögött. Kinézi, hogy hova szeretne eljutni, irányba állítja az autót, majd jöhet a szembekötés és a padlógáz. Ha közeli célt szeretne elérni – mondjuk egy nyílegyenes utca egyik végéről kellene így eljutnia a másikra – akkor talán még teljesíti is a feladatot, de abban a pillanatban, hogy növelnénk a távolságot, drasztikusan csökkennének a túlélési esélyei. Ezen pedig a sebesség sem segít, mi több csak tovább rontja a helyzetet. Pontosan ez történik azzal a projekttel is amelyik nem tudja, hogy hová tart. Hiába növeli az erőforrásokat és az erőfeszítéseket, attól még bekötött szemmel száguld, csak épp 5 km/óra helyett padlógázzal. (Megfigyelésem szerint minden élethelyzetre fel lehet hozni egy jó autós példát)
Bosszantó hiba, amit visszatekintve könnyű felismerni, de amikor az ember egy ilyen szituáció kellős közepén ül akkor nem egyértelmű, hogy ez történik. Azt gondolom, hogy ebben a helyzetben pont a felismerés a legnehezebb. Az alkalamazás-fejelesztés területén ezek ellen lehet védekezni tervekkel és prototípusokkal, de egyik sem mindenható és a projekt bármelyik szintjén bekövetkezhet a baj.
Velem is megtörtént már, hogy egy webfelület egyetlen apró részletének a megjelenésével, órákat dolgoztam, pixeleket toltam jobbra és balra, színsémákkal játszadoztam és hasonlók, miközben a projekt azon fázisában nem volt cél a tökéletes design előállítása. Ezt azonban akkor és ott nem vettem észre, mert belefeledkeztem a részletekbe és már nem láttam a fától az erdőt. Eltűnt előlem a globális cél és végül több órányi munkát követően elkészült a design, de a programrészlet amin eredetileg dolgoznom kellett volna nem haladt semmit.
Nagyon hatékonyan lehet védekezni a jelenség bekövetkezte ellen valamelyik jól kipróbált fejlesztési módszertan alkalmazásával. Nekem személy szerint az agilis módszertanok közül a Scrum tetszik és vállt be a legjobban. Az Scrum például úgy segít, hogy a gyakori iterációk során a Product Ownerek figyelme újra és újra a projektre fókuszál, így van lehetőségük időben észreveheti ha a dolgok nem a megfelelő irányban haladnak és erre felhívhatják a ScrumMaster figyelmét. Ezt követően már a ScrumMaster feladata, hogy a megfelelő mederbe terelje vissza a fejlesztést. Bármikor előfordulhat, hogy a projekt vesz egy fordulatot és nem a megfelelő irányban folytatja útját, azonban az iteráció befejeztével ez azonnal szemet fog szúrni a Product Ownereknek. A kulcs tehát a kis lépésekben rejlik. Az apró és gyakori iterációk során nem fordulhat elő, hogy egy fejlesztési szakasz hosszú időn keresztül rossz irányba haladjon és túl későn derüljön fény a problémára. A Product Ownerek figyelme ugyanis folyamatosan a célra koncentrál és ha bármilyen módon a Scrum Team eltér ettől a céltól akkor szinte azonnal megtörténik a korrekció. Ez benne a nagyszerű, persze csak akkor ha a módszertan következetesen és fegyelmezetten be van tartva! Máskülönben az egész nem ér semmit, hisz nem lesz fék amely megállítaná a szakadék felé száguldó autót.
Hozzá kell tennem, hogy szabadúszóként jellemzően a Solo Scrumot használom, ami esetemben némiképp változtat a felálláson. Egy személyben töltöm be a ScrumMaster és a Scrum Team szerepét, ha pedig saját startup-on dolgozok akkor még a Product Owner is én vagyok. Ez utóbbi esetben különösen nehéz a feladat, mert Product Ownerként saját magamnak kell észrevennem, hogy a ScrumTeam – amit szintén én reprezentálok – nem a kitűzött cél felé halad. Nem túl szerencsés szituáció és lehetőség szerint kerülni kell, hogy minden feladat egy kézben összpontosuljon, ellenkező esetben könnyen kijelenthető, hogy halálra van ítélve a projekt.
Más megközelítésben a GTD-t is elő lehet húzni mint módszertant, amely nagyon komolyan épít arra, hogy a célt folyamatosan szemmel tartsuk. Címszavakban:
- Csak akkor lehetsz nyugodt afelől, amit nem teszel, amikor tudod, hogy mi az, amit nem teszel.
- Ahhoz, hogy eljuss oda, ahova akarsz, tudnod kell, hogy most hol vagy.
- Minél világosabb célod van, annál több módon tudod elérni.
- Fókuszálásod megváltoztatása eredményeidet változtatja meg.
Akárhogy is nézzük, badarság azt gondolni, hogy csak a feladatra kell koncentrálni és a cél – mint önmegvalósító jóslat – majd jön magától és teljesül. A célt ki kell tűzni, folyamatosan szemmel kell tartani és úgy kell elérni. Hacsak nem sportként űzöd a zsákutcák felderítését, akkor nem javaslom, hogy megfeledkezz a célodról, legyen az személyes vagy üzleti eredetű. Fél szemmel tartsd szemmel, hogy mindig tudd hová tartasz!
. A fenti módszernek számomra egyetlen egy problémája van, de az sajnos teljesen használhatatlanná teszi az egész rendszert. Abból indulok ki, hogy a tökéletes GTD rendszer üzemeltetése során egy helyen tárolok mindent. Úgy értem, hogy egy rendszerbe (Gmail), programba, mappastruktúrába sűrítek be mindent. Így ha valamilyen információra szükségem van, tudom, hogy hova nyúljak. Bár a feladataim nagy részét e-mail-ben kapom, azért jócskán akadnak olyan tennivalóim amelyeknek más úton érkeznek (pl. Erkélykorlát lefestése). Ezeknek a berögzítése egy levelezőprogramba elég vicces. Maga a rögzítés persze nem nagy ügy – csináltam persze szabályokat, amelyek már szerveroldalon leválogatják és szétszórják a leveleket – de olyan levelet írni saját magamnak, hogy “Erkélykorlát lefestése”, “Drótkefét venni a barkácsboltban” stb. elég rendszeridegennek érzem. Nem is túl barátságos, és talán a Mail.app, talán a Gmail IMAP implementációjának köszönhetően, nem túl stabil. Néha duplikálódnak a levelek, egy levelet átmásolok egy másik mappába, majd az eredetit törlöm és a másolat is törlődik stb. Kényelmetlen, rendszeridegen, de legfőképp nem egyszerű a fenti rendszert üzemeltetni amint belépnek a képbe a nem e-mailben érkezett feladatok.
