Asana-alternatíva a projekttervezéshez

Ahol az Asana idővonala megszűnik ütemterv lenni

A projekttervezéshez való Asana-alternatíváról szóló cikkek többsége azzal kezdődik, hogy kijelenti: az Asanának nincs Gantt-diagramja. Ez nem igaz, és hamis előfeltevésből kiindulni rossz módja annak, hogy segítsünk bárkinek eszközt választani. Az Asanának van idővonal-nézete, amely sávokat rajzol egy vízszintes tengelyre, nyilakkal köti össze őket, a mérföldköveket rombuszként jelöli, és kérésre ki tudja emelni a kritikus utat. Egy kampányhoz, egy termékbevezetéshez vagy egy toborzási folyamathoz ez tökéletesen ésszerű tervezési mód.

Az őszinte kérdés más. Nem az, hogy létezik-e a diagram, hanem hogy áll-e mögötte tervezési modell, vagyis szabályok készlete, amelyeket a rendszer alkalmaz, amikor valami elmozdul. A modell nélküli diagram egy terv képe. A modellel rendelkező diagram egy terv. A különbség csak akkor mutatkozik meg, amikor a valóság elkezdi nyomni a dátumokat, ami általában a harmadik héten történik, nem a terv jóváhagyásának napján.

Amiben az Asana jó

Az Asana valóban jól teszi láthatóvá a munkát, és készteti az embereket a cselekvésre. A feladatoknak van felelősük, kommentjük és világos határidejük, az idővonal könnyen kezelhető, és a függő feladatok elmozdulnak, amikor az elődjük mozog. A függőségeket olyan nyelven írják le, amelyet senkinek sem kell megtanulnia, blokkol és blokkolva van, ezért a csapatok egy délután alatt átveszik az eszközt. Tíz embernek, akik egy nyolchetes kampányt visznek, ez nem kompromisszum, hanem pontosan annyi eszköz, amennyi a feladathoz kell. Minden összehasonlítás, amely mást állít, elad, nem tanácsot ad.

Érdemes észrevenni, hol fizetnek ezért az egyszerűségért. Minden képesség, amelyet az Asana kihagy az idővonalból, olyan, amely nehezebben tanulhatóvá tette volna a terméket, és felhasználóinak többsége számára ez a helyes csere. A kérdés az, mi történik azokkal a csapatokkal, akiknek nem az.

A pillanat, amikor a terv megszűnik magától újraszámolni

A fordulópont csendben érkezik. Egy beszállító a feltételezettnél két héttel későbbre erősíti meg a szállítást, és a projektvezető elmozdít egy feladatot az idővonalon. A közvetlen utód követi, mert azt a kapcsolatot érti. Aztán a vezető észreveszi, hogy a kötelező kéthetes érlelési időszak után ütemezett átvételi tesztelés most túl korán kezdődik, mert a feladatok közötti szünet sosem volt szabály, csak üres hely a diagramon. A szomszédos projekt feladata, amelynek e szállítás után kellett volna indulnia, egyáltalán nem mozdul, mert a két projekt nem tud egymásról. Fél órával később a vezető kézzel húzgálja a sávokat, és táblázathoz igazítja a dátumokat.

Ez az a pillanat, amikor az ütemterv megszűnik modell lenni. A terv többé nem valami, amit a rendszer tart karban, hanem valami, amit egy ember tart karban, és ez az ember lesz az egyetlen hibapont. Minden újratervezés órákba kerül, minden újratervezésre fordított óra egy óra, amit nem a valódi problémára fordítottak, és a harmadik vagy negyedik iteráció után az emberek egyáltalán abbahagyják a terv frissítését, mert a ráfordítás már nem térül meg. Az elhagyott terv rosszabb, mint a semmilyen terv, mert még mindig jelentések készülnek belőle.

Öt jel, hogy kinőtte az Asana tervezését

E jelek egyike sem a csapat méretéről vagy a költségvetésről szól. A munka alakjáról szólnak, ezért futhat beléjük egy tizenkét fős mérnökcsapat, miközben egy hatvan fős marketingosztály soha. Ha kettő vagy több leírja a projektjeit, a korlátja a tervezési réteg, nem a funkciók száma.

Munkanapokban tervez, nem naptári napokban. Egy csütörtökön kezdődő ötnapos feladatnak a következő szerdán kell befejeződnie, és egy közbeeső ünnepnapnak további egy nappal ki kell tolnia a véget. Ha az időtartamai csendben tartalmazzák a hétvégéket, minden becslés beépített hibát hordoz, amely egy több hónapos tervben halmozódik.

A terv egyes szünetei fizika, nem preferencia. A beton köt, a bevonatok száradnak, egy validációs időszak fut, egy felmondási idő lejár, egy hatóságnak harminc napja van a válaszra. Ezek nem feladatok, amelyeket valaki elvégez, hanem intervallumok, amelyeknek két feladat között el kell telniük. Az ezeket kifejezni nem tudó csapatok „jóváhagyásra vár” nevű helykitöltő feladatokat találnak ki, ami beszennyezi a feladatlistát és félrevezet minden rá épülő jelentést.

Az egyik projekt ütemterve a másikét hajtja. Abban a pillanatban, amikor az infrastruktúra-projekt egy szállítása a migrációs projekt indulásának feltétele, és mindkettőt külön kezelik, valaki a fejében tartja ezt a függőséget. A memória nem küld értesítéseket, és nem éli túl a szabadságot.

Megkérdezik, mennyire sodródott el a projekt az eredeti tervtől. Nem azt, hogy mik a jelenlegi dátumok, hanem hogyan viszonyulnak ahhoz, amit jóváhagytak, és miért. Mentett alapterv nélkül az őszinte válasz az, hogy senki sem tudja, és az irányítóbizottság prezentációjában keringő verzió rekonstrukció.

Az ütemtervnek kettőnél több szintre van szüksége. Szakaszok, amelyek etapokat tartalmaznak, amelyek feladatokat tartalmaznak, ahol a haladás automatikusan felfelé összegződik, és minden szintnek saját dátumai vannak. A szakaszcímekkel ellátott lapos lista a képernyőn hasonlónak látszik, és teljesen máshogy viselkedik, amikor a terv változik.

A függőségtípusok és miért dönti el szemantikájuk a tervet

A függőség nem két sáv közé húzott vonal. Szabály, amelyet a rendszer minden alkalommal alkalmaz, amikor bármelyik vég elmozdul, és a kapcsolat típusa ennek a szabálynak a tartalma. Ezt a részt a legtöbb eszközösszehasonlítás átugorja, mert a „feladatfüggőségek” mellett pipát mutató táblázat elrejti a különbséget a nyilakat újrarajzoló és a dátumokat újraszámoló rendszer között. Mind a FlexiProject, mind az Asana támogatja a négy szabványos típust, így az érdekes kérdés az, mi veszi körül őket.

A szemantika helyes eltalálása nem öncélú pontosság. Ez dönti el, hogy egy projektvezető három másodperc alatt válaszol-e a „ha ez egy hetet csúszik, mikor fejezzük be” kérdésre a diagramra pillantva, vagy három óra alatt a terv újraépítésével. Ahol több projekt verseng ugyanazokért az emberekért, ez a különbség dönti el, hogy megtörténik-e egyáltalán az újratervezés.

BK, KK, BB és KB a gyakorlatban

A befejezés-kezdés mindenhol az alapértelmezett, és a szekvenciális munka nagy részét lefedi: a falat fel kell építeni, mielőtt kifestenék. A kezdés-kezdés olyan munkát ír le, amely közös kiváltóból párhuzamosan fut, például a dokumentációt, amely a fejlesztés kezdetének pillanatában indul, és nagyjából vele lép. A befejezés-befejezés olyan munkát ír le, amelynek együtt kell landolnia, mint a felhasználói képzés, amelynek készen kell lennie a rendszer élesítésének napján, függetlenül attól, mikor kezdődött. A kezdés-befejezés ritka, és leginkább átadásoknál jelenik meg, ahol a régi rendszert csak akkor lehet kikapcsolni, ha az új már működik.

Aki komolyan épít ütemterveket, legalább az első hármat használja, az érett projektszervezetek pedig mind a négyet használják, hogy pontosan modellezzék a valóságot, ahelyett hogy mindent befejezés-kezdés kapcsolatok láncába kényszerítenének. Ha alaposabb végigjárást szeretne kidolgozott példákkal, külön írtunk a Gantt-diagramon lévő feladatfüggőségek típusairól.

Fix késleltetés: a napok, amelyeknek egyszerűen el kell telniük

A FlexiProjectben minden kapcsolat hordozhat napokban kifejezett fix késleltetést. A függőség ekkor azt jelenti, hogy „kezdd ezt a feladatot négy nappal az előző befejezése után”, és a négy nap a szabály része, nem pedig egy szünet, amelyet valaki szemre becsült a diagramon. Amikor az előd mozog, a késleltetés vele mozog, automatikusan, anélkül hogy bárki emlékezne rá, hogy ott volt.

Az üzleti hatás az, hogy a technológiai korlátok megszűnnek az emberek fejében élni. Egy érlelési időszak, egy hatósági felülvizsgálati ablak, egy kötelező karantén a gyártási tételek között vagy egy szerződéses felmondási idő a terv logikájának részévé válik. Senkinek sem kell hamis feladatot létrehoznia, hogy nyitva tartsa a helyet, senkinek sem kell elmagyaráznia egy kollégának, miért nem szabad két sávot összetolni, és semmilyen újratervezés nem tudja csendben megszüntetni azt a korlátot, amelyet a fizika vagy egy szerződés ír elő. Az olyan projektekben, ahol egy kihagyott sorrend átdolgozást jelent, nem pedig egy késői e-mailt, ez a különbség egy megbízható terv és egy kétszer ellenőrizendő terv között.

Kemény kapcsolatok: amikor a kapcsolatot nem szabad megtörni

A FlexiProject ezenfelül megkülönbözteti a kemény kapcsolatokat, amelyeket a feladatpanelen két egymásba kapcsolódó gyűrű jelöl. A kemény kapcsolat azt jelenti, hogy a kapcsolt elemet nem lehet kézzel elhúzni az elődjétől. A rendszer nem engedi, hogy a felhasználó csendben megtörje a sorrendet egy sáv elmozdításával a diagramon, ami korlátozónak hangzik, amíg nem látott ütemtervet hat hónapnyi jó szándékú kézi módosítás alatt leromlani.

Ez ott számít a legtöbbet, ahol az ütemterv megosztott dokumentum, nem pedig egyetlen ember fájlja. Egy nagy projektben többen szerkesztik a tervet, és mindegyiküknek van helyi oka valamit elmozdítani. A kemény kapcsolat kódolja a különbséget egy olyan sorrend között, amely tervezési feltételezés, tehát vita tárgya, és egy olyan sorrend között, amely kemény korlát, tehát nem. A projektvezető abbahagyja a terv kézi felügyeletét, és elkezd rá támaszkodni, ami eleve a tervezőszoftver teljes lényege.

Projektek közötti függőségek: a réteg, amely az Asanából hiányzik

Egyetlen projekten belül a függőségek kényelem. Projektek között a különbséget jelentik egy program és egymással nem összefüggő tervek mappája között. A FlexiProjectben egy kapcsolat összekötheti az egyik projekt feladatát egy másik projekt feladatával, így az infrastruktúra-szállítás, amely egy migráció feltétele, olyan kapcsolat, amelyről a rendszer tud, nem pedig egy megjegyzés valaki emlékeztetőjében. Amikor az egyik oldal dátuma mozog, a másik projekt függő feladatai újraszámolódnak, és felelőseiket értesítik.

A gyakorlati következmény a döntéshozatalban jelenik meg, nem a diagramon. Mielőtt egy programvezető jóváhagyna egy változtatást az egyik projektben, láthatja, hogyan gyűrűzik ez a változás a többi projekten át, összehasonlíthatja az ütemtervet előtte és utána, és megítélheti az igen valódi költségét. Enélkül a költség hetekkel később külön meglepetések sorozataként bukkan fel, amelyek mindegyike helyi problémának látszik, és úgy is kezelik. A több éves programok pontosan ott vannak, ahol ez halmozódik, mert egy a harmadik hónapban könnyedén meghozott kéthetes döntés elmozdíthat egy éles indulási dátumot a huszadik hónapban.

Egy program összes feladata ráadásul egyetlen közös Gantt-diagramon látható, így a programvezető egy helyen látja a kapcsolatokat ahelyett, hogy státuszjelentésekből rekonstruálná őket. Az ezt igénylő csapatok általában a nehéz úton fedezik fel, miután először egy ismétlődő megbeszéléssel próbálták ugyanezt koordinálni. Ha az ön szervezete ebbe az irányba tart, a projektprogramok kezelésére szolgáló szoftverünk leírja, hogyan épülnek fel a programok.

A Gantt-diagram alatti modell

A kapcsolatok a tervezési modell legláthatóbb része, de nem az egész. Négy másik mechanizmus dönti el, hogy egy diagram tervként viselkedik-e, és ezek választják el a Gantt-diagram szoftvert egy idővonal-widgettől. Egyik sem egzotikus. Mindegyik olyasfajta dolog, amelyet csak akkor hiányol, amikor szüksége van rá.

Korlátlan WBS és haladás, amely magától összegződik

Egy szervezet projektjei óriási mértékben eltérnek méretben, egy kéthetes gyors győzelemtől egy több éves tőkeberuházásig, és egyetlen merev szerkezet nem szolgálhat mindkettőt. A FlexiProject nem szab határt annak, milyen mélyre nyúlik a feladatszerkezet, így egy projekt szakaszokra, etapokra, feladatokra és mérföldkövekre bontható olyan mélyen, amennyire szükséges. Egy kis projekt lapos maradhat egy maroknyi feladattal, míg egy beruházási projekt többszintű munkalebontási struktúrát hordozhat, és mindkettő ugyanazt a felületet használja.

A haladást csak az egyes feladatok szintjén viszik be. A szakasz haladását és a projekt teljes haladását automatikusan az alattuk lévő feladatokból számolja, így senkinek sem kell emlékeznie az összesítők frissítésére, mielőtt egy jelentés kimegy. Ez apró kényelemnek hangzik, és valójában adatminőségi mechanizmus: a portfólió szintű állapot ugyanazokból a számokból származik, amelyeket a csapat naponta karbantart, nem pedig egy összefoglalóból, amelyet valaki sietve gépelt be egy irányítóbizottság előtti este.

Munkanaptár nyers naptári dátumok helyett

Egy ütemterv, amely a hétvégéket munkaidőnek számolja, az első naptól kezdve hibás dátumokat állít elő. A FlexiProject a munkanaptárhoz viszonyítva számolja az időtartamokat, így egy munkanapokban kifejezett feladat ott landol, ahol valójában landol, ha a hétvégéket és a munkaszüneti napokat figyelembe vesszük. Ugyanez a logika áll az újrafelhasználható sablonok mögött: a sablonban lévő feladatok munkanapokban kifejezett időtartamot és függőségkészletet hordoznak fix naptári dátumok helyett, így egy projektkezdő dátum megadása automatikusan generálja a teljes ütemtervet.

Egy olyan szervezet számára, amely ismételten hasonló projekteket visz, itt omlik össze a tervezési idő. Ahelyett hogy a tervet a nulláról építené újra és minden dátumot újra levezetne, a projektvezető egy jóváhagyott szerkezetből indul, és azt igazítja, ami ebben az esetben valóban más. A projektsablon-modulunk pontosan ezért a mintáért létezik, és ez az oka annak is, hogy egy tapasztalt PMO által épített sablonok éveken át megőrzik értéküket.

Alapterv és a tervtől való eltérés

Amint egy terv jóváhagyást kap, a FlexiProject alaptervként tárolja. A Gantt-diagram ekkor az eredeti tervet a jelenlegi ütemterv mellett mutatja, így minden eltérés azonnal látható, nem pedig kikövetkeztetett. A rendszer a projekt befejezési dátumát is előrejelzi a jóváhagyotthoz képest, ami rendszerint az egyetlen szám, amelyet egy igazgatóság valóban akar.

Az érték itt kevésbé a mérésről és inkább a beszélgetés minőségéről szól. Egy projektvezető, aki meg tudja mutatni, mit hagytak jóvá, mi a helyzet most, és melyik döntés okozta a rést, más helyzetben van, mint aki csak a jelenlegi dátumokat tudja jelenteni. A vita eltolódik arról, hogy a projekt késik-e, arra, mit tegyünk a konkrét okkal, ami az egyetlen olyan verziója annak a beszélgetésnek, amely döntéssel zárul.

Kritikus út és tartalék

A FlexiProject automatikusan azonosítja a kritikus utat, és pirossal jelöli a Gantt-diagramon, így a projektvezető azonnal tudja, mely feladatok érdemelnek figyelmet. A gyakorlati haszon a rangsorolásban van. Egy kétnapos csúszás egy kritikus feladaton kétnapos csúszás az egész projekt számára, míg egy kétnapos csúszás egy tíznapos tartalékkal rendelkező feladaton zaj. E megkülönböztetés nélkül minden késést ugyanazzal a sürgősséggel eszkalálnak, ami mindenkit arra tanít, hogy figyelmen kívül hagyja az eszkalációkat.

Több párhuzamos folyammal, például az építéssel a szerelés és a dokumentáció mellett, a kritikus út az, ami megakadályozza, hogy egy vezető a rosszat optimalizálja. Ha a fogalom új a csapatának, mélyebben tárgyaltuk, mi a kritikus út és hogyan kezeljük.

Erőforrások a Gantt-diagramon: idő és kapacitás együtt tervezve

Egy ütemterv, amely figyelmen kívül hagyja, ki érhető el, kívánságlista. A FlexiProject közvetlenül a Gantt-diagramról mutatja az erőforrás-terhelést, így a projektvezető egy pillantással látja, mely emberek túlterheltek egy adott időszakban, és melyeknek van még kapacitása. A feladatok az idővonal mentén mozgathatók, miközben a terhelés változását figyeljük, ami az újratervezést szimulációvá változtatja találgatás helyett: a tervet a jóváhagyás előtt optimalizálják, nem azután, hogy valaki panaszkodik.

Ez bezár egy rést, amely folyamatosan felbukkan olyan szervezetekben, amelyek több projektet visznek ugyanazokkal az emberekkel. Egy új projekt tervezése azt jelenti, tudni, hogy a szükséges szakemberek már máshol le vannak-e kötve, és a legtöbb cégnél ez az ellenőrzés kézzel történik, egy táblázatban, elég hosszú késéssel ahhoz, hogy a válasz elavuljon. Amikor a kapacitás ugyanabban a nézetben van, mint a dátumok, a hamarabb befejezés és egy csapat túlterhelése közötti alku megszűnik láthatatlannak lenni, amíg valaki fel nem mond.

A késések ugyanolyan egyenességgel bukkannak fel. A lemaradt feladatok pirossal vannak kiemelve, így a projekt megnyitása elég annak megtekintéséhez, hol szükséges beavatkozás, anélkül hogy előbb jelentést generálnánk. Azoknak a szervezeteknek, amelyek tovább akarnak menni és az egész portfólión kezelni a rendelkezésre állást, az erőforrás-kezelő szoftverünk egyetlen projekten túl is kezeli a terhelést.

FlexiProject és Asana: a tervezési képességek összehasonlítva

Az alábbi táblázat szándékosan szűk. Csak a tervezést fedi le, és megadja az Asanának minden képességet, amellyel valóban rendelkezik, mert egy olyan összehasonlítás, amely alábecsüli a versenytársat, haszontalan az olvasó számára. Az együttműködés, a folyamatautomatizálás és az integrációk más beszélgetés, és több közülük az Asana az erősebb termék.

Olvassa a táblázatot szándék leírásaként, nem eredményjelzőként. Az Asana úgy épült, hogy bárki képzés nélkül tervezhessen, és minden fenti képesség, amelyet kihagy, olyan, amely nehezebben tanulhatóvá tenné a terméket. A FlexiProject valamivel meredekebb kezdést vállal cserébe egy olyan ütemtervért, amely nyomás alatt megtartja formáját. Hogy melyik csere a helyes, teljes egészében attól függ, hogy a projektjei büntetik-e a pontatlan tervet.

Egy ütemterv kimozdítása az Asanából a terv elvesztése nélkül

A migráció mechanikus része kevesebb időt vesz igénybe, mint az emberek várják. Egy ütemterv Excel-fájlból vagy Microsoft Project fájlból importálódik, hozva a feladatokat, a felelősöket, a rendelkezésre álló attribútumokat és, ahol van, a függőségstruktúrát, így az évek történelmi tervein ülő szervezeteknek nem kell újragépelniük őket. Az exportok a másik irányba futnak Excelbe, Microsoft Project XML-be, PDF-be és PNG-be, ami akkor számít, amikor egy alvállalkozó vagy egy auditor egy adott formátumhoz ragaszkodik.

Az a rész, amely valódi gondolkodást érdemel, az átépítés. Egy Asanában épített terv az Asana korlátai alatt épült, ami azt jelenti, hogy a várakozási időszakok valószínűleg hamis feladatok, a sorrend valószínűleg befejezés-kezdés kapcsolatok lánca, és a szakaszszerkezet valószínűleg szakaszcímek. Ennek hű átmásolása reprodukálja a korlátozást egy olyan rendszerben, amelynek már nincs. A jobb megközelítés az, hogy fogunk egy reprezentatív projektet, helyesen újraépítjük a logikáját a megfelelő kapcsolattípusokkal, fix késleltetésekkel ott, ahol az intervallumok kötelezők, és kemény kapcsolatokkal ott, ahol a sorrend nem alku tárgya, és az eredményt sablonként használjuk minden továbbihoz.

Az első menethez van egy ismerésre érdemes gyorsítás. A FlexiProject képes ütemterv-vázlatot generálni a projekt céljainak és követelményeinek leírásából, feladatokat, mérföldköveket, függőségeket és Gantt-diagramot előállítva, amelyet egy projektvezető ezután szerkeszt, nem pedig a semmiből épít. Nem helyettesíti egy tapasztalt tervező ítéletét, de megszünteti az üres oldal problémáját, amelyen a legtöbb újratervezési erőfeszítés elakad. Strukturált végigjárásért írtunk arról, hogyan építsünk projektütemtervet lépésről lépésre.

Gyakran ismételt kérdések

Támogatja az Asana mind a négy függőségtípust?

Igen. Az Asana támogatja a befejezés-kezdés, befejezés-befejezés, kezdés-kezdés és kezdés-befejezés típusokat, alapértelmezettként a befejezés-kezdéssel. Azok az állítások, hogy az Asana csak egyetlen függőségtípust kínál, számos összehasonlító cikkben megjelennek, és elavultak. Az Asana tervezésének lényeges hiányosságai máshol vannak: a fix késleltetésekben, a kemény kapcsolatokban, a munkanaptárakban, az alaptervekben és a projektek közötti kapcsolatokban.

Beállítható-e késleltetési idő a feladatok között az Asanában?

Nem. Az Asana nem engedi fix késleltetés csatolását egy függőséghez, így egy két feladat közötti kötelező intervallumot másképp kell ábrázolni, általában egy üres réssel az idővonalon vagy egy helykitöltő feladattal. Mindkét kerülő megoldás eltörik, amint az előd mozog, mert egyik sem hordozza magával a késleltetést. A FlexiProjectben a késleltetés magának a kapcsolatnak a tulajdonsága, és napokban van kifejezve.

Van az Asanának projekt-alapterve?

Nem. Az Asana nem tárol jóváhagyott verziót az ütemtervről összehasonlításhoz, így nincs beépített mód annak megtekintésére, mennyire sodródott el a jelenlegi terv attól, amit eredetileg megállapodtak. Az ezt igénylő csapatok általában egy pillanatképet tartanak egy táblázatban, amely egyszer válaszol a kérdésre, majd elavul. A FlexiProject a jóváhagyott tervet alaptervként őrzi, és a jelenlegi ütemterv mellett mutatja a Gantt-diagramon.

Össze lehet kapcsolni két különböző projekt feladatait?

Az Asanában nem. A függőségek egyetlen projekten belül maradnak, így egy projektek közötti sorrendet embereknek kell koordinálniuk ahelyett, hogy a rendszer tartaná karban. A FlexiProject megenged egy kapcsolatot különböző projektekhez tartozó feladatok között, újraszámolja a függő dátumokat, amikor bármelyik oldal mozog, és értesíti az érintett felelősöket, ami az alapkövetelmény egy program kezeléséhez egy párhuzamos projektek halmaza helyett.

Nehezebben használható a FlexiProject, mint az Asana?

Az elején többet kér, utána kevesebbet. Az Asanát úgy tervezték, hogy valaki már az első napon tervezhessen, részben azzal, hogy kihagyja az ebben a cikkben leírt fogalmakat. A FlexiProject elvárja, hogy egy projektvezető megértse a kapcsolattípusokat, a munkanaptárakat és az alapterveket, és cserébe karbantartja a tervet ahelyett, hogy egy embert kérne rá. Az egyszerű projektekkel rendelkező csapatok gyorsabbnak találják majd az Asanát. Azok a csapatok, amelyek projektjei büntetik a pontatlan tervet, általában az ellenkezőjét tapasztalják.

Egy Asana-alternatíva választása a projekttervezéshez valójában nem két eszköz közötti választás. Döntés arról, hogy a projektjeinek olyan tervre van-e szüksége, amelyet egy ember tart karban, vagy olyanra, amelyet egy rendszer tart karban, és ez attól függ, milyen drága, amikor a dátumok rosszak. Ha egy csúszott dátum áthelyezett megbeszélést jelent, az Asana jó válasz, és tervezőgépezet hozzáadása csak lassítaná a csapatot. Ha egy csúszott dátum tétlen alvállalkozókat, egy elszalasztott szabályozási ablakot, átdolgozást egy gyártósoron vagy egy kötbérkikötést jelent, akkor a diagram alatti modell nem részlet. Az a termék.

Ami egy teljes tervezési modellel változik, kisebb, mint amit egy funkciólista sugall, és nagyobb, mint amilyennek érződik. A kapcsolatok fix késleltetéseket hordoznak, így a kötelező intervallumok a terv részei, nem valaki emlékezetéé. A kemény kapcsolatok olyan sorrendeket tartanak, amelyek nem nyitottak tárgyalásra. A függőségek átnyúlnak a projekteken, így egy program programként viselkedik. Egy munkanaptár azt jelenti, hogy az időtartamok azt jelentik, amit mondanak, egy alapterv láthatóvá teszi az eltérést, és a kritikus út megmondja, mely késések számítanak valóban. Külön-külön ezek finomításnak látszanak. Együtt ezek a különbség percek alatti újratervezés és egy hétvégén át tartó újratervezés között.

Ha a két terméket egymás mellett szeretné látni a teljes terjedelemben, nem csak az ütemtervben, a költségvetéseket, kockázatokat, projektalapító okiratokat és portfólió-irányítást is beleértve, összeállítottunk egy részletes FlexiProject és Asana összehasonlítást. És ha a projektjei már az itt leírt határokat feszegetik, a leghasznosabb következő lépés fogni egyet közülük, helyesen újraépíteni az ütemtervét, és látni, mennyi kézi munka tűnik el.