project management címkével jelölt bejegyzések

Document/Knowledge Management: milyen rendszert?

Egy ideje keresgélek jó dokumentum/tudásmenedzsment rendszert. Kézenfekvő lenne azt mondani, hogy “csinálj egy wikit” (volt olyan is, hogy csináltunk wikit), de a helyzet nem ilyen egyszerű: van egy rakás (több száz) dokumentumunk (ezek nagy része restricted, tehát csak irodán belül elérhető, webről nem), amit rendszerezni szeretnénk, emellett ugye van egy adag wiki, és van egy adag “misc” tudás.

Kb. ezeket az igényeket írtam le a to be solution kapcsán: Bővebben…

Háztartási kanban.

2013-06-04 11.41.37

Ha belegondolunk, egy család/háztartás működése nem más, mint egy nagy continuous delivery. (És continuous improvement… de az megint egy más történet.) Ha vannak is nagyobb projektek, ezek igazából dependenciák,  minden leosztható kisebb termékekre. Szigorú időkontroll ritkán van, prioritások vannak, illetve esetenként a batchelésre való igény. Mondok példákat:

  1. Meg kell csinálni tavaszig a teraszon egy alsó korlátot, hogy Márti ne másszon ki a mostani korlát alatt (mert kifér).
  2. Fel kell szerelni egy falra egy polcot. Nem tudjuk még, melyik falra, esetleg kell még anyag is hozzá.
  3. Be kell rendezni a dolgozót. Kell még koncepció, kell bútor, aztán össze kell rakni.
  4. El kell vinni az Erdészt olajcserére, körépső diffi megnézésre, ilyesmi. Kell időpont, és nekem körészervezni az életemet.
  5. Kell venni pár nagyobb dolgot (bringát, számítógépet, stb.)
  6. El kell vinni Jul számítógépét szervízbe.

Ilyesmik. Látjuk, hogy vannak one-off elemek, vannak diszktér elemek amik egy ponton függnek egy resource-tól (pl. pénz, autó, barkácsáruház), vannak komplexebbek, vannak olyanok, amik teljes függőség-rendszert vonnak maguk után.

Lássuk tehát, egy pull alapú rendszer, amit erőforrások szerint kell tudni szűrni… hát hiszen ez egy kanban!

Csináltunk is egy táblát Bővebben…

Tanulóprojektek.

Munkám során gyakran találkozom emberekkel, ugyebár. Az említett emberek között sok olyan felvételiző van, akik teljesen pályakezdők, és fogalom nélkül vannak atekintetben, hogy mi fán terem egy projekt, mit csinál egy PM, egy BA (persze ez gyakori probléma az ipart sok éve űzők körében is, lásd még azt a tipikus magyar felfogást, hogy a PM a BA “fölött” van, és több évi BA tapasztalattal az emberből PM lesz), és hány lába van egy metodológiának.

A jelentkező hozzáállásától függően van, akit kidobok mint macskát sz különösebb kommentár nélkül hazaküldök, ne raboljuk egymás idejét; vannak viszont, akiken egyértelműen látszik, hogy szomjazzák ők a tudást, csak hát kikerültek a csodálatos magyar felsőoktatás langy öléből zéró tudással (ja nem bocs: ismerik a Kirchhoff-törvényeket és tudják, hogy minden építész/gépész/villanyos/műszakimanáger fasz (forráskartól függően ugye)), és azt se tudják, hogy merre keressenek.

Nekik szoktam mondani, hogy egyrészt persze

  1. olvasni, olvasni, olvasni, másrészt viszont
  2. csinálni, csinálni, csinálni! Bővebben…

PRINCE2 képzés gyorstapasztalatok.

screenshot.24-03-2013 16.12.48Csináltam egy PRINCE2 vizsgát. Magánérdeklődésből, magánköltségvetésből, magánidőben. Itt most nem azt fogom leírni, hogy milyen volt a vizsga (arra számtalan jobbnál jobb hely van), hanem azt, hogy miért imádom az angol szolgáltatóipart — ez esetben egy PM metodológia képzés vetülettel illusztrálva. Na jó, meg egy kicsit hogy milyen ez a kurzus.

Egyrészt fantasztikus a customer support. Én az ILX-nél vettem az online kurzust és a vizsga vouchert. Három esetben volt support requestem, és mindhárom esetben szinte azonnal (fél órán belül) élő ember válaszolt a kérdésemre — akkor is, ha azt a webes formon toltam be! És ami még fontosabb: nagyon segítőkészek, szinte helyetted gondolkodnak (látszik, hogy valami kemény support IVR backend lehet mögöttük, és ismerik a lehetséges ügyfélpanaszokat), és a válasz mindhárom esetben a megoldást nyújtotta, nem valami fórum linket, mint amikor az Amazon AWS-sel van valami bajod. Ha felhívod a telefonos supportot, 2 csörgés után ember veszi fel, akit egyből kérdezhetsz a konkrétumokról — és kenni fogja a témát, adni a releváns választ. Idehaza hol találsz ilyet? Bővebben…

Háztartási Agile, azaz delivery metodológiát a családba!

Újabb figyelmet érdemlő előadás a TED-en: Bruce Feiler – Agile programming — for your family.

(Átugrom a hosszúra nyúlt bevezetőt és megnézem a videót.)

Nem egy különösebben jó előadás (az előadó megtanult beszélni, de semmi extra, nem inspiratív, mint egy Guy Kawasaki session vagy egy ManBearPig kaliberű prezi; ráadásul az ingerküszübömet némileg meghaladó mennyiségű amerikai hozzáállás van benne a kezelhetetlen mértékű stresszről, amit a család jelent (wtf?) — az is igaz persze, hogy mi nem 4 gyereket menedzselünk), érdekes módon a visszajelzések több, mint 10%-a negatív (lefele mutató ujjacska). Ezen felül a kommentek alapján az emberek nagy része nem érti meg miről van szó, utánanézni meg ugye derogál… de hagyjuk is ezt a részét. Ami minket érdekel, az az előadás üzenete:

Agile-t minden családba!

Bővebben…

$action early, $action often.

Release early, release often.

Agilis, iteratív módszertanok kedvelt jelmondata ez, benne van egy csomó minden, amitől egy agilis metodológia jobb, mint a fél év előkészítés után valamit releaselő waterfall (már ahol… de ebbe most ne menjünk bele).

(Talán kevéssé ismert tény, hogy ez így először nem Agile módszertanban jelent meg, hanem Eric S. Raymond legendás könyvében, a Cathedral and the Bazaar-ban (itt):

Release early. Release often. And listen to your customers.

De ne kanyarodjunk el.)

Szóval fantasztikus, hogy mi mindennel működik (vagy legalábbis ad vicces eredményt) ez. $action bármi lehet, és egy csomószor értelmes, sőt, insightful eredményt ad (figyelem: egy csomószor nem!) Az embereimnek gyakran mondom (egyéb kedvelt szavamjárása mellett, mint pl. a “low hanging fruit”, vagy hogy “azon a hídon majd átkelünk ha odaérünk”), hogy “escalate early, escalate often”, amit persze könnyű abuzálni, melynek eredményeképp a PRINCE2-ben “manage by exception” néven futó, de egy csomó más metodológiában is alapérték elv könnyen sérül, viszont done right (pl. nevezett eszkaláció a megfelelő szintre/helyre ér), hasznos módja a meg-megakadó projekt előremozdításának. (És tegyük a szívünkre a kezünket: nem megakadó projekt nincs, a Nagy Projekt Dungeonmaster gondoskodik erről.)

De működik ez mással is, persze döntse el ki-ki maga, hogy viccesen vagy komolyan: act early, act often; fail early, fail often; wake up early, wake up often; ejaculate early, ejaculate often; és így tovább.

A nyelv remek kis játszótér, nem kell mindig mindent technológiai szükségszerűségből levezetni.

Oppa pm style.

screenshot.25-01-2013 13.12.44

Megtoltuk a hetet. (Megj.: ez egy tegnapi screenshot — obviously.) Eszembe jut ez az Atlassian infographic, 62 meeting per hó, hát én annyinak nagyon örülnék.

A mennyiség egyébként menedzselhető, arra kell odafigyelni, hogy 1 napnál többet azért ne várjak dokumentálással, meeting logok elkészítésével, stb. – illetve megnő a fingreszeléssel szembeni ellenszenv (ne feledjük, enterprise-ról beszélünk, ott nem triviális!), lévén hogy 2-5-8 perc “given back” aránylag óriási hatással bír.

Ps.: Gondoljatok bele, milyen baromi nehéz ezekből a pixeldobozokból kitalálni, hogy hova kéne épp mennem tárgyalni!

Appvasárnap… helyett.

Miért?

Ezer oka van annak, ahogy az aforizmabeli pap fogalmaz, de főleg prioritások változása miatt. Egyrészt le kell tennem egy PRINCE2 vizsgát, amire készülnöm kell, ami (engedjetek meg ennyi személyes vonalat) 2 gyerek és meló mellett nem triviális, másrészt az utóbbi időben felmerült pár dolog, ami elkezdett érdekelni – egyébként pont project management vonalon. (Főállásban ugyebár nem Android blogger vagyok.) Ezekkel foglalkozni szeretnék, beleásni magam kicsit, ehhez pedig szintén idő kell.

A teljes magyarázat az Androidportal.hu-n.