{"id":60380,"date":"2024-03-05T21:11:37","date_gmt":"2024-03-05T12:11:37","guid":{"rendered":"https:\/\/monolith.law\/da\/?p=60380"},"modified":"2024-03-17T20:44:49","modified_gmt":"2024-03-17T11:44:49","slug":"howto-manage-change-in-system-development","status":"publish","type":"post","link":"https:\/\/monolith.law\/da\/it\/howto-manage-change-in-system-development","title":{"rendered":"Hvordan man h\u00e5ndterer \u00e6ndringsstyring i systemudvikling fra et juridisk perspektiv"},"content":{"rendered":"\n<p>I systemudviklingsprojekter sker det ofte, at brugeren \u00e6ndrer det indhold, de har forklaret p\u00e5 forh\u00e5nd, i l\u00f8bet af arbejdsprocessen. Derfor kan det som leverand\u00f8r, der modtager arbejdet, v\u00e6re n\u00f8dvendigt at im\u00f8dekomme \u00e6ndringer i kontraktindholdet, selv efter at kontrakten er indg\u00e5et.<\/p>\n\n\n\n<p>I denne artikel forklarer vi, fra et juridisk perspektiv, hvordan man skal h\u00e5ndtere f\u00e6nomenet &#8220;\u00e6ndringer&#8221;, der foretages efterf\u00f8lgende, i forhold til systemudviklingsprojekter, der ikke altid forl\u00f8ber som forventet.<\/p>\n\n\n\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_53 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<span class=\"ez-toc-title-toggle\"><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/monolith.law\/da\/it\/howto-manage-change-in-system-development\/#Hvorfor_bliver_systemudviklingsprojekter_%E2%80%98aendret%E2%80%99_efterfolgende\" title=\"Hvorfor bliver systemudviklingsprojekter &#8216;\u00e6ndret&#8217; efterf\u00f8lgende?\">Hvorfor bliver systemudviklingsprojekter &#8216;\u00e6ndret&#8217; efterf\u00f8lgende?<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/monolith.law\/da\/it\/howto-manage-change-in-system-development\/#Systemudvikling_er_et_samarbejde_mellem_leverandor_og_bruger\" title=\"Systemudvikling er et samarbejde mellem leverand\u00f8r og bruger\">Systemudvikling er et samarbejde mellem leverand\u00f8r og bruger<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/monolith.law\/da\/it\/howto-manage-change-in-system-development\/#Brugere_har_en_forpligtelse_til_at_samarbejde_men_de_har_en_tendens_til_at_anmode_om_aendringer\" title=\"Brugere har en forpligtelse til at samarbejde, men de har en tendens til at anmode om \u00e6ndringer\">Brugere har en forpligtelse til at samarbejde, men de har en tendens til at anmode om \u00e6ndringer<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/monolith.law\/da\/it\/howto-manage-change-in-system-development\/#Hvad_er_en_aendringsstyringsdokument\" title=\"Hvad er en \u00e6ndringsstyringsdokument?\">Hvad er en \u00e6ndringsstyringsdokument?<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/monolith.law\/da\/it\/howto-manage-change-in-system-development\/#Hvornar_bruges_aendringsstyringsdokumenter\" title=\"Hvorn\u00e5r bruges \u00e6ndringsstyringsdokumenter?\">Hvorn\u00e5r bruges \u00e6ndringsstyringsdokumenter?<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/monolith.law\/da\/it\/howto-manage-change-in-system-development\/#Hvad_skal_inkluderes_i_et_aendringsstyringsdokument\" title=\"Hvad skal inkluderes i et \u00e6ndringsstyringsdokument?\">Hvad skal inkluderes i et \u00e6ndringsstyringsdokument?<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/monolith.law\/da\/it\/howto-manage-change-in-system-development\/#Det_er_godt_at_vide_om_aendringsstyring\" title=\"Det er godt at vide om \u00e6ndringsstyring\">Det er godt at vide om \u00e6ndringsstyring<\/a><ul class='ez-toc-list-level-3'><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/monolith.law\/da\/it\/howto-manage-change-in-system-development\/#AEndringsstyring_bor_generelt_udfores_sammen_med_opgaveadministration\" title=\"\u00c6ndringsstyring b\u00f8r generelt udf\u00f8res sammen med opgaveadministration\">\u00c6ndringsstyring b\u00f8r generelt udf\u00f8res sammen med opgaveadministration<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/monolith.law\/da\/it\/howto-manage-change-in-system-development\/#Det_er_bedre_ogsa_at_fastsaette_regler_for_hvordan_aendringsforhandlinger_skal_udfores\" title=\"Det er bedre ogs\u00e5 at fasts\u00e6tte regler for, hvordan \u00e6ndringsforhandlinger skal udf\u00f8res\">Det er bedre ogs\u00e5 at fasts\u00e6tte regler for, hvordan \u00e6ndringsforhandlinger skal udf\u00f8res<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/monolith.law\/da\/it\/howto-manage-change-in-system-development\/#AEndringsforhandlinger_og_pligten_til_at_handle_i_god_tro\" title=\"\u00c6ndringsforhandlinger og pligten til at handle i god tro\">\u00c6ndringsforhandlinger og pligten til at handle i god tro<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/monolith.law\/da\/it\/howto-manage-change-in-system-development\/#Bestemmelser_om_aendringsmetoden\" title=\"Bestemmelser om \u00e6ndringsmetoden\">Bestemmelser om \u00e6ndringsmetoden<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/monolith.law\/da\/it\/howto-manage-change-in-system-development\/#Opsummering\" title=\"Opsummering\">Opsummering<\/a><\/li><\/ul><\/nav><\/div>\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hvorfor_bliver_systemudviklingsprojekter_%E2%80%98aendret%E2%80%99_efterfolgende\"><\/span>Hvorfor bliver systemudviklingsprojekter &#8216;\u00e6ndret&#8217; efterf\u00f8lgende?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Systemudvikling_er_et_samarbejde_mellem_leverandor_og_bruger\"><\/span>Systemudvikling er et samarbejde mellem leverand\u00f8r og bruger<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Generelt g\u00e5r systemudvikling gennem en planl\u00e6gnings- og forslagsfase, hvor udviklingskravene defineres, og en kontrakt indg\u00e5s. Efter kontrakten er indg\u00e5et, f\u00f8lger en proces med forskellige designfaser, implementering i henhold til designet, og til sidst testning. I hele denne proces har leverand\u00f8ren, som er ekspert i systemudvikling, naturligvis en bred vifte af forpligtelser, men brugeren har ogs\u00e5 en vis forpligtelse til at samarbejde. I processer som identifikation af de funktioner, systemet skal have (dvs. kravdefinition), udseendet og brugeroplevelsen af sk\u00e6rmen (dvs. grundl\u00e6ggende design), og bekr\u00e6ftelse af, om kravene er opfyldt (dvs. test eller accept), er brugerens samarbejde s\u00e6rligt vigtigt. For en generel forklaring p\u00e5 de forpligtelser, brugeren har i systemudvikling, se f\u00f8lgende artikel.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/user-obligatory-cooporation\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/user-obligatory-cooporation[ja]<\/a><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Brugere_har_en_forpligtelse_til_at_samarbejde_men_de_har_en_tendens_til_at_anmode_om_aendringer\"><\/span>Brugere har en forpligtelse til at samarbejde, men de har en tendens til at anmode om \u00e6ndringer<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Men det er ikke altid, at brugere, der ikke er eksperter i systemudvikling, kan formidle alle de n\u00f8dvendige oplysninger til leverand\u00f8ren p\u00e5 en omfattende og fuldst\u00e6ndig m\u00e5de. I virkeligheden er det ofte sv\u00e6rt for brugerne at forudsige, hvilke fakta der kan have afg\u00f8rende betydning i senere faser, netop fordi det er en detaljeret og pr\u00e6cis opgave. Ironisk nok kan det betyde, at de vigtigste fakta ofte kommer frem i sm\u00e5 bidder senere. P\u00e5 grund af disse omst\u00e6ndigheder er det i virkelige projekter vigtigt at overveje, hvordan man h\u00e5ndterer &#8216;\u00e6ndringsstyring&#8217;, selvom det ideelle ville v\u00e6re en &#8216;gennemg\u00e5ende proces fra opstr\u00f8ms til nedstr\u00f8ms faser&#8217;, under antagelse af, at forskellige \u00e6ndringer kan forekomme efterf\u00f8lgende.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hvad_er_en_aendringsstyringsdokument\"><\/span>Hvad er en \u00e6ndringsstyringsdokument?<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith.law\/wp-content\/uploads\/2019\/07\/pixta_40395256_M-1024x682.jpg\" alt=\"\" class=\"wp-image-2910\" \/><figcaption class=\"wp-element-caption\">Hvordan h\u00e5ndteres &#8220;\u00e6ndringsstyring&#8221; under systemudvikling?<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hvornar_bruges_aendringsstyringsdokumenter\"><\/span>Hvorn\u00e5r bruges \u00e6ndringsstyringsdokumenter?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Et \u00e6ndringsstyringsdokument er et dokument, der bruges, n\u00e5r en bruger anmoder en leverand\u00f8r om at \u00e6ndre specifikationer eller tilf\u00f8je funktioner, der afviger fra det, der oprindeligt blev forklaret. Som n\u00e6vnt tidligere, har brugeren en forpligtelse til at samarbejde med leverand\u00f8rens arbejde i faser som kravdefinition og grundl\u00e6ggende design, men det er muligt, at forskellige \u00f8nsker kan opst\u00e5 i senere faser.<\/p>\n\n\n\n<p>Eksempler p\u00e5 situationer, hvor et \u00e6ndringsstyringsdokument kan v\u00e6re n\u00f8dvendigt, inkluderer:<\/p>\n\n\n\n<ul>\n<li>N\u00e5r der er overset noget i kravdefinitionen eller det grundl\u00e6ggende design, og der anmodes om at tilf\u00f8je en funktion efterf\u00f8lgende.<\/li>\n\n\n\n<li>N\u00e5r der er behov for specifikations\u00e6ndringer p\u00e5 grund af en revision af virksomhedens politik midt i udviklingen.<\/li>\n<\/ul>\n\n\n\n<p>Disse er blot nogle eksempler.<\/p>\n\n\n\n<p>Med hensyn til emner som tilf\u00f8jelse af funktioner og \u00e6ndring af specifikationer, er det, der mest bekymrer dem, der modtager arbejdet, om det er juridisk tilladt at \u00e6ndre det estimerede bel\u00f8b. Vi har en separat artikel, der forklarer dette i detaljer.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/increase-of-estimate\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/increase-of-estimate[ja]<\/a><\/p>\n\n\n\n<p>\u00c6ndringsstyringsdokumentet er grundlaget for at vurdere rimeligheden af indholdet, n\u00e5r du \u00f8ger estimatet efterf\u00f8lgende. For at undg\u00e5 konflikter med den anden part, n\u00e5r du fakturerer baseret p\u00e5 det \u00f8gede estimat (og for at give din argumentation overbevisende kraft, hvis der opst\u00e5r en konflikt), er det vigtigt at oprette et \u00e6ndringsstyringsdokument.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Hvad_skal_inkluderes_i_et_aendringsstyringsdokument\"><\/span>Hvad skal inkluderes i et \u00e6ndringsstyringsdokument?<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>S\u00e5 hvad skal juridisk set inkluderes i et \u00e6ndringsstyringsdokument? Kontraktsmekanismen, der bruger \u00e6ndringsstyringsdokumenter til at im\u00f8dekomme \u00e6ndringer i specifikationer og tilf\u00f8jelse af funktioner, er allerede almindeligt anerkendt. Derfor kan du generelt forst\u00e5, hvad der skal registreres ved at kontrollere skabeloner for kontraktbestemmelser, som regeringsagenturer som det japanske ministerium for \u00f8konomi, handel og industri viser.<\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>(\u00c6ndringsstyringsprocedure)<br>Artikel 37 Hvis A eller B modtager et \u00e6ndringsforslag baseret p\u00e5 artikel 34 (\u00e6ndring af systemspecifikationsdokumenter osv.), artikel 35 (godkendelse af midlertidige dokumenter af brugeren), artikel 36 (h\u00e5ndtering af ubestemte sager), skal de inden for \u25cb dage fra modtagelsesdatoen give den anden part et skriftligt dokument (<u class=\"remove-format\">herefter kaldet &#8220;\u00e6ndringsstyringsdokument&#8221;<\/u>.) med <u class=\"remove-format\">f\u00f8lgende oplysninger<\/u> noteret, og A og B skal diskutere godkendelsen af den p\u00e5g\u00e6ldende \u00e6ndring i kommunikationsr\u00e5det defineret i artikel 12.<br> \u2460 <u class=\"remove-format\">Navnet p\u00e5 \u00e6ndringen<\/u><br> \u2461 <u class=\"remove-format\">Den person, der er ansvarlig for forslaget<\/u><br> \u2462 <u class=\"remove-format\">Dato<\/u><br> \u2463 <u class=\"remove-format\">Grunden til \u00e6ndringen<\/u><br> \u2464 <u class=\"remove-format\">Detaljer om \u00e6ndringen, inklusive specifikationer relateret til \u00e6ndringen<\/u><br> \u2465 <u class=\"remove-format\">Hvis der er omkostninger forbundet med \u00e6ndringen, bel\u00f8bet<\/u><br> \u2466 <u class=\"remove-format\">Tidsplanen for \u00e6ndringsarbejdet, inklusive overvejelsesperioden<\/u><br> \u2467 <u class=\"remove-format\">Andre effekter, som \u00e6ndringen har p\u00e5 vilk\u00e5rene for denne kontrakt og individuelle kontrakter (arbejdsperiode eller leveringsdato, kontraktgebyr, kontraktbestemmelser osv.)<\/u><\/p>\n<\/blockquote>\n\n\n\n<p>Hvis du l\u00e6ser teksten direkte og bekr\u00e6fter de anbefalede poster, er yderligere forklaring un\u00f8dvendig. For at undg\u00e5 &#8220;sagde-ikke-sagde&#8221; problemer senere, skal du registrere detaljerne og den specifikke proces for \u00e6ndringen.<\/p>\n\n\n\n<p>Ved at angive disse oplysninger og kombinere dem med underskrifter eller segl fra ansvarlige og beslutningstagere fra b\u00e5de leverand\u00f8ren og brugeren, vil det have samme betydning som en kontrakt som bevis, selvom der skulle opst\u00e5 en retssag.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Det_er_godt_at_vide_om_aendringsstyring\"><\/span>Det er godt at vide om \u00e6ndringsstyring<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<figure class=\"wp-block-image\"><img decoding=\"async\" src=\"https:\/\/monolith.law\/wp-content\/uploads\/2019\/07\/pixta_54572310_M-1024x434.jpg\" alt=\"\" class=\"wp-image-2907\" \/><figcaption class=\"wp-element-caption\">N\u00e5r du har oprettet en \u00e6ndringsstyringsdokument, skal du ogs\u00e5 reflektere det i opgaveadministrationslisten.<\/figcaption><\/figure>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"AEndringsstyring_bor_generelt_udfores_sammen_med_opgaveadministration\"><\/span>\u00c6ndringsstyring b\u00f8r generelt udf\u00f8res sammen med opgaveadministration<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Form\u00e5let med at oprette en \u00e6ndringsstyringsdokument er at styre \u00e6ndringshistorikken for at lede projektet til fuldf\u00f8relse (eller for at undg\u00e5 uretf\u00e6rdig ansvarsp\u00e5dragelse, hvis det ikke lykkes). I praksis er oprettelsen af en \u00e6ndringsstyringsdokument ofte udf\u00f8rt sammen med oprettelse og opdatering af opgaveadministrationslisten. Det vil sige, n\u00e5r \u00e6ndringshistorikken er styret i \u00e6ndringsstyringstabellen, bliver de aftalte \u00e6ndringspunkter indarbejdet i opgaveadministrationslisten som opgaver, der skal h\u00e5ndteres fremover.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Det_er_bedre_ogsa_at_fastsaette_regler_for_hvordan_aendringsforhandlinger_skal_udfores\"><\/span>Det er bedre ogs\u00e5 at fasts\u00e6tte regler for, hvordan \u00e6ndringsforhandlinger skal udf\u00f8res<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Ikke kun hvordan man h\u00e5ndterer \u00e6ndringsstyring, men ogs\u00e5 hvordan man forhandler om \u00e6ndringer, kan det forventes, at \u00e6ndringsh\u00e5ndteringen vil g\u00e5 glat, hvis man ogs\u00e5 fasts\u00e6tter regler for det. Dette er is\u00e6r vigtigt, n\u00e5r man anvender udviklingsmetoder som agile udvikling, hvor forskellige \u00e6ndringer forventes at blive foretaget efterf\u00f8lgende. I praksis er der mange eksempler p\u00e5, at regler er fastsat for, hvorn\u00e5r den anden part skal reagere p\u00e5 en anmodning om forhandling om \u00e6ndringsstyring.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"AEndringsforhandlinger_og_pligten_til_at_handle_i_god_tro\"><\/span>\u00c6ndringsforhandlinger og pligten til at handle i god tro<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>N\u00e5r begge parter \u00e6ndrer en kontrakt, de engang har indg\u00e5et, er det i princippet det samme som at indg\u00e5 en ny kontrakt. Da kontrakten er baseret p\u00e5 parternes fri vilje, er der i princippet ingen pligt for leverand\u00f8ren til at acceptere \u00e6ndringskontrakten. Men hvis denne rettighed overdrives, kan det v\u00e6re bekymrende, at systemudviklingsprojektet ikke vil g\u00e5 glat i praksis.<\/p>\n\n\n\n<p>Derfor er det ofte angivet i kontrakter, at der er en &#8220;pligt til at handle i god tro i forhandlinger om \u00e6ndringer&#8221;, og der er eksempler p\u00e5, at det er angivet, at det er muligt at anmode om erstatning for skader, hvis leverand\u00f8ren ikke reagerer i god tro p\u00e5 \u00e6ndringer.<\/p>\n\n\n\n<p>Et eksempel p\u00e5 en s\u00e5dan formulering er som f\u00f8lger (her er et eksempel p\u00e5 en klausul, citeret fra &#8220;ff Basic\/Individual Contract Model Basic Contract Draft&#8221; officielt oprettet af den uafh\u00e6ngige administrative institution Information Processing Promotion Agency).<\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">\n<p>Artikel 4, afsnit 3 Ved forhandlinger om \u00e6ndringer skal begge parter i god tro dr\u00f8fte emnet for \u00e6ndringen, om \u00e6ndringen kan foretages, og virkningen af \u00e6ndringen p\u00e5 prisen og leveringstiden.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Bestemmelser_om_aendringsmetoden\"><\/span>Bestemmelser om \u00e6ndringsmetoden<span class=\"ez-toc-section-end\"><\/span><\/h3>\n\n\n\n<p>Som n\u00e6vnt tidligere er det juridisk &#8220;sikkert&#8221; at afholde forhandlinger om hver \u00e6ndring. Men i mindre projekter kan det v\u00e6re, at man ikke beh\u00f8ver at fasts\u00e6tte regler for, hvordan man forhandler om \u00e6ndringer. I s\u00e5danne tilf\u00e6lde kan man overveje at lade \u00e6ndringer ske f\u00f8rst, n\u00e5r brugerens og leverand\u00f8rens ansvarlige har underskrevet og stemplet \u00e6ndringsstyringsdokumentet, i stedet for at fasts\u00e6tte regler for forhandlinger. Hvis man tillader \u00e6ndringer at ske let ved mundtlig aftale alene, kan det blive uklart, om \u00e6ndringer er blevet foretaget, hvilket kan f\u00f8re til store problemer senere. I denne forstand b\u00f8r dokumentstyring v\u00e6re grundig.<\/p>\n\n\n\n<p>Men det kan ogs\u00e5 v\u00e6re, at det er en byrde at skulle forberede separate dokumenter for hver \u00e6ndringsstyring, og at man \u00f8nsker at prioritere en fleksibel respons. I s\u00e5danne tilf\u00e6lde kan det v\u00e6re en mulighed at dokumentere \u00e6ndringsrelaterede emner i m\u00f8dereferater. Hvordan man holder m\u00f8dereferater i systemudvikling er detaljeret forklaret i f\u00f8lgende artikel.<\/p>\n\n\n\n<p><a href=\"https:\/\/monolith.law\/corporate\/the-minutes-in-system-development\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/monolith.law\/corporate\/the-minutes-in-system-development[ja]<\/a><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Opsummering\"><\/span>Opsummering<span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p>I milj\u00f8er, hvor specifikations\u00e6ndringer forekommer hyppigt, er der bestemt en tendens til at v\u00e6re i t\u00e6t kontakt med risikoen for problemer og konflikter. Men selv i s\u00e5danne situationer, hvor fleksibilitet er n\u00f8dvendig, kan det ofte v\u00e6re sv\u00e6rt at implementere realistiske foranstaltninger ved blot at understrege &#8220;vigtigheden af styring&#8221; p\u00e5 en stiv m\u00e5de.<\/p>\n\n\n\n<p>Sp\u00f8rgsm\u00e5let om, hvordan man skal balancere den hastighed, der kr\u00e6ves i erhvervslivet, og forberedelsen p\u00e5 en eventuel situation, synes ofte at have forskellige optimale l\u00f8sninger afh\u00e6ngigt af virksomhedens situation og projektets indhold. Selv med hensyntagen til indholdet af denne artikel, mener vi, at det er vigtigt at have en holdning til at s\u00f8ge den passende metode for hver virksomhed og hvert projekt.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>I systemudviklingsprojekter sker det ofte, at brugeren \u00e6ndrer det indhold, de har forklaret p\u00e5 forh\u00e5nd, i l\u00f8bet af arbejdsprocessen. Derfor kan det som leverand\u00f8r, der modtager arbejdet, v\u00e6re n\u00f8dvendi [&hellip;]<\/p>\n","protected":false},"author":32,"featured_media":61570,"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\/da\/wp-json\/wp\/v2\/posts\/60380"}],"collection":[{"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/comments?post=60380"}],"version-history":[{"count":3,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/posts\/60380\/revisions"}],"predecessor-version":[{"id":61572,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/posts\/60380\/revisions\/61572"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/media\/61570"}],"wp:attachment":[{"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/media?parent=60380"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/categories?post=60380"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/monolith.law\/da\/wp-json\/wp\/v2\/tags?post=60380"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}