Hvordan overbevise dine utviklere til å bytte CMS
Overbevis dine utviklere til å bytte CMS med disse fordelene.
Written by Vegard Ottervig on
Overbevis dine utviklere til å bytte CMS med disse fordelene.
Written by Vegard Ottervig on
Fleksibilitet, effektivitet, bedre innholdsskaping: dette er bare noen av fordelene med et nytt CMS som vil få ditt digitale team til å bli entusiastiske.
Men hva med utviklerne dine?
Mens det å forkynne om enklere samarbeid og sømløs redigering kanskje ikke er nok til å overbevise dem om å bytte CMS, vil det å snakke om frontend-rammeverk og åpne standarder definitivt trykke på de riktige knappene.
Moderne teknologi – ved å kombinere et lett headless CMS med deres foretrukne frontend-rammeverk – som det moderne Next.js som kan tilby serverside-JavaScript – kan utviklere komme i gang og utvikle tjenester og løsninger raskt.
Fellesskap og hjelp – et aktivt fellesskap er alltid en fordel for utviklere, da det lar dem feilsøke problemer og lære av andre.
Åpen kildekode – en moderne CMS som er bygget på åpne standarder gjør det både mer forutsigbart og enklere for utviklere å justere systemet til endrede krav og fremtidige trender uten noe oppstyr.
Raskt og enkelt å lære – hvem liker vel ikke et enkelt liv? Utviklerne dine vil definitivt bli fristet av en superintuitiv CMS basert på f.eks. JavaScript.
Innovasjon – å vedlikeholde et gammelt CMS er en stor sløsing med tid og ressurser. I kontrast gir et nytt system rom for innovasjon – noe de beste utviklerne alltid blir begeistret for.
Bygge gode løsninger – som resten av oss ønsker utviklere å bygge noe de er stolte av. Et nytt CMS gir muligheten til å skape noe som virkelig betyr noe, i stedet for å bruke tid på å lappe sammen et gammelt system.
At løsningene deres faktisk blir brukt – mens et gammelt CMS kanskje er utilgjengelig for mindre teknisk kyndige teammedlemmer, vil et nytt, moderne og brukervennlig CMS bli brukt av alle. Det betyr at utviklernes innsats vil bidra til å forbedre arbeidslivet til hele organisasjonen.
Samarbeid med smarte mennesker – samarbeid er kjernen i innovasjon, og utviklerne dine vil få mye av det med et nytt CMS som har funksjoner som f.eks. problemhåndtering, sanntidssamarbeid, og så videre.
Tid og frihet til å eksperimentere – en åpen og fleksibel arkitektur gir utviklerne dine muligheten til å leke med nye ideer og skape et system som passer organisasjonen din som hånd i hanske.
Bruke sitt eget foretrukne utviklingsmiljø – for en utvikler er det få ting som er mer frustrerende enn å jobbe med helt ny maskinvare og programvare, noe som gjør et mer fleksibelt CMS til et uimotståelig tilbud.
Å slippe å supportere de ikke-tekniske brukerne – utviklere har allerede nok å gjøre uten å måtte være tilgjengelige for IT-support. Et nytt CMS som tillater uavhengig innholdsredigering er et tilbud de ikke kan avslå.
Frihet til å velge maler – et pluggbart malverk lar utviklerne dine bruke sine favorittmalmotorer, som Freemarker, Mustache og Thymeleaf.
Frihet til å bruke ethvert frontend-rammeverk – et CMS som lar utviklerne dine bruke sitt foretrukne frontend-rammeverk, enten det er Next.js, Nuxt, SvelteKit, React, Angular eller Vue, er en garantert vinner.
Det er komponerbart – ikke la CMS-et bare være et API blant alle de andre, la det være den sentrale orkestratoren av alle API-er og integrasjoner – og dermed spare utviklerne for mye hodebry.
Utviklere har nok på tapetet uten bryderiet med å distribuere et nytt CMS.
Eller det tror de.
Hvis du introduserer dem til et CMS som ikke bare er raskt, intuitivt og fleksibelt (takket være tilpassbare frontend-rammeverk og serverside-JavaScript), men også enkel å bruke for et ikke-teknisk team, kan ikke utviklerne protestere.
Les mer: Hvorfor vi bygger vårt nye nettsted med Next.js og headless CMS »
Før du begynner å preke for utviklingsteamet ditt, er det verdt å huske hva de ikke liker å høre (ta disse opp i samtalen på egen risiko):
Å bli fortalt hva de skal gjøre – fortell dem dine mål. Ikke fortell dem hvordan de skal komme dit.
Et rigid CMS – et ufleksibelt CMS er som kryptonitt for utviklere. Det bremser arbeidet deres, hemmer innovasjon og er en konstant kilde til smerte.
Å bli bedt om å feilsøke – enhver løsning som krever enda mer feilsøking er dårlig nytt for et allerede travelt team.
Først publisert 30. juli 2019, oppdatert 10. november 2022.
Få enda mer innsikt 🤓