nl.hideout-lastation.com
Demodag: 5 tips om bugs en blunders te voorkomen
Software is gevoelig . Laten we eerlijk zijn, een ">" kan het verschil zijn tussen er uitzien als een expert, of direct van de aarde verdwijnen. Na jaren van ontwikkeling en jaren van professioneel doen (voor de kost) met mijn gezicht en naam achter alles wat we produceren, ben ik de theorie gaan begrijpen van "wanneer, niet als, het breekt".
Laat ik beginnen met dit te zeggen: er is geen gemakkelijke manier om een catastrofale bug, of zelfs een bug met kleine details, af te handelen op de demodag . Dat stukje software waaraan je hebt gewerkt, zal je op een gegeven moment in verlegenheid brengen . Het gaat erom hoe je de kansen verkleint dat dingen in je gezicht opduiken wanneer je het het minst nodig hebt.
Gebaseerd op onze nederige en onbeduidende ervaring, zijn dit de stappen die we in onze processen hebben gezet, dan dat we de kans op een complete bug-getriggerde meltdown op demo-dag kunnen verminderen.
Om te beginnen
Als u degene bent die de demo van het "definitieve" softwareproduct doet naar klanten, potentiële investeerders of potentiële gebruikers, moet u meer aandacht besteden dan wie dan ook . Aan het eind van de dag zul je degene zijn die je handen voor je gezicht houdt en overvloedig zweeft als er iets misgaat.
De mindset zou moeten zijn: "Niemand geeft er meer om dan ik." Zelfs als je team een stelletje rocksterren is, zou iedereen toch moeten denken dat niemand erom geeft als zij.
1. Beheer uw deliverable schema in uw voordeel
Dus, naar het punt, als je schema zegt dat de presentatie van de klant op maandag is, noteer het dan voor de woensdag ervoor en laat je alles bespotten alsof het de echte maandag was. Denk niet aan deze mock date als een oefenloop - dat is het niet . We moeten het als DE datum zien en handelen zoals het is.
Doorloop elke stap zoals je was in de eigenlijke presentatie, en je zult de juiste bugs vinden (di degenen met een hogere neiging om in de eigenlijke demo te verschijnen). Als u deze datum niet nauwkeurig kunt weergeven als de werkelijke presentatiedatum, is dit niet erg gunstig.
2. Beperk de reikwijdte van uw demo
Als je precies weet welke functionaliteit je zult laten zien, richt je dan niet op alles wat fout gaat . Richt u op het debuggen van uw demospecifieke functionaliteit . Een paar weken geleden leverden we een middelgroot, consumentgericht, sociaal beïnvloedingsportaal voor een Latijns-Amerikaans bedrijf. Ze wilden het registratieproces demonstreren, zodat ze konden beginnen met het aanmelden van potentiële gebruikers.
We wisten precies wat ze wilden. We debuggen dat samen met de rest van het platform - grote fout!
De avond voor de demo (uit puur geluk) vonden we een gigantische bug op het exacte moment waarop de gebruiker op "Registreren" zou klikken in een specifieke, nachtmerrie-inducerende, browser die naamloos blijft (maar we weten allemaal welke ik verwijs naar). Houd uw inspanningen voor het opsporen van fouten geconcentreerd .
3. Focus op Plan B en A (en vergeet Plan C niet) ...
Wanneer dingen fout gaan en je bent overrompeld, neem dan een seconde om je als een dwaas te voelen ... en ga dan snel over naar de Plan B-modus. Heb verschillende back-upschema's waarmee je je demo kunt voortzetten.
Heb een offline versie. Een versie hebben die niet is gekoppeld aan de back-end en slechts een front-endversie is. Houd een prototype op je telefoon. Testmodellen. Videos. Iets . Leg niet al uw eieren in één spreekwoordelijke mand.
4. ... en geef jezelf voldoende tijd om je voor te bereiden
Tijdens deze stap zult u wellicht merken dat uw stuk software een probleem heeft. Je zou een enorme bug kunnen ontdekken die op een gegeven moment opduikt tijdens je demo, en dit is een geweldige mogelijkheid om te beslissen welke materialen je zult gebruiken: Plan A + Plan B, of misschien alleen Plan B, of Plan C, etc.
Er zijn zoveel factoren die tegen uw softwaredemo kunnen spelen, niet alleen de coderegels. Denk aan internet, de computer waar je aan het demonstreren bent, de projectie, enz. Geef jezelf de tijd om erachter te komen of de versie van de software die je gaat gebruiken in orde zal zijn. En als dat niet het geval is, hebt u tijd om te reageren .
5. Geef het af en geef het veel af
Elke ontwikkelaar kan begrijpen waar ik vandaan kom als ik zeg: "Laat het het licht zien." Als ontwikkelaars en creatievelingen in het algemeen neigen we ernaar om onze creaties te overbelasten totdat ze de helderste glanzende edelstenen ooit zijn. Maar in werkelijkheid zul je dat juweel omdraaien en een grote chip vinden, wanneer je het het minst verwacht.
"Lever" of laat het product zo veel mogelijk zien aan mensen die de toepassing kunnen besturen in verschillende omgevingen, browsers, resoluties, besturingssystemen, gebruikersaccounts, enz. Zorg dat het heen en weer proces op uw product vroeg is gestart en houd het is constant . Ontwikkelingsgerichte gebruikers kunnen niet anders zijn dan eindgebruikers.
Afronden
De demo-bug-apocalyps kan iedereen overkomen. Denk maar aan de meest recente krantenkoppen waar enkele van de grootste bedrijven in tech betrokken waren bij de meeste amateurfouten. Het punt is: laten we niet overrompeld worden als belangrijke dingen op het spel staan.
Noot van de redactie: dit bericht is geschreven door Gino Ferrand voor Hongkiat.com. Gino is autodidact iOS en webontwikkelaar en oprichter van Tecla Labs. Hij werkt in Generatr.co en je kunt hem vinden op Twitter.
20 Wrist-Worthy Smartwatch UI Herontwerpen
Voor elke nieuwe hardware die wordt uitgebracht, maakt de software en het UI-ontwerp het product . Net zoals we een slecht ontworpen mobiele gebruikersinterface haten, voelen we ons aangetrokken tot gebruikersinterface die soepel werken, goed doordacht zijn en er mooi uitzien wanneer ze worden gebruikt
30 acroniemen die webontwikkelaars moeten weten
Het jargon van de webontwikkelindustrie bevat zoveel afkortingen die we dag in dag uit gebruiken, dat het niet alleen ontmoedigend is voor beginners, maar soms ook moeilijk voor praktiserende ontwikkelaars om te volgen . De meesten van ons gebruiken veilig meer gebruikelijke acroniemen zoals HTML, CSS of HTTP, maar hoe zit het met de minder gebruikte of nieuwere
