Hantera felhantering
•Descargar como PPTX, PDF•
0 recomendaciones•479 vistas
Hantera felhantering Talare är Morten Nielsen
Recomendados
Más contenido relacionado
Destacado
Destacado (9)
Más de Agila Sverige
Más de Agila Sverige (20)
Último
Último (20)
Hantera felhantering
- 1. Hantera felhantering Morten Nielsen www.morkeleb.com morten@morkeleb.com JS-Analytics Proactive error handling
- 2. En saga
- 3. JS-Analytics Proactive error handling
- 21. JS-Analytics Proactive error handling
- 28. Hantera felhantering Morten Nielsen www.morkeleb.com morten@morkeleb.com JS-Analytics Proactive error handling
- 29. JS-Analytics Proactive error handling
Notas del editor
- HejMitt namn är morten nielsenJag arbetar på RemoteX TechnologiesOch jag tänkte dela med mig om hur vi förändrat hur vi hanterar fel i våra produkterJag har även byggt en egen produkt, JS-Analytics, baserat på mina erfarenheter kring det här.
- Jag tänkte berätta det här i sago form.En saga om en process för att hantera fel i mjukvaroprodukter, som är ganska vanlig.Antag för sagans skull att ni driver en hemsida.
- Det var en gång en websurfare, som surfade in på er hemsida.Allt var frid och fröjd tills...
- Surfaren upptäckte ett fel.Felet visar sig genom att det förväntade beteendet inte inträffade och en fin ikon visades i ena hörnet.Hade det här varit en offentlig hemsida, hade surfaren antagligen surfat någon annanstans.Låt oss därför anta att surfaren betalar för det här.
- Då skickar surfaren ett mail till er support för att förklara av som blev fel.
- Mailet kan se ut något såhär.En skärmdump, och en ganska obegriplig felbeskrivning
- Bättre är om surfaren ringer in, för att kunna gräva mer i felet.
- Nu ligger bollen hos er support, det är viktigt att supporten sammlar in så mycket information som möjligt.
- Tillsist går supporten troget till en chef, för att be att få buggen fixad.
- Chefen tittar på den redan fulla listan med saker att göra, och försöker prioritera in det bäst han kan.
- Givet det här underlaget...
- Kan prioriteringen oftast upplevas som aningen slumpmässig.
- Sen kommer den dagen då chefen går till sina utevecklare
- Dialog uppstår
- Kan du fixa felet?
- Huh? Det visar sig, att när man till slut tar tag i buggen har man *fattig information*kanske en helt annan version av produkten*ingen direkt kontakt med kunden
- Utvecklaren vill ha
- *Viskningslek*alla strävar åt samma mål, men behöver olika information*subjektiva bedömningarFinns många produkter som försöker lösa problemet
- Bättre att kunna sammla in information om fel statisktisktOch ge felmeddelanden till utvecklare, inte kunder.
- Alla dessa verktyg har samma arbetssätt gemensamt.De övervakar produkten, och när ett fel uppstår skickas så mycket information som möjligt in till servern så den kan analyseras.Felmeddelanden skickas till rätt person automatiskt. Kunden bör inte se tekniska fel.
- Faktiska mätvärdenHjälper att prioritera
- Itterativt minska krasher genom att ta mest inträffande varje itterationMät resultatet av senaste fixen
- Sparar tid i supportenOch supporten kan ge bättre svar genom att beskriva processen, alt. Omfattning av problemet.
- Erfarenhet från RemoteX:I början ser resultaten väldigt bra ut, man får snabbt resultat eftersom man fixar de problem som inträffar oftast.Vilket gör at färre och färre fel inträffar.Men vad hände med vår surfare?
- Jo han surfar vidare, glad och lycklig över att felet blev åtgärdat.
- Jag heter Morten Nielsen, jag har presenterat hur vi på RemoteX förändrat hur vi hanterar fel i produkten.