Ei spun: "Nu contează cum faceți proiectul. Este important să-i dai drumul.
Și adevărul este, dacă vă gândiți să puneți proiectul la început, atunci șansele de implementare reușită cresc semnificativ. Și există cel puțin trei etape importante, atunci este important să se ridice problema atunci când se ocupă cu clientul - de la începutul proiectului, în mijloc sau spre etapele intermediare ale proiectului și finalizarea proiectului.
La începutul proiectului, totul, echipa și clientul sunt în euforie fericită. Proiectul este văzut într-o lumină puternică. Și, adesea, cu clientul, tot ce trebuie făcut în cursul proiectului este rostit, dar momentul și formatul livrării sunt trecute cu vederea. În același timp, clientul nu se grăbește să ridice această problemă, deoarece, dacă criteriile de acceptare nu sunt specificate, acesta îi oferă libertatea de a pretinde pe termen nelimitat asupra muncii efectuate. "Cum, sistemul nu funcționează în toate browserele cunoscute? Sau de ce am plutit în locația elementelor de pe pagina XXX? Dar aici este o greșeală găsită - dacă vă rog să corectați ... "Și așa mai departe ad infinitum. Din păcate, din moment ce, din păcate, software-ul nu funcționează fără bug-uri, deci dacă nu sunteți de acord imediat cu privire la criteriile de acceptare - se poate transforma într-un proces nesfârșit.
Ce trebuie să faceți la începutul proiectului:
- Suntem de acord cu clientul cu privire la scopul sarcinilor. ce ar trebui făcut, și rezolvați aceste sarcini. Deodată, specificăm o regulă, că acceptarea nu sunt fraze aplicabile:
- „Este evident“ - dacă ceva este important, acesta trebuie să fie exprimate și înregistrate (de exemplu, poate fi auto acordat clientului care „sistemul ar trebui să funcționeze în toate browserele“, dar această cerință presupune o creștere semnificativă a timpului testarea și, prin urmare, ar trebui inclusă în buget, în cazul în care clientul are nevoie de acesta).
- "Am vorbit despre asta" - din nou, se întâmplă ca fluxul de cereri al clientului să fie atât de mare încât să nu puteți înregistra totul. Prin urmare, specificațiile dezvoltate sunt trimise pentru a confirma clienților să se asigure că nimic nu este uitat. Dacă ceva este ratat - nu poate fi obligatoriu pentru acceptare.
Important! Este necesar să se facă distincția între testarea de acceptare și testarea completă a sistemului. Scopul testelor de acceptare este să se asigure că sistemul funcționează în conformitate cu cele mai anticipate scenarii de utilizare. Pentru sistemele medii, un astfel de plan va conține aproximativ 30-100 de scenarii, a căror dezvoltare durează de obicei nu mai mult de 1-2 zile, iar trecerea acceptării în sine durează aproximativ 2-8 ore.
Următorul punct important de control survine în timpul proiectului.
Din experiență - cu cât clientul este implicat mai mult în proiect și în cursul a ceea ce se întâmplă, cu atât mai bine înțelege întreaga situație și este mai înclinat să facă compromisuri în caz de forță majoră. În plus, puteți obține o evaluare a lucrărilor interimare și, dacă există comentarii, corectați-le imediat și luați-le în considerare în dezvoltarea viitoare, mai degrabă decât să remediați problemele legate de bulgăre de zăpadă chiar la sfârșitul proiectului.
Ce trebuie să faceți în cursul proiectului:
- Oferim clienților rapoarte de stare privind proiectul - ce sa făcut, ce a mai rămas, cu ce probleme s-au confruntat, unde este necesară intervenția clientului și ce poate fi rezolvată independent.
Important! Obligatoriu în format: totaluri de 1 pagină + detalii. Cu siguranta, clientul are putin timp sa se implice in toate nuantele, astfel ca informatia principala pentru el va fi raportul dvs. de sinteza, si in detaliu el va arata deja atat de necesar. Un model "semafor" este, de asemenea, util atunci când starea este trimisă chiar la începutul raportului: VERDE - totul este bine, ORANGE - așa, RED - totul este rău. - Derulăm demo intermediară - de exemplu, la fiecare 2 săptămâni (sau mai puțin, în funcție de durata proiectului mai probabil /) demonstrează rezultate, cere opinia clientului și de a primi confirmarea că fie totul merge conform planului, sau sunt necesare ajustări, dar aici vom vedea, dacă în mod corect primit toate cerințele clienților.
Important! În procesul de demonstrație, clientul poate avea noi "Wishlist". Acest lucru este absolut normal. Doar apoi imediat și să decidă ce să facă cu ele - să includă în proiect și pentru a muta cronologie sau atrage dop.resursy pentru a le pune în aplicare sau de a părăsi pentru viitor - este posibil și necesar să fie de acord imediat. Și dacă există comentarii - atunci, bineînțeles, corectați că până la momentul acceptării nu au existat surprize neplăcute.
Și, în sfârșit, când proiectul se încheie, este important să se realizeze competența completă și acceptarea livrării, fiind ghidate de criteriile elaborate la începutul proiectului.
Cea mai frecventă greșeală - clientul tocmai a trimis versiune a sistemului, ca și în cazul în care echipa consideră că acest lucru se face, sau clientul nu specifică datele la care ar trebui sa o confirmare de lucru poate duce la faptul că acceptarea a fost amânată timp de mai multe luni.
Ce trebuie să faceți până la sfârșitul proiectului:
- Realizăm testarea internă "acceptată" internă. în cursul căruia suntem convinși că toate scenariile necesare funcționează.
- Suntem de acord cu clientul la data respectivă și efectuăm demonstrația finală a sistemului. unde vom arăta rezultatul final al dezvoltării către client. Dacă totul se face corect, atunci demo-ul nu ar trebui să fie considerat a fi probleme critice sau grave, iar toate cele mici sunt fixe și vor fi corectate ca parte a escortei.
- Suntem de acord cu un termen specific pentru finalizarea acceptării. în cazul în care se convine că clientul are un timp în care poate testa independent sistemul suplimentar. Este foarte important ca acest moment să fie finit. Ie astfel încât să existe o dată clar acceptată la care se primesc observații.
Aici, probabil, aceste 8 reguli simple, și există o bază care vă va permite să vă luați cu succes proiectele!