Share
Jeg er en del av teamet som nylig har lansert en webapp som heter Dunked. Dunked er en gratis, enkel å bruke online portefølje for kreative typer. Fra mai 2013 er vi i offentlig beta; fortsetter å bygge ut funksjoner, samt gjøre inkrementelle forbedringer basert på tilbakemeldinger fra brukerne.
I denne artikkelen skal jeg diskutere noen av grunnene til at jeg tror at en betaversjon er viktig for utviklingen av produktet. Jeg vil også diskutere hvordan vi, på Dunked, går om prosessen med å overvåke og samle tilbakemeldinger fra brukerne. Til slutt vil jeg diskutere hvordan vi skal gjennomføre endringer basert på brukerens tilbakemelding når vi fortsetter å bygge ut produktet.
Jeg tror personlig at å ha en beta lansering er en veldig god idé. Selvfølgelig er det uheldig å frigjøre noe som er riddled med feil. Det er også en dårlig ide å frigjøre et produkt som ikke er klart for offentlig forbruk. Det er langt bedre å frigjøre produktet når det har de nødvendige kjernefunksjonene og er fri for feil.
Google er nok en av de mer kjente selskapene som i utgangspunktet tilbyr produkter som en beta-utgivelse. Gmail er et godt eksempel. Gmail var i privat beta fra april 2004 til februar 2007, da den ble gjort tilgjengelig for allmennheten. Selv da hadde den fortsatt «beta» -merket. Gmail ble ikke offisielt tatt ut av beta i ytterligere to år. Å ha det som et beta-produkt gjorde det mulig for Google-ingeniører å fortsette å forbedre Gmail basert på brukerdata, samt å teste forskjellige tillegg.
Perfekt eksisterer bare ikke innenfor programvareutvikling
Jeg skjønner at det kan være vanskelig å la brukerne se et produkt før du tror det er perfekt. Men perfekt eksisterer bare ikke innenfor programvareutvikling. Du vil alltid trenger å iterere over et produkt i en konstant innsats for å gjøre forbedringer. Jeg tror at ved å frigjøre en beta-versjon av et produkt, setter du deg i stand til å best tilby brukerne hva de vil. Du kan ha forutsetninger som bare er feil ut. Ved å operere i beta, kan du raskt svinge for å forbedre produktet til brukerens behov.
Ved å ta Dunked til å starte, følte vi at det var avgjørende å identifisere og etablere forskjellene mellom må-ha-funksjoner og hyggelige funksjoner. Må-ha funksjoner er funksjonene som former, og i hovedsak, lage produktet ditt. Must-haves er de funksjonene du bør fokusere på før pre-launch. Når du har fullført listen over must-haves, start. Etter lansering kan du takle de hyggelige, løse eventuelle feil som oppstår, og foreta justeringer basert på tilbakemeldinger fra brukeren..
Som vi fortsetter å bygge, er tilbakemeldingen til brukeren som gull. Brukerne forteller oss når vi gjør ting bra; når vi gjør ting feil og når vi blir bare dumme. Fordi bruker tilbakemelding er så verdifull, er det viktig at du har et system på plass før lanseringen, slik at du kan overvåke og samle tilbakemelding. Du må også etablere et system for å reagere på tilbakemeldingen du mottar.
Overvåking og innsamling av tilbakemelding er ingen enkel oppgave. Brukere er alle forskjellige, med varierende preferanser i hvordan de går om å uttrykke sine meninger. Derfor må du ha et system på plass for aktivt å overvåke en rekke kanaler med tilbakemelding. Vi har valgt å bruke Desk. Det fungerer som vårt sentrale hub, og samler alle tweets rettet mot vårt @DunkedHQ Twitter-håndtak, kommentarer på vår Facebook-side og e-postmeldinger sendt via vårt kontaktskjema for støtte (dette skjemaet er knyttet til fra selve appen). Det gjør det mulig for meg å logge inn på et enkelt sted, hvor jeg kan se gjennom og svare på tilbakemelding i den rekkefølgen den ble sendt inn. Dette er en vinn-vinn for oss og for brukere. Brukere kan uttrykke sine meninger, men de føler seg mest komfortable, og vi kan veldig enkelt få tilgang til all tilbakemelding på et enkelt sted.
Det håndterer nåværende brukere, men hva med folkene som bare sletter sine kontoer uten å gi tilbakemelding. Vet at kontoene vil bli stengt, og gjør ditt beste for å samle inn informasjon fra brukere som lukker kontoene sine. På Dunked, leder brukeren til en rask "exit" -undersøkelse når de har fullført kontoutslettingsprosessen. Undersøkelsen er helt valgfri og kan fullføres på under fem minutter. De fleste folk har vært villige til å fylle ut det, og gir oss ytterligere tilbakemelding på hvorfor de slettet sin konto. Vi har brukt Wufoo til å håndtere våre undersøkelsesbehov fordi de gjør det veldig enkelt.
Nå som vi har en metode for å overvåke og samle tilbakemelding, hva skal vi gjøre med det? For Dunked har vi en ganske enkel tilnærming. Vi bruker en oppgaveliste i Basecamp for å hente tilbakemeldingen vi samler inn. Når en bruker skriver inn med en foreslått forbedring eller ber om en manglende funksjon, legger vi det til vår ønskeliste / forslag til oppgaveliste. Denne listen inneholder også våre tidligere nevnte hyggelige funksjoner. Ikke alle elementene som legges til i listen, blir lagt til i Dunked, men det hjelper oss med å overvåke forslagene. Vanlige funksjonsforespørsler er notert, flyttet til toppen av listen, og er ofte inkludert i våre kodespor, som jeg vil diskutere senere.
Dessverre har Dunked-plattformen ikke vært perfekt, slik at vi noen ganger får feilrapporter. Vi opprettholder en separat feilliste også innenfor Basecamp. Ethvert element lagt til feillisten betraktes som en topp prioritet og er løst så raskt som mulig.
Som jeg tidligere nevnte fortsetter vi å bygge ut kjernefunksjoner for Dunked, men vi føler at det er viktig å reagere på tilbakemeldingene fra tidlige brukere. Fordi brukerne har vært så gode i å gi oss tilbakemelding, vil vi implementere deres forslag etter hvert som tiden tillater det. Vi gjør dette gjennom daglige kode sprints. En eller to ganger i uken, vil vi gå gjennom vår forslag / tilbakemelding liste, og velg noen elementer som kan fylles ut på en enkelt dag med koding. Vi fullfører disse elementene, test på vår utviklingsserver, og trykk deretter til produksjonsserveren når vi er fornøyd med koden.
For å illustrere hvordan bruker tilbakemelding har forbedret Dunked, bør du vurdere følgende eksempel. For bildeopplastinger opprettet vi en enkel, klikk for opplastingsknapp. Ved å klikke på knappen startet filleseren på brukerens datamaskin, slik at de kan bla gjennom og laste opp bilder for sine prosjekter. Det fungerte perfekt for oss. Brukerne hadde imidlertid noen problemer.
Det er to grunnleggende alternativer for hvordan du håndterer bildeopplastinger: klikk for å laste opp eller dra og slipp for å laste opp. Som det viser seg, vi (Team Dunked) hver foretrekker klikk for å laste opp. Vi trodde ikke at brukerne ville ha dra-og-slipp-opplastinger. Ved å samle tilbakemelding ble det tydelig at vi hadde rom for forbedring av bildeopplastinger. Vi la til «Drage-og-slipp-opplastinger» til vår ønskeliste / forslagsliste. Etter flere forespørsler ble dra-og-slipp-opplastinger lagt til i en av våre tidlige kodeprints. Nå når du vil laste opp bilder til et prosjekt, kan du klikke for å laste opp eller dra og slippe.
Dette er et ganske enkelt eksempel på hvordan brukerne brukte Dunked annerledes enn vi forutså. Vi har aldri vurdert at brukerne ville bli kvitt vår tradisjonelle metode for bildeopplastinger. I overvåking, samling og handling etter tilbakemeldinger fra brukerne kunne vi imidlertid forbedre Dunked for brukerne våre.
Nå som jeg har forklart litt om vår tilnærming til en beta-utgivelse, og hvorfor jeg tror at beta-utgivelser er flotte, må jeg diskutere noen av de feilene og begrensningene som kan plage en beta-utgivelse. Den største feilen man kan få i en beta-utgivelse, er å frigjøre en beta før den er klar. Hvis du støter på feil i din egen test, eller hvis du ikke har kjørt et grundig sett med tester på søknaden din, har du ikke noe firma som frigir deg til beta. Når du slipper ut programvare som du vet, ikke er klar for utgivelse, risikerer du tilliten til brukerne og produktets levetid. Mens de fleste beta-brukere er villige til å tilgi mindre bugs som dukker opp i beta, er det uansvarlig å frigjøre et produkt som du vet å være buggy..
Når du slipper ut programvare som du vet, ikke er klar for utgivelse, risikerer du tilliten til brukerne og produktets levetid.
Den nest største feilen du kan lage i en beta-utgivelse, er å la brukerne for fort. Mens du kan kjøre stresstester, vet du ikke 100% hva serveren din kan håndtere før den er satt under en ekte test. Hvis serveren kommer til å krasje, vil du at den skal krasje med 1000 beta inviterer ut og ikke 10.000 eller 100.000 beta inviterer utestående. I tillegg er du i beta, så det er mulig at du kommer over en feil eller to. Med Dunked, for eksempel, hadde vi en merkelig feil relatert til enkelte prosjekt snegler. Alt fungerte bra med administrasjonen, men live-siden resulterte i en 403-feil. Det viste seg å være en veldig enkel løsning. Men fordi problemet var relatert til nettadressene, måtte vi rette opp eksisterende nettadresseslett. Det var absolutt lettere å søke og rette opp hundrevis av prosjekt og sideskredder enn det ville ha vært for hundretusener.
En av de største begrensningene i en beta-utgivelse er relatert til tilbakemelding. Å gi brukere beta-tilgang betyr ikke at de vil gi deg tilbakemelding. Brukere kan fullt ut tenkt å gi tilbakemelding, men har rett og slett ikke tid til å gi tilbakemelding til ord. De kan også føle at de gjør noe galt, når søknaden ikke fungerer som de forventer, og dermed ikke skrive deg med tilbakemelding. I tillegg, hvis du må iterere over en viss komponent i søknaden din, er det uansett at kvaliteten og mengden av tilbakemeldingen kommer til å gå bort.
Jeg tror ikke at det er klokt å prøve å inkludere hver enkelt ønsket funksjon når du starter et produkt. Jeg tror du er bedre i å lansere en "fullført" betaversjon, og fortsetter å lukte over produktet, og legger til flere funksjoner. Ved å gjøre det kan du samle og bruke brukerfeedback for å forbedre produktet.
Når du sier det, må du ha en plan for hvordan du skal overvåke, samle og handle på tilbakemeldingene du samler. Dermed er du i stand til å legge til funksjoner som skaper reell verdi for brukeren, og forbedrer sjansene for suksess.
Accentsconagua