Proiectele IT evită erorile în acceptarea tehnică
conţinut
- Responsabilitățile și componența echipei de acceptare
- Acceptarea tehnică în procesul de dezvoltare software
- Rifturi informale și puncte de probleme
- Cum văd dezvoltatorii și utilizatorii scăderea?
- Slăbiți eficient și cu ușurință
- Apar probleme - ce să faci?
subiecte
conţinut
- Responsabilitățile și componența echipei de acceptare
- Acceptarea tehnică în procesul de dezvoltare software
- Rifturi informale și puncte de probleme
- Cum văd dezvoltatorii și utilizatorii scăderea?
- Slăbiți eficient și cu ușurință
- Apar probleme - ce să faci?
Acceptarea tehnică este momentul adevărului pentru echipele de proiect. Odată cu aceasta, responsabilitatea este transmisă de la dezvoltator la viitorul utilizator - dar numai dacă utilizatorul aprobă rezultatul proiectului. Adesea odată cu acceptarea vine trezirea grosolană pentru managerul de proiect.
Un exemplu de la o companie IT:
Data finalizării proiectului este fixă și a fost comunicată partenerilor și publicului. Dar managerul de proiect însuși nu crede că software-ul dezvoltat de echipa sa este acceptabil. De aceea, o agitație agitată începe cu puțin timp înainte de întâlnirea crucială. Nu mai este suficient timp pentru a elimina toate deficiențele - atât de mult este sigur. Conducerea insistă în continuare pe o scădere. Prin urmare, sunt necesare măsuri pentru a menține daunele cât mai mici posibil. Echipa de proiect lucrează zi și noapte, dar, din păcate, cu succes dubios: pentru o eroare care a fost eliminată, sunt create trei noi. Lansarea este livrată în speranța că cele mai grave erori nu vor fi observate atât de repede.
Sunt scenarii de acest gen cu adevărat inevitabile? Rezultate mai bune de acceptare reușesc dacă companiile își aliniază managementul de proiect cu acest lucru? Un lucru este clar: chiar dacă echipa a folosit prototipuri și a dezvoltat produsul în mod incremental, nu este imună la surprize neplăcute. Greșelile grave pe parcursul proiectului nu pot fi anulate în timpul acceptării. Cu toate acestea, managementul proiectului ar trebui să informeze conducerea cu privire la orice riscuri rămase cu mult înainte de data acceptării, astfel încât să poată lua deciziile adecvate cu privire la etapele necesare în timp util.
Acest articol se concentrează pe probleme și soluții posibile pentru probleme în managementul proiectului unei echipe de acceptare. Acestea sunt afișate folosind exemplul unui proiect software. Articolul se adresează în principal managerilor de proiect, managerilor de calitate și celor responsabili de acceptarea tehnică.
Responsabilitățile și componența echipei de acceptare
Cine este responsabil pentru aprobarea unui proiect software? Cine ia decizia finală? În practică, există mai multe modele de responsabilitate pentru acceptare:
- Responsabilitatea pentru acceptare revine utilizatorului, acesta acționând ca client pentru proiect.
- Responsabilitatea revine departamentului IT al companiei, deoarece utilizatorul este prea slab în raport cu partenerii externi.
- Responsabilitatea revine utilizatorilor și departamentului IT (responsabilitate mixtă).
- Responsabilitatea revine unei echipe independente de inspecție care a fost comandată de conducerea companiei (posibil extern).
Responsabilitatea mixtă nu și-a dovedit valoarea. Dacă viitorii utilizatori vor accepta rezultatul acceptării, este important ca aceștia să aibă responsabilitate profesională în procesul de acceptare. Separarea responsabilității contractuale (departamentul IT) și a responsabilității profesionale (utilizatori) este posibilă și destul de practicabilă.
Cunoașterea mixtă este necesară în echipa de acceptare (tehnică, metodologie de testare, IT). Acest amestec de know-how nu trebuie să fie disponibil doar în echipa însăși. Fiecare membru al echipei ar trebui să știe despre cele trei domenii. Majoritatea membrilor echipei ar trebui să se concentreze pe cunoștințe de specialitate combinate cu cunoștințe despre modul de gestionare a testelor.
Acceptarea tehnică în procesul de dezvoltare software
Acceptarea tehnică ia o poziție hibridă în procesul de dezvoltare software. În acesta există un transfer de responsabilitate de la dezvoltatori la viitorii utilizatori. Fiecare companie le tratează diferit. Cum alegeți o variantă potrivită pentru propriul dvs. proiect? Următoarele note se aplică proiectelor cu o echipă de peste cinci angajați.
Criterii obiective și țintă ale acceptării tehnice
Scopul principal este clar: să ia o decizie dacă clientul va accepta sistemul și îl va folosi în producție. Cum luați această decizie?