mboost-dp1
www.politi.dk
Ok - der må da være en gylden mellemvej mellem at udvikle internt og at udbyde et system til en dyr, dyr udvikler, der ender med at skabe et monster til et system til alt for mange penge....
Folk taler vist som de har forstand :)
Polvagt var udviklet (billigt!) til politiet i Århus og her var/er der stor tilfredshed med det.
Herefter vælger man så fra central side at implementere systemet hos de andre politikredse uden(her gætter jeg!) at have fuldt overblik over arbejdsgange, processer og praksis.
At systemet så under ibrugtagning viser sig ikke at passe ind i praksis eller omvendt, at praksis viser sig ikke at kunne tilpasses i tilstrækkelig grad må være det resultat man kan forvente.
Dem der har fejlet her, lader i høj grad til at være ledelsen. De har villet spare ved at hente et system der virker i én kreds og satse på at det uden videre(eller med lidt lappearbejde) kan fungere i alle kredse...
Sådan fungerer verden ikke...
Som mange herinde ved er der altid nogle grundlæggende antagelser der bliver gjort ift. modelleringen af et IT system. Hvilke enheder opereres der med, hvilken logik osv.
Det er ikke nogen smal sag at ændre på det mest grundlæggende hvilket mange store virksomheders erfaringer med eks. SAP illustrerer.
(en undersøgelser af vellykkede og mislykkedes SAP implementeringsforløb i DK kan ses her mod betaling: http://www.herbertnathan.dk/publikationer/sap360-r... )
Polvagt var udviklet (billigt!) til politiet i Århus og her var/er der stor tilfredshed med det.
Herefter vælger man så fra central side at implementere systemet hos de andre politikredse uden(her gætter jeg!) at have fuldt overblik over arbejdsgange, processer og praksis.
At systemet så under ibrugtagning viser sig ikke at passe ind i praksis eller omvendt, at praksis viser sig ikke at kunne tilpasses i tilstrækkelig grad må være det resultat man kan forvente.
Dem der har fejlet her, lader i høj grad til at være ledelsen. De har villet spare ved at hente et system der virker i én kreds og satse på at det uden videre(eller med lidt lappearbejde) kan fungere i alle kredse...
Sådan fungerer verden ikke...
Som mange herinde ved er der altid nogle grundlæggende antagelser der bliver gjort ift. modelleringen af et IT system. Hvilke enheder opereres der med, hvilken logik osv.
Det er ikke nogen smal sag at ændre på det mest grundlæggende hvilket mange store virksomheders erfaringer med eks. SAP illustrerer.
(en undersøgelser af vellykkede og mislykkedes SAP implementeringsforløb i DK kan ses her mod betaling: http://www.herbertnathan.dk/publikationer/sap360-r... )
Ni (4) skrev:I alt andet har man medarbejdergrupper i bunden af systemet til at hjælpe med at udarbejde kravsspecifikationerne, hvorfor tror it udviklerer at de er tankelæserer?
Det er da udviklernes ansvar at sige hey, skal vi ikke undersøge forholdene inden vi giver den gas?
[Intet af værdi]
Hvor mange udviklere og tankelæsere er der lige? ;)
[/Intet af værdi]
Som #1 er inde på, så synes jeg også tit, at det lyder som om, at der bare bliver taget beslutninger uden foregående undersøgelser.
#6 Mener man, at man som udvikler ikke har behov for en forudgående undersøgelse, så må man vel være tankelæser, hvordan skulle man ellers vide, hvilken hverdag programmet skal fungerer i? - Så alt for mange, udviklere kigger generelt dumt på folk der fortæller dem, hvilke krav de har brug for.
En ansvarlig udvikler brude stille det som krav, at lave en undersøgelse og vide, at en chef ofte ikke kender de specifikke procedure, udvikleren er derfor hamrende inkompetent, når han acceptere et svar eller en beslutning fra ledelsen. Det er udviklerens ansvar at levere et produkt der fungerer til det som er hensigten, han skal vide, hvilken viden han skal bruge og kvaliteten af den for at nå målet.
Det er ikke chefen i den pågældende institution eller virksomhed der skal vide, hvilken viden udvikleren har brug for, hvordan skulle han vide det, han er jo heller ikke tankelæser. Så når udvikleren ikke iværksætter en undersøgelse, så er det udvikleren der er inkompetent, for han bør vide, hvad han skal bruge af data for at kunne levere et produkt af den forventede kvalitet.
Folk elsker at skyde efter ledelsen, specielt i offentlige virksomheder, men sandheden er, at vi nok ikke rigtigt har kompetente it virksomheder i Danmark, når så mange projekter køre af sporet. Det er it virksomhederne som skal vide, om et projekt kan lykkes eller ej, og afgrænse det ordenligt inden det udviklingen startes, så ledelsens ikke har en forvetning om, at vi kan da lige tilføje sådan og sådan.
Hvis samme inkompetence gjorde sig gældende i byggebrancen, så ville byggerier falde sammen om ørene på os. Der er inginørerne gode nok til at sige, hvad der kan og ikke lade sig gøre fra starten og det må it branchen altså snart forstå, at de er inkompetente, når de ikke kan det.
Prisen for kæmpe store byggeprojekter kan fastsætte rimeligt præcis.
En ansvarlig udvikler brude stille det som krav, at lave en undersøgelse og vide, at en chef ofte ikke kender de specifikke procedure, udvikleren er derfor hamrende inkompetent, når han acceptere et svar eller en beslutning fra ledelsen. Det er udviklerens ansvar at levere et produkt der fungerer til det som er hensigten, han skal vide, hvilken viden han skal bruge og kvaliteten af den for at nå målet.
Det er ikke chefen i den pågældende institution eller virksomhed der skal vide, hvilken viden udvikleren har brug for, hvordan skulle han vide det, han er jo heller ikke tankelæser. Så når udvikleren ikke iværksætter en undersøgelse, så er det udvikleren der er inkompetent, for han bør vide, hvad han skal bruge af data for at kunne levere et produkt af den forventede kvalitet.
Folk elsker at skyde efter ledelsen, specielt i offentlige virksomheder, men sandheden er, at vi nok ikke rigtigt har kompetente it virksomheder i Danmark, når så mange projekter køre af sporet. Det er it virksomhederne som skal vide, om et projekt kan lykkes eller ej, og afgrænse det ordenligt inden det udviklingen startes, så ledelsens ikke har en forvetning om, at vi kan da lige tilføje sådan og sådan.
Hvis samme inkompetence gjorde sig gældende i byggebrancen, så ville byggerier falde sammen om ørene på os. Der er inginørerne gode nok til at sige, hvad der kan og ikke lade sig gøre fra starten og det må it branchen altså snart forstå, at de er inkompetente, når de ikke kan det.
Prisen for kæmpe store byggeprojekter kan fastsætte rimeligt præcis.
Ni (4) skrev:I alt andet har man medarbejdergrupper i bunden af systemet til at hjælpe med at udarbejde kravsspecifikationerne, hvorfor tror it udviklerer at de er tankelæserer?
Det er da udviklernes ansvar at sige hey, skal vi ikke undersøge forholdene inden vi giver den gas?
Nu arbejder jeg selv som udvikler, og nej vi er ikke tankelæsere og brugerne er langt fra eksperter når det kommer til at forklare deres krav og specifikationer.
Ansvaret her har ligget hos Projekt Ledelsen.
Dem der har udviklet dette PolVagt har tydeligvis gjort det specifikt med formål til en enkelt kreds eller 2, og så har ledelsen valgt at udvidede det lidt for ekstremt, hvilket jeg kan kan forstå giver Overhead og svartider helt ude i hampen, dette viste udviklerne ikke den gang, og de har stensikkert ikke været inden over udvidelsen. (Sikkert for at spare penge)
Udviklere er ikke guder, vi har brug for projektlederne til at forklare os hvad det faktisk er kunden gerne vil have!
Samt levere dejlige Flowcharts og ikke bare et dokument med teksten "Vi vil have en side hvor vi kan trykke vagter ind!"
Et system til at håndtere vagtplaner burde virkelig ikke være årsag til at de ligefrem bliver tvunget ud i opsigelse og skilsmisse og hvad der ellers står i kilden..
Har Politiet for høje forventninger til deres IT generelt, og hvorfor skal der opfindes nye systemer hver gang de vil bruge en computer?
De kunne jo se på hvordan andre lande eller store virksomheder håndtere det og så købe en færdig fungerende løsning, som de efterfølgende lærer brugerne at benytte.
Men mon ikke strisserne efterhånden har så meget modvilje mod IT at det vil være umuligt at indføre noget som helst.
Har Politiet for høje forventninger til deres IT generelt, og hvorfor skal der opfindes nye systemer hver gang de vil bruge en computer?
De kunne jo se på hvordan andre lande eller store virksomheder håndtere det og så købe en færdig fungerende løsning, som de efterfølgende lærer brugerne at benytte.
Men mon ikke strisserne efterhånden har så meget modvilje mod IT at det vil være umuligt at indføre noget som helst.
Tydeligvis et system udviklet af nogen klamphuggere og amatører. Ligesom det andet. At det begynder at køre langsomt når der sættes flere brugere til er jo et tydeligt tegn på at det er noget bras.
At virksomheder er uærlige og forsøger at snyde er intet nyt. IT virksomheder der leverer til det offentlige er i høj grad styret af kyniske opportunister der leverer skrammel lavet i sidste øjeblik, og ved de offentlige institutioner er der ingen der har forstand på noget til at kunne give sparing skulle en virksomhed for en gangs skyld være ærlig.
En kammerats arbejdsplads havde skullet lave noget for en kommuneforvaltning, men de droppede opgaven fordi når de forsøgte at kontakte kommunen og give sparring og finde frem til et godt produkt blev de mødt med "det ved vi ikke noget om, lad være med at ringe tilbage før i er færdige" flere gange. Hvordan kan man levere et godt produkt under den slags forhold?
At virksomheder er uærlige og forsøger at snyde er intet nyt. IT virksomheder der leverer til det offentlige er i høj grad styret af kyniske opportunister der leverer skrammel lavet i sidste øjeblik, og ved de offentlige institutioner er der ingen der har forstand på noget til at kunne give sparing skulle en virksomhed for en gangs skyld være ærlig.
En kammerats arbejdsplads havde skullet lave noget for en kommuneforvaltning, men de droppede opgaven fordi når de forsøgte at kontakte kommunen og give sparring og finde frem til et godt produkt blev de mødt med "det ved vi ikke noget om, lad være med at ringe tilbage før i er færdige" flere gange. Hvordan kan man levere et godt produkt under den slags forhold?
#8 Hvis nogle kommer med en tekst "Vi vil have en side, hvor vi kan trykke vagter ind", så er det efter min mening udviklerens ansvar at sige, det kan ikke lade sig gøre ud fra den beskrivelse.
En ingeniør accpetere jo heller ikke en ordre på "et hus man kan bo i" - Og skræderen acceptere ikke en odre "på et par bukser" osv. :-D
Jeg ved godt, at det er et ekstremt eksempel du kommer med for sjov, men jeg synes stadig, at du fint illusterer problemet i it branchen. Der er ingen andre brancher, hvor den tilgang til sit arbejde ville gå :-D
Og nej, brugerne er ikke eksperter, man skal have eksperter til at stille brugeren de rigtige spørgsmål. Det er som oftes statskundskabere, sociologier og psykologer der kan finde ud af det. De er ihvertfald uddannet til det.
En ingeniør accpetere jo heller ikke en ordre på "et hus man kan bo i" - Og skræderen acceptere ikke en odre "på et par bukser" osv. :-D
Jeg ved godt, at det er et ekstremt eksempel du kommer med for sjov, men jeg synes stadig, at du fint illusterer problemet i it branchen. Der er ingen andre brancher, hvor den tilgang til sit arbejde ville gå :-D
Og nej, brugerne er ikke eksperter, man skal have eksperter til at stille brugeren de rigtige spørgsmål. Det er som oftes statskundskabere, sociologier og psykologer der kan finde ud af det. De er ihvertfald uddannet til det.
#12 Jamen jeg skal jo også arbejde, så det bliver ikke læst så grundigt igennem :-/
Jeg mener egentligt bare, at når alle andre brancher kan levere store komplekse projekter uden det køre fuldstændig af sporet, så må fejlen ligge i den måde it branchen håndtere projekterne på.
Og min egen erfaring med udviklerer er, at de er arrogante og bedrevidene. Hvis de lyttede, når de var ude på arbejdspladserne, ville mange fundementale fejl kunne undgås.
Min egen erfaring kan jo ikke nødvendigvis perspektiveres, så den er gældende for hele branchen, så det er en antagelse, at de problemer også findes i mange andre udviklingsprojekter.
Jeg mener egentligt bare, at når alle andre brancher kan levere store komplekse projekter uden det køre fuldstændig af sporet, så må fejlen ligge i den måde it branchen håndtere projekterne på.
Og min egen erfaring med udviklerer er, at de er arrogante og bedrevidene. Hvis de lyttede, når de var ude på arbejdspladserne, ville mange fundementale fejl kunne undgås.
Min egen erfaring kan jo ikke nødvendigvis perspektiveres, så den er gældende for hele branchen, så det er en antagelse, at de problemer også findes i mange andre udviklingsprojekter.
#11 Problemet ligger jo i at ALLE vil spare hvor de kan. Chefer forstår ikke hvor meget arbejde der ligger i at lave et stykke software der er udviklet specifikt efter deres krav, og derfor nægter de at betale den pris det egentlig burde koste.
Det resulterer i at man skærer mellemanden væk (eller ihvertfald holder det til et absolut minimum) - Det vil inden for IT branchen typisk betyde projektlederne og konsulenterne, og i stedet giver man blot udviklerne de her typer opgaver.
Forskellen er at de andre brancher har fattet at man bliver nød til at have folk der er et bindeled mellem dem der vil have udført et stykke arbejde og dem der udfører det.
For at bruge dit eksempel, så er vi ude i at et eller andet firma ville have en stor bygning bygget, og de så bare springer arkitekter, ingeniører osv. over, og blot hyrer en masse håndværkere til arbejdet.
Det jeg vil frem til er det som #8 er inde på..
Udviklere har sjældent en eller anden form for projektlederbaggrund, så den eneste måde de har lært at takle et problem på, er bare at knokle løs det bedste de har lært... Det kan man ikke klandre dem for - I stedet burde man sørge for at have de nødvendige bindeled der forstår at få oversat "Lav en side til vores vagtplaner" til alle de nødvendige kravsspecifikationer og illustrationer.
Det resulterer i at man skærer mellemanden væk (eller ihvertfald holder det til et absolut minimum) - Det vil inden for IT branchen typisk betyde projektlederne og konsulenterne, og i stedet giver man blot udviklerne de her typer opgaver.
Forskellen er at de andre brancher har fattet at man bliver nød til at have folk der er et bindeled mellem dem der vil have udført et stykke arbejde og dem der udfører det.
For at bruge dit eksempel, så er vi ude i at et eller andet firma ville have en stor bygning bygget, og de så bare springer arkitekter, ingeniører osv. over, og blot hyrer en masse håndværkere til arbejdet.
Det jeg vil frem til er det som #8 er inde på..
Udviklere har sjældent en eller anden form for projektlederbaggrund, så den eneste måde de har lært at takle et problem på, er bare at knokle løs det bedste de har lært... Det kan man ikke klandre dem for - I stedet burde man sørge for at have de nødvendige bindeled der forstår at få oversat "Lav en side til vores vagtplaner" til alle de nødvendige kravsspecifikationer og illustrationer.
Jeg kan bidrage med en smule fakta omkring POLVAGT. I sin tid udviklede en gruppe studerende et vagtplanlægningsprogram til Århus politikreds (Det var vist deres afsluttende projekt) - Det var et simpelt standalone program til planlægning af vagter via en web frontend. Stor var succesen, da politifolkene ret enkelt kunne planlægge og bytte vagter - Og derfor ville både alle de andre politikredse og Politiforbundet have en landsdækkende løsning som så foruden planlægningen, validering og bytteri og lige skulle kunne hente og overføre data til og fra Politiets HR system (En SAP løsning).
At lave et vagtplanlægningsprogram, med integration til andre systemer, planlægning, godkendelsesworkflow (vist noget de kalder de t dobbelte asynkrone verifikationsprincip), validering af vagtplanen op imod alle gældende arbejdstidsregler samt efteerfølgende overførsel af data til Politiets SAP system er ret anderledes end en standalone applikation og ikke bare lige noget der laves overnight :-)
Det største problem i hele det projekt er, at det ikke har været styret af Politiets IT afdeling, men af deres HR afdeling.
Jeg har intet til overs for Politiforbundet og deres klager. Problemet er jo at et planlægningsprogram overholder de regler der bliver puttet ind i programmet (hvilket jo er regler som Politiforbundet selv har forhandlet på plads med ministeriet). Så nu kan de stakkels politimænd ikke længere fuske med deres arbejdstider. Det går jo fint med papir og blyant, men når planen bliver valideret i et program, så siger den jo stop, når der er ting som konflikter. Den lektie lærte forsvarets døgnbemandede enheder for mange år siden, da de overførte planlægningen til deres DeMars (også en SAP løsning)...
At lave et vagtplanlægningsprogram, med integration til andre systemer, planlægning, godkendelsesworkflow (vist noget de kalder de t dobbelte asynkrone verifikationsprincip), validering af vagtplanen op imod alle gældende arbejdstidsregler samt efteerfølgende overførsel af data til Politiets SAP system er ret anderledes end en standalone applikation og ikke bare lige noget der laves overnight :-)
Det største problem i hele det projekt er, at det ikke har været styret af Politiets IT afdeling, men af deres HR afdeling.
Jeg har intet til overs for Politiforbundet og deres klager. Problemet er jo at et planlægningsprogram overholder de regler der bliver puttet ind i programmet (hvilket jo er regler som Politiforbundet selv har forhandlet på plads med ministeriet). Så nu kan de stakkels politimænd ikke længere fuske med deres arbejdstider. Det går jo fint med papir og blyant, men når planen bliver valideret i et program, så siger den jo stop, når der er ting som konflikter. Den lektie lærte forsvarets døgnbemandede enheder for mange år siden, da de overførte planlægningen til deres DeMars (også en SAP løsning)...
Meganight (8) skrev:Ni (4) skrev:I alt andet har man medarbejdergrupper i bunden af systemet til at hjælpe med at udarbejde kravsspecifikationerne, hvorfor tror it udviklerer at de er tankelæserer?
Det er da udviklernes ansvar at sige hey, skal vi ikke undersøge forholdene inden vi giver den gas?
Nu arbejder jeg selv som udvikler, og nej vi er ikke tankelæsere og brugerne er langt fra eksperter når det kommer til at forklare deres krav og specifikationer.
Ansvaret her har ligget hos Projekt Ledelsen.
Dem der har udviklet dette PolVagt har tydeligvis gjort det specifikt med formål til en enkelt kreds eller 2, og så har ledelsen valgt at udvidede det lidt for ekstremt, hvilket jeg kan kan forstå giver Overhead og svartider helt ude i hampen, dette viste udviklerne ikke den gang, og de har stensikkert ikke været inden over udvidelsen. (Sikkert for at spare penge)
Udviklere er ikke guder, vi har brug for projektlederne til at forklare os hvad det faktisk er kunden gerne vil have!
Samt levere dejlige Flowcharts og ikke bare et dokument med teksten "Vi vil have en side hvor vi kan trykke vagter ind!"
Det er derfor at man ikke har direkte kontakt med kunden/brugerne som udvikler.
Kunder snakker altid på Russisk mens udviklere snakker på Mandarin. Derfor er man nødt til at have en projektdesigner ind midt i mellem, der kan agere tolk.
Det er projektdesignerens opgave at forstå de to abstrakte verdener og formidle det videre på et sprog alle kan forstå.
Projektlederens opgave er at sørge for at tidsrammen bliver overholdt, samt håndtere problemer undervejs, typisk i udviklingen, men også at holde kundernes ønsker tilbage så udviklerne kan fokusere på helheden, i stedet for at lave konstante ændringer der øger kompleksiteten af den igangværende udviklingsrunde.
#16 Interessant :)
Jeg har som arbejdssociolog været med i et større forskningsprojekt om digital arbejdstidsplanlægning i skifteholdsarbejde. Her var det desværre primært sundhedssektoren samt et callcenter, der blev undersøgt. Det kunne have været ret spændende at undersøge politiet også.
Rytmerne i løbet af arbejdsdagen og udfordringerne med planlægningen på en politistation og et hospital minder dog umiddelbart meget om hinanden.
Vores resultater viste først og fremmest, at der var stor forskel på systemernes brugervenlighed og funktioner. Men ikke en sammenhæng mellem systemernes eller implementerings ambitionsniveau og resultaterne.
De gode resultater skete der, hvor der blev skabt dialog og læring omkring daglig praksis i brugen af systemet. Kommunikation om systemets muligheder og begrænsninger samt øje for arbejdspladsens arbejdsgange var nøglen til succes.
Faktisk var der gode erfaringer med et system, der kunne meget lidt, og som var ret fejlbehæftet, simpelthen fordi man indførte det inkrementelt i takt med at arbejdspladsen blev modnet.
Et andet system advarede medarbejderne om, når de var ved at bryde overenskomstfastlagte arbejdstidsaftaler i deres vagtbytte, men de var stadig i stand til at foretage byttet. Dette var de rigtigt glade for, fordi de så sig selv som dem der bedst kunne varetage deres vagtlængder, restitution og antal vagter i løbet af ugen.
Ift. polvagt lyder det som om, at både system og implemetering har fejlet. Ansvaret har i begge tilfælde ligget hos HR. Det lyder umiddelbart som om, de ikke i tilstrækkelig grad har været i dialog med forbund, MED-udvalg, tillidsvalgte, arbejdsmiljøorganisation osv osv. Det har gjort dem ude af stand til tilstrækkelig kravsspecifikation. Og så har de nok heller ikke haft de dygtigste udviklere. Endelig har de tilsyneladende indført en lang række ændringer samtidig frem for inkrementelt, hvilket er farligt, hvis implementeringen (læring og kommunikation) ikke sidder lige i skabet.
Jeg har som arbejdssociolog været med i et større forskningsprojekt om digital arbejdstidsplanlægning i skifteholdsarbejde. Her var det desværre primært sundhedssektoren samt et callcenter, der blev undersøgt. Det kunne have været ret spændende at undersøge politiet også.
Rytmerne i løbet af arbejdsdagen og udfordringerne med planlægningen på en politistation og et hospital minder dog umiddelbart meget om hinanden.
Vores resultater viste først og fremmest, at der var stor forskel på systemernes brugervenlighed og funktioner. Men ikke en sammenhæng mellem systemernes eller implementerings ambitionsniveau og resultaterne.
De gode resultater skete der, hvor der blev skabt dialog og læring omkring daglig praksis i brugen af systemet. Kommunikation om systemets muligheder og begrænsninger samt øje for arbejdspladsens arbejdsgange var nøglen til succes.
Faktisk var der gode erfaringer med et system, der kunne meget lidt, og som var ret fejlbehæftet, simpelthen fordi man indførte det inkrementelt i takt med at arbejdspladsen blev modnet.
Et andet system advarede medarbejderne om, når de var ved at bryde overenskomstfastlagte arbejdstidsaftaler i deres vagtbytte, men de var stadig i stand til at foretage byttet. Dette var de rigtigt glade for, fordi de så sig selv som dem der bedst kunne varetage deres vagtlængder, restitution og antal vagter i løbet af ugen.
Ift. polvagt lyder det som om, at både system og implemetering har fejlet. Ansvaret har i begge tilfælde ligget hos HR. Det lyder umiddelbart som om, de ikke i tilstrækkelig grad har været i dialog med forbund, MED-udvalg, tillidsvalgte, arbejdsmiljøorganisation osv osv. Det har gjort dem ude af stand til tilstrækkelig kravsspecifikation. Og så har de nok heller ikke haft de dygtigste udviklere. Endelig har de tilsyneladende indført en lang række ændringer samtidig frem for inkrementelt, hvilket er farligt, hvis implementeringen (læring og kommunikation) ikke sidder lige i skabet.
Ni (7) skrev:Hvis samme inkompetence gjorde sig gældende i byggebrancen, så ville byggerier falde sammen om ørene på os. Der er inginørerne gode nok til at sige, hvad der kan og ikke lade sig gøre fra starten og det må it branchen altså snart forstå, at de er inkompetente, når de ikke kan det.
Ni (7) skrev:Prisen for kæmpe store byggeprojekter kan fastsætte rimeligt præcis.
Desværre er der visse forskelle mellem bygge projekter og IT projekter.
Bygge branchen har 5000 års erfaring. IT branchen har 50 års erfaring.
Et IT projekt til pris på X har langt større komleksitet end et bygge projekt til pris X.
Indenfor IT branchen udskiftes "materialer" og "værktøjer" langt hurtigere end indenfor bygge branchen.
Da man i IT kan lave perfekte kopier til næsten ingen penge, så er IT projekter altid "nyt"
Ni (7) skrev:Mener man, at man som udvikler ikke har behov for en forudgående undersøgelse, så må man vel være tankelæser, hvordan skulle man ellers vide, hvilken hverdag programmet skal fungerer i?
Ni (7) skrev:Så når udvikleren ikke iværksætter en undersøgelse, så er det udvikleren der er inkompetent, for han bør vide, hvad han skal bruge af data for at kunne levere et produkt af den forventede kvalitet.
Hmm.
Det fremgår klart af artiklen og er blevet uddybet i #5 (og #16) at systemet fungerede fint i Århus.
Og der forlyder intet om at udviklerne ikke snakkede med brugerne.
Problemerne opstod da løsningen blev flyttet til København.
Ni (13) skrev:
Og min egen erfaring med udviklerer er, at de er arrogante og bedrevidene. Hvis de lyttede, når de var ude på arbejdspladserne, ville mange fundementale fejl kunne undgås.
Men brugere som kommenterer på en artikel uden at læse indholdet og antager at udviklerne ikke har snakket med brugerne uden noget som helst belæg for det er ikke arrogante????
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