Alternativă la Asana pentru planificarea proiectelor

Unde cronologia din Asana încetează să fie un program

Majoritatea articolelor despre o alternativă la Asana pentru planificarea proiectelor încep afirmând că Asana nu are diagramă Gantt. Nu este adevărat, iar a porni de la o premisă falsă este un mod prost de a ajuta pe cineva să aleagă un instrument. Asana are o vedere de cronologie care desenează bare pe o axă orizontală, le leagă cu săgeți, marchează jaloanele ca romburi și, la cerere, poate evidenția calea critică. Pentru o campanie, lansarea unui produs sau un proces de recrutare, este un mod perfect rezonabil de a planifica.

Întrebarea onestă este alta. Nu dacă diagrama există, ci dacă în spatele ei stă un model de planificare, adică un set de reguli pe care sistemul le aplică atunci când ceva se mișcă. O diagramă fără model este imaginea unui plan. O diagramă cu model este un plan. Diferența se vede doar când realitatea începe să apese pe date, ceea ce se întâmplă de obicei în a treia săptămână, nu în ziua în care planul este aprobat.

Ce face bine Asana

Asana este cu adevărat bună la a face munca vizibilă și la a determina oamenii să acționeze pe baza ei. Sarcinile au responsabili, comentarii și termene clare, cronologia este ușor de manipulat, iar sarcinile dependente se deplasează când predecesorul lor se mișcă. Dependențele sunt descrise într-un limbaj pe care nimeni nu trebuie să îl învețe, blochează și este blocată de, motiv pentru care echipele adoptă instrumentul într-o după-amiază. Pentru zece oameni care conduc o campanie de opt săptămâni, acesta nu este un compromis, este exact cantitatea potrivită de instrument pentru sarcină. Orice comparație care pretinde altceva vinde în loc să consilieze.

Merită observat unde se plătește această simplitate. Fiecare capacitate pe care Asana o lasă în afara cronologiei este una care ar fi făcut produsul mai greu de învățat, iar pentru majoritatea utilizatorilor săi acesta este compromisul potrivit. Întrebarea este ce se întâmplă cu echipele pentru care nu este.

Momentul în care planul încetează să se recalculeze singur

Punctul de cotitură vine în tăcere. Un furnizor confirmă livrarea cu două săptămâni mai târziu decât se presupunea, iar managerul de proiect mută o sarcină pe cronologie. Succesoarea imediată o urmează, pentru că acea legătură este înțeleasă. Apoi managerul observă că testarea de acceptanță programată după o perioadă obligatorie de întărire de două săptămâni începe acum prea devreme, pentru că intervalul dintre acele sarcini nu a fost niciodată o regulă, doar spațiu gol pe o diagramă. Sarcina din proiectul vecin care trebuia să înceapă după această livrare nu se mișcă deloc, pentru că cele două proiecte nu știu unul de altul. O jumătate de oră mai târziu, managerul trage bare manual și verifică datele cu o foaie de calcul.

Acesta este momentul în care un program încetează să fie un model. Planul nu mai este ceva ce menține sistemul, este ceva ce menține o persoană, iar acea persoană devine unicul punct de eșec. Fiecare replanificare costă ore, fiecare oră de replanificare este o oră nededicată problemei reale, iar după a treia sau a patra iterație oamenii încetează cu totul să actualizeze planul pentru că efortul nu se mai justifică. Un plan abandonat este mai rău decât niciun plan, pentru că din el se generează în continuare rapoarte.

Cinci semne că ați depășit planificarea din Asana

Niciunul dintre aceste semne nu ține de mărimea echipei sau de buget. Țin de forma muncii, motiv pentru care o echipă de inginerie de doisprezece persoane le poate întâlni în timp ce un departament de marketing de șaizeci nu le întâlnește niciodată. Dacă două sau mai multe descriu proiectele dvs., constrângerea dvs. este stratul de planificare, nu numărul de funcții.

Planificați în zile lucrătoare, nu în zile calendaristice. O sarcină de cinci zile care începe joi ar trebui să se termine miercurea următoare, iar o sărbătoare legală la mijloc ar trebui să împingă finalul cu încă o zi. Dacă duratele dvs. includ în tăcere weekendurile, fiecare estimare poartă o eroare încorporată care se acumulează de-a lungul unui plan de mai multe luni.

Unele intervale din planul dvs. sunt fizică, nu preferință. Betonul se întărește, straturile de acoperire se usucă, curge o perioadă de validare, expiră un termen de preaviz, un regulator are treizeci de zile pentru a răspunde. Acestea nu sunt sarcini pe care le execută cineva, sunt intervale care trebuie să se scurgă între două sarcini. Echipele fără o modalitate de a le exprima inventează sarcini de umplutură numite „în așteptarea aprobării”, ceea ce poluează lista de sarcini și induce în eroare fiecare raport construit pe ea.

Programul unui proiect îl conduce pe al altuia. În momentul în care o livrare din proiectul de infrastructură condiționează startul proiectului de migrare, iar ambele sunt gestionate separat, cineva ține acea dependență în memorie. Memoria nu trimite notificări și nu supraviețuiește concediului.

Sunteți întrebat cât de mult a deviat proiectul de la planul original. Nu care sunt datele actuale, ci cum se compară cu ceea ce a fost aprobat, și de ce. Fără un plan de referință salvat, răspunsul onest este că nimeni nu știe, iar versiunea care circulă în prezentarea comitetului de conducere este o reconstrucție.

Programul are nevoie de mai mult de două niveluri. Faze care conțin etape care conțin sarcini, cu progresul care se însumează automat în sus și cu date proprii la fiecare nivel. O listă plată cu titluri de secțiune arată similar pe ecran și se comportă complet diferit când planul se schimbă.

Tipurile de dependență și de ce semantica lor decide planul

O dependență nu este o linie trasată între două bare. Este o regulă pe care sistemul o aplică de fiecare dată când oricare capăt se mișcă, iar tipul relației este conținutul acelei reguli. Aceasta este partea pe care majoritatea comparațiilor de instrumente o sar, pentru că un tabel cu o bifă lângă „dependențe între sarcini” ascunde diferența dintre un sistem care redesenează săgeți și un sistem care recalculează date. Atât FlexiProject, cât și Asana acceptă cele patru tipuri standard, așa că întrebarea interesantă este ce le înconjoară.

A prinde corect semantica nu este precizie de dragul preciziei. Ea decide dacă un manager de proiect răspunde la întrebarea „dacă asta alunecă cu o săptămână, când terminăm” în trei secunde privind diagrama, sau în trei ore reconstruind planul. Acolo unde mai multe proiecte concurează pentru aceiași oameni, această diferență decide dacă replanificarea are loc măcar.

FS, SS, FF și SF în practică

Sfârșit-început este valoarea implicită peste tot și acoperă cea mai mare parte a muncii secvențiale: zidul trebuie construit înainte de a fi vopsit. Început-început descrie muncă ce rulează în paralel dintr-un declanșator comun, de exemplu documentația care începe în momentul în care începe dezvoltarea și rămâne aproximativ în pas cu ea. Sfârșit-sfârșit descrie muncă ce trebuie să se încheie împreună, precum instruirea utilizatorilor care trebuie să fie completă în ziua în care sistemul intră în producție, indiferent de când a început. Început-sfârșit este rar și apare mai ales în predări, unde sistemul vechi poate fi oprit doar odată ce cel nou funcționează.

Oricine construiește programe în mod serios va folosi cel puțin primele trei, iar organizațiile de proiect mature le folosesc pe toate patru pentru a modela realitatea cu precizie în loc de a forța totul într-un lanț de legături sfârșit-început. Dacă doriți o parcurgere mai aprofundată cu exemple lucrate, am scris separat despre tipurile de dependențe între sarcini pe o diagramă Gantt.

Întârziere fixă: zilele care trebuie pur și simplu să treacă

În FlexiProject, fiecare relație poate purta o întârziere fixă exprimată în zile. Dependența înseamnă atunci „începe această sarcină la patru zile după ce se termină cea anterioară”, iar cele patru zile fac parte din regulă în loc să fie un interval pe care cineva l-a estimat din ochi pe diagramă. Când predecesorul se mișcă, întârzierea se mișcă cu el, automat și fără ca cineva să își amintească că era acolo.

Efectul de business este că restricțiile tehnologice încetează să trăiască în capul oamenilor. O perioadă de întărire, o fereastră de revizuire de reglementare, o carantină obligatorie între loturi de producție sau un termen de preaviz contractual devine parte din logica planului. Nimeni nu trebuie să creeze o sarcină falsă pentru a ține spațiul deschis, nimeni nu trebuie să îi explice unui coleg de ce două bare nu trebuie apropiate, și nicio replanificare nu poate elimina în tăcere o restricție impusă de fizică sau de un contract. În proiectele unde o secvență ratată înseamnă refacere și nu un e-mail întârziat, aceasta este diferența dintre un plan în care poți avea încredere și un plan pe care trebuie să îl verifici de două ori.

Relații dure: când legătura nu trebuie ruptă

FlexiProject distinge suplimentar relațiile dure, marcate în panoul sarcinii cu două inele întrepătrunse. O relație dură înseamnă că elementul legat nu poate fi tras manual departe de predecesorul său. Sistemul nu va lăsa un utilizator să rupă în tăcere secvența mutând o bară pe diagramă, ceea ce sună restrictiv până când ai văzut un program degradându-se pe parcursul a șase luni de ajustări manuale bine intenționate.

Acest lucru contează cel mai mult acolo unde un program este un document partajat și nu fișierul unei singure persoane. Într-un proiect mare, mai multe persoane editează planul, iar fiecare are un motiv local să mute ceva. O relație dură codifică diferența dintre o secvență care este o presupunere de planificare, și deci deschisă discuției, și o secvență care este o restricție dură, și deci nu. Managerul de proiect încetează să supravegheze planul manual și începe să se bazeze pe el, ceea ce este întregul scop al unui software de planificare de la bun început.

Dependențe între proiecte: stratul pe care Asana nu îl are

În interiorul unui singur proiect, dependențele sunt o comoditate. Între proiecte, ele sunt diferența dintre un program și un dosar de planuri fără legătură. În FlexiProject o relație poate conecta o sarcină dintr-un proiect cu o sarcină din altul, astfel încât livrarea de infrastructură care condiționează o migrare este o legătură pe care sistemul o cunoaște și nu o notă în procesul-verbal al cuiva. Când data dintr-o parte se mișcă, sarcinile dependente din celălalt proiect sunt recalculate, iar responsabilii lor sunt notificați.

Consecința practică apare în luarea deciziilor, nu pe diagramă. Înainte de a aproba o schimbare într-un proiect, un manager de program poate vedea cum se propagă acea schimbare prin proiectele rămase, poate compara programul înainte și după și poate judeca costul real al unui da. Fără asta, costul iese la suprafață săptămâni mai târziu ca o serie de surprize separate, fiecare arătând ca o problemă locală și fiind tratată ca atare. Programele multianuale sunt exact locul unde acest lucru se acumulează, pentru că o decizie de două săptămâni luată cu ușurință în luna a treia poate muta o dată de lansare în luna a douăzecea.

Toate sarcinile unui program sunt de asemenea vizibile pe o singură diagramă Gantt partajată, astfel încât un manager de program vede legăturile într-un singur loc în loc să le reconstruiască din rapoarte de stare. Echipele care au nevoie de asta o descoperă de obicei pe calea grea, după ce au încercat mai întâi să coordoneze același lucru cu o ședință recurentă. Dacă organizația dvs. merge în această direcție, software-ul nostru pentru gestionarea programelor de proiecte descrie cum sunt structurate programele.

Modelul de sub diagrama Gantt

Relațiile sunt partea cea mai vizibilă a modelului de planificare, dar nu sunt întregul model. Alte patru mecanisme decid dacă o diagramă se comportă ca un plan, și ele sunt cele care separă un software de diagramă Gantt de un widget de cronologie. Niciunul dintre ele nu este exotic. Toate sunt genul de lucruri pe care le simți lipsă doar când ai nevoie de ele.

WBS nelimitat și progres care se însumează singur

Proiectele dintr-o organizație variază enorm ca scară, de la o victorie rapidă de două săptămâni la o investiție de capital pe mai mulți ani, iar o singură structură rigidă nu poate servi ambelor. FlexiProject nu pune nicio limită asupra cât de adânc merge structura de sarcini, așa că un proiect poate fi împărțit în faze, etape, sarcini și jaloane atât de jos cât este nevoie. Un proiect mic poate rămâne plat cu o mână de sarcini, în timp ce un proiect de investiții poate purta o structură de descompunere a muncii pe mai multe niveluri, și ambele folosesc aceeași interfață.

Progresul se introduce doar la nivelul sarcinilor individuale. Progresul etapei și progresul general al proiectului sunt calculate automat din sarcinile de dedesubt, astfel încât nimeni nu trebuie să își amintească să actualizeze agregatele înainte de a ieși un raport. Sună a comoditate minoră și este de fapt un mecanism de calitate a datelor: statusul la nivel de portofoliu este derivat din aceleași numere pe care echipa le menține zilnic, și nu dintr-un rezumat pe care cineva l-a tastat în grabă în seara dinaintea unui comitet de conducere.

Un calendar de lucru în locul datelor calendaristice brute

Un program care numără weekendurile ca timp de lucru produce date greșite din prima zi. FlexiProject calculează duratele față de un calendar de lucru, așa că o sarcină exprimată în zile lucrătoare aterizează unde aterizează cu adevărat odată ce weekendurile și sărbătorile legale sunt luate în calcul. Aceeași logică susține șabloanele reutilizabile: sarcinile dintr-un șablon poartă o durată în zile lucrătoare și un set de dependențe în loc de date fixe, așa că introducerea unei date de început a proiectului generează întregul program automat.

Pentru o organizație care rulează proiecte similare în mod repetat, aici se prăbușește timpul de planificare. În loc să reconstruiască un plan de la zero și să rederiveze fiecare dată, un manager de proiect pornește de la o structură aprobată și ajustează ceea ce este cu adevărat diferit în acest caz. Modulul nostru de șabloane de proiect există exact pentru acest tipar, și este de asemenea motivul pentru care șabloanele construite de un PMO experimentat își păstrează valoarea ani de zile.

Plan de referință și abatere de la plan

Odată aprobat un plan, FlexiProject îl stochează ca plan de referință. Diagrama Gantt arată atunci planul original alături de programul actual, astfel încât fiecare abatere este vizibilă imediat în loc să fie dedusă. Sistemul prognozează de asemenea data de finalizare a proiectului față de cea aprobată, care este de obicei singurul număr pe care un consiliu de administrație îl vrea cu adevărat.

Valoarea aici ține mai puțin de măsurare și mai mult de calitatea conversației. Un manager de proiect care poate arăta ce a fost aprobat, care este situația acum și ce decizie a cauzat diferența se află într-o poziție diferită față de unul care poate raporta doar datele actuale. Discuția se mută de la dacă proiectul este în întârziere la ce să facem cu cauza concretă, care este singura versiune a acelei conversații care se termină cu o decizie.

Calea critică și rezerva

FlexiProject identifică automat calea critică și o marchează cu roșu pe diagrama Gantt, astfel încât un manager de proiect știe imediat ce sarcini merită atenție. Utilizarea practică este în triaj. O alunecare de două zile pe o sarcină critică este o alunecare de două zile pentru întregul proiect, în timp ce o alunecare de două zile pe o sarcină cu zece zile de rezervă este zgomot. Fără această distincție, fiecare întârziere este escaladată cu aceeași urgență, ceea ce îi învață pe toți să ignore escaladările.

Cu mai multe fluxuri în paralel, de exemplu construcția care rulează alături de montaj și documentație, calea critică este ceea ce împiedică un manager să optimizeze fluxul greșit. Dacă noțiunea este nouă pentru echipa dvs., am tratat mai în profunzime ce este calea critică și cum să o gestionezi.

Resursele pe diagrama Gantt: timp și capacitate planificate împreună

Un program care ignoră cine este disponibil este o listă de dorințe. FlexiProject arată încărcarea resurselor direct din diagrama Gantt, astfel încât un manager de proiect vede dintr-o privire ce persoane sunt supraîncărcate într-o anumită perioadă și care mai au capacitate. Sarcinile pot fi mutate de-a lungul cronologiei în timp ce se urmărește cum se schimbă încărcarea, ceea ce transformă replanificarea într-o simulare în loc de o presupunere: planul este optimizat înainte de a fi aprobat, nu după ce se plânge cineva.

Aceasta închide un gol care apare constant în organizațiile care rulează mai multe proiecte cu aceleași persoane. A planifica un proiect nou înseamnă a ști dacă specialiștii de care are nevoie sunt deja angajați în altă parte, iar în majoritatea companiilor acea verificare se face manual, într-o foaie de calcul, cu o întârziere suficient de lungă încât să facă răspunsul învechit. Când capacitatea stă în aceeași vedere ca datele, compromisul dintre a termina mai devreme și a supraîncărca o echipă încetează să fie invizibil până când cineva demisionează.

Întârzierile ies la suprafață cu aceeași sinceritate. Sarcinile rămase în urmă sunt evidențiate cu roșu, astfel încât deschiderea proiectului este suficientă pentru a vedea unde este nevoie de intervenție, fără a genera mai întâi un raport. Pentru organizațiile care vor să meargă mai departe și să gestioneze disponibilitatea pe întregul portofoliu, software-ul nostru de gestionare a resurselor tratează încărcarea dincolo de un singur proiect.

FlexiProject și Asana: capacitățile de planificare comparate

Tabelul de mai jos este deliberat îngust. Acoperă doar planificarea și îi acordă Asanei fiecare capacitate pe care o are cu adevărat, pentru că o comparație care subestimează un concurent este inutilă pentru cel care o citește. Colaborarea, automatizarea fluxurilor și integrările sunt o altă discuție, iar în mai multe dintre ele Asana este produsul mai puternic.

Citiți tabelul ca o descriere de intenție și nu ca un scor. Asana este construită astfel încât oricine să poată planifica fără instruire, iar fiecare capacitate de mai sus pe care o omite este una care ar face produsul mai greu de învățat. FlexiProject acceptă un start ceva mai abrupt în schimbul unui program care își păstrează forma sub presiune. Care compromis este cel corect depinde în întregime de dacă proiectele dvs. penalizează un plan imprecis.

Scoaterea unui program din Asana fără a pierde planul

Partea mecanică a unei migrări durează mai puțin decât se așteaptă oamenii. Un program se importă dintr-un fișier Excel sau dintr-un fișier Microsoft Project, aducând sarcini, responsabili, atribute disponibile și, unde există, structura dependențelor, astfel încât organizațiile care stau pe ani de planuri istorice nu trebuie să le retasteze. Exporturile merg în sens invers către Excel, Microsoft Project XML, PDF și PNG, ceea ce contează când un antreprenor sau un auditor insistă pe un anumit format.

Partea care merită gândire reală este remodelarea. Un plan construit în Asana a fost construit sub restricțiile Asanei, ceea ce înseamnă că perioadele de așteptare sunt probabil sarcini false, secvența este probabil un lanț de legături sfârșit-început, iar structura de faze sunt probabil titluri de secțiune. Copierea fidelă a acestora reproduce limitarea într-un sistem care nu o mai are. Abordarea mai bună este să iei un proiect reprezentativ, să îi reconstruiești logica corect cu tipurile de relație potrivite, întârzieri fixe unde intervalele sunt obligatorii și relații dure unde secvența nu este negociabilă, și să folosești rezultatul ca șablon pentru tot ce urmează.

Pentru prima trecere există o scurtătură pe care merită să o cunoști. FlexiProject poate genera o ciornă de program dintr-o descriere a obiectivelor și cerințelor proiectului, producând sarcini, jaloane, dependențe și o diagramă Gantt pe care un manager de proiect apoi o editează în loc să o construiască din nimic. Nu va înlocui judecata unui planificator experimentat, dar elimină problema paginii albe, unde se împotmolesc majoritatea eforturilor de replanificare. Pentru o parcurgere structurată, am scris despre cum să construiești un program de proiect pas cu pas.

Întrebări frecvente

Asana acceptă toate cele patru tipuri de dependență?

Da. Asana acceptă sfârșit-început, sfârșit-sfârșit, început-început și început-sfârșit, cu sfârșit-început ca implicit. Afirmațiile că Asana oferă doar un tip de dependență apar în mai multe articole de comparație și sunt depășite. Lacunele semnificative din planificarea Asanei sunt în altă parte: în întârzierile fixe, relațiile dure, calendarele de lucru, planurile de referință și legăturile între proiecte.

Se poate seta un timp de întârziere între sarcini în Asana?

Nu. Asana nu permite atașarea unei întârzieri fixe la o dependență, așa că un interval obligatoriu între două sarcini trebuie reprezentat altfel, de obicei printr-un gol gol pe cronologie sau o sarcină de umplutură. Ambele soluții de compromis se rup imediat ce predecesorul se mișcă, pentru că niciuna nu poartă întârzierea cu ea. În FlexiProject întârzierea este o proprietate a relației însăși și este exprimată în zile.

Are Asana un plan de referință de proiect?

Nu. Asana nu stochează o versiune aprobată a programului pentru comparație, așa că nu există o modalitate integrată de a vedea cât de mult a deviat planul actual de la ceea ce s-a convenit inițial. Echipele care au nevoie de asta țin de obicei un instantaneu într-o foaie de calcul, care răspunde la întrebare o dată și apoi devine învechit. FlexiProject păstrează planul aprobat ca plan de referință și îl arată alături de programul actual pe diagrama Gantt.

Se pot lega sarcini din două proiecte diferite?

În Asana nu. Dependențele rămân în interiorul unui singur proiect, așa că o secvență între proiecte trebuie coordonată de oameni în loc să fie menținută de sistem. FlexiProject permite o relație între sarcini care aparțin unor proiecte diferite, recalculează datele dependente când oricare parte se mișcă și notifică responsabilii afectați, ceea ce este cerința de bază pentru a gestiona un program și nu un set de proiecte paralele.

Este FlexiProject mai greu de folosit decât Asana?

Cere mai mult la început și mai puțin după aceea. Asana este concepută astfel încât cineva să poată planifica din prima zi, parțial prin lăsarea deoparte a conceptelor descrise în acest articol. FlexiProject se așteaptă ca un manager de proiect să înțeleagă tipurile de relație, calendarele de lucru și planurile de referință, și în schimb menține planul în loc să ceară unei persoane să îl mențină. Echipele cu proiecte simple vor găsi Asana mai rapidă. Echipele ale căror proiecte penalizează un plan inexact găsesc de obicei contrariul.

A alege o alternativă la Asana pentru planificarea proiectelor nu este de fapt o alegere între două instrumente. Este o decizie despre dacă proiectele dvs. au nevoie de un plan pe care îl menține o persoană sau de un plan pe care îl menține un sistem, iar asta depinde de cât de scump este când datele sunt greșite. Dacă o dată alunecată înseamnă o ședință reprogramată, Asana este un răspuns bun, iar adăugarea unei mașinării de planificare ar încetini doar echipa. Dacă o dată alunecată înseamnă antreprenori inactivi, o fereastră de reglementare ratată, refacere pe o linie de producție sau o clauză de penalizare, atunci modelul de sub diagramă nu este un detaliu. Este produsul.

Ceea ce se schimbă cu un model complet de planificare este mai mic decât sugerează o listă de funcții și mai mare decât pare. Relațiile poartă întârzieri fixe, așa că intervalele obligatorii fac parte din plan în loc de memoria cuiva. Relațiile dure țin secvențe care nu sunt deschise negocierii. Dependențele ajung între proiecte, așa că un program se comportă ca un program. Un calendar de lucru face ca duratele să însemne ceea ce spun, un plan de referință face abaterea vizibilă, iar calea critică spune care întârzieri contează cu adevărat. Separat, acestea par rafinamente. Împreună, sunt diferența dintre replanificarea în minute și replanificarea de-a lungul unui weekend.

Dacă vreți să vedeți cele două produse una lângă alta pe întregul domeniu și nu doar programul, inclusiv bugete, riscuri, acte constitutive de proiect și guvernanța portofoliului, am pregătit o comparație detaliată între FlexiProject și Asana. Iar dacă proiectele dvs. deja apasă pe limitele descrise aici, cel mai util pas următor este să luați unul dintre ele, să îi reconstruiți programul corect și să vedeți cât de multă muncă manuală dispare.