Asanához hasonló alkalmazások: mit érdemes nézni a feladatlistákon túl

Miért kezdenek a csapatok Asanához hasonló alkalmazásokat keresni

Az Asana jól csinálja azt, amire tervezték. Közös helyet ad a csapatnak a feladatoknak, a hozzárendeléseknek, a megjegyzéseknek és a fájloknak, gyorsan megtanulható, és az emberek tényleg használják, ami magasabb léc, mint amit a legtöbb szoftver megugrik. Amikor a csapatok alternatívákat kezdenek keresni, a kiváltó ok ritkán hiányosság. Inkább az változik meg, amit irányítaniuk kell: egy kampányokat koordináló csapat mostantól egy szerződéses értékkel bíró ügyfélbevezetést szállít le, vagy egy cég, amely négy projektet vitt egyszerre, most harmincat visz. A feladatok nem lettek nehezebbek; a felelősség igen.

Azt a pontot, ahol egy projektmenedzsment-rendszer nélkülözhetetlenné válik, érdemes pontosan megnevezni, mert ez dönti el, milyen eszközt kellene keresned. Valaki most azt kérdezi, mikor fejeződik be a projekt, mennyi maradt a költségvetésből, és hogy a márciusban szükséges emberek márciusban elérhetők lesznek-e. Ha a válaszod az, hogy „több rend kell a feladatokban”, az Asana-alternatívák piaca széles és nagyrészt felcserélhető. Ha a válasz az, hogy „projekteket kell irányítanunk, nem feladatokat”, ennek a piacnak a nagy része egyáltalán nem rólad szól.

Ahol egy feladatlista megszűnik terv lenni

Egy feladatlista dátumokat tartalmaz. Egy terv dátumok közötti kapcsolatokat tartalmaz. A különbség láthatatlan, amíg semmi sem változik, és teljes, amint minden megváltozik. Amikor egy beszállító a vártnál két héttel később erősít meg, egy feladatlistában átírhatod azt az egy határidőt; minden feladat, amely tőle függött, megtartja az eredeti dátumát, és a terv mostantól csendben hibás. Valakinek észre kell vennie, végig kell gondolnia a továbbgyűrűző hatásokat, és kézzel át kell írnia további tizenöt dátumot.

A tünetek felismerhetők: az állapotot a heti értekezleten emlékezetből rakják össze, ahelyett hogy a tervből olvasnák ki; az ütemtervet a feladateszköz mellett egy táblázatban vezetik; senki sem tudja megmondani, melyik csúszás fenyegeti valóban a határidőt; és a költségtúllépés egy számláról derül ki, nem egy előrejelzésből. Ezek egyike sem fegyelmezetlenség. Egy olyan eszköz, amelyet a „ki mit csinál” megválaszolására építettek, most a „megcsináljuk-e, és mennyiért” kérdésre kényszerül válaszolni.

Három eszközosztály ugyanazon keresés mögött

Szinte minden Asanához hasonló eszközlista három szoftverosztályt kever össze anélkül, hogy ezt kimondaná, és épp ezért a olvasók zavartabban jönnek ki belőle, mint ahogy beléptek.

• Feladat- és teendőalkalmazások a személyes és a kiscsapatos munkát rendezik: listák, táblák, emlékeztetők, egy közös nézet. Nem modelleznek függőségeket, költségvetéseket vagy kapacitást, és nem is törekszenek rá.
• Munkakezelő platformok ott helyezkednek el, ahol maga az Asana. Több nézetet, egyéni mezőket, automatizálásokat, célokat és csapatok közötti riportolást adnak hozzá. A tervezési rétegük többnyire egy idővonal: húzható dátumok, korlátozott vagy opcionális függőséglogikával.
• Projekt- és portfóliókezelő rendszerek a projekt mint objektum köré épülnek, amelyhez ütemterv, költségvetés, kockázatok, erőforrások, eredmények és jóváhagyási előzmény tartozik. A súlypont a terv és annak a tervhez mért teljesítése.

A FlexiProject projektmenedzsment-rendszer a harmadik osztályba tartozik. Ez a becsületes besorolás: ha a problémád egy zsúfolt feladattábla, akkor ez rossz válasz. Akkor válik jó válasszá, amikor a tervet, a pénzt és az embereket egyetlen objektumként kell irányítani, nem három táblázatként. A képességről képességre haladó összehasonlítás a FlexiProject és az Asana összevetésében ugyanezt a terepet fedi le erre az egy eszközre.

Nyolc képesség, amely elválasztja az Asanához hasonló alkalmazásokat

Vond ki az eszköz-összehasonlításokból a marketinget, és a gyakorlatban számító különbségek nyolc képességre szűkülnek. Mindegyik vagy valódi modulként van jelen, vagy hiányzik, és semennyi egyéni mező sem pótolja a hiányzókat.

A cikk további része egyesével veszi ezeket a sorokat, mert a táblázat azt mondja meg, mi létezik, nem azt, miért számít. Külön elmagyarázzuk, milyen egy jó alternatíva a projekttervezéshez.

Ütemterv, amely magától újraszámol, ha a dátumok elmozdulnak

Egy munkakezelő platformon az idővonal a dátumok vizualizációja, amelyet te tartasz karban. Egy projektrendszerben az ütemterv egy modell: leírod, hogyan épül fel a munka és hogyan függnek egymástól a részek, a modell pedig megmondja, mik a dátumok. Ez a különbség akkor válik kézzelfoghatóvá, amikor először közbeszól a valóság. Egy kulcsfeladat öt napot csúszik; egy modellalapú ütemtervben minden utána következő automatikusan eltolódik, a kritikus út újraszámolódik, és azonnal látod, hogy a záró dátum mozdult-e el, vagy a tartalék elnyelte a csúszást. A projektvezető dolga az lesz, hogy eldöntse, mit tegyen, nem az, hogy kiszámolja, mit jelent.

Korlátlan WBS a lapos feladatlista helyett

Egy szervezeten belül a projektek méretben vadul eltérnek. Egy folyamatjavítás hat hétig tart egy tucat feladattal; egy gyárberuházás három évig, több száz feladattal, fázisokba és szakaszokba rendezve. Egy eszköz, amely korlátozza a mélységet, arra kényszerít, hogy a nagyobb projektet több mesterséges „projektre” darabold, hogy beférjen, és onnantól a riportolás hibás, mert egyetlen objektum sem képezi le a valódi vállalkozást.

A FlexiProject projektütemterv-moduljának nincs beágyazási mélységkorlátja, így egy Quick Win maradhat lapos, míg egy több éves beruházás teljes munkalebontási struktúrát visel, mindkettő ugyanabban a felületen, és mindkettő ugyanabba a portfólióba riportol. Ugyanaz az ütemterv három nézetben érhető el, amelyek egyetlen adathalmazon osztoznak: egy feladatlista a részletekhez, a FlexiProject Gantt-diagramja a függőségek kezeléséhez, és egy Kanban-tábla a haladás követéséhez. Ez a bevezetés szempontjából számít, mert a projektvezető a strukturált nézetben dolgozhat, míg a csapat a számára ismerős táblán marad, anélkül hogy bárki egy második igazságmásolatot tartana karban.

Függőségek, késleltetés és kritikus út

Vonalat húzni két feladat közé nem ugyanaz, mint ki tudni fejezni, milyen kapcsolatról van szó. A FlexiProject a négy szabványos kapcsolattípust támogatja, így megmondhatod, hogy a teszt akkor indul, amikor a fejlesztés véget ér, hogy két munkaág együtt indul, hogy együtt kell befejeződniük, vagy a ritkább esetet, amikor az egyik feladat kezdete vezérli a másik végét. A fix késleltetés azokat a napokat fedi le, amelyeknek egyszerűen el kell telniük, és amelyeken senki sem dolgozik: a beton kötése, egy törvény által előírt véleményezési határidő, egy beszállító szállítási ideje. Ha ezeket a kapcsolaton lévő késleltetésként modellezed, nem álfeladatként, az ütemterv őszinte marad, mert a várakozási idő az előtte lévő feladattal együtt mozdul. A merev kapcsolatok megakadályozzák, hogy a kötés egy figyelmetlen húzástól felszakadjon, ami megvédi azokat a sorrendeket, ahol a sorrend műszaki vagy szerződéses követelmény.

E szerkezet fölött áll a kritikus út. Arra a kérdésre válaszol, amelyet minden irányítóbizottság végül feltesz: a hat csúszó dolog közül melyek fenyegetik valóban a határidőt. E számítás nélkül minden csúszás egyformán riasztónak tűnik, és a vezetés figyelme egyenletesen oszlik szét nagyon eltérő fontosságú problémák között. Az alatta lévő projektnaptár kezeli a munkaszüneti napokat és a távolléteket, így egy öt munkanapra ütemezett feladat nem emészt fel csendben egy hétvégét.

Felfelé összegződő haladás és azonnal látható csúszások

A legtöbb feladateszközben egy fázis készültségi százaléka olyasmi, amit egy ember begépel. Ez a szám becslés, a beírás pillanatában elavult, és ez az a szám, amely a bizottsági riportba kerül. A FlexiProject csak az egyes feladatok szintjén kérdez rá a haladásra, a szakaszokat, fázisokat és az egész projektet ezekből számolja, így a portfólió-nézetekben és a riportokban szereplő értékek felépítésükből fakadóan konzisztensek, nem fegyelemből.

A késésben lévő feladatok közvetlenül az ütemtervben piros kiemelést kapnak, így a projektvezető a projekt megnyitásakor látja a beavatkozást igénylő pontokat, anélkül hogy előbb riportot generálna. A probléma felmerülése és aközött, hogy valaki észreveszi, tátongó rés az, ahol az ütemtervet érő kár nagy része felhalmozódik, és ennek a résnek egy hétről egy pillanatra csökkentése megváltoztatja, mi javítható még.

Bázisterv: az a terv, amelyen valóban számon kérhető vagy

Kérdezz meg egy bázisterv nélküli csapatot, hogy késik-e, és megfontolt, őszinte és megcáfolhatatlan választ kapsz. Ez nem tisztességtelenség. Arról van szó, hogy a terv és a valóság végig ugyanaz a dokumentum volt: valahányszor egy dátum elmozdult, a terv is elmozdult vele, így bármely pillanatban a projekt pontosan időben van, egy tucatszor átírt ütemtervhez mérve.

A bázisterv megtöri ezt a hurkot. Amint az ütemterv és a költségvetés megvan, jóváhagyják és referenciapontként rögzítik, és onnantól a rendszer jelzi az eltérést aközött, amire elköteleződtek, és ami történik. A jóváhagyás a FlexiProjectben egy meghatározott útvonalon zajlik, nem egy nyomtatványon lévő aláírással, így nyoma marad, ki melyik verziót és mikor hagyta jóvá. Amit ezzel megveszel, az az idő: egy tizennyolc hónapos ütemterv második hónapjában négy napot késő projekt beszélgetés, míg ugyanaz a projekt a tizenhatodik hónapban hat hét késéssel felfedezve válság, amelynek nincs több lehetősége.

Projekt-költségvetés a befejezésig szóló előrejelzéssel

Egy „költségvetés” nevű egyéni mező a projektkártyán nem költségvetés-kezelés; egy szám, amelyet valaki időnként frissít, és amelyben a második hónapra már senki sem bízik. Egy projekt költségvetését kezelni azt jelenti, hogy nyomon követed a tervezett összegeket, a tényleges költést és a várható hátralévő költséget olyan részletességgel, amely megmutatja, honnan ered az eltérés.

Költségek, bevételek és a projekt eredménye

A projekt-költségvetés modul mindkét oldalról építi fel a költségvetést, költségekből és bevételekből, a szervezet igénye szerint csoportosított tételekkel. A bevételt termelő projekteknél a rendszer a tervezett eredményt, a tervtől való eltérést és a végső pénzügyi eredmény előrejelzését mutatja, nem csak a kiadási oldalt. Egy szakmai szolgáltatásokat nyújtó vagy mérnöki cégnél, ahol minden projekt szerződés, épp ez az a szám, amelyre a vezetés valóban rákérdez, és önmagában egy költségösszegből nem vezethető le.

A költségvetési tételek dinamikusan összeköthetők az ütemterv feladataival, így ha egy feladat dátuma változik, a megfelelő költségvetési tétel dátuma vele változik, és a cash flow mindig az aktuális tervet tükrözi. Minden tétel hordozhatja a pénzügy számára szükséges attribútumokat, beleértve a költséghelyet, a kiadás típusát, a kategóriát és a beszállítót, a megfelelő sorhoz csatolt számlákkal. A FlexiProject emellett integrálódik a könyvelési rendszerekkel, és behozza a projekthez kötött számlákat a dátumukkal, összegükkel, bizonylatszámukkal és beszállítójukkal együtt, ami megszünteti a kettős rögzítést, amitől a projektköltségvetések egyébként eltávolodnak a könyveléstől.

Miért a „mennyit költöttünk” a rossz kérdés

A tényleges költés a múltat írja le. Mire problémát mutat, a pénz már elment. A döntéseket megváltoztató kérdés az, mennyit költenek még a projekt befejezéséig, és megválaszolásához a tény mellett vezetett előrejelzés kell.

A FlexiProject minden költségvetési sorhoz egyszerre három értéket mutat: a tervet, az eddig elköltött összeget és a hátralévő költség előrejelzését, az ebből adódó eltéréssel. Az a projektvezető, aki a harmadik hónapban látja, hogy az előrejelzés tizenkét százalékkal meghaladja a tervet, választhat: újratárgyalja a hatókört, korán eszkalál, tartalékhoz nyúl. Ugyanez a vezető, aki csak a ténnyel dolgozik, a nyolcadik hónapban tudja meg, amikor az egyetlen maradék lehetőség az, hogy megmagyarázza. A pénzügy ráadásul olyan bontásban kérhet riportokat, amilyenre szüksége van, kategória, beszállító vagy időszak szerint, mindig aktuális adatokkal. Külön kifejtjük, mit jelent a projekt költségvetésének ellenőrzése a valóságban.

Kockázati nyilvántartás, amely egyetlen projekt fölött is működik

Egy feladateszközben a kockázatból címkével ellátott feladat lesz, vagy egy pont egy állapotdokumentumban, amelyet senki sem olvas el másodszor. A kockázati nyilvántartás más objektum: minden bejegyzésnek van valószínűség- és hatásértékelése, felelőse, választerve és előzménye, és az ütemterv mellett él, nem egy párhuzamos dokumentumban.

A FlexiProject kockázati nyilvántartása lehetővé teszi, hogy a bevezetéskor beállítsd a kockázati mátrix dimenzióit. Ez apró beállításnak hangzik, és gyakran ez az oka, hogy egy kockázati modul használatlan marad: egy szervezet, amely évekig három a háromhoz mátrixszal dolgozott, nem vezet be olyan rendszert, amely öt az öthöz beállítást rögzít, így a modult csendben feladják, és a kockázatkezelés visszaköltözik egy diára. Az ismétlődő kockázatokat sablonok kezelik, így egy új bevezetést kezdő csapat nem üres nyilvántartással indul, hanem egy összeállított alappal, amelyet ehhez a projekthez igazít. Ez a kockázatazonosítást a képzelet gyakorlatából a szervezet felhalmozott tapasztalatának átnézésévé alakítja.

Az egyes projekt fölött minden portfóliónak saját kockázati füle van, amely egy helyre gyűjti az összes projektje kockázatát. Ez felszínre hoz valamit, ami egyébként láthatatlan: három projektvezető egymástól függetlenül ugyanazt a beszállítói kockázatot kezeli, háromszoros erőfeszítést fordít rá, és három különböző következtetésre jut. Portfólió-szinten nézve ez a kockázat egy felelőst és egy választ kap, a kockázati riportok pedig lehetővé teszik egy új projektet kezdő csapatnak, hogy átnézze, mi fenyegette valóban a hasonló projekteket korábban. Bemutatjuk azt is, hogyan néz ki a gyakorlatban a projekt kockázatkezelése.

Erőforrás-terhelés, mielőtt elköteleződsz egy dátum mellett

A legnehezebb kérdés egy projektvezérelt szervezetben nem az, „mit kell megcsinálnunk”, hanem „ki csinálja meg, és ráér-e”. A feladatalkalmazások a terhelést hozzárendelések számaként mutatják, ami szinte semmit sem mond, mert nyolc kis feladat és egy háromhetes feladat hasonlóan néz ki, és egy ember hónapjának teljesen eltérő részét emészti fel.

A FlexiProject ezt erőforrás-kezelő szoftverként közelíti meg: személyenként és naponta modellezi a rendelkezésre állást, figyelembe veszi a szabadságokat és a távolléteket, és jelez, ha a tervezett terhelés meghaladja a rendelkezésre álló kapacitást. Ez megelőzi az ismert csapdát, amikor egy szakértő egyszerre bukkan fel tíz projekt tervében, minden terv külön-külön ésszerű, az összegük pedig lehetetlen. A terhelés közvetlenül a Gantt-diagramról látható: ahogy időben mozgatod a feladatokat, figyeled, hogyan változik a teher, ami a tervezést olyan szimulációvá teszi, amelyet a terv jóváhagyása előtt futtatsz, nem pedig utólagos felfedezéssé.

Az egyes projekt fölött a szervezet nézetet kap az összes projekt-erőforrásról a következő hónapokban, a szervezeti struktúra szerint lebontva. A PMO és a vezetés látja, mikor van szabad kapacitása bizonyos csapatoknak, ami két ismétlődő döntést ösztönből aritmetikává alakít: megpályázzák-e az épp az asztalra kerülő munkát, és mikor kezdjenek toborozni.

Projektalapokmány és sablonok, amelyek a te standardodat viszik

A legtöbb szervezetnek, amely komolyan visz projekteket, van standardja. Ez általában egy Word-sablonban, egy prezentációban és két tapasztalt ember fejében él, ami azt jelenti, hogy betartják, amikor ez a kettő jelen van, egyébként improvizálják. Egy eszköz, amely viszi a standardot, más ajánlat, mint egy eszköz, amely mellette áll.

A FlexiProject projektalapokmány-modulját komponensekből állítják össze, mindenféle programozás nélkül, így a dokumentum azt az elrendezést tükrözi, amelyet a szervezet több száz projekten át már finomított, nem egy szállító rögzített sablonját. Egynél több alapokmány-standardot is meghatározhatsz: K+F-projekteket a fejlesztéshez releváns mezőkkel, marketingprojekteket piaci megkülönböztetőkkel és csatornákkal, beruházási projekteket a technológia és a megtérülés mezőivel, miközben egy vállalati szintű mezőkészlet mindegyiknek közös marad. Épp ez teszi lehetővé, hogy a standardizáció túlélje a valósággal való találkozást, mert az osztályokat nem kényszerítik egy kompromisszumos dokumentumba, amely egyiknek sem felel meg.

Az alapokmány jelentős része magától kitöltődik: a mérföldkövek, a fő kockázatok és más elemek automatikusan az ütemtervből és a kockázati nyilvántartásból töltődnek be, így az alapokmány konzisztens marad az alapadatokkal. Az alapokmányok verziózottak és jóváhagyási útvonalakon keresztül hagyják jóvá őket, és minden jóváhagyott verzió nyomot hagy arról, ki és mikor hagyta jóvá. Ugyanez a logika terjed ki a FlexiProject projektsablonjaira, amelyek projekttípusonként csomagolják az ütemterv szerkezetét, a tipikus kockázatokat és a dokumentumelrendezéseket, így egy új projekt a szervezet felhalmozott gyakorlatából indul, nem egy üres képernyőről.

Portfóliók és programok: az egy projekt fölötti nézet

Amikor egy szervezet harminc, ötven vagy száz projektet visz, a hasznos kérdések megváltoznak. Vezetői szinten senki sem akarja tudni, mit csinál egy adott ember csütörtökön. Azt akarják tudni, mely projektek csúsznak, melyek fogyasztanak a tervezettnél többet, és a portfólió tükrözi-e még a stratégiát. A feladatszámokat összesítő irányítópultok ezek egyikére sem válaszolnak.

Ezt a rést a projektportfólió-szoftver zárja be. A FlexiProject dedikált stratégiai nézetet nyújt: a projektek ütemtervét mérföldkövekkel és azok állapotával, a tervhez való összevetést és a pénzügyi haladást minden projektre és a portfólió egészére. Egy projekt egyszerre több portfólióhoz is tartozhat, ami többet jelent, mint amennyinek hangzik, mert egyetlen informatikai beruházás gyakran egyszerre része egy technológiai portfóliónak és egy transzformációs programnak. A programok a fölötte lévő réteget adják hozzá: kapcsolódó projektek csoportjait a köztük futó függőségekkel, ami a legtöbb, több csapatot érintő szállítás töréspontja, mert minden terv belül koherens, míg az átadásokat e-mailben kezelik. A projektpontozás támogatja a mindezt megelőző döntést, a projektellenőrzések modul pedig a rendszerből érkező állapotot tartja fenn, nem egy telefonálgatós kör eredményét. Külön cikkben nézzük meg, mit nyújt egy Asana-alternatíva egy projektirodának.

Licencelés, nyelvek és hol vannak az adataid

Három szempont ritkán jelenik meg a funkció-összehasonlításokban, és rendre eldönti az eredményt, amint egy szervezet túllép a piloton.

Az első a licencmodell. A legtöbb rendszer minden felhasználóért hasonló díjat számol fel, így a szervezet teljes helyet fizet olyanokért is, akik csak azért nyitják meg az eszközt, hogy frissítsék a saját feladataikat és megnézzenek egy állapotot. A FlexiProject három szintet kínál a valós szerephez igazítva: teljes licencet a projektvezetőknek, a PMO tagjainak, a szponzoroknak és a döntéshozóknak; standard licencet az aktív résztvevőknek, akik haladást jelentenek és feladatokon működnek együtt; és ingyenes licencet azoknak, akiknek csak a saját munkájukra van rálátásuk. A szervezet dönti el az arányt, ami a tágabb csapat lefedésének költségét arányban tartja azzal az értékkel, amit ezek az emberek kapnak.

A második a nyelv. A FlexiProject felülete 28 nyelven érhető el, köztük angolul, németül, franciául, spanyolul, olaszul, hollandul, lengyelül, csehül, szlovákul, magyarul, románul, bolgárul, ukránul, svédül, dánul, norvégul, finnül, észtül, lettül, litvánul, szlovénul, görögül, portugálul, törökül, oroszul, indonézül, japánul és kínaiul. A felhasználói dokumentáció 11 nyelven érhető el, az oktatóvideók pedig lengyelül és angolul. Egy több országban leányvállalatokkal rendelkező csoport számára épp ez teszi lehetővé az egy standardot és egy rendszert, miközben mindenki a saját nyelvén dolgozik. A harmadik a telepítés: a FlexiProject a felhő mellett on-premises is elérhető, ami a szabályozott iparágaknak nem preferencia, hanem feltétel ahhoz, hogy egyáltalán szóba jöjjön.

Hogyan tesztelj Asanához hasonló alkalmazásokat anélkül, hogy elpazarolnál egy negyedévet

A funkció-összehasonlításnak mint kiválasztási módszernek rossz a hírneve, mert minden szállító oldala mindenre igent mond. Egy valódi projekten végzett kéthetes próba többet válaszol meg, mint egy hónapnyi demó, feltéve, hogy úgy állítod be, hogy a valóban eltérő dolgokat tesztelje. Tegyél az eszközbe egy élő projektet, ne egy mintaprojektet: végy egy már futó projektet a valós ütemtervével, embereivel és költségvetésével, és építsd fel újra. A súrlódás, amelybe ez alatt az újraépítés alatt ütközöl, ugyanaz a súrlódás, amelybe utána minden héten ütközni fogsz, és a gyakorlatban egyben képzésként is szolgál, mert aki a saját projektjén tanulja a rendszert, többet jegyez meg, mint aki kitalált adatokon végez gyakorlatot.

Aztán futtasd le a négy tesztet, amely elválasztja az osztályokat. Mozgass egy feladatot az ütemterv közepén egy héttel, és nézd meg, mi számolódik újra. Hagyj jóvá egy bázistervet, hajts végre egy változtatást, és nézd meg, látható-e az eltérés anélkül, hogy bárki kiszámolná. Vidd be a költségvetést a befejezésig szóló előrejelzéssel, és ellenőrizd, olvasható-e az eltérés. Rendelj hozzá két embert, akik máshol már le vannak terhelve, és nézd meg, figyelmeztet-e az eszköz. Ha egy eszköz átmegy ezen a négyen, a többi ízlés kérdése; ha megbukik rajtuk, semennyi egyéni mező sem zárja be a rést.

Végül légy tudatos abban, mit viszel át. A migráció az egyetlen pillanat, amikor olcsó hátrahagyni a kategóriákat, amelyeket senki sem használ, és a konvenciókat, amelyek az előző eszköz korlátainak megkerülései voltak. Vidd át a nyitott munkát, a szerkezetet, amelyet a jövőben szeretnél, és a történeti projekteket, amelyekből érdemes tanulni.

Gyakran ismételt kérdések

Mire használják az Asanához hasonló alkalmazásokat?

Az Asanához hasonló alkalmazásokat a csapatmunka egy közös helyen való szervezésére és követésére használják: feladatok, felelősök, dátumok, megjegyzések és fájlok. A legerősebbek az együttműködő és ismétlődő munkában, mint a marketing, az üzemeltetés és a támogatás. Ha a munkának függőségekkel bíró ütemterve, költségvetése és hozzárendelt erőforrásai vannak, egy projektmenedzsment-rendszer jobban illik.

Mi a különbség egy feladatalkalmazás és egy projektmenedzsment-szoftver között?

Egy feladatalkalmazás munkaelemeket és dátumokat tárol. Egy projektmenedzsment-szoftver modellezi a projektet: újraszámolja az ütemtervet, ha a dátumok változnak, a teljesítést egy jóváhagyott bázistervhez méri, követi a költségeket és az előrejelzéseket, kockázati nyilvántartást vezet, és kezeli az erőforrás-kapacitást. A gyakorlati teszt az, hogy egy feladat elmozdítása automatikusan elmozdítja-e mindazt, ami tőle függ.

Van az Asanának projekt-bázisterve?

Az Asana nem kínál eltéréskövetéses, jóváhagyott projekt-bázistervet. Az idővonala a terv aktuális állapotát tükrözi, így amikor a dátumok változnak, az eredeti elköteleződés már nem érhető el összehasonlításra. A PPM-osztályú rendszerek, köztük a FlexiProject, jóváhagynak és rögzítenek egy bázistervet, majd jelzik a közte és a tényleges teljesítés közötti eltérést.

Tudják-e az Asanához hasonló alkalmazások kezelni a projektköltségvetéseket?

A legtöbb nem, egy számot tartalmazó egyéni mezőn túl. Egy projekt költségvetésének kezelése soronként tervezett összegeket, tényleges költést és a hátralévő költség előrejelzését igényli, az ütemtervhez kötve, hogy a dátumok konzisztensek maradjanak. A FlexiProjectben a költségvetés lefedi a költségeket és a bevételeket, és egymás mellett mutatja a tervet, a tényt és a befejezésig szóló előrejelzést.

Mikor túl korai elhagyni az Asanát?

Ha a projektjeid rövidek, néhány emberrel futnak, nincs formális költségvetésük és külső határidős elköteleződésük, az eszközváltás folyamatot ad hozzá, kontrollt nem. A váltás jele szerkezeti: függőségek, amelyeket nem tudsz kifejezni, egy külön táblázatban vezetett költségvetés, és állapotértekezletek, amelyeket olyan információ rekonstruálásáért tartanak, amelynek már a rendszerben kellene lennie.

Mennyi ideig tart egy projektet kihozni az Asanából?

Egyetlen futó projekt újraépítése egy új rendszerben az ütemterv- és költségvetés-szerkezethez általában néhány órát vesz igénybe, és néhány napot, ha közben sablonokat és standardokat is definiálsz. A szervezeti szintű bevezetés kevésbé az adatokon múlik, inkább a döntéseken: melyik standard, mely sablonok, és ki mit hagy jóvá.

Az Asanához hasonló alkalmazások keresése többnyire eszközkérdésként indul, és arról szóló kérdésnek bizonyul, mit is irányít valójában a szervezet. Ha a válasz a csapat együttműködése egy közös munkán, a piac jól kiszolgált, és a fő lehetőségek közötti különbségek jórészt a felület és az ár kérdései. Ha a válasz elköteleződésekkel bíró projektek, a releváns képességek nem azok, amelyek az összehasonlító oldalakon feltűnnek: egy magától újraszámoló ütemterv, egy jóváhagyott bázisterv, amely láthatóvá teszi a csúszást, amíg még kicsi, egy előrejelzést tartalmazó költségvetés a kiadások összege helyett, egy kockázati nyilvántartás, amely egyetlen projekt szintje fölött működik, és egy erőforrás-kapacitás, amelyet ellenőrizhetsz, mielőtt dátumot ígérnél. A FlexiProject ezek köré épül, ami rossz választássá teszi egy rendezettebb feladattáblát kereső csapat számára, és jó választássá egy olyan szervezet számára, amelynek határidőkért és pénzért kell felelnie. A legmegbízhatóbb módja annak, hogy megtudd, ki vagy, nem egy funkciótáblázat, hanem két hét: végy egy valódi projektet, építsd fel újra, mozgass egy feladatot, és nézd meg, mit mond az eszköz.