Diferențele dintre managementul de proiect clasic și agil (partea 1) - proiectele ușurate
Clasic sau agil - două metodologii în managementul de proiect care nu ar putea fi mai diferite: Sigur, fiecare manager de proiect vrea să-și conducă proiectul către succes, dar ideile de bază și abordarea celor două abordări par complet opuse. Acest lucru este exprimat nu în ultimul rând în dezbaterile aprinse despre care metodă este „mai bună”. Dar există această pătură „mai bună”? Foarte probabil! Este bine cunoscut faptul că instrumentele funcționează numai dacă sunt selectate corespunzător pentru acest scop. În articolul „Agile, classic & Co: Când este potrivită metodologia de management al proiectului?” Puteți afla mai multe despre alegerea corectă a metodologiei.
Deci, cum alegeți o abordare sau alta? În primul rând, trebuie să știți în ce vă implicați cu fiecare metodă. Mai exact, acest lucru înseamnă: ce înseamnă angajamentul pentru proiectul dvs. și în ce fel diferă cele două abordări. Pentru a vă fi mai ușor, următorul articol este primul dintr-o serie de 4 articole în care explicăm diferențele dintre clasic și agil ajunge la fund.
La începutul seriei, începem cu trei diferențe foarte fundamentale:
Pericol: În spatele termenilor clasic și agil O mulțime de modele diferite de procese, cadre și implementări sunt ascunse. În practică, există câteva abordări mixte ale celor mai variate caracteristici. Prin urmare, un proiect clasic organizat poate conține sub-proiecte agile. Chiar dacă un proiect urmează în mod oficial una sau cealaltă predare 100% și cadrul este fixat, managerul de proiect șiret va găsi adesea o soluție pragmatică pentru a face față problemelor rezultate. În această serie nu intrăm în astfel de forme mixte și soluții, ci luăm în considerare în mod deliberat formele extreme de „clasic” și „agil” pentru o mai bună înțelegere.
Feedback târziu vs. feedback timpuriu
Din perspectiva clientului, diferențele dintre procedurile clasice și cele agile devin deosebit de clare atunci când Timpul și frecvența feedback-ului să fie luat în considerare: Când poate sau trebuie (sau poate) clientul (clientul, utilizatorul final, ...) să ofere feedback cu privire la rezultatul/produsul proiectului?
Management de proiect clasic:
Adesea rezultatul este prezentat clientului doar la sfârșitul proiectului. Acest lucru poate de ex. să fie un produs dezvoltat în cadrul proiectului. Pentru ca acest lucru să nu meargă prost și acest produs să îndeplinească de fapt așteptările clientului, trebuie acordată o atenție deosebită la definirea cerințelor la începutul proiectului. De obicei, se creează o specificație de cerință care stă la baza acceptării clientului la sfârșitul proiectului. Deci feedback-ul vine doar la sfârșit.
Exemple:
- Pompă personalizată pentru o stație de epurare cu cerințe și specificații tehnice clare
- Implementarea unui eveniment de marketing pentru introducerea unui nou smartphone
- Instruirea angajaților unei autorități pe tema „noilor norme de protecție a datelor”
Pericol: În managementul clasic al proiectului există, desigur, și opțiunea de a oferi clienților oportunități de feedback în timp ce proiectul se desfășoară. Exemple, vă rog?
- În proiectul de dezvoltare prezentat mai sus, consultarea cu clientul ar putea avea loc după încheierea fazei de proiectare.
- În exemplul instruirii angajaților, conceptul de formare dezvoltat ar putea fi prezentat conducerii autorității pentru aprobare.
În managementul clasic al proiectului, astfel de puncte de feedback sunt utilizate în primul rând pentru a verifica dacă proiectul este încă pe drumul cel bun, pentru a preveni să se întâmple lucruri mai rele. În cazul în care este necesară o corecție a cursului într-un astfel de moment, aceasta implică de obicei un efort considerabil de reprogramare - proiectul este adesea costisitor și întârziat.
Management de proiect agil:
Clientul primește sub-funcții sau creșteri de produs pentru evaluare în cicluri regulate - feedback-ul și critica sunt binevenite în mod expres. Acest lucru funcționează numai dacă un rezultat al proiectului poate fi împărțit în trepte care pot fi generate unul după altul și apoi examinat/evaluat. Primul exemplu este dezvoltarea de software - zona în care își are originea ideea agilă.
Figura arată procedura utilizând exemplul cadrului Scrum în managementul de proiect agil:
În medii nesigure, cu cerințe în schimbare, avantajul este evident: în loc să dezvolte un produs complet pe perioade lungi de timp, toți cei implicați primesc în mod regulat informații despre progresul proiectului. Cerințele pot fi ajustate și următorii pași definiți. În acest fel, ajustările ulterioare ulterioare sunt eliminate automat. Spre deosebire de managementul de proiect clasic, nu există riscul ca modificările cerințelor să rămână nedetectate sau, în cel mai rău caz, un produs să fie ocolit pe piață.
Exemple:
- Dezvoltarea unui site web cu un magazin online și numeroase alte funcționalități detaliate
- Dezvoltarea unui software de control pentru un nou design de motor
- Planificarea unei case unifamiliale de către un birou de arhitectură
Procese definite vs. inovaţie
Construcția celei de-a treisprezecea case prefabricate „de pe picior” diferă enorm de dezvoltarea unei aplicații inovatoare, în ciuda tuturor opțiunilor de configurare - și, prin urmare, procedura va diferi, de asemenea, semnificativ:
Management de proiect clasic:
Proiectele planificate și implementate clasic sunt adecvate în special pentru proiectele care urmează procese definite în care sunt utilizate soluții/componente detaliate bine înțelese și din care ar trebui să iasă un rezultat previzibil. Pașii dovediți și definiți conduc la un rezultat prestabilit.
Exemple:
- Construcția unei case unifamiliale „pe picior”
- Actualizarea peisajului serverului într-o companie
Management de proiect agil:
Managementul de proiect agil este adesea utilizat în medii dinamice: în dezvoltarea produselor, cercetare și dezvoltare software. De multe ori nu este posibil să se prezică în mod clar cum va arăta rezultatul în detaliu și ce abordări vor aduce cea mai bună soluție - la început pur și simplu nimeni nu știe. Un plan sau proces dat nu are prea mult sens, la urma urmei, ar trebui creat ceva nou. Dacă se vor crea inovații inovatoare, nu există o rețetă standard care să poată fi aplicată direct.
Exemple:
- Optimizarea unui afișaj pentru laptop cu o nouă tehnologie care nu este încă pe deplin înțeleasă
- Dezvoltarea unei aplicații inovatoare pentru pierderea în greutate
Dezvoltare secvențială vs. dezvoltarea iterativă
În pași predeterminați, succesivi către obiectiv - sau în cicluri scurte? Metodologiile de management al proiectului diferă considerabil aici. Acest punct este strâns legat de frecvența de feedback (a se vedea mai sus):
Management de proiect clasic:
În proiectele implementate în mod tradițional, fazele definite sunt procesate una după alta la început. Când o fază sau un bloc de sarcini a fost finalizat, începe următoarea. În principiu, fazele se pot suprapune, dar cel puțin în cadrul unui subproiect nu sunt niciodată procesate aproximativ în paralel, ci în esență una după alta.
Această abordare se bazează pe presupunerea că toate informațiile sunt disponibile la începutul proiectului. Acestea sunt împachetate în cerințe și modele, apoi începe implementarea.
Exemplu: Programarea va începe doar când proiectarea site-ului web este complet terminată.
Management de proiect agil:
În managementul de proiect agil, nu totul este definit în detaliu la început. Ideea de bază: oamenii nu pot vedea toate detaliile în avans și nici măcar clienții nu știu exact ce vor și ce opțiuni sunt disponibile la început. Din acest motiv, sunt implementate unități mici, acestea sunt verificate și, dacă este necesar, îmbunătățite.
Iterativă:
Abordarea iterativă se bazează pe premisa că în primul pas multe lucruri sunt deseori incorecte sau nu sunt rezolvate în mod ideal înainte ca erorile să fie corectate în etapa următoare. Pentru a spune direct: Prima aruncare este pentru coșul de gunoi, dar putem învăța din el și ne putem baza pe el. Sau altfel: prima aruncare este o sugestie către client. Prin urmare, încercările multiple nu sunt privite ca o eroare, ci mai degrabă planificate ca parte a procedurii de la început.
exemplu: În loc să trimiteți o schiță detaliată a unui nou site web în toate detaliile sale, sunt create schițe brute, se creează versiuni anterioare și acestea sunt rafinate treptat în consultare cu clientul.
Incremental:
Cu abordarea incrementală, bucăți mari sunt împărțite în subtaskuri și acestea sunt finalizate una după alta. Fundalul: Dacă este construită o mică parte, cunoștințele pot fi dobândite și aplicate altor funcții.
Exemplu: În loc să proiecteze toate subpaginile unei noi prezențe a companiei, se creează inițial doar pagina de start.
Concluzie
Alegerea instrumentului potrivit pentru fiecare aplicație este adesea trucul! În acest articol ați cunoscut primele trei diferențe dintre managementul de proiect clasic și agil. Ești curios să afli mai multe? Partea 2 continuă!