mboost-dp1
www.politi.dk
El_Coyote (1) skrev:Hr. Landbetjent og frue har vel ikke været vandt til at bruge det der nymodens PC-pjat
korrekt..
Det ender derfor altid med at projekter, små som store, bliver dyrere end beregnet, netop fordi man ikke har spurgt manden på gulvet..
En udvikler kunne lave en applikation der tilgås via CLI for at kunne opfylde funktionalitetskravene til en given applikation. Problemet er når Hr Jensen skal bruge det - og han for øvrigt godt kunne tænke sig en "lav kaffe" knap, en "direkte til ekstrabladet knap" osv osv..
Det lyder som om hun har fat i den rigtige ende - start nedefra: hvad kan brugerne og skal disse evt uddannes inden man kan sætte avancerede systemer i luften..
Der har været comments på andre fora som jeg synes har været relevante. De omhandlede at projekt kontoret blot er blevet oprettet for at kunne skyde skylden på nogen, andre end cheferne.
Problemets kerne er at Politiet som alle andre statslige ting, er offentligt. Det offentlige er underlagt reglerne om udbud, reglerne om udbud kan omgås til det privates fordel.
Omgåelsen består i at overskridelser af tid og budget er lovlige - hvilket resulterer i kontrakter der er uopnåelige / umulige: Overskrid bliver et 'krav', men projektet var da 'billigt' til at starte med for staten.
Problemets kerne er at Politiet som alle andre statslige ting, er offentligt. Det offentlige er underlagt reglerne om udbud, reglerne om udbud kan omgås til det privates fordel.
Omgåelsen består i at overskridelser af tid og budget er lovlige - hvilket resulterer i kontrakter der er uopnåelige / umulige: Overskrid bliver et 'krav', men projektet var da 'billigt' til at starte med for staten.
LordMike (4) skrev:Der har været comments på andre fora som jeg synes har været relevante. De omhandlede at projekt kontoret blot er blevet oprettet for at kunne skyde skylden på nogen, andre end cheferne.
Fordelen ved projekt kontoret er der sidder nogen som har skylden i forvejen når et projekt starter. 3/4 af udgifterne i et offentlig software projekt går på at alle parter sikrer sig at intet er deres skyld, og at de altid kan forsvare sig med 3. parts rapport, som ikke hjælper projektet nogen steder hen. Men det hjælper til at kunne flytte sorteper når det går galt. ( Og det ved alle jo alligevel at det gør. )
#0
Jeg undrer mig lidt over hvad der fremhæves som en løsning på problemerne.
Hvis problemet er at systemerne leveres on time og on budget, men at de ansatte ikke kan finde ud af systemerne eller at systemerne ikke passer til arbejdsopgaverne, så giver det rigtigt god mening at fokusere på brugerne.
Hvis problemet er at systemerne er forsinkede og over budget, så hjælper det ikke en snus at fokusere på brugerne.
Og desværre så ....
Jeg undrer mig lidt over hvad der fremhæves som en løsning på problemerne.
Hvis problemet er at systemerne leveres on time og on budget, men at de ansatte ikke kan finde ud af systemerne eller at systemerne ikke passer til arbejdsopgaverne, så giver det rigtigt god mening at fokusere på brugerne.
Hvis problemet er at systemerne er forsinkede og over budget, så hjælper det ikke en snus at fokusere på brugerne.
Og desværre så ....
noisycricket (2) skrev:Det ender derfor altid med at projekter, små som store, bliver dyrere end beregnet, netop fordi man ikke har spurgt manden på gulvet..
Man skal have respekt for brugerne, men de er netop kun brugere/ansatte - det er ledelsen som skal sætte målene med hjælp fra nedsatte udvalg med interne og eksterne fageksperter. Ledelsen skal selvfølgelig bakke projektledelsen op.
Tanken om at lade fagforeninger og ansatte bestemme direkte hvilke funktioner der skal være i systemer har man prøvet et sted... i hjemmeplejen og det holdt tydeligvis ikke.
nubus (8) skrev:Man skal have respekt for brugerne, men de er netop kun brugere/ansatte - det er ledelsen som skal sætte målene med hjælp fra nedsatte udvalg med interne og eksterne fageksperter. Ledelsen skal selvfølgelig bakke projektledelsen op.
Kun hvis man vil være sikker på en fiasko.
Ledelsen skal udstikke hvad man vil, men medarbejderne skal spørges om hvordan man opnår det.
Det er de færreste chefer der har evner til at forklare hvordan skærmbilleder, stam data etc. bør struktureres.
nubus (8) skrev:Tanken om at lade fagforeninger og ansatte bestemme direkte hvilke funktioner der skal være i systemer har man prøvet et sted... i hjemmeplejen og det holdt tydeligvis ikke.
Hjemmeplejen er da netop et klassisk eksempel på at det ikke fungerer godt med chefer og ekspert udregnet minut tal.
arne_v (9) skrev:Hjemmeplejen er da netop et klassisk eksempel på at det ikke fungerer godt med chefer og ekspert udregnet minut tal.
Dét tør siges. Min mor der ellers nok kan prædike trafikmoral må tilstå at ligge med 130 på landevejene for at nå kvoten... Heldigvis kører hun aften og nat... :-|
Nu har jeg efterhånden læst mange meninger omkring hvorfor POLSAG og andre offentlige systemer ikke når at blive leveret til tiden og altid koster mere end de oprindelige projekt projekteringer.
Det skal siges at jeg har selv været med som udvikler på POLSAG og andre offentlige systemer.
Den grundliggende fejl i alle de projekter som pt. er under udvikling er:
1) Udviklerne bliver ikke spurgt til råds eller lyttet til. Projektet bliver som regel ledet af en navle-pillende papir nusser der absolut intet fatter af udvikling af systemer eller applikationer.
Af alle projektledere jeg har haft, har jeg kun mødt en som tidligere var uddannet, og havde arbejdet som udvikler. Resten er økonomer, eller personer som havde arbejdet sig hurtigt op ad rangstigen.
De har egentlig ikke nogen udpræget interesse i udvikling, men kun deres egen karriere.
De springer fra projekt til projekt, og kan de overlevere grønne tal på bundlinien for afd. er det godt for ham. Alt andet kan tørres af på folk under ham.
2) Den pris der bliver aftalt for et projekt har somregel intet med den reelle regning. De underbyder konkurrenterne og lover en deadline som ikke kan overholdes, vedvidende om at det ikke kan lade sig at gøre. Når man først er halvvejs inde i udviklingsfasen kan man altid genforhandle.
3) Virksomheder som påtager sig opgaver af den størrelse, har også selv en vist størrelse for at kunne løfte opgaven. IBM, Siemens, CSC, KMD osv... Det er en 'organisation' og ikke bare et firma, og derfor går der nemt politik i tingene...
Der er andre afgørende faktorer specifikt omkring POLSAG, men jeg må desværre nok ikke udtale mig om det.
Men det ville nu være dejligt hvis alle hjernedøde chefer forsvandt og overlod arbejdet til dem som egentlig har forstand på hvad de laver.
Det skal siges at jeg har selv været med som udvikler på POLSAG og andre offentlige systemer.
Den grundliggende fejl i alle de projekter som pt. er under udvikling er:
1) Udviklerne bliver ikke spurgt til råds eller lyttet til. Projektet bliver som regel ledet af en navle-pillende papir nusser der absolut intet fatter af udvikling af systemer eller applikationer.
Af alle projektledere jeg har haft, har jeg kun mødt en som tidligere var uddannet, og havde arbejdet som udvikler. Resten er økonomer, eller personer som havde arbejdet sig hurtigt op ad rangstigen.
De har egentlig ikke nogen udpræget interesse i udvikling, men kun deres egen karriere.
De springer fra projekt til projekt, og kan de overlevere grønne tal på bundlinien for afd. er det godt for ham. Alt andet kan tørres af på folk under ham.
2) Den pris der bliver aftalt for et projekt har somregel intet med den reelle regning. De underbyder konkurrenterne og lover en deadline som ikke kan overholdes, vedvidende om at det ikke kan lade sig at gøre. Når man først er halvvejs inde i udviklingsfasen kan man altid genforhandle.
3) Virksomheder som påtager sig opgaver af den størrelse, har også selv en vist størrelse for at kunne løfte opgaven. IBM, Siemens, CSC, KMD osv... Det er en 'organisation' og ikke bare et firma, og derfor går der nemt politik i tingene...
Der er andre afgørende faktorer specifikt omkring POLSAG, men jeg må desværre nok ikke udtale mig om det.
Men det ville nu være dejligt hvis alle hjernedøde chefer forsvandt og overlod arbejdet til dem som egentlig har forstand på hvad de laver.
#11
Du tænker på:
:-)
Pålidelige estimater kræver at den der laver estimaterne har erfaring med opgaver af den type og tilstrækkelig teknisk indsigt til at kunne vurdere konsekvenserne af forskellige specifikke krav.
For at alle praktisk formål betyder det en software person.
En projekt leder behøver ikke at have forstand på programmering. En projekt leder behøver at have forstand på projektledelse.
Forstand på projektledelse inkluderer at spørge folk med den nødvendige viden, når der er behov for det.
Du tænker på:
import java.util.List;
import java.util.Random;
public class NonSoftwarePersonProjectManager {
private static Random rng = new Random();
public int estimate(List<Requirement> req) {
return rng.nextInt(100) + 1;
}
}
:-)
Pålidelige estimater kræver at den der laver estimaterne har erfaring med opgaver af den type og tilstrækkelig teknisk indsigt til at kunne vurdere konsekvenserne af forskellige specifikke krav.
For at alle praktisk formål betyder det en software person.
En projekt leder behøver ikke at have forstand på programmering. En projekt leder behøver at have forstand på projektledelse.
Forstand på projektledelse inkluderer at spørge folk med den nødvendige viden, når der er behov for det.
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