Selv om du ikke trenger å være en webutvikler for å starte et teknologibasert selskap, må du definitivt jobbe med et på et tidspunkt. Og nei, det er ikke så lett som å ansette noen til å bygge opp visjonen din og bare se på den kommer til live - du vil være ansvarlig for å finne den rette personen for teamet ditt, instruere dem om hva de skal utvikle (ideelt sett jobber du i en samarbeidende måte), og administrere prosjektet underveis.
Og gjennom hele denne prosessen er det noen få ting som mange gründere lærer på den harde måten. Her er hva du skal vite før du begynner.
1. Valider ideene dine før du begynner å utvikle
Har du en god ide for et nytt produkt eller en funksjon? Instinktene dine kan være å finne en utvikler og komme i gang med å bygge med en gang - men først er det viktig å teste om kundene dine faktisk vil ha det.
For å gjøre dette, spesifiser hvilket problem du vil løse (f.eks. "Vi vil at brukere skal komme tilbake til nettstedet ofte"). Deretter lager du en målbar hypotese som du kan teste for å se om brukerne dine faktisk vil oppføre seg på en måte som støtter løsningen din. For eksempel kan hypotesen din være: "Å la brukere legge ut statusoppdateringer kommer til å generere en økning i brukerinteraksjoner og brukeroppbevaring."
Når du har gjort dette, lager du en prototype av funksjonen du ønsker å bygge. Og du trenger ikke en utvikler for dette ennå - for et tidlig utkast kan du lage en klikkbar demo ved hjelp av PowerPoint eller Word, eller til og med bruke en papirskisse. Det finnes også mer avanserte prototyping- og wireframing-verktøy, for eksempel Axure, Mockingbird og Balsamiq, som du bør være komfortabel med hvis du skal administrere et produkt.
Deretter - før du involverer utviklerne dine - viser prototypen til kundene dine (eller potensielle kunder) og få tilbakemeldinger. (Du kan planlegge personlige intervjuer eller bruke elektroniske verktøy som Usabilla eller UserTesting.com.) Still dem åpne spørsmål for å måle tankene og interessen deres for funksjonen, og prøv å virkelig forstå om løsningen er spennende dem eller løse en smerteterskel. Og i så fall? Først da er det på tide å gå videre til å faktisk bygge noe.
2. Ansett og bygg et flott Dev-team
Å ansette de rette menneskene er nødvendig i en hvilken som helst organisasjon, men når du ansetter noen som bygger produktet ditt og bringer visjonen din til live - det er helt avgjørende.
Her er den mest verdifulle ansettelsestimen jeg har lært: Lei inn for DNA først, og for arbeidserfaring for det andre. Lag en liste over egenskapene du verdsetter som et selskap, eller "DNA" (dvs. ubarmhjertig stasjon, vil få jobben gjort uansett hva, humor) - så sørg for at personen du intervjuer eller snakker for å matche de fleste elementene du kom frem til.
Det som er like viktig er å ansette personer med dyktighet, ikke et spesielt ferdighetssett. På det tekniske området blir ferdigheter foreldet annethvert år, så det er bedre å ansette folk som er i stand til å lære nye teknologier (og ideelt sett har en oversikt over å gjøre det) i stedet for folk som tilfeldigvis vet hvordan de skal gjøre noe spesifikt nå . Husk at denne personen ideelt sett vil være med deg i lang tid, og du vil forsikre deg om at han eller hun er en god kamp både nå og senere.
3. Administrer prosjektet hvert steg på veien
Til slutt, være involvert i byggingen av produktet ditt. En vanlig feil jeg ser folk gjøre: En grunnlegger vil sende produktspesifikasjoner til en utvikler, og stole på at alt blir gjort slik grunnleggeren ser det i hodet, og bare sjekke inn igjen når det endelige produktet er klart.
Dette er en oppskrift på katastrofe. Hvis du tar denne hands-off-tilnærmingen, finner du oftere at nettstedet eller produktet ditt ikke implementeres slik du hadde sett for deg. Kanskje var veibeskrivelsene dine uklare, kanskje var de faktisk umulige å implementere teknisk, kanskje utvikleren din bare misforsto. Men uansett hvorfor det skjer - dette er en situasjon du helst bare vil unngå helt. Tro meg, det er mye lettere å holde seg oppdatert på utviklingsprosessen enn det er å måtte gå tilbake og fikse ting senere - eller enda verre, begynn på nytt!
En bedre tilnærming er å bruke "Agile Project Management", en vanlig metode for planlegging og veiledning av et teknisk prosjekt. Et smidig prosjekt fullføres i små seksjoner som kalles iterasjoner eller sprints (daglig, ukentlig eller innen to uker, maks). Etter at en utvikler eller utviklingsteam har fullført en iterasjon, blir den gjennomgått og kritisert av andre medlemmer av prosjektgruppen.
Den viktigste fordelen med smidig prosjektledelse er evnen til å svare på problemer når de oppstår. Du vil kunne følge med på om prosjektet går etter planen eller ikke, forstå hvilke endringer som er nødvendige, og til slutt bidra til å levere et vellykket prosjekt i tide og på budsjett.
For å lære mer om den smidige utviklingsprosessen, introduksjonsvideo og sjekk ut prosjektledelsesverktøy på nettet som Asana og Pivotal Tracker.
