It sikkerhet har de siste årene vært et et tema med økt fokus og relevans. Når vi jobber med systemutvikling er det derfor viktig å håndtere tilgangsstyring på en sikker måte, med gode rammeverk og hjelpemidler. Autentisering (hvem er du) og Autorisering (hva har du lov til) er to aspekter som kan håndteres med Duende IdentityServer.

hei
I 2020 gikk identityServer fra å hovedsakelig være et open source produkt, av Dominick Baier and Brock Allen, til å bli tilbudt som et mer komplett produkt fra Duende Software, og benyttes i dag av en rekke store og små it-selskaper.

For tilgangsstyring skiller vi gjerne mellom:

For bruker-til-system access har IdentityServer god støtte for flere typer innlogging. Dette kan for eksempel være brukernavn og passord, eller ved å integrere med IdPorten så brukere kan benytte BankId.
For maskin-til-maskin access gjør api'er kall til IdentityServer for å autentisere seg.

Når det gjørs et vellykket innlogging/autentiseringsforsøk til IdentityServer, blir det sendt et JWT bearerToken i response.

Hvis man vil se innholdet i et Bearer token kan man f.eks benytte 

 som har et grensesnitt for å se innholdet i bearertokens:

Dette vil resultere i at kall til endepunktet uten token, automatisk gir en 

, siden man ikke har sendt med noe token, og ikke er autentisert.

Kall med token, men som ikke har scope som behøves, vil gi en 

, siden man er autentisert, men ikke har rettigheter til å be om data fra endepunktet.

, siden man ikke har sendt med noe token, og ikke er autentisert.

Tilgangsstyring, med Duende IdentityServer (BlockContent)

Blogg med skalert bilde

<figure><img alt="Image of “Design Systems” spelled out with colorful lego bricks, showcasing how legos can be used as an analogy for a design system" src="https://cdn-images-1.medium.com/max/1024/1*Ja-0F899xqTLKqLss_jr8g.png"></figure>Design systems are an essential aspect of modern web and software development. They help teams create consistent and cohesive user experiences across different platforms and devices. However, building a design system can be a challenging task, particularly when working with a small team. In this article, we will explore some of the challenges and solutions I’ve used when building a design system with a small team.
If you’d like an easy intro to understanding design systems, <a href="https://medium.com/dfind-consulting/creating-consistency-how-lego-can-help-us-build-better-design-systems-8de430df74d3">check out this article</a> where I explore the concepts and use a relatable analogy of LEGO to explain the building blocks of a successful design system.
So, what should you keep in mind? Here’s a little list I’ve prepared, based on my own experiences.
<figure><img alt="“If you wish to make apple pie from scratch, you must first invent the universe.” A quote by Carl Sagan. Image of the ingredients of an apple pie, in the style of Andy Warhol" src="https://cdn-images-1.medium.com/max/1024/1*Bvp-Gqp_n5wP2uoZsjnXlw.png"><figcaption>To make something great, you need to understand and know everything that goes into it, just like making an apple pie from scratch needs all the ingredients and a instructions on how to make it. Image by <a href="https://www.linkedin.com/in/henriknyqvist/">Henrik Nyqvist</a></figcaption></figure><h3>1. Don’t Reinvent the Wheel</h3>
<figure><img alt="1. Don’t reinvent the wheel. Image of a yellow wheel, in the style of Andy Warhol" src="https://cdn-images-1.medium.com/max/1024/1*oBKXg7J0EVqkt_kGo1UHKQ.png"><figcaption>Image by <a href="https://www.linkedin.com/in/henriknyqvist/">Henrik Nyqvist</a></figcaption></figure>As a designer, it’s easy to go down the long winding road of trying to innovate anything and everything you touch, at least that’s the case for me. And that’s pretty time consuming when trying to build a design system, given how many challenges you’ll need to conquer. So, it is important to remember that many of the design problems we encounter have already been solved by others. It’s essential to take inspiration and even steal ideas from existing design systems.
<figure><img alt="Image of the well-known quote “good artists copy, great artists steal” by Pablo Picasso, with an image of a banana replicating an album cover designed by Andy Warhol." src="https://cdn-images-1.medium.com/max/1024/1*3xkFshSf4TQapTECTPiPBw.png"><figcaption>Andy Warhol created a series of artworks inspired by existing commercial images and products, like the famous cover for The Velvet Underground depicting a banana. Image by <a href="https://www.linkedin.com/in/henriknyqvist/">Henrik Nyqvist</a></figcaption></figure>The well-known quote “good artists copy, great artists steal” by Pablo Picasso highlights the importance of taking inspiration from other sources and incorporating it into one’s own work. A good artist may simply copy the work of others, but a great artist takes inspiration from multiple sources and creates something new and unique.
So, take inspiration from other design systems, and save time building your own. Instead of starting from scratch, find out what already works, learn from the successes and failures of others, and adapt your findings to your own team’s specific needs and goals. (Something I wished I’d thought of before I started my first project)
<h3>2. Know Your Limits</h3>
<figure><img alt="Image of a woman with a measuring tape, in the style of Andy Warhol" src="https://cdn-images-1.medium.com/max/1024/1*XIXva4ExpIJzM-vbN1oq6Q.png"><figcaption>Image by <a href="https://www.linkedin.com/in/henriknyqvist/">Henrik Nyqvist</a></figcaption></figure>When working in a small team, be aware of the time constraints and the capacity of your team members. Building a design system is a long-term project and it’s not possible to do everything at once. Therefore, it’s important to start with the most critical elements of the design system, such as buttons, forms, colours or typography. So start small and prioritize low-hanging fruit.
It’s essential to identify who you need help from, and who is available to help you, whether it’s internal or external resources. This could be a developer, a designer, or an accessibility specialist. By bringing in new team members with different skills and perspectives, you can expand your resources and capabilities.
Some design systems also include code snippets and documentation, which is the ultimate goal, but also requires a lot of development time. Therefore, it may be wise to wait until the team becomes a bit larger before tackling the more complex components.
<h3>3. Find Out What Already Exists</h3>
<figure><img alt="Images of color schemes, typography and grids from Monio Design System" src="https://cdn-images-1.medium.com/max/1024/1*AhXPGrrIbpJpNqDI6_xDWw.png"><figcaption>Images from Monio Design System</figcaption></figure>Before starting to build a design system, it’s important to understand what already exists, what’s working well already and what’s not working and needs changing. A UI audit is a great way to do that, in which you evaluate the user interface of a website or application, identify issues and areas for improvement. This includes documenting existing styles, colours, typography, spacing, and other design elements. By conducting a UI audit, your team can identify what’s working well and what’s not, and make informed decisions about what to keep and what to change.
Ask a developer in your team with good knowledge of the code base and find all existing patterns, naming conventions, styles and components, and identify any inconsistencies. Involving technical resources early in the process can help build ownership of the project. They can also help to identify any technical constraints that need to be taken into account when building the design system.
<h3>4. Create Reusable Components</h3>
<figure><img alt="Images of buttons, checkboxes and input fields from Monio Design System" src="https://cdn-images-1.medium.com/max/1024/1*aytEZ2dMiFJMRbYbKvlU8w.png"><figcaption>Images from Monio Design System</figcaption></figure>A design system is a living project, it’s never “done”. Therefore, it’s essential to start with the basics and create reusable components that can be easily updated and maintained, which can save time and effort in the long run.
This could include designing a set of standardized buttons, forms, and other UI elements that can be used across different pages and platforms. This will not only save time in both the design and development processes, but also make it a lot easier to spot inconsistencies and maintain a uniform design language across all products and pages.
<h3>5. Be Organized</h3>
<figure><img alt="Images of custom Figma project covers from Monio Design System" src="https://cdn-images-1.medium.com/max/1024/1*6FQ0Xro68gpCmdW6XxKTCA.png"><figcaption>Small things like organizing design files in Figma by using custom covers that reflect the content and category can make it easier for others to find the right documents at the right time. Images from Monio Design System</figcaption></figure>It’s important to avoid “quick and dirty” solutions. While it may be tempting to take shortcuts and skip steps, in the long run, it’s more efficient to take the time to organize. This means establishing clear naming conventions, keeping design files and assets organized, and maintaining a consistent file structure across the design system. This can reduce communication errors and the need to go back and fix things later on, as well as reduce time looking for files.
Naming Conventions
Naming conventions are a critical aspect of organization and maintaining consistency in a design system. They help to standardize the names of design elements, such as buttons, forms, and other UI elements, across different pages and platforms.
Having a clear and consistent naming convention can improve the overall usability of the design system. It makes it easier for team members to understand the design elements and how they are used. It also makes it easier to update and maintain the design system in the future.
Read more about naming conventions in <a href="https://www.invisionapp.com/inside-design/naming-conventions/">this article</a> by InVision.
<h3>6. Be accessible</h3>
<figure><img alt="An image of a diverse group of people, to reinforce the idea that accessibility and inclusiveness in design benefits everyone, in the style of Andy Warhol, with the text “6. Be Accessible”." src="https://cdn-images-1.medium.com/max/1024/1*48nshEOhqWEtzhYqcYO4dg.png"><figcaption>Image by <a href="https://www.linkedin.com/in/henriknyqvist/">Henrik Nyqvist</a></figcaption></figure>Designing an accessible design system is crucial for creating inclusive and user-friendly products that cater to a wide range of users, including those with disabilities. Accessibility not only enhances the user experience but also provides a competitive advantage for businesses. According to the <a href="https://www.ssb.no/statbank/table/12760/">AKU survey</a> (Arbeidskraftundersøkelsen) conducted by the Norwegian SSB, the number of people with disabilities varies from year to year, and is between 15% and 18% of the population from 15 to 66 years old. In 2020, the proportion was 18%, which corresponds to approximately 636,000 people. People with disabilities face challenges in using technology such as difficulty lifting or grasping objects, cognitive or emotional impairments, vision or hearing impairments, and more.
Design systems help to streamline the process of creating accessible products by providing a baseline for accessibility. The baseline includes components such as colours, typography, spacing, and sizing, and helps to take decision-making away from designers so they can focus on the design itself. However, it is still necessary to conduct additional testing of the design system, interfaces, navigation, and user flows to ensure accessibility.
Testing tools can assist in evaluating the accessibility of design systems. Some essential tools are colour contrast checkers that evaluates UI components against WCAG standards for AA and AAA levels (if you use Figma — try out the <a href="https://www.figma.com/community/plugin/1149686177449921115/Use-Contrast">Use Contrast</a> or <a href="https://www.figma.com/community/plugin/733159460536249875/A11y---Color-Contrast-Checker">A11y</a> plugin) and a colour blindness simulator that allows designers to experience user interfaces from a colour blindness perspective. For MacOS users, you can use the <a href="https://support.apple.com/guide/mac-help/use-color-filters-mchl11ddd4b3/mac">built-in Colour Filters</a> under Accessibility settings which can be really helpful.
Implementing an accessible design system can be a time-consuming process, but it is essential to ensure that the final product is inclusive and usable by a wide range of users. You can make this task manageable by breaking it down into smaller, more manageable tasks and prioritizing the most critical elements first. For example, you could start by establishing clear accessibility guidelines and conducting an initial <a href="https://uxdesign.cc/getting-started-with-web-accessibility-testing-1c85c97f21b9">accessibility audit</a>. You could then focus on implementing the most important changes, such as ensuring that text has enough colour contrast, before moving on to more complex changes, such as improving keyboard navigation.
<h3>7. Test &amp; Validate</h3>
<figure><img alt="Image of a man looking at an iPad, in the style of Andy Warhol" src="https://cdn-images-1.medium.com/max/1024/1*rfrEanK_6X0gEDovrvNIQw.png"><figcaption>Image by <a href="https://www.linkedin.com/in/henriknyqvist/">Henrik Nyqvist</a></figcaption></figure>A design system is not complete until it has been thoroughly tested and validated by real users. This means conducting user research, usability testing, and gathering feedback from the team and stakeholders.
User research and usability testing can help to identify any issues or areas for improvement in the design system. This can be done by recruiting a small group of users to test the design system, and gather feedback on the usability and overall experience. This feedback can then be used to make adjustments to the design system, and ensure that it meets the needs of the users.
<h3>8. Monitor and Improve</h3>
<figure><img alt="Image of a man with glasses, a pencil and a drawing board, in the style of Andy Warhol." src="https://cdn-images-1.medium.com/max/1024/1*Hvp6I6U3oXYFw-Cn6uUG-A.png"><figcaption>Image by <a href="https://www.linkedin.com/in/henriknyqvist/">Henrik Nyqvist</a></figcaption></figure>A design system is a living project and it should be continuously monitored and improved over time. This means regularly reviewing and updating the design system, and keeping it aligned with the overall goals and objectives of the project.
It’s important to regularly review and update the design system to ensure that it remains relevant and effective over time. This includes monitoring the usage of the design system, gathering feedback from users and stakeholders, and keeping it aligned with the latest design trends and best practices, so that it remains relevant and effective over time.
<h3>TL;DR</h3>
<figure><img alt="Text saying “Too much to chew? Here’s the summary” with an image of a man with a huge sandwich in his hands that he can’t chew, in the style of Andy Warhol." src="https://cdn-images-1.medium.com/max/1024/1*AvPgEudpIPolSFS1PFrF1g.png"><figcaption>Image by <a href="https://www.linkedin.com/in/henriknyqvist/">Henrik Nyqvist</a></figcaption></figure>In conclusion, building a viable design system as a small team can be challenging, but it’s not impossible. By following a few key principles and best practices, even a small team can create a design system that is efficient, easy to use, and easy to maintain.
<ul>
<li>Don't reinvent the wheel — borrow, steal or get inspired by other design systems and solutions</li>
<li>Know your limits and prioritize resources</li>
<li>Find out what already exists and build on strengths and address weaknesses</li>
<li>Create reusable components and be organized</li>
<li>Use a step-by-step approach to successfully implement accessibility guidelines when you’re short on time and resources</li>
<li>Test and validate with real users</li>
<li>Continuously monitor and improve over time</li>
<li>Tailor the design system to the specific needs and goals of the team.</li>
</ul>
Sources
<ul>
<li><a href="https://www.ssb.no/statbank/table/12760/">https://www.ssb.no/statbank/table/12760/</a></li>
<li><a href="https://www.invisionapp.com/inside-design/naming-conventions/">https://www.invisionapp.com/inside-design/naming-conventions/</a></li>
<li><a href="https://www.uxpin.com/studio/blog/design-system-accessibility/#h-summary">https://www.uxpin.com/studio/blog/design-system-accessibility/#h-summary</a></li>
</ul>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=a4b36ed16b95" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/designing-efficiently-how-to-build-a-design-system-with-limited-resources-a4b36ed16b95">Designing Efficiently: How to Build a Design System with Limited Resources</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Designing Efficiently: How to Build a Design System with Limited Resources

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*EgsCn4V61NW3AYRs"><figcaption>Photo by <a href="https://unsplash.com/@marvelous?utm_source=medium&amp;utm_medium=referral">Marvin Meyer</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure>I hele min karriere har jeg vært opptatt av å skape et nært bånd mellom design og utvikling. I team jobber man ofte mot de samme målene, og er avhengig av hverandre for å nå dem. Ved å ha et åpent sinn og transparent arbeidsmiljø, vil man kunne lære en hel del, om og av andre, som nesten alltid vil komme til nytte. I min tid som konsulent har jeg opplevd og blitt kjent med mange ulike kunder, prosesser, team og mennesker. Om det er noe viktig jeg har lært, så er det at samarbeid på tvers av fag, og tett kommunikasjon, er helt nødvendig når man jobber i tverrfaglige team.
Men hva syntes jeg har fungert bra, og hva har fungert mindre bra? Og hva må til for at et team skal føle at det er på bølgelengde? Noen tanker rundt disse spørsmålene, og egne erfaringer, skriver jeg om i innlegget. Innholdet er like relevant for designere og utviklere, som ledere, forretning- og domeneekspeter.
<h3>Transparens og åpenhet</h3>
Et team som er transparent, er et team som kommuniserer åpent og ærlig om arbeidet og prosessene de har. Når man vet hva alle de andre i teamet ditt jobber med og hvilket ansvar de har, og samtidig vet at alle de andre har motivasjonen for å ville levere like bra som deg, og du vet hvem du kan snakke med om ulike problemstillinger, da vet du at teamet er på samme bølgelengde.
<h4>Èn av ni løsninger</h4>
I et møte hos en tidligere kunde ble jeg plutselig overrasket. Det jeg ble vitne til da, var to avdelinger som knapt kommuniserte med hverandre. La oss kalle dem for avdeling A og B — begge avdelingene var eid av samme selskap, A var bruker og B jobbet med utvikling. Avdeling A holdt et innlegg for avdeling B om hvordan de jobbet i sin avdelingen, og hvilke verktøy de brukte. De brukte èn av ni verktøy som avdeling B hadde laget for dem. De åtte gjenværende verktøyene løste ikke lengre de utfordringene som avdeling A hadde. Avdeling A forklarte hva som var problemet med de åtte verktøyene og hadde sjeldent noe positivt å si om dem. Den niende løsningene ble derimot sett på som det eneste brukbare, som fra Avdeling B sin side var et utdatert, usikkert og et dårlig lagd system. Uten å ha kommunisert utfordringene tidligere, kjøpte avdeling A andre verktøy og løsninger, og la til side de som ikke ble brukt, uten å si noe til Avdeling B. Vel uvitende jobbet avdeling B med optimalisering og forbedring, i god tro om at det de hadde skapt ble brukt. Grunnen til at kun èn av ni løsninger ble brukt, var i hovedsak mangelen på kommunikasjon mellom avdelingene. Ingen av partene var åpne om systemenes tilstand eller tok initiativ til å diskutere fremtidige behov og utfordringer. Ingen av partene var heller så interessert i hva den andre parten gjorde eller jobbet med, enda de satt vegg i vegg med hverandre.
Selv om historien over ikke handlet om det tverrfaglige teamet, er poenget det samme. Dersom man unngår å holde hverandre informert om utfordringer, kan lignende situasjoner oppstå. Man bør ikke kommeet punkt hvor man bare leter etter feil, før man forsøker å kommunisere eller løse de utfordringene man allerede har.
<h4>Synliggjøring</h4>
Åpenhet kommer tydelig frem når man synliggjør hvem som er ansvarlig for hva. Den personen som starter med en oppgave, er sannsynligvis den mest kompetente til å løse den i starten — mens andre kan bli mer kompetente på sikt. Synliggjøring av kompetanse og ansvar gjør at teamet blir bedre på å delegere arbeid og teammedlemmene vet hvem man kan spørre om hjelp for ulike problemstillinger. Samtidig bidrar synliggjøring til at informasjon ikke holdes skjult, men det er heller en strøm av ressurser og ideer som flyter mellom medlemmene. Synliggjøring er med på å skape tillit i teamet og styrker hvordan man samarbeider i sin helhet.
<h4>Oppsummering: Transparens og åpenhet</h4>
Jeg tror at team som er transparente har mindre utfordringer og at problemer løses raskere. Grunnen kan være at i transparente team, vil man jevnlig snakke om utfordringer, feil man har gjort og bekymringer. Medlemmene kjenner hverandres styrker og svakheter. Strømmen av informasjonen som flyter rundt i teamet gjør det tydelig hvem som har ulikt ansvar, oppgaver og kompetanse. Teammedlemmene har stor tillit til hverandre. De er ikke redd for å dele, få tilbakemeldinger eller motta kritikk, fordi teamet i utgangspunktet deler med hverandre. Dersom vi tør å snakke om feilene vi gjør, vil vi unngå at andre gjør dem også. Vi må godta at andre kan gjøre feil, og gi dem ros når de deler erfaringene med oss.
<h3>Kunnskapsdeling</h3>
Kunnskap er ferskvare, mens erfaring får man jo mer man anvender kunnskap. Når man deler kunnskap, bidrar man til at andre kan utforske den samme kunnskapen og bygge mer erfaring. Deling er en kritisk forutsetning for personlig og andre sin utvikling. Noen ganger har vi behov for å få andres perspektiver, gjennom tilbakemeldinger, innspill og konstruktiv kritikk for å utvikle oss.
<h4>Deling mellom designere og utviklere</h4>
Det viktigste et tverrfaglig team gjør for å holde hverandre oppdatert, er å dele kunnskap. Team som jevnlig deler kunnskap vil kunne diskutere kompleksitet i mye større grad, på tvers av fagområder, enn team som ikke gjør det.
La oss ta for oss noen fordeler som utviklere og designere kan få ut av å dele kunnskap: Utviklere kan få bedre innsikt i hvordan designere arbeider og verktøyene de bruker. Man vil oppdage feil og mangler lettere. Man får bedre forståelse for informasjonsarkitektur, brukertesting, universell utforming og kontraster, for å nevne noe. Dette gjør det mulig for utviklere å ta egne avgjørelser og gjøre endringer i grensesnittet uten å være avhengig av en designer til enhver tid. Designere kan få bedre innsikt i hvordan komponentene (samspillet mellom koden og designet) oppfører seg i brukergrensesnittet. Skisser og prototyper kan utvikles med dypere teknisk innsikt når man skal lage nye eller videreutvikle eksisterende løsninger. Designeren blir mer bevisst på hvordan data prosesseres og flyter mellom systemene — fra backend via frontend til sluttbrukeren — og kan sammenligne kode og design.
Jo mer designere og utviklere vet om hverandres fagområder, desto bedre vil man kunne diskutere forandringer i utseende, tekniske utfordringer, prioriteringer, ytelse og testing m.m. Det vil være enklere å holde kode, design og dokumentasjon synkronisert. Designsystemer kan være svært nyttig til dokumentering, og er et fint verktøy for å samle, synkronisere, strukturere og organisere informasjon i èn felles plattform (en såkalt «single source of truth»). Designere og utviklere som er synkroniserte tar bedre avgjørelser, alene og i fellesskap.
<h4>Oppsummering: Kunnskapsdeling</h4>
En ting jeg husker spesielt godt, fra et tidligere prosjekt, var da jeg og en designer gjorde par-programmering og par-design for å dele kunnskap. De gangene vi leste kode, forklarte jeg hvordan koden og elementene i grensesnittet — designet — hang sammen. Andre ganger satt vi i Figma og diskuterte hvilke tekniske utfordringer vi måtte tenke på når designet skulle utformes. Designeren inviterte meg stadig med på brukertesting for å observere hvordan brukerne opplevde å bruke applikasjonen i den stegvise utviklingen over seks uker. Det viste seg å ha stor verdi for løsningene vi lagde i ettertid. Personlig har det også vært en svært nyttig erfaring for løsninger jeg har bidratt med å lage i andre prosjekter. Når man lærer bort trenger det ikke alltid være noe nyttig, det viktigste er at man får noe ut av læringen. Lær bort det du vet kan være nyttig for andre. Det finnes utallige måter å dele kunnskap på og det kan skje i mange ulike forum. Whiteboard med notislapper, verktøy som Trello, Figma eller discussions i Github er noen eksempler.
<h3>Frihet og eierskap</h3>
I tiden vi lever i nå, hvor endringer skjer utrolig raskt, er bedrifter helt avhengig av å fornye seg for å henge med. Kreative prosesser, eierskap og frihet under ansvar er derfor nødvendig for at vi skal lykkes med å skape nye ideer og nyttige resultater.
<h4>Frihet under ansvar</h4>
Selskapene som fanger interessen til dagens designere og utviklere, er de som har og gir stor frihetsfølelse. Det er også de selskapene som gir rom for egne perspektiver, der det er høyt under taket og lite byråkratisk ledelsesstruktur. Når man hele tiden blir fortalt hva man kan gjøre og hva man ikke kan gjøre, er det vanskelig å kunne være kreativ og bidra med sine beste ideer. Og, når man har fagkompetente mennesker som jobber for seg, er det snodig når en høyt oppe i systemet skal ta tekniske valg fordi de mener de har en god magefølelse. Å gi de ansatte større frihet til å velge selv, når de skal jobbe, hvordan og hvor de skal jobbe — om de vil delta på kontoret eller i møter — vil det mest sannsynlig resultere i lykkeligere ansatte. Det å stole på sine ansatte, og vite at de har kompetansen som trengs, er like viktig da de jo faktisk er profesjonelle på det de gjør. Der teamene har frihet under ansvar, kommer også lojalitet, produktivitet, fleksibilitet og effektivitet som et naturlig resultat.
<h4>Eierskap</h4>
At team tar eierskap for det man skaper, har sterk innvirkning på kvaliteten og arbeidsinnsatsen for sluttproduktet. For at teamet skal få følelsen av eierskap, må selskapene tørre å gi team og medlemmene ansvar. Ansvar betyr å gi teamet selvstendighet til å eie produktet ved å bestemme egne prosesser, metodikk, leveranser og teknologi. Med eierskap blir teamene mer selvdrevne og eksperter innenfor sitt domenet. Utviklerne og designerne kan fokusere på færre prosjekter, og de slipper å sjonglere mellom mange ulike domener, kontekster, prosesser og avhengigheter (møter, planlegging, standups) som ikke har noe med hverandre å gjøre. Eierskap gir mer trygghet, og dypere forståelse for det man jobber med, fordi man kan fokusere og bli ekspert på mindre deler av et prosjekt, domene, brukergruppe eller produkt.
<h4>Oppsummering: Frihet og eierskap</h4>
Jeg jobbet en gang i et team hvor en rekke utviklere og designere hadde fullt eierskap til flere løsninger innenfor et bestemt domene. Dersom en avhengighet utenfor domenet måtte løses, ble et annet team koblet på for å løse avhengigheten i det respektive domenet — fordi det var deres ansvarsområdet og ekspertområde. Jeg jobbet også i et annet team for ikke så lenge siden — der jeg kom helt fersk inn i domenet og selskapet –, hvor alle utviklerne kunne plukke utviklingsoppgaver fra mange ulike domener. Det var ikke så nøye hvem som gjorde hva, men oppgavene skulle løses. Utfordringen med å jobbe på denne måten, var at ingen fikk spesiell kompetanse på noen av domenene. Samtidig kunne du jobbe med enten SvelteJS, NextJS, NodeJS eller ren ReactJS, CSS, SCSS, CSS Modules eller StyledComponents. Personlig har jeg hatt en god opplevelse når det kommer til Frihet under ansvar. Men jeg tror at de teamene som har ansvar for få prosjekter, har lettere for å ta et større eierskap fordi de kan gå i dybden og konsentrere seg om færre ting. For mye eierskap kan gjør at man ikke kjenner godt nok til et domene. Dersom man er innom mange oppgaver og prosesser samtidig i ulike prosjekter, kan delegering av arbeid og ansvar fort føre til at man får mindre eierskap og oversikt for de enkelte prosjektene.
<h3>Individuell og kreativ tenking</h3>
Mange utviklingsteam jobber etter smidige prosesser som Scrum eller Lean. I smidige prosesser samles gjerne teamet en gang i blant for å snakke om ideer, progresjon, mål, oppgaver, ansvar og trivsel. Under samlingene, er målet som regel å arbeide og tenke som et lag. Men, det kan også handle om å finne roller og styrker i teamet eller meningen med hvorfor du og teamet eksisterer.
<h4>Retrospektiv</h4>
Retrospektiv er en ganske vanlig teknikk som benyttes i smidige prosesser. Teamet reflekterer sammen om hva som har fungert bra, og hva man kan forbedre i utviklingssyklusen. Dette er ofte kalt sprinter. En gang jobbet jeg med et team bestående av utviklere, designere, testere, devops, prosesseier og produkteier. Teamet var opptatt av å få med alle sine meninger, for det var viktig at alle ble hørt. Hver og en av oss tok en bunke post-it lapper og tusj. Vi fikk ti minutter til å skrive ned tanker og ideer i stillhet. En og en fra teamet fikk så henge opp sine post-it lapper på veggen og snakke om hva den handlet om foran de andre. På denne måten fikk alle formidle sine tanker og ideer som ble delt med resten av teamet. Til slutt hadde vi avstemning. Hvert teammedlem fikk tre røde prikker som kunne klistres på de lappene som man syntes burde diskuteres videre eller fortjente å være med videre til neste syklus.
<h4>Hvorfor?</h4>
Vet du meningen bak hvorfor akkurat du og teamet ditt eksisterer? Hvorfor dere skal løse de utfordringene dere er tildelt, og hvorfor du og dine egenskaper er viktig for å løse dem? Jeg husker godt da teamet mitt benyttet teknikker fra Simon Sinek’<a href="https://www.amazon.com/gp/product/B005JZD3B4/ref=kinw_myk_ro_title"> bok</a> og<a href="https://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action"> TED foredrag</a>,<a href="https://www.amazon.com/gp/product/B005JZD3B4/ref=kinw_myk_ro_title"> Start with Why</a>. Simon har laget en modell han kaller “The Golden Circle”, der han snakker om hvordan store ledere verden over inspirerer til innovasjon og definerer suksess; svaret er å starte med “Why”:
<ul>
<li>”hvorfor eksisterer vi som team i denne virksomheten?”</li>
<li>“hvorfor er jeg i teamet og hva kan jeg bidra med?”</li>
<li>“hvorfor er vi viktig for virksomheten, brukerne eller kundene?”</li>
<li>“hvorfor eksisterer produktene våres?”</li>
<li>“hvorfor skal kundene bruke produktene vi lager?”</li>
</ul>
Modellen fokuserer på hvorfor, fremfor hva og hvordan.
<h4>Oppsummering: Individuell og kreativ tenking</h4>
Selv tror jeg, at når enkeltmenneske kan reflektere og tenke individuelt, vil man få frem utrolig mange ulike ideer, meninger og følelser. Jeg tror også at det skapes flest ideer, og at de beste beslutningene blir tatt, når man får flest mulig perspektiver inn i diskusjonene, og hver person kan tenke for seg selv uten forstyrrelser. Det er viktig å finne ut hvem man selv er i teamet, og hvor man kan bidra med sine styrker. Simons Sinek’ modell, hjalp teamet mitt med å få et godt overblikk på hver enkeltes bidrag, ansvaret de hadde og hvorfor vi individuelt og teamet eksisterte. Retrospektiv er en veldig god aktivitet for alle mulige team, men jeg tror det er spesielt nyttig der teamene er tverrfalige. De ulike fagrettningene kan oppleve forskjellige utfordringer og kan dele de med resten av teamet. Mange teknikker i smidig utvikling handler om å prate og jobbe sammen som ett lag. Og det er jo fint det, men jeg har også opplevd når man jobber i workshops, at det er lett for at personene som har flest ideer eller de som snakker mest, ofte sitter med fasiten. Retrospektiv muliggjør for at alle kan tenke frem sine ideer og dele de med hele teamet. Fordi alle ideene, meningene og menneskene blir tatt seriøst, og er like viktige.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=3243f38daab8" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/erfaringer-fra-arbeid-i-tverrfaglige-team-3243f38daab8">Erfaringer fra arbeid i tverrfaglige team</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Erfaringer fra arbeid i tverrfaglige team

<figure><img alt="Scrabble bricks floating" src="https://cdn-images-1.medium.com/max/1024/1*zgxTpdSxw3M7wROIh0MS2g.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@tot87?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Piotr Łaskawski</a> on <a href="https://unsplash.com/photos/gL7oJLJOb_I?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure><h3>Introduksjon</h3>
Det kan være svært frustrerende og tidkrevende å navigere gjennom en mengde tekst for å finne det vi leter etter uten en klar og tydeliggjort syntaks. I dette innlegget vil vi se på hvilke grep designere kan gjøre for å forbedre den opplevelsen. Design-grep som kontraster, avstander, tykkelser og størrelse er blant tingene vi skal snakke om.
<h3>Bakgrunn</h3>
Folk scanner tekst etter triggerord, det vil si at de har en mental modell av hva de ser etter og scanner teksten etter dette. Hvordan vi kan gjøre dette så enkelt som mulig for brukeren? Gjennom en god syntaks. Så, hva menes med syntaks? Syntaks er måten ord og setninger er satt sammen på for å formidle noe. Det kan også beskrives som en semantisk struktur, altså at et budskap blir formidlet på tydeligst mulig måte ved bruk av færrest mulig ord, uten å bli upresis. Dårlig tydeliggjort syntaks kan føre til forvirring, misforståelser og i verste fall, feil handlinger. Derfor er det meget viktig å ha en klar og tydelig syntaks for å sikre en god brukeropplevelse.
<h3>Design-grep</h3>
<figure><img alt="Tools laying on a table" src="https://cdn-images-1.medium.com/max/1024/1*GZiMQGsuVd5ZyKkA_Areyg.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@dancristianpaduret?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Dan Cristian Pădureț</a> on <a href="https://unsplash.com/photos/noOXRT9gfQ8?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Et av de viktigste grepene man kan gjøre for å tydeliggjøre syntaksen i et budskap er ved å bruke kontraster. Det handler om å strukturere et logisk hierarki som gjør det enkelt for brukeren å forstå hva som er overskrift, ingress og brødtekst. Får man til det vil det gå veldig raskt for en bruker å identifisere hvor de skal lete etter den informasjonen de søker. Noen er kun ute etter essensen, og vil derfor søke etter ingressen. Dersom ingressen ikke skiller seg visuelt fra brødteksten, er den også vanskelig å identifisere. Måten man kan gjøre dette på er ved å bruke forskjellige fonter, farger eller skriftstørrelser for å skille mellom viktige deler av budskapet. Avstander kan også brukes for å skille mellom forskjellige elementer og gjøre det lettere å navigere gjennom teksten. Tykkelsen på skrifttypen kan også justeres for å fremheve viktige ord eller setninger.
Det finnes mange gode prinsipper å følge i UX-verdenen som kan hjelpe oss å skape gode brukeropplevelser. Derfor er det viktig å forstå disse. Et av dem er Gestalt prinsippene. Gestalt prinsippene tar for seg hvordan hjernen vår tolker visuell informasjon for å skape mening og forståelse. Her er noen av disse:
<ol>
<li>
Nærhet: Tendensen å oppfatte ting som nært relatert hvis de er plassert i nærheten av hverandre.</li>
<li>
Likhet: Tendensen til å se ting som ligner hverandre som relatert.</li>
<li>
Lukking: Tendensen til å fullføre figurer eller mønstre, selv om de er ufullstendige.</li>
<li>
Symmetri: Tendensen til å se symmetriske figurer som mer organisert og harmonisk.</li>
<li>
Kontinuitet: Tendensen å se kontinuerlig og jevnt flytende linjer som beslektet.</li>
</ol>
“Nærhet” og “Likhet” brukes ofte for å skape mening og sammenheng i et budskap. For eksempel kan lignende elementer grupperes sammen for å vise at de hører sammen, mens elementer som ikke er relatert kan plasseres fysisk lenger fra hverandre. Disse gestalt-effektene er grunnleggende prinsipper for hvordan hjernen vår organiserer og forstår visuell informasjon, og er noe vi burde tenke på når vi designer for å skape mer effektive og engasjerende opplevelser.
<h3>Ting å huske på</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*DMW8ftvY8Sk8yXNnOZhxQw.jpeg"><figcaption>Photo by <a href="https://unsplash.com/@brett_jordan?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Brett Jordan</a> on <a href="https://unsplash.com/photos/ofpr9Cw8Rj8?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Det er viktig å ikke overdrive bruken av design-grepene nevnt over. Det vil fungere i mot sin hensikt. Teksten vil da bli forvirrende og vanskelig å lese. En annen ting man må huske på er at man må sørge for at de blir brukt konsekvent gjennom hele teksten. Er man ikke det vil innholdet bli mye vanskeligere å fordøye for brukeren. Hold det enkelt og vær konsekvent. Dette vil føre til gode opplevelser. Helt til slutt, husk å test med brukere for å sikre at det er tydelig og lett å forstå.
<h3>Konklusjon</h3>
For å avslutte, ved å bruke design-grep som kontraster, avstander, tykkelser og gestalt-prinsipper, kan vi tydeliggjøre syntaksen i et budskap og forbedre brukeropplevelsen. Det er viktig å ikke overdrive bruken av disse for å sørge for konsekvent bruk for å unngå forvirring. Husk å alltid teste med ekte brukere for å sikre at det er tydelig og lett å forstå.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=bce7165e0cd2" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/tydeliggj%C3%B8ring-av-syntaksen-i-et-budskap-bce7165e0cd2">Tydeliggjøring av syntaksen i et budskap</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tydeliggjøring av syntaksen i et budskap

<figure><img alt="Image of “Design Systems” spelled out with colorful lego bricks, showcasing how legos can be used as an analogy for a design system" src="https://cdn-images-1.medium.com/max/1024/1*JzLRrvtQL1tVMWn6w9GUGg.png"></figure>Design systems have become a crucial part of creating user-centered and visually appealing products. They provide a set of guidelines that designers follow to ensure consistency, scalability and clarity throughout the design process. But where can we find inspiration for these systems? In this article, we explore the design principles of one unexpected source: LEGO. We will delve into how LEGOs can be used as an example of a natural atomic design system and how its design principles can be applied. Let’s dive in, think outside the box and see how LEGOs can inspire your next design system project.
As a designer, I’ve always been fascinated by the principles of design systems. So, when I was assigned to lead the rebranding of a previous employer’s identity, I realized that I had to find the right inspiration. That’s when it hit me: LEGO.
I had always loved playing with LEGOs as a kid, but as I began to study their design principles, I was truly amazed by their level of consistency, modularity, and clarity.
I realized that the iconic little blocks and pieces represent the atoms of a design system. Those atoms come together to form smaller components, which are the molecules, and molecules come together to form organisms, which form products that exist within a theme. The higher up the chain you go, the more specialized things become. This structure is very similar to Brad Frost’s <a href="https://atomicdesign.bradfrost.com/">Atomic Design principles</a>.
I learned a lot from my research and I want to share this knowledge with others. That’s why I decided to write this article, to show how LEGOs can be an excellent source of inspiration for any design system.
<h4>1. Introduction</h4>
<blockquote>A design system is a collection of guidelines, components, and tools used to build and maintain a consistent user experience over time.</blockquote>
LEGO can be used as an analogy to explain design systems. Just as LEGO bricks are used to build structures, design system components (such as colors, typography, and buttons) are used to create interfaces. Like LEGO bricks, design system components are modular and can be used in a variety of ways to create different designs.
In this article, we will explore how LEGO can be used as an analogy to explain design systems, the importance of design systems in creating a consistent user experience and how to implement a design system in your organization.
<h4>2. Building with LEGO vs. a design system</h4>
<figure><img alt="A pile of various colored and shaped LEGO bricks, showcasing the modularity and flexibility of LEGO" src="https://cdn-images-1.medium.com/max/1024/0*hKmTUrlUo7V27Tmm"><figcaption>Photo by <a href="https://unsplash.com/@xavi_cabrera?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Xavi Cabrera</a> on <a href="https://unsplash.com/photos/kn-UmDZQDjM?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></figcaption></figure>Building with LEGO involves using a variety of different shaped and colored bricks to create structures. These bricks are designed to fit together in a specific way, allowing for the creation of intricate and complex designs. This modularity of LEGO bricks is similar to the modularity of design system components, which can be combined in various ways to create different designs.
<figure><img alt="An image of a detailed replica of the Tatooine Cantina from Star Wars, built entirely out of lego bricks, showcasing the intricate designs and possibilities of lego building." src="https://cdn-images-1.medium.com/max/1024/0*i9RkGl2MFFRJvbGd"><figcaption>LEGOs can be used to create anything you can imagine, as long as you have the right pieces and know how to put them together. Photo by <a href="https://www.flickr.com/photos/tales2astonish/">marvelousRoland</a> on Flickr. (1)</figcaption></figure>In the same way that LEGO bricks have specific guidelines on how they should be used to create stable structures, design system components also have specific guidelines on how they should be used. These guidelines help ensure that the final product is consistent and visually pleasing.
Additionally, LEGO sets come with instructions on how to assemble the bricks into a specific, repeatable design. In the same way, a design system includes instructions on how to use its components to create cohesive designs. This allows for consistency across different designs and projects.
<figure><img alt="“Consistency is one of the most powerful usability principles: when things always behave the same, users don’t have to guess what will happen.” — Jakob Nielsen" src="https://cdn-images-1.medium.com/max/1024/0*z9ye9ZgqD63y9sSE"><figcaption>This quote from Jakob Nielsen highlights the importance of consistency in creating a user-friendly experience, which is one of the key principles of a design system.</figcaption></figure><h3>3. The LEGO Design System</h3>
<figure><img alt="An image of the packaging of a LEGO TIE-Bomber set, showcasing the branding and product design of LEGO." src="https://cdn-images-1.medium.com/max/1024/0*oGa8JGEdlFkRWgCV"><figcaption>A LEGO Star Wars Tie Bomber set, showcasing how LEGO’s design system is used to create consistent and recognizable products across different franchises. Photo by <a href="https://www.flickr.com/photos/tales2astonish/">marvelousRoland</a> on Flickr (2).</figcaption></figure>Just like any other company, LEGO has its own design system which is used to ensure consistency across its products. This design system includes a color palette, typography, and iconography that are used in the creation of LEGO sets, packaging, and other materials.
The LEGO design system is used in the development process of new products, from initial concept to final packaging. It ensures that all products have a recognizable LEGO look and feel, making it easy for consumers to identify them as LEGO products.
The different components of the LEGO design system, such as the color palette and typography, are used in combination to create consistent designs. This consistency helps to strengthen the LEGO brand and makes it easy for consumers to recognize and trust LEGO products.
<h4>4. Implementing a Design System</h4>
Implementing a design system in your organization can help to create a consistent user experience across all of your products and platforms. To begin creating your design system, it is important to involve all stakeholders in the process, including designers, developers, and product managers.
One of the first steps in creating a design system is to establish a set of design principles. These principles will guide the design decisions and provide a framework for the design system components.
Some examples of design principles:
<ol>
<li>
Consistency: The consistent use of design elements across different platforms and devices to create a cohesive user experience and recognizable design (LEGO bricks are designed to fit together in a specific way to create a consistent structure).
</li>
<li>
Modularity: The design of the interface should be modular, with reusable and flexible components, allowing for adaptability and scalability (LEGO bricks can be used in a variety of ways to create different designs).
</li>
<li>
Clarity: The creation of a clear and simple interface that is easy to understand and use, providing a seamless user experience and providing clear instructions (LEGO instructions guide you through the building process).
</li>
</ol>
Next, you should create a set of reusable components such as buttons, forms, and typography. These components should be tested and refined to ensure that they meet the established design principles.
<figure><img alt="An image of a set of basic design elements in a system, including buttons, checkboxes, radio buttons, and input fields." src="https://cdn-images-1.medium.com/max/1024/0*bS7iqLOVzwpjDJXW"><figcaption>An example of a few basic component sets in a design system. Images from Monio Design System.</figcaption></figure>Once the design system is in place, it is important to maintain and evolve it over time. This includes updating components as needed, and making sure that all new designs adhere to the established guidelines. It’s also important to provide training and resources to ensure that all team members are aware of the design system and understand how to use it.
<h4>5. TL;DR</h4>
<ul>
<li>Design systems are essential for creating a consistent user experience across different platforms and devices. The LEGO analogy helps illustrate the importance of using a set of guidelines and modular components to create consistent and recognizable designs.</li>
<li>Implementing a design system in an organization can take some time and effort, but it is worth it in the long run. It will improve the overall user experience and make it easier for the organization to create consistent and recognizable designs.</li>
<li>A design system is like a set of LEGO bricks, when you have all the right pieces and know how to use them, you can build something great.</li>
<li>A design system is a living document: it is important to remember that a design system is not a one-time project, but a living document that should be constantly reviewed and updated to reflect the ever-changing needs of the organization and its users.</li>
<li>So, whether you’re building with LEGO bricks or designing interfaces, the principles of consistency, modularity, and guidelines will always be key to creating something great.</li>
</ul>
Credits
(1) “Blast from the Past: Tatooine Cantina MOC from 2010” by marvelousRoland on Flickr. Used under the Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0) license. Image source: <a href="https://www.flickr.com/photos/tales2astonish/">https://www.flickr.com/photos/tales2astonish/</a>. License terms: <a href="https://creativecommons.org/licenses/by-nc-nd/2.0/">https://creativecommons.org/licenses/by-nc-nd/2.0/</a>
(2) “LEGO TIE-Bomber packaging” by marvelousRoland on Flickr. Used under the Attribution-ShareAlike 2.0 Generic (CC BY-SA 2.0) license. Image source: <a href="https://www.flickr.com/photos/tales2astonish/">https://www.flickr.com/photos/tales2astonish/</a>. License terms: <a href="https://creativecommons.org/licenses/by-nc-nd/2.0/">https://creativecommons.org/licenses/by-nc-nd/2.0/</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=8de430df74d3" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/creating-consistency-how-lego-can-help-us-build-better-design-systems-8de430df74d3">Creating Consistency: How LEGO Can Help Us Build Better Design Systems</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Creating Consistency: How LEGO Can Help Us Build Better Design Systems

Vi som jobber med UX har mye fokus på hvordan vi skal kommunisere for å nå brukerne på best mulig måte. Hvordan skal vi få sagt alt riktig? Hvordan skal vår kommunikasjonsstrategi være, og hvordan skal vi prioritere?
Vi voksne bruker så mange ord. Så store ord, og kanskje til og med litt vanskelige ord. Ord som viser hvor veltalende vi er. Vi glemmer kanskje at mottakeren burde kunne det samme for å forstå det vi prøver å si? For det er vel egentlig målet? At de som tar imot skal forstå?
Hva hadde vi gjort om vi bare kunne noen få ord? Om vi ikke kunne si eller skrive det vi ønsket å formidle?
I vår satt jeg i stua med sønnen min som lekte sykehus. Han kom med noe til både meg, og til pappaen sin. Det var et brettet ark med et plaster på. Han er fem år, og kunne ikke skrive annet enn sin egen forbokstav. Men jeg var aldri i tvil om hva det var jeg fikk i hendene. Det var helt selvsagt en innkalling til sykehuset hans.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*fJGApaHmlhworwdVl67UaQ.png"><figcaption>En femårings innkalling til sykehus</figcaption></figure>UX designeren i meg ble så imponert, stolt og nesten litt rørt over hans evne til å kommunisere hans mål på en så tydelig og enkel måte uten ord. Og dette satte virkelige tankene i spinn!
Ord for overlevelse I ettertid har jeg opplevd flere og flere øyeblikk som har endret måten å skrive på. Min toåring har også fått meg til å tenke. Hun lærer seg stadig nye ord, og det fascinerer meg hvilke ord hun lærer først. De første ordene som kommer er de ordene hun trenger mest for å overleve. “Mamma” og “pappa” for trygghet. “Tørst”, “mer”, “banan” for ikke å sulte. Og så skader det jo ikke med litt “bø” og “tittei” på veien for å skape sosiale relasjoner.
Hun bruker ordene som trengs mest for å dekke hennes behov på raskest mulig måte. Hun bruker ordene som vi selv bruker for å nå inn til oss, og ord som har gitt viktig respons når hun tidligere har brukt de. Når hun må tisse så roper hun “Tisse!”. Men hva gjør jeg da? Jo, jeg begynner med masse fuzz og spørsmål om hun har tissa i bleia frem til hun avbryter meg med å rope “Potte”! Tisse. Potte. Du får det ikke mer klart. Et behov, to enkle ord. Greit… jeg forstår!
Når hun fikk vannkopper ropte hun “Au”, og “mau”! Og siden vi er i samme stamme så vet jeg at mau betyr maur. Men jeg vet også at hun ikke kan ordet klø, men at å klø kan kjennes ut som å ha en maur krypene oppover.
Hvordan kan vi lære noe av måten barn snakker på? Nå er det sjeldent vi kan bruke kun to ord i vår kommunikasjon, og dette er jo slettes ikke verken barseltreff eller mammaforum. Så hvorfor tar jeg opp dette, og hvordan kan vi lære noe av nok en mamma som snakker om barna sine?
Jo, vi kan forenkle og forbedre måten vi skriver og kommuniserer på. Vi kan bruke enkle ord. Ord som sterkt dekker et behov, hvor det ikke er tvil. Ord som alle forstår, og ord som brukerne selv lærer oss. Vi kan bruke symboler som alle forstår, som har et klart budskap. Vi kan finne frem barnet i oss, gjøre det enkelt. Når ble vi så kompliserte? Hvor mange ganger har du ikke tenkt «årh.. hva er nå ordet for dette». Kanskje trenger du ikke det ordet… kanskje trenger du bare å beskrive hva du skulle finne et ord for. Kanskje er beskrivelsen av ordet lettere å forstå for alle andre også, og i tillegg vil en beskrivelse kunne åpne opp for enda mer følelser. Det er jo også ofte slik vi kommuniserer med andre som snakker et annet språk enn oss selv. Da bruker vi ordene vi begge forstår for å beskrive det vi egentlig mener.
Så kan vi kanskje ikke gå til en barnehage hver gang vi skal skrive for en målgruppe. Og det trenger vi heller ikke. Men vi kan gå til målgruppen. Vi kan lære deres språk, deres ord, deres stammespråk og deres tydeligste ord som dekker deres viktigste behov. Og vi kan bruke deres egne beskrivelser om ord og begrep.
Vi er inne i høysesong for dager hjemme med sykt barn. Nyt tiden med de små UX designerne, lytt, le og bli inspirert.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=90e5450c9a43" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/snakk-som-et-barn-90e5450c9a43">Snakk som et barn?</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Snakk som et barn?

Som teamleder må du legge til rette for godt samarbeid i teamet ditt. En måte å samarbeide på, eller å komme i gang med samarbeid på, er å ha workshops (/arbeidsmøter).
Det som er fint med workshops er at det krever involvering fra de som deltar. Å ha en workshop uten at alle er med, er kun et vanlig møte. Når vi gjør noe, lærer vi bedre. Benjamin Franklin sa “Tell me and I forget, teach me and I remember, involve me and I learn”. Og som gruppe kan vi få til mer enn når vi er alene, spesielt om vi er tverrfaglige.
Jeg skal kort gjennomgå noen tips til hvordan arrangere morsomme og interessante workshops.
Tillit
For å få folk til å komme med de beste idéene, er det viktig med tillit. En måte å skape tillit på er å starte workshopen med en «Ice breaker», — en uhøytidelig øvelse før man begynner. I Dfind Consulting brukte jeg nylig «ett ord i gangen»-øvelsen, hvor hver deltaker sier ett ord hver, i tur og orden, og til slutt blir ordene til en setning. Det skapte latter og det fikk folk til å slappe av. Resultatet ble, til min store overraskelse, fornuftig: «Inspirerende samarbeid er kult og alle bør være sammen om hverandres idé». 12 personer blir til 12 ord i en setning.
En annen viktig sak er å få etablert regler om hvordan vi skal være mot hverandre, såkalt etikette. I mindre sammensveisede miljøer er det lurt å tenke på regler som beskytter mot at noen blir krenket, for eksempel kan en generell regel være «Vi behandler kollegaer, kunder og ledere likt». En slik regel skal bidra til å fremme likebehandling og redusere konflikter.
Regler som inkluderer mangfold og inkluderingstankegang kan være:
<ol>
<li>Snakk fra din egen erfaring i stedet for å generalisere.</li>
<li>Unngå å ugyldiggjøre en annens historie med din vurdering av deres innspill.</li>
<li>Målet er ikke å alltid være enig, målet er å få en bedre forståelse.</li>
<li>Vær bevisst på kroppsspråket ditt og ikke-verbal respons.</li>
</ol>
I tillegg bør man ha vanlige regler som at «hvert innspill er et godt innspill» og «store og sprø idéer er velkommen», slik at folk ikke blir redde for å si det de tenker.
For å være sikker på at alle får sagt det man mener, må man dele inn i mindre grupper, gjerne helt ned i 3 per gruppe. Gruppene bør ha en avtale på at alle skal si noe, og i den sammenheng kan man for eksempel bruke en penn. Den som har penna snakker, og penna går på rundgang. I virtuelle «breakout» rom, må man ha en talestyrer som passer på at alle sier noe.
<figure><img alt="Morsomt med “Ice breaker”" src="https://cdn-images-1.medium.com/max/1024/0*oZkoNbaZjlhyFnM7"></figure>Forandring fryder
Det er mange forskjellige teknikker å bruke når man skal kjøre en workshop. Min erfaring er at forandring fryder. Hvis teamet ditt er vant med at alt foregår på skjerm, er det fint å variere med en workshop der man bruker fysiske ting som en vanlig tavle eller en «white board». Og motsatt, er man vant med å bruke whiteboard og papir, bruk Miro på PC.
<figure><img alt="Flytt ut av PC’en til tavla." src="https://cdn-images-1.medium.com/max/1024/0*gKOit8M1K1MgnvLd"></figure>Nylig flytta jeg jira-tavla over på en fysisk tavle med én oppgave per post-it, som vi oppdaterte hver dag i en uke. Målet var å få flest mulig lapper over til høyre side (til status «Ferdig»). Dette hjalp på motivasjonen i teamet. Mange av de involverte likte å flytte lapper fysisk. Det krever selvsagt en del manuell oppdatering av fasilitator/meg å holde Jira-tavla og den fysiske tavla i synk, men det er også en glimrende mulighet for fasilitator/meg å se det man holder på med i et nytt perspektiv.
Typer workshops
Ellers er det haugevis med tips på nett til forskjellige workshop-teknikker. Men jeg anbefaler:
<ul>
<li>Bryt opp og gjør noe annet, som for eksempel: flytt Jira-oppgaver (eller oppgaver i et digitalt verktøy) over på post-its og oppdatér tavla fysisk.</li>
<li>
<a href="https://cynefin.io/wiki/Future_backwards">«Future backwards»</a>, for å legge en strategi framover eller lage en plan. Ha god tid.</li>
<li>
<a href="https://theworldcafe.com/">«The world café»</a> for å få gode samtaler og produsert noe konkret, for eksempel lage et utkast til en ny applikasjon med bruk av papir og teip etc.</li>
</ul>
<figure><img alt="Det er avslappet stemning på kafé." src="https://cdn-images-1.medium.com/max/1024/0*oDPEiGpUUh-LJTmJ"></figure><ul>
<li>
<a href="https://www.qualitativemind.com/projective-techniques/">Projisering</a>: Finn et bilde som for eksempel representerer hvilken opplevelse brukere skal ha av tjenesten vi skal utvikle og la gruppene diskutere og argumentere for hvorfor de har valgt seg det og det bildet. Kjernen i øvelsen er samtalene rundt bildene.</li>
<li>Og ikke minst, et forslag til virtuelle workshops: bruk «Tre små griser» som retrospektiv iblant. <a href="https://www.funretrospectives.com/three-little-pigs/">«Three little pigs»</a> er en morsom retrospektiv-metode som får frem litt andre poeng enn de vanlige typene retrospektiv: «Hus av strå», «Hus av pinner» og «Hus av mur» i stedet for «Hva var dårlig?», «Hva kan forbedres?» etc.</li>
</ul>
Det viktigste kommer likevel til slutt: etterarbeidet og tiltak. Det man kommer fram til i workshopen skal brukes videre. Tiltak skal gjennomføres av team-deltakerne og teamleder må sørge for det. Det er viktig at teamleder tar hovedansvaret og sørger for at tiltak blir gjennomført.
Oppsummering
Oppsummert blir dette:
<ul>
<li>Start med en «Ice-breaker»</li>
<li>Bestem regler for oppførsel</li>
<li>Del inn i grupper på 3 personer, også virtuelt i «break out rooms», og pass på at alle får sagt sin mening</li>
<li>Bruk en workshop-teknikk som er en variasjon i teamet sin hverdag</li>
<li>Teamleder sørger for at alle tiltak blir gjort</li>
</ul>
Om du har spørsmål eller tanker, kontakt meg på <a href="mailto:heidi.hundala@dfind.no">heidi.hundala@dfind.no</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=df389a9088f5" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/workshops-og-samarbeid-df389a9088f5">Workshops og samarbeid</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Workshops og samarbeid

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*NcYlXOfb8Wdwa_jP"><figcaption>Photo by <a href="https://unsplash.com/@zacdurant?utm_source=medium&amp;utm_medium=referral">Zac Durant</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure>Sometimes I see developers define variable names such asisNotSelected, hasNoData and shouldNotInclude. I avoid writing variable names like this as much as possible. Declaring variables like so focuses on the negative outcome. Variables written in a non-active, negative or reversed way give a feeling that the returned value is something we don’t want or that is not positive and good. Instead, writing code that focuses on something active, positive, or forwarding will make the code-reading experience more efficient and less frustrating.
<h3>Variable naming: positive vs negative</h3>
We force our brains to think reversely when naming variables based on the negative outcome. Doing so is more strenuous than thinking in an active or forward way.
The code we are producing should be easy to read and make sense. Naming our variables on the positive outcome is better for a developer’s reading experience because it feels active and valuable. If we eventually want the opposite outcome, the non-active or negative, we invert it when necessary. In my opinion, It’s easier to think that something is active and inactive instead of in-active and not in-active. Let’s make a comparison:
Negative named variable:
<pre>const isNotActive = true isNotActive // =&gt; true</pre>
Positive named variable:
<pre>const isActive = false isActive // =&gt; false</pre>
<h3>Inverting</h3>
The exclamation mark (!) is almost ubiquitous in programming languages and is a suitable replacement for words like no, not and doesn’t. For instance, we can turn a boolean state to the opposite by using an exclamation mark.
Use exclamation marks to turn positive to negativ (or the other way). In When we see an exclamation mark on a variable that is initially based on something active or a positive outcome, developers generally know that the condition will turn to the opposite value. In the code example below, we could prepend exclamation marks to isNotActive and isActive. Still, the isActive variable would be easier to read for the common eye because it has an active state in the first place. On the other hand, when we initially base our variable name on the negative outcome, the results are not quite so clearly.
Negative named variables:
<pre>const isNotActive = true const hasNoData = true</pre>
<pre>if(isNotActive &amp;&amp; hasNoData) { // not active }</pre>
<pre>/******* OR *******/</pre>
<pre>if(!isNotActive &amp;&amp; !hasNoData) { // active }</pre>
Positive named variables:
<pre>const isActive = false const hasData = false</pre>
<pre>if(!isActive &amp;&amp; !hasData) { // not active }</pre>
<pre>/******* OR *******/</pre>
<pre>if(isActive &amp;&amp; hasData) { // active }</pre>
Working with arrays could be another example. Let’s say we have an array of vegetables and want to be sure that it does not contain carrots. We could make a couple of variables named doesNotContainsCarrots or containsCarrots and wrote the code like so:
Negative named variable:
<pre>const vegetables = ['potato', 'salad'] const doesNotContainsCarrots = vegetables.some(v =&gt; v !== 'carrot')</pre>
<pre>if(doesNotContainsCarrots) { // does not contain carrots, no chopping }</pre>
<pre>/******* OR *******/</pre>
<pre>if(!doesNotContainsCarrots) { // contains carrots, chop chop }</pre>
Positive named variable:
<pre>const vegetables = ['potato', 'salad'] const containsCarrots = vegetables.some(v =&gt; v === 'carrot')</pre>
<pre>if(!containsCarrots) { // does not contain carrots, no chopping }</pre>
<pre>/******* OR *******/</pre>
<pre>if(containsCarrots) { // contains carrots, chop chop }</pre>
Like previous examples, it’s easier to read and think that something exists and invert it if we want the opposite outcome (positive to negative).
<h4>Consistency Throughout the codebase</h4>
We write code that should function, exists and work. Refactoring will become easier if the naming of variables follows a specific format. How we name variables, functions, enums or types in our code should be consistent throughout the codebase to avoid confusion. Naming things both positively and negatively in the same file or within the same scope should also be avoided. If that is the case, we should choose to go for either the positive or negative naming style since mixing is confusing. But in the end, I guess you will choose to go with positive and active naming simply because it feels more natural.
<h3>Summarize</h3>
Writing code that focuses on the active state and should return a positive outcome in our variable increases readability. By doing so, we don’t have to think in reverse. The state would be easier to revert since you always turn something active to not active, and lastly, we will focus more on what we need in our code instead of what we don’t need. Finally, our code would be easier to keep consistent because we follow a specific format for naming variables (and functions, types, etc.) Code must be easy to read, and we should write variable names with that in mind.
Code foh shizzle
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=b42328d51e9c" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/about-writing-positive-and-negative-variable-names-b42328d51e9c">About Writing Positive and Negative Variable Names</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

About Writing Positive and Negative Variable Names

<h3>Agile 2 — Agile har blitt oppgradert?</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*QczHI4JoE5yrlGfjIyTqdQ.png"></figure>Nylig leste jeg en bok som heter <a href="https://agile2.net/">Agile 2 — The next iteration of Agile</a> og la meg starte med å si at det er ikke en oppgradering, men en gjennomtenkt nytenkning av det opprinnelige Agile manifestet. Men først en liten tur ned memory lane.
I februar 2001, hadde 17 meget dyktige mennesker samlet seg på et hotell i Utah. Her ble det gjort et stykke arbeid, som endret arbeidshverdagen for mange mennesker til det bedre og enklere. Det var på det hotellet i Utah det Agile manifestet så sitt dagslys.
Det Agile manifestet er et bygd opp på <a href="https://agilemanifesto.org/iso/no/manifesto.html">fire verdier</a> og <a href="https://agilemanifesto.org/iso/no/principles.html">tolv prinsipper</a> for hvordan man bør jobbe med agil programvareutvikling.
<ol>
<li>Personer og samspill fremfor prosesser og verktøy</li>
<li>Programvare som virker fremfor omfattende dokumentasjon</li>
<li>Samarbeid med kunden fremfor kontraktsforhandlinger</li>
<li>Å reagere på endringer fremfor å følge en plan</li>
</ol>
De som laget verdiene over, er også tydelige på at verdiene både på venstre og høyre side er viktige, men at verdiene på venstre side av “fremfor” bør verdsettes høyere.
Nå tenker du kanskje, dette høres fornuftig og logisk ut, og jeg er helt enig. Det er nok også en veldig stor grunn til at agil programvareutvikling har blitt såpass utbredt som det er i dag. Men, det har skjedd mye innenfor agil programvareutvikling på de 20+ årene som har gått siden de så dagslys. Det er det boken Agile 2 — The next iteration of Agile tar for seg. Boken er skrevet av <a href="https://agile2.net/about/">15 personer</a>, med omfattende erfaring innen agil programvareutvikling fra hele verdenen.
Forfatterne av Agile 2 er veldig tydelige på at de ikke har laget et rammeverk for prosess, for som de selv påpeker i boken, er at det er ikke noen prosess i det agile.
I boken tar de for seg det som er positivt med det Agile manifestet. Og at intensjonen med Agile 2 er ikke å erstatte Agile, men å foredle og utvide. Men også på noen områder å justere noen av de opprinnelige ideene som kanskje nå i etterpåklokskap, har vær litt for enkle, ekstreme eller at de passer til alle typer problemstillinger.
Apropos det enkle, så mener forfatterne av Agile 2 at det Agile manifestet forenklet en del ting og ikke tok hensyn til ledelsesteori, atferdspsykologi og kognitiv kunnskap.
Som et eksempel så tar boken for seg hvordan man i det agile fokuserer på team i veldig stor grad. Her mener forfatterne at man har gått litt for enkelt til verks, og at hvert enkelt individ i et team har blitt glemt litt oppi det hele. I boken bryter de ned til et så banalt eksempel som det daglige rituale mange agile team kjører, bedre kjent som stand-up. Se for deg et gitt eksempel med at du jobber som utvikler og teamet ditt har en daglig stand-up kl 08:45. Du kommer kanskje på jobb rundt kl 08:00 og du vet hva du skal jobbe med å løse denne dagen. Og her kommer allerede et viktig poeng i boken, og det er at å skrive kode er ikke noe man bare gjør på stående fot, men at det til tider kan være et ganske krevende tankearbeid. Så når du da har satt deg ned på plassen din og du vet at det er i underkant av 45 minutter til stand-up, så er det kanskje ikke hensiktsmessig å starte på dette tankearbeidet, for du vil bli avbrutt når du skal på stand-up. I stedet henter du deg kanskje noe å drikke, samt at du muligens snakker litt med en kollega om noe. Deretter kommer du til stand-up, hvor alle på tur går igjennom hva de har jobbet med dagen før, hva de skal jobbe med i dag og evt om de har noen problemer.
Her kommer Agile 2-boken inn på enda et viktig poeng som kanskje har blitt neglisjert litt i oppi iveren etter det agile. Hvor mye verdi/interessant er egentlig denne informasjonen for de andre i teamet? Hvor viktig er det å vite hva kollegaen din har jobbet med dagen før eller skal jobbe med om det faktisk ikke påvirker deg eller ditt arbeid? Kanskje det kan løses på andre måter, hvor man likevel får delt nødvendig informasjon med teamet, uten at man trenger å kjøre tradisjonell stand-up?
Men nå tenker du kanskje, ja men da har man jo god tid etter stand-up til å jobbe? Igjen, så kommer har forfatterne av boken et godt poeng og jeg tror de av oss som har jobbet noen år vil kjenne seg igjen i dette. Som oftest er ikke dagen møtefri etter stand-up, men består gjerne av både planlagte og uforutsette møter som bryter opp dagen i mange biter. Så når skal man egentlig komme seg i en flytsone og få tid til tankearbeidet? Dette og mye annet ønsker Agile 2 boken å belyse, men den kommer også med forslag til hvordan kan løse de ulike problemstillingene på en god måte.
Dersom du har lest ned helt hit, så kanskje du har blitt litt nysgjerrig på boken selv? Jeg vil absolutt anbefale deg å lese boken, den er et friskt pust til det agile. Selv satt jeg igjen med en god del nyttige aha-opplevelse og nyttige refleksjoner for hvordan jeg selv har arbeidet med agile.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=98a407be3070" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/agile-2-agile-har-blitt-oppgradert-98a407be3070">Agile 2 — Agile har blitt oppgradert?</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Agile 2 — Agile har blitt oppgradert?

<h3>JavaZone 2022 — Key takeaways</h3>
<h4>JavaZone er en av verdens største samfunnsdrevne konferanser og tar for seg ulike temaer innenfor teknologi, sikkerhet, UX og ledelse. Konferansen gikk over to dager med fullpakket program og mange interessante foredrag.</h4>
Skrevet av <a href="https://medium.com/@mathias.hartveit">Mathias Hartveit</a> og <a href="https://marius-ibsen.medium.com/">Marius Ibsen</a>
Som alle tidligere år ble JavaZone holdt i Oslo Spektrum. Konferansen hadde mer enn 3200 deltakere, over 100 foredrag og foredragsholdere.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*wSQSpqbrXGVXOyQuJoQMCQ.jpeg"><figcaption><a href="https://www.instagram.com/p/CiQCSulKngJ/?utm_source=ig_web_copy_link">https://www.instagram.com/p/CiQCSulKngJ/?utm_source=ig_web_copy_link</a></figcaption></figure>Vi har tatt med oss mange erfaringer fra årets JavaZone som vi syntes er viktig å belyse. Erfaringene og kompetansen vi har tatt med i år handler hovedsakelig om mennesker.
<h3>Utvikling handler om mennesker</h3>
Utviklere blir mer og mer tilknyttet flere deler av organisasjonen og tar valgene som tidligere ble tatt av personer uten innsikt eller kunnskap om faget. Dette kommer nok av at man forstår bedre hva utviklerrollen er og at den kan flettes inn med de andre fagdisiplinene i organisasjonen.
På JavaZone i år delte flere foredragsholdere om egne erfaringer som ikke nødvendigvis hadde hovedfokus på kode. Det handlet også om mennesker, forventninger til utviklere og at utvikling ikke alltid trenger å være så seriøst.
Hva betyr det å være en god utvikler? Christin Gorman fra Kodemaker mener at vi må oppdatere hvilke forventninger om hva programmering egentlig er; dette snakket hun om i foredraget<a href="https://2022.javazone.no/#/program/a28cd1fa-9696-4a1f-97b0-ce1c0bbad6dc"> What makes a good developer?</a>. Det som forventes av en utvikler i dag er gode mattekunnskaper og å kunne skrive algoritmer. Programmering som fag blir ofte fremstilt som en idyllisk verden hvor det ikke oppstår problemer eller utfordringer men dette stemmer ikke overens med virkeligheten. Utviklere opplever utfordringer i hverdagen slik som i andre jobber, vi løser bare ulike utfordringer og har andre behov.
Forventningene som stilles i dag er nesten irrelevant og langt ifra hva en utvikler faktisk jobber med. Utviklere flest bruker svært lite matematikk i det daglige, og de færreste av oss skriver en algoritme. Det er hverken nødvendig med gode mattekunnskaper eller å kunne skrive algoritmer for å være en god utvikler. Christin mener vi bør fokusere på andre egenskaper som er mer nødvendige og relevante for det arbeidet vi driver med. Hvordan man jobber med mennesker og forstå problemene vi må løse for menneskelige behov er av viktigere art; en utvikler programmerer hovedsakelig løsninger for å løse menneskelige utfordring. Christin nevner tre egenskaper man bør se etter når man skal rekruttere nye talenter:
<ul>
<li>De viktigste egenskapene en utvikler må ha er tålmodighet og utholdenhet.</li>
<li>Jo mer vi kan av det grunnleggende desto bedre valg kan vi ta i fremtiden.</li>
<li>Vi trenger mer menneskelig interesse. Vi må bry oss om menneske vi lager løsninger for, og vi må forstå utfordringene brukerne våre opplever.</li>
</ul>
Stian Veum Møllersen fra NRK tok oss med på en <a href="https://2022.javazone.no/#/program/8c383c4d-e6ab-44f0-a5a2-ae0782d20e9f">røverhistorie om Popcorn og klokker</a>. For noen år siden startet han et moro-prosjekt for å gjenskape låten Popcorn, en meme-låt fra 1969. Prosjektet gjorde at man måtte løse ulike problemstillinger og finne riktige datastrukturer for å håndtere tid og lyd synkront i nettleseren. Utfordringene han måtte løse gjorde at han fikk innsikt i flere av nettleserens verktøy, som blant annet setInterval, setTimeout, requestAnimationFrame og WebAudio-klokka. En annen foredragsholder, Vegard Veiset fra Bekk, viste frem sin hjemmesnekra spillmotor laget i Kotlin. Spillmotoren hadde han laget fordi han ville forstå hvordan en spillmotor fungerer, ikke for å faktisk lage spill. Prosjektet hadde han jobbet med i over fire år på hobbybasis.
Både Stian og Vegard lagde noe med interesse for å løse andre problemer enn det de vanligvis støttet på. De trengte ingen spesiell grunn eller mening de ville bare gjøre noe gøy for å lære seg ny kunnskap. Det vi lager trenger ikke være seriøst eller nyttig, ei heller profesjonelt for å være lærerikt. Det viktigste er at man får noe ut av det man lager
Nina Bakken, designer i NAV, hold innlegget <a href="https://2022.javazone.no/#/program/77ba7dac-424f-401f-ac34-2539aeba2807">Fart, flyt og hyppige leveranser = bedre brukeropplevelse</a> hvor hun delte erfaringer om det å lære et team å arbeide sammen i smidige prosesser. Essensen av smidig utvikling handler om å gjøre små ting, ofte. Ved å gjøre dette, vil man redusere risiko ved store lanseringer. Smidig utvikling handler også om kontinuitet, og at man jobber med små porsjoner som kan lanseres hele tiden. En typisk designmetodikk går gjennom flere steg — ide, konsept, testing og utvikling. Utviklere jobber gjerne etter en kortere prosess hvor de “slipper unna” de stegene som ikke har med utvikling å gjøre og feil fikses ofte umiddelbart. Hvis man får alle de ulike fagdisiplinene til å arbeide sammen som et team, så er det ikke noe i veien for at alle de tverrfalige rettningene kan jobbe slik utviklere gjør. Det bør ikke være separate faser men noe som skjer kontinuerlig. Innsikt, konsept, testing, utvikling og videreutvikling er noe man alltid må gjøre uansett.
Inkludering av de tverrfaglige fagrettningene i hverandres prosesser vil etter hennes mening gi økt fart, flyt og hyppigere leveranser. Åpenhet om kode og design vil skape mindre usikkerhet i teamet. Det er viktig å kunne vise frem og snakke om uferdig arbeid for å unngå tap av innsikt og læring. Hun trekker frem noen tilnærminger som har fungert bra for deres team, blant annet parprogrammering, par-design og datadreven utvikling.
Samlingen av disse foredragene og tilnærmingsmåtene danner et bilde av en norsk industri i vekst hvor fokuset på den tekniske og den organisatoriske og menneskelige siden av utvikling blir mer sammenflettet.
<h3>Fremtiden er Sosio-Teknisk</h3>
Norske bedrifter og organer har over lengre tid hatt fokus på en digitaliseringsprosess av deres tjenester og produkter. Denne prosessen ser ut til å ha ført de fleste opp mot en felles problemstilling. Hvordan skaper man og vedlikeholder IT-baserte team, programvare og prosesser som er bærekraftige, langsiktige og stabile for medlemmer, produktet og brukere?
Dersom man spør 10 bedrifter får man nok 10 forskjellige svar, og derfor er det veldig givende at mange av Norges IT-kjemper deltar på JavaZone for å dele sine erfaringer og anmodninger om hvordan nettopp de oppnår sine mål — uten å slite ut både teknologien og menneskene involvert.
Vipps utforsker sine utfordringer, opplevelser og erfaringer i foredraget <a href="https://2022.javazone.no/#/program/5a831bdc-03be-4142-9e47-ec24dd95713c">Hva er digital produktutvikling? En historie fra Vipps.</a> Moquan Chen og Marit Andreassen understreker viktigheten av å danne tverrfaglige og myndiggjorte team. Et myndiggjort team dannes når medlemmene har autonomi til å ta de valgene fagpersonene mener er best for å oppnå målet definert av ledelsen. For mye styring ovenfra fører til mikrostyring, noe som ofte fører til teknisk dårligere produkter og mindre eierskap for selve laget som utfører oppgavene. Man ønsker å teste teorier og hypoteser så tidlig som mulig i prosessen frem mot et produkt for å luke ut hvilke muligheter teamene har fremover.
<a href="https://2022.javazone.no/#/program/85187a21-c215-43f8-90e8-88989b7a945d">Einar W. Høst fra NAV</a> mener at moderne utviklere og it-systemer er “sosio-tekniske” fenomener. Organisasjonens krefter påvirker utviklingen av programvare, som igjen påvirker arbeidsmåten til organisasjonen. Utviklere som ønsker å påvirke organisasjonen må være mer enn bare teknisk dyktige, de må også være sosialt dyktige. I foredraget tar Einar oss gjennom de personlige utfordringene som kan oppstå individuelt og internt i team som blir mer og mer myndiggjort i dagens landskap.
Det eneste som ser ut til å være sikkert i tverrfaglige, teknologiske og myndiggjorte team er at landskapet rundt endrer seg kjapt, og det endrer seg ofte. Dette gjelder både teknisk med tanke på teknologiske utfordringer og muligheter som åpner for nye løsninger, men også samfunnsmessige endringer. Lover og regler, fokus på nye brukergrupper eller endringer i brukernes daglige behov kan slå inn på hva fremtiden til teamet skal se ut som. Desto viktigere er det at teknologene er fokusert på å bygge bærekraftige løsninger. Med bærekraftige løsninger menes det tekniske løsninger som tåler endring og vedlikehold over lang tid, med skiftende fokus og landskap.
<a href="https://2022.javazone.no/#/program/b0d4acb2-2255-48db-acf0-f1268017b49e">Kristofer Giltvedt Selbekk</a> deler sine erfaringer fra 10 år med design systemer og frontend komponentbibliotek for å belyse hvordan man designer React komponenter med fokus på den fremtidige utvikleren. <a href="https://2022.javazone.no/#/program/8a2fd154-b7d0-466c-99b4-ffce79cc6e2f">Vegard Haugstvedt</a> forteller om NAVs pågående arbeid med å digitalisere alle sine søknader. Til nå estimerer de at de har digitalisert om lag 300 søknader på 3 år! Teamet må underveis ta hensyn til flere lag med brukere, samt endringer i lover og regler, endringer i nav-kunders behov og ikke minst ønsker om å kunne bruke tjenesten utenfor den digitale sfæren.
Som deltaker på JavaZone 2022 har det vært svært givende å delta i diskusjonene og erfaringene som deles av mange av Norges fremste teknologiske bedrifter. Dette er utfordringer som er universelle for alle team i alle sektorer, og byr på et spennende blikk inn i fremtiden for mange “sosio-teknologer”.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=b344a33962f9" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/javazone-2022-key-takeaways-b344a33962f9">JavaZone 2022 — Key takeaways</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

JavaZone 2022 — Key takeaways

<h3>Fra student til konsulent — Løft blikket før skredet tar deg</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*TE4iDhsn-kLJC4x4hHptgA.jpeg"><figcaption>Fra Camp Dfind 2022</figcaption></figure>August er alltid en spennende tid hos oss i Dfind Consulting. Sommerstudentene har nettopp blitt offboardet, mens våre nyutdannede kollegaer har sin første arbeidsdag som eksperter i IT. Dette innebærer naturligvis forventninger fra oss som arbeidsgiver, fra kunder og ikke minst fra den nyansatte selv. I dette innlegget skriver jeg om hvordan Dfind Consulting sørger for å møte deres forventninger gjennom vår onboarding-uke. Hensikten med uken er å gi nyutdannede en trygg start på karrieren og samtidig hjelpe dem på veien til å bli gode konsulenter. Slik lykkes Dfind Consulting i å utvikle markedsledende løsninger for våre kunder.
<h4>En nyutdannet sin styrke</h4>
Erfaring, hva har det egentlig å si i IT-bransjen? En erfaren topptur-gåer kan mest sannsynlig gå fortere, gjøre bedre sporvalg og klare seg bedre enn en uerfaren topptur-gåer. Statistikken viser derimot at jo mer erfaren du er, jo mer utsatt er du for å bli tatt av snøskred. Kan man basert på dette anta at jo mer erfaren du er, jo høyere er sannsynligheten for at du følger “kjente spor” i stedet for å se nye løsninger eller legge merke til endrede forutsetninger?
Det er nettopp her de nyutdannede rett fra skolebenken har sin styrke, og dette gjelder spesielt i IT-bransjen. Teknologi, rammeverk og språk endrer seg så raskt at innen du kan kalle deg erfaren, kan forutsetningene ha endret seg, eller det det kan ha kommet en ny løsning på problemstillingen. Derfor mener jeg at nyutdannede med ufargede sinn, er særlig relevante og stiller sterkt for å se de beste løsningene for våre kunder.
Innenfor frontend finnes det flere gode eksempler på hvor raskt teknologi og etterspurt kompetanse utvikler seg. Du rekker knapt å bli erfaren i et rammeverk før det har kommet et nytt og mer “moderne” på banen. Illustrasjonen nedenfor viser endring i popularitet for hvert frontend-rammeverk siden 2016. Dette gjenspeiler riktignok ikke etterspørsel i markedet, men det gir et interessant bilde av hvor raskt det skjer endringer i teknologi, som igjen påvirker etterspørselen av kompetanse.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*jqHJBEkG4TMpemwl"><figcaption>“THE STATE OF JS 2021: FRONT-END FRAMEWORKS AND LIBRARIES”. Alex Ivanovs. 19. februar, 2022</figcaption></figure><h4>Utvikler vs. konsulent</h4>
Våre nyutdannede konsulenter har i løpet av studietiden blitt eksperter innenfor sitt tekniske fagfelt. Dette har vi sikret gjennom grundige screeningprosesser og intervju. Felles for alle er at ingen har hatt “konsulentfaget” på skolen. Konsulent og utvikler er i mine øyne to veldig forskjellige roller. Vi konsulenter går hele tiden på line. Oppgaven vår er å balansere mellom å utfordre kundene våre, og samtidig se at løsningen vi oppfatter som perfekt, nødvendigvis ikke er den som skaper høyest verdi. Det er nettopp her det er så utrolig viktig at vi bruker kompetansen vår til å hjelpe kundene våre i å gjøre gode vurderinger.
Det finnes ingen fasit på hva som definerer en god konsulent. Du har muligheten til å lage din egen definisjon basert på din personlighet, erfaring og kompetanse. En god konsulent er uavhengig av personlighetstrekk. Forskjellen finner vi i hvordan du lærer å bruke disse trekkene sammen med din kompetanse til å spille deg selv og våre kunder gode. Det betyr at jo større mangfold vi har, jo større arsenal tilegner vi oss av fremgangsmåter for å hjelpe kundene våre. Dette er etter min mening, det som virkelig gjør jobben vår til en av de mest givende, utviklende og utfordrende jobbene innenfor IT. Så hvordan utgjøre denne forskjellen som konsulent, uten erfaring? Jo, Camp Dfind.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*chojcC4cbVf1Pd8lIz18lA.jpeg"><figcaption>Det ble luftig på Camp Dfind 2022</figcaption></figure><h4>Camp Dfind</h4>
Vi kan ikke påstå at vi er de eneste i bransjen som har en onboarding-uke for nyutdannede konsulenter. Derimot tør vi påstå at vi har bransjens kanskje mest unike omboardinguke. Konseptet bak Camp Dfind er å trene opp våre egne, av våre egne. De nyutdannede får under trygge forhold bryne seg på typiske fallgruver man som konsulent opplever, og kjenne på presset som kan oppleves ute hos kunde. Samtidig blir de kjent med sine nye kollegaer og ledere på en utflukt ute av byen. Hensikten med Camp Dfind er å gi konsulentene en verktøykasse de kan ta med seg ut til sitt første prosjekt. Dette gjør at våre nyutdannede kollegaer kan senke skuldrene når første kunde står for tur. De vil føle seg tryggere, skape mer verdi og på den måten føle seg mer verdsatt, som til syvende og sist fører til høyere trivsel.
Teknologi og språk er selvsagt også en viktig del av Camp Dfind. Vi har fokus på at konsulentene får tatt i bruk nye spennende språk og rammeverk som de kanskje ikke har vært borti før. Dette gjenspeiler også noen av utfordringene når man går fra skolebenken til konsulent hos en ny kunde. Evnen til å tilegne seg kunnskap i ukjente språk, rammeverk, metodikker og teknologier raskt.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*QYQcyj9GCKA8Sli_xV6jPg.png"><figcaption>Deltakernes beskrivelse av Camp Dfind 2022</figcaption></figure>Camp Dfind er under kontinuerlig utvikling for å sikre våre nyutdannede den beste starten på sin karriere hos oss. Ser du for deg en fremtid som IT-konsulent og har lyst til å vite mer om Camp Dfind? Vi kan dessverre ikke røpe mer om konseptet, men håper du har lyst til å oppleve det med oss. Kanskje vi sees på Camp Dfind?
Referanser
The State of JS 2021: Front-end Frameworks and Libraries. 2022. Hentet fra <a href="https://stackdiary.com/front-end-frameworks/">https://stackdiary.com/front-end-frameworks/</a>
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=5cde7e60910" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/fra-student-til-konsulent-l%C3%B8ft-blikket-f%C3%B8r-skredet-tar-deg-5cde7e60910">Fra student til konsulent — Løft blikket før skredet tar deg</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Fra student til konsulent — Løft blikket før skredet tar deg

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*NNpIKZmLZ8bDSz79"><figcaption>Photo by <a href="https://unsplash.com/@vonshnauzer?utm_source=medium&amp;utm_medium=referral">Egor Myznik</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure>Did you know we can use Git reference logs to restore Git commit history(?) Often we developers experience challenges when working with Git. We can accidentally force-push commits to the remote main branch, complete a rebase that went bad, delete a branch we wanted to keep or hard reset to the wrong commit. In this post, we will look at git reflog and git reset. We will review some common scenarios on restoring local commits, restoring a deleted branch, and reverting force-pushed changes due to a rebase.
<h3>Git reflog</h3>
<a href="https://git-scm.com/docs/git-reflog">git reflog</a> is a tool that can help us recover almost anything — at least everything we have committed. The tool keeps track of commits that have been created but also discarded ones in a log called the reference log. The reference log is kept on our local computer under the .git directory in a local repository. It contains a list of commits that HEAD has pointed to and keeps track of the entire history of a commit. Besides the reference log for branches, we have a separate reference log for stash.
It’s important to know that reference logs do not track in the remote repository, like pushes, fetches and clones; it is purely local and current to the working environment. Below is two screencaps, the first from Github Codespaces and the second from a local filesystem that initially created all the commits of the main branch in the same repository:
<figure><img alt="" src="https://cdn-images-1.medium.com/max/964/1*L1DTjYe4kiUo01_95hL-dQ.png"><figcaption>Reference log from a workspace in Github Codespaces</figcaption></figure><figure><img alt="" src="https://cdn-images-1.medium.com/max/930/1*d175xjAzVotgtgHlFvjtQg.png"><figcaption>Reference log from local computer where the commits were initially created</figcaption></figure>Records of the history on a branch will expire after 30 days by default. We can change the expiration days running git reflog —expire if we want to keep the history for a longer time or just want to change the duration.
<h3>Git log vs reflog</h3>
<a href="https://git-scm.com/docs/git-log">git log</a> is a command that shows a list of commits related to a branch.git reflog is similar to git log but shows a list of snapshots and times when HEAD was changed. reflog can also reference other types such as stash, branches, rebase, merge and tags. A reference is known as refs, and the syntax for accessing these is name@{qualifier}. Running git reflog is the most basic use case and essentially the equivalent of writing git reflog show HEAD. The output will look like this:
<pre>=&gt; git reflog</pre>
<pre>47efaa2 HEAD@{0}: commit: refactor: remove post schema f243f12 HEAD@{1}: commit: refactor: change author fields 4783ba0 HEAD@{2}: commit: chore: add .env to gitignore a19d142 HEAD@{3}: commit: chore: update readme f5ade9a HEAD@{4}: commit: chore: update yarn.lock 854c08f HEAD@{5}: commit (initial): feat: bootstrap sanity studio</pre>
<h3>Git reset</h3>
<a href="https://git-scm.com/docs/git-reset">git reset</a> is a command we can use to move back to a previous commit, discarding or undoing previous changes. We can run git reset --hard &lt;commit_sha&gt; to move our branch back in the commit history.
<ul>
<li>
A hard reset (git reset --hard) will completely destroy any changes and remove them from your local repository.</li>
<li>
A soft reset (git reset --soft) will keep your changes, and stage them back automatically.</li>
<li>
A mixed reset (git reset --mixed) which is the default, will keep you changes but they will also become unstaged. Even tho it is flexible, you will have to stage the changes manually.</li>
</ul>
<h3>Restore local commits</h3>
<h4>Scenario</h4>
We have made some commits that haven’t been pushed to the remote repository yet. We do a git reset —-hard &lt;commit_sha&gt; to a previous commit, and our local branch is set back to an earlier point and discarded all history after the chosen commit. We then run git log and see that the commits are gone. We cannot pull the changes from the remote repository since we never synced the changes.
<h4>How to restore</h4>
When running git reflog we can see that our changes still are tracked by the reference log; we even have a separate commit for the hard reset that we did earlier:
<pre>f243f12 HEAD@{0}: reset: moving to f243f12 eec6f27 HEAD@{1}: commit: refactor: author should not have image 47efaa2 HEAD@{2}: commit: refactor: remove post schema f243f12 HEAD@{3}: commit: refactor: change author fields</pre>
With this information, we can reset our branch back to the state we discarded by using one of the references in the reflog. We can move our branch to the selected commit by running git reset --hard &lt;commit_sha&gt;:
<pre>=&gt; git reset --hard f243f12 =&gt; git reflog</pre>
<pre>f243f12 HEAD@{0}: reset: moving to eec6f27 f243f12 HEAD@{1}: reset: moving to f243f12 eec6f27 HEAD@{2}: commit: refactor: author should not have image 47efaa2 HEAD@{3}: commit: refactor: remove post schema f243f12 HEAD@{4}: commit: refactor: change author fields</pre>
<h3>Restore a deleted branch</h3>
We can recover deleted branches using SHA’s in the reference logs.
<h4>Scenario</h4>
Not uncommonly, we might checkout a new branch in our local environment. We could have a branch called chore/update-packages and commit a change that adds <a href="https://day.js.org/">dayjs</a> as a package:
<pre>=&gt; git checkout -b chore/add-dayjs-package =&gt; yarn add dayjs =&gt; git add . =&gt; git commit -m 'chore: add dayjs package'</pre>
<pre>5a75042 HEAD@{0}: commit: chore: add dayjs package</pre>
At a later point, we checkout the main branch and deletes the chore/add-dayjs-package branch — maybe we did not need it anymore for some reason:
<pre>=&gt; git checkout main</pre>
<pre>47efaa2 HEAD@{0}: moving from chore/add-dayjs-package to main</pre>
<pre>=&gt; git branch -D chore/add-dayjs-package</pre>
<pre>Deleted branch chore/add-dayjs-package (was 5a75042)</pre>
We will get a confirmation message that git deleted the branch. After a while, we discover that we could need the changes after all, so how do we get them back?
<h4>How to restore</h4>
We can undo these changes with git reflog and git checkout. If we run git reflog we won’t see any references to the deleted branch. We could use the commit SHA provided in the delete message (5a75042) to revert the latest commit on that branch. But if we have lost the message, we need to use the reference log. And if you named your commits well, it should be easy to find the missing commit:
<pre>=&gt; git reflog</pre>
<pre>// deletion of a branch is not logged to reflog 47efaa2 HEAD@{0}: moving from chore/add-dayjs-package to main 5a75042 HEAD@{1}: commit: chore: add dayjs package 47efaa2 HEAD@{2}: moving from main to chore/add-dayjs-package</pre>
We can now checkout the deleted commit SHA and create a new branch from that commit running git checkout -b &lt;branch_name&gt;:
<pre>=&gt; git checkout 5a75042 =&gt; git checkout -b chore/add-dayjs-package</pre>
<h3>Revert force-pushed changes</h3>
<h4>Scenario</h4>
We reset our branch using git reset —-hard to an earlier commit and run git push — force to override any changes that we otherwise could pull from the remote repository. But at some point, we want those changes back.
<pre>=&gt; git reset --hard &lt;commit_sha&gt; =&gt; git push --force</pre>
<h4>How to restore</h4>
We can use git reflog and git reset to restore force-pushed changes.
<pre>=&gt; git reflog f243f12 HEAD@{0}: reset: a19d142 to f243f12</pre>
By the log we can see that the message on HEAD@{0} is reset: a19d142 to f243f12, which means that commit with hash a19d142 was force-pushed by f243f12. That also gives us information about which commit we need to restore, the one with hash a19d142. We can simply do the same procedure as initially to move back to the overriden commit:
<pre>git reset --hard a19d142 git push --force</pre>
Finally, we force-push the new changes to the remote repository. Always be careful and check that you are on the correct branch before doing a force push. Especially to prevent that production code is not being affected or team member code is not being overwritten.
Thanks for reading! I hope you enjoyed this content. Feel free to clap, comment or share.
Code foh shizzle
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=67f7676e902f" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/restore-commit-history-with-git-reflog-67f7676e902f">Git reflog: Restore Version Control History</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Git reflog: Restore Version Control History

<h3>Dfind Consulting Internship 2022</h3>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*bIkHM8F11nVKVT1pVOiACQ.jpeg"><figcaption>Jannicke Hamarsnes, Helena Skants, Skjalg Hovland Holtbakk, Eskil Schjølberg, Kavusikan Sivasubramaniam, Thea Kvinnegard, Ida Anseth, Duvara Nishaharan, Elsa Lossius (bak fv.) og Patrick Wulff.</figcaption></figure>Skrevet av Axel Aasen
Dfind Consulting har i år hatt sitt første internship. Over seks uker har ti sommerstudenter hatt ansvar for å lede et prosjekt for selskapet. I løpet av perioden har de utviklet en mobilapplikasjon og en webapplikasjon. Jeg har tatt en prat med sommerstudentene Thea Kvinnegard, Jannicke Hamarsnes og Ida Anseth for å få innsikt i hva de har arbeidet med og lært i løpet av perioden.
Sommerstudentene var delt inn i to team; Team App og Team Admin. Team App hadde ansvar for å utvikle mobilapplikasjonen, mens Team Admin hadde ansvar for å utvikle webløsningen. De to teamene var avhengige av hverandre gjennom hele prosjektet, og samarbeidet på tvers. På denne måten fikk de en realistisk opplevelse av hvordan man som konsulent jobber i prosjekt, med viktigheten av kommunikasjon, forventningsstyring, koordinering, prioritering og hvordan eget arbeid påvirkes av andres. Thea beskriver dette som en av de viktigste erfaringene hun tar med seg fra perioden.
“Å jobbe i parallelle team og se hvordan et slikt samarbeid kan fungere, å faktisk oppleve at det ikke alltid går smidig eller blir helt sånn man hadde tenkt har jeg lært utrolig mye av.”
For best mulig prosessgjennomføring benyttet teamene scrum som metodikk. Med daglig standup, ukentlig sprintplanlegging, demo og retro sikret studentene evaluering og progresjon underveis i prosjektet. Likt for begge teamene var at de rullerte uke for uke på hvem som var Scrum Master, slik at de som ville fikk prøve seg på denne rollen. Av studentene jeg har pratet med mente samtlige at dette var relevant og lærerik erfaring å ta med seg, og Thea beskriver hva hun erfarte i rollen::
“Å få jobbe ordentlig etter scrum-metodikk har vært en stor forskjell fra studiehverdagen til arbeidslivet. Som student er det ikke mulig å benytte slike metodikker fordi det ikke er nok kontinuitet i prosjektene. Det var en øyeåpner å se hvor bra scrum faktisk fungerer — gøy å oppleve.“
Jannicke legger til:
“I en uke hadde jeg hovedansvar for at teamet fulgte arbeidsformen vi hadde blitt enige om, og så til at vi kommer oss gjennom oppgavene som er prioritert. Dette er første gang jeg har fått prøve meg som Scrum Master, så veldig gøy å få prøvd meg på den rollen.”
Gjennom hele internshipet var produkteier og flere konsulenter fra Dfind Consulting tilstede for å bistå og støtte studentene underveis. Dette bidro naturligvis til trygghet for studentene, samtidig som det ga synergier på bakgrunn av mangfoldet de sammen utgjorde. Både Thea, Jannicke og Ida beskriver dette som en av de største forskjellene mellom studiehverdagen og arbeidslivet, og som noe av den viktigste erfaringen de tar med seg.
“Det var en trygghet å ha erfarne konsulenter fra Dfind Consulting i ryggen. Det å ha noen å spørre og sparre med gjør det lettere å komme videre om man står fast.”
“Dette er er jo en bransje som utvikler seg veldig raskt, så det er gøy å få sparre med konsulenter som er aktive i rollen … Vi får både bruke teknologier som er veldig relevante i arbeidslivet òg prøvd oss på de i trygge miljøer.”
Som studentene påpeker har vi sørget for å ta i bruk moderne teknologi som gir studentene relevant og etterspurt erfaring. Mobilapplikasjonen, som Team App hadde ansvar for, var en quiz-løsning som lar brukerne spille quiz live. Applikasjonens frontend ble utviklet i React Native, mens det i backend ble brukt Firebase, hvor Firestore ble brukt som database og Firebase Authentication ble brukt til logg-inn. Det ble også laget Firebase functions, blant annet for å håndtere Push-notifikasjoner. For å lage og administrere innholdet i quizen ble en webløsning utviklet som Team Admin hadde ansvar for. Løsningen ble utviklet i React og hostet på Firebase hosting. Som vi gjorde med mobilapplikasjonen, brukte vi også Firebase som backend i webløsningen.
Basert på tilbakemeldinger fra Thea, Jannicke og Ida, og de andre sommerstudentene i Team App og Team Admin, kan vi trygt si at vi har lykkes i Dfind Consulting sitt første internship. Thea påpeker at vi har bidratt til at hun har funnet sin plass i IT-verden, og med den tilbakemeldingen kan vi ikke konkludere med annet enn at vi har skapt verdi og fått til noe mer enn bare å utvikle et produkt. Vi ser frem til samarbeid med flere sommerstudenter i årene som kommer!
“Jeg føler den viktigste erfaringen jeg tar med meg er at jeg har funnet min plass i et team, men også min plass i IT-verden. Jeg har skjønt at det er her jeg ønsker å være, dette jeg vil jobbe med fremover — at jeg har valgt riktig.“
Er du nysgjerrig på hvilke muligheter som finnes som student i Dfind Consulting? Ta en titt på våre studentsider <a href="https://www.dfindconsulting.no/jobb-hos-oss#internshipArticle">her</a> for å lese mer.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=9db3fd9222e4" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/dfind-consulting-internship-2022-9db3fd9222e4">Dfind Consulting — Internship 2022</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dfind Consulting — Internship 2022

Dfind Direction er vår satsning på ledelse, arkitektur og rådgiving, enkelt og greit.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*3-u42TfNnSpbbJV5Y8M7zw.jpeg"></figure><h3>Hvorfor?</h3>
Vel, først blir det litt historiefortelling. Det hele startet i 2016. Consulting så dagens lys og i løpet av 2017 hadde de første pionerene blitt med på skuta. Hovedvekten av konsulenter var utviklere selv om man også hadde prosjektledere og arkitekter i tillegg til UX og andre roller. Det har vært en god vekst i selskapet og når vi etter hvert nærmet oss og passerte 150 ansatte ble utfordringene tydeligere. Flesteparten av konsulenter og kunder kjente oss som et konsulentselskap med utviklere og det ble vanskelig å vise mot både kunder og potensielle nye kolleger at vi hadde mange andre bein å stå på. I tillegg så vi at det var forskjellige behov både avhengig av hvilken profil man har, men også også mtp. senioritet. Man er på forskjellige steder i livet rett og slett.
Dfind Direction ble etablert som vår satsning på ledelse, arkitektur og rådgiving med de av våre konsulenter som kjente seg igjen i denne beskrivelsen. Flere har blitt med siden den gang.
<h3>Hvorfor prosjektledere og arkitekter i samme gruppe?</h3>
I bunnen er vi IT-konsulenter alle sammen. Det vil si at vi er prosjektledere, produkteiere, scum mastere, team lead, tech leads og arkitekter i IT-prosjekter. Alle er tekniske i bunnen eller direkte i sin rolle.
I et samfunn som stadig blir digitalisert og hvor nye og kommende generasjoner er født digitale, vil flere og flere selskaper, organisasjoner og offentlige aktører ha alle sine prosesser digitalisert. Conways lov og prinsippet om at organisasjoner vil utvikle IT-systemer som gjenspeiler organisasjonen, viser oss at det er en særdeles sterk link mellom arkitektur og ledelse. På mange måter går de hånd i hånd og det er behov for lik kompetanse i begge leire.
Til sist vil jeg også poengtere at arkitekt og prosjektleder bare er paraplybetegnelser i mine øyne. De favner flere og mer definerte roller slik som jeg har forsøkt å illustrere under. Noen konsulenter har flere av disse hattene, mens noen har gjort et dypdykk ned i én. Det de har til felles er at det kreves en del erfaring og senioritet
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ErV5_5dCaAqwZm9glCx10A.png"></figure>Erfaringen vi har gjort oss i vekstperioden er at det er krevende å kombinere mange spesialiseringer i samme gruppe. Det er veldig mye man har til felles, men det er også en del unike og egne behov. Det krever et visst fokus og det krever muligheten til å gjøre ting annerledes. Med vår filosofi om autonomitet, selvstyre og et selskap bygget av og for konsulenter, er den naturlige tilnærmingen å starte opp en egen divisjon, så selvstyrt som mulig, og nesten som et eget selskap i selskapet.
<blockquote>Poenget er at det er må være fleksibelt nok til å forme seg i takt med konsulentene i selskapet.</blockquote>
På bakgrunn av alt dette ble Dfind Direction etablert. Vi jobber fortsatt med “å finne oss sjæl”. Dette er kontinuerlig arbeide og aller viktigst; det er noe vi gjør sammen.
<h3>Første strategisamling</h3>
Pandemien gjorde at vi ikke fikk startet slik vi ønsket så når høsten 2021 kom så vi vårt snitt til å samle alle i direction og gjennomføre den første strategisamlingen vår.
Målet var å finne ut hva Direction er for oss og hva som er de viktigste verdiene for alle som er med i Direction.
Workshoppen gikk som følger:
<h4>Halen på grisen, aka hvor er vi i markedet</h4>
For å skjønne litt mer om oss selv var det interessant og også se på andre. På den måten kan vi se hva som var unikt for oss, men også bekrefte enda litt tydeligere hvem vi er.
Vi startet med å definere to akser hvor den ene går fra teknologi til forretning og den andre fra rådgivende til implementerende. Deretter plassere vi oss selv og andre konsulentselskaper i denne matrisen. Det er ikke så interessant hvor andre er, men det vi oppdaget om oss selv er at vi vil være mer implementerende enn rådgivende når det gjelder forretning og mer rådgivende når det gjelder teknologi.
Det er ikke et veldig overraskende resultat for prosjektledere og arkitekter, men det er en fin måte å visualisere det på. Det er også mulig å snakke om hvor man er og hvor man vil være og utvikle en strategi for å bevege seg i den retningen man vil.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/796/1*Ns4Q_Xyp3Yg4MrQb2SNVTw.png"></figure>Her er noen eksempler på konsulentoppdrag og hvordan det ville plassert seg i matrisen
<ol>
<li>Rådgivende/teknologi: Teknisk revisjon</li>
<li>Teknologi/implementerende: Utvikler i et team</li>
<li>Implementerende/forretning: Forretningsutvikler eller produkteier</li>
<li>Forretning/Rådgiver: Markedsundersøkelse/rapport</li>
</ol>
De aller største selskapene har gjerne en fot i alle kvadranter og det blir sånn sett vanskelig å plassere de. Derfor havnet alle i midten
<blockquote>Et svært viktig prinsipp vi fikk ut av denne øvelsen er at de gangene vi har rådgivende roller eller er i en posisjon hvor vi blir spurt om å gi råd, så skal vi også være i stand til å implementere det vi snakker om.</blockquote>
<h4>Cover story</h4>
For å få brukt kreativiteten litt krydret vi med noen “klippe og lime” aktiviteter. Med “Cover story” skal man ha litt vyer og se for seg en tenkt avis eller magasinforside om 15 år. Det skrives om dere. Hva står det?
Gruppa klippet og limte med både hvitt og farget papir. Det ble mye forskjellig, men felles for de alle var at Dfind Direction skulle være et sted hvor folk ønsket å bli værende.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/526/1*CNH74xBBEI_uo3iqaKunrg.png"><figcaption>Et av bidragene</figcaption></figure><h4>Verdibrainstorming</h4>
Kanskje det viktigste aktiviteten for dagen. Den gjennomføres ganske enkelt som en brainstorming med påfølgende presentasjon og diskusjon før vi grupperer like lapper og til slutt stemmer på hva vi mener er viktigst.
For å fokusere på verdier hadde vi noen “knagger” man kunne bruke for å komme i gang:
<ul>
<li>Kollegaer og sosialt</li>
<li>Faglig innhold og utvikling</li>
<li>Verdier og holdninger</li>
<li>Roller og oppgaver</li>
<li>Bli motivert</li>
<li>Kompensasjon</li>
<li>Familie og venner</li>
</ul>
Vi fylte en vegg med post-it lapper og vell så det. I mylderet viste det seg etter hvert at det var noen områder som var viktige for alle sammen
Work/life: Mange har famile eller andre utenomsportslige aktiviteter. Vi ønsker en arbeidsplass som tilrettelegger for at vi yter og utvikler oss så godt som mulig
Fag: Faglig styrke er ikke bare en enorm styrke for selskap og kunde, det er også hvem vi er. Vår stolthet ligger i å gjøre en god jobb, designe gode systemer eller etablere vellykkede team og produkter. Om vi ikke kontinuelig utvikler oss og selv vil vi hverken trives eller lykkes.
Sosialt: Den store utfordringen for de fleste konsulentselskaper hvor vi er hos kunde store deler av dagen er å holde på et sterkt bånd med sine kollegaer. Dette er viktig for oss og vi må jobbe for å skape arenaer som legger til rette for dette.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/455/1*HEPFM5hPRbvyUCNskcohCQ.png"></figure>Til slutt snakket vi om sammenhengen mellom disse. Fag og sosialt må balanseres med work-life. Finner vi balansen mellom disse tre er vi på riktig vei
<h4>Product box</h4>
Den siste øvelsen vi gjorde på denne samlingen var også av det kreative slaget. Her skulle vi se for oss hvordan det hadde sett ut om en Dfind Direction hadde vært et produkt som ble levert i en boks. Hva trekker vi frem som unike egenskaper på innpakningen?
<figure><img alt="" src="https://cdn-images-1.medium.com/max/781/1*vYTha1EYNXavlzSe2rU2Tg.png"></figure>En fantastisk morsom øvelse hvor vi fikk brukt alle kvaliteter vi lærte oss på kunst og håndverk på ungdomsskolen. Skal vi trekke frem noen av de viktigste egenskapene ved Dfind Direction er det (1) Faglig styrke og kvalitet, (2) Familie og work-life balance, (3) likestilling og (4) levere det vi prater om.
Mange av de samme punktene gikk igjen gjennom alle øvelsene. Dette er mye fordi det etter hvert blir forankret i gruppa og gjentar seg selv av den grunn, men også fordi vi lykkes med å finne noe som er viktig for alle. Det er sånn vi skal utvikle oss i Direction. Det er høy kompetanse og folk med såpass lang erfaring at når vi legger hodene sammen så får vi det til.
<h4>Oppsummert</h4>
Om vi skal prøve å oppsummere det som er starten på en strategi for Direction ser det ca sånn ut.
<ul>
<li>Gir solide råd og veileder, men må kunne “walk the walk” og implementere det vi snakker om, både teknologi og prosess for teknologiutvikling.</li>
<li>Vi er sterke på teknologi, men også forretning, siden teknologi i større og større grad driver og definerer forretning og organisasjon</li>
<li>Dette er summen av Direction, hver enkelt konsulent har forskjellig kompetanse, men vi spiller på hverandre og utnytter hverandres kompetanse inn i prosjekt og problemløsning</li>
<li>Vi må legge til rette for fortsatt sterk faglig utvikling og sosialisering med kollegaer slik at det lar seg kombinere med disse andre viktige delene av livet. Og ikke minst gjør alt det andre lettere.</li>
</ul>
Direction har i dag blitt utvidet til alle Dfind Consulting sine kontorer og vi jobber med å definere oss selv som et nasjonalt nettverk på best mulig måte. Denne høsten ser vi på faglig utvikling så vi kan tilrettelegge for at både arkitekter og prosjektledere fortsetter med å styrke sin kompetanse på sine premisser.
Vi skal fortelle hvordan det har gått ved en senere anledning..
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=ea82454942b8" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/hva-er-dfind-direction-ea82454942b8">Hva er Dfind Direction?</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hva er Dfind Direction?

European Women in Tech er Europas største tech-arrangement for kvinner, og tar for seg temaer innen teknologi, ledelse og karriereutvikling. Etter to år med pandemi var en gjeng på femten ansatte fra Dfind Consulting sultne på kompetanseutvikling og networking — og dette fikk vi. Etter to inspirerende konferansedager med flere av techbransjens mest innflytelsesrike kvinner har vi plukket ut tre takeaways vi nå ønsker å dele med fler.
European Women in Tech fant sted på det velkjente konferansesenteret RAI midt i Amsterdam. Konferansen gjestet over 250 speakers, hadde over 250 sesjoner og workshops, og over 4000 deltakere.
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*x5OL_HU_PGVA2bEyGJV9xg.jpeg"><figcaption>Dfind Consulting på European Women in Tech 2022</figcaption></figure>Den viktigste kompetansen vi tar med oss og ønsker å belyse:
<h4>Rollemodeller</h4>
Et av de mest fremmende tiltakene for å øke kvinneandelen i techbransjen er å eksponere unge jenter for rollemodeller som inspirerer og viser at det er mulig å få en spennende karriere innen teknologi.
Microsoft gjennomførte en studie med flere enn seks tusen kvinnelige deltakere i alderen ti til tretti år. Av studien fremkom det at interessen for STEM (science, technology, engineering, mathematics) nesten dobles når de har en rollemodell som inspirerer dem, hvor foreldre og lærere her ble trukket frem som aktuelle rollemodeller. Studien viste at sannsynligheten for at jenter vil studere datateknologi og informatikk øker med 81 % dersom en forelder oppmuntrer til en STEM-utdannelse, sammenlignet med en som ikke oppmuntres.
I stor grad handler det om å i det hele tatt prate om og kommunisere STEM som et alternativ til valg av studieretning, og samtidig bryte tabuer om at jenter ikke mestrer realfag like godt som gutter. Studien viser at 91 % av unge jenter regner seg selv som kreative, og at hele 72 % ønsker arbeid som hjelper verden. Vi som jobber i bransjen vet jo hvor fantastisk store muligheter det er for kreativ utfoldelse og arbeid med samfunnsnyttige løsninger — dette må prates om! Vi må bidra til økt bevissthet og kunnskap rundt de faktiske mulighetene som finnes ved å jobbe i techbransjen. “If you cannot see it, you cannot be it”. For at foreldre og lærere skal kunne være gode rollemodeller, må også vi som arbeider i bransjen ta ansvar og være rollemodeller gjennom kompetansedeling og bevisstgjøring.
<h4>Bias i kunstig intelligens (AI)</h4>
Bias i AI er et reelt problem med potensielle alvorlige konsekvenser. Algoritmer er ikke objektive, men virker ut fra det som defineres av den som lager algoritmen. Det er sannsynlig at vi mennesker tar med oss våre biaser inn i koden. Samtidig vil også datagrunnlaget som algoritmen lærer av og baserer sine resultater på, kunne ta med seg biaser. Dette er to viktige faktorer til at bias i AI forekommer i utgangspunktet.
“One size doesn’t fit all”. Techbransjen må være en sann representasjon av mangfoldet som finnes i samfunnet, slik at mangfoldet også blir representert når ny teknologi utvikles. Konsekvensene av en teknologisk utvikling som ikke er representativ sees allerede, som ved talegjenkjenning som ikke gjenkjenner pronomenet “hers”, men gjenkjenner “his”. Eller ansiktsgjenkjennings-programvarer som ikke klarer å skille personer med mørk hud.
Vi har fortsatt en vei å gå innenfor teknologi for å unngå bias i AI. Mye av følgene som sees er skapt av manglende mangfold eller allerede samfunnsdefinerte forutantakelser. Ved å tilføre mer mangfold og ikke minst ta høyde for at bias i AI kan og vil oppstå er vi allerede et stykke på vei for å unngå konsekvensene det kan få.
For mer informasjon og flere tips til hvordan vi unngår bias i AI, les innlegget European Women in Tech har postet om tematikken: <a href="https://www.europeanwomenintech.com/blog/bias-in-ai">https://www.europeanwomenintech.com/blog/bias-in-ai</a>
<h4>“Claim your space!”</h4>
En siste og generell oppfordring vi tok med oss og mener er viktig å bringe videre, er å våge å ta plass og ta kontroll over egen karriere. Dette var en fellesnevner ved flere av foredragene, og samtlige av foredragsholderne delte sine historier om hvordan deres karriere skjøt fart eller endret kurs den dagen de tok et valg om å ta plass.
Snakk høyt om egne ambisjoner, fremhev og vis hva du kan. Vit din verdi og be om det du fortjener, med en antagelse om at ingen kommer til å gi deg noe gratis. Det handler om å synliggjøre seg selv og vise hva du er god for. Hvordan skal ellers din leder eller mentor kunne støtte deg og påvirke din faglige og personlige utvikling for å nå dine karrieremål?
Delta i og inkluder alle i diskusjonen. Prat med de med andre synspunkter enn deg selv, også de personene du vet du får en utfordrende samtale med, eller den som vanligvis ikke inkluderes i diskusjonen. Med en oppriktig nysgjerrighet overfor alle perspektiver utvikler du deg. Å skape nettverk som både inkluderer de som kan støtte, rådgi og utfordre deg kan åpne fantastiske utviklings- og karrieremuligheter. Ved å tørre å ta denne plassen, fremme egne meninger og kompetanse samtidig som andre også inkluderes, skapes perspektivbevegelighet og synergier. Det skaper en arena for å selv kunne utvikle seg og motta andres respons.
Med det håper vi å ha inspirert flere kvinner og menn der ute til å være gode rollemodeller og utfordre seg selv til å ta litt større plass. Vi mener at European Women in Tech-konferansen er like relevant for menn som kvinner, og oppfordrer alle menn til å engasjere seg på tilsvarende arrangementer, selv om det inkluderer “women” eller “kvinner” i tittelen. Som vi nå har presisert — hvordan skal kompetansedeling og endring skje om ikke alle inkluderes i diskusjonen og kunnskapsdelingen? Vi i Dfind Consulting fortsetter i hvertfall vårt arbeid med å dele kompetanse, og håper vi har bidratt til å belyse viktigheten av mangfold i techbransjen.
<img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=d3cc717610e8" width="1" height="1" alt=""><hr>
<a href="https://medium.com/dfind-consulting/european-women-in-tech-2022-tre-takeaways-d3cc717610e8">European Women in Tech 2022 - Tre takeaways</a> was originally published in <a href="https://medium.com/dfind-consulting">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

European Women in Tech 2022 - Tre takeaways

dsjdsjjd

\n<figure><img alt=\"\" src=\"https://cdn-images-1.medium.com/max/1024/1*nbN27RdqN2KqpTZGCjWUAA.jpeg\"><figcaption>Think of a static website as if we were sitting at a sushi belt in a restaurant. Instead of waiting for the good pieces to come past use at our seat, we can choose precisely the sushi pieces we want right away, ready served. Photo by: <a href=\"https://unsplash.com/@kyleunderscorehead\">https://unsplash.com/@kyleunderscorehead</a></figcaption></figure>Single-Page Applications (SPA’s, or dynamic) and server-based, also called Server Side Rendered (SSR) applications, are probably the most popular ways to create websites these days. But also Static Site Generation (SSG) has become very popular in the past years.\nWhen we need a fast, simple, secure, and cheap website, our next project should be using Static Site Generation.\n<h3>Static vs. dynamic websites</h3>\nTo begin with, we should clear up what the main differences between a static generated website and dynamic websites are:\nA static website is pre-built (on the server) and fetched once on the client without a server.\n<ul><li>Static-generated sites are just a bunch of HTML files. The site may be updated and re-build when publishing new content through a Content Delivery Network (CDN) or when pushing new features. With static site generation, websites become fast; they are easy to publish and secure! We will drill deeper into these benefits later on.</li></ul>\nA dynamic website is when files are changed on the server and fetched on the client on each change.\n<ul><li>Dynamic sites consist of a backend with servers and databases. The site’s content changes dynamically and needs to interact with a database to generate the files “on the fly.” Also, the site needs to fetch the content every time someone revisits the site. Dynamic sites are harder to maintain and less reliable.</li></ul>\n<h3>Benefits of Static Site Generation</h3>\nDynamic and statically generated websites are suitable for different types of applications. Static Generation has unique features for creating a website with few dependencies, and suites better when meeting business goals is crucial.\nWe will look at eight benefits that SSG provide, whereas dynamic websites are not quite as good:\n<h4>No need for a backend developer</h4>\nWe won’t need a backend developer to make an SSG website. Content Administrators and Writers can maintain a Content Management System that stores and have manageable content. Also, a Content Delivery Network (CDN) is a great place to upload our static files.\n<h4>Better reliability</h4>\nWe won’t receive irritating error messages like “500 Internal Server Error.” on an SSG website. The only possible time we will get errors is when the hosting provider gets issues, which rarely happens. Besides that, our website will not have downtime or be unavailable. We will also not need to worry about dynamically scaling our servers or databases.\n<h4>Simplicity</h4>\nWith Static Site Generation comes simplicity. They require no servers or databases. Some JavaScript frameworks, like React-based ones NextJS or GatsbyJS and SvelteJS, provide build-in support and help us generate, minify, and bundle static HTML files at build time. The static files can easily change or move from one hosting service to another.\n<h4>Performance</h4>\nStatic Site Generation gives excellent performance and is fast. We won’t need to wait for many spinners [or skeletons] to tell the user that something is on the way and will replace it at some point.\nThink of a static website as if we were sitting at a sushi belt in a restaurant. Instead of waiting for the good pieces to come past use at our seat, we can choose precisely the sushi pieces we want right away, ready served.\n<h4>Security</h4>\nWe will have excellent security since we don’t need a database or servers running, and they are vulnerable to security breaches. Compilation of source code and content ahead of time (AoT) makes it impossible for hackers to access our databases, CMS, or servers. Since there are no servers involved, the site is also more resilient to DDoS attacks.\n<h4>Lower costs</h4>\nWe may choose to upload our static content to services like Netlify, Vercel, Amazon S3, Google Cloud Platform, and Microsoft Azure; these services are also entirely free. Hosting static content is cheap and requires less bandwidth. And since our site will be less vulnerable to security breaches, we may use that left-over-money for other essential business goals instead of thinking of security monitoring.\n<h4>Improved SEO</h4>\nDynamic sites can be complex when we want to optimize our website for search engines. And if it’s crucial for our site and content. The most common problems with dynamic sites are that these are fast at first page-load, but most critical content is fetched and displayed asynchronously.\nWe get well-optimized content for SEO with pre-rendered content and fast page load. Good SEO optimization will give a low or decreased “bounce rate,” which is the proportion of visitors leaving the website. It also improves search traffic, better lead generation, and customer engagement.\n<h4>Scalability</h4>\nStatic Site Generation provides excellent scalability; we cannot always say the same with dynamic sites. So let’s take a scenario where we may have scalability issues with a dynamic site:\n<ul><li>We have a website that a few visitors typically use. At one point (maybe just a few minutes), the site can be used by thousands of users simultaneously. Maybe we’ve published something that has gone viral — such as news — or a DDoS attack. Such an event can be costly, grow rapidly in volume and take down our servers in the worst case. Such events can cause an unexpectedly large number of server requests and will potentially generate dynamic content for each of the thousands of unexpected users.</li></ul>\nStatic content and SSG are different: The website is pre-generated, with styles and content. Users only need to download the page’s content that they are visiting.\n<h3>Conclusion</h3>\nWe should use Static Site Generation when making a blog, landing page, newspaper, hotel booking service, or e-commerce store. On some occasions, we may even combine dynamic and static content, where our public pages as static pre-rendered content and internal or user-oriented pages are dynamic.\nWhen running an online newspaper, combing dynamic and static content might be a good choice. The front pages can be of static content presented on the page to the users as soon as they enter, with main headlines and images, and videos can have a generated GIF instead of loading in a preview. Articles can then be fetched by an identifier (id) in the URL and rendered in a separate application or on a different route on the website that dynamically retrieves the content.\nStatic Site Generation should be considered over dynamic SPA’s if any of the abovementioned points are crucial for our organization, whether costs, user experience, or performance.\nThanks for reading!\nCode foh shizzle\n<img src=\"https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=5fb187d1ffe6\" width=\"1\" height=\"1\" alt=\"\"><hr>\n<a href=\"https://medium.com/dfind-consulting/benefits-of-static-websites-5fb187d1ffe6\">Benefits of Static Site Generation</a> was originally published in <a href=\"https://medium.com/dfind-consulting\">Dfind Consulting</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.\n

Benefits of Static Site Generation

Nysgjerrige folk med forskjellig kompetanse gir nye perspektiver og styrker oss som selskap. Du bør ha relevant utdanning og minimum 3 års erfaring som utvikler, designer, arkitekt eller prosjektleder. Bli med på laget!

Bli en av oss banner

– Fantastisk å kunne bytte prosjekt uten å måtte bytte arbeidsgiver

Systemutvikler Peder Thorup har aldri angret på at han ble konsulent. Spennende kunder, varierte dager og gode kolleger er noe av det som bidrar til at han trives så godt i rollen.

– Jeg har alltid vært interessert i datamaskiner og problemløsning generelt. Samtidig er jeg nok både tålmodig og analytisk, og den kombinasjonen er nok grei å ha med seg hvis man skal være systemutvikler, sier Peder Thorup.
30-åringen var ferdig utdannet i 2016, og har siden jobbet som konsulent. Dét stortrives han med - ikke minst takket være spennende oppdrag hvor utfordringene er mange og ingen arbeidsdager er like.
Nå for tiden er Dfind Consulting-konsulenten utleid til et prosjekt for Finn.no. Kort fortalt jobbes det med fornying av annonsene i nyboligsegmentet.
–Det er et spennende prosjekt hvor vi jobber i et veldig autonomt utviklerteam. Det er også veldig gøy at det man lager blir sett og brukt av mange mennesker, påpeker han.
Det sammensatte prosjektet fører ifølge Thorup også til svært varierte arbeidsdager.
– Vi jobber hele tiden mot nye lanseringer av nye tjenester og løsninger, men det er jo selvfølgelig også litt forvaltningsarbeid fra dag til dag, forklarer han.

- En del tenker nok at man kan føle seg litt alene som konsulent, men slik er det absolutt ikke. Vi jobber i stor grad i team, og man har mye kontakt både med kunder og andre internt i Dfind Consulting.

I tillegg til variasjon i selve oppgavene, har det utvilsomt også vært stor forskjell på prosjektene han hittil har vært involvert i.
Tidligere har han vært utleid til blant andre Eika Gruppen og Statens Pensjonskasse Hos sistnevnte jobbet han med systemet som beregner pensjonen for alle offentlig ansatte.
– Det var et tungt domene å sette seg inn i. Pensjon er et komplisert tema i seg selv, og i tillegg må man følge utviklingen av endringer i pensjonslovverket. Den ble man heldigvis kurset og fikk mye ny kunnskap både før og underveis i prosjektet, sier han.
I forbindelse med prosjektet var både advokater og en rekke prosjektledere involvert, og oppgavene var kort fortalt langt fra det han nå jobber med i Finn.
– Fellesnevneren mellom de to prosjektene er at det er spennende og givende å være med på. Man jobber med noe som kommer mange til nytte, sier Thorup.

På spørsmål om han ved prosjektslutt synes det er vemodig å forlate teamet han er utstasjonert hos, svarer han følgende:
– Det er veldig vemodig å forlate teamet man har sittet på. Slik er det jo også ellers i arbeidslivet, og på den måten er ikke dette noe unikt for oss konsulenter, sier Thorup og fortsetter.
– For øvrig var nettopp dette en av grunnene til at jeg valgte å bli konsulent. Det er jo fantastisk å kunne bytte prosjekt uten å måtte bytte arbeidsgiver, legger han engasjert til.
Thorup trekker også frem andre fordeler ved jobben som systemutviklerkonsulent.
– Læringskurven er ofte bratt, spesielt i begynnelsen av nye prosjekter. Fordi man ofte får være med på flere prosjekter enn interne utviklere, får man gjerne også oppleve denne bratte læringskurven. Videre får man sett veldig mye på relativt kort tid, og i tillegg er oppgavene veldig varierte. Det er dessuten alltids spennende at man ikke er helt sikker på hva neste prosjekt blir.

Han er riktignok er på ingen måte «redd» for hva som venter rundt neste sving når et prosjekt nærmer seg slutten.
– I Dfind Consulting kan man være helt sikker på at også neste oppdrag er spennende å ta fatt på. Variasjonen, kombinert med interessante kunder, gjør at jeg har det veldig godt som konsulent her, sier han.
Han skryter ellers av Dfind Consulting for godt miljø, dyktig ledelse og en sterk sosialkomité. Ifølge Thorup er det «veldig god takhøyde» både for å foreslå og å få gjennomført sammenkomster av ulike slag.
– En del tenker nok at man kan føle seg litt alene som konsulent, men slik er det absolutt ikke. Vi jobber i stor grad i team, og man har mye kontakt både med kunder og andre internt i Dfind Consulting. Når man på toppen får det sosiale, er det ingenting som tilsier at det skal bli ensomt, avslutter han.

Møt en utvikler artikkel

Systemutvikling

UX Design

Prosjektledelse

Systemarkitektur

Møt en X banner

Utvikler

Holder trådene samlet i spennende gigantprosjekt

Lars Martin Riiser Haraldsen var ikke «så dyktig som de andre» på å utvikle. Så valgte han å sy sammen kommunikasjons- og utviklerferdigheter - og ble prosjektleder.

– Helt fra dag én ønsket jeg å ta steget til prosjektleder. Det virket veldig spennende å være et bindeledd mellom kunden og utviklerne, og å få bruke ferdigheter innen både utvikling óg kommunikasjon, sier Lars Martin Riiser Haraldsen og fortsetter.
– Dessuten innså jeg nok at jeg ikke var like dyktig på å utvikle som mange av de andre var, legger han til med et smil.
Selv om han sier det med en spøkefull tone, står sivilingeniøren på at dette faktisk var noe av årsaken til at han tok valget om å satse som prosjektleder.
– Ettersom det ikke var så enkelt, måtte jeg gjennom noen år som utvikler og sertifiseringer - noe som i senere tid har vist seg å være en god ting. Det førte til at jeg tilegnet meg kunnskaper og mer teknisk kompetanse enn mange andre prosjektledere, sier han.
Det skulle vise seg å være helt riktig å følge magefølelsen om å bli prosjektleder – og konsulent. Han har nå vært i jobben i fire-fem år - og stortrives.
– Man får oppleve veldig mye spennende, sier han.

- Helt fra dag én ønsket jeg å ta steget til prosjektleder. Det virket veldig spennende å være et bindeledd mellom kunden og utviklerne, og å få bruke ferdigheter innen både utvikling óg kommunikasjon

Dfind Consulting-prosjektlederen forklarer at jobben kort fortalt går ut på å sørge for god prosess – helt fra start til slutt.
– Min hovedoppgave er jo å levere arbeid av god kvalitet til gitte datoer, sier han.
Dette innebærer blant annet å sørge for at de ulike teamene til enhver tid er i rute med gitte oppgaver.
– Og er det noe som ikke går helt på skinner, er det da min oppgave å ha fortløpende dialog og diskusjon med alle involverte, sier han og fortsetter.
– Målet er at teamet skal være så selvdrevet som mulig. På den måten kan du egentlig si at jo bedre ting fungerer, jo mindre behov er det for meg, sier en lattermildt Haraldsen - før han understreker at hverdagen som konsulent i Dfind Consulting er både travle óg spennende.

Haraldsen har jobbet som prosjektleder i Dfind Consulting siden 2018, og på disse årene er det nemlig ikke småtteri han har fått være med på.
– Jeg har fått jobbe med veldig spennende prosjekter på oppdrag fra Digitaliseringsdirektoratet. I det siste prosjektet, som vi startet på i midten av 2020, jobber vi med en portal som skal gjøre arveoppgjør enklere for folk, sier han.
Mens dette i dag innebærer lange og tunge papirprosesser og involverer en rekke aktører, samles dette nå i en felles portal.
– Prosjektet innebærer mye tverrfaglig jobbing og en rekke juridiske prosesser, hvilket er både interessant, komplisert og lærerikt på én gang. I tillegg er det jo givende å vite at det man gjør bidrar til å bistå mange i en vanskelig situasjon - som arveoppgjør gjerne er, sier Haraldsen.

Planen er ifølge Haraldsen at den nye portalen for arveoppgjør skal lanseres i 2022.
Hvor lenge han blir utleid som konsulent til Digitaliseringsdirektoratet, vet han ikke. Riktignok er det heller ikke noe han tilsynelatende bruker mye tid på å tenke på.
– Som prosjektlederkonsulent får man jo et nært forhold til kundene. De blir jo en form for kolleger. «Ulempen» er at det kan være litt trist å dra fra dem, sier Haraldsen.
Han er riktignok ikke i tvil om at dette mildt sagt kommer i skyggen av fordelene ved det å være prosjektlederkonsulent.
– Man får unike muligheter til å bygge nettverk. Som prosjektleder får man også nye team og med det følger variasjon og nye, spennende utfordringer. Hvert team er jo forskjellig, sier han.
– Dessuten har jeg på toppen av dette et veldig godt forhold til både kolleger og ledelse i Dfind Consulting. Vi er et veldig godt eksempel på flat lederstruktur, og miljøet generelt er veldig bra, avslutter han.

Møt en prosjektleder artikkel

Prosjektleder

Opplever større mening og sterkere eierskap i jobben som konsulent

Mens hun tidligere jobbet noen timer med hver oppgave, er UX-designer Anniken Carson Engesvik nå på samme prosjekt i lang tid. Dét har gitt en helt annen jobbhverdag.

Etter å ha fullført bachelorgraden i grafisk design ved Norges Kreative Fagskole, jobbet Anniken Carson Engesvik tre år som designer i reklamebransjen.
Etter hvert lokket riktignok ønsket om større grad av brukerinvolvering i designprosessen. Med etterutdanning som interaksjonsdesigner i sekken, ventet konsulentstilling. Dét skulle vise seg å være midt i blinken.
– Jeg er veldig fornøyd med at jeg gikk den veien. Som ansatt i reklamebransjen fikk vi ofte veldig korte tidsfrister. Nå derimot, er jeg gjerne på samme prosjekt i et helt år. Da får man testet produktet, slik at man er sikker på at det fungerer - før lansering, sier hun og fortsetter.
–Dette gir meg et større eierskap til det jeg leverer, og det ingen tvil om at man som konsulent får jobbe med prosjekter som derfor føles litt mer meningsfulle.

– Mange tenker nok at vi designere først og fremst pynter, men jobben vår handler om ganske mye mer enn det

I løpet av de fire årene hun har jobbet som UX-designer, har hun jobbet med Jernbanedirektoratet, Luftfartstilsynet, Santander og Storebrand.
– Jeg har blant annet fått være med på å være digital rådgiver for en låneagent som hjelper folk bort fra forbrukslån. Da føler man at man er med på å bidra til å hjelpe folk ut av en vanskelig situasjon, ved å sørge for at de virkelig forstår tjenesten de benytter seg av og føler seg ivaretatt. Slike prosjekter er naturligvis svært givende å få være en del av, sier Engesvik.
I både dette og andre prosjekter har hun hele veien jobbet tett med resten av teamet – og også kunden selv.
– Mange tenker nok at vi designere først og fremst pynter, men jobben vår handler om ganske mye mer enn det, sier Anniken og smiler.
– Vår rolle handler også veldig mye om å se brukermønstre. Vi må sette oss inn i hvordan folk tenker når de for eksempel navigerer i en app, og hvordan de bruker appen i ulike hverdagssituasjoner. Kan den for eksempel brukes samtidig som de har en baby på armen? Kan du lese teksten på nettsiden når du er ute i sola, og lyset er helt annerledes enn inne? Det er mye psykologi og mange faktorer man må tenke på bak de produktene vi lager, legger hun til.
– Har vi gjort jobben vår godt nok, merker du det ikke når du bruker produktet. Da er det smertefritt.

Både hun og de andre konsulentene jobber vanligvis veldig tett på kundene, og Engesviks erfaring er at samarbeidet fungerer svært godt.
– Det er jo en grunn til at kunden ønsker seg konsulentbistand, de har et behov. Derfor er de også veldig åpne og lydhøre med tanke på våre innspill, sier hun.
Mens hun i reklamebyrå ofte opplevde det som vanskelig å få tak i hva kunden ønsket og hvorfor, er dette nå helt motsatt.
– Man er som sagt gjerne utleid i lang tid. Da rekker man å bli godt kjent med både kunden, produktet og bransjen. Dette gir naturligvis en mye bedre helhetsforståelse. Som en bonus får man jo verdifull erfaring man tar med seg videre til andre prosjekter, avslutter hun.

Møt en designer artikkel

Designer

Møt en designer

– Som konsulent rekker jeg ikke å bli utålmodig

Tommy Svendsen kunne endt opp som fisker, men hoppet etter hvert over på IT-utdanning. Også det har gitt god fangst – i form av spennende arkitektoppdrag for store kunder.
– Jeg har jo egentlig en litt spesiell bakgrunn. Som 16-åring ble jeg fisker og senere maritimt utdannet med sertifikat på skip. Jeg stortrivdes på havet, men etter hvert fristet det nok med litt andre rammer. Valget falt på IT-utdanning i Alta, forklarer Tommy Svendsen.
Det er nå over 15 år siden han var ferdig på skolebenken ved Høyskolen i Finnmark. Ifølge ham selv har han på ingen måte angret på at han valgte å nettopp den veien.
Det har nemlig ført til en rekke spennende arbeidsdager, ikke minst nå – i rollen som arkitektkonsulent i Dfind Consulting.
– Når man har vært en del år i bransjen, er det ofte naturlig å ta steget videre som prosjektleder eller arkitekt. For meg falt valget på det siste, og det er jeg glad for, sier han og fortsetter.
– Jeg stortrives med utfordringene som ligger i det å omforme forretningsmessige behov til tekniske løsninger.

– Jeg stortrives med utfordringene som ligger i det å omforme forretningsmessige behov til tekniske løsninger.

Svendsen forklarer videre at hovedoppgaven ofte går ut på å få en oversikt over dagens løsninger, og hvordan kunden per i dag har løst domeneproblematikken.
– Videre blir vi enig med med forretningsledelsen om et målbilde, og ut fra dette settes det opp et veikart for veien videre, forklarer han.
Og det er ikke småtteri han får være med på. Svendsen var blant annet én av to som tegnet opp hele den avanserte arkitekturen i KLP. Prosjektet vakte såpass oppsikt at han ble invitert til å holde foredrag på Java Zone.
– På samme tid hadde The Guardian brukt en tilsvarende løsning, noe som indikerte at det vi gjorde var fremtidsrettet og riktig, sier Svendsen.
Han har også jobbet med Deichman i Bjørvika, hvor det oppskaleres fra 120.000 til over 2 millioner årlige brukere – uten at de ansetter flere ressurser.

Ifølge arkitektkonsulenten har han ingen planer om å bytte beite.
– Jeg liker utfordringer - og ikke minst følelsen av at man bidrar til å utgjøre en forskjell for folk, sier Svendsen.
Han poengterer også han mener man som konsulent minimerer sjansen for å føle at man stagnerer eller blir lei av jobben.
– Jeg kan nok bli litt utålmodig i jobben etter et par, tre år. Konsulentrollen passer meg derfor helt utmerket, fordi man jevnlig får nye utfordringer og oppdrag.Som konsulent rekker jeg med andre ord ikke å bli utålmodig, sier han engasjert.
Ifølge ham selv øker dessuten trivselen i takt med erfaringen han tilegner seg gjennom ulike prosjekter.
– Når man går fra et prosjekt til et annet, har man gjerne fått med seg masse relevant erfaring som den nye kunden ikke selv besitter. Det er veldig givende å oppleve den takknemligheten man da gjerne møter.

Svendsen er ofte leid ut minst seks måneder av gangen - gjerne med opsjon på forlengelse. Stort sett hele perioden tilbringes ute hos kunde.
På den måten er man som konsulent ofte relativt «ny på jobben» og med lite hverdagskontakt med egne kolleger. Likevel føler han seg på ingen måte ensom eller alene i jobben.
– I Dfind Consulting er det sterkt fokus på trivsel og godt miljø. Som en del av dette har vi et eget årshjul med masse aktiviteter, blant annet kickoff, spillkvelder og så videre, sier han og fortsetter:
– Dette er noe som settes stor pris på. Selv da vi arrangerte digital lønningspils møtte 46 av 100 ansatte opp, og det sier vel sitt om miljøet, avslutter Svendsen med et smil.

Møt en arkitekt artikkel

Les historier fra hvordan arbeidet som arkitekt er hos oss.

Truls

Arkitekt

Møt en arkitekt

Vi jobber med brukeropplevelser (UX), systemutvikling, prosjektledelse, rådgivning og arkitektur.

lysgraa

Jon Wiklund Didriksen

DC Studio

Jens Kristian Tøraasen

DC Skolen

morkskumring

Konsulent 1

JAVA

Konsulent 2

.NET

Konsulent 3

Frontend

Programmering

mellomblaa

Nettverksleder

Plattform og sikkerhet

DevOps

Power Platform

Bug leader

This element disturbs everything!

Stian Berntsen

primaerorange

Data platform

Datascience

Analyse

Andre Orten

Data & Insight

irrgronn

Prosjekt

Rådgivning

Ledelse

lysrosa

Tjeneste

Interaksjon

Grafisk

Bug Leader

Second Element That Breaks everything

Eirik Gihle

Fagsjef

Fagorganisering

Hva vi kan

Hva vi kan - Dfind Consulting

I dag kreves det kontinuerlig nye funksjoner i applikasjoner for å være konkurransedyktige, derfor er vi en smart samarbeidspartner som innehar kompetanse innen flere ulike frontend rammeverk, kunstig intelligent, maskinlæring, skytjenester, DevOps og solid backend kompetanse.

Systemutvikling Banner

Våre designere lytter og utvikler krav basert på innsikt, lager prototyper, tester og itererer til tjenesten tilfredsstiller brukeren og bedriftens krav. Vi jobber tverrfaglig med grafisk-, tjeneste- og interaksjonsdesignere for å lage løsninger med høy brukskvalitet og gode bruksopplevelser.

Design Banner

Et digitalt produkt skal fungere på flere platformer og enheter uten at kunden opplever at kvaliteten forringes. Det krever derfor god prosjektledelse som ser helheten og samtidig de enkelte komponentene i et utviklingsmiljø.

Prosjektledelse Banner

Våre arkitekter ser helheten i infrastrukturen og sørger for at en agil utviklingsprosess kan gå så smertefritt som mulig. De beskriver hvordan ulike tjenester og produkter samhandler best mulig for å oppnå ønsket mål, uten nedetid for øvrige funksjoner.

Systemarkitektur Banner

Vi elsker teknologi og løsninger vi kan lage for både den private og offentlige sektor. I dag kreves det kontinuerlig nye funksjoner i applikasjoner for å være konkurransedyktige derfor er vi en smart samarbeidspartner som innehar kompetanse innen flere ulike frontend rammeverk, kunstig inteligens, maskinlæring, skytjenester, DevOps og solid backend kompetanse.

Hos Dfind Consulting finner du noen av markedets råeste konsulenter. Vi har sertifiseringer på rammeverk som React, Apache, Kafka og Spring Integration og skyplattformene Azure, Google Cloud og Kafka. Hos oss kan du få spesialtilpassede team eller enkeltkonulent for å møte dine tekniske behov. Vi har konsulenter i de store tunge xxx-miljøene og i de som liværer seg på mobilapplikajsoner. Sammen med våre kunder skaper vi alt fra selvbetjeningsløsninger, mobilapplikasjoner, ....etcet... Vi jobber i Java, .Net, etcetc... og bruker åpne kildekoder ved hjelp av ulike rammeverk alt etter kundens behov. Det viktigste for oss er at du som kunde skal være sikker og trygg på at du alltid får den best tilgjenglige kompetansen for å svare på dine behov.
Her jobbes det med tekst

Info kort

Test

UX design handler om totalopplevelsen en bruker har i et møte med en digital tjeneste, system eller produkt. 

Vi har grafisk- og interaksjonsdesignere men mange års erfaring. Våre designere lytter og utvikler krav basert på innsikt, lager prototyper, tester og itererer til tjenesten tilfredsstiller brukerens krav, bedriftens krav og tilgjengelig teknologi. 

Design og brukervennlighet

Universell utforming sikrer ikke bare at alle kan delta, det kan også bidra til å øke hastigheten på siden, bedre SEO og gjøre kundeopplevelsen bedre for alle.


Universel Utforming

Brukergrensesnitt

Våre prosjektledere/teamledere fungerer som rådgivere for våre partnere.Vårt mål er å avdekke behov som reduserer risiko og lager løsninger for fremtiden samt sikre at prosjektene kommer vel i havn. Effektivisering, rasjonalisering og forenkling er viktige ord i en utviklingsprosess hvor man streber etter kontinuerlige forbedringer. Vi er smidige og tilpasser oss våre kunders behov og skalerer prosjektene ut fra omgivelsene, ekisterende rammeverk og krav. Vi er oppdatert og kjenner til ulike metoder som passer best til forutsetningene, om man sikter mot en MVP som skal ittereres eller et rammeverk som skal forvaltes på en hensiktsmessig måte. Våre konsulenter ser helheten i systemporteføljen og sikrer god informasjonsflyt mellom de involverte parter.

Prosjektledelse og rådgiving

Agil prosjektledelse

Scrum

En systemarkitekt sørger for at en utviklingsprosess tar hensyn til allrede eksisterende infrastruktur og hvordan ulike tjenester og produkter samhandler best mulig for å oppnå ønsket mål.

En systemarkitekt finner løsninger som er tilpasset ulike interesser og behov. Det er sjelden man kan lage frittstående komponenter uten å tenke på helheten og hvor komponenten skal samarbeide med eksisterende eller fremtidige løsninnger. Endringer ett sted kan gi ringvirkninger ett annet. Når man jobber agilt med kontinuerlige endringer/iterasjoner, må man tilrettelege for dette. En agil utviklingsprosess er ikke strømlinjeformet fra start til ferdig leveranse. Våre arkitekter ser helheten i infrastrukturen og sørger for at en agil utviklingsprosess kan gå så smertefritt som mulig. En arktiekt kan beskrive hvordan ulike tjenester og produkter samhandler best mulig for å oppnå ønsket mål, uten nedetid for øvrige funksjoner. Kontinuerlig utvikling vil si at man aldri er ferdig men jobber kontinuerlig for å forbedre, forvalte og tilrettelegge for nye tjenester som måtte komme.