Un flux de lucru fără durere pentru raportarea și rezolvarea problemelor

(Acesta este o postare sponsorizată.) Erori, bug-uri și alte probleme vor apărea în dezvoltarea web. Chiar dacă nu sunt erori absolute, clienții au adesea feedback despre cum a fost proiectat ceva, unde a fost plasat sau cum funcționează anumite elemente. Este doar o parte a concertului.

Poate fi și o parte foarte dureroasă a concertului.

Luați acest scenariu, de exemplu:

E-mail nr. 1 de la client: „Nu mai văd butonul. Vă rog, îl puteți pune înapoi pe pagina principală?”

E-mailul #2 de la dvs.: „La ce buton vă referiți? Îmi poți trimite o captură de ecran?”

Încercați să sunați clientul, dar primiți în schimb mesageria vocală.

E-mail nr. 3 de la client: „Butonul pentru a rezerva o demonstrație.”

Te uiți la captura de ecran atașată și vezi că secțiunea Rezervați o demonstrație este intactă, dar butonul nu apare. Afișați site-ul pe Chrome și Safari și îl vedeți în ambele browsere: un buton mare albastru pe care scrie „Programează Demo”. Îl tragi pe iPhone și îl vezi și acolo.

E-mailul nr. 4 de la dvs.: „Îmi puteți spune pe ce dispozitiv și browser vedeți problema?”

E-mail nr. 5 de la client: „Telefonul meu”.

Știți cum va merge acest lanț de mesaje și nu va duce decât la frustrare la ambele capete. Ca să nu mai vorbim de costurile pentru afacerea dvs. de fiecare dată când trebuie să vă opriți de la serviciu pentru a încerca să interpretați un raport de eroare și apoi să îl rezolvați.

Apoi, există costul erorilor pentru clienții tăi la care trebuie să te gândești. Când ceva nu merge bine după lansare și clientul tău încearcă în mod activ să trimită trafic către site-ul web, o eroare le-ar putea afecta vânzările.

Când se va întâmpla asta, după cine crezi că vor veni?

Un flux de lucru fără durere pentru raportarea problemelor și reparații

Nu contează care este dimensiunea erorii sau a problemei. Când este detectat și raportat, trebuie tratat. Există o serie de motive pentru care.

Pentru început, este singura modalitate prin care veți convinge clientul să semneze un proiect ca fiind finalizat. În plus, rezolvarea rapidă și imediată a erorilor duce la relații mai bune cu clientul dvs., care vede cât de investit sunteți în crearea unui site web impresionant (și fără erori) pentru afacerea lor. Și, bineînțeles, cu cât rezolvați mai eficient erorile, cu atât mai repede puteți reveni la finalizarea acestei lucrări și trecerea la altele!

Așadar, iată ce trebuie să faceți pentru a aborda mai eficient și fără durere aceste probleme.

1. Atribuiți pe cineva la triaj
2. Utilizați un flux de lucru pentru rezolvarea problemelor
3. Oferiți utilizatorilor dvs. un instrument de raportare a erorilor
4. Oferiți managerului dvs. de triaj o platformă de urmărire
5. Lucrați într-o platformă locală de testare
6. Închideți întotdeauna bucla

1. Atribuiți pe cineva la triaj

Primul lucru de făcut este să decideți cine va rezolva problemele.

Dacă lucrezi pe cont propriu, atunci această responsabilitate este a ta. Dacă lucrați într-o echipă, aceasta ar trebui să meargă la un manager de proiect sau un lider de dezvoltare care poate gestiona problemele raportate la fel de eficient precum ar gestiona volumul de lucru al echipei.

Această persoană va fi apoi responsabilă de:

• Monitorizarea problemelor raportate.
• Adăugarea erorilor la coadă.
• Introducerea acestora prin fluxul de lucru de rezoluție.
• Rezolvarea și închiderea rapoartelor de erori.
• Analizând tendințele și revizuirea proceselor pentru a reduce probabilitatea ca erorile recurente să apară din nou.

Odată ce știți cine va gestiona procesul, este timpul să vă proiectați fluxul de lucru și să construiți o serie de instrumente în jurul acestuia.

2. Utilizați un flux de lucru pentru rezolvarea problemelor

Managerul dvs. de triaj nu poate face asta singur. Vor avea nevoie de un proces pe care să-l urmărească îndeaproape pentru a duce fiecare problemă de la Punctul A (detecție) la Punctul B (rezoluție).

Pentru a vă asigura că ați parcurs fiecare pas, utilizați un instrument de vizualizare precum Lucidchart pentru a stabili pașii sau etapele fluxului dvs. de lucru.

Iată un exemplu despre cum ar putea arăta diagrama dvs. de flux:

Să o descompunem:

Veți începe prin a identifica unde a fost detectată problema și prin ce canal a fost raportată. Acest exemplu nu devine prea specific, dar să presupunem că noua problemă detectată a fost cea menționată anterior: butonul Rezervați o demonstrație lipsește pe pagina de pornire.

Următorul lucru de făcut este să răspunzi la întrebarea: „Cine l-a găsit?” În cele mai multe cazuri, acesta va fi feedback trimis de clientul dvs. din software-ul dvs. de urmărire a erorilor (mai multe despre asta în curând).

În continuare, veți intra în diferitele etape prin care vor trece problemele dvs.:

Aceasta este partea procesului în care managerul de triaj va determina cât de gravă este problema unui buton Rezervați o demonstrație lipsă (care este „Severă”, deoarece va costa conversiile clientului). Apoi îl vor transmite dezvoltatorului pentru a-l verifica.

În funcție de câți dezvoltatori sau experți în domeniu sunt disponibili pentru a rezolva problema, este posibil să doriți, de asemenea, să întrerupeți această etapă în funcție de tipul de eroare (de exemplu, funcționalitate întreruptă vs. actualizări de design).

Indiferent, odată ce eroarea a fost verificată și în ce context (ca dacă ar fi fost doar pe iPhone 7 sau mai devreme), biletul este mutat în „În curs”.

În cele din urmă, diagrama dvs. de flux ar trebui să prezinte pașii următori pentru problemele care pot fi rezolvate:

Puteți denumi acești pași oricum doriți. În exemplul de mai sus, fiecare pas explică foarte specific ce trebuie să se întâmple:

• Problemă nouă
• În curs
• Test
• Fix
• Verifica
• Rezolva
• Închideți bucla.

Pentru a simplifica lucrurile, ați putea folosi un flux de rezoluție ca acesta:

• Problemă nouă
• A face
• Face
• Terminat
• Arhiva.

Oricum ați alege să vă configurați fluxul de lucru pentru corecție, asigurați-vă că patch-ul este testat și verificat înainte de a închide biletul.

3. Oferiți utilizatorilor dvs. un instrument de raportare a erorilor

Când vine vorba de alegerea unui instrument de raportare a erorilor pentru site-ul dvs., doriți unul care să le permită echipei și clienților dvs. să lase feedback cu ușurință și chiar mai ușor pentru dvs. să îl procesați.

Un astfel de instrument care face acest lucru bine se numește BugHerd.

Practic, BugHerd este o modalitate simplă prin care oamenii netehnici vă pot raporta probleme vizual și contextual. Deoarece nu este nevoie să instruiți utilizatorii cu privire la modul de a intra în instrumentul de raportare a erorilor sau de a-l folosi, este un lucru mai puțin pe care trebuie să vă petreceți timpul în acest proces.

Mai mult decât atât, BugHerd vă scutește de necazul de a face față neîncetatului dus-întors care are loc atunci când feedback-ul este comunicat verbal și în afara contextului.

Cu BugHerd, totuși, utilizatorii lasă feedback pe site la fel de ușor cum ar lăsa o notă lipicioasă pe birou. În plus, feedback-ul este fixat în locul exact în care există eroarea.

Permiteți-mi să vă arăt cum funcționează:

Când adăugați pentru prima dată site-ul web al clientului dvs. la BugHerd (este primul pas), vi se va cere să instalați extensia de browser BugHerd. Acesta este ceea ce permite lui BugHerd să fixeze bara de feedback pe site.

Arata cam asa:

Această bară de feedback fixată face incredibil de ușor pentru clienți să lase feedback fără a modifica efectiv site-ul live.

Iată cum arată fereastra pop-up pentru urmărirea erorilor:

După cum puteți vedea, este o formă foarte simplă. Și, într-adevăr, tot ce trebuie să facă clienții tăi este să selecteze elementul de pe pagină care conține bug-ul, apoi să introducă detaliile. Restul poate fi completat de managerul de triaj.

Pe măsură ce se adaugă feedback nou, comentariile sunt fixate pe pagina în care l-au lăsat. De exemplu:

Veți observa, de asemenea, în captura de ecran de mai sus că sarcinile cărora li s-a atribuit un nivel de severitate sunt marcate ca atare. De asemenea, sunt enumerate de sus în jos pentru cât de critici sunt.

Pe partea ta a lucrurilor, ai de unde alege unde vezi feedback-ul. Puteți deschide site-ul și puteți revizui notele fixate pe fiecare pagină. Sau puteți accesa aplicația BugHerd și consultați comentariile de pe panoul Kanban:

În mod implicit, toate erorile intră în Backlog pentru a începe. Este sarcina managerului tău de triaj să completeze fiecare eroare cu detaliile lipsă, să-l atribuie unui dezvoltator și să-l mute prin pașii până la rezolvare.

Acestea fiind spuse, BugHerd își asumă o mare parte din munca mai obositoare de a captura rapoarte de erori pentru tine. De exemplu, când faceți clic pe oricare dintre erorile raportate în panoul kanban, va apărea această bară laterală „Detalii sarcină”:

Acest panou oferă detalii suplimentare despre problemă, arată o captură de ecran a locului în care există pe site și, de asemenea, vă informează cine a lăsat comentariul.

În plus, BugHerd captează „Informații suplimentare”:

În acest fel, nu trebuie să vă faceți griji că clientul nu vă oferă contextul complet al problemei. Aceste detalii vă spun pe ce dispozitiv și browser se aflau, cât de mare era ecranul și prin ce rezoluție de culoare îl vedeau.

Veți vedea și codul elementului buggy. Dacă există ceva de fapt rupt sau codificat incorect, s-ar putea să-l descoperi de aici.

Una peste alta, BugHerd este un instrument excelent pentru a simplifica cât de mult are de făcut toată lumea din toate părțile și pentru a se asigura că fiecare solicitare este abordată în timp util.

4. Oferiți managerului dvs. de triaj o platformă de urmărire

Dacă doriți să păstrați acest flux de lucru cât mai simplu posibil, puteți utiliza tabloul de bord BugHerd pentru a urmări și gestiona solicitările dvs.:

Managerul de triaj și echipa de dezvoltare vor dori probabil să folosească ceva pentru a completa capabilitățile de raportare a erorilor ale BugHerd. Dar noroc să-i cereți clientului să folosească o platformă precum Jira pentru a vă ajuta să gestionați erorile.

În acest caz, aș recomanda adăugarea unui alt instrument la acest flux de lucru.

Din fericire pentru dvs., BugHerd se integrează perfect cu software-ul de urmărire a problemelor și serviciul de asistență precum Jira, Zendesk și Basecamp, astfel încât să nu vă faceți griji cu privire la utilizarea mai multor instrumente pentru a gestiona diferite părți ale aceluiași proces. Odată ce se realizează conexiunea între cele două platforme, orice sarcină creată în BugHerd va fi copiată automat în centrul dvs. de rezolvare a problemelor.

Acum, dacă există un instrument pe care echipa ta îl folosește deja, dar cu care BugHerd nu se integrează direct, este în regulă. Puteți folosi Zapier pentru a vă ajuta să vă conectați cu și mai multe platforme.

De exemplu, acesta este cât de ușor este să creezi instantaneu un „zap” care copiază noile sarcini BugHerd pe cărțile tale Trello. Și totul are loc din interiorul BugHerd!

Odată realizată conexiunea, managerul dvs. de triaj poate începe să lucreze de la platforma de gestionare a sarcinilor sau de urmărire a problemelor pe care o alege. În acest caz, iată ce se întâmplă când Zapier conectează BugHerd și Trello:

Aceasta este o sarcină nouă pe care tocmai am creat-o în BugHerd. În câteva secunde, cardul a fost plasat în proiectul Trello exact și în lista pentru care am configurat zap:

Acest lucru va face munca managerului dvs. de triaj mult mai ușoară, deoarece nu vor fi limitate de etapele disponibile în BugHerd, având totodată aceleași informații la îndemână.

5. Lucrați într-o platformă locală de testare

Când sunt raportate erori, nu doriți să testați și să implementați remediile presupuse pe site-ul live. E prea riscant.

În schimb, lucrați la rezolvarea problemelor de pe o platformă locală de testare. Acest articol are câteva sugestii grozave despre instrumentele de dezvoltare locală pentru WordPress pe care le puteți folosi pentru aceasta.

Aceste instrumente vă permit să:

• Faceți rapid o copie a site-ului dvs.
• Reproduceți bug-ul cu aceleași condiții de server.
• Testați posibilele remedieri până când găsiți una care funcționează.

Numai atunci ar trebui să lucrați la corectarea erorii de pe site.

6. Închideți întotdeauna bucla

În cele din urmă, revine managerului tău de triaj să aducă la capăt formal fiecare problemă.

În primul rând, ar trebui să informeze clientul (sau vizitatorul) care a raportat inițial problema că aceasta a fost rezolvată. Acest tip de transparență și responsabilitate va oferi agenției dvs. un aspect mai rafinat, ajutându-vă în același timp să construiți încredere cu clienții care ar putea fi deranjați de descoperirea erorilor în primul rând.

Odată ce lucrurile sunt închise pe partea clientului, managerul de triaj poate apoi arhiva raportul de eroare.

Totuși, nu ar trebui să se termine aici.

La fel ca managerii de proiect tradiționali, un manager de triaj ar trebui să urmărească în mod regulat tendințele, precum și severitatea generală a erorilor găsite pe site-urile lor web. Datele ar putea dezvălui că există o problemă mai profundă în joc. În acest fel, echipa ta se poate concentra pe rezolvarea problemei de bază și nu mai petrece atât de mult timp reparând aceleași tipuri de erori și probleme.

Încheierea

Gândiți-vă la toate modurile în care problemele și erorile pot fi raportate: printr-un formular de contact, prin e-mail, prin telefon, prin chat sau, mai rău, într-un forum public, cum ar fi rețelele sociale.

Acum, gândiți-vă la toți diferiții oameni care v-ar putea raporta aceste probleme: echipa dvs., clientul, un client al clientului dvs., o persoană care l-a găsit la întâmplare în timp ce se uita la site și așa mai departe.

Există prea multe variabile în această ecuație, ceea ce face ușor să pierdeți din vedere problemele deschise. Mai rău, atunci când feedback-ul este vag, subiectiv sau imposibil de explicat fără niciun context, devine prea dificil să rezolvi problemele complet sau în timp util.

Cu toate acestea, cu sistemul potrivit de raportare, urmărire și organizare a feedback-ului, puteți aduce ordine în acest haos și puteți elimina mai eficient erorile găsite pe site-ul dvs.