Vissza
Vezérigazgatói blog

Az egyetemi első év és az első munkám által lerakott alapok

Az előző bejegyzésben arról írtam, hogyan voltam majdnem minden az első munkahelyemen (még mindig szabadúszó szerződések alapján): a Google AdWords kampányfelügyelőjétől a programozóig. Az reklámügynökségnél való munka kiváló kezdés volt a szabadúszó karrieremnek, mert valószínűleg minden lehetséges hibát megtanított.

A weboldalak készítése mellett az első dolog, amivel elkezdtem dolgozni, a Google AdWords fizetett hirdetése volt, ami akkoriban eléggé rejtélyesnek tűnt. Arra emlékszem, hogy semmit nem tudtam róla, csak annyit, hogy a Google Analytics egyre népszerűbb és új eszköz volt, amely részben kapcsolódott a Google AdWords fizetett hirdetési szolgáltatáshoz.

Azért, hogy őszinte legyek és jól végezzem a munkát, letöltöttem néhány Apress könyvet a SEO-ról és a Google AdWords-ről torrentek segítségével. Ezeket angolul olvastam minden nap, hogy megérthessem, miről szólnak, és hogyan kell őket megfelelően kezelni.

Büszke vagyok, de ezek a három könyv, amiket olvastam, remek kezdés volt az általános SEO és Google ismeretek megszerzéséhez. Ezek után folytattam az ismeretek bővítését a blogok olvasásával és a legújabb fejlemények követésével. Ezek a könyvek olvasása megalapozta az ismereteimet, amelyek ma is hasznosak.

A második probléma, amit akkor felismertem, az volt, hogy a nyomtatott tervező nem lehet egyszerre webtervező. Akkoriban majdnem minden tervező magát egyetemes tervezőnek tekintette, és olyan kifejezések, mint UX vagy UI, nem voltak használatban. Ez jelentős probléma volt.

A probléma az volt, hogy a tervezők statikus, gyönyörű képeslapokat készítettek, amelyek valamilyen értelemben webhelyként kellett működjenek. Néhány példa:

• Menüpontokat terveztek állapotok nélkül, és nem tették egyértelművé, hogy rájuk lehet kattintani.
• Gradienset használtak (akkor még nem létezett a CSS3), és a háttér egy hatalmas kép lett – képzeld el, mit mondana most a Google PageSpeed Insights erről.
• A tervező dőlt betűket vagy akár Comic Sans-t használt néha. Igen, ez előfordult.

A kollegáim segítésére elkezdtem olvasni a korábban népszerű Smashing Magazine blogot, amely lényegében meghatározta a webtervezési megértésemet: hogyan kell rendezni az elemeket és a legjobb gyakorlatokat, és általában lefektette az UI/UX szabványok alapjait, amelyek a jövőben kialakultak.

Így én lettem az első akadály az ügyfeleknek való bemutatás előtt – az, aki néhány megjegyzést adott a tervezőnek, hogy a tervezés legalább valamivel jobb legyen. Emlékszem, ez valódi kihívás volt egy tapasztalt nyomtatott tervező számára – egy gyerek, aki megpróbálja megmondani neki, hogyan kell rajzolni. Sok feszültség volt, de úgy éreztem, köteles vagyok jól és minőségi munkát végezni. Szerettem volna megosztani az ismereteimet.

A harmadik probléma az volt, hogy a weboldalak nem voltak az reklámügynökség fő üzletágai. Nem titok, hogy az reklámügynökségek gyakran az összeköttetésekről és kapcsolatokról szólnak, ahol egy “jó haver” bejön és rendel szolgáltatásokat, mert tudják, hogy “jól dolgozol.”

Ennek következtében észrevettem, hogy az ügyfelek gyakran több funkcionalitást vagy másfajta igényt szeretnének, miután a projektet átadták. Úgy gondolták, hogy az összes kívánságukat és elvárásaikat egy fix áron teljesítik. Végül is, ha egy eseményt szervezel vagy egy szórólap tervezését finomhangolod, annyi változtatást tehetsz, amennyit csak szeretnél, amíg elégedett vagy a végső eredménnyel.

Kezdetben nem írtunk vagy határoztunk meg semmilyen követelményt. És természetesen nem lehetett cserben hagyni egy jó barátot, tehát minden további kívánságot ingyen teljesíteni kellett. Természetesen mindez végül az én költségemre ment. Senki sem értette meg, hogy egy új oldaltípus hozzáadása nem csak egy menüpont hozzáadását jelenti, hanem egy új entitás, kezelési rendszer programozását és integrálását az átfogó rendszerbe.

Csak homályosan hallottam a követelményekről és arról, hogy léteznek. Bevezettem a leírások írásának célt (legjobb esetben ezeket követelményeknek lehetne nevezni) bármely projekt megkezdése előtt és plusz költséget számítottam fel az egyéb meghatározatlan költségekért.

Mindkettőnknek előnyös volt ez: nem kellett ingyen dolgoznom és változó igényeket teljesítenem, míg az ügynökség okot talált arra, hogy még többet számíthasson fel az ügyfélnek. Bár néhány esetben én voltam az egyetlen, aki ugyanazzal a költségvetéssel profitált.

Ettől kezdve minden projekthez technikai specifikációkat vagy követelmények leírását tanultam meg írni. Folyamatosan fejlesztettem és tanultam, hogy pontosabban és jobban írjam le őket, és minden új ügyféllel kevesebb és kevesebb vitám volt arról, hogy mit kell tenni és mennyiért.

A negyedik probléma, amivel szembesültem, a projektmenedzsment volt. Egy esemény szervezése vagy egy szórólap vagy névjegy munka kezelése nem ugyanaz, mint egy működő weboldal létrehozása.

Nem lehet bosszankodni, mert ma sem könnyű jó IT projektmenedzsereket találni. Ahhoz, hogy jó IT projektmenedzser legyél, meg kell értened, mit csinálnak a tervező és programozó kollégáid, és a folyamatot. Ha ezt nem érted, akkor csak egy üzenetvivő maradsz az ügyfél és a programozó között. Üzenetvivő lenni gyakran annyit jelent, hogy üresen pattogsz ügyfelek között és továbbítod az e-maileiket, ami nem teremt értéket.

Ezt a különbséget már a tizenkettedik osztályban észrevettem, amikor figyeltem, hogyan dolgozott velem a projektmenedzser. Például mielőtt egy feladatot átadott volna egy programozónak, azt először megfelelően le kellett írni, az szükséges hitelesítéseket meg kellett szerezni, és mindent elő kellett készíteni, hogy csak végrehajtani maradjon. De kiderült, hogy, ahogyan azt remélni sem kellene, már nem történt meg, hogy “erre nem tudok válaszolni, ellenőriznem kell,” vagy “visszajelzek neked a válasszal.” Az összes választ egyszerűen másolva a kliensnek továbbítottad, és az e-maileiket továbbítottad. Végül te válsz a projektmenedzserré, függetlenül attól, hogy akarod-e vagy sem.

Ezt a problémát akkor oldottuk meg, amikor én, első egyetemi évemben és autó nélkül, gyakran vonattal utaztam Kaunasból Vilniusba ügyfél találkozókra.

Bájos volt, hogy frissmanként az első vonattal 6 órakor indultam Vilniusba, ahol a projektmenedzser már várt rám a vasútállomáson 8-kor, és együtt mentünk az ügyféltalálkozókra.

Valóban ijesztő volt, mert a cégek egészen nagynak és kifinomultnak tűntek – legalábbis nekem így tűntek. A legjobb pulóvert hordtam és ügyeltem rá, hogy ne legyenek szőrszálak a kabátomon. Professzionálisnak akartam tűnni és nem csak egy rémült gyereknek.

Hallgattam és figyeltem, ahogyan egy igazán jó projektmenedzser (minden IT-vel kapcsolatos probléma ellenére) szépen kommunikált, feloldotta a konfliktusokat és még szolgáltatásokat is értékesített. A megfigyelés által tanultam, és a megfigyelés legalább olyan fontos, mint magad cselekedni. Amikor nem érted a kontextust vagy hogyan kell csinálni, az példától tanulás rengeteg kontextust nyújt, amelyet később alkalmazhatsz. Hálás vagyok érte.

Például egy látszólag egyszerű szabályt tanultam meg: hogy pontosan időben érkezz, nem korábban vagy később. Mindig túl korán érkeztem, mert attól féltem, hogy elkésem.

Vicces, hogy néhány azok közül az ügyfelek közül, akik akkoriban voltak, most az én ügyfeleim lettek az e-kereskedelem területén az ügynökségen keresztül anélkül, hogy tudnák. Ez egy egó felfrissülés.

Így az első munkám szabadúszó szerződés alapján egy reklámügynökségnél lefektette az alapokat a további szabadúszó utazásomhoz. Első SEO készségeimet fejlesztettem, elmélyítettem a programozási ismereteimet WordPress rendszerek építésével, és elkezdtem képességeket kialakítani elemzőként és projektmenedzserként.

Végül a projektek az “amivel csak működik” fejlődtek a “rendesen való dolgok készítése” irányába: specifikációkkal és követelmény leírásokkal, előzetes értékelésekkel és profi webtervezők és front-end fejlesztők felvételével, miközben én mindent programoztam és kezeltem a folyamatot. Még az ügyfeleknek is készítettünk utasításokat, hogyan kell használni a rendszert, és ezeket a tréningeket én vezettem, megmutatva, hogyan működik a rendszer.