În acest articol, voi împărtăși experiența mea în selectarea ideilor pentru dezvoltarea funcționalității produselor noastre și vă voi spune cum să mențineți principalii vectori de dezvoltare.
Dezvoltăm un sistem automat de decontare (ACP) - facturare. Termen
Durata de viață a produsului nostru este de 14 ani. În acest timp, sistemul a evoluat de la primele versiuni ale unui sistem tarifar industrial la un complex modular format din 18 produse care se completează reciproc. Unul dintre cele mai importante aspecte ale longevității pentru programe este dezvoltarea constantă. Iar dezvoltarea necesită idei.
idei
surse
Există 5 surse:
- Prietenul principal al unui dezvoltator de sisteme informatice corporative este client. Iar clientul este o imagine colectivă a factorilor de decizie, a sponsorilor de proiecte, a proprietarilor și executanților de procese, a specialiștilor IT interni, a utilizatorilor obișnuiți și a unui număr mare de persoane interesate în diferite grade. Este important pentru noi ca fiecare dintre reprezentantii clientului sa fie potential un furnizor de idei. În cel mai rău caz, primim doar feedback negativ despre problemele din sistem. În cel mai bun caz, există o persoană de partea clientului, care este o sursă constantă de idei de îmbunătățire, oferind informații structurate despre nevoile clientului.
- Noastră agenti de vanzari si manageri de cont sunt a doua cea mai importantă sursă de idei de îmbunătățire. Ei comunică în mod activ și extensiv cu reprezentanții industriei și primesc întrebări de primă mână despre funcționalitatea de facturare de la clienții potențiali. Vânzătorii și conturile trebuie să fie conștienți de toate modificările semnificative ale funcționalității lor și de cele mai recente actualizări ale software-ului concurenților și să fie capabili să justifice avantajele și dezavantajele diferitelor soluții. Aceștia sunt angajații noștri care sunt primii care simt dacă unele capacități de facturare devin un standard de facto, fără de care software-ul nu poate fi considerat complet.
- Proprietarul produsului — unul dintre managerii noștri de top sau un manager de proiect foarte experimentat. Ține cont de obiectivele strategice ale companiei și adaptează planurile de dezvoltare a produselor în conformitate cu acestea.
- arhitect, o persoană care înțelege capacitățile și limitările soluțiilor tehnologice alese/utilizate și impactul acestora asupra dezvoltării produsului.
Echipe de dezvoltare și testare. Persoane care sunt direct implicate în dezvoltarea produsului.
Clasificarea cererilor
Primim date brute din surse - scrisori, bilete, cereri verbale. Toate
contestațiile sunt clasificate:
- Consultanță cu semnificația „Cum se face?”, „Cum funcționează?”, „De ce nu funcționează?”, „Nu înțeleg...”. Solicitările de acest tip ajung la Linia de asistență de nivel 1. Este posibilă recalificarea consultării în alte tipuri de solicitări.
- Incidente cu semnificația „Nu funcționează” și „Eroare”. Procesat de 2 și 3 linii de asistență. Dacă sunt necesare corecții prompte și eliberarea unui patch, acestea pot fi transferate de la suport direct la dezvoltare. Este posibil să o reclasificați ca solicitare de modificare și să o trimiteți în backlog.
- Solicitari de modificari si dezvoltare. Ei intră în stocul de produse, ocolind liniile de asistență. Dar există o procedură de procesare separată pentru ei.
Există statistici privind solicitările: imediat după lansare, numărul de solicitări crește cu 10-15% pentru o perioadă scurtă de timp. Există, de asemenea, creșteri ale solicitărilor atunci când un client nou cu un număr mare de utilizatori vine la serviciile noastre cloud. Oamenii învață să folosească noi capabilități software, au nevoie de sfaturi. Chiar și un client mic, când începe să lucreze în sistem, arde cu ușurință peste 100 de ore de consultații pe lună. Prin urmare, atunci când conectăm un nou client, rezervăm întotdeauna timp pentru consultațiile inițiale. Adesea chiar selectăm un anumit specialist. Prețul de închiriere, desigur, nu acoperă aceste costuri cu forța de muncă, dar în timp situația se uniformizează. Perioada de adaptare durează de obicei de la 1 la 3 luni, după care nevoia de consiliere se reduce semnificativ.
Anterior, am folosit soluții auto-scrise pentru a stoca solicitările. Dar am trecut treptat la produsele Atlassian. În primul rând, am transferat dezvoltarea pentru a facilita lucrul în conformitate cu Agile, apoi asistență. Acum, toate procesele critice trăiesc în Jira SD, plus sunt acceptate de diverse plugin-uri pentru Jira, plus Confluence. Soluțiile auto-scrise au rămas doar pentru procesele care nu erau critice pentru activitățile companiei. Se pare că sarcinile noastre sunt acum transversale și pot fi transferate între suport și dezvoltare fără a sări de la un sistem la altul.
Din acest link putem obține date despre toate sarcinile, costurile planificate și efective ale forței de muncă, putem folosi diverse opțiuni de preț pentru clienți și putem genera documentație pentru nevoile interne și raportarea către clienți.
Procesarea cererilor de modificare
De obicei, astfel de solicitări vin sub forma cerințelor de funcționalitate. Analistul nostru studiază cererea, creează un caiet de sarcini și specificații tehnice de top. Transferă specificația și specificațiile tehnice către persoana care a depus această cerere de aprobare - trebuie să fim siguri că vorbim aceeași limbă cu clientul.
După ce a primit confirmarea de la client că ne-am înțeles corect, analistul introduce cererea în backlog-ul de produse.
Managementul funcționalității produsului
Restul acumulează solicitări de schimbare și dezvoltare. Consiliul tehnic, format din director, șefi de suport, dezvoltare, vânzări și arhitectul de sistem, se întrunește la fiecare șase luni. Într-un format de discuție, consiliul analizează și prioritizează aplicațiile din restanța și convine asupra a 5 sarcini de dezvoltare pentru implementare în următoarea ediție.
De fapt, consiliul tehnic răspunde cererilor industriei și pieței prin revizuirea nevoilor exprimate în aplicații. Tot ceea ce are puțină relevanță rămâne în restanță și nu ajunge la dezvoltare.
Clasificarea cererilor de modificare și finanțare
Dezvoltarea este costisitoare. Prin urmare, vă vom spune imediat ce opțiuni putem avea dacă cererea de modificare a venit de la un client și nu de la un angajat.
Clasificăm cererile de modificare după cum urmează: nevoia industriei sau caracteristica individuală a întreprinderii; o cantitate semnificativă de funcționalități noi sau o remediere minoră. Remedierile minore și solicitările individuale sunt procesate fără bibelouri. Cererile individuale sunt calculate și implementate pentru un anumit client ca parte a lucrului de proiect cu acesta.
Dacă aceasta nu este o nevoie masivă a industriei și volumul de funcționalități este mare, atunci se poate lua decizia de a dezvolta un nou modul separat care va fi vândut în plus față de funcționalitatea principală. Dacă o astfel de solicitare este primită de la un client, putem acoperi costurile de dezvoltare a modulului, putem oferi clientului modulul gratuit sau cu plată parțială și putem pune modulul în sine la vânzare. Într-o astfel de situație, clientul preia o parte din sarcina metodologică și, în esență, realizează o implementare pilot a modulului pe sine.
Dacă aceasta este o nevoie masivă a industriei, atunci se poate lua decizia de a include o nouă funcționalitate în produsul de bază. Costurile în acest caz revin în întregime asupra noastră, iar noua funcționalitate apare în versiunea actuală a programelor.
Clienților vechi li se oferă o actualizare.
De asemenea, se poate ca mai mulți clienți să aibă o nevoie similară, dar nu se califică pentru un produs de masă. În acest caz, putem trimite specificația acestor clienți și le putem oferi să împărțim costurile de dezvoltare între ei. În cele din urmă, toată lumea câștigă: clienții primesc funcționalitate la un cost scăzut, noi îmbogățim produsul și, după un timp, alți participanți la piață pot obține și funcționalitatea pentru utilizarea lor.
DevOps
Dezvoltarea pregătește două lansări majore pe an. În fiecare lansare, timp este rezervat pentru implementarea a 5 sarcini primite de la consiliul tehnic. Astfel, în mijlocul rutinei, nu uităm niciodată de dezvoltarea produsului.
Fiecare versiune este supusă unui set adecvat de testare și documentație. În continuare, această ediție este instalată în mediul de testare al clientului corespunzător, care, la rândul său, verifică meticulos totul și numai după aceea ediția este transferată în producție.
Pe lângă sistemul de lansare, există un format pentru remedieri rapide de erori, astfel încât clienții să nu trăiască cu erori timp de șase luni. Acest format intermediar vă va permite să răspundeți rapid la incidentele de primă prioritate și să îndepliniți SLA-urile menționate.
Toate cele de mai sus sunt valabile în primul rând pentru sectorul corporativ și soluțiile on-premise. Pentru serviciile cloud care vizează segmentul IMM-urilor, nu există oportunități atât de mari pentru clienți de a participa la dezvoltarea produsului. Formatul de închiriere SMB nici măcar nu presupune acest lucru. În loc de o solicitare de schimbare sub forma unor cerințe clare din partea părții corporative, aici există doar feedback obișnuit și dorințe pentru serviciu. Încercăm să ascultăm, dar produsul este masiv și dorința unui client de a aduce ceva familiar din vechiul sistem istoric poate contrazice strategia de dezvoltare a sistemului în ansamblu.
Sursa: www.habr.com