Gramo må utsette desember-utbetalinga. Nytt IT-system ble ikke ferdig i tide

[Gjest Marius B. Jørgenrud]

Beklager at musikere og plateselskap ikke får penger før jul.

Gramo må utsette desember-utbetalinga. Nytt IT-system ble ikke ferdig i tide

[Kakeshoma]

– Alle er naturligvis skuffet over dette. Vi er kanskje mest skuffet av alle.

 

Ja, det er ofte de som utbetaler som er mest skuffet.. De som skal ha pengene er sikkert bare lei seg på vegne av Gramo, og spesielt adm dir, som ikke har klart å planlegge prosjektet godt nok. De tenker nok bare at utbetalingene kan vente, bare Gramo får de nye systemene sine i orden stakkar.

Endret 28. november 2017 av Kakeshoma

[Per Buer]

"Jobben skal ha blitt mer kompleks og tidkrevende enn leverandøren hadde sett for seg."

 

Det er vel også et relativt godt annerkjent faktum at en det hører til sjeldenhetene at en kunde faktisk greier å forstå og spesifisere sitt eget behov.

[Magnus Reintz]

All honnør til Administrerende Direktør, som anerkjenner at de selv har bomma, i stedet for å peke på utvikleren.

[1J7HHBGW]

"Jobben skal ha blitt mer kompleks og tidkrevende enn leverandøren hadde sett for seg."

 

Det er vel også et relativt godt annerkjent faktum at en det hører til sjeldenhetene at en kunde faktisk greier å forstå og spesifisere sitt eget behov.

 

Det der er et tveegget sverd Hr Buer,

 

Det er slett ikke uvanlig at leverandørene tyner anbudet for å få leveransen, og det er slett ikke uvanlig at leverandøren og konsulentene ikke forstår kundens behov.

 

Vi måtte skrape en leveranse og starte på nytt med blanke ark og ny anbudsrunde for et tungt forretningssystem med en hel del skreddersøm. Erfaringene fra prosessen rundt den kasserte løsningen endret vår tilnærming til anbudsprosessen og både spec og avtale for den nye leverandøren var klokkeklar.

 

Vi var imidlertid ikke 100% overbevist om at leverandøren ville prestere og levere. De var best, men var det godt nok? Så vi limte den internasjonale "teknologieieren" til leverandøren, og denne gikk på en kjempesmell.

[BjartmarO]

"Jobben skal ha blitt mer kompleks og tidkrevende enn leverandøren hadde sett for seg."

 

Det er vel også et relativt godt annerkjent faktum at en det hører til sjeldenhetene at en kunde faktisk greier å forstå og spesifisere sitt eget behov.

Jeg vet at det ofte vinkles sånn...

 

"Kunden forstod ikke sitt eget behov, derfor sitter vi i saksen."

 

Jeg mener at dette som regel er bullshit.

 

Det riktige er som regel at utvikleren ikke har forstått behovet godt nok, og/eller at utvikleren ikke har evnet å kommunisere sin egen (mangelfulle) forståelse av problemet godt nok til kunden før oppstart av prosjektet.

 

Det er ikke bare kunden sitt ansvar å fortelle utvikleren hva det er han vil ha. Det er like mye utvikleren sitt ansvar å spørre og grave, og å sørge for å skaffe seg tilstrekkelig informasjon til å kunne utforme en god løsning for kunden.

 

Kunden vet ikke hva han kan få. Han kjenner ikke det tekniske mulighetsrommet. Dermed vet han heller oftest ikke eksakt hvilken informasjon som kan være relevant i forkant av prosjektet. Det er dermed utvikleren sitt ansvar, som ekspert, å drive denne prosessen, og å sørge for at all relevant informasjon kommer på bordet.

 

Etter min mening er det en slags form for unnskyldning eller ansvarsfraskrivelse når utvikleren i etterkant av et prosjekt kommer dragende med at "kunden ikke skjønte sitt eget behov godt nok".

Endret 28. november 2017 av BjartmarO

[1J7HHBGW]

 

"Jobben skal ha blitt mer kompleks og tidkrevende enn leverandøren hadde sett for seg."

 

Det er vel også et relativt godt annerkjent faktum at en det hører til sjeldenhetene at en kunde faktisk greier å forstå og spesifisere sitt eget behov.

Jeg vet at det ofte vinkles sånn...

 

"Kunden forstod ikke sitt eget behov, derfor sitter vi i saksen."

 

Jeg mener at dette som regel er bullshit.

 

Det riktige er som regel at utvikleren ikke har forstått behovet godt nok, og/eller at utvikleren ikke har evnet å kommunisere sin egen (mangelfulle) forståelse av problemet godt nok til kunden før oppstart av prosjektet.

 

Det er ikke bare kunden sitt ansvar å fortelle utvikleren hva det er han vil ha. Det er like mye utvikleren sitt ansvar å spørre og grave, og å sørge for å skaffe seg tilstrekkelig informasjon til å kunne utforme en god løsning for kunden.

 

Kunden vet ikke hva han kan få. Han kjenner ikke det tekniske mulighetsrommet. Dermed vet han heller oftest ikke eksakt hvilken informasjon som kan være relevant i forkant av prosjektet. Det er dermed utvikleren sitt ansvar, som ekspert, å drive denne prosessen, og å sørge for at all relevant informasjon kommer på bordet.

 

Etter min mening er det en slags form for unnskyldning eller ansvarsfraskrivelse når utvikleren i etterkant av et prosjekt kommer dragende med at "kunden ikke skjønte sitt eget behov godt nok".

Det viktigste for at et prosjekt skal bli vellykket er at man har en "gobetween" som virkelig KAN teknologien og virkelig FORSTÅR bedriften. Disse personene vokser ikke på trær, men om man er så heldig har man har denne personen involvert så er det helt uvurderlig. Har hatt privilegiet å oppleve dette fungere, og det er nesten som en drøm. Etter mitt syn er det denne kompetansen som det er størst mangel på i Norge.

[Per Buer]

 

"Jobben skal ha blitt mer kompleks og tidkrevende enn leverandøren hadde sett for seg."

 

Det er vel også et relativt godt annerkjent faktum at en det hører til sjeldenhetene at en kunde faktisk greier å forstå og spesifisere sitt eget behov.

Etter min mening er det en slags form for unnskyldning eller ansvarsfraskrivelse når utvikleren i etterkant av et prosjekt kommer dragende med at "kunden ikke skjønte sitt eget behov godt nok".

 

Dette er ikke noe gyldig grunn til ansvarsfraskrivelse. Leverandører skal vite dette og de må forholde seg til det. Men det er med på å forklare hva som kan ha skjedd.

 

Så skal jeg være den første til å innrømme at jeg ikke forstår og kan spesifisere mine egne behov. Jeg forsøker dog å ta hensyn til disse begrensningene.

[tommyb]

Det riktige er som regel at utvikleren ikke har forstått behovet godt nok, og/eller at utvikleren ikke har evnet å kommunisere sin egen (mangelfulle) forståelse av problemet godt nok til kunden før oppstart av prosjektet.

 

Det er ikke bare kunden sitt ansvar å fortelle utvikleren hva det er han vil ha. Det er like mye utvikleren sitt ansvar å spørre og grave, og å sørge for å skaffe seg tilstrekkelig informasjon til å kunne utforme en god løsning for kunden.

 

Kunden vet ikke hva han kan få. Han kjenner ikke det tekniske mulighetsrommet. Dermed vet han heller oftest ikke eksakt hvilken informasjon som kan være relevant i forkant av prosjektet. Det er dermed utvikleren sitt ansvar, som ekspert, å drive denne prosessen, og å sørge for at all relevant informasjon kommer på bordet.

 

Vel, noen ganger treffer man og noen ganger bommer man, men det er definitivt forskjell på kunder. Noen kunder kommer med en klar og tydelig spec på hvordan de vil at sitt excel-ark skal konverteres til html. Hvis man da antyder at det finnes andre måter å gjøre det på, vil noen være interessert og andre ikke. Og det er ikke å stikke unna en stol at noen ganger er excel-på-nett mye billigere å utvikle enn det de egentlig burde hatt.

[1J7HHBGW]

Åkkesom:

Det blir nok ekstra mange julemusikantturneer i år - det er bare å stålsette seg...

[BjartmarO]

 

 

"Jobben skal ha blitt mer kompleks og tidkrevende enn leverandøren hadde sett for seg."

 

Det er vel også et relativt godt annerkjent faktum at en det hører til sjeldenhetene at en kunde faktisk greier å forstå og spesifisere sitt eget behov.

Jeg vet at det ofte vinkles sånn...

 

"Kunden forstod ikke sitt eget behov, derfor sitter vi i saksen."

 

Jeg mener at dette som regel er bullshit.

 

Det riktige er som regel at utvikleren ikke har forstått behovet godt nok, og/eller at utvikleren ikke har evnet å kommunisere sin egen (mangelfulle) forståelse av problemet godt nok til kunden før oppstart av prosjektet.

 

Det er ikke bare kunden sitt ansvar å fortelle utvikleren hva det er han vil ha. Det er like mye utvikleren sitt ansvar å spørre og grave, og å sørge for å skaffe seg tilstrekkelig informasjon til å kunne utforme en god løsning for kunden.

 

Kunden vet ikke hva han kan få. Han kjenner ikke det tekniske mulighetsrommet. Dermed vet han heller oftest ikke eksakt hvilken informasjon som kan være relevant i forkant av prosjektet. Det er dermed utvikleren sitt ansvar, som ekspert, å drive denne prosessen, og å sørge for at all relevant informasjon kommer på bordet.

 

Etter min mening er det en slags form for unnskyldning eller ansvarsfraskrivelse når utvikleren i etterkant av et prosjekt kommer dragende med at "kunden ikke skjønte sitt eget behov godt nok".

Det viktigste for at et prosjekt skal bli vellykket er at man har en "gobetween" som virkelig KAN teknologien og virkelig FORSTÅR bedriften. Disse personene vokser ikke på trær, men om man er så heldig har man har denne personen involvert så er det helt uvurderlig. Har hatt privilegiet å oppleve dette fungere, og det er nesten som en drøm. Etter mitt syn er det denne kompetansen som det er størst mangel på i Norge.

 

Helt enig...

 

Jeg ser denne oppgaven som en integrert del av oppgaven til utviklingsteamet. Utviklingsteamet må sørge for å ha med seg minst en person som evner å kommunisere med kunden, og som evner å sette seg DYPT inn i hvordan kunden tenker seg å bruke systemet etter at det står ferdig.

 

Like viktig, evnene til å forklare den foreslåtte løsningen til kunden før man setter i gang med å implementere den, slik at man er sikker på at den endelige løsningen ikke kommer som en overraskelse på kunden. Eller i alle fall at man greier å minimere mengden av ting som kunden ikke er forberedt på.

 

Også, at man evner å holde kommunikasjonen i gang underveis i prosjektet, så man kan samle ny og forbedret informasjon om de delene av løsningen som krever en slags iterativ tilnærming.

 

Det viktige i denne rollen er at den besettes av folk som faktisk skjønner begge sider, som du sier. Altså, som både skjønner teknologien (og skjønner den GODT), og som har evnen til å sette seg inn i komplekse bruksmønster og behov hos kunden, og å forstå disse fullt ut. Det er "tverrsynet" som er det verdifulle her. Evnen til både å se hva som trengs, og å se hva som er teknisk mulig.

 

En del (spesielt offentlige) organisasjoner skjønner dette bare sånn delvis. De skjønner at de må ha en mellommann. Men de setter gjerne inn byråkrater som hverken skjønner teknologien, eller har evnen til å analysere og forstå bruksmønstrene hos kunden. Det er ikke selve det å ha en mellommann som er det verdifulle. Men det å ha en mellommann som evner å se på tvers. Disse rene byråkratiske mellommennene ender ofte opp med å bare gjøre vondt verre, etter min mening, fordi man da har personer som egentlig er MENT å skulle forvalte denne oppgaven, men som ikke er i stand til å gjøre det, rent kompetansemessig. Da faller ting ofte mellom to stoler, er min erfaring... Ingen blir sittende med ansvaret. Og man ender opp i situasjoner hvor man skylder på hverandre, og hvor man sier at "kunden ikke forstod sitt eget behov".

Endret 28. november 2017 av BjartmarO

[Bjørn Remseth]

Etter min mening er det en slags form for unnskyldning eller ansvarsfraskrivelse når utvikleren i etterkant av et prosjekt kommer dragende med at "kunden ikke skjønte sitt eget behov godt nok".

 

Hmmm. Har du utviklet mange systemer i dialog med kunder? Jeg kan forsikre deg om at normaltilstanden er at kunden ikke vet hva de vil ha.

 

De kan gjerne tro de vet det, men det er nesten alltid feil. Om ikke annet vet de ikke hva teknologien som blir brukt for å levere kan levere, slik at når de ser hva utviklernes tolkningen av deres ønsker er, så viser det seg at de er uenige med utviklernes tolkning. Dette er helt normalt. Moderne utviklingsmetodologi tar høyde for dette og itererer ofte med feedback fra kunden for å sikre at man er på riktig spor. Selv da kan det gå galt siden det ikke er alltid man faktisk får feedback fra sluttbrukere men med en eller annen "tastemaker" som på vegne av kunden mener å kunne foreta valg på vegne av sluttbrukerne. Hvis tastmakers vurdering på noe tidspunkt er forskjellig fra det sluttbrukerne faktisk er komfortable med, da blir det også galt.

 

Utvikling av komplekse systemer er mer en øvelse i kommunikasjon mellom folk som ikke snakker så godt sammen enn programmering.

[1J7HHBGW]

 

Etter min mening er det en slags form for unnskyldning eller ansvarsfraskrivelse når utvikleren i etterkant av et prosjekt kommer dragende med at "kunden ikke skjønte sitt eget behov godt nok".

 

Hmmm. Har du utviklet mange systemer i dialog med kunder? Jeg kan forsikre deg om at normaltilstanden er at kunden ikke vet hva de vil ha.

 

De kan gjerne tro de vet det, men det er nesten alltid feil. Om ikke annet vet de ikke hva teknologien som blir brukt for å levere kan levere, slik at når de ser hva utviklernes tolkningen av deres ønsker er, så viser det seg at de er uenige med utviklernes tolkning. Dette er helt normalt. Moderne utviklingsmetodologi tar høyde for dette og itererer ofte med feedback fra kunden for å sikre at man er på riktig spor. Selv da kan det gå galt siden det ikke er alltid man faktisk får feedback fra sluttbrukere men med en eller annen "tastemaker" som på vegne av kunden mener å kunne foreta valg på vegne av sluttbrukerne. Hvis tastmakers vurdering på noe tidspunkt er forskjellig fra det sluttbrukerne faktisk er komfortable med, da blir det også galt.

 

Utvikling av komplekse systemer er mer en øvelse i kommunikasjon mellom folk som ikke snakker så godt sammen enn programmering.

Har vært nødt til å plage meg selv gjennom mange runder med sluttbrukere, og det er ofte ikke særlig givende fordi banaliteter ofte blir monstre. Forståelsen kan være skremmende lav og du har helt rett både når det gjelder "tastemaster" og (typisk) finansdirektøren som eier av prosjektet internt.

 

En av de store salderingspostene når tidsrammene og budsjettet begynner å bli trangt er brukergrensesnittene som sluttbrukerne skal jobbe i, og når det blir skviset der vil gjerne produktiviteten og ROI bli redusert - enkelte ganger dramatisk svekket.

 

Så i tillegg til en ytterst kompetent prosjektleder/"mellommann" er det kjempeviktig å ha svært dyktige folk innen design av brukergrensesnitt.

[BjartmarO]

Har du utviklet mange systemer i dialog med kunder? Jeg kan forsikre deg om at normaltilstanden er at kunden ikke vet hva de vil ha. De kan gjerne tro de vet det, men det er nesten alltid feil.

 

Ja, og tilsvarende, så er normaltilstanden at utviklerne ikke vet hva kunden vil ha. De kan tro at de vet det, men det er nesten alltid feil.

 

Du kan si at kunden ikke skjønner teknologien, og at de dermed ikke vet på forhånd hva de vil ha. Jeg har ikke noe problem med akkurat det utsagnet.

 

Men, du må huske på at det oftest går andre veien også. Sett en ren programmerer og fagnerd til å designe en praktisk løsning på et forretningsmessig problem, og du får ofte en håpløst knotete greie... Utviklerne forstår ofte teknikken, men ikke det praktiske. Og kunden forstår det praktiske, men ikke teknikken.

 

Det er denne kløften som er problemet...

 

Man avhjelper litt med en slags iterativ tilnærming. Da unngår man f.eks. at utviklerne blir sittende måneder, kvartaler og halvår jobbende i en retning som kunden ikke er enig i.

 

Men, det man egentlig trenger i disse situasjonene er utviklere med kunde- og forretningsforståelse. Altså personer som kan utviklingsfaget og teknologien til fingerspissene (med andre ord som er eller har vært utviklere selv), og som samtidig evner å se utfordringene fra den andre siden av bordet. Utviklere som evner å se problemet fra kundens side, og å skjønne måten hans å tenke på.

 

Som 1J7HHBGW sier er denne typen fagpersoner litt å betrakte som enhjørninger. Men, om man får fatt i de, så er det mye mer effektivt enn å iterere mange runder med parter som egentlig ikke forstår hverandre. For å "se" de gode løsningene tidlig må man ha personer som klarer å ha dyp forståelse både av teknologien og av kunden sine behov. Først da ser man de egentlige mulighetene som ligger i prosjektet. Man må ha noen som klarer å "se på tvers", på en måte.