a … harmadik

Mi van akkor ha harmadik félként vagyunk egy projektben? Ahol az irányítás a mienk, de:

- a második fél nem fogad el kérést/utasítást/javaslatot (semmit) tőlünk, csak az Ügyféltől?

- az Ügyfél nem akar az egésszel foglalkozni

- az Ügyfél nem akar kommunikációs csatorna lenni…

És mindehez még a következő tényezők társulnak:

- az Ügyfél az adattulajdonos

- a második fél – nevezzük Xrt-nek a könnyebbség kedvéért – az adatgazda: náluk vannak az adatbázisok, ők végeznek műveleteket

- Mi, a 3. fél, csak kiírjuk amit az Ügyfél megálmodott.

Mivel magát az adatokat mi nem láthatjuk, igazán fogalmunk sincs arról, hogy amit az Ügyfél kér egyáltalán lehetséges-e, van-e olyan adat. De jóhiszeműen feltételezzük, hogy csak van arról valami halvány fogalma, hogy milyen adatokkal dolgozik.

Az eredeti kérdés: mit csináljunk ilyen helyzetben?

Ami a legfontosabb – tapasztalat mondatja velem – minden lehetséges módon védjük meg a hátsó fertályunkat. Merthogy ebből jól kijönni nem lehet az is biztos. Itt a veszteségek (pénz és presztízs) minimalizálása a cél. Borzasztó így dolgozni, de megesik.

1. Minden döntési helyzetben mindegyik félnek kommunikáljuk le, hogy miben és kitől várunk döntést. Ne felejtsül el hangoztatni, hogy amennyiben egy döntés nem születik meg időben mi onnantól kezdve nem vagyunk felelőssé tehetők a határidő be nem tartásáért.

2. Magunknak vezessük egy excelben, wordben, kockás füzetben, hogy mikor kitől mit kértünk, milyen formában (email, szóban, megbeszélés,..) és mikor kaptunk rá választ. Amikor az első határidőcsúszás eljön és mindenki hirtelen ránk – a projekt managementre – kezd mutogatni akkor könnyebb legyen összeszedni és az orruk alá tolni. Jobb esetben a hiúságokat leküzdve a felek összekapják magukat és belátható időn belül kialakil az együttműködés.

Vannak azonban perverz helyzetek amikor az egyik félnek – pl Xrt-nek – érdeke, hoyg mi minél sárosabbak legyünk és bebukjuk a projektet. Mivel minden lényeges info tőlük kell származzon nagyon könnyen szabotálhatnak: jaj, bocs, majdnem jó adatot adunk, de kicsit mégse; millió felesleges kört futtatnak; nem válaszolnak, atán amikor igen akkor este 11 és hajnali 2 között teszik, majd még ők szólnak, h ők bezzeg teljesítettek és a pm cseszte el, h másnap reggel 8ra nem volt kész… és még ezer évig folytathatnám. Sajnos a magyarok szivatási indexe talán az egyik legmagasabb a világon. Ha tized ennyi erőt fektetne be mindenki a munkájába, mint amennyit annak kikerülésébe fektet már rég szárnyalhatnánk…

3. A kritikus pontoknál nem elég az ügyfél kapcsolattartója felé kommunikálni, ekkor jöhet a nagyágyú – mind3 fél legfelsőbb szintjánek kell figyelmeztetést küldeni, hogy bizony az a határidő nem lesz betartva. Egyrészről ugyebár a formás hátsó védelme, másrészről – és ez etikailag szerintem sokkal fontosabb – lehetnek a felsővezetésnek olyan információi amik összefüggnek a mi ügyünkkel és más perspektívába helyezik azt. Ergo lehet, h ők tudnak olyat amivel akár nekik házon belül, akár Xrt-nél sikerül elérni, hogy pályára álljon a projekt.

4. Teszteljünk! Kényes szituációkban a mi oldalunk által előállított anyagoknak kifogástalannak kell lennie. Nem megengedhető egy typo, egy rossz pixel. Nem szabad a másik oldal kezébe önként és dalolva muníciót adni. Ilyen szituációkban a tesztjegyzőkönyv szerepe felértékelődik.

Last, but not least …. nyugi.

 

gmail és más gugliságok

Mindenki isteníti. Biztos jó is. Én azonban nem kapom meg az oda címzett leveleimet. Miért is jobb mégis, mint a többi?

Jobb egyáltalán? Kétség kívül jobban használható. Szép és jó dolog, hogy mindent egy helyen lehessen elérni. Megpróbálnak behálózni, hogy minden fontos közösségi élményem rajtuk keresztül történjen. Teljesen érthető üzleti cél.  Sima userként aki blogol, képeket tölt fel, az egész család életét szervezi, nyaralást, programokat…. nagyon kis hasznos. olyan, mint az a bizonyos kis könyvecske, naptárral, telefon regiszterrel a végén. És akkor megvan az első ami hiányzik: egy todo lista. És ha már hétköznapi anyaként, feleségként gondolkodok – akkor jó lenne egy bevásárlólista. Persze olyan amit szinkronizálhatok az iPhone-al, vagy más kütyütelefonnal…

Végülis meg tudom oldani a guglidocs-al, de azért mégis örömmel látnék ilyen apró segítségeket.

Másik oldalról pedig gyakorló project managerként és szervezőként egy másik dolgot hiányolok (amit bevallom az outlookban szeretek): az értekezletek szervezése ott nagyon jó! Az erőforrások elérhetőségének vizsgálata, egy közös kalendárium ahol látom, hogy XY-nak mikor jó, mikor nem jó, .. Tudok pl. projectort is igényelni és tárgyalót. Dolgoztam olyan megoldással ahol, ha lefoglaltam egy tárgyalót és projektort is igényeltem, akkor ment az IT-nak is mail és biztos lehettem benne, hogy ha a tárgyalás előtt 5 perccel odamentem akkor már ott üzemelt a projektor, notebook, vagy amit kértem.

És mindeközben vannak cégek ahol még a közös address book is a jövő zenéje és terv

 

szervezés… Minden csak a szervezésen múlik. Elvileg. De amikor a harmadik fél nem teljesít, amikor a megrendelő dühöng, amikor … akkor ez a szó nem sokat segít

Viszont ha minden szépen le van írva, dokumentálva, ha még időben szóltunk az ügyfélnek, hogy a határidő nem tartható, ha …akkor azért nem akkora a gond.

De csak egy dolog, ha a hátsó le van védve. Az pedig egy másik, hogy a presztívveszteség mekkora.

Végülis milyen dokumentáció is szükséges? Kezdetnek nem rossz ha van egy specifikáció, netán kettő (igény és funkcionális), nagyobb volumen esetén a rendszerterv/adatbázisterv sem jön rosszul. A heti jelentések – ügyfél és főnök felé – sokat segítenek a kommunikációban. Nemcsak egyfajta kifelé szóló kommunikáció, hanem segít összerendezni a hét történéseit, és segít előkészíteni a jövő hetet. Amikor végiggondoljuk a ‘mi volt’ és a ‘mi lesz’ akkor egyben azt is végiggondoljuk, hogy

1. jól osztottuk-e be az embereket, feladatoka a héten
2. a jövő héten kell-e változtatni a stratégiánkon
3. milyen kritikus pont(ok)hoz érkeztünk, milyen végiggondolnivalónk vagy tennivalónk van

A heti report felépítése

Mivel mi készítjük és tudjuk miről van szó, hajlamiosak vagyunk elfelejteni az alapokat – miről szól, miéyen időintervallumot ölel fel, kinek szól.

Utána jöhetnek a részletek. Problémák. Tervezett feladatok – státusszal. A jövő hét feladatai.

Mennyire kell részletesen? Nagyon.

A Problémák résznél a probléma leírása, a vonatkozó emailek becitálása vagy hivatkozása, zanzásított tartalom (mikor melyik), a felderített vagy vélhető ok, megoldás vagy megoldási kísérlet, ha kell várható megoldás ideje.

A tervezett feladatok rész nagyon változatos lehet. Van amikor a projekt terv sorait kell csak behivatkozni, van amikor hétről hétre változnak a feladatok, prioritások.

 

Igényfelmérés újra…. a célok

Az egy dolog ha leírjuk az igényeket. Nagyon is szép dolog és igenis kell hozzá tehetség és gyakorlat, hogy jó legyen egy  igényfelmérés és a maximumot ki tudjuk hozni az ügyfélből is.

Azonban legább ilyen fontos, hogy az pontosan definiáljuk a célokat is. Mert az eszköz lehet jó vagy rossz, hatékony vagy épp felesleges, de referenciapont nélkül vajmi nehéz megállapítani melyik.

Ilyen referenciapont(ok) lehet a project ötletelési fázisaban a miértre adott válasz(ok).

• Miért akarja az ügyfél ezt a projektet?
• Mit vár tőle?
• Miért pont most és miért pont ezeket a funkciókat?

Az első kérdés a legfontosabb. Az általános válaszok mellett nem árt azonban ha mi is végiggondoljuk és próbáljuk konkrét célok felé orientálni az Ügyfelet. Nagyon szép és jó, hogy egy webáruházat azért szeretne az Ügyfél, mert az értékesítési csatornák bővítése egy kívánatos dolog.

De itt is lehet, hogy új vásárlók bevonása a cél, de lehet, hogy a meglévő kliensek beszerzési módszereit szeretné “csak” változtatni/optimalizálni. Esetleg munkaerő leépítés és ezáltal hatékonyságnvelés és költségcsökkentés a célja. Mindegyik valid cél, teljesen jogosak. Azonban ezek a hátsó szándékok is meghatározzák mit érdemes ajánlani majd az Ügyfélnek.

 

Igényspecifikáció

Eljön a pillanat amikor beesik az ajtón egy potenciális ügyfél, elmondja mit szeretne, mi pedig lelkesen elkezdünk tervezni. De mit is? Merthogy sokszor már itt félremegy a dolog.

Nem tervezni kell, hanem rögzíteni az igényeket, mégpedig lehetőleg olyan formában, hogy azokban ne szerepeljenek felesleges technológiai megkötésekre vonatkozó infok. Amennyiben tényleg van technológia megkötés, azt az igényfelmérés eredményeit rögzítő doksi egy külön fejezetében kell taglalni.

Akkor nézzük közelebbről az igényfelmérés eredményit dokumentáló irást, alias Igényspecifikációt. Tartalmazza az Ügyfél igényeit. Triviálisan egyszerű… vagy mégsem

Mikor bejön egy Ügyfél és elkezdi mondani mire is gondol, mi lenne az igénye, akkor sokszor még Ő is hezitál, megerősítést vár és a reakciónk függvényében halad tovább a gondolkodása. (Persze van a másik fajta is – pontosan tudja mire van szüksége, netán még azt is hogyan kellene ezt megvalósítani…. de velük majd máskor)

Ilyen esetben nagyon nehéz megállni, hogy ne akarjuk elkápráztatni és minél nagyobbra felfújni a projektet már a legelején. Simán megtehetjük, akkor miért is ne? Mert egy nem pontosan körülírt fejlesztésnél nyúlósabb, nyálkásabb, ragacsosabb dolog kevés van…. (mondjuk egy kétéves amint segít csokisszütit sütni ) Sok a hiba és vita lehetősége, a végeredmény pedig korántsem biztos, hogy minden fél számára kielégítő.

Igényfelméréskor nagyon figyeljünk, halljuk meg mit mond az Ügyfél és legföképpen a tervezett projekt mögötti üzleti szemléletet próbáljuk megérteni. Gyűjtsük szisztematikusan össze az Ő ötleteit, vágyait, gondolatait és ezeket írjuk le. Fontos, hogy tényleg átlássuk miről beszél, megértsük neki miért kell az adott fejlesztés.

Ennek a beszélgetésnek a végeredménye az Igényspecifikáció. Ebben szabatosan vázolva van:

• Miért
• Kinek
• Mit
• Hogyan/Hogyan ne

A Miért az üzleti vagy más elérni kívánt cél.

A Kinek a célközönség. Hiszen nagyban befolyásolhatja egy projekt menetét, hogy kik lesznek a végfelhasználók.

A Mit lesz a konkrét leírása annak, hogy az Ügyfél mit szeretne. Itt érdemes az igényeket táblázatba foglalni, fontossági sorrendet adva nekik – ez egy későbbi fázisokra bontásnál még jól jöhet.

A Hogyan/Hogyan ne részbe kerülnek az Ügyfél már meglévő tapasztalatai (pl. soha nem akar még egyszer lila felületet látni, mert fáj tőle a feje) és a technikai korlátok.

Ezt at Igényspecifikációt érdemes az Ügyféllel egyeztetni, aláiratni.

Tanácsadó válogatja: van aki helyben felvázol magában/magának több alternatívát, van aki kér 1-2 napot a javaslatok elkészítésére. Magát az Igényeket ha felmértük elég pár óra, hogy azokat formalizálva rögzítsük. A javaslatok kigondolására, leírására szintén nem tanácsos pár napnál többet szánni. Ezekből a javaslatokból még úgyis ki kell gyomlálni az Ügyféllel együtt az életképeset, amjd abba az egy irányba kell sok energiabefektetéssel haladni és elkészíteni a Követelményspecifikációt. De ez már egy újabb post lesz

 

Specifikáció

Most szembesültem vele, hogy van a 21. században még olyan fejlesztő cég akiknél a specifikáció egy telefonos ötletbörzés, egy félig átgondolt email és társait jelenti. Van szervezet ahol nem alakult még ki az a standardizált, kontollált és megfelelő eszközökkel támogatott belső működés  aminek hozadéka a pontosság, a költséghatékonyság és társai. A nagy válság árnékában azonban ők is úgy gondolják, hogy talán azért nem ártana valamit tenni az ügyben.

Ennél a cégnél fogok december elsején kezdeni. Alapból szörnyülködhetnék, hogy atyaég, én ilyen gagyi helyre nem megyek… ez sufni tuning bt kicsit nagyobban. Nem szörnyülködöm. Mert nézhetjük másik oldalról: adott egy cég akik nagyon komoly bajban lesznek hamarosan ha nem történik változás a működésükben,  nem válnak minél hamarabb profikká. És én szeretem a kihívásokat!

Eme szép feladat megoldására kaptam határidőt. Márpedig egy egész hetet. Netán kettőt. de az a max.! És végülis elég egy jó koncepció kidolgozásához.

Most csak egy nagyon gyors összefoglalás, hogy miről is kell majd gondolkodnom az elkövetkezendő hetekben:

• project management célok meghatározása
• pm struktúra, kommunikáció meghatározása, hatáskörök definiálása
• gyakorlati lépések

1. sales és pm process kidolgozása
2. pm és development sablonok elkészítése
3. pm eszköz(ök) kiválasztása, bevezetése, használata

 

Egy projekt első lépése – Információ gyűjtés

Sokszor látom, hogy alábecsülik sokan ezt a legelső -tapogatózó- fázist. Miről is szól ez az egész? Bejön az ügyfél és elmondja mit szeretne, miről szóljon az ajánlat. Az ilyenkor pontosan meghatározott célok jelenthetik a projekt későbbi sikerét. … avagy bukását. Szerencsére azért ez nem ennyire fekete fehér. Normál esetben ez egy iterációs folyamat aminek a végeredménye egy ajánlat, amely tartalmazza a műszaki, időbeli és pénzbeli feltételeket.

Jobb esetben ezeket a paramétereket a felek olyan pontosan határozzák meg, hogy az egy rendszerspecifikáció kiinduló dokumentumaként, avagy másképp nevezve egy teljes követelmény specifikációként használható. Lesz egy bejegyzés a követelmény specifikációról is külön, de most még nézzük nagyobb általánosságban a dolgokat. Van egy ajánlatunk aminek része egy nagyon pontos felmérés arról, hogy az ügyfél mit szeretne és mi ezt hogyan képzeljük el. Tartalmazza továbbá, hogy ezeket a fejlesztéseket milyen időintervallumon belül szeretnénk megvalósítani. Ezen a ponton cége válogattja, hogy aláírnak-e szerződést a folytatáshoz, vagy még nem.

Azonban minden esetben a követelmény specifikálása után fontos megbeszélni az ügyféllel és írásba foglalni még egy – két apróságot. Olyanokat, mint például: a leendő site vagy alkalmazás célközönsége, a sikeresség mércéje (erről később bövebben), egy rövid versenytárs elemzés, a szükséges erőforrások és információ az ügyfél részéről, kommunikációs csatornák …