Projektmenedzsment a szemnek: post-it fal

Bár őszintén szólva a grid téma kapcsán arra számítottam, hogy a hazai webdizájnerek, sitebuilderek közül 3-nál többen elmondják szakmai véleményüket, és ezzel egy elég fontos alapkérdésben láthatunk tisztábban, végül ez mégsem következett be. Igaz ugyan, hogy páran rámcseteltek, és privátban értekeztünk a témáról. De szerintem a problémakör azért több ingert kellett volna, hogy kiváltson. Mindegy. Aki esetleg utólag szeretne kommentelni, a postnál megteheti

Mindezek után bedobnék még egy témát, ami szerintem elég fontos ahhoz, hogy szó legyen róla. Sőt, akár kommentelésre is ösztönözzön.  

A téma egy kicsit a projektmenedzsment. Pontosabban annak a szoftveres, számítógépes részén túli világa. Én nemrégiben vezettem be a munkahelyemen a Kanban-táblához hasonló falra írós ticketelési rendet. Ha a Kanbant (lean módszereket) úgy magában nem is tartom minden tekintetben a világ leghatékonyabb projektszervezési módszertanának, de azt az elvet, hogy fizikailag is kerüljünk kapcsolatba feladatokkal (vagy azok reprezentációival) egy olyan szakmában, ami alapvetően elvont, mindenképpen jónak gondolom. 

kanban_tabla.png

Nagyon egyszerű whiteboard reprezentciót választottam a projekthez. Egyrészt a whiteboard úgy van feltéve a falra, hogy a projekt résztvevői mind rálássanak. Másrészről a négy fázisos verziót használom: egy ticket vagy várakozik, vagy folyamatban van, vagy elkészült, vagy pedig át van adva.

Amíg egy ticket nincs átadva, addig visszakerülhet bármelyik korábbi állapotba. Vagyis elkészült ticket is visszamehet a "folyamatban" oszlopba, és egy folyamatban lévő ticket is visszamehet "várakozik" státuszba. Ha azonban egy ticketet átadtunk, akkor az le van pecsételve. Haladni kell a többivel.

A postitekre a feladat rövid megnevezése mellett az adott tickethez rendelt komplexitás-szám van még ráírva. És az etapok különböző színű postitekre vannak írva. Így az is jól látszik, hogy mi az, ami régóta bent ragadt feladat, és mi az, ami újabb, és gyorsabban mozog a táblán. 

Néhány hete ezzel kapcsolatban kértem is a véleményeteket Twitteren. Egyetlen komoly és részletes válasz érkezett, mégpedig Szűcs Attilától (Arkon): 

Azt láttuk, hogy egy 60-70 fős cégnél már elég nagy energiát kell abba fektetni, hogy tudjuk, ki milyen projekten dolgozik, milyen összefüggések vannak a projektek között, és hogyan tud 60-70 ember egymást segítve gördülékenyen együtt dolgozni. Arra jutottunk, hogy kell egy átlátható, egyszerű roadmap. Mi ez a "csomagolópapír roadmap", miért kezdtük el használni? Hiszünk a lean megoldásokban, úgyhogy a futárunk vett az Ápiszban csomagolópapírt és Post-it-et (fontos, hogy valódi Post-it legyen, különben lefújja a szél a terveket!). Amit most láttok, az egy "publikus béta" roadmap, kb. 3 hónapja használjuk, szóval még van hova fejlődnie. A terveink szerint idővel eljutunk oda, hogy 4 negyedévre szól majd folyamatosan, egyelőre kb. év végéig látunk előre. Epic szintű (azaz 2-6 hét) között lefejleszthető feladatcsokrok vannak egy-egy cetlin. Minden kéthetes fejlesztési ciklus kezdetén és végén összegyűlik a csapat, és kipipálja az elvégzett feladatokat.

Ők amúgy 4 hónapja használják a postit falat, és pozitívumként azt emelik ki, amit én is meg tudok erősíteni: a tábla nemcsak azért jó, mert látható a munkanap bármelyik pillanatában, hogy hogyan állunk a feladatokkal, hanem egyszersmind mindenki (avagy: nem csak projekttagok) számára látható a fal. Így transzparens a munka. És ennek nagyon fontos hatása van a nyugodt munkavégzésre. 

kanban_tabla_arkon.png

(Kanban tábla az Arkon Zrt.-nél)

Azt is kiemelik az arkonosok, hogy sokkal kézzelfoghatóbbá válik, hogy hogyan haladnak egy adott sprinttel. Ezt is meg tudom erősíteni. Mindenki pontosan látja, hogy egy adott időpillanatban mennyire áll jól a sprint. 

Felsoroltak néhány problémát is: 

  • Jó lenne, ha lenne egy távolról is elérhető verziója. A területi képviselők például ritkán vannak az irodában, jó lenne, ha ők is látnák. Gondolkozunk egy webkamerán vagy valamilyen online eszközön.
  • Figyelni kell rá, hogy aktuális maradjon, még nem teljesen szoktuk meg, hogy heti gyakorisággal ránézzünk, aktualizáljuk. Időnként gyomtalanítani kell, ezt ez egyik kollégánk önként vállalta.
  • A függőségeket manuálisan kell kezelni (átteszünk egy cetlit, nem viszi magával a függőségeket automatikusan).
  • A felelősöket rá kell írni a cetlire.
  • Archiválásra jó lenne valamilyen megoldás, pl. lefotózni időnként.
  • Gyakran nehéz rövid, de pontos és közérthető elnevezésket írni a cetlikra. Ha nem sikerül, akkor "tolmács" kell a projekteket közelről nem ismerők számára.
  • Nem mindig egyértelmű, hogy egy téma "megérdemel-e" egy külön cetlit.
  • Jó lenne az összes roadmapet egy helyen látni, de ahhoz egy 4m magas fal kellene...

Az én legnagyobb kontrám az egésszel kapcsolatban az, hogy extra adminisztrációs feladatot ró minden munkatársra. Nálunk az a szabály, hogy mindenki maga írja meg a hozzá tartozó ticketeket postitre, és maga is teszi fel a táblára, és sajátmaga mozgatja a táblán. Ez kétségtelenül extra elfoglaltság. Hiszen a normál projektmenedzsment rendszerben is vezetni kell ugyanezeket. Néha lemaradoznak ticketek, nem mozognak át az új helyükre. És ez zavart tud okozni.

Ezzel együtt azt gondolom, hogy ez egy egyszerű és jó módszer arra, hogy egy random pillanatban is elég jó képet kapjunk arról, hogy ki min dolgozik, hol tartunk a projekttel, mennyire tartható a határidő. Ráadásul mindezt úgy, hogy sem határidők, sem időpontok nincsenek a táblára írva. 

Szűcs Attilának pedig még egyszer köszönet a részletes és érdekes leírásért. 

Ti használtok hasonló megoldásokat? Ha igen, mi a véleményetek? Ha nem, miért nem próbáltátok eddig ki?

Címkék: projektmenedzsment kanban whiteboard kanban tábla post-it fal agilis módszertanok
2012.09.03. 19:43. írta: hírbehozó

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Az extra adminisztrációhoz: mindenki a saját területéért felel, és ügyesen sprintek indulásakor az egész csapat odaáll a falhoz, ha valami elkészült, azt ünnepélyesen kipipáljuk, illetve megnézzük az új elemeket. Így az egésznek egyáltalán nincs adminisztrációs hangulata, sokkal inkább egy belső szeánszra hasonlít.
Egy kis pontosítás a falunkhoz:
A cetlik, ilyen sok együttműködő csapat esetén már nem tennivalókat képviselnek, hanem gyakran többhetes ügyeket (epic -eket). Valójában egy roadmap fal és nem kanban fal.

A kanbanos cetlifal egy (akár 6-8 fős) csapat esetén még jól tud működni, viszont ennél több ember együttműködése esetén csavarni kell a zoomon hogy áttekinthető legyen.

A csapatok Jira -t használnak (egy igen népszerű és sokat tudó agilis tool), azon belül is GreenHoppert. Ennek legfrissebb (6 -os) verziója már nagyon kézreálló Kanban vagy SCRUM falakat tud.

Léptékek nagyon leegyszerüsítve:
- task: max néhány órás tennivaló egy embernek (Jira)
- story: max néhány napos feladat egy csapatnak (Jira)
- epic: több hét - több hónap egy csapatnak (roadmap fal)
- cél: negyedév - év egy osztálynak (google sites és fal)
- vízió: sok év a vállalatnak (google sites)
Remek kis cikk! Tényleg hatásosak ezek de elég nehéz bevezetni őket. Én az elmúlt évben több volt munkahelyemen is próbálkoztam velük sajnos sikertelenül. Whiteboard, cetlik, webes megoldások... mind elhasalt. A csapat nem igazán volt vevő rá. Kisebb létszámnál már lehetetlen betartatni egy kritikus időn túl, nagyobban meg leszavazzák amint megtudják, hogy ez extra adminisztrációs feladatokkal jár és be kell őket tartani. De jó látni, hogy idehaza van ahol működik és tudják alkalmazni ezeket a módszereket. ;)
én egy kisebb csapatot irányítok a munkahelyemen, de mivel a vezetőimet a fent már említett okokból nehéz rávenni egy komplexebb stratégia alkalmazására, így magamnak vezetgetem és updatelem a projek(jeim). nagyjából a fenti elvekhez hasonlót alakítottam ki magamnak, a nyomon követésre a zendone-t használom, a háttérinfók tárolására pedig az evernote-ot. ha jól keresek és tag-elek folyamatosan, akkor egy-egy jó kereséssel rögtön látom vizuálisan, h melyik projektben hol állok, mi a következő lépés és mikorra kell, illetve, h kinél van kint egy adott részfeladat amire várok.
és ugye evernote-nál (is) megoldható lenne az, h mások is lássák, h hol állok, csak ez már egy felsőbb szintű döntés lenne a cégnél…
az evernote-ban a különböző notebookok a projektek, maguk a notes-ok az adott feladatok, a tag-ek pedig jelzik, h hol áll az adott feladat, ill. a kollégáknak van tag-jük, h ha náluk áll. az egész meg be van vezetve zendone-ba, ahol látom a határidőket.
Oh, nalunk a blig.hu devben, millio eve (2009), meg Bandeszekkal kezdtuk el a postitezest - scrummal egyutt. A blog.hu admin 2 dev hasonlokepp zajlott 2011ig.
De ismet visszaterunk a falhoz pont a public-manifest miatt.
Moblirol kuldve ennyi fert be.
@viteez: Az Evernote-ot én is használom. Ez az egyetlen egy ami megmaradt a többi közül. Van még pár hasznos megoldás de igazán egyik sem válik be huzamosabb ideig mert lanyhul a figyelem, lazul a fegyelem és szétesik az egész. De az Evernote a legjobb alkalmazás amit az utóbbi pár évben használtam. Én már mindent abban tárolok és a tag-eknek hála tényleg könnyebb a használata. Projekteknek, témáknak pedig külön jegyzetfüzeteket lehet benne létrehozni.
Szomoru hallani, hogy hasonlo jol mukodo rendszereket otthon ilyen nehez bevezetni. Eddig ket cegemnel hasznaltuk az emlitett rendszert es egyik sem az az 5 fos ceg.
ESz par tipp. Jira jo de azert elegge korlatozott egy bizonyos ido utan, foleg hogyha scrum rendszert hasznaltok. Probald meg a Hansoft-ot nekem sokkal inkabb bejott.
Mentalitasbeli problemakat velek felfedezni David es Vitees hozzaszolasaban. Egyfelol valoszinu azert nemsikerul meggyozni a beosztottakat es a vezetoket, mert nektek sincsen eleg nagy tapasztalatok abban, hogy ez gyakorlatban hogyan mukszik. Ezen nagyon egyszeru segiteni elegge sok szakirodalom van ezzel kapcsolatban ( Scrum rendszer vagy Agile) de biztos vagyok abban is hogy tovabbkepzesek is leteznek otthon erdemes elvegezni oket mert otthon meg mindig a papir sokkal tobbet szamit mint a tenyleges tapasztalat.
Azt ugyancsak erdemes megemliteni, hogy ez a tablara irogatasos rendszer csak akkor er sokat, hogyha a munkafolyamatok is ez alapjan epulnek fel.
Adminisztracios ido? Ugyan mar! Azt senki sem gondolhatja komolyan, hogy olyan sok ido felirni egy cetlire hogy aznap/azon a heten min is fogok dolgozni. Ha megis az lenne akkor ott sokkal komolyabb problemak vannak.
Barhol is dolgoztam azt tapasztaltam hogy nagyon rovid ido utan mindenki borzasztoan buszke arra, hogy a kiadott a feladatot megcsinalta atteheti a Done ala. Ha szamokat kellene mondanom akkor kb 30-50%-al nott a hatekonysag a csapaton belul. Arrol mar nem is szolok, hogy mennyi idot sporoltunk meg azzal, hogy mindenki pontosan tisztaban volt azzal, hogy ki min dolgozott es ezert egybol hozza fordult ha vmi kapcsolodo gondja, kerdese volt. Ugye ez az idomegtakaritas nem igazan merheto, csak erzekelheto. Vegul de nem utolsosorban ez a rendszer a vezeto szemszogebol a legtutibb, hiszen folyamatosan tisztaban van azzal, hogy ki hol all es igy sokkal pontosabb kepet tud adni a projekt egeszet nezve. Ezt ugye nem is kell reszleteznem, hogy mennyire jelentos.
Szemely szerint, hogyha valaha is hazaterek es vagy az iparagon belul helyezkedek el vagy sajat ceget inditok ez alap lesz. Ha a bevezetes es a vegrehajtas kovetkezetes akkor nagyon gyorsan hozza lehet szoktatni mindenkit.
- A cetlifal legjobb tulajdonsága, hogy fizikai korlátokat szab a túlbonyolított user storyknak. Mi a Jira plugint használjuk és gyakran megszalad a tolla a dizájnereknek.
- Kanbanban sprint? Érdekes.
- A Trello.com-t próbáljátok ki elosztott csapatok organizálásához. Joel Spolsky-ék csinálják.
- Még nem hivatalos, de szeptember 19.-én lesz Java User Meeting (JUM), ahol lehet hogy lesz előadás egy Scrum-eszközről.
Mi a cégünknél teljesen átálltunk a trello (www.trello.com) nevű rendszer használatára. Ugyanaz a funkciója, mint a kanban falnak, csak virtuális és rengeteg mindent tud még kiegészítésként. Sikerült kialakítani egy mindenki által használt és támogatott workflow-t, amivel managerként tényleg sokkal egyszerűbb dolga van az embernek a nap/hét végén. És a legnagyobb előnye, hogy ingyenes! :)
csak ajánlani tudom.

Mellette nálam evernote a jegyzeteknek, viteezhez hasonlóan notebook/projectenként és producteev a saját taskok-ra.
Számomra az ultimate solution a Trello. Magáncélra, céges vagy hobbi/pet-projekt menedzsmentre egyszerűen tökéletes.
Ajánlom elolvasásra a cikket a Trello "készítőjétől":
www.joelonsoftware.com/items/2012/07/09.html
És persze a bemutató/demo video:
www.youtube.com/watch?v=aaDf1RqeLfo
Én a pár hét múlva induló zöld mezős projektemben fogom kipróbálni ez a dolgot, én ebből próbálok dolgozni, ha tudtok még ajánlani valamit akkor írjátok légyszi.
www.adaptiveconsulting.hu/sites/default/files/KanbanEsScrum_MindkettobolALegjobbat_1.pdf
Sziasztok itt egy online eszköz amit szerintem hasznos lehet. Ami még pluszban pont az alkalmazásnak hogy lehet integrálni a google bácsival. www.symphonical.com
@Kamela: Én is csak ajánlai tudom a Trello.com-ot! Kiváló bármilyen projektre és ingyenes! (elméletileg az is marad, bár ezért simán adnék pénzt is) :)
Üdv!

Én ezt használom saját projekthez:
www.targetprocess.com/

A Kanban részét nem használom, de nekem nagyon bejön, hogy User Story alapján tudom csoportosítani a Task-okat (és ez mind a Kanban, mint a Scrum táblán úgy jelenik meg)
Nekunk a PivotalTracker muxik.
@Jatekfejleszto kisiparos: nekem nem nagyon van tapasztalatom más agilis projektmenedzsment eszközzel, de a JIRA nagyon jól testre szabható, mi kis nyomozással és beállítással az összes saját és speciális igényeinket be tudtuk rakni a munkafolyamatban.
A cégnél mi személyre szabott, és saját igények alapján továbbfejlesztett PHPCollab (NetOffice) nevű eszközt használunk, ami felett igencsak eljárt az idő és már töviről hegyire ismerjük a korlátait, de mivel igen rég használjuk, nehéz a váltás. Így marad a verejtékes és sokszor idegtépő munka. :|

A Trellot én is kipróbáltam. A Kanban táblája is könnyen használható, de nagy hiányossága volt, amikor néztem, hogy nem találtam benne olyan megoldást, ami az elszámolást, vagy az egy feladatra fordított idő rögzítését segítette volna.

Mivel magáncélra (is) kerestem PM megoldást így mindenképpen olyat szerettem volna, ami minden - a cégnél eddig felmerült-, és a magánjellegű igényeimet is kielégíti.

A nagy keresgélésnek az lett a vége, hogy elkezdtem magam írni egy alkalmazást, amit saját célra már a kezdetektől fogva használok. Cél volt, hogy a feladatokat folyamatokban tudjam kezelni (teendő-folyamatban-készre jelentett-ügyfélnél-lezárt), és ezeket vizuálisan, kanban táblában is lássam.

Persze ennek a saját megoldásnak is megvannak még a gyerekbetegségei meg a hiányosságai, pláne egy több éve, nagy csapat által fejlesztett alkalmazásokhoz képest, de a lendület és a fejlődés töretlen. :)

A PM-ről bővebben: evolutionsuite.hu/

(A keresgéléseim közepette viszont a több tucat külhoni megoldás mellett nem találtam szinte semmilyen magyar, még aktívan fejlesztés alatt lévő eszközt.)
@Mefi:
Jira tokeletes bugok kezeleseben. Persze mind minden programnak ennek is vannak hatarai, korlatai, bar ezeket en inkabb az emberi tenyezoben latom. Csak a felreertesek elkerulese vegett egy 20-30 de meg egy 50 fos fejlesztoi kornyezetben ezek a hibak soha nem fognak elojonni. De egy ennel sokkal nagyobb fejlesztoi kornyezetben mar igen. Az teny hogy nagyon szemelyre szabhato eszkoz, es rengeteg erdekes neha mar mar hasztalan dolgot is lehet vele csinlani.
Viszont pl egy scrum rendszernek pont az a lenyege hogy ne csak az adott szemely lassa a taskot amit el kell vegeznie vagy csak az aki watcherkent be van allitva, hanem barki. Na erre nem alkalmas a JIRA, hiszen nem is erre terveztek. Azon progikat amiket a tobbiek ajanlottak csak felszinesen ismerem ezert velemenyt mondani roluk nem lenne helyenvalo. Viszont a Hansoft-ot igen. Pont arra valo ami itt a lenyeges kerdes volt, hiszen ez pont arra lett kifejlesztve. Ugyancsak bovitheto, es nem okoz neki gondod, hogy egy nagyobb fejlesztoi csapatot is kiszolgaljon.
Joparszor megtapasztaltam mar a vezetes elore nem latasat azaz hogy olyan programmal kezdtek el dolgozni amit utana a fejleszto csapat egyszeruen kinott. Ilyen pl a Bug-track is. Egyszeruen sokkal tobb bug jott egy fejlesztes alatt mint ami a maximum kapacitasa volt. Egy ilyen szituacio egy fejlesztesnel rengeteg gondot okozhat. De vegyuk csak develop hozzaszolasat. Kepzeljuk el hogy egy progival kezdunk neki a fejlesztesnek. Azt azutan kinovi a csapat vagy kiderul hogy a megvaltozott korulmenyek miatt mar nem alkalmas arra amire hasznalni kivantuk. Egy valtas a fejlesztes kozepe vege alatt sokkal tobbe kerul ( es itt nemcsak a penzrol beszelek, hiszen az idotenyezo neha sokkal tobbet er) mintha eleve egy sokkal komplexebb progival kezdtunk volna neki a fejlesztesnek. Persze az sem szerencses hogyha megvesszuk a csili vili legjobb cuccot es csak 10%-at hasznaljuk ki. Ez a felsovezetes dontese, de a hatasa sokkal inkabb a csapaton csattan.
10 éve fejlesztünk projektmenedzsment szoftvert, mely webes és a megjelenő feladatok felülete nagyon hasonlít a cikkben is fotózott post-it táblára, gyakorltailag egy webes kanban táblánk van (ezért kaptam fel a fejem a cikkre).
A feladatok kezelését egy egyszerűen és jól paraméterezhető folyamatmotor adja, mellyel tetszőleges folyamatok írhatóak le. Két kiemelt képernyőnk a feladatkosár, melyen (sárga színű) postiteken megjelennek csoportosítva, hogy milyen feladataim vannak és mikor keletkeztek, illetve hogy milyen feladatokat kapott a csoportom (ezeket még nem vett senki magára), másik kiemelt képernyő a projektáttekintő, mely a feladatok "fejléce", (kék postiteken) nyomon követhető tetszőleges csoportosításban a futó projektek. Ezeken általában azt jelezzük (paraméterezhető a megjelenő adat), hogy ki a projekt felelőse, mennyi idő ment el már a megvalósításra, hol tart éppen a projekt, mi a zárás várható időpontja. A postitet kijelölve megnézhetőek az ügy során keletkezett feladatok, dokumetumok, hozzászólások.

Az ügyfeleinknek szállított rendszerekben legtöbbször összetett folyamatokat kell leírnunk (pl banki belső folyamatok), de előfordul olyan is, aki az említett todo-inprogress-done folyamatot alkalmazza.

Az ügyfelek fejlesztési megrendeléseinek nyomon követésére mi egy, a két véglet közötti folyamatmodellt alkalmazunk, melynek fő feladatai, állapotai a következőek:
1. feladatkiosztás (fejlesztő kijelölése, de a fejlesztő maga is leveheti magához)
2. terv készítés (az ügyben rögzített bejelentés alapján a fejlesztő leírja, hogy hogyan képzeli a megvalósítást)
3. terv jóváhagyás (a feladatot megkapva látom a fejlesztő tervét, melyet elutasíthatok, vagy megjegyzéssel láthatok el)
4. fejlesztés (a fejlesztő rögzíti, hogy miben történt a változás)
5. tesztelés (a tesztelő csoport megkapja a feladatot, ahol látja hogy mi volt az igény, mi a terv és melyik patchel tudja tesztelni a változtatást)
6. release kiadás (gyakorlatilag a patch küldése)
7. ügyfél megtudja, hogy megkapta a fejlesztést és nézze meg, hogy oké-e minden
8. számlázás (számlázásnál kiköpi a rendszer, hogy mennyi ráfordítás ment el az üggyel, illetve ha volt ajánlat külön, akkor az mennyiről szólt)

Természetesen számtalan ág ki van alakítva, melyek most nem lényegesek (pl tesztelés nem sikerül, visszakapja a fejlesztő a postitjét...stb)

Ezen felül egyes feladatcsoportok meghatározhatnak státuszokat az ügyhöz. Ezek a felületen könnyen csoportosíthatóak és láthatóak, hogy mik vannak "beérkezett", "fejlesztés alatt", "lezárt" státuszokban.

A post-itek kaptak még egy jópofa beállítható tulajdonságot: az elvégzetlen feladatok, ahogy öregednek, jól láthatóan gyűrődnek és sötétednek, mellyel ránézésre megállapítható, hogy ez a feladat már régi és még mindig nincs elvégezve.
A valós kanban táblán kellene pár tíz évet várni, hogy meglátszódjon rajta, hogy egy feladat régi ;D!
Két hete kezdtük el használni a táblát, üzemeltetési és fejlesztési projekt is egyben amin dolgozunk. Ezek a tapasztalatok:

- A csapat létszáma folyamatosan - egy napon belül - változik, így a WIP korlát túlságosan rugalmas
- A mcsv (munkacsoport-vezető) is több projekten dolgozik, így az esetleges WIP korlát ütközésnél nem mindig van jelen
- A feladatok több olyan forrásból érkeznek be, amivel gond van:
○ Problémások:
§ Email (amin az IT csapatvezető nincs rajta)
§ JIRA (nem nézi rendszeresen a JIRA-t az IT mcs vezető)
□ Ez már kezelve lett , minden felvett feladatról kapok értesítést (viszont sajnos a státusz váltásokról is, így rengeteg a JIRA levél…)
§ Személyes ill. "cetlis" kérés projektvezető, egyéb munkacsoport-vezető, munkacsoport-tag , ügyviteli dolgozó részéről
○ Ami rendben van
§ Emailes kérés - IT mcsvezető legalább cc-ben
§ Közös egyeztetés megbeszéléseken elhangzott feladat
§ Feladat kérése IT mcsv-n keresztül (kvázi bármilyen formában)
- 1-1 feladat nem rendelhető csak 1 erőforráshoz, így nehéz a WIP korlát betartása
○ Talán érdemes kisebb egységekre szedni (pl adott CR javítása - kell tesztelő/db szakember/fejlesztő)