Etabler en samarbeidsmodell

En veldefinert og strukturert samarbeidsmodell står sentralt i effektiv drift av et avsamlet team. Denne delen tar hensyn til faktorer som kan bidra til at dette lykkes, for eksempel veldefinerte roller og ansvar, en strukturert forretningsforbindelse, pålitelige kommunikasjonskanaler og en tilgjengelig dokumentasjonsportal.

Definer roller og ansvar

For å skape et effektivt fusjonsteam må du først etablere klare roller og ansvar. Det viktigste er å starte i det små og bare innføre flere roller og personell når det er nødvendig. Bruk mindre mål for å bygge videre på suksess og demonstrere verdien av fusjonsteammodellen før du prøver mer ambisiøse prosjekter.

Som et minimum bør teamet inkludere følgende personell og roller:

• Produkteieren – vanligvis er dette personen som har som oppgave å sikre at prosjektene lykkes. Han eller hun definerer også det klare og attraktive formålet, eller kan komme til å utvikle denne visjonen sammen med resten av teamet.
• Domeneeksperten – dette er teamets forretningskyndige medlem som forstår og kan forme både utfordringen og løsningen. Med tanke på tilnærmingen med Power Apps-lavkode bør han eller hun kunne få mest mulig ut av å opprette denne løsningen.
• Den profesjonelle utvikleren – "Pro Dev" tar løsningen fra domeneeksperten og gir den nok kodingsstøtte til at den kan levere den tiltenkte funksjonaliteten (og ikke noe mer) om nødvendig.
• Administratoren – dette teammedlemmet forenkler integrerings- og støttescenarioer, og tar samtidig hånd om administrative tjenester i bakgrunnen. Eventuell ytterligere støtte i form av tid og ekspertise som kjerneteamet krever, kan hentes inn på fleksibelt grunnlag i stedet for som et permanent medlem av gruppen. Denne metoden sikrer effektiv drift av fusjonsteamet, samtidig som teamet får tilgang til flere ressurser som produkteierne trenger for å nå målene.

Etablere rytmen til en forretningsmodell

Synkronisering av driftsrytmer relatert til apputvikling i et fusjonsteam kan forbedre teamets effektivitet ved å tilpasse seg følgende struktur:

• Definer en gjentatt kalenderhendelse for teamsynkronisering. For de fleste team er det i orden med ukentlige statusoppdateringer eller annenhver uke. Du bør imidlertid ikke planlegge møter bare fordi du ønsker å ha møter, og du må prøve å unngå å øke hyppigheten for møter som nærmer seg tidsfrister, siden denne metoden kan være kontraproduktiv.
• Hold deg til avtalte arbeidstimer. Ideelt sett vil teamet ditt være plassert på samme sted, men fusjonsteam kan også arbeide effektivt på tvers av geografiske områder og tidssoner. Uansett arbeidsplan må du sørge for at alle forstår hensikten med og varigheten av arbeidstiden og respekterer disse grensene.
• Skap en ukentlig rytme. Teamets ukentlige rytme bør omfatte egenarbeid, samarbeidende samhandlinger og, når det er nødvendig, effektive møter. Disse møtene bør ha et bestemt formål, for eksempel følgende:
  • Omfangsgjennomganger – for å samle team på nye initiativer.
  • Brukeropplevelseanmeldelser – for å gå over apputforming og testversjoner. Møter for å planlegge andre møter, møter i stedet for e-poster eller direktemeldinger, eller møter uten et klart definert formål, dreper produktiviteten.
• Arbeid effektivt. Teamet må innrette seg internt for å skape den mest nyttige løsningen. Denne innrettingen bør inneholde muligheten til å bruke komponenter som andre har bygd på nytt.
• Oppretthold konsekvent fremdrift mot målet. For å sikre at teamet oppfyller målene, er det viktig at alle samarbeider for å oppnå dette resultatet. For fusjonsteam som arbeider med Power Apps, innebærer det å opprettholde denne fremdriften å fange opp og forstå tilbakemeldinger fra brukere, prioritere etterslep og etablere og vedlikeholde et helhetlig veikart for hele prosjektet.
• Generer en matrise for støtte. En matrise for støtte gir en strukturert metode for å få nødvendig støtte til å gå videre i forhold til teamets samlede mål. En uunngåelig utfordring med eksperter på forretningsteknologi som bygger apper direkte, er når de når grensene for kunnskap og ferdigheter. På dette punktet, hvem skal de kontakt, og hvordan skal de gjøre det? Hvordan håndterer de en brukerfeilrapport? Denne matrisen bør definere hvordan de kan utstede en støtteforespørsel for å engasjere det riktige teamet til feilsøking og løsing av problemet, basert på hvor vanskelig problemet er. Denne matrisen forklarer eskalerings- og feilsøkingsbanen for hvert støttescenario.

Definer hvordan teamet kommuniserer

Standardisering av teamkommunikasjon er en annen viktig komponent for å opprettholde en effektiv drift. Alle teammedlemmer må vite hvordan teamet kobler til, spesielt i asynkrone moduser på tvers av tidssoner. Din kommunikasjonsstrategi bør vurdere følgende områder:

• Kanaler. Hvilke kanaler skal teamet bruke for primær- og sekundærkommunikasjon? Hva er fordelene og ulempene med hver av dem? I en verden av valg er det ikke sikkert at det å ta i bruk e-post er den beste løsningen, og alternativer som Microsoft Teams kan gi bedre klarhet, forbedret sporbarhet og høyere svarprosent.
• Varslingstyper. Hvordan varsler du teamet om oppdateringer eller hendelser de må gjøre noe med?
• Meldingshyppighet og -volum. Hvor ofte informerer du teamet? Daglig kommunikasjon kan gi et nyttig sammendrag av hva som har skjedd den dagen, men enkelte meldinger må kanskje ageres på tidligere. De fleste kunnskapsarbeidere er overbelastet med e-postmeldinger. Sørg for at du oppnår en balanse mellom hyppighet og volum for å unngå at teammedlemmer blir overbelastet med prosjektrelaterte meldinger.
• Automatisering. Hvordan kan du automatisere kommunikasjonsprosessen? Standardiserte e-postmaler, flasker og hendelsesvarsler kan hjelpe, men de må brukes på en ansvarlig måte hvis de ikke skal overbelaste teammedlemmenes mulighet til å svare.
• Gode kommunikasjonsferdigheter. Ikke alle i et team vil ha samme kommunikasjonsnivå, men alle kan bli bedre. Enkle fremgangsmåter som å velge et godt emne for en e-postmelding gjør en stor forskjell i hvor godt teamet svarer på meldingen. Oppmuntre til enkel og effektiv skriving i all kommunikasjon, der det finnes handlinger som teammedlemmer må utføre, være spesifikke og fremkalle disse handlingene på emnelinjen.

Et eksempel på hvordan du bruker effektiv kommunikasjonsferdigheter, kan være stedet der du må endre en tabelldefinisjon i Dataverse, for eksempel legge til flere felter. Når du sender ut et varsel om denne tilsiktede endringen, må teamet forstå at hvis de ikke svarer innen rimelig tid, indikerer denne mangelen på svar avtalen deres. Standardiserte og logiske kommunikasjonsprosesser bidrar til å forbedre effektiviteten og levere forventede resultater.

Publisere en dokumentasjonsportal

Dokumentasjon er ikke bare en valgfri del av et prosjekt – det er viktig for kommunikasjon, samarbeid, støtte og pågående operasjoner. Kommentert kode er god kode og det å opprette omfattende forklarings- og opplæringsdokumentasjon er en vesentlig del av distribusjons- og læringsfasene i ethvert oppsigelsesprosjekt.

• Appkatalog. Appkatalogen er en matrise eller tabell som oppsummerer og koordinerer alle apper som ligger hos et bestemt team. Katalogen inneholder alle de respektive eierne fra delen om roller og ansvar. En nøkkelfunksjon er å sikre at teamet vet nøyaktig hvem som eier hva, og dermed forenkle prosessen med å kontakte det riktige teammedlemmet for å få spesifikke svar.
• Tekniske spørsmål. Teamet ditt bør ha en oppbevaringssted for vanlige (eller ikke fullt så vanlige) tekniske spørsmål om driften av appen. Disse spørsmålene må være rimelige, med svarene velskrevne og tilgjengelige.
• Veiledninger. Veiledninger er umiddelbart fordøybare sett med prosedyrer som gir enkle svar på vanlige spørsmål om konfigurasjon og drift. De besvarer vanligvis et bestemt spørsmål, for eksempel "Hvordan kommer jeg i gang med å opprette en ny app?"
• Pålasting. Pålastingsinstruksjoner er interne dokumenter som er utformet for å hjelpe nye teammedlemmer. Denne dokumentasjonen inkluderer informasjon som tilgangsforespørsler, kobling av distribusjonslister for e-post, konfigurasjon og abonnement på varsler og så videre.

Beste fremgangsmåter

De beste fremgangsmåtene nedenfor bør hjelpe deg med å definere grenser og fremgangsmåter for effektivt arbeid i fusjonsteam.

Ansvarlighet

Mens utviklings- og oppsamningsteam ledet av utviklere muliggjør rask apputvikling og -distribusjon, er det svært viktig å sikre at denne innsatsen blir utført med i partnerskap med IT-avdelingen. Utviklere må være ansvarlige overfor IT for å hindre problemer i forhold til veksten av skygge-IT-systemer.

IT må derfor varsles hver gang en utvikler begynner å bygge en app. Denne varslingen muliggjør i sin tur utviklingsprosessen fordi IT kan gi egnet støtte til utvikleren og fusjonsteamet, slik at de kan lage godt utformede apper som er ordentlig sikret og administrert.

Automatisering

En godt implementert automatisering kan gi en stor økning i produktiviteten. Et eksempel på hvordan du øker distribusjonssuksessen for løsningen, er å automatisere eventuelle nødvendige kontroller i distribusjoner av flere løsninger. Disse automatiske kontrollene kan omfatte følgende:

• Verifisering av løsningsversjoner der hver distribusjon bruker et oppdatert versjonsnummer, og dermed unngår problemer ved feilsøking.
• Dupliser tilkoblingsreferanser.
• Manglende tilkoblingsreferanser.
• Dupliser komponenter.

Løsningen PR-kontroller inneholder et eksempel på hvordan denne automatiseringen kan innlemmes på en effektiv måte.

Rapportering

Fusion Teams og apper utviklet av utviklere må tilpasses til en første datatilnærming, som betyr å bygge apper der det er mulig å overvåke suksess direkte. Oppnåelse av dette resultatet krever god instrumentering som gir mulighet til å finne ut hva teamet gjør bra, sammen med analyser av denne tilbakemeldingen for å generere nøyaktige vurderinger av effektiviteten til en bestemt app. Du bør gjøre følgende for å oppnå dette resultatet:

• Overvåk og vurder apper. Selv om én person mener at noe er nyttig eller en god idé, betyr ikke det automatisk at alle vil finne verdi i det. Teamene må overvåke appens nyttbarhet og vurdere funksjonaliteten for å sikre at eventuelle nye utviklinger er nyttige og fungerer på riktig måte.
• Oppmuntre til godt skjønn. Du bør med andre ord ikke bygge apper bare fordi du kan – du bør i stedet kun utvikle dem for å løse et bestemt forretningsbehov.