Elmaradottság

Az elmaradottság nem (csak) ott kezdődik, hogy másoknak van valami, de nekünk nincs. Ott is, hogy nekünk is van, de nem használjuk. Erre igen adekvát példa a magyar közigazgatásban az információga(rá)zdálkodás. 

Nincs hiány, hiszen az EU-s, honi és egyéb információk valahol megvannak. Csak a pórnép számára (szinte) elérhetetlenül. 

Egyszerű keresést eszközöltem: a Norvég Alap terhére kiírt pályázatokról szerettem volna többet megtudni. Volt 1-2 éve egy környezetvédelmi oktatáshoz kapcsolódó kiírásuk. Emlékeim szerint a NA is tól-ig időintervallumokban határoz meg kiemelt célokat és támogatandó projekteket. Ennyi az "előéletem". 

Első lépésként az NFÜ honlapján néztem szét, mint minden pályázati kiírás összefogójának vélt oldalon. Naiv vagyok,.... De a Norvég Alap pályázatait megtaláltam! Hurrá. Nézzük az Aktuális Pályázatok fejléc alatti két linket. A második eleve vicces: Magyary Zoltán Posztdoktori Ösztöndíjpályázat 2009 (HU 0041). 2009! 

Megnéztem az elsőt is, ez egy pdf, keresgélni kell a határidőt benne: 2010. október 18. 24 óra

Komolyan, majdnem eldobtam az agyam!

Közben megkerestem a NA saját weboldalát. Február elején lejárt az első ötletbeadás határideje. 

Sajnos sok ilyen példát tudnék mondani (EU Framework 7. Magyar koordinációs irodájuk is van. De ki tud róluk vajon? Évekkel ezelőtt beszéltem velük, akkoriban alig pár ötlettel találták meg őket... ). De van más jellegű példa is: milyen iratokat kell magammal vinni adott típusú ügy elintézéséhez? Itt már van előrelépés, de van még hova fejlődni....

A közigazgatásban nagyon át kellene gondolni az információgazdálkodás témakörében az alábbi alapvető és egyszerű kérdéseket:

• mely információk azok, amiket a pórnép (értsd jól: vállalkozások, tudósok, non-profit cégek, oktatási intézmények, stb) hasznosítani tudhatnak
• mely információk szükségesek az ő jobb/könnyebb fejlődésük érdekében
• milyen körben és milyen formában kellene ezen infokat disztributálni

Ezek a kérdések megegyeznek egy -bármilyen- webes megjelenés tervezési fázisában feltett első kérdésekkel.

  

Issue tracking - PM szemmel

Mit akar látni a PM, milyen adatokra kíváncsi és milyen bontásban? Ezekre a kérdésekre adott válaszok eléggé jól körvonalaznak egy jó feladatkiosztó rendszert.
Nézzük meg a leggyakoribb nézeteket és tartalmukat.

Ki, Min, Mennyit - a legalapvetőbb
Feladat - ember - idő. Ezen koordináták mentén kell tudni kigyűjteni az adatokat. Ez lehet egy olyan lista ami megmutatja, hogy adott munkatárs az elmúlt 2 hétben milyen feladatokat végzett el, és mennyi időt könyvelt rá (time tracking). Lehet egy olyan lista amiből kiderült, hogy adott projekten milyen feladatok lettek az elmúlt 1 hónapban elvégezve, és ezeket a feladatokat kik végezték el, mennyi idő alatt. (issue tracking).

Ki, Mikor, Min fog dolgozni?
Ugyanezen listák jövőre vonatkozó - a becslésre alapuló - nézetei is fontosak. Elsődlegesen, mert a tervezést lehetővé teszi, és talán a kedves munkatárs sem fog meggebedni a ráosztott feladatok súlya alatt.

Melyik projekt hol tart?
A tervezetthez képest mi valósult meg, van-e csúszás? Nagyon fontos nézet, mert elkerülhetővé teszi a túlórázást, még időben lehet korrigálni a feladatok kiírásán, vagy időben szét lehet osztani a csúszásban lévő feladatokat más emberek között. Vagy ha olyan a helyzet akkor időben lehet jelezni az ügyfél felé, hogy csúszás várható.

Mi elszámolható, mi nem?
Praktikus egy elszámolás típusa mező bevezetése, amivel a költségek nyomon követhetőek. Esetleg az órabéres emberek járandósága kimutatható. 

Megbeszélések, időgazdálkodás

Nem túl régen írtam arról, hogy miért is nem dolgozunk a munkahelyen. Gondolkodtam, milyen alapelvek kellenek, hogy jobb szervezéssel, kevesebb idő menjen el feleslegesen. Egyenlőre a házon belüli megbeszéléseket vettem sorra, nem az ügyféllel való kommunikációt. Egyszer majd azt is.....

Meg kell(ene) tervezni a megbeszéléseket, a meghívottak körét - sokkal jobban. Érdemes végiggondolni mikor, milyen embereknek, milyen információkat kell átadni, ahhoz, hogy a probléma megoldása a leghatékonyabb legyen. Ha jobban belegondolunk ez magába foglalja azt is, hogy hajlandóak legyünk a hierarchiát háttérbe szorítani és feladat orientáltan csak a ténylegesen szükséges személy(ek)kel megbeszélni a dolgokat.

Nagyon sokszor tapasztaltam, hogy a megbeszélésekre felkészületlenül jönnek az emberek. Még mindig nem eléggé elterjedt, hogy egy megbeszélésre már előre elkészített agendával menjünk be. Igen, munkaigényes. Előre végig kell gondolni mit akarunk közölni, milyen válaszok várhatóak, mire készüljünk fel, milyen kérdések merülhetnek fel... Tehát a lehetséges kérdésekre a lehetséges válaszokat is már előre összeállítjuk. Én mindig így működtem, meggyőződésből és mert elvárás is volt. Bekerültem egy olyan szervezetbe ahol ez nem volt szokás és elvárás. Mi volt a megoldás - de jó, mentesültem egy csomó munka alól. Közben csak magam alatt vágtam a fát. Nem voltam eléggé felkészült, nem tudtam "csípőből" válaszolni,.... Ennél rosszabbat nem is tehettem volna. Tanulság levonva.
Ennek egy másik hozadéka: sokkal könnyebben mederben lehet tartani a megbeszélést, és az esetleg elkalandozó munkatárs figyelmét könnyebb felhívni arra, hogy ő most nem igazán járul hozzás a megoldáshoz, ellenben teljesen más vágányra tévedt.

Triviális apróság: a megbeszélések kezdődjenek pontosan. És ha össze vannak szedve az adatok, témák akkor lényegesen kevesebb időt fogunk eltölteni üres fecsegéssel, gondolkodással.

Még egy időhöz kapcsolódó ötlet. Próbáljunk meg belőni egy időintervallumot amin belül szeretnénk maradni. Legyen reális időkeret. Nem feltétlenül csak fél és egyórás időblokkok vannak :) Ezt az időkeretet közöljük előre és az idő múlását is jelezzük. Egy 1 órásra tervezett megbeszélésnél a felétől kezdve lehet 10, majd 5 percenként jelezni. Nagyobb csoportnál meg lehet kérni a feleket, hogy mindenki csak adott időegységet beszéljen. Ilyenkor érdemes adni 1-2 percet arra, hogy ő maga összeszedje a lényegi infókat (bár teszem hozzá, jól felkészült szakembereknél erre nincs szükség tapasztalatom szerint). Ez a munkatársat is arra ösztönzi, hogy minél összeszedettebben, pontosan fogalmazva és logikusan adja elő a mondanivalóját.

Vegyük elejét a parttalan beszélgetéseknek. Látszólag a probléma megoldására irányulnak, azonban ha nem közöl az illető új ötletet, nem helyezi más megvilágításba a dolgokat, hanem pusztán ismételgeti magát vagy a másikat, más szavakkal akkor igenis vegyük el tőle a szót. Ezt lehet kedvesen és nem sértő módon tenni.

Minden megbeszélésnek legyen egy moderátora. Nem kell formalizálni ezt sem. Többnyire aki kezdeményezte a beszélgetést annak kell kordában tartania a többieket. Azonban ha ő erre nem alkalmas akkor érdemes az első 1 percben tisztázni ki legyen az. 

Amikor csak lehet keressünk más megoldást a megbeszélés szervezése helyett. A konkrét problémamegoldásokra sem kell mindig megbeszélést összehívni pl. nagytárgyalóba. Célravezetőbb ha megkérjük a résztvevőket (ha ezek száma kisebb, mint 3-4 fő), hogy mondjuk ebéd után üljünk le és csak az adott problémát akarjuk megoldani. Így megvalósul, hogy előre szóltunk és van idő összeszedni a gondolataikat, utánanézni esetleg dolgoknak. De mégis egy kicsit kevésbé formalizált, nem bürokrácia-vezérelt, hanem probléma-orientált. Még egy hozadéka van: jobban egyenrangú félnek érzik magukat az emberek.
Sokszor egy csapaton belüli levlistára bedobott mondat is elég lehet. Netán egy megosztott doksi, amihez mindenki hozzáteszi a magáét.

Issue tracking - alapok

A feladatok kiosztásának több módja is van. Ma már azért elvárható, hogy legalább a software fejlesztésben támogassuk meg ezt a folyamatot. A piacon kismillió issue tracker névre hallgató online és desktop alkalmazás van. Nem térnék ki a desktop alkalmazásokra, az idő bebizonyította életképtelenségüket.
Mire használunk egy issue tracker alkalmazást?
Elsősorban a feladatok kiosztására. Másodsorban bizonyos szinten ügyfélkezelésre is - főképp, ha ezen a felületen keresztül jelenthetik be az észlelt hibákat és követhetik azok életútját.
Mik az alapvető funkciók?
Fel kell tudni venni issue-kat, vagy nevezhetjük ticketeknek. Ki kell tudni osztani adott emberre. Adott embernek tudni kell kommunikálni, státuszt állítani, csatolni doksikat, és esetleg másik embernek átadni a feladatot.
Mik a kevésbé alapvető funkciók?
Az alapfunkcionalitást érdemes kibővíteni egy idő-kezelési modullal. Ez alapján lehet megmondani, hogy egy adott ember mennyi ideig dolgozott egy feladaton. Maga a feladat, embernél, adott státuszban eltöltött ideje könnyen logolható. Ezekből az egyszerű adatokból a managerek nagyon szép és hasznos kimutatásokat tudnak készíteni. Teszem hozzá, a fejlesztői hatékonyság vizsgálatára és javításokat célzó új módszertanok/metódusok bevezetésének visszamérésére is jól használhatóak.
A feladatok csoportosítása átláthatóbb és strukturáltabb megjelenítést tesz lehetővé.
In progress.... Ha a fejlesztő magára tudja rántani a feladatot és ezt a rendszer jelezni is képes az azért jó, mert folyamatában látjuk, hogy éppen ki, min dolgozik.
Verzió/build/sprint.. alapú csoportosítás. Ez már a tervezéshez közeli funkció. 
Becslés. Szerintem lényegi elem. Lehetővé teszi, hogy a terhelést jobban elosszuk. Például ha van sprint alapú csoportosítás, akkor ezzel együtt pontosan be tudjuk osztani a fejlesztők idejét és lehetőség szerint annyi feladatot oszthatunk ki, amennyi az adott (rész)határidőbe belefér. A becslés vs valóságban a feladattal töltött idő szintén fontos metrika. Hatékonyságnövelést csak akkor tudunk elérni, ha van egy olyan alapunk amihez képest szeretnénk jobbak lenni.
Code repository összeköttetés. Elsősorban több ágon történő, vagy szétosztott fejlesztési csapatoknál kihasznált funkció.
Non plus ultra: build/deploy folyamattal való összekötés. Milyen egyszerű lehetne az élet: pár klikk és összeáll a release levél, hogy pl. adott sprint alatt milyen feladatok készültek el, azok melyik ágon és milyen státuszban vannak. Majd újabb egy mozdulattal azt mondhatnánk: Mehet!

Tehát jóval több, mint első látásra gondolnánk.
És akkor még nem néztük meg az alapegységektől elvárt működést, illetve a teljes workflowt... Ami késik, nem múlik. Lesz még erről post.....
Mint ahogy a nagyobb online elérhető alkalmazásokról is.

Új Széchenyi Terv és csökkentett bürokrácia

Ma reggel kivételesen bekapcsoltam a tv-t, kb fél 8-kor. M1 - Ma Reggel c. műsor.
Épp valami főokos nyilatkozott az Új Széchenyi tervről. Többek között elhangzott az, h sokkal szélesebb körnek tudnak már segítséget nyújtani, illetve a pályázatok előkészítése jobb lett - a bürokráciát csökkentették.
Ennek örömére kedvet kaptam, hogy körbenézzek Új Sz. terv háza táján. Random letöltöttem egy kkv-k és mikrovállakozások komplex technológia fejlesztése témakörben kiírt pályázatot.
És kb. agybajt kaptam.

1. a pályázati kiírás 6. oldalán már sikerült megtudnom, hogy mire is írták ki
2. a 2. oldalon viszont már megtudtam: vállalni kell, hogy "A projekt befejezési évét közvetlenül követő 2 üzleti év átlagos éves személyi jellegű ráfordításainak (sic) növekednie kell a támogatási összeg 5 %-ával a bázisévhez (beadást megelızı üzleti év) képest." Valamint azt is, hogy nem csökkenhet a statisztikai létszám.
   Így is lehet garantálni a legalább infláció követő bérezést. 
3. Ténylegesen nagyon rövid a kötelező beadandókat részletező fejezet. Kivették a pályázati felhívásból és áttették a pályázati útmutató nevű doksiba. Ezzel tényleg csökkent a bürokrácia - ja, persze.

Na igen, ez olyan magyar módi :(

flickr

"Megfejtettem" a flickr.com névválaszátását. Vagy lehetséges egyik magyarázatát. Nem mondanám, h sokat gondolkodtam rajta, inkább csak beugrott :)

Kimentem az erkélyre (5. emelet) és innen tiszta időben látni Budapest fényeit. Ma este tiszta az idő és jó messzire ellátni. Automatikusan ugrott be az ilyen esetekben használatos "flickering lights of the city" anglicizmus. Arra a helyzetre szokták alkalmazni amikor tiszta időben a távolabbi fények változó erősséggel, egyfajta felvillanásokkal láthatóak. 

Lehet ez egy magyarázat a flickr-re: ők sem a statikus böngészés és tematizálást helyezik előtérbe, hanem a felvillantásokat. Felhasználó feltölt egy képet, megosztja, elküldi, beköti máshova, másvalakinek, hogy lássa. 

Persze tovább kellett fejleszteni és lett benne tematizálásra lehetőség. De mint alapötlet még mindig a hirtelen megmutatom és megosztom másokkal koncepció a lényeg.