Demo Day: 5 tips for å forhindre feil og blunders

Programvaren er følsom . La oss innse det, en ">" kan være forskjellen mellom å se ut som en ekspert, eller ønsker å forsvinne umiddelbart fra jordens overflate. Etter mange års utvikling og år med å gjøre det profesjonelt (for å leve) med ansiktet mitt og navnet bak alt vi produserer, har jeg kommet for å forstå teorien om "når, ikke om det bryter".

La meg begynne med å si dette: Det er ingen enkel måte å håndtere en katastrofal feil på, eller til og med en liten detaljbit på demonstrasjonsdagen . Det stykke programvare du har jobbet med, vil på et tidspunkt skamme deg . Det som betyr noe er hvordan du reduserer sjansene for at ting blåser opp i ansiktet ditt når du minst trenger det.

Basert på vår ydmyke og ubetydelige opplevelse, er disse trinnene vi har tatt gjennom våre prosesser enn kan bidra til å redusere sjansene for en komplett feilutløst smeltefeil på demonstrasjonsdagen.

Å starte av

Hvis du vil være den som gjør demo av "siste" programvareproduktet til kunder, potensielle investorer eller potensielle brukere, må du være mer oppmerksom enn noen andre . På slutten av dagen vil du være den som holder hendene i ansiktet ditt og svetter voldsomt når noe går galt.

Tankegangen bør være: "Ingen bryr seg så mye som meg." Selv om laget ditt er en haug med rockstjerner, bør alle fortsatt tenke at ingen bryr seg så mye som de gjør.

1. Behandle din leverbare tidsplan til din fordel

Så til det punktet, hvis timeplanen din sier klientpresentasjonen er mandag, skriv den ned til onsdagen før det og ha alt mocked opp som om det var den faktiske mandagen. Ikke tenk på denne spotten som en øvelsesløp - det er det ikke . Vi bør tenke på det som datoen og handle som den er.

Gå gjennom hvert trinn som du var i selve presentasjonen, og du vil avdekke de riktige feilene (det vil si de med høyere tendens til å dukke opp i selve demoen). Hvis du ikke klarer å presentere denne datoen nøyaktig som den faktiske presentasjonsdagen, vil det ikke være veldig gunstig.

2. begrense omfanget av din demo

Hvis du vet nøyaktig funksjonaliteten du vil vise deg, ikke fokus på å feilsøke alt . Fokuser på feilsøking av demo-spesifikk funksjonalitet . For noen uker siden leverte vi en mellomstor, forbrukerrettet, sosial innflytelsesportal for et latinamerikansk selskap. De ønsket å demo registreringsprosessen slik at de kunne begynne å registrere seg potensielle brukere.

Vi visste nøyaktig hva de ønsket. Vi debugged det sammen med resten av plattformen - stor feil!

Natten før demonstrasjonen (ut av ren flaks) fant vi en ginormøs feil i det øyeblikk da brukeren ville slå "Registrer" i en bestemt, marerittfremkallende nettleser som vil forbli navnløs (men vi vet alle hvilken jeg refererer til). Hold fokus på debugging .

3. Fokus på Plan B, Og A (Og ikke glem Plan C) ...

Når ting går galt, og du blir tatt av vakt, ta et sekund for å føle deg som en idiot ... og deretter raskt overgang til Plan B-modus. Har flere forskjellige sikkerhetskopieringsplaner som lar deg fortsette med din demo.

Har en frakoblet versjon. Har en versjon som ikke er koblet til baksiden, og er bare en front-end-versjon. Hold en prototype på telefonen din. Mockups. Videoer. Noe . Ikke legg alle eggene dine i en ordspråklig kurv.

4. ... og gi deg god tid til å forberede deg

Under dette trinnet kan du bare finne ut at ditt stykke programvare har et problem. Du kan avdekke en stor feil som på et tidspunkt vil blåse opp under din demo, og dette er en flott mulighet til å bestemme hvilke materialer du vil bruke: Planlegg A + Plan B, eller kanskje bare Plan B eller Plan C, etc.

Det er så mange faktorer som kan spille mot programvaredemoen din, ikke bare kodelinjene. Tenk på Internett, datamaskinen du vil demoere på, projeksjonen, etc. Gi deg selv tid til å finne ut om versjonen av programvaren du vil kjøre vil være ok. Og hvis det ikke er tilfelle, har du tid til å reagere .

5. Gi det av og legg det av mye

Hver utvikler kan forstå hvor jeg kommer fra når jeg sier, "la det se lyset." Som utviklere, og reklamer generelt, har vi en tendens til å overbeskytte våre kreasjoner til de er de lyseste skinnende edelstener, noensinne. I virkeligheten skjønner du imidlertid den perlen rundt og finner en stor brikke på den, når du minst forventer det.

"Lever" eller vis produktet så mye som mulig til folk som kan styre programmet i forskjellige miljøer, nettlesere, oppløsninger, operativsystemer, brukerkontoer etc. Få frem og tilbake prosessen startet på produktet tidlig og hold det konstant . Utviklingsorienterte brukere kunne ikke være mer annerledes enn sluttbrukerne.

Wrap Up

Demo-bug-apokalypsen kan skje med noen. Bare tenk på de siste overskriftene der noen av de største selskapene i teknologi ble involvert av de mest amatørfeilene. Poenget er: la oss ikke bli fanget av vakt når viktige ting er på linjen.

Redaktørens notat: Dette innlegget er skrevet av Gino Ferrand for Hongkiat.com. Gino er en selvlært iOS og webutvikler, og grunnlegger av Tecla Labs. Han jobber i Generatr.co, og du finner ham på Twitter.

7 ting klienter si og hva de egentlig betyr

Å vite et annet språk enn ditt morsmål gir deg alltid en positiv kant. Som profesjonell designer er det behov for å forstå Clientish-språket. Clientish er språket til en homogen gruppe av mennesker som kalles "klienter", en art som designere har å håndtere hver dag.Selv om klienter kommer fra forskjellige bakgrunner og har varierte typer, snakker alle disse språkene. Derfor b

(Tekniske og design tips)

Forbedre blogtrafikk: 5 må-ha egenskaper

Tidligere var de fleste blogger daglige ramblings av personlig karakter uten høy trafikk eller sidevisninger som mål. I dag er situasjonen helt annerledes da vi ser en rekke blogger opprettet for å oppnå høy trafikk med mange formål som inntektsgenerering.Det er mange praktiske måter å oppnå høy trafikk som å skape detaljerte opplæringsprogrammer som leserne er ivrige etter å lære, eller snakker om visse varme emner som målrettede lesere er interessert i å lese videre og kommentere. Disse metodene

(Tekniske og design tips)