Redaksjonen. Skrevet 3. juli 2020 Del Skrevet 3. juli 2020 KOMMENTAR: Åtte fellesnevnere i et godt IT-prosjekt Lenke til kommentar
Kajac Skrevet 3. juli 2020 Del Skrevet 3. juli 2020 Min erfaring: Unngå konsulentselskaper. Egne ansatte er både billigere for bedriften og gir et mer stabilt team, som igjen gir et bedre produkt. Konsulenter bør kun brukes dersom det er akutt behov for arbeidskraft for en liten, avgrenset periode. 1 Lenke til kommentar
DJKU9PU3 Skrevet 3. juli 2020 Del Skrevet 3. juli 2020 Vel, hvis bedriften din kan sette av mange nok folk til et prosjekt som kommer i tillegg til vanlige arbeidsoppgaver, så har de vel egentlig for lite å gjøre til daglig. 2 1 Lenke til kommentar
_Nils_ Skrevet 3. juli 2020 Del Skrevet 3. juli 2020 @Kajac Unngå -store- konsulentselskaper Lenke til kommentar
Gjest Slettet+987123849734 Skrevet 4. juli 2020 Del Skrevet 4. juli 2020 Kajac: dette kan man da si om alle tjenesteleverandører da? Unngå elektrikere, ansett heller en selv. Unngå rørleggere ansett heller en selv osv. Utfordringen idag er at det er opprettet store kameraderier mellom det offentlige og private selskaper, sånn at det leies ut udugelig personer til det offentlige som beskrives som konsulenter. Når igjen det offentlige har skrevet helt elendige produkt spesifikasjoner som de skal, så blir resultatet at de elendige innleide blir tvunget til å lage en elendig løsning. Hadde staten utelukkende sett på pris i anbud, så kunne det vært mulig å få levert kvalitet, men når det er viktigere at du har ansatt utlandske kvinner til å gjøre jobben og du har flere års erfaring med offentlige anbud, så fjernes det interessen fra ganske så mange flinke. Lenke til kommentar
Bing123 Skrevet 5. juli 2020 Del Skrevet 5. juli 2020 (endret) On 7/3/2020 at 11:39 AM, Kajac said: Min erfaring: Unngå konsulentselskaper. Egne ansatte er både billigere for bedriften og gir et mer stabilt team, som igjen gir et bedre produkt. Konsulenter bør kun brukes dersom det er akutt behov for arbeidskraft for en liten, avgrenset periode. At det er "billigere" med egne ansatte er jo en gigantisk antagelse. Hvorfor skal noen være så greie å gjøre dette? Hvem hindrer de fra å si opp når som helst? Ikke bare skal de ifølge deg gjøre en bedre jobb, de skal også få mindre betalt og bli der over lang tid. Dette er mye mer nyansert enn som så. Endret 5. juli 2020 av atlemag 1 Lenke til kommentar
tjavel Skrevet 5. juli 2020 Del Skrevet 5. juli 2020 9 minutes ago, atlemag said: At det er "billigere" med egne ansatte er jo en gigantisk antagelse. Hvorfor skal noen være så greie å gjøre dette? Hvem hindrer de fra å si opp når som helst? Ikke bare skal de ifølge deg gjøre en bedre jobb, de skal også få mindre betalt og bli der over lang tid. Dette er mye mer nyansert enn som så. Inhouse utviklere er nå fortsatt ganske vanlig heldigvis. Mange utviklere vil foretrekke jobbe inhouse siden er en tryggere og mindre omflakkende tilværelse, noe slik som at noen vil foretrekke å jobbe i det offentlige fremfor det private. Det er slik i dag at inhouse utviklere per i dag stort sett gjør en bedre jobb siden de da over tid kjenner kunden og systemene bedre, tar mindre betalt og blir der over lengre tid fordi bytte jobb er slit og dårlig for CVen om en trives og er bra nok betalt. Tenker at om det er et prosjekt som skal vedlikeholdes over tid etter første utviklingsfasen så bør en ha en kjerne av faste utviklere som tar styringen, og så leier man inn konsulenter i utviklingsfasen når det er størst behov. Det som er meningsløst er å gi fra seg lederskap til et større konsulentfirma i et større prosjekt som krever vedlikehold over tid. Det er å gi de sugerør rett i statskassa eller hvem som enn er oppdragsgiver, så slik som NAV og skatteetaten har intern kompetanse så de unngår den fella. 1 Lenke til kommentar
Kajac Skrevet 5. juli 2020 Del Skrevet 5. juli 2020 atlemag skrev (2 timer siden): At det er "billigere" med egne ansatte er jo en gigantisk antagelse. Hvorfor skal noen være så greie å gjøre dette? Hvem hindrer de fra å si opp når som helst? Ikke bare skal de ifølge deg gjøre en bedre jobb, de skal også få mindre betalt og bli der over lang tid. Dette er mye mer nyansert enn som så. Konsulenter er dyrere. Det en bedrift betaler for konsulenten skal ikke bare dekke alle utgifter til lønn, pensjon og avgifter, men også en god del som fortjeneste til konsulentselskapet. Mellom en intern ansatt og en ekstern konsulent som har samme lønn, vil konsulenten være betraktelig dyrere for bedriften. Det er fakta, ikke en antagelse. Eller tror du konsulentselskapene jobber gratis? Å ha et fast team med faste ansatte er omtrent alltid bedre enn å outsource til konsulentselskap. Det finnes unntak, som f.eks. hvis en bedrift trenger en liten app eller et annet begrenset prosjekt, og ikke har kapasitet til å sette i stand et helt eget utviklingsteam. Men der IT-prosjektet er en del av bedriftens kjernevirksomhet, vil det aldri lønne seg å bruke konsulenter til å verken utvikle eller drifte dette. Konsulenter er pr. definisjon midlertidig arbeidskraft. Å bruke konsulenter i f.eks. et devops-team er helt meningsløst etter min mening. Lenke til kommentar
Bing123 Skrevet 5. juli 2020 Del Skrevet 5. juli 2020 (endret) 2 hours ago, Kajac said: Konsulenter er dyrere. Det en bedrift betaler for konsulenten skal ikke bare dekke alle utgifter til lønn, pensjon og avgifter, men også en god del som fortjeneste til konsulentselskapet. Mellom en intern ansatt og en ekstern konsulent som har samme lønn, vil konsulenten være betraktelig dyrere for bedriften. Det er fakta, ikke en antagelse. Eller tror du konsulentselskapene jobber gratis? Å ha et fast team med faste ansatte er omtrent alltid bedre enn å outsource til konsulentselskap. Det finnes unntak, som f.eks. hvis en bedrift trenger en liten app eller et annet begrenset prosjekt, og ikke har kapasitet til å sette i stand et helt eget utviklingsteam. Men der IT-prosjektet er en del av bedriftens kjernevirksomhet, vil det aldri lønne seg å bruke konsulenter til å verken utvikle eller drifte dette. Konsulenter er pr. definisjon midlertidig arbeidskraft. Å bruke konsulenter i f.eks. et devops-team er helt meningsløst etter min mening. Jo det er en antagelse Å forvente at noen skal jobbe der fast over lengre tid for mindre penger enn noen andre, feks konsulenter. Det høres iallfall meningsløst ut. En konsulent får tilsvarende en mill i året, vil du da gladelig komme der å tilby deg å gjøre samme jobb for 800 tusen? Er en grunn til at noen bedrifter overhode ikke får tak i faste ansatte, hvis dét er forventningen. Som var poenget mitt initielt. Det er ikke bare å ønsketenke seg fram til faste ansatte og bare høste godene sjøl. Du må tilby noe som arbeidsgiver. Endret 5. juli 2020 av atlemag 2 Lenke til kommentar
Kajac Skrevet 5. juli 2020 Del Skrevet 5. juli 2020 atlemag skrev (1 time siden): Jo det er en antagelse Å forvente at noen skal jobbe der fast over lengre tid for mindre penger enn noen andre, feks konsulenter. Det høres iallfall meningsløst ut. En konsulent får tilsvarende en mill i året, vil du da gladelig komme der å tilby deg å gjøre samme jobb for 800 tusen? Er en grunn til at noen bedrifter overhode ikke får tak i faste ansatte, hvis dét er forventningen. Som var poenget mitt initielt. Det er ikke bare å ønsketenke seg fram til faste ansatte og bare høste godene sjøl. Du må tilby noe som arbeidsgiver. De fleste konsulenter får ikke en million i året. Jeg jobber og har jobbet med mange konsulenter fra mange forskjellige konsulenthus. Ja, enkelte ligger oppunder en mill, noen også over, men i snitt ligger konsulenter rundt 17 % over fast ansatte, en pris jeg tror mange, meg selv inkludert, er villig til å betale for blant annet større forutsigbarhet og jobbsikkerhet og andre fordeler. Lenke til kommentar
tjavel Skrevet 5. juli 2020 Del Skrevet 5. juli 2020 (endret) Fra artikkelen Quote Ikke vær redd for å ta risiko underveis, det er ved å våge at grenser flyttes. Husk at bak alle feil finnes det mye viktig ny kunnskap. Viktig dette, "fail-fast" er et bra prinsipp der det er bedre å forsøke løse risiko-områdene først, opp til et visst nivå. Hun sier mye fornuftig, en overordnet plan er også bra men ikke så detaljert at en går seg vill i detaljplanlegging før en har begynt på noe praktisk. Det jeg ville anbefale er: - prototyp som kan utvides til full versjon der en får på plass grunnmuren i systemet, det vil si basis datamodell, tjenester og de store linjene i UI, seeing is believing. Dette får en kunden til å teste ut og få avklaring på at en "generelt er på rett vei" og ikke har misforstått oppdraget, eller at kunden selv ikke har skjønt egne prosesser sett i forhold til hvordan man kan digitalisere bedriften. Dette er arkitektur/design fasen der man ikke gjør noe streng prosjektmodell for å fullføre i henhold til kravspek og kravspek behøver ikke være komplett, man sonderer terrenget nettopp så man kan komplettere kravspek. Man fokuserer på risikoområder. - Så med mere komplett kravsspek så kan man gå gjennom alt på nytt og komplettere hver av funskjonalitetene. Dvs de delene man er sikre på at man trenger og hvordan skal være, de gjør man helt ferdig med automatiserte tester og full pakke mens de man ikke er sikre på kan man prototype videre på inntil man er mere sikker. Dette er mye som vanlig agil/devops men i Scrum så hoppet man raskt over punkt 1 og bare forsøkte med en gang å fylle backlog med oppgaver fra kravspec som så skal gjøres ferdig uten å se helheten. Og så kommer en til sprint demo og har lagd noe som det ikke var bruk for. Det blir nesten som gammeldags metodikk der det var en papirmølle før en forsøkte ut ideene i praksis. I stedet bør en å ha en friere prototype/proof of concept-fase der det er lov og tid til å gjøre feil og en refaktorerer til en har en solid grunnmur for hele systemet på plass. Endret 5. juli 2020 av tjavel Lenke til kommentar
Anders Jensen Skrevet 5. juli 2020 Del Skrevet 5. juli 2020 Hvis jeg skal utvikle en organisasjon ved å forbedre en prosess ved hjelp av et IT verktøy så ville jeg unngått prosjektmodellen og konsulenter så langt som overhodet mulig, men de punktene listet her er greit å ta med seg i oppstartsfasen. Det er imidlertid en smidig produktutvikling metodikk som er egnet her. Prosjekter har fundamentale utfordringer knyttet til diskontinuitet i kunnskap og lokal optimalisering av både scope og den første byggeperioden. Dessuten er dette som regel unike systemer som krever endring under hele livsløpet ikke bare i prosjektperioden, da må en tenke mer langsiktig og sørge for at insentivene hos deltakerne gjenspeiler dette. F.eks med «you build it, you run it» 1 Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå