<\/span><\/h3>\n\n\n\nSystemutvikling f\u00f8lger vanligvis en prosess der man g\u00e5r gjennom planleggings- og forslagstadiet, definerer utviklingskravene, og inng\u00e5r en kontrakt. Etter kontraktsinng\u00e5elsen f\u00f8lger man en rekke designfaser, implementerer i henhold til designet, og avslutter med testing. I hele denne prosessen har leverand\u00f8ren, som systemutviklingsekspert, omfattende forpliktelser, men brukeren har ogs\u00e5 en viss samarbeidsplikt. Brukerens samarbeid er spesielt viktig i faser som kravdefinisjon (\u00e5 identifisere n\u00f8dvendige funksjoner), grunnleggende design (utseende og brukeropplevelse), og testing eller akseptansetest (\u00e5 bekrefte at systemet oppfyller kravene). For en generell forklaring p\u00e5 brukerens forpliktelser i systemutvikling, se f\u00f8lgende artikkel.<\/p>\n\n\n\n\nhttps:\/\/monolith-law.jp\/corporate\/user-obligatory-cooporation\n<\/div><\/figure>\n\n\n\n
<\/span>Selv med samarbeidsplikt, krever brukere ofte endringer<\/span><\/h3>\n\n\n\nMen selv om brukeren ikke er en systemutviklingsekspert, kan man ikke alltid forvente at de alltid har en plan og gir leverand\u00f8ren all n\u00f8dvendig informasjon uten mangler. I virkeligheten, p\u00e5 grunn av den detaljerte og presise naturen av arbeidet, kan brukeren ofte ikke forutse hvilke fakta som vil v\u00e6re avgj\u00f8rende i senere faser. Ironisk nok kan viktige fakta derfor komme frem i sm\u00e5 porsjoner etter hvert. P\u00e5 grunn av disse omstendighetene, selv om det ideelle er en “gjennomg\u00e5ende prosess fra start til slutt”, er det viktig \u00e5 h\u00e5ndtere endringer som kan oppst\u00e5 i etterkant. Dette gj\u00f8r endringsstyring til en kritisk faktor i reelle prosjekter.<\/p>\n\n\n\n
<\/span>Hva er et endringsstyringsdokument?<\/span><\/h2>\n\n\n\nHvordan h\u00e5ndtere “endringsstyring” som oppst\u00e5r under systemutvikling?<\/figcaption><\/figure>\n\n\n\n<\/span>N\u00e5r endringsstyringsdokumenter brukes<\/span><\/h3>\n\n\n\nEt endringsstyringsdokument er et dokument som brukes n\u00e5r en bruker ber en leverand\u00f8r om \u00e5 endre spesifikasjoner eller legge til funksjoner fra det som opprinnelig ble forklart. Som nevnt tidligere, har brukeren en plikt til \u00e5 samarbeide med leverand\u00f8rens arbeid i faser som kravdefinisjon og grunnleggende design, men det kan faktisk oppst\u00e5 situasjoner hvor brukeren kommer med nye krav i senere faser.<\/p>\n\n\n\n
Eksempler p\u00e5 situasjoner hvor et endringsstyringsdokument kan v\u00e6re n\u00f8dvendig inkluderer:<\/p>\n\n\n\n
\nN\u00e5r det er mangler i kravdefinisjonen eller grunnleggende design, og brukeren ber om \u00e5 legge til funksjoner i etterkant<\/li>\n\n\n\n N\u00e5r det er behov for \u00e5 endre spesifikasjoner p\u00e5 grunn av en revisjon av forretningsstrategien under utviklingen<\/li>\n<\/ul>\n\n\n\nRelatert til temaet om \u00e5 legge til funksjoner eller endre spesifikasjoner, er det viktigste for den som utf\u00f8rer arbeidet \u00e5 vite om loven tillater endringer i estimatbel\u00f8pet. Dette punktet er forklart i detalj i en annen artikkel.<\/p>\n\n\n\n\nhttps:\/\/monolith-law.jp\/corporate\/increase-of-estimate\n<\/div><\/figure>\n\n\n\n
Ved \u00e5 \u00f8ke estimatet i etterkant, er endringsstyringsdokumentet grunnlaget for \u00e5 vurdere rimeligheten av det nye estimatet. For \u00e5 unng\u00e5 konflikter med motparten n\u00e5r man fakturerer basert p\u00e5 det \u00f8kte estimatet (og for \u00e5 styrke sin egen posisjon i tilfelle en konflikt), er det viktig \u00e5 utarbeide et endringsstyringsdokument.<\/p>\n\n\n\n
<\/span>Endringsstyringsdokumentets innhold<\/span><\/h3>\n\n\n\nHva b\u00f8r et endringsstyringsdokument inneholde i henhold til loven? Bruken av endringsstyringsdokumenter for \u00e5 h\u00e5ndtere spesifikasjonsendringer og funksjonsutvidelser er allerede allment kjent. Derfor kan man f\u00e5 en god forst\u00e5else av hvilke elementer som b\u00f8r dokumenteres ved \u00e5 se p\u00e5 malene for kontraktsvilk\u00e5r som er utarbeidet av japanske myndigheter, som for eksempel den japanske \u00f8konomi-, handels- og industrimodellen.<\/p>\n\n\n\n
\n\uff08Endringsstyringsprosess\uff09
<\/p>\n
<\/p>\n
Ved \u00e5 lese lovteksten direkte og bekrefte de anbefalte elementene, er ytterligere forklaring un\u00f8dvendig. For \u00e5 unng\u00e5 fremtidige tvister om hva som ble sagt eller ikke sagt, b\u00f8r endringshistorikken dokumenteres detaljert og spesifikt.<\/p>\n
<\/p>\n
<\/p>\n
Ved \u00e5 tydelig spesifisere disse elementene og inkludere signaturer eller stempler fra b\u00e5de leverand\u00f8rens og brukerens ansvarlige og godkjennende parter, vil dokumentet ha samme bevisverdi som en kontrakt i tilfelle en rettssak.<\/p>\n
<\/span>Hva du b\u00f8r vite om endringsstyring<\/span><\/h2>\n<\/p>\n
<\/p>\nEtter \u00e5 ha utarbeidet endringsstyringsdokumentet, reflekteres det ogs\u00e5 i oppgavelisten.<\/figcaption><\/figure>\n<\/p>\n
<\/p>\n
<\/span>Endringsstyring b\u00f8r vanligvis utf\u00f8res sammen med oppgavestyring<\/span><\/h3>\n<\/p>\n
<\/p>\n
\u00c5 utarbeide et endringsstyringsdokument har som form\u00e5l \u00e5 administrere endringshistorikken for \u00e5 lede prosjektet til suksess (eller for \u00e5 unng\u00e5 uberettiget ansvar hvis det ikke lykkes). For \u00e5 oppn\u00e5 dette form\u00e5let, utf\u00f8res utarbeidelsen av endringsstyringsdokumentet ofte sammen med opprettelse og oppdatering av oppgavelisten. Med andre ord, n\u00e5r endringshistorikken administreres i endringsstyringstabellen, blir de avtalte endringspunktene inkludert som elementer i oppgavelisten som fremtidige oppgaver.<\/p>\n
<\/p>\n
<\/p>\n
<\/span>Det er bedre \u00e5 ogs\u00e5 fastsette regler for endringsforhandlinger<\/span><\/h3>\n<\/p>\n
<\/p>\n
Det er ikke bare viktig \u00e5 fastsette metoder for endringsstyring, men ogs\u00e5 \u00e5 etablere regler for hvordan endringsforhandlinger skal gjennomf\u00f8res. Dette kan bidra til en smidig h\u00e5ndtering av endringer. Dette er spesielt viktig n\u00e5r man benytter utviklingsmetoder som Agile, hvor mange endringer forventes etter hvert. I praksis er det mange eksempler p\u00e5 at det er fastsatt regler for n\u00e5r motparten skal delta i forhandlinger om endringer.<\/p>\n
<\/p>\n
<\/p>\n
<\/span>Endringsforhandlinger og plikten til \u00e5 handle i god tro<\/span><\/h3>\n<\/p>\n
<\/p>\n
N\u00e5r begge parter har blitt enige om en kontrakt og deretter \u00f8nsker \u00e5 endre den, er det som \u00e5 inng\u00e5 en ny kontrakt. Siden kontrakter er basert p\u00e5 partenes frie vilje, er det i prinsippet ingen plikt for leverand\u00f8ren til \u00e5 g\u00e5 med p\u00e5 endringskontrakten. Men hvis denne retten blir for sterkt vektlagt, kan det skape bekymringer for at systemutviklingsprosjekter ikke vil g\u00e5 smidig.<\/p>\n
<\/p>\n
<\/p>\n
Derfor er det i praksis ofte spesifisert i kontrakter at det er en “plikt til \u00e5 handle i god tro i endringsforhandlinger”. Hvis leverand\u00f8ren ikke handler i god tro, kan det v\u00e6re mulig \u00e5 kreve erstatning. Et eksempel p\u00e5 en slik klausul kan v\u00e6re som f\u00f8lger (utdrag fra den offisielle “ff Basic\/Individual Contract Model Basic Contract Draft” utarbeidet av den japanske Information-technology Promotion Agency):<\/p>\n
<\/p>\n
<\/p>\n
\nArtikkel 4, paragraf 3: I endringsforhandlinger skal begge parter i god tro diskutere endringsobjektet, muligheten for endring, og p\u00e5virkningen p\u00e5 pris og leveringstid, og avgj\u00f8re om endringen skal gjennomf\u00f8res.<\/p>\n
<\/p><\/blockquote>\n
<\/p>\n
<\/p>\n
<\/span>Regler for endringsmetoder<\/span><\/h3>\n<\/p>\n
<\/p>\n
Som nevnt tidligere, er det juridisk “tryggere” \u00e5 holde forhandlinger om hver endring. Men i sm\u00e5 prosjekter kan det v\u00e6re tilfeller hvor man ikke spesifiserer hvordan forhandlinger skal gjennomf\u00f8res. I slike tilfeller kan man vurdere \u00e5 gj\u00f8re endringer gyldige ved \u00e5 f\u00e5 signaturer og stempler fra ansvarlige personer hos b\u00e5de brukeren og leverand\u00f8ren p\u00e5 endringsstyringsdokumentet, uten \u00e5 holde forhandlinger. Hvis man kun baserer seg p\u00e5 muntlige avtaler, kan det bli uklart om endringer er gjort, noe som kan f\u00f8re til store problemer senere. Derfor b\u00f8r dokumentstyring v\u00e6re grundig.<\/p>\n
<\/p>\n
<\/p>\n
Imidlertid kan det v\u00e6re tilfeller hvor det er for tungvint \u00e5 utarbeide separate dokumenter for hver endring, og man \u00f8nsker \u00e5 prioritere fleksibel h\u00e5ndtering. I slike tilfeller kan man dokumentere endringer i m\u00f8tereferater. For mer informasjon om hvordan man f\u00f8rer m\u00f8tereferater i systemutvikling, se f\u00f8lgende artikkel.<\/p>\n
<\/p>\n
<\/p>\n\n\nhttps:\/\/monolith-law.jp\/corporate\/the-minutes-in-system-development\n<\/div>\n<\/figure>\n
<\/p>\n
<\/span>Oppsummering<\/span><\/h2>\n<\/p>\n
<\/p>\n
P\u00e5 arbeidsplasser hvor spesifikasjoner ofte endres, er det sant at risikoen for problemer og konflikter kan v\u00e6re h\u00f8y. Men p\u00e5 slike steder hvor fleksibilitet er n\u00f8dvendig, kan det v\u00e6re vanskelig \u00e5 implementere praktiske tiltak hvis man bare strengt understreker “viktigheten av styring”.<\/p>\n
<\/p>\n
<\/p>\n
Problemet med hvordan man skal balansere forretningshastighet med beredskap for uforutsette hendelser varierer ofte avhengig av selskapets situasjon og prosjektets innhold. Selv om man tar hensyn til innholdet i denne artikkelen, er det viktig \u00e5 ha en holdning hvor man s\u00f8ker etter passende metoder for hvert selskap og prosjekt.<\/p>\n
<\/p>","protected":false},"excerpt":{"rendered":"
I systemutviklingsprosjekter skjer det ofte at brukerne endrer innholdet de tidligere har forklart etter hvert som arbeidet skrider frem. Derfor kan det som leverand\u00f8r ogs\u00e5 bli n\u00f8dvendig \u00e5 g\u00e5 med p\u00e5 e […]<\/p>\n","protected":false},"author":32,"featured_media":81983,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[16],"tags":[19,31],"acf":[],"_links":{"self":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/70952"}],"collection":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/comments?post=70952"}],"version-history":[{"count":2,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/70952\/revisions"}],"predecessor-version":[{"id":81985,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/posts\/70952\/revisions\/81985"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media\/81983"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/media?parent=70952"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/categories?post=70952"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/no\/wp-json\/wp\/v2\/tags?post=70952"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}