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.

Slik sikrer du datamaskinen din fra identitetstyver

Identitetstyveri er et mareritt som alle kunne oppleve. Det kan påvirke enkeltpersoner, bedrifter og til og med offentlige etater som driver sine tjenester på nettet. Identitetstyver bruker andres identitet til å begå forbrytelser som å stjele, forkjøle eller for egen eller personlig interesse.Som e

(Tekniske og design tips)

Slik bruker du MutationObserver API for DOM Node Changes

Her er et scenario: Rita, et magasinforfatter redigerer en artikkel av hennes online. Hun sparer sine endringer, og ser meldingen "endringer lagret!" Bare da merker hun en skrivefeil hun savnet. Hun løser det, og er ved å klikke "lagre", når hun får en sint telefonsamtale fra sjefen sin.Ett

(Tekniske og design tips)