Este necesară o strategie pentru a construi sprijin. Dar este necesar să-l construim din informațiile despre proiectele însele.
Numărul de utilizatori ai sistemelor client nu este cea mai mare pondere atunci când se construiește suport. Numărul de accesări afectează media și timpul mediu pentru rezolvarea solicitării.
Separarea suportului de la dezvoltare are sens dacă există o mulțime de funcționalități tipice (comune pentru toate proiectele). Dacă există o mulțime de îmbunătățiri funcționale, personalul GP va trebui să țină cont de toate caracteristicile fiecărui proiect. Odată cu creșterea numărului de proiecte de informare, vor exista multe, care pot afecta calitatea suportului.
În cazul proiectelor extrem de dezvoltate, este logic să alocăm un personal de sprijin pentru 3-4 proiecte. Dar aici, în mod individual, trebuie să abordăm atât proiectul, cât și angajatul. Depinde de gradul de finalizare a proiectului și de competențele angajatului.
Și bineînțeles că nu ar trebui să faceți serviciul de curierat în afara suportului, în acest caz ei vor transfera pur și simplu lucrarea la aceiași programatori și ei înșiși vor sta exact la preot.
În mod ideal, ofițerul de suport ar trebui să poată distribui întrebări pe mai multe tipuri (1. sfaturi cu privire la funcționalitatea, 2. erori în funcționalitatea și 3. rafinamentul (dorințe) ale acestei funcționalități). Dacă un angajat nu face acest lucru, totul va cădea pe programator și nu are nici un sens în acest sprijin.
În același timp, pe toate tipurile de întrebări, trebuie să înțeleagă ce se cere de la el.
1. Consultarea privind funcționalitatea este o problemă de sprijin de 100%.
2. Eroare-% 40-50 este suport. Diagnosticarea, redarea, testarea după corecție (aceasta din urmă este posibilă în departamentul de testare, aceasta depinde deja de modul în care este construit procesul de eliberare a plasturelui).
3. Îmbunătățirile / dorințele-10-20% au de asemenea nevoie de asistență. Aflați procesul de afaceri, poate că acest lucru se poate face și mijloacele actuale fără modificări. Dacă este deja imposibil, scrieți TK pentru dezvoltatori.
Îmi pare rău despre ce strategie putem vorbi la o asemenea scară? Aplicațiile de la 100 de utilizatori vor procesa chiar și 0,5 maimuțe.
Articole similare
Trimiteți-le prietenilor: