În timpul sprintului, toate lucrările necesare pentru a obține o versiune funcțională a produsului trebuie să fie finalizate. Scopul unui sprint ar trebui să fie fixat. Datorită acestui fapt, echipa își poate asuma responsabilitatea pentru implementarea acesteia. Pe baza acestui fapt, restul de sprint nu poate fi modificat de nimeni, cu excepția echipei.

Puteți afla despre toate acestea în detaliu din cartea „Scrum - o metodă revoluționară de management de proiect” de Jeff Sutherland, iar noi vom continua conversația pe tema practicilor. Odată ce vă familiarizați cu acestea, veți putea înțelege cum este implementat un proiect Scrum.

Întâlniri zilnice Scrum

Întâlnirile zilnice au loc dimineața înainte de începerea lucrărilor. Sunt necesare pentru ca fiecare membru al echipei să știe cine face exact ce în proiectul curent. Durata optimă a unor astfel de întâlniri este de 15 minute. Nu se rezolvă probleme în acest proces, deoarece... participanții pur și simplu împărtășesc informații. Dacă există probleme care necesită rezolvare, acestea sunt luate în afara ședinței.

Scrum Master conduce întâlniri zilnice. La rândul său, el pune fiecărui participant următoarele întrebări:

• Ce ai făcut ieri?
• Ce vei face astăzi?
• Ce probleme ati intampinat?

Toate întrebări deschise Scrum Master adaugă „Elemente de acțiune” la listă. Formatul „Ce? OMS? Când?". Iată un exemplu simplu de astfel de listă:

• Discutați detaliile de design de fundal
• Tolia și Kolya
• Imediat după prânz

Oricine poate participa la întâlnirile zilnice parte interesată, cu toate acestea, toate deciziile sunt luate numai de membrii echipei de dezvoltare. Motivul pentru aceasta este angajamentul participanților pentru atingerea obiectivului de sprint. Dacă altcineva contribuie la luarea deciziilor, el va elimina astfel responsabilitatea membrilor echipei.

Întâlniri de revizuire Sprint

La sfârșitul fiecărui sprint, este obișnuit să organizați o întâlnire demonstrativă pentru a revizui sprintul. Durata optimă a acestor întâlniri nu este mai mare de 4 ore.

La începutul întâlnirii, echipa de dezvoltare îi arată proprietarului produsului versiunea sa de lucru (demonstrează rezultatele muncii depuse). Întâlnirea are loc sub controlul proprietarului însuși, iar acesta are dreptul de a invita la ea toate persoanele interesate și reprezentanții acestora.

În timpul întâlnirii, proprietarul produsului evaluează ce cerințe din backlog-ul de sprint au fost îndeplinite, discută rezultatele cu echipa și clientul și, împreună cu aceștia, planifică sarcinile care urmează să fie finalizate în noul sprint.

În a doua jumătate a întâlnirii, Scrum Master, împreună cu ceilalți participanți, analizează sprintul trecut. Echipa de dezvoltare le determină, le analizează, trage concluzii și ia decizii care vor îmbunătăți munca ulterioară.

La sfârșitul întâlnirii, rezultatele sunt rezumate și următorul sprint este planificat (acest lucru se întâmplă conform algoritmului obișnuit de planificare a sprintului despre care am discutat deja). După finalizarea celui de-al doilea sprint, are loc o nouă întâlnire demonstrativă și așa mai departe într-un cerc până când proiectul Scrum este complet finalizat.

Sprint oprire de urgență

O oprire de urgență la sprint este necesară doar în cazuri speciale. Echipa poate opri sprintul înainte de termenul limită (termenul limită de finalizare a sprintului) dacă realizează că nu este posibilă atingerea rezultatelor stabilite pentru acest sprint. Sprintul poate fi, de asemenea, oprit de proprietarul produsului dacă nu mai este nevoie să atingeți obiectivul de sprint.

Dacă sprintul este oprit, toți participanții la proiect se adună la o adunare generală, discută motivele opririi și actiunile urmatoare. După aceasta, se dă voie pentru a începe un nou sprint și a-l planifica, pentru care se folosesc aceiași algoritmi.

Este ușor de observat că practicile Scrum sunt destul de simple. Dar, pe lângă roluri și practici în managementul proiectelor Scrum, există și documente importante, numite artefacte. Le-am menționat deja pe scurt, dar va fi mai bine dacă ne aprofundăm puțin în acest subiect.

Artefacte în Scrum

În orice proiect Scrum există trei artefacte (documente) principale:

• Restante produs
• Sprint Backlog
• Graficul Sprint (Grafic Burndown)

Fiecare dintre artefacte are propriile sale caracteristici.

Jurnal de produs

Backlogul de produse este pregătit chiar de la începutul proiectului. Este o listă de cerințe sortate după importanță. Este compilat de proprietarul produsului, iar echipa de dezvoltare îl completează, inclusiv estimări ale costului implementării fiecărei cerințe.

Restul de produse ar trebui să includă cerințele tehnice și funcționale necesare dezvoltării sale. Aceste cerințe trebuie prioritizate, iar cele cu cea mai mare prioritate trebuie notate în detaliu, astfel încât echipa să aibă posibilitatea de a le evalua și testa.

Detalierea în timp util și pregătită a proiectelor, precum și livrarea lor integrală și la momentul potrivit, sunt sarcinile proprietarului produsului.

Jurnal de sprint

Backlogul de sprint reflectă funcționalitatea pe care proprietarul produsului a selectat-o ​​din stocul de produse compilat anterior. Fiecare funcție este împărțită în sarcini. Defalcarea se face astfel încât să nu dureze mai mult de două zile pentru a finaliza o sarcină.

Datorită unei împărțiri de înaltă calitate a funcțiilor în sarcini, sprintul poate fi planificat în așa fel încât până la sfârșitul acestuia să nu rămână nimic nefăcut, ceea ce înseamnă că obiectivul de iterație este atins.

Odată ce detalierea este finalizată, stocul de sprint este estimat și această estimare este comparată cu estimarea inițială a stocului de produse. Când sunt identificate discrepanțe semnificative, echipa de dezvoltare lucrează cu proprietarul produsului pentru a determina cantitatea de muncă care trebuie finalizată în timpul unui anumit sprint, precum și cantitatea care poate fi reportată la următoarea iterație.

Sarcinile minore care nu au un impact prea mare asupra atingerii obiectivului de iterație sunt excluse din stocul de sprint.

Programul de sprint

Este necesară o diagramă de sprint pentru a arăta modificarea zilnică a muncii totale rămase până la sfârșitul sprintului. Cu ajutorul ei, echipa poate analiza situația actuală și poate răspunde la schimbări în timp util.

În plus, folosind programul de sprint, proprietarul produsului poate urmări progresul iterației. Prin urmare, este foarte ușor pentru el să stabilească: dacă volumul de muncă nu scade în fiecare zi, înseamnă că există unele abateri în proces și acțiunile echipei trebuie urgent ajustate.

Acestea sunt caracteristicile generale ale metodologiei Scrum. Dacă doriți să înțelegeți această metodă mai detaliat, atunci Jeff Sutherland vă va ajuta cu aceasta - consultați cartea deja menționată „Scrum - o metodă revoluționară de management de proiect”. Și nu putem decât să rezumam acest lucru prezentare scurta Scrum.

Concluzii despre Scrum

Deci, legat de sistemul de metode management flexibil Agil, Scrum poate fi numit în siguranță o adevărată descoperire pentru persoanele ale căror activități sunt legate de proiecte. Printre avantajele sale, în primul rând, se remarcă orientarea și adaptabilitatea. Metoda vă permite să modificați oricând cerințele proiectului (chiar dacă nu garantează că aceste modificări vor fi implementate). Și această oportunitate este foarte atractivă pentru clienți.

În al doilea rând, Scrum este foarte ușor de învățat. În plus, metoda nu necesită mult timp. Și datorită faptului că sistemul de lucru este construit pe un principiu iterativ (și fiecare iterație are propriul scop), folosind metoda Scrum poți obține versiuni de lucru ale produsului la sfârșitul fiecărui sprint.

În al treilea rând, accentul în metodă se pune pe o echipă multifuncțională și auto-organizată, care este capabilă să rezolve majoritatea problemelor cu un minim de coordonare. Acesta este motivul pentru care proiectele Scrum sunt potrivite pentru startup-uri și firme mici, scutindu-i de nevoia de a forma un personal specializat de manageri sau de a angaja profesionisti din afara.

Dar nu ar trebui să credeți că metodologia Scrum este soluția tuturor problemelor și o garanție a succesului. Are și câteva dezavantaje. De exemplu, minimalismul și simplitatea acestuia determină, deși puține, dar totuși stricte reguli, în special regulile de interacțiune în cadrul echipei, care în unele cazuri pot provoca anumite inconveniente clientului.

Un alt dezavantaj este lipsa unui plan, deoarece toate acțiunile participanților la proiect sunt realizate în timp real. Și, în sfârșit, concentrarea asupra echipei nu este întotdeauna utilă. Deși nu există o nevoie specială de coordonare a echipei (și, prin urmare, nu există costuri pentru aceasta), costurile de recrutare, formare și motivare a personalului pot crește. Dacă, de exemplu, nu există destui specialiști potriviți pe piața muncii, va trebui să angajezi fie profesioniști scumpi, fie să nu angajezi pe nimeni.

Cu toate acestea, avantajele metodologiei Scrum nu pot fi comparate cu dezavantajele acesteia, iar cu o anumită persistență, stăpânirea acesteia nu va fi dificilă. Utilizarea Scrum ajută companiile să implementeze o varietate de proiecte și să devină mai competitive. Metoda este axată pe schimbare și dezvoltare constantă, iar flexibilitatea sa este obținută prin interacțiunea continuă a participanților la proiect între ei.

Dar permiteți-ne să vă reamintim că această recenzie are doar scop informativ, prin urmare, pentru a obține Informații suplimentareÎn orice caz, va trebui să apelezi la surse terțe. Și de la ei puteți afla despre alte complexități ale managementului de proiect Scrum și despre caracteristicile aplicației sale. Puteți începe cu acest scurt videoclip și vă dorim mult succes și implementare cu succes a tuturor proiectelor dumneavoastră!

Cea mai cunoscută carte pe această temă, în traducere rusă, este cunoscută sub numele de „Scrum. O metodă revoluționară de management de proiect”, care conține o definiție care provoacă adesea critici. În original, subtitlul este diferit: „Arta de a face de două ori mai multă muncă de două ori mai repede”. Aici Scrum nu se numește metodă și nu vorbim despre managementul proiectelor. Cu toate acestea, această versiune a interpretării într-un context mai larg este, de asemenea, justificată. Mai ales dacă se ia în considerare o zonă de dezvoltare neîngustă software(software) și abordarea care stă la baza cadrului, care se extinde cu ușurință la aproape orice tip de activitate colectivă.

Scrum: Pierdut în traducere

Scrum (pronunțat „scrum” în rusă) este un termen care în rugby se referă la figura creată de jucători în timpul jocului, iar în afaceri a fost inventat de autorii Jeff Sutherland și Ken Schwaber ca un cadru pentru un proces eficient de dezvoltare a software-ului. Descrierea oficială a Scrum nu oferă îndrumări cu privire la ce trebuie făcut în orice situație, iar unele întrebări rămân fără răspuns (de exemplu, indică necesitatea de a estima timpul alocat procesului, dar nu specifică tipul de estimare). Prin urmare, vorbirea despre Scrum ca o metodologie cuprinzătoare în sensul clasic al cuvântului trebuie făcută cu prudență.

Dezvoltatorii de software înșiși numesc adesea Scrum cadru, adică atât o platformă care determină structura unui sistem software, cât și un fel de formă organizațională care permite structurarea conținutului procesului. În această a doua accepțiune a „un model-formă pentru structurarea conținutului activităților colective” Scrum a început să fie utilizat în alte industrii comerciale și necomerciale. Acolo, după ce a fost completată cu conținutul său, structura de management a primit titlul de metodologie.

Cadrul universal Scrum

Managementul produsului în Scrum constă din mai mulți pași care sunt universali pentru fiecare context.

1. Este selectat un „Product Owner” - o persoană care devine legătura dintre piață (clientul produsului sau utilizatorul final) și echipa de performeri. Această persoană este responsabilă pentru adăugarea de valoare produsului și vede viziunea de ansamblu de la început.
2. Se formează o echipă de interpreți, a căror competență trebuie combinată cu capacitatea de a lucra în mod coordonat.
3. Scrum Master este hotărât. Aici maestrul este un administrator care monitorizează evoluția muncii în echipă, dar nu este comandant, ci ajută la pregătire, asigură întâlniri programate etc.
4. O listă de cerințe pentru obiectiv și produs este creată cu elementele prioritizate. Această listă se modifică pe măsură ce proiectul progresează.
5. Membrii echipei evaluează fiecare element de pe listă, hotărând cât timp și resurse materiale vor fi necesare pentru a finaliza sarcina.
6. Proprietarul produsului, maistrul și membrii echipei țin o întâlnire în care este planificată o discuție comună pentru un sprint - o etapă scurtă (nu mai mult de o lună în practica dezvoltatorilor de software) pentru care se preconizează rezolvarea unei anumite părți a problemelor. . În unele contexte, această etapă se numește iterație. Se presupune că în timpul fiecărei iterații de sprint echipa acumulează un anumit număr de puncte, pe care este de dorit să le crească în următorul sprint pentru a demonstra o creștere a productivității.
7. Pentru a informa toți participanții la proces, este creat un panou informativ, plin cu note lipicioase, care împarte ceea ce trebuie făcut, ceea ce este în desfășurare și ceea ce s-a făcut. Pe măsură ce sarcinile sunt finalizate, autocolantele sunt mutate dintr-o coloană în alta.
8. Mic de statura adunările generale se tin zilnic. Aceștia își exprimă obstacolele pe parcurs, determină ce a fost deja făcut în beneficiul proiectului și ce este planificat.
9. Fiecare sprint se încheie cu o trecere în revistă detaliată a muncii și, la fel de important, cu o discuție despre performanța procesului din sprintul anterior. Dacă ceva poate fi îmbunătățit, se discută despre inovații care vizează optimizare și vor fi implementate în următorul sprint.

Pentru ca o astfel de schemă să fie viabilă, metodologia de management Scrum trebuie să fie compusă dintr-un număr de componente:

• Filosofia Scrum, care a inclus de-a lungul timpului valorile și principiile manifestului Agile (autorii metodologiei s-au numărat printre cei 17 autori care au semnat celebrul manifest),
• cerințe într-un format dat,
• un anumit algoritm de acțiuni cu repartizarea rolurilor în echipă,
• tip special de relație de muncă,
• înțelegerea specifică a unei etape individuale de lucru,
• instrumente adecvate acestei metodologii.

În funcție de zona în care este implementată metodologia de management Scrum, caracteristicile unor componente pot diferi. De exemplu, numărul de interpreți dintr-o echipă, unele instrumente de contabilitate sau sistemul de puncte variază. Dar punctele cheie și cadrul cadrului Scrum ar trebui să rămână neschimbate.

Baza filozofică a Scrum

Managementul produselor în Scrum la nivel ideologic urmărește un anumit mod de viață și un anumit mod de activitate. Autorul cărții despre metoda Scrum era pasionat de artele marțiale japoneze, iar această pasiune s-a reflectat în atitudinea sa față de munca sa, care nu mai era doar despre a câștiga bani. Lucrul în stilul Scrum (cum ar fi Aikido) este o modalitate de îmbunătățire continuă prin exercițiu care luptă pentru unitatea corpului și a minții.

Fundamentele ideologice ale Scrum au fost mai târziu exprimate mai clar în manifestul Agile. A enumerat 4 valori și 12 principii pe care autorii manifestului au cerut să le urmeze. Primul loc în sistemul de valori a fost acordat:

• oamenii și interacțiunile lor,
• produs de lucru
• colaborare live cu clientul,
• dorinta de schimbare si schimbare.

Aceste valori nu au fost opuse, ci au fost identificate ca fiind mai importante în raport cu aderarea formală la modelul procedural și alegerea instrumentelor, aderarea la procedura birocratică și aderarea la planul inițial.

S-a presupus că, dacă practica face ajustări în fiecare etapă, iar acest lucru face produsul mai bun și mai valoros, iar consumatorii mai fericiți, atunci această practică este mai bună decât planificarea rigidă. Abordarea Agile a reunit o familie de modele bazate pe valori articulate. Scrum a fost și rămâne parte a acestei familii de modele.

Roluri în Scrum

Abordarea Scrum presupune distribuirea a trei roluri între participanții la proiect.

1. Proprietarul produsului. Această persoană este numită „proprietar de produs” deoarece devine singurul care ia decizia finală (deci acest rol nu este de obicei delegat unui grup de oameni). De asemenea, conduce proiectul în ansamblu și este angajat în creșterea valorii produsului pentru piața (clientul) pe care îl reprezintă. Performantul acestui rol trebuie să atribuie sarcini echipei pentru sprint, dar nu atribuie sarcini unui anumit performer. Adică, proprietarul produsului gestionează produsul, nu echipa.
2. Scrum Master. Rolul maistrului nu presupune nici posibilitatea de a atribui sarcini unui anumit executant, întrucât echipa, urmând principiile demersului, trebuie să se manifeste ca un organism auto-organizat și autoguvernant. Rolul său în muncă este mai apropiat de cel al unui administrator:
3. Echipă. O echipă Scrum din acest model este interfuncțională și se autogestionează. Nu există o persoană specială care să-i organizeze munca. În ceea ce privește domeniul dezvoltării software, echipele, de regulă, sunt formate din 5-9 persoane (în medie șapte) specialiști în diverse domenii (analiști, dezvoltatori, testeri). În ciuda diversității specialiștilor din cadrul echipei, Team funcționează ca un întreg, iar rezultatele activităților sale sunt, de asemenea, evaluate ca rezultat al muncii de ansamblu.

În alte domenii de afaceri care au adoptat modelul Scrum, ei încearcă să mențină acest standard cantitativ, deoarece este dificil pentru o echipă mai mare să se organizeze și să funcționeze eficient. Nu e de mirare în celebrul joc Ce? Unde? Când? autorul ei, V. Voroshilov, în elaborarea regulilor, s-a stabilit pe cei șase experți ca fiind cea mai eficientă unitate colectivă funcțională.

În cazul scalării atunci când rezolvă probleme multifațete foarte intensive în muncă, ei încearcă totuși să nu mărească numărul de oameni din echipa Scrum, ci să organizeze un sistem de mai multe echipe pentru lucru. Printre altele, acest lucru este explicat de „Legea Brooks”, conform căreia, dacă echipa nu are timp să finalizeze proiectul la timp, atunci adăugarea mai multor interpreți întârzie proiectul și mai mult.

Caracteristicile etapelor de lucru

Lucrarea la proiect și managementul timpului implică faze de planificare, sprinturi și debriefing de sprint.

În modelul Scrum, procesele și activitățile implică transparență. Pentru ca toată lumea să poată vedea totul în timp real, este introdus un set de instrumente specific - o tablă cu coloane, pe care procesul este ilustrat prin rearanjarea autocolantelor. În versiunea avansată, lista panourilor informative este extinsă.

Lista artefactelor Scrum include 4 instrumente:

Toate etapele, procesele (ritualurile) și tehnologia de utilizare a instrumentelor sunt importante pentru viabilitatea modelului. Managementul proiectelor Scrum oferă un efect maxim prin implementarea cuprinzătoare și sistematică a tuturor componentelor.

• maestrul lucrează pentru a crea o atmosferă de încredere în echipă, în timp ce alții își rezolvă problemele,
• înlătură obstacolele
• ridică, formulează și aduce în discuție contradicții ascunse,
• devine legătura dintre managerul de proiect și echipă.

Scrum este cea mai eficientă și populară metodologie de management de proiect pentru dezvoltare sisteme de informareși software.

Creată relativ recent, tehnica și-a câștigat inițial popularitate datorită utilizării sale în activitatea corporațiilor tehnologice avansate Apple și Google. Acum este utilizat pe scară largă în diferite tipuri de companii online digitale, startup-uri mici, proiecte tradiționale și non-profit, primind o recunoaștere binemeritată, deoarece utilizarea sa a crescut semnificativ eficiența dezvoltării proiectelor și sarcinilor.

Care este esența metodologiei Scrum?

Autorii acestei tendințe revoluționare, Jeff Sutherland și Ken Schwaber, au introdus conceptul de Scrum, împrumutându-l de la faimosul joc de echipa„rugby”. În termeni simpli, înseamnă lucrul în echipă coordonat și responsabil al unei echipe într-un proiect.

Metodologia face posibilă utilizarea cât mai eficientă a forței de muncă și a resurselor materiale disponibile ale echipei, a întregului potențial tehnic al acesteia, atunci când personalul este împărțit în grupuri, fiecare fiind responsabil de direcția sa specifică.

În consecință, managerul de proiect controlează și coordonează munca tuturor echipelor, gestionează procesele de dezvoltare și discutare a ideilor și controlează progresul acestora către rezultatul final. Această metodă vă permite să colectați în mod competent toate datele necesare, să exercitați controlul deplin și stăpânirea situației privind implementarea proceselor de lucru și, dacă este necesar, să stabiliți motivația potrivită pentru angajați.

Adesea, lipsa de coerență și lipsa de înțelegere a obiectivului final de dezvoltare, de regulă, duc la încălcări ale planurilor și programelor de lucru, o creștere a bugetului și crearea unui microclimat intern nesănătos în echipă.

Metodologia Scrum, care a fost creată ca o alternativă la abordarea clasică învechită de implementare etapă cu etapă a proiectelor și sarcinilor, este concepută pentru a elimina toate aceste probleme. Folosind-o, echipa de dezvoltare va putea scăpa pentru totdeauna de disputele inutile, pierderea de timp prețios, executarea de duplicate ale acelorași sarcini de către diferite grupuri, precum și multe alte probleme în curs.

Prin analogie cu jocul de rugby, autorii metodologiei invită toți membrii echipei să „intră în luptă, să acționeze armonios și să aducă jocul la rezultatul dorit”. Acest lucru necesită o înțelegere clară a scopului urmărit și unitatea intențiilor tuturor membrilor. Doar în acest caz lucru in echipa devine de succes și vă permite să faceți mult mai mult în mai puțin timp.

Manifestul metodologiei agile, principiile sale de bază.

Acestea includ următoarele puncte:

• Prioritatea principală este satisfacerea tuturor nevoilor clienților.
• Proiectele se bazează pe echipe de profesioniști autonome, fără superiori sau șefi, unde membrii echipei au drepturi egale și toate deciziile sunt luate colectiv, pe baza votului comun. În acest caz, procesul de formare a echipelor este reflectat mai pe deplin și devine imediat evident cine se străduiește să obțină rezultate și cine este pur și simplu în echipă și o trage în jos.
• Un produs funcțional care satisface toate nevoile clienților este un indicator fundamental al progresului.
• Pentru a face treaba eficient, trebuie să aveți încredere în dezvoltatori în tot. Acesta este ceea ce va crea condiții optime pentru o soluție rapidă a problemelor complexe, bazată pe o înțelegere completă a esenței ideii în sine de către toți participanții la proces.
• Simplitatea și un minim de muncă inutilă este un element necesar.
• Echipele analizează sistematic modalități de a îmbunătăți eficiența, de a îmbunătăți calitatea designului și de a-și ajusta stilul de lucru.
• Un proces continuu de schimb de informații între proprietarii de produse, dezvoltatori și utilizatorii finali, menținând un ritm de lucru și zilnic. colaborare contribuie la creșterea excelenței tehnice.
• Produsul de lucru ar trebui să fie lansat cât mai des posibil, iar modificările cerințelor ar trebui permise în toate etapele de dezvoltare.

Valori metodologice SCRUM

Efectul pozitiv al utilizării tehnologiei Scrum se realizează prin acțiunea sistemului de valori expus în celebrul manifest:

• Oamenii sunt un factor mai important în obținerea rezultatelor decât procesele în sine . Angajații care sunt nemulțumiți de ceea ce fac, problemele respingătoare și nevoile clienților, deseori strica totul mult mai mult decât procesele structurate incorect din companie.
• Produsul este mai important decât documentația . Crearea unor volume mari de documentație duce la întârzieri în finalizarea lucrărilor, dar nu va ajuta în niciun fel echipa să creeze exact produsul de care are nevoie consumatorul.
• Comunicarea și cooperarea cu clientul este mai importantă decât contractul scris. Pentru a implementa cu succes un proiect și a crea un produs de înaltă calitate, este necesar, în primul rând, să organizați o interacțiune strânsă cu clientul, să îl implicați în proces, astfel încât să poată participa direct la lucru și să înțeleagă perspectivele pentru obtinerea rezultatului dorit. Este necesar să construiți relații strânse și de încredere, să deveniți parteneri amabili și onești, iar în acest caz nu va trebui să cheltuiți mult timp și bani pentru întocmirea și încheierea unui contract.
• Abilitatea de a face schimbări flexibile este mai importantă decât executarea planurilor. Planurile întocmite și aprobate inițial se pot schimba dramatic în timp, și este important să vă îndreptați pas cu pas către obiectivul dvs., fără a încerca să-l anticipați pe termen lung. În acest caz, va fi posibil să evitați eșecurile stupide și să nu adăpostiți iluzii inutile.
• Ceea ce faci este mai important decât ceea ce ai poziții înalteși regalii. Când vine vorba de activitățile practice de creare a unui produs care este dezvoltat de profesioniști pasionați în domeniul lor, șefi clasici cu poziții de mare profil și regalii în conditii moderneîși pierd rolul, ierarhiile sunt desființate, iar organizațiile capătă un statut plat.

Metodologia Scrum creează încredere, conducând la dezvoltarea interactivă și la crearea de valoare autentică. În jurul principiilor sale cheie se dezvoltă diverse instrumente care permit obținerea rezultatelor dorite în cel mai scurt timp posibil și la cel mai mic cost.

Roluri în SCRUM

Metodologia Scrum este împărțită în anumiți indicatori de rol care sunt îndepliniți de participanții la proiect și anume:

• Proprietarul produsului este un fel de „legătură” între consumatorii finali și dezvoltatorii de proiecte. El este responsabil pentru elaborarea conceptului și, de asemenea, comunică cu echipa de dezvoltare și clienții, discutând actual și probleme controversate. Ia decizii și este responsabil pentru valoarea produsului. Pentru a obține un rezultat eficient care ajută la extragerea de profituri maxime, trebuie să aveți o înțelegere excelentă a pieței și să aveți o serie de puteri de decizie. Prin urmare, la dezvoltarea proiectelor mari, de regulă, sunt implicați mai mulți proprietari de produse.
• Echipa de dezvoltare a produsului, de ex. implementatorii directi ai proiectului. Responsabil pentru ritmul, timpul și calitatea muncii.
• Scrum Master. Aceasta este o persoană responsabilă care monitorizează progresul proiectului și ajută echipa în rezolvarea și eliminarea diferitelor tipuri de obstacole și probleme. De asemenea, ea este angajată în creșterea eficienței muncii sale, identificarea punctelor de creștere și promovarea motivației angajaților. Organizează toate întâlnirile și conferințele.

Planificare în SCRUM

Procesul începe cu adunarea echipei potrivite și întocmirea unei liste de cerințe pentru produsul în curs de dezvoltare, care determină mișcarea către obiectivul final. După care sarcinile sunt aranjate în ordinea priorităților; daca este necesar cel putin Puncte importante poate fi sters.

Planificarea se realizează de obicei în mai multe etape:

1. Alegerea unui proprietar de produs.
2. Crearea de echipe de profesionisti, inclusiv toti specialistii necesari pentru finalizarea proiectului.
3. Alegerea unui Scrum Master.
4. Crearea unei liste de cerințe (backlog) pentru produs, plasând fiecare articol în conformitate cu prioritate. Această listă se poate modifica pe măsură ce lucrările progresează.
5. Evaluare backlog. Clarificarea dimensiunilor proiectului. Membrii echipei evaluează toate articolele din listă și iau în considerare toate costurile materiale și timp pentru crearea fiecăruia dintre ele.
6. Planificarea sprinturilor (etape de timp pentru îndeplinirea sarcinilor individuale). Determinarea obiectivelor prioritare de sprint, a volumelor, a calendarului și a vitezei de finalizare a lucrărilor. Scor efectuarea de sprinturi.
7. Crearea unei table Scrum și a diagramei de execuție a sarcinilor. Toate sarcinile care sunt în desfășurare, deja făcute sau pe cale de a fi finalizate sunt marcate cu note lipicioase și plasate în coloanele corespunzătoare de pe tablă.
8. Întâlniri operaționale zilnice (întâlniri scurte cu rapoarte, identificarea dificultăților, sarcini planificate pentru ziua respectivă).
9. Revizuirea sprintului (demonstrația părții finalizate a proiectului finalizată în timpul acestui sprint).
10. Spectacol retrospectiv (prezentarea sprintului finalizat, discutarea aspectelor de lucru pentru implementarea îmbunătățirilor).

În funcție de domeniul de aplicare al metodologiei, unele puncte se pot modifica sau pot fi șterse, dar etapele cheie și cadrul structurii rămân întotdeauna aceleași.

Lucru în echipă în SCRUM

Esența muncii în echipă

Metodologia Scrum presupune deschiderea completă a informațiilor, inclusiv a informațiilor financiare, și absența oricărei manifestări de ierarhie.

Spre deosebire de structurile ierarhice închise, echipele Scrum preferă să dezvăluie pe deplin toate informațiile și cunoștințele despre procesul care se desfășoară: cât de multă muncă s-a făcut până acum, în ce volume, ce s-a făcut și cum, ce trebuie făcut și în ce timp cadru.

Acest lucru permite echipelor să fie bine conștiente de propria dinamică a sarcinilor pentru a lucra în mod coerent, a rezolva rapid problemele care apar și a obține rezultatul dorit în cel mai scurt timp posibil.

Caracteristicile echipei

Cele mai bune echipe au următoarele caracteristici:

• Autonomia și capacitatea de a se autoorganiza, de ex. echipa decide singură cum să ajungă cel mai bine la obiectiv.
• Căutarea excelenței în fluxul de lucru.
• Multifuncționalitatea echipei și prezența unei culturi de asistență reciprocă și interschimbabilitate. Echipa a selectat oameni care pot acumula abilitățile necesare pentru a îndeplini sarcinile.
• Ordinea sarcinilor.
• Fără procesare.
• Lucrul în „flux” este o stare de cea mai mare concentrare creativă.

Dimensiunile echipei

Munca în echipă se realizează cu succes numai dacă există o echipă mică, bine coordonată. Pentru ca proiectul tău să se dezvolte cu succes, vei avea nevoie de 7-8 persoane care să lucreze la el.

Dacă numărul de angajați este mai mic, atunci productivitatea muncii va scădea semnificativ.

Cu un număr mai mare de oameni, sunt probabil să apară diferite tipuri de probleme: cu comunicarea, timpi diferiți de adaptare și costuri mari. Cu un termen limită strâns, adăugarea de angajați suplimentari în echipă nu va face decât să încetinească viteza proiectului.

De ce SCRUM

Metodologia Scrum ajută echipele să rezolve rapid orice problemă în fiecare etapă de lucru din proiect, să găsească și să selecteze soluții optime la probleme complexe.

Vă permite să minimizați semnificativ riscurile în relațiile cu clientul, deoarece asigură livrarea pas cu pas a proiectului, feedback la timp din partea clientului, iar produsul este demonstrat și aprobat în toate etapele existente de dezvoltare.

În acest caz, proprietarul produsului nu va trebui să cheltuiască mult timp și bani pentru a înțelege că proiectul său nu funcționează conform așteptărilor.

Pentru a rezuma, putem concluziona că metodologia Scrum încurajează echipa să fie mai activă și mai fructuoasă în proiect, ajută la găsirea de noi puncte de creștere și depune eforturi pentru a-și îmbunătăți constant cunoștințele și abilitățile.

Cartea „Scrum. A Revolutionary Project Management Method” a fost scris de Jeff Sutherland, fondatorul metodologiei Scrum. Cartea vă va ajuta să implementați proiecte de câteva ori mai rapid și mai eficient. Poate că istoricii viitorului vor împărți progresul omenirii cu o linie clară: „înainte de Scrum” și „după” - această tehnică este atât de revoluționară. Este folosit de majoritatea companiilor de tehnologie din lume, dar acum este disponibil pentru toți cei care se ocupă cu proiecte complexeîn orice industrie.

Jeff a inventat metodologia Scrum în încercarea de a depăși neajunsurile managementului de proiect clasic: rareori oamenii reușesc să lucreze coeziv, eficient și rapid, majoritatea planurilor nu sunt implementate (fie din punct de vedere al timpului, fie al resurselor), departamentele și echipele desfășoară deseori conflicte sau sarcini duplicative.

Timp de 20 de ani, metodologia Scrum a ajutat nu numai majoritatea dezvoltatorilor de software, ci și FBI, producătorii de automobile, farmaciștii și oameni normali planificându-și treburile.

Cartea „Scrum. O metodă revoluționară de management de proiect vă va revoluționa complet abordarea față de managementul proiectelor și vă va ajuta să obțineți rezultate care anterior păreau imposibile. Nu contează dacă vrei să schimbi sistemul educațional, să inventezi noi tehnologii, să lupți cu foamea, să deschizi doar un startup sau să-ți gestionezi echipa mult mai eficient - Scrum te va ajuta să obții mai mult, cheltuind mai puțin timp și resurse.

Despre autorul cărții „Scrum. O metodă revoluționară de management de proiect”

Jeff Sutherland este consilier al OpenView Venture Partners și șeful Scrum, Inc. și autorul metodologiei Scrum, pe care o descrie în cartea sa. A dezvoltat tehnica în 1993 și a oficializat-o în 1995 cu Ken Schwaber.

Metodologia Scrum a fost și este folosită de companiile de software din întreaga lume. Dar Jeff și-a dat seama că Scrum ar putea beneficia mai mult decât doar companiile IT și l-a adaptat pentru alte industrii - finanțe, asistență medicală, educatie inalta, telecomunicatii. El se consultă cu multe companii, ajutându-le să construiască echipe extrem de productive. Jeff a lucrat ca CTO pentru unsprezece companii de tehnologie.

Citate din carte

Metodologie

Scrum accelerează ritmul tuturor eforturilor umane. Indiferent care este proiectul sau problema, Scrum poate fi folosit în orice efort de a îmbunătăți productivitatea și de a obține rezultate mai bune.

Întâlniri

Reunește-te timp de cincisprezece minute în fiecare zi. Vezi ce poți face pentru a crește viteza și calitatea - și fă-o.

Marimea echipei

Echipele mici lucrează mai repede decât echipele mari. Regula numărul unu este șapte participanți, plus sau minus doi. Mulțumește-te cu puțin.

Timp

Timpul este principalul limitator al tuturor aspirațiilor umane. Timpul are de-a face cu totul: cât muncim; cât durează să faci lucruri diferite; cât de succes avem. Trecerea inexorabilă și ireversibilă a timpului ne modelează viziunea asupra lumii și asupra noastră.

Rupeți cărți de vizită

Scapa de titluri si titluri, de la manageri si structuri ierarhice. Oferă oamenilor libertatea de a face ceea ce cred că este corect și oportunitatea de a-și asuma responsabilitatea pentru asta. Rezultatele te vor uimi.

Transparenţă

Realizați o tablă care să arate ce lucru trebuie făcut, la ce lucrați în prezent și ce a fost deja făcut. Toată lumea ar trebui să-l vadă și toată lumea ar trebui să actualizeze informațiile de pe el.

Vizualizări: 10.043

Jeff Sutherland

Arta de a face de două ori mai multă muncă în jumătate de timp

Publicat cu permisiunea Scrum, Inc. c/o Agenția Ross Yoon

Suportul juridic pentru editura este asigurat de firmă de avocatură"Vegas-Lex"

© Jeff Sutherland și Scrum, Inc. 2014

© Traducere în rusă, publicare în rusă, design. Mann, Ivanov și Ferber LLC, 2016

* * *

Această carte este bine completată de:

Tom DeMarco

Prefața partenerului la ediția rusă

Cartea pe care o ții în mâini a fost scrisă de unul dintre autorii lui Scrum. El vorbește despre condițiile prealabile pentru crearea metodologiei și aspectele sale principale.

Cel mai important lucru în această metodologie (în opinia mea) este orientarea către client. Clientul trebuie să obțină ceea ce dorește la timp și cu costuri minime.

Ideea principală a metodologiei Scrum este o abordare iterativă a planificării și executării unui proiect. Spre deosebire de abordarea liniară (în cascadă), atunci când proiectul este planificat inițial „de la” la „până”, iar rezultatul este undeva „la sfârșitul căii”, această metodă permite timp scurt obțineți produsul finit la un cost minim. Desigur, nu are încă toate caracteristicile necesare, dar poate fi deja folosit. În plus, pe parcursul derulării proiectului, antreprenorul primește feedback de la client, pe baza căruia se realizează o creștere ciclică a funcționalității și îmbunătățirea produsului.

Principala caracteristică a Scrum este flexibilitatea. Această abordare vă permite să răspundeți rapid la schimbările din cerințele clienților și să adaptați rapid produsul la acestea.

Astăzi, Scrum este o metodologie bine dezvoltată. Popularitatea sa crește în fiecare zi, inclusiv în țara noastră. Cu toate acestea, pot exista provocări atunci când implementați Scrum. În primul rând, se presupune Participarea activă client în proiect și, în al doilea rând, este necesară o muncă în echipă bine coordonată. Din proprie experiență pot spune că nu întotdeauna este posibil să se realizeze prezența clientului la întâlniri și adecvată părere De la el. Profesionalismul, responsabilitatea și capacitatea de a lucra în echipă, de asemenea, nu pot fi numite caracteristici integrale ale realității noastre de afaceri din Rusia.

Dar, în orice caz, noua abordare merită să te interesezi. Unele idei și instrumente pot fi aplicate parțial, iar acest lucru va da roade. Pentru cei care intenționează serios să implementeze această metodologie în compania lor, le recomand să urmați o pregătire specială. Scrum este predat în școlile de afaceri din întreaga lume.

Cartea este scrisă într-un limbaj foarte viu și, datorită bogăției materialelor factice, este ușor de citit. Autorul oferă numeroase exemple de proiecte care au folosit Scrum, de la proiecte de amploare precum un plan de modernizare a sistemului de management al informației al FBI și al unei mari companii farmaceutice, până la un proiect de renovare a locuinței. De asemenea, face referire la studii care ilustrează aspectele psihologice ale managementului de proiect.

Toate acestea fac ca cartea „Scrum. O metodă revoluționară de management de proiect” interesantă și utilă pentru toți cei care sunt interesați management de proiectși dorește să-și îmbunătățească eficiența în acest domeniu. Cred că după ce o citește, toată lumea va avea dorința de a folosi abordările și instrumentele pe care le oferă autorul, precum și de a studia această metodă mai profund.

Ulyana Samolova,

Președinte al Grupului Samolov

Introducere

De ce Scrum?

Totul a început când Ken Schwaber și cu mine am creat abordarea noastră pentru dezvoltarea de software pentru industriile tehnologice în urmă cu douăzeci de ani și am numit-o Scrum. Metodologia noastră a fost mai rapidă, mai fiabilă și mai eficientă.

Până atunci, un model cascadă a fost folosit pentru a gestiona proiecte de dezvoltare software - și așa mai departe până în 2005. Lucrarea a fost efectuată pas cu pas, îndreptându-se treptat către obiectiv - obținerea rezultatului final și transferarea acestuia către utilizator. Procesul a fost lent, dezvoltat imprevizibil, de multe ori nu a condus niciodată la crearea de produse de care clientul avea nevoie sau pe care oamenii pur și simplu doreau să le cumpere. Birocrația, care durează multe luni și uneori ani, este o trăsătură caracteristică model în cascadă. Planurile pas-cu-pas predeterminate, prezentate pe diagramele Gantt, arătau atât de detaliate încât au făcut ca managementul să se simtă ca și cum ar avea control complet asupra procesului de dezvoltare – totuși, practic, eram sortiți să rămânem în întârziere și să cădem catastrofal peste buget.

Pentru a depăși aceste neajunsuri, am venit cu Scrum în 1993 - o nouă abordare a rezolvării problemelor, fundamental diferită de metoda de proiectare de sus în jos folosită anterior. Spre deosebire de metodologiile anterioare, principiul Scrum a fost similar cu sistemele evolutive, adaptative, autocorecte.

De la începuturile sale, conceptul Scrum a stat la baza proiectării de noi produse software pentru industriile tehnologice. Cu toate acestea, după ce a câștigat recunoașterea și succesul în Silicon Valley în rândul managerilor de proiect pentru crearea de software și hardware nou, Scrum rămâne o metodologie puțin cunoscută în practica generală de afaceri. De dragul acestei comunități de afaceri - oameni care nu sunt direct asociați cu lumea tehnologiei înalte - am decis să scriu o carte în care voi dezvălui și explica avantajele Scrum ca sistem de management în afaceri. Voi vorbi despre originile metodologiei Scrum: sistem de producere Compania Toyota și un concept creat pentru sarcinile aviației de luptă - ciclul OODA. Voi lua în considerare întrebarea de ce organizarea proiectelor folosind echipe mici este mai mult mod eficient muncă. Mă voi opri asupra următoarelor puncte: cum să prioritizez corect munca la un proiect; cum să organizezi sprinturi, adică etape scurte de dezvoltare a proiectului (de la o săptămână la o lună) și să o faci în așa fel încât fiecare membru al echipei să fie responsabil pentru partea sa din muncă, iar rezultatul etapei ulterioare să absoarbă functiile proiectului implementate in etapele anterioare; cum să conducă zilnic discuții scurte despre sarcinile proiectului pentru a fi conștienți nu numai de ceea ce s-a făcut, ci și de dificultățile care trebuie întâmpinate inevitabil. În plus, voi explica modul în care metodologia Scrum îmbină conceptul de îmbunătățire continuă și conceptul de implementare a unui produs cu funcționalitate minimă, ceea ce vă permite să nu așteptați ca toată munca să fie finalizată, ci să îndepliniți rapid cerințele clienților în fiecare etapă. a proiectului. Veți afla că am folosit Scrum pentru a proiecta absolut orice: de la crearea de mașini ieftine cu un consum de combustibil de patru litri la suta cincizeci de kilometri până la dezvoltarea bazelor de date FBI moderne, din secolul al XXI-lea.

Citiți cartea până la capăt. Sunt sigur că veți înțelege că, cu ajutorul Scrum, vă veți putea reconsidera abordarea propria afacere: modul în care compania dumneavoastră operează, creează, planifică și ia decizii. Sunt convins că prin aplicarea Scrum este posibilă transformarea radicală a operațiunilor unei întreprinderi în aproape orice industrie. La urma urmei, această metodologie a revoluționat deja domeniul inovației, datorită căreia o galaxie magnifică de companii tinere din Silicon Valley și lumea înaltei tehnologii au reușit să cucerească rapid piața cu o gamă incredibilă de produse noi.

Jeff Sutherland

Capitolul întâi
Ordinea mondială obișnuită se sparge

Jeff Johnson era deja sigur că ziua nu va fi ușoară. Apoi, pe 3 martie 2010, Biroul Federal de Investigații a decis să-și suspende planul de modernizare a managementului informațiilor pe scară largă și promițător. Implementând-o, FBI ar putea preveni evenimente precum 11 septembrie. Cu toate acestea, dezvoltarea proiectului a fost un fiasco - unul dintre cele mai ambițioase din istoria dezvoltării software. Biroul a încercat să-și modernizeze sistemul informatic de peste un deceniu și se pare că au fost întâmpinați cu un dezastru. Un alt eșec.

Dar de data aceasta - cu creația lui Jeff Johnson - totul va merge diferit.

În urmă cu șapte luni, a apărut la FBI și a atras atenția directorului suport informativ Chad Fulgham - au lucrat odată împreună la Lehman Brothers. Jeff a fost numit adjunct al șefului de dezvoltare a informațiilor și i s-a oferit un birou la ultimul etaj al clădirii J. Edgar Hoover, sediul FBI din centrul orașului Washington, DC. Biroul său spațios avea vedere la Monumentul Washington. Nu și-a imaginat Jeff că va petrece următorii doi ani într-un subsol de beton, într-un dulap fără ferestre, unde va încerca să repare un proiect care, după toate socotările, era considerat fără speranță.

Jeff Johnson și șeful său au considerat că este corect să declare înfrângerea și să închidă programul, care era în lucru de aproape zece ani și a costat FBI-ul sute de milioane de dolari. A sosit momentul să recunoașteți că ar fi mai logic să o luați pentru dvs. și să lucrați singur la el în cadrul departamentului. „Nu a fost o decizie ușoară pentru noi”, a spus Jeff. „Dar proiectul trebuia făcut și bine făcut.”

Atât de mult așteptat sistem electronic a fost chemat să ajute FBI-ul să intre în nouă eră– era Facebook, Twitter, Amazon și Google. Era 2010 și cea mai mare parte a documentației era stocată în în formă de hârtie. Sistem software, creat odată pentru nevoile Biroului, a fost numit „Automated Case Support” (ACS) și a lucrat pe computere gigantice - cea mai recentă tehnologie din îndepărtatul anilor optzeci. Mulți agenți speciali au ales să nu-l folosească. A fost prea greoi și lent pentru epoca atacurilor teroriste și a criminalilor care se mișcau rapid.

Când un agent FBI trebuia să facă ceva - și de fapt orice: plătiți un informator, găsiți un terorist, întocmiți un dosar despre un jefuitor de bănci - munca lui nu era cu mult diferită de cea similară de acum treizeci de ani. Iată cum descrie Johnson procedura: „Ați scris o notă detaliată într-un procesor de text și ați tipărit-o în trei exemplare. Un exemplar a fost trimis spre aprobare și a trecut prin întregul lanț de sancțiuni până la vârf. Al doilea a fost trimis la arhiva locală în cazul în care prima s-a pierdut. Ei bine, cu al treilea, te-ai așezat, ai luat un pix roșu - da, nu glumesc, un pix roșu - și ai urmărit Cuvinte cheie pentru a fi introduse în baza de date. Ți-ai indexat propriul raport.”

Deci, dacă cererea dvs. a fost aprobată, atunci primul exemplar a fost numerotat și trimis. Doar un număr ștampilat pe o bucată de hârtie - așa a gestionat FBI documentele privind cazurile aflate în anchetă. Sistemul era vădit arhaic și fantastic de vulnerabil. Parțial, Biroul a fost acuzat pentru eșecul de a conecta toate informațiile și de a localiza numeroșii activiști al-Qaeda care au intrat în țară în lunile și chiar săptămâni înainte de 11 septembrie. Un departament urmărea o anumită persoană suspectă. Un alt departament s-a ocupat de străini îndoielnici, care din anumite motive urmau simultan cursuri de zbor în număr mare. În al treilea departament, cineva nesigur a fost trecut pe lista de control special. Dar nu a existat nici un schimb de informații între departamente. Nimeni din întregul FBI nu a adunat datele.

Este destul de semnificativ faptul că, după eșecul programului Virtual Investigative Cases, mulți angajați FBI au încetat să mai fie astfel de angajați.

FBI a început următorul proiect, numit Sentinel, imediat în 2005. Programul va începe cu siguranță să funcționeze. În acest caz, totul va fi diferit: Biroul va accepta masurile necesare, efectuează proceduri bugetare adecvate și stabilesc controalele corecte. Și-au învățat bine lecția. Intrebare pret? Un simplu fleac - 451 de milioane de dolari. Și sistemul Guardian va fi pe deplin operațional în 2009.

Ce ar putea merge prost de data asta? Răspunsul a apărut în martie 2010 și a fost pe biroul lui Jeff Johnson. Lockheed Martin, antreprenorul angajat pentru dezvoltarea noului sistem, a întârziat cu un an, finalizand doar jumătate din proiect și cheltuind 405 milioane de dolari. Pentru a finaliza programul, estimează experții independenți, ar fi nevoie de încă șase până la opt ani, iar contribuabilii ar trebui să plătească cel puțin încă 350 de milioane de dolari.

Johnson a trebuit să se ocupe de problemă.

De ce a mers totul prost? Cum ai reușit să faci față situației? Acestea sunt cele două întrebări care m-au inspirat să scriu această carte. Nu se poate spune că la proiect au lucrat proști, sau că Biroul a avut angajați incompetenți sau că au ales tehnologia greșită. Nu s-a vorbit despre unul rău disciplina muncii, nici despre lipsa unui spirit competitiv sănătos.

Era o chestiune de cale muncă. În, cum lucrează majoritatea oamenilor. De altfel, în opinia noastră comună, trebuie îndeplinită munca pentru ca asa am fost invatati sa o facem.

Când afli cum a avut loc procesul de dezvoltare, la început se face impresia, de parcă totul decurgea destul de rațional. Înainte de a concura pentru dreptul de a lucra la proiect, angajații Lockheed au studiat nevoile clientului și s-au gândit cum să creeze un sistem care să răspundă cerințelor acestora. Apoi, mulți oameni inteligenți s-au adunat și au lucrat cu răbdare câteva luni, plănuind exact ce ar trebui făcut. Apoi au petrecut și mai multe luni gândindu-se cum ar trebui să se realizeze. Au desenat grafice minunate care au conturat toate detaliile care trebuiau completate și timpul necesar pentru fiecare sarcină. Apoi, printr-o selecție precisă a culorilor, au arătat cum fiecare fază a proiectului trece succesiv în următoarea - totul seamănă cu o cascadă de apă.

Model în cascadă

Aceste diagrame sunt numite diagrame Gantt, numite după creatorul lor, Henry Gantt. Odată cu apariția computerelor personale în anii 1980, a devenit mai ușor să creezi tot felul de diagrame fanteziste și să le faci reale. cuprinzătoare– s-au transformat în autentice opere de artă. Întregul progres al proiectului este marcat în detaliu. Fiecare pas. Orice etapa. Orice data de livrare. Într-adevăr, diagramele Gantt fac o impresie profundă. Există o singură problemă: sunt întotdeauna gresit- fără excepție.

Henry Gantt a venit cu celebrele sale topuri în 1910. Acestea au fost folosite pentru prima dată de generalul William Cruiser, șeful serviciului de artilerie și tehnic al forțelor armate americane în Primul razboi mondial. Oricine a studiat istoria acestui război știe că nici pregătirea resurselor umane, nici sistemul de organizare nu au fost niciodată punctele forte. Nu pot înțelege de ce conceptul din Primul Război Mondial devine un instrument de design analitic de facto și este folosit chiar și în secolul XXI. Am abandonat principiile războiului de tranșee, dar cumva ideile sale organizaționale de „tranșee” rămân populare până în zilele noastre.

De fapt, totul pare incredibil de tentant atunci când munca trebuie făcută proiect major, este reprezentat grafic în detaliu și prezentat pentru vizionare publică. În timp ce vizitam multe companii, am văzut angajați ai căror singurul responsabilitatea a fost actualizarea zilnică a diagramelor Gantt. Singura problemă este că, de îndată ce acest plan perfect perfecționat se întâlnește cu realitatea, se prăbușește imediat în praf. Dar în loc să arunce atât planul, cât și abordarea lui la gunoi, managerii pretind că planul funcționează și chiar angajează specialiști care să-l facă. În esență, plătesc oamenii să-i mintă.

Acest model de acțiune este destul de nepotrivit și amintește de modelul de comportament al Biroului Politic al Comitetului Central al PCUS de la sfârșitul anilor 1980, care se presupune că a crezut în rapoartele primite în ajunul prăbușirii Uniunii Sovietice. Vizibilitate clară. Astăzi, ca și în acei ani, rapoartele continuă să fie mai importante decât realitatea - pe care, aparent, sunt menite să o descrie - dar dacă neconcordanțe ies brusc la suprafață, realitatea, nu o diagramă, este învinuită.

Când eram cadet la Academia Militară a Statelor Unite, mai cunoscută sub numele de West Point, dormeam în fosta cameră a lui Eisenhower. Noaptea, luminile stradale, reflectate în semnul auriu atârnat deasupra șemineului, mă trezeau uneori. Semnul scria: „Dwight Eisenhower a dormit aici”. M-am gândit la acest președinte pentru că odată a remarcat că planificarea unei bătălii este foarte importantă, dar odată trase focuri, planul tău dispare cu primul fum. Cel puțin Eisenhower a avut bunul simț să nu folosească diagramele Gantt.

Așa că Lockheed a prezentat FBI-ului o grămadă de programe tentante, iar Biroul a aprobat. De data aceasta, din toate punctele de vedere, sarcina fusese gândită în detaliu, așa că nimic nu putea merge prost: „Uite, iată planul proiectului - cu coduri de culori, cronologie și grafice cu bare.”

Cu toate acestea, în primăvara lui 2010, Jeff și șeful său, Chief Information Officer Chad Fulgham, revizuind din nou planul, și-au dat seama ce profanare completă erau, de fapt, Toate diagrame similare. Cei doi au început să studieze starea reală a lucrurilor, să se familiarizeze cu rezultatele reale și și-au dat seama că era imposibil de rezolvat problema. Au fost descoperite noi defecte în program mai repede decât puteau fi eliminate cele deja identificate.

Ciad a raportat inspectorului general al Departamentului de Justiție că singurul mod în care Biroul ar putea finaliza sistemul Sentinel este dacă ar prelua controlul asupra proiectului: au redus numărul de dezvoltatori, au finalizat partea cea mai dificilă a planului de cinci ori mai repede și a cheltuit mai puțin. decât o zecime din banii bugetului. Rapoartele inspectorului general către Congres, de obicei seci și formale, aveau o notă clară de scepticism.

Reprezentanți control financiar, care a revizuit în mod regulat progresul proiectului la ordinul inspectorului general, a depus un alt raport în octombrie 2010 în care și-au exprimat îngrijorări serioase cu privire la propunerea FBI; Ei și-au subliniat principalele considerații în nouă puncte, urmate de concluzia lor:

În general, avem preocupări semnificative cu privire la noua abordare propusă; rămân multe întrebări cu privire la capacitatea implementatorilor de a asigura finalizarea proiectului Guardian fără costuri suplimentare, fără încălcarea termenelor limită și menținând totodată sistem nou funcționalitatea vechiului sistem de management al cazurilor de investigație...

Dan Eggen, Griff Witte. Upgrade-ul FBI care nu a fost. 170 de milioane de dolari au cumpărat un sistem informatic inutilizabil // Washington Post, 2006, 18 august, p. A1.

Chad Fulgham a raportat inspectorului general pentru că FBI, o ramură nu numai a comunității de informații din SUA, ci și a Departamentului de Justiție al SUA, raportează atât directorului de informații naționale, cât și procurorului general. Biroul Inspectorului General este responsabil de audit și audituri pentru a controla cheltuirea fondurilor. La momentul evenimentelor descrise, Glenn Fine (2000–2011) era inspector general.

Stadiul implementării Proiectului Sentinel de către Biroul Federal de Investigații. Departamentul de Justiție al SUA, Biroul Inspectorului General. Raport 11–01, octombrie 2010.