Metodologia proiectelor software: cum să alegi între Waterfall, Agile, Scrum, Kanban, DevOps și hibrid

Ce este o metodologie de proiect software și de ce contează alegerea

O metodologie de proiect software este o abordare structurată care definește cum este planificat, executat și livrat un proiect software. Prescrie faze (sau absența lor deliberată), roluri, artefacte, ritmuri și tipare de luare a deciziilor. Metodologii diferite optimizează rezultate diferite: Waterfall pentru predictibilitate și documentație, Agile pentru adaptabilitate și livrare de valoare, DevOps pentru viteza de lansare și integrarea operațională. Nicio metodologie nu este universal mai bună; fiecare este mai bună pentru un set specific de condiții. Sarcina managerului de proiect nu este să o aleagă pe cea preferată, ci să potrivească metodologia proiectului în curs.

Alegerea nu este cosmetică. State of Project Management Report 2024 al Wellingtone a arătat că doar 34% dintre organizații finalizează proiectele la timp și 34% în buget, iar deși metodologia este doar o variabilă, este una controlabilă. Proiectele cu cerințe stabile derulate în Agile irosesc adesea efort replanificând ceea ce nu a avut niciodată nevoie să se schimbe; proiectele cu cerințe volatile derulate în Waterfall livrează adesea în raport cu un plan care nu mai corespunde nevoii de business. Ambele moduri de eșec sunt evitabile prin selecția metodologiei, iar ambele sunt comune în organizațiile care aleg după preferința echipei în loc de potrivirea la proiect.

Pentru un manager de proiect sau un analist PMO, cadrul decizional contează pentru că alegerea metodologiei este una dintre primele decizii ale proiectului și una dintre cele mai greu de inversat. Schimbarea metodologiei la mijlocul proiectului este posibilă, dar costisitoare: contractele, așteptările sponsorului, instrumentele și competențele echipei se aliniază unei metodologii, iar schimbarea direcției înseamnă realinierea tuturor. Cele cinci metodologii de mai jos plus hibridul acoperă majoritatea proiectelor software; o alegere bună la început evită reamenajarea ulterioară.

Cele cinci metodologii principale de proiect software dintr-o privire

Tabelul de mai jos rezumă cele cinci metodologii principale plus hibridul, oferind o privire de ansamblu rapidă înaintea secțiunilor detaliate. Fiecare rând răspunde la întrebările pe care un manager de proiect le pune mai întâi: cum este organizată munca, care este ritmul, pentru ce este cea mai potrivită, unde este slabă.

Restul acestui articol tratează fiecare metodologie mai în profunzime, urmat de cadrul decizional pentru a alege între ele.

Waterfall: predictibil, condus de plan, secvențial

Metodologia Waterfall, formalizată de Winston Royce într-un articol din 1970 (în mod ironic, descriind ceea ce el considera o abordare defectuoasă), organizează un proiect software în faze secvențiale care curg una în alta: colectarea cerințelor, proiectarea sistemului, implementarea, integrarea și testarea, implementarea în producție și mentenanța. Fiecare fază se finalizează înainte ca următoarea să înceapă, iar revenirea la o fază anterioară este tratată ca un eveniment semnificativ care necesită un control formal al modificărilor. Disciplina metodologiei provine din presupunerea că cerințele pot fi definite în avans și nu se vor schimba substanțial în timpul execuției.

Waterfall nu este relicva învechită pe care marketingul Agile o sugerează uneori. Rămâne alegerea corectă în mai multe situații. Industriile reglementate (farmaceutică, aviație, apărare, conformitate financiară) necesită adesea documentație completă în avans și validarea formală a fiecărei faze, ceea ce Waterfall oferă în mod natural. Contractele cu domeniu fix și termen fix (proiecte publice, livrabile de la furnizori) beneficiază de claritatea Waterfall privind ce se va livra și când. Proiectele cu cost ridicat al schimbării în timpul execuției, precum infrastructura fizică, integrarea hardware sau aprobările de reglementare complexe, se aliniază cu disciplina Waterfall de a stabili corect cerințele înainte de a construi. Predictibilitatea pe care Waterfall o impune este exact ceea ce au nevoie aceste proiecte.

Slăbiciunile Waterfall sunt oglinda punctelor sale forte. Când cerințele se schimbă în timpul execuției, controlul formal al modificărilor din Waterfall adaugă cost și timp pe care metodologiile agile le-ar absorbi în iterația normală. Feedbackul vine târziu, adesea doar în timpul testării de integrare, astfel încât defectele și neînțelegerile ies la iveală după o investiție semnificativă. Livrarea valorii de business este amânată până la finalul proiectului, deci dacă proiectul este anulat devreme, nu s-a livrat nimic utilizabil. Metodologia se potrivește extrem de bine anumitor proiecte; nu se potrivește proiectelor cu incertitudine reală privind ce trebuie construit. Ghidul nostru despre metodologia Waterfall tratează fazele și execuția lor mai în detaliu.

Agile: iterativ, adaptiv, orientat pe valoare

Agile nu este o singură metodologie, ci un cadru umbrelă care cuprinde mai multe metode specifice (Scrum, Kanban, Extreme Programming, Crystal și altele). Ceea ce le unește este Manifestul Agile din 2001, care a prioritizat indivizii și interacțiunile în locul proceselor și instrumentelor, software-ul funcțional în locul documentației exhaustive, colaborarea cu clientul în locul negocierii contractuale și răspunsul la schimbare în locul urmării unui plan. Douăsprezece principii subiacente operaționalizează aceste valori: livrarea frecventă de software funcțional, întâmpinarea cerințelor care se schimbă, echipe auto-organizate, ritm sustenabil și altele. Valorile Manifestului nu sunt împotriva planificării sau a documentației; stabilesc priorități când trebuie făcute compromisuri.

Agile se potrivește proiectelor cu cerințe în evoluție, domeniu incert, valoare mare a feedbackului timpuriu și echipe împuternicite să ia decizii de livrare. Dezvoltarea de produse software, inițiativele de transformare digitală și orice proiect în care aportul clientului în timpul dezvoltării îmbunătățește semnificativ rezultatul beneficiază de ciclurile scurte și adaptarea continuă din Agile. Puterea metodologiei provine din bucla strânsă de feedback: construirea unui increment mic, prezentarea lui părților interesate, învățarea a ceea ce trebuie ajustat, construirea următorului increment. Pe durata unui proiect, această buclă produce de obicei ceva mai apropiat de ceea ce părțile interesate au cu adevărat nevoie decât alternativele planificate în avans.

Implementarea practică a Agile se lovește de o problemă comună de instrumente: dezvoltatorii preferă puternic Jira, Azure DevOps sau platforme agile similare centrate pe echipă, pentru că se potrivesc nativ mecanicii sprinturilor și îngrijirii backlogului, în timp ce PMO-urile au nevoie de vizibilitate la nivel de portofoliu pe care aceste instrumente nu o oferă bine. Tiparul pragmatic este integrarea: dezvoltatorii lucrează în Jira, PMO-urile văd subsetul relevant pentru portofoliu în sistemul lor PPM prin sincronizarea datelor. FlexiProject implementează acest tipar cu o integrare directă cu Jira care importă epice, story-uri și task-uri păstrând statusul, responsabilul și tipul, astfel încât PMO-urile și conducerea văd munca agile în aceeași vizualizare de portofoliu ca proiectele non-agile fără ca echipele să schimbe instrumentele. Pentru o definiție mai completă a Agile, vedeți ghidul nostru Ce este Agile; pentru perspectiva operațională PM/PMO, articolul nostru Managementul proiectelor de dezvoltare software agilă în PPM tratează modelul de livrare în profunzime.

Scrum și Kanban: două variante ale Agile în practică

Scrum și Kanban sunt cele mai utilizate două metode agile în dezvoltarea software. Împărtășesc valorile subiacente ale Agile, dar le implementează diferit, iar alegerea între ele depinde de tiparul de lucru al echipei.

Scrum: Agile bazat pe sprinturi cu roluri definite

Scrum organizează munca agile în iterații de lungime fixă numite sprinturi (de obicei două săptămâni). Fiecare sprint începe cu planificarea sprintului, unde echipa se angajează la un set de story-uri de utilizator din backlogul de produs, și se încheie cu revizuirea sprintului (demonstrație pentru părțile interesate) și retrospectiva (îmbunătățirea procesului echipei). Trei roluri duc munca: Product Owner (prioritizează backlogul), Scrum Master (facilitează evenimentele și îndepărtează impedimentele) și Echipa de Dezvoltare (livrează angajamentul sprintului). Scrum funcționează bine pentru echipe care construiesc funcționalități noi într-un ritm predictibil, cu un Product Owner capabil să se angajeze la domeniul sprintului și o echipă care beneficiază de disciplina iterației. Ghidul nostru despre metodologia Scrum tratează rolurile, evenimentele și artefactele în detaliu.

Kanban: flux continuu cu limite WIP

Kanban înlocuiește limitele de sprint din Scrum cu flux continuu. Elementele de lucru avansează prin coloane de flux (de obicei De făcut, În lucru, Revizuire, Gata) cu limite de lucru în curs la fiecare coloană, ceea ce forțează echipa să termine înainte de a începe. Nu există roluri fixe dincolo de cele pe care echipa le are deja, nici evenimente obligatorii (deși majoritatea echipelor adoptă standup-uri zilnice și revizuiri operaționale periodice), nici gruparea muncii în sprinturi. Kanban se potrivește echipelor de suport, muncii DevOps, campaniilor de marketing și oricărui flux în care prioritățile se schimbă mai des decât durata unui sprint. Ghidul nostru despre sistemul Kanban tratează întreaga metodologie, inclusiv cele șase practici, metricile și tiparele de adoptare în PMO.

Alegerea între Scrum și Kanban nu este permanentă. Echipele încep adesea cu structura Scrum în timp ce învață Agile, apoi evoluează către Scrumban (evenimente Scrum cu o tablă Kanban și limite WIP) pe măsură ce munca lor devine mai continuă, și în cele din urmă către Kanban pur când întreruperile domină. Cadrul ar trebui să servească tiparul de lucru al echipei; tiparul servește rareori cadrul.

DevOps: dezvoltarea și operațiunile ca una singură

DevOps este o metodologie, o cultură și un set de practici care integrează dezvoltarea software și operațiunile IT într-un singur pipeline de livrare continuă. Termenul a fost inventat în jurul anului 2009 de Patrick Debois, iar practica a apărut din echipe frustrate de zidul tradițional dintre dezvoltatori (care scriau codul) și operațiuni (care îl implementau și îl rulau). DevOps îndepărtează acel zid: aceeași echipă deține codul de la commit până în producție, automatizarea înlocuind predările manuale la fiecare etapă.

Practicile centrale sunt integrarea continuă (CI, unde fiecare commit de cod declanșează un build și teste automatizate), livrarea continuă (CD, unde fiecare build reușit este pregătit automat pentru implementare), infrastructura ca cod (IaC, unde infrastructura este versionată și implementată ca software), testarea automatizată (teste unitare, de integrare, de securitate și de performanță rulează automat) și monitorizarea continuă (comportamentul din producție realimentează prioritățile de dezvoltare). Împreună, aceste practici comprimă ciclul de lansare de la luni la zile sau ore și transformă implementarea dintr-un eveniment planificat într-o operațiune de rutină.

DevOps se potrivește proiectelor software cu mai multe caracteristici. Serviciile cloud-native cu frecvență mare de lansare (produse SaaS, aplicații web, microservicii) beneficiază de DevOps pentru că ciclul de lansare este dimensiunea competitivă. Echipele care livrează în producție continuu (nu doar la finalul proiectului) au nevoie de automatizarea pe care DevOps o oferă. Organizațiile cu mentalitate de produs (nu de proiect) tratează livrarea ca fiind continuă în loc de terminală, ceea ce DevOps permite. Furnizorii de infrastructură cloud (AWS, Azure, GCP) și-au construit instrumentele în jurul presupunerilor DevOps, făcând adoptarea semnificativ mai simplă decât acum un deceniu.

DevOps nu se potrivește oricărui proiect. Industriile reglementate cu cicluri de lansare trimestriale obligatorii și validare formală a fiecărei modificări adesea nu pot acomoda ritmul rapid de implementare al DevOps, deoarece povara de conformitate a validării fiecărei implementări ar consuma câștigurile de viteză. Echipele mici cu lansări ocazionale găsesc adesea povara de instrumente a DevOps disproporționată față de beneficiu. Sistemele moștenite construite fără o arhitectură prietenoasă cu automatizarea pot necesita ani de refactorizare înainte ca practicile DevOps să funcționeze semnificativ. În aceste cazuri, adoptarea de practici DevOps selective (CI, testare automatizată) fără implementare continuă completă oferă adesea cea mai mare parte a beneficiului fără angajamentul total.

Peisajul instrumentelor este vast, dar în convergență. Printre platformele CI/CD se numără Jenkins, GitLab CI, GitHub Actions, CircleCI și echivalente cloud-native (AWS CodePipeline, Azure Pipelines). Printre standardele de infrastructură ca cod se numără Terraform (multi-cloud), Ansible (gestionarea configurației), Kubernetes (orchestrarea containerelor) și Docker (containerizare). Stivele de monitorizare combină metrici (Prometheus, Datadog), loguri (stiva ELK, Splunk) și trasare (Jaeger, OpenTelemetry). Instrumentele specifice se schimbă; practicile pe care le susțin rămân stabile. DevOps coexistă adesea cu metodologiile agile la nivel de echipă: Agile pentru planificare și prioritizare, DevOps pentru livrare și operațiuni. Această combinație este ceea ce majoritatea organizațiilor software moderne rulează efectiv, fie că o numesc așa, fie că nu.

Hibrid: combinarea metodologiilor pentru proiecte din lumea reală

Managementul hibrid al proiectelor combină elemente din mai multe metodologii pentru a se potrivi proiectelor care nu corespund clar niciunei abordări unice. Nu este un compromis, ci o alegere deliberată: folosirea disciplinei Waterfall acolo unde contează predictibilitatea, a flexibilității Agile acolo unde există incertitudine și integrarea lor la granițe. Cel mai comun tipar hibrid în proiectele software combină planificarea la nivel de proiect din Waterfall (buget fix, guvernanță pe bază de jaloane, aprobări formale) cu execuția agile în cadrul fazelor (dezvoltare iterativă, livrare pe bază de sprinturi, feedback continuu al părților interesate).

Hibridul se potrivește mai multor situații recurente. Industriile reglementate care au nevoie de date de lansare fixe din motive de conformitate, dar doresc flexibilitatea execuției agile, adoptă adesea hibridul: ritmul de lansare este în stil Waterfall (planificat trimestrial, cu aprobări formale), în timp ce dezvoltarea din cadrul fiecărei lansări rulează agile. Proiectele software de întreprindere cu contracte fixe, dar detalii de implementare incerte folosesc hibridul: contractul angajează domeniul și datele, dar cum-ul din interiorul acestor angajamente rulează iterativ. Programele multi-echipă care amestecă echipe de produs agile și echipe de infrastructură Waterfall au nevoie de coordonare hibridă: fiecare echipă își rulează metodologia nativă, cu puncte de sincronizare pe bază de jaloane care le conectează. Ghidul nostru despre managementul hibrid al proiectelor tratează tiparele și capcanele mai în detaliu.

Riscul hibridului este devierea de la intenționat la accidental. O abordare hibridă care specifică cu grijă ce rulează în Waterfall și ce rulează în Agile funcționează bine; o abordare hibridă care amestecă ambele ambiguu pentru că nimeni nu a luat decizia explicit ajunge fără disciplina niciuneia. Rolul PMO în hibrid este să facă granițele explicite: care decizii sunt în stil Waterfall (planificate, aprobate, modificate formal), care sunt în stil Agile (iterative, ajustate continuu) și unde se conectează. Un hibrid bine proiectat combină punctele forte ale ambelor abordări. Un hibrid neglijent moștenește slăbiciunile ambelor.

Cum să alegi metodologia potrivită: un cadru decizional

Selecția metodologiei este una dintre cele mai importante decizii timpurii ale proiectului și este cel mai bine luată sistematic, nu după preferință. Cele patru criterii de mai jos acoperă majoritatea deciziei. Fiecare criteriu împinge către unele metodologii și dinspre altele, iar combinarea lor produce o alegere apărabilă.

Stabilitatea cerințelor

Criteriul de departe cel mai important este cât de stabile sunt de fapt cerințele proiectului (nu cât de stabile pretinde sponsorul că sunt). Cerințele stabile, precum livrabilele reglementate, integrările bine definite sau înlocuirea unui sistem existent cu specificații clare, se aliniază cu Waterfall sau hibrid, unde planificarea în avans surprinde cea mai mare parte a ceea ce se va construi. Cerințele volatile, precum produsele noi, funcționalitățile orientate spre client, transformarea digitală sau orice cu incertitudine de piață, se aliniază cu Agile, Scrum sau Kanban, unde echipa așteaptă și întâmpină schimbarea. În caz de îndoială privind stabilitatea, înclinați spre Agile: costul Agile pe cerințe stabile este o suprasarcină modestă; costul Waterfall pe cerințe volatile este o refacere semnificativă.

Ritmul de lansare și presiunea termenelor

Al doilea criteriu este care trebuie să fie ritmul de lansare. Termenele fixe cu domeniu fix (livrabile contractuale, termene de reglementare, campanii de marketing legate de date specifice) necesită Waterfall sau hibrid, pentru că cer un angajament în avans privind ce se va livra și când. Lansările în loturi predictibile (lansări de funcționalități la fiecare 6-8 săptămâni, versiuni de produs) se potrivesc cu Scrum, pentru că granițele de sprint se aliniază natural cu granițele de lansare. Fluxul continuu fără structură pe loturi (muncă de suport, îmbunătățiri incrementale, muncă condusă de incidente) se potrivește cu Kanban. Frecvența mare de lansare (implementări zilnice sau orare în producție) necesită DevOps, pentru că implementarea manuală nu poate susține ritmul.

Componența echipei și maturitatea agile

Al treilea criteriu este ce poate executa efectiv echipa. O echipă agile matură, cu mai mulți ani de experiență, poate rula Agile complet eficient; o echipă nouă în Agile beneficiază adesea de structura Scrum în timp ce învață, evoluând apoi către metode mai puțin prescriptive. Echipele care amestecă puternic dezvoltarea și operațiunile înclină natural către DevOps, pentru că practicile corespund realității lor. Echipele din medii reglementate cu documentație obligatorie și validare formală se aliniază cu Waterfall sau hibrid indiferent de preferința agile, pentru că cerințele de conformitate au întâietate față de filosofia metodologiei. Componența echipei determină ce este realist, nu doar ce este ideal teoretic.

Contextul portofoliului

Al patrulea criteriu este adesea subevaluat: proiectul nu rulează izolat, ci ca parte a unui portofoliu organizațional cu alte proiecte. PMO-urile rulează de obicei portofolii mixte în care coexistă muncă de produs agile, proiecte de capital Waterfall și inițiative reglementate hibride. Alegerea metodologiei oricărui proiect individual afectează și este afectată de restul portofoliului: un proiect agile care depinde de rezultatele unui proiect Waterfall are nevoie de sincronizare la jaloane; o echipă Kanban care alimentează un tren de lansări Scrum are nevoie de coordonarea predărilor. FlexiProject sprijină portofoliile mixte făcând din Kanban una dintre cele trei vizualizări de planificare (listă de sarcini, diagramă Gantt, Kanban), astfel încât echipe diferite să poată lucra în reprezentarea preferată în timp ce PMO le vede pe toate într-un tablou de bord de portofoliu unificat. Combinat cu integrarea directă cu Jira, acest lucru permite echipelor agile să rămână în Jira pentru munca zilnică, în timp ce sarcinile lor relevante pentru portofoliu apar în FlexiProject alături de proiectele Waterfall.

Întrebări frecvente: metodologia proiectelor software

Care este diferența dintre o metodologie și un cadru de lucru?

O metodologie este o abordare completă de gestionare a unui proiect: faze, roluri, artefacte, ritmuri și tipare de decizie. Un cadru de lucru este o structură mai ușoară care oferă principii și practici fără o prescriere completă. Scrum, de exemplu, este adesea numit cadru mai degrabă decât metodologie pentru că prescrie roluri și evenimente, dar lasă deschise practicile de inginerie. Kanban este similar apropiat de un cadru. Waterfall este fără echivoc o metodologie pentru că prescrie întreaga structură de faze. Agile în sine nu este exact niciuna, ci mai degrabă o umbrelă de valori pe care metodologii și cadre specifice le implementează.

Se pot folosi mai multe metodologii într-un singur proiect?

Da, iar asta formalizează managementul hibrid al proiectelor. Un tipar comun este Waterfall la nivel de proiect (buget fix, jaloane, guvernanță formală) cu Agile la nivel de fază (execuție iterativă în cadrul fiecărei faze). Un altul este Scrum pentru dezvoltarea funcționalităților plus Kanban pentru suportul continuu al aceluiași produs. Cheia este proiectarea deliberată: a specifica care metodologie se aplică unde și cum se conectează granițele. Amestecul superficial tinde să producă ce e mai rău din ambele în loc de ce e mai bun.

Care metodologie este cea mai bună pentru echipele mici?

Echipele mici (2-6 persoane) beneficiază de obicei de Kanban pentru că are cea mai mică suprasarcină obligatorie: fără roluri dincolo de cele pe care echipa le are, fără evenimente dincolo de cele pe care le alege, doar vizualizare, limite WIP, gestionarea fluxului, politici explicite, revizuiri regulate și îmbunătățire continuă. Echipele mici care dezvoltă produse noi folosesc adesea un Scrum ușor cu roluri combinate (o persoană joacă Product Owner și Scrum Master, de exemplu). Echipele mici cu contracte cu domeniu fix pot folosi în continuare Waterfall pentru simplitatea guvernanței, deoarece suprasarcina Agile poate fi disproporționată pentru livrări simple.

Cum se raportează DevOps la Agile?

Agile și DevOps sunt complementare, nu concurente. Agile este o metodologie de organizare a muncii de dezvoltare (cicluri iterative, planificare adaptivă, colaborare cu părțile interesate). DevOps este un set de practici de integrare a dezvoltării și operațiunilor (pipeline-uri automatizate, livrare continuă, infrastructură ca cod). Majoritatea organizațiilor software moderne rulează ambele: Agile pentru planificare și prioritizare la nivel de echipă, DevOps pentru livrare și operațiuni pe tot ciclul de viață al software-ului. Niciuna nu o înlocuiește pe cealaltă; rezolvă probleme diferite pe straturi diferite ale procesului de livrare software.

Ce rol joacă un PMO în selecția metodologiei?

Rolul PMO este să ofere îndrumare de selecție fără a impune o singură metodologie. Proiecte diferite din portofoliu beneficiază de metodologii diferite, iar forțarea tuturor proiectelor într-o singură abordare reduce de obicei performanța globală a portofoliului. Contribuția PMO include: criterii de selecție (cadre precum cel din acest articol), standarde la nivel de portofoliu valabile între metodologii (ritmuri de guvernanță, raportarea costurilor, categorizarea riscurilor), instrumente care sprijină mai multe metodologii simultan și mentorat pentru echipele care aleg o metodologie pentru prima dată. PMO deține cadrul; echipele dețin alegerea în cadrul lui.

Metodologia potrivită pentru un proiect software este cea care se potrivește stabilității cerințelor, ritmului de lansare, componenței echipei și contextului de portofoliu al proiectului, nu cea cu cel mai bun marketing sau cu cei mai vocali susținători din echipă. Waterfall funcționează pentru muncă predictibilă, condusă de plan, cu cerințe stabile. Agile funcționează pentru muncă adaptivă, iterativă, cu cerințe în evoluție. Scrum funcționează pentru echipe care construiesc într-un ritm predictibil. Kanban funcționează pentru muncă continuă condusă de întreruperi. DevOps funcționează pentru livrare cu frecvență mare care integrează dezvoltarea și operațiunile. Hibridul funcționează când o singură metodologie nu se potrivește condițiilor reale ale proiectului. Cercetarea Power Skills a PMI a constatat că 9 din 10 profesioniști de proiect cred că abilitățile interpersonale, precum comunicarea, empatia, adaptabilitatea și leadershipul, îi ajută să lucreze mai inteligent, iar metodologia singură nu le înlocuiește niciodată. Cea mai bună metodologie în mâini greșite dă randament mai slab decât o metodologie imperfectă în mâini competente. Metodologia dă structură; oamenii livrează rezultate. FlexiProject sprijină întreaga gamă de metodologii prin trei vizualizări de planificare (listă de sarcini, diagramă Gantt, Kanban) între care echipele pot comuta pe măsură ce tiparul lor de lucru evoluează, și o integrare directă cu Jira care menține munca echipelor agile vizibilă la nivel de portofoliu fără a forța echipele să iasă din instrumentele preferate. Alegeți metodologia care se potrivește proiectului; investiți în oamenii care îl vor executa; folosiți instrumente care le sprijină pe ambele. Acesta este tiparul care duce proiectele în cele 34% care își respectă angajamentele în loc de cele 66% care eșuează.