Cum se fac estimări rapide și corecte ale timpului de dezvoltare a proiectului - revista cms

Cum se fac estimări rapide și corecte ale timpului de dezvoltare a proiectului - revista cms

Cum se fac estimări rapide și corecte ale timpului de dezvoltare a proiectului - revista cms

Bună ziua tuturor. Numele meu este Vladimir Zertaytilov, eu sunt șeful studioului de soluții pentru Internet "Sibiriks".

Trebuie adesea să răspundeți la întrebarea "Cât costă un site web?" Câte întrebări principale cereți să vină la un anumit nivel și să o vorbească? Trebuie să fie anunțat dacă detaliile TK nu sunt clare? Ce trebuie să faceți cu fluxul de aplicații - evaluați fiecare TOR în mod individual sau utilizați estimări ale șablonului? Dezvoltatorii sunt mulțumiți de termenele limită și clienții - cu suma bugetului?







Practica sugerează că nu totul este atât de simplu în evaluare. Pentru a face o evaluare clară și adecvată a oricărui proiect, este nevoie de mult timp pentru un specialist calificat, care nu este faptul că acesta va fi plătit. Aici este un exemplu: în urmă cu câțiva ani, am luat aproximativ patru ore de lucru pe zi la doi dezvoltatori calificați pentru a efectua o evaluare a tuturor cererilor primite. Ne-a făcut trist și am decis să corectăm situația.

Astăzi, cu creșterea volumului de cereri, efortul necesar pentru a face evaluări la aproximativ 20 de minute pe zi, iar cei mai mulți dintre ei fac managerii de proiect (nu experți tehnici), precizia este crescut în mod semnificativ. Și astăzi aș dori să vorbesc despre metode simple și eficiente pe care le aplicăm în fiecare zi:

1. Cea mai simplă și corectă modalitate de a face o evaluare nu este să o faceți. Sună ciudat? "Dar funcționează." Este necesar să aflați bugetul proiectului direct de la client.

De ce poate funcționa aceasta?

În primul rând, clientul are încă un buget pe care intenționează să-l cheltuiască. Prea mult nu va merge pentru el oricum.

În al doilea rând, se poate întâmpla ca bugetul clientului să fie mult mai mic decât cel pe care îl luați de obicei pentru astfel de proiecte. Apoi, bine-cunoscutul principiu Pareto - 80/20 - vine în ajutorul nostru. Linia de jos este că de bază utile, necesare și aduc caracteristicile proiectului face profit, de obicei în jur de 20% (deși există un lider de funcții nerevendicate - MS Excel de program, care este utilizat în mod constant la aproximativ 4%). Cunoscând acest principiu, ar trebui să discute afacerea clientului, pentru a ajuta-l determina ce caracteristici va fi cheia pentru el și să aducă o rentabilitate maximă, și în același timp, sunt susceptibile de a fi în măsură să se încadreze în buget.







De ce s-ar putea ca acest lucru să nu funcționeze? Din diferite motive. Destul de obișnuit - clientul monitorizează pur și simplu piața și caută cel mai mic preț (ați fost vreodată rugat să faceți o reducere din prețul pe care l-ați numit "FROM" și din tavan?).

2. A doua metodă este potrivită pentru evaluarea rapidă, dar inexactă a volumelor groase de TK sau a unor activități de rutină. Se va folosi o metrică. Scrollbar. Care este scopul? - Să spunem că ai fost trimis materiale pentru umplerea catalogului de bunuri, câteva sute de coli în Word și un pachet de fotografii nesortate. În mișcare pentru a înțelege cât timp va dura pentru a conduce acest director este destul de dificil. Luăm, începem să facem bunurile și măsuram timpul. Am condus câteva piese - după cum a trecut bara de scroll în document, vedem aproape progresul nostru (în procente). În continuare - o chestiune de tehnologie, se înmulțește două numere.

În cazul în care estimările TK - luați și selectiv evalua o pereche de pagini este înmulțită cu numărul de pagini, factorul ghinion și factorul de lăcomiei corporatiste. Toate scorurile sunt gata. Funcționează excelent pentru TK omniprezente, omogene și detaliate, care trebuie evaluate rapid. Uneori dă greșeli grave, dacă pe undeva pe pagina penultimă, zeci de module fără detalii sunt enumerate printr-o virgulă. Hopa.

4. O modalitate foarte bună de a face o evaluare este "Planificarea Poker". Echipa care va lucra direct pe proiect, se reuneste si incepe sa discute fiecare caracteristica a proiectului. Fiecare membru al echipei primește un set de 13 cărți cu diferite denumiri. După ce facilitatorul a explicat cum ar trebui să funcționeze caracteristica particulară, toți membrii echipei ar trebui să-și pună cărțile cu fața în jos cu ratingurile lor. După aceea, cardurile sunt deschise.

Cum se fac estimări rapide și corecte ale timpului de dezvoltare a proiectului - revista cms

Dacă evaluările coincid, atunci evaluarea este clară și întreaga echipă este de acord cu aceasta. Dacă nu - aceasta înseamnă că o problemă nu este înțeleasă (de exemplu, persoana care nu a aruncat numărul, trezit de formulare a problemei), sau unul dintre membrii echipei cunosc unele caracteristici ale problemei discutate (de exemplu, capcane, sau mai repede metoda de soluție). În acest caz, cel al cărui scor nu a coincis cu echipa ar trebui să explice de ce a scos exact o astfel de carte și ceea ce vede nuanțele implementării. După aceea, conul este reluat.

Numerele de pe carduri. în funcție de circumstanțe, poate însemna ore, zile sau "Punct de poveste". Când evaluăm punctul "Story", alegem cea mai mică caracteristică din proiect și o considerăm standard. Toate celelalte caracteristici sunt evaluate în raport cu cele selectate.

În pachet, pe lângă numere, există carduri speciale - "pauză de cafea / bere", ". "(Folosit de noii dezvoltatori care îi este greu de evaluat)," 0 "(dacă funcția este gata sau făcută într-un minut).

Procesul este destul de lung, durează o oră sau două sau mai multe, în funcție de experiența echipei și de sfera proiectului. Ideal pentru proiecte mari în care echipa lucrează pe scrum și câștigă sarcini pentru următoarele două-patru săptămâni (sprint). Un plus suplimentar - detaliile proiectului și ale implementării devin clare pentru toată lumea, iar pentru evaluările făcute există un sentiment de responsabilitate.

Vă recomandăm întotdeauna să faceți evaluări cronologice pentru toate proiectele, indiferent de proiectele interne ale proiectelor sau de proiectele clientului - indiferent de cât de mici se pare. (De ce? Puteți citi despre el și îl puteți vedea pe blogul nostru sau pe Google, la solicitarea "Legea lui Parkinson").







Trimiteți-le prietenilor: