Alternativa k Asaně pro plánování projektů

Kde časová osa Asany přestává být harmonogramem

Většina článků o alternativě k Asaně pro plánování projektů začíná tvrzením, že Asana nemá Ganttův diagram. To není pravda a vycházet z nepravdivého předpokladu je špatný způsob, jak někomu pomoci vybrat nástroj. Asana má zobrazení časové osy, které vykresluje pruhy na vodorovné ose, spojuje je šipkami, značí milníky jako kosočtverce a na požádání umí zvýraznit kritickou cestu. Pro kampaň, uvedení produktu nebo náborový proces je to naprosto rozumný způsob plánování.

Poctivá otázka je jiná. Ne zda diagram existuje, ale zda za ním stojí plánovací model, tedy sada pravidel, která systém uplatní, když se něco pohne. Diagram bez modelu je obrázek plánu. Diagram s modelem je plán. Rozdíl se ukáže teprve tehdy, když realita začne tlačit na termíny, což se obvykle stane ve třetím týdnu, ne v den, kdy je plán schválen.

Co Asana dělá dobře

Asana je skutečně dobrá v tom, aby byla práce vidět a aby lidé podle ní jednali. Úkoly mají vlastníky, komentáře a jasné termíny, časovou osu lze snadno upravovat a závislé úkoly se posunou, když se pohne jejich předchůdce. Závislosti jsou popsány jazykem, který nikdo nemusí studovat, blokuje a je blokován, a proto si týmy nástroj osvojí za jedno odpoledne. Pro deset lidí vedoucích osmitýdenní kampaň to není kompromis, je to přesně tolik nástroje, kolik úkol potřebuje. Každé srovnání, které předstírá opak, prodává, místo aby radilo.

Za povšimnutí stojí, kde se za tuto jednoduchost platí. Každá schopnost, kterou Asana z časové osy vynechává, by ztížila učení produktu, a pro většinu jejích uživatelů je to správný kompromis. Otázka je, co se stane s týmy, pro které tomu tak není.

Okamžik, kdy se plán přestane přepočítávat sám

Zlom přichází potichu. Dodavatel potvrdí dodání o dva týdny později, než se předpokládalo, a projektový manažer posune jeden úkol na časové ose. Bezprostřední následník se posune také, protože tato vazba je pochopena. Pak si manažer všimne, že akceptační testování naplánované po povinné dvoutýdenní době zrání teď začíná příliš brzy, protože mezera mezi těmito úkoly nikdy nebyla pravidlem, jen prázdným místem v diagramu. Úkol v sousedním projektu, který měl začít po této dodávce, se nepohne vůbec, protože oba projekty o sobě navzájem nevědí. O půl hodiny později manažer ručně tahá pruhy a porovnává termíny s tabulkou.

To je okamžik, kdy harmonogram přestává být modelem. Plán už není něco, co udržuje systém, je to něco, co udržuje člověk, a ten člověk se stává jediným bodem selhání. Každé přeplánování stojí hodiny, každá hodina přeplánování je hodina nevěnovaná skutečnému problému, a po třetí nebo čtvrté iteraci lidé přestanou plán aktualizovat úplně, protože se úsilí přestane vyplácet. Opuštěný plán je horší než žádný plán, protože se z něj stále generují reporty.

Pět signálů, že jste plánování v Asaně přerostli

Žádný z těchto signálů se netýká velikosti týmu ani rozpočtu. Týkají se tvaru práce, a proto na ně může narazit dvanáctičlenný inženýrský tým, zatímco šedesátičlenné marketingové oddělení nikdy. Pokud dva nebo více popisují vaše projekty, vaším omezením je plánovací vrstva, ne počet funkcí.

Plánujete v pracovních dnech, ne v kalendářních. Pětidenní úkol začínající ve čtvrtek by měl skončit následující středu a státní svátek uprostřed by měl konec posunout o další den. Pokud vaše doby trvání potichu zahrnují víkendy, každý odhad nese vestavěnou chybu, která se v několikaměsíčním plánu kumuluje.

Některé mezery ve vašem plánu jsou fyzika, ne preference. Beton tuhne, nátěry schnou, běží validační období, končí výpovědní lhůta, úřad má třicet dní na odpověď. To nejsou úkoly, které někdo vykonává, jsou to intervaly, které musí mezi dvěma úkoly uplynout. Týmy bez způsobu, jak je vyjádřit, si vymýšlejí zástupné úkoly typu „čekání na schválení“, což zaplevelí seznam úkolů a zavádí každý report na něm postavený.

Harmonogram jednoho projektu řídí harmonogram jiného. Ve chvíli, kdy dodávka v infrastrukturním projektu podmiňuje zahájení migračního projektu a oba jsou řízeny odděleně, drží někdo tuto závislost v paměti. Paměť neposílá upozornění a nepřežije dovolenou.

Ptají se vás, jak daleko se projekt odchýlil od původního plánu. Ne jaké jsou aktuální termíny, ale jak se srovnávají s tím, co bylo schváleno, a proč. Bez uloženého základního plánu zní poctivá odpověď tak, že to nikdo neví, a verze kolující v prezentaci pro řídicí výbor je rekonstrukce.

Harmonogram potřebuje více než dvě úrovně. Fáze obsahující etapy obsahující úkoly, s postupem, který se automaticky sčítá nahoru, a s vlastními termíny na každé úrovni. Plochý seznam se sekčními nadpisy vypadá na obrazovce podobně a chová se úplně jinak, když se plán změní.

Typy závislostí a proč jejich sémantika rozhoduje o plánu

Závislost není čára nakreslená mezi dvěma pruhy. Je to pravidlo, které systém uplatní pokaždé, když se pohne kterýkoli konec, a typ vazby je obsahem tohoto pravidla. Právě tuto část většina srovnání nástrojů přeskakuje, protože tabulka s fajfkou u „závislosti úkolů“ skrývá rozdíl mezi systémem, který překresluje šipky, a systémem, který přepočítává termíny. FlexiProject i Asana podporují čtyři standardní typy, takže zajímavá otázka zní, co je obklopuje.

Správně vystihnout sémantiku není přesnost pro přesnost. Rozhoduje o tom, zda projektový manažer odpoví na otázku „když se tohle o týden zpozdí, kdy skončíme“ za tři sekundy pohledem na diagram, nebo za tři hodiny přestavbou plánu. Tam, kde o stejné lidi soupeří několik projektů, tento rozdíl rozhoduje, zda se přeplánování vůbec uskuteční.

FS, SS, FF a SF v praxi

Konec-začátek je všude výchozí a pokrývá většinu sekvenční práce: zeď musí být postavena, než se natře. Začátek-začátek popisuje práci, která běží paralelně ze společného spouštěče, například dokumentaci, která začíná ve chvíli, kdy začíná vývoj, a zhruba s ním drží krok. Konec-konec popisuje práci, která musí dopadnout společně, třeba školení uživatelů, které musí být hotové v den spuštění systému, bez ohledu na to, kdy začalo. Začátek-konec je vzácný a objevuje se hlavně u předávek, kde starý systém lze vypnout teprve tehdy, když běží nový.

Kdokoli sestavuje harmonogramy vážně, použije alespoň první tři a vyspělé projektové organizace používají všechny čtyři, aby modelovaly realitu přesně, místo aby vše nutily do řetězce vazeb konec-začátek. Pokud byste chtěli podrobnější průchod s propracovanými příklady, psali jsme samostatně o typech závislostí úkolů v Ganttově diagramu.

Pevné zpoždění: dny, které musí prostě uplynout

Ve FlexiProject může každá vazba nést pevné zpoždění vyjádřené ve dnech. Závislost pak znamená „začni tento úkol čtyři dny poté, co skončí předchozí“, a ty čtyři dny jsou součástí pravidla, ne mezera, kterou někdo odhadl od oka na diagramu. Když se předchůdce pohne, zpoždění se posune s ním, automaticky a bez toho, aby si někdo pamatoval, že tam bylo.

Obchodní dopad je, že technologická omezení přestávají žít v hlavách lidí. Doba zrání, lhůta pro posouzení úřadem, povinná karanténa mezi výrobními šaržemi nebo smluvní výpovědní lhůta se stane součástí logiky plánu. Nikdo nemusí vytvářet falešný úkol, aby udržel místo otevřené, nikdo nemusí kolegovi vysvětlovat, proč dva pruhy nesmějí být stlačeny k sobě, a žádné přeplánování nemůže potichu odstranit omezení, které ukládá fyzika nebo smlouva. V projektech, kde zmeškaná posloupnost znamená předělávku, a ne opožděný e-mail, je to rozdíl mezi plánem, kterému lze věřit, a plánem, který musíte dvakrát kontrolovat.

Tvrdé vazby: když se vazba nesmí přerušit

FlexiProject navíc rozlišuje tvrdé vazby, označené v panelu úkolu dvěma do sebe zaklesnutými kroužky. Tvrdá vazba znamená, že propojený prvek nelze ručně odtáhnout od jeho předchůdce. Systém nedovolí uživateli potichu přerušit posloupnost posunutím pruhu v diagramu, což zní omezujícím dojmem, dokud jste nesledovali, jak se harmonogram během šesti měsíců dobře míněných ručních úprav rozpadá.

To má největší význam tam, kde je harmonogram sdíleným dokumentem, a ne souborem jedné osoby. Ve velkém projektu upravuje plán několik lidí a každý z nich má lokální důvod něco posunout. Tvrdá vazba zakóduje rozdíl mezi posloupností, která je plánovacím předpokladem, a tudíž otevřená diskusi, a posloupností, která je tvrdým omezením, a tudíž ne. Projektový manažer přestane plán ručně hlídat a začne se na něj spoléhat, což je vůbec celý smysl plánovacího softwaru.

Závislosti napříč projekty: vrstva, kterou Asana nemá

Uvnitř jednoho projektu jsou závislosti pohodlí. Napříč projekty jsou rozdílem mezi programem a složkou nesouvisejících plánů. Ve FlexiProject může vazba spojit úkol v jednom projektu s úkolem v jiném, takže infrastrukturní dodávka, která podmiňuje migraci, je vazbou, o níž systém ví, a ne poznámkou v něčím zápisu z porady. Když se termín na jedné straně pohne, závislé úkoly v druhém projektu se přepočítají a jejich vlastníci jsou upozorněni.

Praktický důsledek se ukáže v rozhodování, ne v diagramu. Než programový manažer schválí změnu v jednom projektu, může vidět, jak se tato změna šíří zbývajícími projekty, porovnat harmonogram před a po a posoudit skutečnou cenu souhlasu. Bez toho cena vyplave o týdny později jako řada oddělených překvapení, z nichž každé vypadá jako lokální problém a jako takové se řeší. Víceleté programy jsou přesně tam, kde se to kumuluje, protože dvoutýdenní rozhodnutí učiněné bezstarostně ve třetím měsíci může posunout datum spuštění ve dvacátém měsíci.

Všechny úkoly programu jsou navíc viditelné na jednom sdíleném Ganttově diagramu, takže programový manažer vidí souvislosti na jednom místě, místo aby je rekonstruoval ze stavových hlášení. Týmy, které to potřebují, to obvykle zjistí tvrdě, když se totéž nejprve pokusily koordinovat opakovanou schůzkou. Pokud vaše organizace míří tímto směrem, náš software pro řízení programů projektů popisuje, jak jsou programy strukturovány.

Model pod Ganttovým diagramem

Vazby jsou nejviditelnější částí plánovacího modelu, ale nejsou celý model. O tom, zda se diagram chová jako plán, rozhodují další čtyři mechanismy, a právě ony oddělují software pro Ganttův diagram od widgetu časové osy. Žádný z nich není exotický. Všechny jsou tím, co začnete postrádat, teprve když je potřebujete.

Neomezený WBS a postup, který se sčítá sám

Projekty v jedné organizaci se enormně liší rozsahem, od dvoutýdenního rychlého vítězství po víceletou kapitálovou investici, a jediná pevná struktura nemůže sloužit oběma. FlexiProject neklade žádný limit na to, jak hluboko struktura úkolů sahá, takže projekt lze rozdělit na fáze, etapy, úkoly a milníky tak hluboko, jak je potřeba. Malý projekt může zůstat plochý s hrstkou úkolů, zatímco investiční projekt může nést víceúrovňovou strukturu rozpadu práce, a oba používají stejné rozhraní.

Postup se zadává jen na úrovni jednotlivých úkolů. Postup etapy i celkový postup projektu se počítají automaticky z úkolů pod nimi, takže si nikdo nemusí pamatovat aktualizovat souhrny před odesláním reportu. Zní to jako drobné pohodlí a ve skutečnosti je to mechanismus kvality dat: stav na úrovni portfolia se odvozuje ze stejných čísel, která tým udržuje denně, a ne ze souhrnu, který někdo narychlo naťukal večer před řídicím výborem.

Pracovní kalendář místo holých kalendářních dat

Harmonogram, který počítá víkendy jako pracovní čas, produkuje termíny, které jsou chybné od prvního dne. FlexiProject počítá doby trvání vůči pracovnímu kalendáři, takže úkol vyjádřený v pracovních dnech přistane tam, kde skutečně přistane, jakmile se zohlední víkendy a státní svátky. Stejná logika podpírá znovupoužitelné šablony: úkoly v šabloně drží dobu trvání v pracovních dnech a sadu závislostí místo pevných kalendářních dat, takže zadání data zahájení projektu vygeneruje celý harmonogram automaticky.

Pro organizaci, která opakovaně vede podobné projekty, se tady čas na plánování hroutí. Místo přestavování plánu od nuly a znovuodvozování každého termínu vychází projektový manažer ze schválené struktury a upravuje to, co je na této instanci skutečně jiné. Náš modul šablon projektů existuje přesně pro tento vzorec, a je to i důvod, proč šablony vytvořené zkušeným PMO drží svou hodnotu roky.

Základní plán a odchylka od plánu

Jakmile je plán schválen, FlexiProject jej uloží jako základní plán. Ganttův diagram pak zobrazuje původní plán vedle aktuálního harmonogramu, takže každá odchylka je vidět okamžitě, místo aby se dovozovala. Systém také prognózuje datum dokončení projektu vůči schválenému, což je obvykle jediné číslo, které vedení skutečně chce.

Hodnota tu je méně o měření a více o kvalitě rozhovoru. Projektový manažer, který dokáže ukázat, co bylo schváleno, jaká je situace teď a které rozhodnutí ten rozdíl způsobilo, je v jiné pozici než ten, kdo umí hlásit jen aktuální termíny. Diskuse se posune od toho, zda je projekt opožděný, k tomu, co udělat s konkrétní příčinou, a to je jediná verze toho rozhovoru, která končí rozhodnutím.

Kritická cesta a rezerva

FlexiProject identifikuje kritickou cestu automaticky a značí ji červeně v Ganttově diagramu, takže projektový manažer okamžitě ví, které úkoly si zaslouží pozornost. Praktické využití je v třídění. Dvoudenní skluz na kritickém úkolu je dvoudenní skluz pro celý projekt, zatímco dvoudenní skluz na úkolu s desetidenní rezervou je šum. Bez tohoto rozlišení se každé zpoždění eskaluje se stejnou naléhavostí, což všechny naučí eskalace ignorovat.

Při několika paralelních proudech, například stavba běžící vedle montáže a dokumentace, je kritická cesta tím, co manažerovi brání optimalizovat ten nesprávný. Pokud je koncept pro váš tým nový, podrobněji jsme popsali, co je kritická cesta a jak ji řídit.

Zdroje v Ganttově diagramu: čas a kapacita naplánované společně

Harmonogram, který ignoruje, kdo je k dispozici, je seznam přání. FlexiProject zobrazuje vytížení zdrojů přímo z Ganttova diagramu, takže projektový manažer na první pohled vidí, kteří lidé jsou v daném období přetížení a kteří mají ještě kapacitu. Úkoly lze posouvat po časové ose a přitom sledovat, jak se vytížení mění, což mění přeplánování v simulaci místo dohadu: plán se optimalizuje před schválením, ne poté, co si někdo stěžuje.

Tím se uzavírá mezera, která se neustále objevuje v organizacích vedoucích několik projektů se stejnými lidmi. Naplánovat nový projekt znamená vědět, zda specialisté, které potřebuje, už nejsou nasazeni jinde, a ve většině firem tato kontrola probíhá ručně, v tabulce, se zpožděním dost dlouhým na to, aby odpověď zastarala. Když kapacita sedí ve stejném pohledu jako termíny, kompromis mezi dřívějším dokončením a přetížením týmu přestane být neviditelný, dokud někdo nedá výpověď.

Zpoždění se vyplavou se stejnou přímočarostí. Úkoly, které zaostaly, jsou zvýrazněny červeně, takže otevření projektu stačí k tomu, aby bylo vidět, kde je potřeba zásah, aniž by se nejprve generoval report. Pro organizace, které chtějí jít dál a řídit dostupnost napříč celým portfoliem, náš software pro řízení zdrojů zvládá vytížení nad rámec jednoho projektu.

FlexiProject a Asana: srovnání plánovacích možností

Následující tabulka je záměrně úzká. Pokrývá jen plánování a přiznává Asaně každou schopnost, kterou skutečně má, protože srovnání, které konkurenta podceňuje, je pro čtenáře k ničemu. Spolupráce, automatizace workflow a integrace jsou jiné téma a v několika z nich je Asana silnějším produktem.

Čtěte tabulku jako popis záměru, ne jako skóre. Asana je postavena tak, aby mohl plánovat kdokoli bez školení, a každá schopnost výše, kterou vynechává, je schopnost, která by ztížila učení produktu. FlexiProject přijímá o něco strmější start výměnou za harmonogram, který pod tlakem drží tvar. Který kompromis je správný, závisí výhradně na tom, zda vaše projekty trestají nepřesný plán.

Přesun harmonogramu z Asany bez ztráty plánu

Mechanická část migrace zabere méně času, než lidé čekají. Harmonogram se importuje ze souboru Excel nebo Microsoft Project a přináší úkoly, vlastníky, dostupné atributy a, kde jsou, strukturu závislostí, takže organizace sedící na letech historických plánů je nemusí přepisovat. Exporty běží opačným směrem do Excelu, Microsoft Project XML, PDF a PNG, což se hodí, když dodavatel nebo auditor trvá na konkrétním formátu.

Část, která si zaslouží skutečné přemýšlení, je přestavba. Plán postavený v Asaně byl postaven za omezení Asany, což znamená, že čekací lhůty jsou pravděpodobně falešné úkoly, posloupnost je pravděpodobně řetězec vazeb konec-začátek a struktura fází jsou pravděpodobně sekční nadpisy. Věrné překopírování reprodukuje omezení v systému, který je už nemá. Lepší přístup je vzít jeden reprezentativní projekt, správně přestavět jeho logiku se správnými typy vazeb, pevnými zpožděními tam, kde jsou intervaly povinné, a tvrdými vazbami tam, kde posloupnost není vyjednatelná, a výsledek použít jako šablonu pro vše další.

Pro první průchod stojí za to znát jednu zkratku. FlexiProject umí vygenerovat návrh harmonogramu z popisu cílů a požadavků projektu a vytvořit úkoly, milníky, závislosti a Ganttův diagram, který projektový manažer pak upravuje, místo aby jej stavěl z ničeho. Nenahradí úsudek zkušeného plánovače, ale odstraní problém prázdné stránky, na kterém většina snah o přeplánování uvázne. Pro strukturovaný průchod jsme psali o tom, jak krok za krokem sestavit harmonogram projektu.

Často kladené otázky

Podporuje Asana všechny čtyři typy závislostí?

Ano. Asana podporuje konec-začátek, konec-konec, začátek-začátek a začátek-konec, s konec-začátek jako výchozím. Tvrzení, že Asana nabízí jen jeden typ závislosti, se objevují v řadě srovnávacích článků a jsou zastaralá. Podstatné mezery v plánování Asany jsou jinde, v pevných zpožděních, tvrdých vazbách, pracovních kalendářích, základních plánech a vazbách napříč projekty.

Lze v Asaně nastavit prodlevu mezi úkoly?

Ne. Asana neumožňuje připojit k závislosti pevné zpoždění, takže povinný interval mezi dvěma úkoly musí být znázorněn jinak, obvykle prázdnou mezerou na časové ose nebo zástupným úkolem. Oba obchvaty se rozbijí, jakmile se předchůdce pohne, protože ani jeden zpoždění nenese s sebou. Ve FlexiProject je zpoždění vlastností samotné vazby a vyjadřuje se ve dnech.

Má Asana základní plán projektu?

Ne. Asana neukládá schválenou verzi harmonogramu pro srovnání, takže neexistuje vestavěný způsob, jak zjistit, jak daleko se aktuální plán odchýlil od toho, co bylo původně dohodnuto. Týmy, které to potřebují, si obvykle drží snímek v tabulce, který odpoví na otázku jednou a pak zastará. FlexiProject uchovává schválený plán jako základní plán a zobrazuje jej vedle aktuálního harmonogramu v Ganttově diagramu.

Lze propojit úkoly ze dvou různých projektů?

V Asaně ne. Závislosti zůstávají uvnitř jednoho projektu, takže posloupnost napříč projekty musí koordinovat lidé, místo aby ji udržoval systém. FlexiProject umožňuje vazbu mezi úkoly patřícími do různých projektů, přepočítá závislé termíny, když se kterákoli strana pohne, a upozorní dotčené vlastníky, což je základní požadavek pro řízení programu, a ne sady paralelních projektů.

Je FlexiProject těžší na používání než Asana?

Žádá víc na začátku a méně potom. Asana je navržena tak, aby někdo mohl plánovat hned první den, zčásti tím, že vynechává koncepty popsané v tomto článku. FlexiProject očekává, že projektový manažer rozumí typům vazeb, pracovním kalendářům a základním plánům, a na oplátku plán udržuje, místo aby o to žádal člověka. Týmy s jednoduchými projekty budou Asanu považovat za rychlejší. Týmy, jejichž projekty trestají nepřesný plán, obvykle zjistí opak.

Volba alternativy k Asaně pro plánování projektů není ve skutečnosti volbou mezi dvěma nástroji. Je to rozhodnutí o tom, zda vaše projekty potřebují plán, který udržuje člověk, nebo plán, který udržuje systém, a to závisí na tom, jak drahé to je, když jsou termíny špatně. Pokud posunutý termín znamená přeložení schůzky, Asana je dobrá odpověď a přidávat plánovací mašinérii by tým jen zpomalilo. Pokud posunutý termín znamená nečinné dodavatele, zmeškané regulační okno, předělávku na výrobní lince nebo smluvní pokutu, pak model pod diagramem není detail. Je to produkt.

To, co se s úplným plánovacím modelem mění, je menší, než napovídá seznam funkcí, a větší, než se zdá. Vazby nesou pevná zpoždění, takže povinné intervaly jsou součástí plánu, a ne součástí něčí paměti. Tvrdé vazby drží posloupnosti, které nejsou otevřené vyjednávání. Závislosti sahají napříč projekty, takže se program chová jako program. Pracovní kalendář dává dobám trvání ten význam, který říkají, základní plán zviditelňuje odchylku a kritická cesta říká, která zpoždění skutečně záleží. Odděleně to vypadá jako vylepšení. Dohromady jsou to rozdíl mezi přeplánováním za minuty a přeplánováním přes víkend.

Pokud chcete vidět oba produkty vedle sebe v celém rozsahu, ne jen harmonogram, ale i rozpočty, rizika, zakládací listiny projektů a řízení portfolia, sestavili jsme podrobné srovnání FlexiProject a Asany. A pokud vaše projekty už tlačí na hranice zde popsané, nejužitečnějším dalším krokem je vzít jeden z nich, správně přestavět jeho harmonogram a vidět, kolik ruční práce zmizí.