Praktisk fejlfinding rapport

Indledning. Vi har fokuseret på blind support , og support generelt. Vi har fået en masse værktøjer som, kan hjælpe os med at få, en bedre kunde kontakt. Vi fik først gennemgået et emne, og derefter skulle vi så prøve det af, som vi lige havde snakket om. Vi fik en problemstilling, for hver opgave, og så skulle man have forskellige roller, der var en Observer tør som skulle notere og observere alt hvad der forgik under supporten. Så var der en IT supporter , som skulle supportere den kunde som havde brug for hjælp. en bruger , som skulle kontakte it supporten, og blive guidet til at løse det givende problem. I nogle tilfælde var der en second hand IT supporter , hvis job var at, hjælpe it supporteren hvis der var manglende viden på et givet problem. Den faglige gennemgang. Observation: Under observationsdelen har jeg gjort mig nogle, særlige observationer i forhold til de problemstillinger vi har haft. Allerede i første opgave, hvor brugerens problem var at han/hun ikke kunne komme på nettet, på sin computer. Der lagde jeg først mærke til kommunikationen mellem IT-supporteren og brugeren, der blev ikke stillet de vigtige spørgsmål som Stationær, eller bærbar . Som hurtigt resulteret i forvirring og i sidste ende tidsspild. Men der blev dog fundet en løsning, i forhold til kvalitet, synes jeg dog, at man kunne have snakket noget mere med brugeren undervejs, da der var meget stille i nogle perioder, og det var tilldels også fordi at supporten selv sad, og kiggede efter en løsning på egen computer. Der kom forbedringer i tredje opkald hvor jeg igen sad som observatør. Med samme problemstilling som sidst Ingen internet på PC . Men denne gang blev der spurgt indtil, om det var stationær eller bærbar. Der blev også spurgt indtil om brugeren brugte Lan kabel eller trådløs forbindelse. Jeg kunne hurtigt se hvor meget det hjalp på 1. kundens tålmodighed. 2. Tiden der blev brugt på support. 3. Det virkede meget mere professionelt. 4. Mere tale undervejs. Metode: Vi snakkede om systematisk fejlfinding, og hertil OSI-modellen som man kunne bruge til en Bottom up troubleshooting eller top Down troubleshooting , og hvis man allerede kunne udelukke nogle steps var der devide-and-conquer . Jeg brugte mest Bottom up, og havde den samme tilgang til hver problemstilling som, jeg blev sat overfor. Jeg kunne med det samme mære en forbedring, i forhold til måden jeg supporterede på. Jeg havde meget mere styr på, hvad jeg havde prøvet, og hvad næste step skulle være. Men efter nogle gange med samme problemstilling kunne jeg begynde at, devide-and-conquer . Eftersom jeg nærmest allerede kunne udelukke nogle af de første steps.