mboost-dp1
SXC - nighthawk7
Nu har jeg lige haft kurset Specifikation af IT systemer :-)
Jeg har læst en del artikler om hvordan problemer med de store projekter kan opstå.
Her bliver der tit peget på at kunden forventer at det nye system tilpasser sig kundens eksisterende processer fuldt ud, selvom de måske er fuldstændig tåbelige. Leverandøren får aldrig lov til at rette op på dem, men skal kode rundt om dem i vildskab (=dårligere system).
Det lyder til en sådanne kravspec virkelig kunne hjælpe med netop det, nice!
Jeg har læst en del artikler om hvordan problemer med de store projekter kan opstå.
Her bliver der tit peget på at kunden forventer at det nye system tilpasser sig kundens eksisterende processer fuldt ud, selvom de måske er fuldstændig tåbelige. Leverandøren får aldrig lov til at rette op på dem, men skal kode rundt om dem i vildskab (=dårligere system).
Det lyder til en sådanne kravspec virkelig kunne hjælpe med netop det, nice!
Lyder som en god fremgangsmåde.
Men jeg synes også det er farlig at lade det være op til leverandøren at bestemme hvordan et system skal fungere. Det kan ende med et system som er fuldstændig anderledes end det eksisterende, hvilket resultere i at brugerne slet ikke kan finde rundt i det... Også har vi "modstand mod forandring".
Det skal være en balancegang mellem det gamle system og det nye. Men denne kan være svær at finde. Specielt i komplekse systemer.
I så store systemer, burde man faktisk flytte en superbruge over på udviklingsholdet på fuldtid. Denne brugers opgave er udelukkende at fortælle hvordan de gjorde, og modtage input fra udviklerne om hvordan det kan gøres bedre, også vurdere om funktionen skal erstattes af den nye.
At finde en superbruger som er i stand til dette kan dog vise sig at være meget svær.
Men jeg synes også det er farlig at lade det være op til leverandøren at bestemme hvordan et system skal fungere. Det kan ende med et system som er fuldstændig anderledes end det eksisterende, hvilket resultere i at brugerne slet ikke kan finde rundt i det... Også har vi "modstand mod forandring".
Det skal være en balancegang mellem det gamle system og det nye. Men denne kan være svær at finde. Specielt i komplekse systemer.
I så store systemer, burde man faktisk flytte en superbruge over på udviklingsholdet på fuldtid. Denne brugers opgave er udelukkende at fortælle hvordan de gjorde, og modtage input fra udviklerne om hvordan det kan gøres bedre, også vurdere om funktionen skal erstattes af den nye.
At finde en superbruger som er i stand til dette kan dog vise sig at være meget svær.
"Metoden er endnu ikke særlig udbredt"
Øh, ja måske ikke i det offentlige, men i det private er kravspecifikationer og meget nøjagtig beskrivelse af funktionalitet mm. temmelig udbredt, ihvertfald hvis man ønsker at overleve mere end 6 måneder i branchen.
Men på den anden side, det private har jo heller ikke uendelige ressourcer at trække på hvis noget fucker op, og der er man nødt til at sikre sig bedre med sine samarbejdspartnere og deres forpligtelser.
Øh, ja måske ikke i det offentlige, men i det private er kravspecifikationer og meget nøjagtig beskrivelse af funktionalitet mm. temmelig udbredt, ihvertfald hvis man ønsker at overleve mere end 6 måneder i branchen.
Men på den anden side, det private har jo heller ikke uendelige ressourcer at trække på hvis noget fucker op, og der er man nødt til at sikre sig bedre med sine samarbejdspartnere og deres forpligtelser.
Det er de klassiske kravs-specs, som det her forslag bevæger sig væk fra, over mod behovs-specs.Sofus99 (5) skrev:meget nøjagtig beskrivelse af funktionalitet mm. temmelig udbredt,
Ikke at behovs-specs er noget nyt, men rart at se at der kommer mere fokus på det.
Det er alt for nemt for leverandører at gemme sig bag de traditionelle kravs-specs, da de oftest kan opfyldes for individuelle dele af projektet, uden at det giver noget godt samlet slutresultat.
Søren Lauesen har fuldstændig ret i, at korrekt kravspecifikation handler om at beskrive hvilken information, systemet skal kunne håndtere samt hvordan, informationsstrømmen skal ske.
Brugerne skal generelt blande sig uden om, hvordan opgaven løses.
Så skal systemudviklerne nok selv finde de smarte løsninger. Det er jo det, de kan.
Men hans "case" er ingen løsning på det problem, at det offentliges systemkyndige og IT-leverandørerne tilsyneladende er ude af stand til at tale samme sprog, nemlig et sæt kravsspecifikationer, som både korrekt beskriver kundens ønsker og er omsættelige til programkode.
Jeg mener stadig, at løsningen er statsligt ansatte IT-projekt-tovholdere med ekspertise i netop at undgå de fælder af forkert eller manglende kommunikation mellem kunde og leverandør, som offentlige IT-projekter for tit havner i.
Brugerne skal generelt blande sig uden om, hvordan opgaven løses.
Så skal systemudviklerne nok selv finde de smarte løsninger. Det er jo det, de kan.
Men hans "case" er ingen løsning på det problem, at det offentliges systemkyndige og IT-leverandørerne tilsyneladende er ude af stand til at tale samme sprog, nemlig et sæt kravsspecifikationer, som både korrekt beskriver kundens ønsker og er omsættelige til programkode.
Jeg mener stadig, at løsningen er statsligt ansatte IT-projekt-tovholdere med ekspertise i netop at undgå de fælder af forkert eller manglende kommunikation mellem kunde og leverandør, som offentlige IT-projekter for tit havner i.
Sofus99, problemet er ivirkeligheden at det offentlige har en alt for udførlig beskrevet kravspecifikation (vi snakker ned til font størrelser og margener)
Tværtimod skal de offentlige kører efter iterative processer med løbende releases, som også er en effektiv kvalitetssikring, da de hele tiden for mulighed for at ændre hvis de er utilfredse, eller føler sig misforstået, derudover skal de også give udviklerne mulighed for at forbedre det nuværende flow.
Men i Danmark er vi igang med digitalisering 1.0 som er at oversætte papirarbejdsgang til digital arbejdsgang, digitalersing 2.0 er at forbedre disse digitale arbejdsgange.. Det mest optimale ville jo være at hoppe direkte til 2.0.
Tværtimod skal de offentlige kører efter iterative processer med løbende releases, som også er en effektiv kvalitetssikring, da de hele tiden for mulighed for at ændre hvis de er utilfredse, eller føler sig misforstået, derudover skal de også give udviklerne mulighed for at forbedre det nuværende flow.
Men i Danmark er vi igang med digitalisering 1.0 som er at oversætte papirarbejdsgang til digital arbejdsgang, digitalersing 2.0 er at forbedre disse digitale arbejdsgange.. Det mest optimale ville jo være at hoppe direkte til 2.0.
Jeg har Søren Lauesen i faget "Systematisk Design af Brugergrænseflader" på ITU, og hvis flere softwarevirksomheder havde den viden, som vi får på det fag, så ville mange af de problemer her ikke eksistere.
Jeg har på fornemmelsen, at mange virksomheder laver et brugerinterface, og så direkte går videre med udviklingen af det bagvedliggende (sådan har det i hvert fald været de steder jeg har arbejdet). Men design af brugerinterface er en længere proces, med blandt andet usability-test meget tidligt i forløbet (bl.a. usability-test på hand-written mockups). På den måde kan man finde mange af fejlene tidligt.
Jeg tror lige ledes at mange benytter sig af heuristisk evaluering, men sandheden er at heuristisk evaluering har en "hit-rate" på cirka 50%. Kun halvdelen af det man finder ved heuristisk evaluering er egentlige problemer, og man finder langt fra alle problemerne.
Jeg har på fornemmelsen, at mange virksomheder laver et brugerinterface, og så direkte går videre med udviklingen af det bagvedliggende (sådan har det i hvert fald været de steder jeg har arbejdet). Men design af brugerinterface er en længere proces, med blandt andet usability-test meget tidligt i forløbet (bl.a. usability-test på hand-written mockups). På den måde kan man finde mange af fejlene tidligt.
Jeg tror lige ledes at mange benytter sig af heuristisk evaluering, men sandheden er at heuristisk evaluering har en "hit-rate" på cirka 50%. Kun halvdelen af det man finder ved heuristisk evaluering er egentlige problemer, og man finder langt fra alle problemerne.
Der er masser af forskning der viser, at undersøgelse, analyse, programmering ikke fungerer. Det fungerer ikke fordi, at det ikke er den måde mennesket tænker i en eneste situation af øget kompleksitet. At det offentlige så forsøger at kontraktuelt sikre sig mod vandfaldsmodellens problemer er bare grinagtigt - noget jeg vel ikke behøver at føre bevis for. Tillykke, I får en erstatning og kan inddrive bøder, men ikke noget IT-system.
Som jeg læser modellen fremlagt der, forsøger den netop at anvende en form for iterativ analyse ved f.eks. at anvende sketching, som der også står i artiklen. Det lyder fornuftigt, og hvis det er et worddokument på dansk der skal til for at gumpetunge offentlige ledere opdager hvad alle har skreget om de sidste 20 år, jamen så er jeg all in favour :)
Som jeg læser modellen fremlagt der, forsøger den netop at anvende en form for iterativ analyse ved f.eks. at anvende sketching, som der også står i artiklen. Det lyder fornuftigt, og hvis det er et worddokument på dansk der skal til for at gumpetunge offentlige ledere opdager hvad alle har skreget om de sidste 20 år, jamen så er jeg all in favour :)
#9 jeg tror faktisk ikke problemet er software virksomhedder. Ikke i det offentlige regi i hvert fald. Tror langt mere problemet skyldes at der er alt for mange i det offentlige der lige skal pisse teritoriet af og bestemme et eller andet uden egentlig at vide noget om det.
Det burde kræve minimum et kursus til de folk der skal håndtere kravspesifikationer og andet i det offentlige så de faktisk er klar over hvad det er de har med at gøre.
Hvis vi så samtidig kunne få brugerflader udviklet i form af noget test drevet og i tæt samarbejde med dem der bruger det ville man nå rigtigt langt. Trods alt kan meget af funktionaliteten ofte laves inden man begynder at koble brugerflade på.
Problemet ved det vil så være at det store lag af mellemledere i det off. vil have deres mening om hvor knapperne skal sidde også og ikke nødvendigvis tage snakken med dem der sidder på gulvet.
Modsat i mange virskomhedder er det lettere at komme til at snakke med dem der rent faktisk skal bruge tingene for der ved mellemledere og ledere godt at jo bedre brugerne syns systemet er jo bedre bliver slut resultatet også.
Man kan nogen gange få tanken med det off. at de først ser programmet første gang ved levering og så der opdager en masse ting der ikke virker som de havde troet de ville. Hvor private virksomhedder ofte er mere villige til at blande sig i udviklingen også fordi at hvis de opdager noget er forkert jamen så skal det rettes her og nu inden der er brugt for mange penge på at lave noget andet.
Det burde kræve minimum et kursus til de folk der skal håndtere kravspesifikationer og andet i det offentlige så de faktisk er klar over hvad det er de har med at gøre.
Hvis vi så samtidig kunne få brugerflader udviklet i form af noget test drevet og i tæt samarbejde med dem der bruger det ville man nå rigtigt langt. Trods alt kan meget af funktionaliteten ofte laves inden man begynder at koble brugerflade på.
Problemet ved det vil så være at det store lag af mellemledere i det off. vil have deres mening om hvor knapperne skal sidde også og ikke nødvendigvis tage snakken med dem der sidder på gulvet.
Modsat i mange virskomhedder er det lettere at komme til at snakke med dem der rent faktisk skal bruge tingene for der ved mellemledere og ledere godt at jo bedre brugerne syns systemet er jo bedre bliver slut resultatet også.
Man kan nogen gange få tanken med det off. at de først ser programmet første gang ved levering og så der opdager en masse ting der ikke virker som de havde troet de ville. Hvor private virksomhedder ofte er mere villige til at blande sig i udviklingen også fordi at hvis de opdager noget er forkert jamen så skal det rettes her og nu inden der er brugt for mange penge på at lave noget andet.
#11 Det er interessant. IT uddannede "diplomater" som skal stå for forhandlingerne når der skal erhverves software.
Det er altid svært at lave software til folk der ikke forstår hvordan systemer hænger sammen, hverken deres eget, eller det de ønsker. Resultat bliver et stort gæt.
Det er altid svært at lave software til folk der ikke forstår hvordan systemer hænger sammen, hverken deres eget, eller det de ønsker. Resultat bliver et stort gæt.
Sofus99 (5) skrev:Øh, ja måske ikke i det offentlige, men i det private er kravspecifikationer og meget nøjagtig beskrivelse af funktionalitet mm. temmelig udbredt, ihvertfald hvis man ønsker at overleve mere end 6 måneder i branchen.
Hvis du fulgte lidt med i debatten ville du vide at offentlige projekter som oftest kritiseres for for stramme krav spec.
Jeg er tror ikke på at det er problemet, men det er en anden debat.
Ihvertfald bruger det offentlige krav spec.
Det diskussionen her drejer sig om er hvilken for for krav spec.
andsens (1) skrev:Her bliver der tit peget på at kunden forventer at det nye system tilpasser sig kundens eksisterende processer fuldt ud, selvom de måske er fuldstændig tåbelige. Leverandøren får aldrig lov til at rette op på dem, men skal kode rundt om dem i vildskab (=dårligere system).
Tore (8) skrev:Men i Danmark er vi igang med digitalisering 1.0 som er at oversætte papirarbejdsgang til digital arbejdsgang, digitalersing 2.0 er at forbedre disse digitale arbejdsgange.. Det mest optimale ville jo være at hoppe direkte til 2.0.
Ideen lyder meget god.
Men det fungerer sjældent godt i praksis.
Problemerne ved strategien:
* modstand fra brugerne mod at tingene laves om
* manglende feedback fra brugerne fordi de ikke kan hjælpe med en process de ikke kender
vil som oftest mere end opveje fordelene.
Det kræver super-ledelse hos kunden at gennemføre den slags revolutionerende projekter.
nbhansen (10) skrev:Der er masser af forskning der viser, at undersøgelse, analyse, programmering ikke fungerer.
Det fungerer faktisk ofte udmærket.
Det meste af kritikken kommer fra nogen som lige har opfundet den nye super metodik XYZ der kan sikre success i IT projekter. Og af en eller anden årsag hellere vil tjene småpenge på en bog om metodikken fremfor at starte deres eget software firma og blive multi milliardærer (for det er utænkeligt at de selv skulle mene at deres nye metodik er 10% nye gode ideer + 40% kendte gode ideer + 50% snake oil).
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund