100.000 ganges forskel
Jeg var engang med i et projekt, hvor jeg opdagede at en udvikler havde brugt en uge på at lave en del af en flot grafisk grænseflade til opsætning af det færdige system. Desværre var det spild af gode kræfter, da hvert system kun skulle installeres en gang af vores egne teknikere, som var vant til at klare sig med noget langt simplere. Det fik mig til at tænke over, hvordan man overhovedet kunne få overblik over alle funktionerne i et stort system. De fire ringbind vi havde stående med funktionsbeskrivelser og use cases var ikke løsningen.
I stedet endte jeg med et diagram som det nedenunder.
Siden har jeg set hvordan både mobiltelefoner og web-services kunne have gavn af at designerne brugte et tilsvarende diagram, når de skulle prioritere deres indsats.
Der var vedligeholdelse af softwaren øverst til venstre som kunne strække sig over en uge og laves en gang om året, og der var telefonbetjening af kunder i nederste højre hjørne som skulle klares på et minut og laves flere tusind gange om dagen.
Nu kunne man se, hvor projektet skulle bruge kræfterne. Der var ingen grund til at gøre noget fancy ved øverste venstre hjørne, bare man begrænsede risikoen for fejl. Til gengæld var det værd at bruge tid og kræfter på at spare et enkelt tastetryk i hver opgave i nederste højre hjørne.
De opgaver kunne igen inddeles i to grupper. Der var de algoritmiske som kunne og skulle automatiseres totalt, og der var de andre, hvor man skulle lave en fast procedure som minimerede arbejdet for den operatør der ikke kunne undværes. Endelig var der de komplekse opgaver, hvor det er afgørende at operatøren eller brugeren har størst mulig frihed til at løse dem på den måde, som han eller hun syntes er bedst.
Lige som i vores almindelige tilværelse er opgaver ikke bare opgaver. De er forskellige, og det skal man helst tage hensyn til.
Om Georg StrømKommentarer (8)
Hej Georg
Tak for indlægget. Jeg synes det er en god måde at finde ud af hvor det er vigtigts at bruge sin tid.
-
0 -
0
Jeg har ikke fundet ud af hvordan eller om man kan zoome på et billede i Version2.
Min egen web-site hedder: www.georg.dk
Der har jeg lagt et diagram i stor størrelse. Det ligger under:
http://www.georg.dk/diagram-opgaver.jpg
Venlig hilsen
Georg
-
0
-
0
Bør det ikke være de opgaver, der ligger over diagonalen, der bør ses på? Altså de opgaver, der udføres relativt hyppigt [i]og[/i] tager lang tid.
Selv om telefonopkald foretages hyppigt, er det ikke sikkert, at det samlede tidsforbrug er alarmerende. Jeg ville være mere bekymret over den cirkel, der er midt i den højre halvdel. Der er log(tidantal) = log(tid)+log(antal) = 2.1 + 2 = 4.1, mens log(tidantal) for telefonopkald ser ud til at være 0.1 + 3.5 = 3.6.
-
0
-
0
Det er rigtigt, at man kan spare mere tid ved at optimere de opgaver som laves hyppigt og tager lang tid.
Det var bare ikke det problem jeg stod med, da jeg lavede diagrammet. Det er vanskeligt at vurdere hvor lang tid det i gennemsnit vil tage at lave en opgave, når man er ved at planlægge et nyt system. Det viste sig heller ikke at være det afgørende.
Det afgørende var, hvor lang tid opgaven måtte tage, før resultatet ikke længere opfyldte sit formål. For eksempel hvor lang tid en kunde ville blive i telefonen eller vente på at en web-service var færdig og leverede svaret.
-
0
-
0
Glemmer I ikke lige noget med pris ?
Pris som i ddk, risiko for medetid, risiko for dårligt omdømme, ...
Den studerende ("Inderen") i kundesupport er nok meget billig og risikoen er minimal, hvorimod det modsatte er tilfældet når IT er involveret...
Selv har jeg set IT-projekter hvor noget med vold-og-magt skulle håndteres automatisk, men hvor en manuelt løsning ville have meget billigere og med væsentligt øget kvalitet...
Så: forstå problemdomænet (altså det i den virkelige verden, og ikke det i den IT-virtuelle)!
-
0
-
0
Selv har jeg set IT-projekter hvor noget med vold-og-magt skulle håndteres automatisk, men hvor en manuelt løsning ville have meget billigere og med væsentligt øget kvalitet...
Det har jeg også, og det er bindegalt, for en IT-løsning ville være mere besværlig.
Måske tænker nogle binært, dvs. alt eller intet, og netop det, at det er tidskrævende at lave disse ting, gør, at jeg kalder det 'at lave edb til undtagelser, og ikke til reglen'.
Hvis man laver en ROI, ville man hurtigt opdage hvor tåbeligt visse ting er.
-
0
-
0
